本文出处忘记了，从我的电脑里搜索到了，费了老半天编辑啊，手累。。。

1 软件测试

编程大师说：“任何一个程序，无论它多么小，总存在着错误。”
初学者不相信大师的话，他问：“如果有个程序小得只执行一个简单的功能，那会怎么样
“这样的程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生错误。”
但初学者不满足，他问：“如果操作系统不失效，那会怎么样
“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生错误。”
初学者仍不满足，再问：“如果硬件也不失效，那会怎么样
大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是错误。”
没有错误的程序世间难求。（摘自《编程之道》）

错误是一种严重的软件缺陷。测试的目的是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量。由于测试与改错并不能体现软件开发人员的聪明才智，相反地，它们带来了更多的烦恼与牢骚。因此在教学和开发实践中，软件测试总是遭受冷遇。
医生犯的错误最终会被埋葬在地下，从此一了百了。但软件的错误不会自动消失。据统计，对于大多数的软件产品而言，用于测试与改错的时间将占整个软件开发周期的30％。如果不懂得有效地进行测试、改错，却花了那么高的代价，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。所以我们必须学会测试与改错，并且要把测试与改错工作做好。

1.1 测试的常识与道理

1.1.1 你真的懂测试吗/h3>

在软件开发过程中，编程和测试是紧密相关、相辅相成的技术活动，缺一不可。从理论上讲，两者不分贵贱，同等重要。但在大多数软件企业中，程序员的待遇普遍要高于专职的测试人员。即使不考虑待遇问题，大多数人认为开发工作比测试工作有乐趣、有成就感、有前途。所以计算机专业人员通常会把编程当成一种看家本领，舍得下功夫学习和专研，但极少有人以这种态度对待软件测试。这种意识导致软件测试被过于轻视。不仅学生们在读书时懒得学习测试（目前国内高校似乎没有“软件测试”的课程），就连有数年工作经验的软件开发人员也未必懂得测试。
我在读博士学位时，某天有一位比我聪明、编程比我快、学习能力比我强的计算机专业博士生恭恭敬敬地请我坐好，并且史无前例地削了苹果请我吃，为的是向我请教软件测试问题。你必定以为这位仁兄好学之极，非也！他和我同窗三年，从未探讨过软件工程。只因为他明天要去应聘，生怕在面试时被人问倒，就央我当晚为他恶补一把。他还特地问起“白盒测试和黑盒测试”，因为那个公司曾经面试过这类问题。我讲了一会儿测试的概念与方法，他叹了一口气说：“这些玩意儿我读大学十年从来没搞过，怎么能记得住、讲得出来。唉，就去碰碰运气吧。”
我在公司里遇到的软件测试问题要比学校里多得多。曾有一位项目经理来诉苦，说有个项目成员很差劲，不会测试，给了他参考书，还是不知道如何下手，问我怎么办。
我说：“既然他自己学不会，那么你就花点时间指导他，他不至于笨到教不会吧!”
项目经理说：“测试又不是我的工作，我不懂也没时间，我还有很多管理工作要做。”
面对这样的项目经理，你无话可说，只能叹气。
人力资源是有限的，很多情况下软件开发人员不得不兼任测试人员的角色。所以开发人员学会测试只有好处没有坏处，否则会误事的。我发现在小公司干过的人通常技能比较全面，他们从需求开发、系统设计、编程、测试、直到维护，一路滚爬过去，做过一个项目后，该学的全学会了。在这方面大公司的员工反而不及小公司的，由于大公司的岗位安排是“一个萝卜一个坑”，员工们老是做岗位所指定的工作，技术覆盖面相对而言比较窄。
不少开发人员虽然不敌视测试工作，但是有“临时抱佛脚”的坏习惯，往往事到临头才到处找测试资料，向人请教。经常有人向我要关于测试的文档模板，对付测试。
你以为有了文档模板就懂得如何测试了吗！
测试虽然并不深奥，但是学好并不容易。不懂得“有效”测试的项目小组往往面临这样的问题：计划中的时间很快就用完了，即使有迹象表明软件中还遗漏着不少缺陷，也只好草草收场，把麻烦留在将来。

1.1.2 为什么需要测试/h3>

