软件测试---软件测试原则

完全测试程序是不可能的

• 输入量太大
• 输出结果太多
• 软件实现用途太多

软件测试是有风险的行为

• 不测所有情况就选择了风险
• 要将无边际的可能减少到可控制的范围
• 明智选择，去粗求精
• 对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

good-enough原则

不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的， 什么样的测试是过分的。目前唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

软件测试无法显示潜伏的软件bug

通过软件测试只能报告软件已被发现的缺陷和故障，无法报告隐藏的软件故障。

并非所有bug都能修复

不能修复的原因：

• 没有足够的时间，项目进度决定
• 不算真正bug，是一项功能
• Fix风险太大，可能导致其它bug

没有任何一个产品没有Bug

《编程珠玑》作者让100多个专业程序员使用两个小时的充足时间编写一个简单的二分查找程序，结果发现90%的人编写出的的代码都有Bug 。
Knuth在《Sorting and Searching》一书中提及：第一个二分查找程序在1946年已经公布，但直到1962年才出现第一个没有Bug的二分查找程序。

永远不可能找出并修复所有的Bug。

在修复了旧的Bug 的同时，往往又会生新的Bug。
根据微软的经验，每修复三到四个Bug一般就会产生一个新的Bug。
不值得修复，不常用的功能，不常出现的bug，可以躲过的

软件开发过程中应在早期就开展各种质量保证活动。

应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

在改错之后一定要马上重新测试，以免引入新的错误

程序中的大部分错误往往是在一小部分模块中发现的，遵循帕雷托定律（八二原则）

一段程序中存在错误的概率与这段程序中已经发现的错误数成正比

编码规范、需求理解、技术能力、内部耦合性都会导致这种“虫子窝“现象

避免测试自己的程序

什么时候停止测试

• 发现所有的漏洞时才停止测试是不可能的
  关键在于是否经济

  • 市场压力
  • 质量目标
  • 客户要求
  • 费用约束

• 基于静态分析的决策

  • 错误发现率
    错误被发现的频率可以显示出系统的测试阶段是否接近
    完成
  • 错误植入

• 

• 

总的来说，错误的成本必须明显大于测试的成本，我们就可以继续测试下去

测试的误区

• 测试工作是测试人员的事情，和开发人员无关。

• 软件质量是由测试人员决定的，如果客户在使用中发现缺陷，那是测试人员的责任。

• 自动化测试将会取代手动测试

• 因为软件测试不能给企业带来收益，所以软件测试不重要，重要的是开发人员。

• 测试没有技术含量，是人就能做。
  卧槽，这个 bug简直太明显了好么？连这个都测不粗来，请问你们的测试，都是姚老师教的吗？