测试小故事55：软件测试悖论

常常会想到一些关于测试的奇怪问题：

1.穷尽测试是不可能的。换句话说，如论测试多么的充分，系统总存在缺陷。从软件测试的经济学来讲，要发现程序中的所有错误也是不切实际的，也是不可能的。

--> 软件测试是一个过程，是为了发现程序中的错误而执行程序的过程。软件测试的价值在于发现缺陷、评估软件质量。

系统总会有缺陷，为什么还要做软件测试？

2.实现测试自动化，降低人力成本，提高测试效率。

--> 自动化测试往往无法发现新的缺陷。

不能发现新缺陷，为什么还要做自动化测试？

3.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

-->开发即测试，测试即开发，结对编程，互相测试。

既然避免检查自己的程序，为什么还要开发自测？

软件测试的悖论？

换个角度，从软件质量看待开发、测试。。。。。。也许一切都合情合理了。

---------------------------------------------------------------------------------------------------------------------------

1. 测试是为了发现程序中的错误而执行程序的过程。2. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。3. 成功的测试是发现了至今为止尚未发现的错误的测试。

1．应当把“尽早和不断的测试”作为开发者的座右铭。
2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

原则1: 测试显示缺陷的存在

测试可以显示缺陷的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的，或者说是不存在缺陷的。

原则2: 穷尽测试是不可能的

穷尽测试是不可能的，当满足一定的测试出口准则时测试就应当终止。考虑到所有可能输入值和它们的组合，以及结合所有不同的测试前置条件，这是一个天文数字，我们没有可能进行穷尽测试。

原则3: 测试的尽早介入

根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。此外，IBM的一份研究结果表明，缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。因此，软件测试人员要尽早地且不断地进行软件测试，以提高软件质量降低软件开发成本。

原则4：缺陷集群性

Pareto原则表明“80%的错误集中在20%的程序模块中”。实际经验也证明了这一点，通常情况下，大多数的缺陷只是存在测试对象的极小部分。缺陷并不是平均而是集群分布的。因此，如果在一个地方发现了很多缺陷，那么通常在这个模块中可以发现更多的缺陷。因此，测试过程中要充分注意错误集群现象，对发现错误较多的程序段或者软件模块，应进行反复的深入的测试。

原则5: 杀虫剂悖论

论杀虫剂用得多了，害虫就有免疫力，杀虫剂就发挥不了效力。在测试中，同样的测试用例被一遍一遍反复使用时，发现缺陷的能力就会越来越差。这种现象的主要原因在于测试人员没有及时更新测试用例，同时对测试用例及测试对象过于熟悉，形成思维定势。为克服这种现象，测试用例需要经常的评审和修改，不断增加新的不同的测试用例来测试软件或系统的不同部分，保证测试用例永远是最新的，即包含着最后一次程序代码或说明文档的更新信息。

原则6: 测试活动依赖于测试背景

对于每个软件系统，比如测试策略测试技术、测试工具、测试阶段以及测试出口准则等等的选择，都是不一样的。同时，测试活动必须与应用程序的运行环境和使用中可能存在的风险相关联。因此，没有两个系统可以以完全相同的方式进行测试。比如，对关注安全的电子商务系统进行测试，与一般的商业软件测试的重点是不一样的，它更多关注的是安全测试和性能测试。

原则7: 不存在缺陷的谬论

系统的质量特征不仅仅是功能性要求，还包括了很多其它方面的要求比如稳定性、可用性、兼容性等等。假如系统无法使用，或者系统不能完成客户的需求和期望，那么，这个系统的研发是失败。同时在系统中发现和修改缺陷也是没有任何意义的。

测试小故事55：软件测试悖论相关推荐

测试小故事26：软件测试的艺术
艺术,什么是艺术?当无法用准确的语言描述所看到的.听到的.感受到的,也许我们会用"很艺术"来形容. <软件测试的艺术>, The Art of Software Tes ...
测试小故事91：讲故事
测试报告:只堆积数字,干巴巴的,难于解析出有价值的内容,也许讲个故事更能体现价值. "I don't care this defect this time". 这是开发说给测试的一 ...
测试小故事21：语言的力量
技术人员的语言是简单的,也许他们的世界只有数字和公式.了解他们做的,用他们的语言说话,用他们的语言进行日常协作,也许能更好的与他们沟通,也许才能逐步获得对方的信任,才能更好的与对方对接,. 自小被家长 ...
测试小故事52：怎么测？
自动化测试是将手工测试的过程使用工具实现的过程.如论怎么测,业务是核心.技术是手段.编码是工具. 化繁为简,当自动测试实现过于繁琐或无法实现的时候,回到测试的本原,思考测试的目的. 最近的一件测试内容 ...
测试小故事6：术业有专攻
一次同几位测试同行聊天,讲起一件有趣的事情. 测试人员提交了系统UI和可用性的BUG,一位开发人员不愿意了,大发脾气,对着开发给出了一通抱怨. 1. 这些不是系统的BUG,即使是BUG也是无关 ...
测试小故事75：角色
测试团队的角色有哪些? 这个似乎很简单:测试团队最基本的角色就是测试执行. 从测试过程看:测试需求分析.测试计划.测试设计.测试执行.测试报告.测试分析. 因此角色可以分为:需求.计划.设计.执行.报 ...
测试小故事27：职业化与专业化
职业精神,最早接触是来自于国外的职业足球运动员.对于这些职业运动员来讲,转会是很平常的事情,而对于他们需要做到的是用专业的运动技能效力于当前的俱乐部. 也许昨天还效力于一家俱乐部,第二天转会到另一家俱 ...
测试小故事88：耍流氓
耍流氓,只是测试对开发不负责任态度的一种说法. "开发进度天天改,测试时间一压再压,质量出了问题就拿测试说话." "测试报告发了,该注意的问题也提了,没有理没人问,到头来 ...
测试小故事10：时间与耐性
江湖越老,胆子越小. 不知道是不是真的随着年龄增长,越活越抽抽,胆子越来越小,只是发现随着年纪越大,人的耐心真的会慢慢增加,一笑而过的事情也越来越多. 初中时,因为觉得老师不公对待而与老师拳脚相加 ...

测试小故事55：软件测试悖论

测试小故事55：软件测试悖论相关推荐

最新文章

热门文章