由于软件之中有缺陷，要靠测试把缺陷找出来。缺陷是软件“毛病”的统称，其范畴比“错误”更广。例如有些缺陷虽然不会导致软件发生错误，但可能使软件的性能严重下降。
Bug是缺陷的形象比喻，人们喜欢说Bug是因为可以把Bug当作“替罪羊”。软件的缺陷明明是人造成的，有了Bug这词后就可以把责任推给Bug——“都是Bug搞的鬼”。Bug真是太冤枉了。
为什么需要测试为软件中有Bug。
为什么软件中有Bugbr> 以下是一些原因：
（1）开发人员不太了解需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了Bug。
（2）软件系统越来越复杂，开发人员不太可能精通所有的技术，如果不能正确地使用技术，将产生Bug。
（3）技术文档普遍比较糟糕，文档本身就有Bug，导致使用者产生更多的Bug。
（4）软件需求、设计报告、程序经常发生变更，每次变更都可能产生新的Bug。
（5）任何人在编程时都可能犯错误，导致程序中有Bug。
（6）人们常处于进度的压力之下，急忙之下容易产生Bug，尤其是在期限临近之际。
（7）人们过于自信，喜欢说“没问题”，不真实的“没问题”将产生真正的问题。

1.1.3 测试的目的是什么/h3>

测试的目的是为了发现尽可能多的缺陷。可是这个观念不容易被人接受。
正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是不真实的。
目前高校的科技成果鉴定普遍存在虚假现象。“成果鉴定”相当于软件开发过程中的“验收测试”，但是大部分人在测试时“只报喜不报忧”。我在读硕士时就亲身经历过这样的事情。我们的项目主要研究集成电路制造过程中的成品率问题。当时国内大多数工厂的集成电路成品率只有百分之几，我们开发的软件可以把“精心挑选”的集成电路的成品率优化到98%。演示效果是如此的好，以致一位评委（某厂的总工程师）不无讽刺地说：“采用你们的成果，我们可要发大财了。”这个项目就轻易地通过了鉴定，并且不久后获得了电子工业部科技进步二等奖。这就象在考试时通过作弊取得了好成绩而被表扬。我那时尚且纯真，羞愧之余，不禁对高校科研成果的水平和真实性大失所望。当我在大学里呆了十年后，已经不再失望，因为很少抱希望。
如果为了说明软件有多么好，那么应当制作专门的演示。千万不要将“测试”与“演示”混为一谈。
看来测试并不单单是个技术问题，还是个职业道德问题。
根据测试的目的，可以得出一个推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
如果测试工作很全面、很认真，但是的确没有发现新的缺陷。那么这样的测试是否毫无价值br> 不，那不是测试的过失，应当反过来理解：由于软件的质量实在太好了，以致于这样的测试发现不了缺陷。
所以，如果产品通过了严格的测试，大家不要不吭气，应当好好地宣传一把，把测试的成本捞回一些。

1.1.4 一些常识和经验之谈

（1）测试能提高软件的质量，但是提高质量不能依赖测试。
（2）测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。
（3）测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
（4）每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
（5）80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错。
（6）测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。

1.2 测试的分类与比较

1.2.1 测试的分类及关系图

如果一股脑地罗列出测试的种类，常见的大体有20种，如表7-1所示（参见文献 [Hower2001]）。

表7-1中那么多的测试会把人吓住，让人们不知如何下手。如果不把测试好好分类，理清关系，人们理解和执行起来都会很费力。
按测试方式分类，可以把不关心软件内部实现的测试通称为“黑盒测试”。反之，将依赖软件内部实现的测试通称为“白盒测试”。黑盒测试的主要依据是“需求”，而白盒测试的主要依据是“设计”。
按测试阶段分类，测试可分4个主要阶段：单元测试、集成测试、系统测试和验收测试。这是一种“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。
如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系，如图7-1所示（参见文献[Wiegers2000, p116]）。

1.2.2 黑盒测试与白盒测试的比较

“黑盒”、“白盒”都是比喻。“黑盒”表示看不见盒子里头的东西，意味着黑盒测试不关心软件内部设计和程序实现，只关心外部表现，即通过观察输入与输出即可知道测试的结论。任何人都可以依据软件需求来执行黑盒测试。
白盒测试关注的是被测对象的内部状况，需要跟踪源代码的运行。白盒测试者必须理解软件内部设计与程序实现，并且能够编写测试驱动程序，一般由开发人员兼任测试人员的角色。
黑盒测试与白盒测试的对比如表3所示。

1.4.3 测试何时结束/h3>

测试什么时候可以结束如下几种答复：
（1）在软件消亡之前，测试永远不可能结束。它只是从测试人员转移到用户或维护人员身上而已。
（2）从统计学角度讲，如果软件运行1000个CPU小时内不出错的概率大于0.995的话，那么我们就有95％的信心说测试可以结束了。
（3）当期限来临或经费用光了的时候，测试就可以结束了。
第一种答复是真理，但毫无参考价值。第二种答复比较科学，但太抽象，普通技术人员难以掌握。第三种答复特别实在，但很无奈，因为测试是被迫终止的。
以下是三种比较实用的规则，可以结合使用。
一、基于测试用例的规则
（1）先构造测试用例（并请有关人员进行评审）。
（2）在测试过程中，当测试用例的不通过率达到20％时，则拒绝继续测试，待开发人员修正软件后再进行测试。
（3）当功能性测试用例通过率达到100％，非功能性测试用例通过率达到90％时，允许正常结束测试。
该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。
二、基于“测试期缺陷密度”的规则
把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。绘制“测试时间－缺陷数”的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于10，m小于等于1。该规则比较适用于系统测试阶段。
三、基于“运行期缺陷密度”的规则
把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间－缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于100，m小于等于1。该规则比较适用于验收测试阶段，即客户试运行软件期间。

