软件测试.docx
《软件测试.docx》由会员分享，可在线阅读，更多相关《软件测试.docx（45页珍藏版）》请在冰豆网上搜索。
软件测试
软件测试
软件测试3
7.1测试的常识与道理4
7.1.1你真的懂测试吗？
4
7.1.2为什么需要测试？
5
7.1.3测试的目的是什么？
5
7.1.4一些常识和经验之谈6
7.2测试的分类与比较6
7.2.1测试的分类及关系图6
7.2.2黑盒测试与白盒测试的比较8
7.2.3有了黑盒测试为什么还要白盒测试？
9
7.2.4单元测试9
7.2.5集成测试10
7.2.6系统测试11
7.2.7验收测试11
7.2.8回归测试12
7.3测试人员的组织12
7.3.1Microsoft公司的经验教训13
7.3.2测试心理学13
7.3.3如何组织测试人员？
14
7.3.4避免开发人员与测试人员产生矛盾14
7.4企业的测试策略15
7.4.1一些指导方针15
7.4.2如何合理地减少测试工作量15
7.4.3测试何时结束？
17
7.4.4需求经常变更怎么办18
7.4.5奖励机制18
7.5测试规范18
7.5.1流程图18
7.5.2测试的“启动准则”和“完成准则”19
7.5.3测试计划19
7.5.4测试用例21
7.5.5测试报告22
7.6软件系统的主要测试内容及技术22
7.6.1接口与路径测试23
7.6.1.1接口测试23
7.6.1.2路径测试24
7.6.1.3在单元测试与集成测试中的应用25
7.6.2功能测试26
7.6.3健壮性测试27
7.6.4性能测试28
7.6.5用户界面测试29
7.6.6信息安全性测试31
7.6.7压力测试31
7.6.8可靠性测试32
7.6.9安装/反安装测试33
7.7改错34
7.7.1要有勇气改错34
7.7.2对症下药34
7.7.3调试方法35
7.7.4消除代码错误的注意事项35
7.8小结36
第7章软件测试
编程大师说：
“任何一个程序，无论它多么小，总存在着错误。
”
初学者不相信大师的话，他问：
“如果有个程序小得只执行一个简单的功能，那会怎么样？
”
“这样的程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生错误。
”
但初学者不满足，他问：
“如果操作系统不失效，那会怎么样？
”
“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生错误。
”
初学者仍不满足，再问：
“如果硬件也不失效，那会怎么样？
”
大师长叹一声道：
“没有不失效的硬件。
但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是错误。
”
没有错误的程序世间难求。
（摘自《编程之道》）
错误是一种严重的软件缺陷。
测试的目的是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量。
由于测试与改错并不能体现软件开发人员的聪明才智，相反地，它们带来了更多的烦恼与牢骚。
因此在教学和开发实践中，软件测试总是遭受冷遇。
医生犯的错误最终会被埋葬在地下，从此一了百了。
但软件的错误不会自动消失。
据统计，对于大多数的软件产品而言，用于测试与改错的时间将占整个软件开发周期的30％。
如果不懂得有效地进行测试、改错，却花了那么高的代价，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。
所以我们必须学会测试与改错，并且要把测试与改错工作做好。
7.1测试的常识与道理
7.1.1你真的懂测试吗？
在软件开发过程中，编程和测试是紧密相关、相辅相成的技术活动，缺一不可。
从理论上讲，两者不分贵贱，同等重要。
但在大多数软件企业中，程序员的待遇普遍要高于专职的测试人员。
即使不考虑待遇问题，大多数人认为开发工作比测试工作有乐趣、有成就感、有前途。
所以计算机专业人员通常会把编程当成一种看家本领，舍得下功夫学习和专研，但极少有人以这种态度对待软件测试。
这种意识导致软件测试被过于轻视。
不仅学生们在读书时懒得学习测试（目前国内高校似乎没有“软件测试”的课程），就连有数年工作经验的软件开发人员也未必懂得测试。
我在读博士学位时，某天有一位比我聪明、编程比我快、学习能力比我强的计算机专业博士生恭恭敬敬地请我坐好，并且史无前例地削了苹果请我吃，为的是向我请教软件测试问题。
你必定以为这位仁兄好学之极，非也！
他和我同窗三年，从未探讨过软件工程。
只因为他明天要去应聘，生怕在面试时被人问倒，就央我当晚为他恶补一把。
他还特地问起“白盒测试和黑盒测试”，因为那个公司曾经面试过这类问题。
我讲了一会儿测试的概念与方法，他叹了一口气说：
“这些玩意儿我读大学十年从来没搞过，怎么能记得住、讲得出来。
唉，就去碰碰运气吧。
”
我在公司里遇到的软件测试问题要比学校里多得多。
曾有一位项目经理来诉苦，说有个项目成员很差劲，不会测试，给了他参考书，还是不知道如何下手，问我怎么办。
我说：
“既然他自己学不会，那么你就花点时间指导他，他不至于笨到教不会吧!
”
项目经理说：
“测试又不是我的工作，我不懂也没时间，我还有很多管理工作要做。
”
面对这样的项目经理，你无话可说，只能叹气。
人力资源是有限的，很多情况下软件开发人员不得不兼任测试人员的角色。
所以开发人员学会测试只有好处没有坏处，否则会误事的。
我发现在小公司干过的人通常技能比较全面，他们从需求开发、系统设计、编程、测试、直到维护，一路滚爬过去，做过一个项目后，该学的全学会了。
在这方面大公司的员工反而不及小公司的，由于大公司的岗位安排是“一个萝卜一个坑”，员工们老是做岗位所指定的工作，技术覆盖面相对而言比较窄。
不少开发人员虽然不敌视测试工作，但是有“临时抱佛脚”的坏习惯，往往事到临头才到处找测试资料，向人请教。
经常有人向我要关于测试的文档模板，对付测试。
你以为有了文档模板就懂得如何测试了吗？
否！
测试虽然并不深奥，但是学好并不容易。
不懂得“有效”测试的项目小组往往面临这样的问题：
计划中的时间很快就用完了，即使有迹象表明软件中还遗漏着不少缺陷，也只好草草收场，把麻烦留在将来。
7.1.2为什么需要测试？
由于软件之中有缺陷，要靠测试把缺陷找出来。
缺陷是软件“毛病”的统称，其范畴比“错误”更广。
例如有些缺陷虽然不会导致软件发生错误，但可能使软件的性能严重下降。
Bug是缺陷的形象比喻，人们喜欢说Bug是因为可以把Bug当作“替罪羊”。
软件的缺陷明明是人造成的，有了Bug这词后就可以把责任推给Bug——“都是Bug搞的鬼”。
Bug真是太冤枉了。
为什么需要测试？
因为软件中有Bug。
为什么软件中有Bug？
以下是一些原因：
（1）开发人员不太了解需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了Bug。
（2）软件系统越来越复杂，开发人员不太可能精通所有的技术，如果不能正确地使用技术，将产生Bug。
（3）技术文档普遍比较糟糕，文档本身就有Bug，导致使用者产生更多的Bug。
（4）软件需求、设计报告、程序经常发生变更，每次变更都可能产生新的Bug。
（5）任何人在编程时都可能犯错误，导致程序中有Bug。
（6）人们常处于进度的压力之下，急忙之下容易产生Bug，尤其是在期限临近之际。
（7）人们过于自信，喜欢说“没问题”，不真实的“没问题”将产生真正的问题。
7.1.3测试的目的是什么？
测试的目的是为了发现尽可能多的缺陷。
可是这个观念不容易被人接受。
正确理解测试的目的十分重要。
如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。
这样的测试是不真实的。
目前高校的科技成果鉴定普遍存在虚假现象。
“成果鉴定”相当于软件开发过程中的“验收测试”，但是大部分人在测试时“只报喜不报忧”。
我在读硕士时就亲身经历过这样的事情。
我们的项目主要研究集成电路制造过程中的成品率问题。
当时国内大多数工厂的集成电路成品率只有百分之几，我们开发的软件可以把“精心挑选”的集成电路的成品率优化到98%。
演示效果是如此的好，以致一位评委（某厂的总工程师）不无讽刺地说：
“采用你们的成果，我们可要发大财了。
”这个项目就轻易地通过了鉴定，并且不久后获得了电子工业部科技进步二等奖。
这就象在考试时通过作弊取得了好成绩而被表扬。
我那时尚且纯真，羞愧之余，不禁对高校科研成果的水平和真实性大失所望。
当我在大学里呆了十年后，已经不再失望，因为很少抱希望。
如果为了说明软件有多么好，那么应当制作专门的演示。
千万不要将“测试”与“演示”混为一谈。
看来测试并不单单是个技术问题，还是个职业道德问题。
根据测试的目的，可以得出一个推论：
成功的测试在于发现了迄今尚未发现的缺陷。
所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
如果测试工作很全面、很认真，但是的确没有发现新的缺陷。
那么这样的测试是否毫无价值？
不，那不是测试的过失，应当反过来理解：
由于软件的质量实在太好了，以致于这样的测试发现不了缺陷。
所以，如果产品通过了严格的测试，大家不要不吭气，应当好好地宣传一把，把测试的成本捞回一些。
7.1.4一些常识和经验之谈
（1）测试能提高软件的质量，但是提高质量不能依赖测试。
（2）测试只能证明缺陷存在，不能证明缺陷不存在。
“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。
我们应当祈祷：
软件的缺陷在产品被淘汰之前一直没有机会发作。
（3）测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
（4）每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
（5）80-20原则：
80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错。
（6）测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。
7.2测试的分类与比较
7.2.1测试的分类及关系图
如果一股脑地罗列出测试的种类，常见的大体有20种，如表7-1所示（参见文献[Hower2001]）。
名称
说明
黑盒测试
基于软件需求，而不是基于软件内部设计和程序实现的测试方式。
白盒测试
基于软件内部设计和程序实现的测试方式。
单元测试
主要测试软件模块的源代码。
一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。
集成测试
将一些“构件”集成一起时，测试它们能否正常运行。
这里“构件”可以是程序模块、客户机－服务器程序等等。
功能测试
测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。
一般由独立测试人员执行。
系统测试
测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。
一般由独立测试人员执行，通常采用黑盒测试方式。
回归测试
指错误被修正后或软件功能、环境发生变化后进行的重新测试。
回归测试的困难在于不好确定哪些内容应当被重新测试。
验收测试
由客户或最终用户执行，测试软件系统是否符合需求规格说明书。
负载测试
测试软件系统的最大负载，超出此负载软件可能会失常。
压力测试
概念上与负载测试相似，叫法不同。
性能测试
测试软件在各种状况下的性能，如在正常或最大负载下的状况。
易用性测试
测试软件是否易用，主观性比较强。
一般要根据很多用户的测试反馈信息，才能评价易用性。
安装与反安装测试
测试软件在“全部、部分、升级”等状况下的安装/反安装过程。
恢复测试
测试该系统从故障中恢复过来的能力。
安全性测试
测试该系统防止非法侵入的能力。
兼容性测试
测试该系统与其它软件硬件兼容的能力。
比较测试
通过与同类产品比较，考察该系统的优点、缺点。
Alpha测试
一种先期的用户测试，此时系统刚刚开发完成。
Beta测试
一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。
表7-1测试的常见种类
表7-1中那么多的测试会把人吓住，让人们不知如何下手。
如果不把测试好好分类，理清关系，人们理解和执行起来都会很费力。
按测试方式分类，可以把不关心软件内部实现的测试通称为“黑盒测试”。
反之，将依赖软件内部实现的测试通称为“白盒测试”。
黑盒测试的主要依据是“需求”，而白盒测试的主要依据是“设计”。
按测试阶段分类，测试可分4个主要阶段：
单元测试、集成测试、系统测试和验收测试。
这是一种“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。
如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系，如图7-1所示（参见文献[Wiegers2000,p116]）。
需求开发
高层设计
详细设计
单元测试
集成测试
系统测试
验收测试
编程
图7-1开发与测试的“V”型关系
从测试的内容划分，适合采用白盒测试方式的主要有：
接口测试、路径测试等。
比较适合采用黑盒测试方式的主要有：
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等。
上述测试阶段、测试方式、测试内容的关系如表7-2所示：
测试阶段
主要依据
测试人员、测试方式
主要测试内容
单元测试
系统设计文档
由开发小组执行白盒测试
接口测试、路径测试
集成测试
系统设计文档和软件需求
由开发小组执行白盒测试和黑盒测试
接口测试、路径测试
功能测试、性能测试
系统测试
软件需求
由独立测试小组执行黑盒测试
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试
验收测试
软件需求
由用户执行黑盒测试
表7-2测试阶段、测试方式、测试内容之间的关系
7.2.2黑盒测试与白盒测试的比较
“黑盒”、“白盒”都是比喻。
“黑盒”表示看不见盒子里头的东西，意味着黑盒测试不关心软件内部设计和程序实现，只关心外部表现，即通过观察输入与输出即可知道测试的结论。
任何人都可以依据软件需求来执行黑盒测试。
白盒测试关注的是被测对象的内部状况，需要跟踪源代码的运行。
白盒测试者必须理解软件内部设计与程序实现，并且能够编写测试驱动程序，一般由开发人员兼任测试人员的角色。
黑盒测试与白盒测试的对比如表3所示。
测试方式
特征
依据
测试人员
测试驱动程序
黑盒测试
只关心软件的外部表现，不关心内部设计与实现。
软件需求
任何人（包括开发人员、独立测试人员和用户）
一般无需编写额外的测试驱动程序
白盒测试
关注软件的内部设计与实现，要跟踪源代码的运行。
设计文档
由开发人员兼任测试人员的角色
需要编写额外的测试驱动程序
表7-3黑盒测试与白盒测试的对比
7.2.3有了黑盒测试为什么还要白盒测试？
通常用户关心的是软件是否符合既定的需求，而不关心软件是如何设计与实现的。
既然如此，我们为什么不把精力集中在黑盒测试上，为什么还要进行白盒测试？
道理如下：
（1）黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。
因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
（2）白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。
在这方面，黑盒测试存在严重的不足。
问题还可以反过来问：
如果程序通过了白盒测试，为什么还需要黑盒测试？
道理如下：
通过了白盒测试只能说明程序符合设计要求，并不能说明最终的软件符合用户需求。
如果系统设计偏离了用户需求，那么100％正确的程序也不是用户想要的。
将错就错不等于正确，所以还需要黑盒测试。
可见黑盒测试与白盒测试都不能取代对方，只有两者结合才能弥补对方的不足。
7.2.4单元测试
在系统设计阶段，整个系统最终被细分为许多模块，这里可以把模块理解为单元。
每个单元的接口、数据结构与算法都已经设计完成。
在实现阶段，程序员首先编写这些单元，然后把单元集成为子系统，再把子系统集成为最终的目标系统。
在做集成之前，应当先执行单元测试，以保证单元本身正确无误。
为了测试单元是否符合设计要求，必须跟踪到单元内部，检查所有的源代码。
因此单元测试采用白盒测试方式。
由于单元通常不是可运行程序（如.exe文件），因此无法直接测试。
测试者必须编写额外的可运行的测试驱动程序，通过测试驱动程序调用单元的接口，从而跟踪到单元的内部。
单元测试的主要麻烦就在此处，并且由于测试驱动程序不是目标系统的组成部分，测试完了也就用不着了（至多被备份起来），让人有一种“不值得”的感觉。
每当你有这种思绪时，请尽量想开点。
人一生中会干不知多少“不值得”的事情，就别在乎单元测试中那一点浪费了！
何况单元测试做好了，以后的工作就会轻松一些，好处还是蛮多的。
单元测试人员既要了解单元的详细设计，又要有本事为该单元编写测试驱动程序。
这样的测试人员不好找，可以就地取材，让开发小组成员兼任测试人员的角色。
通常做法是，开发人员编写完成某个单元后，先自我检查，然后请同伴进行代码审查，再请同伴进行单元测试，如果发现缺陷，原开发者应当及时修正程序。
这样边开发、边审查、边测试，可以高效率地发现并排除单元中的缺陷。
如果单元通过了同伴的审查与测试，就可以升级成为基准（Baselined）文件，以后再对该单元修改时，必须遵循变更控制规则，避免修改过于频繁而失控。
一个系统的单元通常比较多，看起来单元测试的工作量比较大，挺烦人的。
但由于每个单元比较小，而且相对独立，因此测试与改错的难度比较底。
综合考虑，单元测试并不可怕。
能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
这样是否会提高单元测试的效率呢？
不会！
如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。
最糟糕的是无法估计测试与改错的工作量，使进度失去控制。
因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
7.2.5集成测试
软件实现一般是渐增式的，从编写单元到完成整个系统，通常要经历数次集成（除非软件的规模很小）。
于是每次单元集成都要进行相应的集成测试。
有人可能问：
“如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？
”
的确有可能！
要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。
例如：
数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。
所以集成测试是必要的，不是多此一举。
集成测试界于单元测试和系统测试之间，如何测试通常取决于“集成体”的特征。
刚开始时，“集成体”的规模比较小，离目标系统比较遥远，那么要以白盒测试为主。
不仅要跟踪“集成体”的那部分新代码（从语义上理解，它们不能算是单元），有时还要跟踪到那些被测试过的单元的内部，如果错误是单元造成的话。
随着集成次数的增加，“集成体”的规模越来越大，离目标系统越来越近，此时要以黑盒测试为主。
可以提前做系统测试阶段的部分工作，例如子系统的功能测试、性能测试等等。
由于每个“集成体”并不是最终的目标系统，所以测试者还得编写测试仿真程序。
集成测试工作通常让开发小组成员承担，采用白盒加黑盒的混合测试方式。
集成测试属于软件实现阶段，如何安排测试取决于集成开发的方式。
常见的集成方式有两种：
“自顶向下”和“自底向上”。
因此产生“自顶向下”和“自底向上”两种集成测试方式，一种集成测试方式的优点差不多就是另一种的缺点[Pressman99,p345-348]。
我们并不建议严格按照“自顶向下”和“自底向上”的方式开发软件，折衷办法是：
软件结构的高层采用“自顶向下”方式开发，软件结构的底层采用“自底向上”方式开发。
如果软件系统要分若干次集成，能否只在最后一次做集成测试？
以便降低集成测试的工作量呢？
道理如同单元测试不能等到所有单元开发完了再做一样，把集成测试拖到最后执行也会导致缺陷的累积和扩散，使集成测试与改错的代价增加。
7.2.6系统测试
当软件开发完毕后，需要进行全面的系统测试。
系统测试采用黑盒测方式，其目的是检查系统是否符合软件需求。
系统测试的主要内容有：
功能测试、健壮性测试、性能－效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等。
在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
不能！
因为集成测试是在仿真环境中开展的，那不是真正的目标系统。
再者，单元测试和集成测试通常由开发小组执行。
根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
为了保证测试的客观性，应当由机构的独立测试小组来执行系统测试。
7.2.7验收测试
验收测试的内容与系统测试的内容几乎是相同的，主要区别在于测试人员不同。
验收测试人员来自于客户方，而系统测试人员则来自于开发方。
难道开发方的测试人员执行的系统测试还不够客观公正吗？
非得要请用户重新测试吗？
这不仅仅是“客观公正”的问题，主要原因如下：
（1）首先是“信任”问题。
对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢?
所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。
否则，那是客户失职。
（2）其次，即使开发方测试人员对天发誓“他们在系统测试时铁面无私、绝无半点虚假”，也不能因此省略客户验收测试。
不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。
测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
如此说来，何不让用户取代测试小组，把系统测试和验收测试合二为一呢？
理论上是可以的，但在现实中却行不通，因为：
（1）系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。
用户还有自己的事情要做，他们为什么要为别人测试呢？
即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。
（2）系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。
如果让用户发现这样的“内幕”，一是丢脸，二是会吓跑买主。
所以还是关起门来，先让测试小组做完系统测试的好。
验收测试可以分成两类：
Alpha测试和Beta测试。
两者的主要区别是测试的场所不同。
Alpha测试是指把用户请到开发方的场所来测试，Beta测试是指在一个或多个用户的场所进行测测试。
Alpha测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。
而Beta测试的环境是不受开发方控制的，谁也不知道用户如何折磨软件，用户数量相对比较多，时间不集中。
一般地，Alpha测试先于Beta测试执行。
通用的软件产品需要较大规模的Beta测试，测试周期比较长。
如果产品通过了Beta测试，那么就可以正式发行了。
如果是合同项目，应当在合同中说明验收测试是Alpha测试还是Beta测试，或者两个都
升级会员 