测试的基本理论与方法(转帖)
上一篇 / 下一篇 2011-12-31 16:21:27 / 个人分类：软件质量管理
一、对软件测试的误解
1. 如果发布出去的软件有质量问题,那是软件测试人员的错.
2. 软件测试技术要求不高,至少比编程容易多了
3. 软件测试随便找一个能力差的人就能做.
4. 软件测试是测试人员的事,与开发人员无关.
5. 设计-实现-测试,软件测试是开发后期的一个阶段
二、如何理解软件测试
软件测试是一种有效的提高软件质量的手段,但即使在投入上有所保证,测试也不能百分为百发现所有质量隐患.况且软件质量并不仅仅是测试出来的.
很多人认为软件测试就是运行一下软件,看看结果对不对.但实际上,如何在有限的投入下,提高软件测试的效率和产出是一件很见功底的事.好的测试人员不仅要掌握各种测试技术,还要具备丰富的编程经验和对BUG的敏感.测试的复杂之处,除了测试技术问题之外,还有测试管理问题.
测试不是可有可无,随心所欲的.规范化的软件开发需要对软件测试早做计划,分配必要的时间,人力和财力等资源,并将其作为项目管理的一个部分加以控制和协调.
开发和测试是软件项目相辅相成的两个过程,人员间的交流,协作和配合是提高整体效率的重要因素.
软件产品开发完毕,再进行测试的观念是有悖于生命周期理论的.软件产品质量问题越晚发现,修复的代价越大.
一些常识和经验之谈
测试能提高软件的质量，但是提高质量不能依赖测试。
测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。
测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错
测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。
三、软件测试的定义
软件测试是为了发现错误而执行程序的过程
软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程.
四、软件测试的对象
软件测试不等于程序测试.软件测试贯穿于软件定义和开发的整个期间.需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象.
软件生存各个阶段间的确认和验证
软件配置：包括软件需求规格说明、软件设计规格说明、源代码 等；
测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。
测试工具：为提高软件测试效率，可使用测试工具支持测试工具。例如：测试数据自动生成程序、测试结果分析程序等。
五、测试的目的
测试是程序的执行过程,目的在于发现错误;
一个好的测试用例在于发现至今未发现的错误;
一个成功的测试是发现了至今的错误的测试.
六、测试的种类
名称 说明
黑盒测试 基于软件需求，而不是基于软件内部设计和程序实现的测试方式。
白盒测试 基于软件内部设计和程序实现的测试方式。
单元测试 主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，
因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外
的测试驱动程序。
集成测试 将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以
是程序模块、客户机－服务器程序等等。
功能测试 测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。一般由独
立测试人员执行。
系统测试 测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。一般
由独立测试人员执行，通常采用黑盒测试方式。
回归测试 指错误被修正后或软件功能、环境发生变化后进行的重新测试。回归测试
的困难在于不好确定哪些内容应当被重新测试。
验收测试 由客户或最终用户执行，测试软件系统是否符合需求规格说明书。
名称 说明
负载测试 测试软件系统的最大负载，超出此负载软件可能会失常。
压力测试 概念上与负载测试相似，叫法不同。
性能测试 测试软件在各种状况下的性能，如在正常或最大负载下的状况。
易用性测试 测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信
息，才能评价易用性。
安装与反安装测试 测试软件在“全部、部分、升级”等状况下的安装/反安装过程。
恢复测试 测试该系统从故障中恢复过来的能力。
安全性测试 测试该系统防止非法侵入的能力。
兼容性测试 测试该系统与其它软件硬件兼容的能力。
比较测试 通过与同类产品比较，考察该系统的优点、缺点。
Alpha 测试 一种先期的用户测试，此时系统刚刚开发完成。
Beta测试 一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改
正，即将正式发行。
七、测试的分类与比较
测试方式
白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档
黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档
测试阶段
单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。
开发与测试的 V 型关系
如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系 。
测试内容
接口与路径测试。
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试…
测试阶段 主要依据 测试人员、测试方式 主要测试内容
单元测试 系统设计文档 由开发小组执行白盒测试 接口测试、路径测试
集成测试 系统设计文档 由开发小组执行白盒测试 接口测试、路径测试
需求文档 和黑盒测试 功能测试、性能测试
系统测试 需求文档 由独立测试小组执行黑盒测试 功能测试、健壮性测试、
性能测试、用户界面测试、
验收测试 需求文档 由用户执行黑盒测试 安全性测试、压力测试、
可靠性测试、安装/反安装测试
黑盒测试与白盒测试的比较
测试方式 特征 依据 测试人员 测试驱动程序
黑盒测试 只关心软件的外部表现， 软件需求 任何人（包括开发人员 一般无需编写额外
不关心内部设计与实现。 、独立测试人员和用户）的测试驱动程序
白盒测试 关注软件的内部设计与实 设计文档 由开发人员兼任 需要编写额外的
现，要跟踪源代码的运行。 测试人员的角色 测试驱动程序
问题1：有了“黑盒”测试为什么还要“白盒”测试？
黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？
要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。
问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。
不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
问题6：能否将系统测试和验收测试“合二为一”？
系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。
系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。
回归测试
回归测试是指对某些已经被测试过的内容进行重新测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，不仅要对新内容进行测试，还要对某些老内容进行回归测试。
测试人员的组织
了解开发人员的测试心理
测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。
开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.
开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。
结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。
如何组织测试人员：应当视企业的人力资源而定
条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。
条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。
条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。
条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好吧！
避免开发人员与测试人员产生矛盾
开发人员不能很好地测试自己的程序是因为做不到“无情”。但如果测试人员真的做到了“无情”却会引起开发人员的愤怒，遭人白眼。由于开发与测试存在“对立”关系，开发人员与测试人员很容易产生矛盾，这对项目而言是一种伤害。
开发人员的注意事项：
（1）不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。
（2）不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。
测试人员的注意事项：
（1）发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。
（2）在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。
尽量不要相互讽刺对方，例如：
A对B说：你唯一的特点就是无能。
B对A说：你唯一的特点就是粗鲁。
还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。
企业的测试策略
理念：
企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。
用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。
如何合理地减少测试工作量
减少冗余的测试
白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
减少无价值的测试
无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
如何“偷工减料”
有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分，其它次要部分可以忽略或将来再测试。
“偷工减料”方法的测试优先级：
哪些功能是软件的特色？
哪些功能是用户最常用的？
如果系统可以分块卖的话，哪些功能块在销售时最昂贵？
哪些功能出错将导致用户不满或索赔？
哪些程序是最复杂、最容易出错的？
哪些程序是相对独立，应当提前测试的？
哪些程序最容易扩散错误？
哪些程序是全系统的性能瓶颈所在？
哪些程序是开发者最没有信心的？
测试何时结束？
一、基于测试用例的规则
（1）先构造测试用例（并请有关人员进行评审）。
（2）在测试过程中，当测试用例的不通过率达到20％时，则拒绝继续测试，待开发人员修正软件后再进行测试。
（3）当功能性测试用例通过率达到100％，非功能性测试用例通过率达到90％时，允许正常结束测试。
该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。
二、基于“测试期缺陷密度”的规则
把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。绘制“测试时间－缺陷数”的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于10，m小于等于1。该规则比较适用于系统测试阶段。
三、基于“运行期缺陷密度”的规则
把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间－缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于100，m小于等于1。该规则比较适用于验收测试阶段，即客户试运行软件期间。
需求经常变更怎么办
1. 如果发布出去的软件有质量问题,那是软件测试人员的错.
2. 软件测试技术要求不高,至少比编程容易多了
3. 软件测试随便找一个能力差的人就能做.
4. 软件测试是测试人员的事,与开发人员无关.
5. 设计-实现-测试,软件测试是开发后期的一个阶段
二、如何理解软件测试
软件测试是一种有效的提高软件质量的手段,但即使在投入上有所保证,测试也不能百分为百发现所有质量隐患.况且软件质量并不仅仅是测试出来的.
很多人认为软件测试就是运行一下软件,看看结果对不对.但实际上,如何在有限的投入下,提高软件测试的效率和产出是一件很见功底的事.好的测试人员不仅要掌握各种测试技术,还要具备丰富的编程经验和对BUG的敏感.测试的复杂之处,除了测试技术问题之外,还有测试管理问题.
测试不是可有可无,随心所欲的.规范化的软件开发需要对软件测试早做计划,分配必要的时间,人力和财力等资源,并将其作为项目管理的一个部分加以控制和协调.
开发和测试是软件项目相辅相成的两个过程,人员间的交流,协作和配合是提高整体效率的重要因素.
软件产品开发完毕,再进行测试的观念是有悖于生命周期理论的.软件产品质量问题越晚发现,修复的代价越大.
一些常识和经验之谈
测试能提高软件的质量，但是提高质量不能依赖测试。
测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。
测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错
测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。
三、软件测试的定义
软件测试是为了发现错误而执行程序的过程
软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程.
四、软件测试的对象
软件测试不等于程序测试.软件测试贯穿于软件定义和开发的整个期间.需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象.
软件生存各个阶段间的确认和验证
软件配置：包括软件需求规格说明、软件设计规格说明、源代码 等；
测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。
测试工具：为提高软件测试效率，可使用测试工具支持测试工具。例如：测试数据自动生成程序、测试结果分析程序等。
五、测试的目的
测试是程序的执行过程,目的在于发现错误;
一个好的测试用例在于发现至今未发现的错误;
一个成功的测试是发现了至今的错误的测试.
六、测试的种类
名称 说明
黑盒测试 基于软件需求，而不是基于软件内部设计和程序实现的测试方式。
白盒测试 基于软件内部设计和程序实现的测试方式。
单元测试 主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，
因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外
的测试驱动程序。
集成测试 将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以
是程序模块、客户机－服务器程序等等。
功能测试 测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。一般由独
立测试人员执行。
系统测试 测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。一般
由独立测试人员执行，通常采用黑盒测试方式。
回归测试 指错误被修正后或软件功能、环境发生变化后进行的重新测试。回归测试
的困难在于不好确定哪些内容应当被重新测试。
验收测试 由客户或最终用户执行，测试软件系统是否符合需求规格说明书。
名称 说明
负载测试 测试软件系统的最大负载，超出此负载软件可能会失常。
压力测试 概念上与负载测试相似，叫法不同。
性能测试 测试软件在各种状况下的性能，如在正常或最大负载下的状况。
易用性测试 测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信
息，才能评价易用性。
安装与反安装测试 测试软件在“全部、部分、升级”等状况下的安装/反安装过程。
恢复测试 测试该系统从故障中恢复过来的能力。
安全性测试 测试该系统防止非法侵入的能力。
兼容性测试 测试该系统与其它软件硬件兼容的能力。
比较测试 通过与同类产品比较，考察该系统的优点、缺点。
Alpha 测试 一种先期的用户测试，此时系统刚刚开发完成。
Beta测试 一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改
正，即将正式发行。
七、测试的分类与比较
测试方式
白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档
黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档
测试阶段
单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。
开发与测试的 V 型关系
如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系 。
测试内容
接口与路径测试。
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试…
测试阶段 主要依据 测试人员、测试方式 主要测试内容
单元测试 系统设计文档 由开发小组执行白盒测试 接口测试、路径测试
集成测试 系统设计文档 由开发小组执行白盒测试 接口测试、路径测试
需求文档 和黑盒测试 功能测试、性能测试
系统测试 需求文档 由独立测试小组执行黑盒测试 功能测试、健壮性测试、
性能测试、用户界面测试、
验收测试 需求文档 由用户执行黑盒测试 安全性测试、压力测试、
可靠性测试、安装/反安装测试
黑盒测试与白盒测试的比较
测试方式 特征 依据 测试人员 测试驱动程序
黑盒测试 只关心软件的外部表现， 软件需求 任何人（包括开发人员 一般无需编写额外
不关心内部设计与实现。 、独立测试人员和用户）的测试驱动程序
白盒测试 关注软件的内部设计与实 设计文档 由开发人员兼任 需要编写额外的
现，要跟踪源代码的运行。 测试人员的角色 测试驱动程序
问题1：有了“黑盒”测试为什么还要“白盒”测试？
黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？
要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。
问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。
不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
问题6：能否将系统测试和验收测试“合二为一”？
系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。
系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。
回归测试
回归测试是指对某些已经被测试过的内容进行重新测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，不仅要对新内容进行测试，还要对某些老内容进行回归测试。
测试人员的组织
了解开发人员的测试心理
测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。
开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.
开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。
结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。
如何组织测试人员：应当视企业的人力资源而定
条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。
条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。
条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。
条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好吧！
避免开发人员与测试人员产生矛盾
开发人员不能很好地测试自己的程序是因为做不到“无情”。但如果测试人员真的做到了“无情”却会引起开发人员的愤怒，遭人白眼。由于开发与测试存在“对立”关系，开发人员与测试人员很容易产生矛盾，这对项目而言是一种伤害。
开发人员的注意事项：
（1）不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。
（2）不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。
测试人员的注意事项：
（1）发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。
（2）在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。
尽量不要相互讽刺对方，例如：
A对B说：你唯一的特点就是无能。
B对A说：你唯一的特点就是粗鲁。
还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。
企业的测试策略
理念：
企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。
用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。
如何合理地减少测试工作量
减少冗余的测试
白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
减少无价值的测试
无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
如何“偷工减料”
有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分，其它次要部分可以忽略或将来再测试。
“偷工减料”方法的测试优先级：
哪些功能是软件的特色？
哪些功能是用户最常用的？
如果系统可以分块卖的话，哪些功能块在销售时最昂贵？
哪些功能出错将导致用户不满或索赔？
哪些程序是最复杂、最容易出错的？
哪些程序是相对独立，应当提前测试的？
哪些程序最容易扩散错误？
哪些程序是全系统的性能瓶颈所在？
哪些程序是开发者最没有信心的？
测试何时结束？
一、基于测试用例的规则
（1）先构造测试用例（并请有关人员进行评审）。
（2）在测试过程中，当测试用例的不通过率达到20％时，则拒绝继续测试，待开发人员修正软件后再进行测试。
（3）当功能性测试用例通过率达到100％，非功能性测试用例通过率达到90％时，允许正常结束测试。
该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。
二、基于“测试期缺陷密度”的规则
把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。绘制“测试时间－缺陷数”的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于10，m小于等于1。该规则比较适用于系统测试阶段。
三、基于“运行期缺陷密度”的规则
把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间－缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于100，m小于等于1。该规则比较适用于验收测试阶段，即客户试运行软件期间。
需求经常变更怎么办
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
我的存档
数据统计
- 访问量: 57185
- 日志数: 58
- 建立时间: 2009-02-25
- 更新时间: 2013-03-16