1.4.4 需求经常变更怎么办

需求变更可能会让项目所有成员遭殃，如何“预防变更”以及“降低变更的代价”是软件工程的经典问题。本节仅论述需求变更对测试的影响。
需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是上一次测试有可能白做了，如果软件变更比较大的话。
测试人员不要只是自认倒霉，应当主动作些应变：
（1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。
（2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。
（3）向领导反映需求变更对测试造成的影响，为自己争取余地。
（4）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。
引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该怎么办br> 如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功能，测试人员不可认为这些功能反正是“锦上添花”，便自作主张地测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。

1.4.5 奖励机制

在系统测试和验收测试阶段，应当设法让更多的人参与测试，以便尽早发掘并消灭缺陷。为了调动测试者的积极性，企业或项目应当设立奖励机制：
（1）根据缺陷的危害程度，把奖金分等级。
（2）每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。
注意，奖金额要适当，太低了人们不感兴趣。若奖金额比较高，如果软件错误百出，会让项目破产的。

1.5 测试规范

1.5.1 流程图

所有阶段的测试都应当遵循如下流程（如图7-2所示）：
第一步：制定测试计划。该计划被批准后转向第二步。
第二步：设计测试用例。该用例被批准后转向第三步。
第三步：如果满足“启动准则”（Entry Criteria），那么执行测试。
第四步：撰写测试报告。
第五步：消除软件缺陷。如果满足“完成准则”（Exit Criteria），那么正常结束测试。

1.5.4 测试用例

什么是测试用例br> 测试用例是用于检验软件是否符合要求的一种“示例”，其基本要素有：目的、前提条件、输入数据或动作、期望的响应。《测试用例》就是描述各种测试用例的文档，相当于一本“测试操作手册”。关于测试用例的一些常识如下：
（1）设计测试用例的目的是找出需求、设计、代码中的毛病，因此最好尽可能早地设计。
（2）测试用例的设计需要动脑筋，不见得比“正向设计”简单。
（3）不同的测试用例其用途应当不一样，不要累赘。
每个测试阶段可能有各色各样的测试用例，撰写《测试用例》显然比写《测试计划》费时费力，所以不要只让一个人干，应当让大家分担。设计与审批《测试用例》的角色及递交时间如表7-8所示。

1.5.5 测试报告

《测试报告》的主要用途是：（1）记录测试实况；（2）对本次测试进行分析，提出建议。表7-10是《测试报告》的参考模板，使用时应根据实际情况进行修改。

1.6.1.1 接口测试

数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。每个接口可能有多个输入参数，每个参数有“典型值”、“边界值”、“异常值”之分，所以输入的组合数可能并不少。根据接口的定义，可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。如果实际输出与期望的输出不一致，那么说明程序有错误。白盒方式的接口测试和黑盒方式的功能测试，其方法十分相似，请参见7.7.1节。
由于接口测试只关心输入和输出，并不知道函数体内是怎样运行的。有时候，输入、输出都是正确的，而函数体内却可能有错误（或者隐藏了错误）。所以仍需要进行路径测试。

1.6.1.2 路径测试

一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。想遍历测试几乎是不可能的，不测试或者胡乱找几条路径测试却又不行。
对于严格系统而言，采用形式化或准形式化的方式来推导出的那些路径才能让人信服。文献 [Pressman99, p315-p326] 介绍了“流图符号”、“环形复杂性估算”、“图矩阵”、“条件测试”、“数据流测试”、“循环测试”等方法。这些方法似乎比编程还要复杂，普通技术人员很难掌握。
对于非严格系统而言，在分析路径方面化费很多精力是不值得的。我认为在构造接口测试的同时已经建立了测试路径。因为每一种输入将产生唯一的输出，输入与输出之间的路径也是唯一的。由于接口测试中的输入是有代表性的，因此相应的路径也具有代表性，用得着费煞苦心地去找测试路径吗br> 如果路径已经选好了，接下来的工作就是沿着路径一条一条地检查语句。遇到循环时作适当的处理后可以跳出。路径测试的检查表如表7-11所示：

当然，由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没有被测试。预防措施有：
（１）观察是否有程序语句从来没有被执行过。如果发生在这种情况，要么是程序有错误，存在无用的代码；要么是接口测试不充分，漏掉了一些路径。
（２）要特别留意函数体内的错误处理程序块（如果存在的话），这是最易被人疏忽的路径，隐患最多。
（３）采用自动化的测试工具，可以自动分析路径测试的“覆盖率”。

