软件测试需要掌握那些技能与知识？

欣欣

我是一名刚毕业的大学毕业生，现在在一家面向石油、石化方向的计算机软件公司做软件测试工作。对于这个领域的认识，我可谓是从0开始。希望大家能给我一点意见和建议，让我从茫然中逐渐走出。

testing

找本软件测试的入门书籍先看看。比如《软件测试入门》之类的书籍

云层

看看软件工程也不错，越看越有味道

ezcross

以人为本！！！

主要是你个人应该勤奋，并富有耐心，善于学习，思考和发现问题，要细心有条理，善于总结问题。有坦诚、清晰、简明的交流表达能力。最重要的是你喜欢测试工作。

有了这些，其他的都只是个时间的问题了。

云层

最重要的是你喜欢测试工作。

ezcross

up

曹向志

测试工作远比开发工作要难，起码做深入测试的时候，需要掌握很多的知识，才能胜任测试工作。做过开发最好，如果没有，先了解一些开发知识。再阅读一些测试类书籍，关于测试的书籍目前比较多，但是几乎找不到一本写得完善的书，测试理论也不完善，需要自己从浅入手。上面的朋友提出的《软件测试入门》还可以。另外，到www.china-pub.com 上看看，很多书籍有评论。

ezcross

up

up

up

欣欣

谢谢大家对我的指导，我现在很开心，因为我已经喜欢上了测试，并且从中得到了很多的乐趣

盘子

我是因为看到了这个论坛中的内容，才喜欢上测试的

xiaohan

我本来就挺喜欢测试的,看来论坛里有这么多的内容,使我更加的喜欢测试!不过我还是一位新手,还希望大家可以多多的指点我!
  我这里先谢了!

hotbadcat

Originally posted by 盘子 at 2004-10-14 05:43 PM:
我是因为看到了这个论坛中的内容，才喜欢上测试的

So did I!

tempuser

有热情才是关键

boluomao

受教

dreamdj012

我对编程比较感兴趣，我现在不明白的是测试和编程的调试有什么差异？？

orange1997orang

软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。也就是说，如果用户面对着应用程序的 A 界面，在使用硬件 B 的时候做 C 操作，那么 D 结果应该出现。所谓受控制的条件应该包括正常条件和非正常条件。应该故意地去促使错误的发生，也就是事情在不该出现的时候出现或者在应该出现的时候没有出现。从本质上说，软件测试是“探测”。

在如何负责质量保障和软件测试的责任方面，各个机构有不同的做法。有时候，由一个小组或者个人来负责。常见的办法是项目组包括了测试人员和开发人员，他们在一起合作工作，由项目负责人来对质量保障进行总负责。这取决于该机构的大小和该机构的商务结构。

   (软件测试是在受控制的条件下对系统或应用程序进行操作并评价操作的结果)

在软件开发过程中5个常见的问题是什么?

M 需求说明差 (poor requirements) ── 需求不清楚、不完整、太概括、或者不可测试，都会造成问题。

M     不切实际的时间表 (unrealistic schedule) ── 如果在很短的时间里要求做许多事，出现错误是不可避免的。

M     测试不充分 (inadequate testing)── 只能根据客户意见或者系统崩溃来判断系统质量的高低。

M     不断增加功能 (featuritis) ── 在开发正在进行过程中要求增加许多新的功能。这是常见的问题。

M     交流问题 (miscommunication) ── 如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。

(需求说明差 不切实际的时间表 测试不充分 不断增加功能 交流问题)

针对软件开发过程中的问题，有5个解决办法：

ü  可靠的需求 (solid requirements) —— 应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。

ü  合理的时间表 (realistic schedules) —— 为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。

ü  适当的测试 (adequate testing) —— 尽早开始测试；每次改错或变更之后，都应重新测试。项目计划中要为测试和改错留出足够的时间。

ü  尽可能坚持最初的需求 (stick to initial requirements as much as possible) —— 一旦开发工作开始，要准备防止修改需求和新增功能。要说明这样作的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。