1.6.1.3在单元测试与集成测试中的应用

单元测试只能采用白盒测试方式。由于单元本身不能运行，必须先构造相应的测试驱动程序。单元的接口测试语句全部存放在测试驱动程序中。使用编译器提供的调试工具，可以从测试驱动程序跟踪到单元里面，实现接口测试和路径测试。
如果集成测试阶段需要白盒测试，可以把“集成体”当成大的单元看待。如果“集成体”本身就可以运行，那么不必构造额外的测试驱动程序。直接通过用户界面输入接口测试用例，再用调试工具跟踪到“集成体”内部即可。
接口与路径测试用例的参考模板如表7-12所示。

1.6.3 健壮性测试

健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
容错是指发生异常情况时软件不出错误的能力，容错是非常健壮的意思。比如Unix的容错能力很强，很难搞死它。
恢复是指软件发生错误后（不论死活）重新运行时，能否恢复到没有发生错误前的状态的能力。
从语义上理解，恢复不及容错那么健壮。例如某人挨了坏蛋一顿拳脚：特别健壮的人一点事都没有，表示有容错能力；比较健壮人，虽然被打到在地，过了一会还能爬起来，除了皮肉之痛外倒也不用去医院，表示恢复能力比较强；而虚弱的人可能在短期恢复不过来，得在病床上躺很久。
恢复能力是很有价值的。Microsoft公司早期的窗口系统如Windows 3.x和Windows 9x，动不动就死机，其容错性的确比较差。但它们的恢复能力还不错，机器重新启动后一般都能正常运行，看在这个份上，人们也愿意将就着用。
比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错，例如：
（1）输入错误的数据类型。如“猴”年“马”月。
（2）输入定义域之外的数值。如上海人常说的“十三点”（钟表上最大的数值是十二点没有十三点，上海人常用“十三点”来讽刺神经兮兮的人）。
粗暴一些方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试客户机－服务器模式的软件时，把网络线拔掉，造成通信异常中断。这里我举不出更多的例子来，因为我从没有对软件粗暴过，并且这辈子也不打算学会粗暴。让别人去做“大猩猩”测试吧。
恢复测试重点考察一下几项：
（1）系统能否重新运行；
（2）有无重要的数据丢失；
（3）是否毁坏了其它相关的软件硬件。
健壮性测试用例的参考模板如表7-14所示。

1.6.5 用户界面测试和评估

绝大多数软件拥有图形用户界面。图形用户界面测试和评估的重点是正确性、易用性和视觉效果。在评价易用性和视觉效果时，主观性非常强，应当考虑多个人的观点。
常见的界面元素有窗口、菜单、工具条、按钮、输入框、列表等等，其组合数量可能非常多。好在界面元素大多是成熟的、标准的构件，它们本身一般不会出错，我们可以把精力集中在使用上，省事不少。用户界面测试用例的参考模板如表7-16所示。

1.6.6 信息安全性测试

信息安全性（security）是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。信息安全是一门比较深奥的学问，其发展是建立在正义与邪恶的斗争之上。这世界似乎不存在绝对安全的系统，连美国军方的系统都频频被黑客入侵。如今全球黑客泛滥，真是“道高一尺，魔高一丈”啊。
对于大多数软件产品而言，杜绝非法入侵既不可能也没有必要。因为开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。究竟什么样的安全性是令人满意的呢br> 一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、危险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
信息安全性测试有如下步骤：
（1）为非法入侵设立目标，例如“盗窃某个文件”或“更改数据库记录”等。
（2）邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”。
（3）如果有人成功了，请他详述入侵的过程。别忘了给予奖励。
根据“黑客”的“口供”，开发人员找出系统的漏洞。如果修补漏洞很容易，那么马上就改正。如果修补的代价很高，那么就与“损失的代价”相比较，分析值不值得修改漏洞。
信息安全性测试用例的参考模板如表7-18所示。

1.6.8 可靠性测试

口语中的可靠性含义宽泛，几乎把正确性、健壮性全部囊括。只要人们发现系统有毛病，便归结为可靠性差。如果这样理解，可靠性测试就会与功能测试、健壮性测试重复。
严格地讲，可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠性测试可能会花费很长时间。
比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。
可靠性测试用例的参考模板如表7-20所示。

1.6.9 安装/反安装测试

功能测试、健壮性测试、性能测试、安全性测试、压力测试、可靠性测试都是在系统已经存在的前提下开展的。即使上述测试都通过了，如果系统在安装时出了错误，用户也不能接受，这真是“大风浪都挺过来了，却在阴沟里翻了船”。
安装测试的主要工作：来源：上善若水2020