ü 沟通 (communication ) —— 在适当时机进行预排和检查；充分利用团组通信工具 —— 电子邮件、群件 (groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档；进行远距离联合作业及协作；尽早使用模型，使得客户的预想是清楚的。

   (可靠的需求 合理的时间表 适当的测试 尽可能的坚持最初的需求 沟通)

软件测试包括哪些内容?

以下是一些需要考虑的步骤：

ü         得到需求、功能设计、内部设计说书和其他必要的文档

ü         得到预算和进度要求

ü         确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 (例如发行过程、变更过程、等等)

ü         确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制

ü         确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试

ü         确定对测试环境的要求 (硬件、软件、通信等)

ü         确定所需的测试用具 (testware)，包括记录/回放工具、覆盖分析、测试跟踪、问题/错误跟踪、等等

ü         确定对测试的输入数据的要求

ü         分配任务和任务负责人，以及所需的劳动力

ü         设立大致的时间表、期限、和里程碑

ü         确定输入环境的类别、边界值分析、错误类别

ü         准备测试计划文件和对计划进行必要的回顾

ü         准备白盒测试案例

ü         对测试案例进行必要的回顾/调查/计划

ü         准备测试环境和测试用具，得到必需的用户手册/参考文件/结构指南/安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据

ü         得到并安装软件版本

ü         进行测试

ü         评估和报告结果

ü         跟踪问题/错误，并解决它

ü         如果有必要，重新进行测试

ü         在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具

  

什么是“测试案例”?

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

注：开发一个应用软件的测试案例的过程，需要全面、深入地考虑该软件的操作，所以有助于发现在其需求或设计里面的问题。因此，如果有可能，在开发周期中应当尽早准备测试案例。

(测试案例包括:测试标识, 案例名称,目标,测试条件/设置,输入数据要求,步骤,以及预期结果)

如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。

由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

ü        对于该项目的用途而言，哪种功能最重要?

ü        哪种功能对用户最明显?

ü        哪种功能对安全影响最大?

ü        哪种功能对用户最有用?

ü        对客户来说，该应用软件的哪个部分最重要?

ü        在开发过程中，该应用软件的哪个部分可以最先测试?

ü        哪一部分代码最复杂，容易导致出现错误?

ü        哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

ü        哪一部分程序与过去项目中引起问题的部分相类似/有关?

ü        哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

ü        需求和设计的那些部分不清楚或不容易读?

ü        开发人员认为在应用软件中哪些部分是高风险的?

ü        哪些问题能造成最差的发行?

ü        哪些问题最能引起用户抱怨?

ü        哪些测试可以容易地覆盖多种功能?

ü        哪些测试在覆盖高风险部分的测试时使用时间最少?

  

如果需求一直在变化怎么办?

这是一个常见的令人头疼的问题。

ü        如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

ü        如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

ü        好的代码注释和好的文档有助于开发人员作出相应的改变。

ü        只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

ü        在项目的时间表中应当留出余量，以应付可能出现的变更。

ü        尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

ü        通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

ü        要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

ü        在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

ü        在设计自动测试剧本时，试图使其有一些灵活性。

ü        在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

ü        对变更进行适当的风险分析，以减少回归测试的要求。

ü        在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

ü        少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。

  面向对象的设计如何影响测试?

好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试，最后追溯到需求，成为一件容易的事。因为它对黑盒测试的影响很少 (不需要了解应用软件的内部设计) ，而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好，就可简化测试设计。

orange1997orang

软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。

不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试。

在谈到软件测试时，许多人都引用Grenford J. Myers在《The Art of Software Testing》一书中的观点：

①、软件测试是为了发现错误而执行程序的过程；
②、测试是为了证明程序有错，而不是证明程序无错误。
③、一个好的测试用例是在于它能发现至今未发现的错误；
④、一个成功的测试是发现了至今未发现的错误的测试。

这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。

首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如 Bev Littlewood发现一个经过测试而正常运行了n小时的系统有继续正常运行n小时的概率。

三、软件测试的基本方法
软件测试的方法和技术是多种多样的。

对于软件测试技术，可以从不同的角度加以分类：

从是否需要执行被测软件的角度，可分为静态测试和动态测试。

从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试；

1、黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

2、白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

3．ALAC(Act-like-a-customer)测试

ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

orange1997orang

人们常常以为，开发一个程序是困难的，测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。

不论是黑盒测试方法还是白盒测试方法，由于测试情况数量巨大，都不可能进行彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。 “黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 “白盒”法是穷举路径测试，贯穿程序的独立路径数是天文数字，但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。E．W．Dijkstra的一句名言对测试的不彻底性作了很好的注解：“程序测试只能证明错误的存在，但不能证明错误不存在”。

在实际测试中，穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例时应注意遵守“经济性”的原则。第一，要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级；第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。掌握好测试量是至关重要的，一位有经验的软件开发管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险，过度测试则会浪费许多宝贵的资源。

测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外，还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下：

①、系统的目的

系统的目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。一台在Boeing 757上的系统应该比一个用于公共图书馆中检索资料的系统需要更多的测试。一个用来控制密封燃气管道的系统应该比一个与有毒爆炸物品无关的系统有更高的可信度。一个安全关键软件的开发组比一个游戏软件开发组要有苛刻得多的查找错误方面的要求。

②、潜在的用户数量

一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。一个在全世界范围内有几千个用户的系统肯定比一个只在办公室中运行的有两三个用户的系统需要更多的测试。如果不能使用的话，前一个系统的经济影响肯定比后一个系统大。除此而外，在分配处理错误的时候，所花的代价的差别也很大。如果在内部系统中发现了一个严重的错误，在处理错误的时候的费用就相对少一些，如果要处理一个遍布全世界的错误就需要花费相当大的财力和精力。

③、信息的价值

在考虑测试的必要性时，还需要将系统中所包含的信息的价值考虑在内，一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这两个系统的用户都希望得到高质量、无错误的系统，但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑，投入与经济价值相对应的时间和金钱去进行测试。

④、开发机构

一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多，因此，对于不同的开发机构来说，所需要的测试的必要性也就截然的不同。

然而，那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是最不可能进行这一活动的，在许多情况下，机构的管理部门并不能真正地理解开发一个高质量的系统的好处。

⑤、测试的时机

测试量会随时间的推移发生改变。在一个竟争很激烈的市场里，争取时间可能是制胜的关键，开始可能不会在测试上花多少时间，但几年后如果市场分配格局已经建立起来了，那么产品的质量就变得更重要了，测试量就要加大。测试量应该针对合适的目标进行调整。

五、软件测试的心理学问题
1、程序测试的过程具有破坏性

人类的活动具有高度的目的性，建立适当的目标具有重要的心理作用。如果我们的目的是要证明程序中没有错误，那我们就会不自觉地朝这个方向去做；也就是说，我们会倾向于挑选那些使程序出错的可能性较小的测试数据。另一方面，如果我们的目标是要证明程序中有错，那就会选择一些易于发现程序所含错误的测试数据。而后一种态度会比前者给程序增添更多的价值。

测试的定义意味着程序测试的过程是具有破坏性的，其程度甚至达到了不可容忍的地步。社会上大多数人的人生观是建设性的，而不是破坏性的。人们倾向于创造一个物品，而不是轻易毁坏—个物品。因此，程序坏—个物品。因此，程序测试的破坏性的定义使人们对程序测试工作望而生畏。程序测试定义还隐含着如何设计测试情况（测过数据），以及应该由谁和不应由谁来测试一个给定程序等等观点。

心理学研究还告诉我们，当人在干一件已经知道是不合适的或不可能做到的事时，往往做得不好。例如：如果让一个人在15分钟解出一个刊登在星期曰《纽约时报》上的交叉填字字谜，10分钟后我们会看到这人几乎没一点进展，因为他会感到实际上不可能做到而放弃自已的努力。然而，如果我们要求花4小时解出这题，那也许就会看到他在开头的10分钟内有较大的进展了。把程序测试定义为在程序中找出错误的过程，就使测试成了可以做到的任务，从而克服了心理上存在的问题。

另一个令人烦躁的问题是即使程序完成了预期要求，仍可能含有错误。也就是说，如果程序不按要求工作，它显然有错，但是如果程序做了不要它做的事，它也有错。

orange1997orang

开发者被指定测试自己的代码是一件很糟糕的事。开发和测试生来就是不同的活动。开发是创造或者建立什么东西的行为，一个模块或者整个系统。而测试的唯一目的是证明一个模块或者系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演的很好。基于这个想法，应该限制开发者在测试中的参与。给他们比较合适的任务是进行有可能的最低层的测试--单元测试。不同当一个程序员在完成了设计，编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。许多户主都知道，揭掉糊墙纸（破坏性过程〉是不容易的，若糊墙纸原先是由他而不是别人贴上的，他几平会感到难以忍受的沮丧。所以，大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），因而不能有效地测试自己的程序。

除了这个心理学问题之外，还有一个重要的问题：程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。

再者，可以把测试看做是对一篇论文或—本书作校对，或与写评论相类似的工作。正如许多作者所知，校对或批评自己的著作是非常困难的。也就是说，在自已的工作中找出缺陷往往是人的心理状态所不容的。

以上看法并不意味着程序员不可能测试自已的程序。不过相比之下如果由另外—些人来进行程序测试，就会更有效、更成功。注意：这个论断并不适用于纠错（改正已知错误），由原来程序的作者纠错肯定效率更高。

3、程库设计机构不应测试自己的程序

在许多意义上来说，一项工程或一程序设计机构是个有生命的有机体，它同样有心理学问题。再者，在大多数情况下，人们都是以在给定日期内，以一定代价编制程序的能力来衡量程序设计机构和项目管理人员的。这祥做的一个理由是时间和成本指标便于衡量，而程序的可靠性却很难度量。要程序设计机构在测试自己的程序时持客观态度是困难的，因为如果用正确的定义看待测试，就不大可能按预定计划完成测试也不大可能把耗费的代价限制在要求的范围以内。

软件生产的三个最重要的因素是：质量、进度和费用。

计算技术的进步，意味着在经济领域中信息系统更新的速度更快。新的硬件技术的发展，均会使软件过时，系统交付使用的时间变得日益重要，新产品在其性能和费用上被其他产品取代之前的推销时间，即市场窗口就已经缩小了。

由于费用和进度的限制，要开发一种高质量、快速交付和低成本的软件产品变得越来越困难，也就是说要同时达到三个目标是困难的。因此在软件产品的开发中就要权衡它们之间的关系，使软件的特性能满足用户的要求，这意味着软件产品特性的度量和预计是必要的。

软件测试由独立测试机构承担有许多好处。独立测试是指软件测试工作由在经济上和管理上独立于开发机构的组织进行。独立测试可以避免软件开发者测试自己开发的软件，由于心理学上的问题，软件开发者难以客观、有效地测试自己的软件，而找出那些因为对问题的误解而产生的错误就更加困难。独立测试还可以避免软件开发机构测试自己的软件，软件产品的开发过程受到时间、成本和质量三者的制约，时间和成本指标便于衡量，而质量却很难度量，因此在软件开发过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试过程受到干扰。

采用独立测试方式，无论在技术上还是管理上，对提高软件测试的有效性都具有重要意义。

①、客观性

对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能够以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完成。

②、专业性

独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效用的必然途径。

③、权威性

由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，由专业化的独立测试机构的评价，更客观、公正和具有权威性。

④、资源有保证

独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性，可以避免开发单位侧重软件开发而对测试工作产生不利的影响。

六、好的测试工程师应具备的素质
人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。

①、沟通能力。

一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

②、移情能力。

和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。

③、技术能力。

就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

④、自信心。

开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

⑤、外交能力。

当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

⑥、幽默感。

在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

⑦、很强的记忆力。

一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

⑧、耐心。

一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

⑨、怀疑精神。

可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

⑩、自我督促。

干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

11、洞察力。

一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

fzx

我此时此刻的感受：离散数学真的挺重要的