软件测试的原则

软件测试的原则

前言

这是学习总结、复习使用的

1.所有软件测试都要追溯到用户源头

1.1缺陷的源头

软件缺陷最多的地方就是软件需求说明书（即软件需求定义），而不是程序代码。

规格说明书 > 设计 > 代码 > 其它

1.2如何应用此原则

• 测试第一个任务是需求分析
• 测试需求分析要做好
• 时刻要提醒自己考虑用户需求
• 最早缺陷的罪魁祸首不是程序员
• 做好需求评审
  • 审查所做的内容是否符合用户的需求

2.尽早启动测试工作

1.缺陷雪崩

需求 错误的需求 （开发做的）

设计 错误的设计 、需求

开发 错误的实现、设计、需求

测试 常见的缺陷、难以修复的缺 陷、被隐藏的缺陷

交付 测试发现的/未发现 开发修复/未修复 少量发现/大量遗留

2.测试成本

阶段	修改一个错误的相对成本
需求分析	1
设计	3-6
编码	10
开发测试	15-40
系统测试	30-70
实际操作	40-1000

3.如何应用此原则

测试应该是与软件开发或者维护工作并行的一个过程，测试应该持续进行

3.尽早做测试计划

• 软件测试不仅仅是测试执行
• 应该在测试佛南工作真正开始前的较长时间内就进行测试计划

4.穷尽测试不可能 & 软件测试有风险

• 完全测试、完美测试、从分测试

• 无法穷尽测试：测试数据量太大，时间不够

• 原则使用

  • 不去测试所有的情况，会面临大的风险，但是不用应该怎么使用呢？

    1.使用风险分析，确定测试的重点和优先级，控制测试的开销（时间、成本、资源）

    2.风险分析需要判断技能、尝试、感觉和经验

5.测试中的 Good-enough原则

1.含义

​ 既不要做过多测试，也不做不充分的测试，够就行了

2.运用

通过需求分析和风险分析（时间、费用、资源）找到测试重点，指定最低测试通过标准和测试内容，然后具体问题具体分析

6.Pareto法则应用于软件测试

1.含义

• 一般情况下 80% 的缺陷集中在20%的关键核心业务模块中

• 在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能发现其余缺陷的80%，最后4% 的缺陷只能在用户大范围、常见见使用后才会暴露出来

  需求、设计、开发-----------80%

  测试 ----------------------------80%

  交付------------------------------4%

  原则使用

  • 做好测试需求分析和测试计划，分清测试重点
  • 尽早测试
  • 持续测试

7.尽可能使用分阶段测试

• 单元测试 - 集成测试 - 系统测试 - 验收测试 （代码量不断加大）

8.为达到最佳效果，应由独立的第三方来构造测试

最佳效果 : 指最有可能发现错误的测试

• 程序员从来不会承认自己写的程序有错误
• 程序员自己测试自己的代码是一件很糟糕的事情，但是让他们测试别人的编码却成了最好的测试人员
• 程序员的测试思路有明显的局限性
• 多数的程序员没有经过严格正规的职业训练
• 程序员无良好的BUG跟踪和回归测试习惯

9.测试旨在发现存在的缺陷

• 软件测试可以报告软件测试缺陷存在，却不呢个报告软件缺陷不存在
• 即使在测试过程中未发现软件失效，也不呢个证明被v额二u案件没有错误

10.为保证测试的有效性和高效性，测试必须是破坏性、系统化的

• 充分、有效、系统的测试可以减少软件中未被发现的可能性
• 测试既要验证软件的正确性，更要通过破坏软件，发现缺陷的不正确性

11.找到的软件缺陷越多，说明软件隐含的缺陷越多

缺陷具有群集效应，应该在发现缺陷的地方继续找

12.杀虫剂怪事

• 用于描述软件测试越多，其对测试的免疫力越强的现象

  程序员对于测试人员的”惯用伎俩“已经可以主动躲避了

• 为了克服杀虫剂怪事。测试人员必须不断编写不同的、新的测试程序、对程序的不同部分进行测试，以找出更多软件缺陷

13.并非所有的缺陷都要修复

• 没有足够的事件
• 不算真正的软件缺陷
• 修复的风险太大

14.木桶原理使用

• 木桶原理在软件产品生产方面即使全面质量管理（QTM）的概念
• 团队合作

15.前进两步，后退一步

• 测试中的一个基本问题是——缺陷修复总会以（20-50）%的几率引入新的缺陷

• 每次测试以后 ，必须确认测试和回归测试。

  • 再测试 / 确认测试

    测试人员提交缺陷，开发人员修复缺陷以后，测试开发人员需要重新测试，验证之前的提交的缺陷是否真正修复

  • 回归测试

    测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，确保对程序修改后没有给软件其他未改变部分带来新的缺陷。软件修改或环境变更后，必须进行回归测试

16.软件测试是一个迭代过程

无论项目采用何种开发模型，测试人员总是一个版本接着有个版本测试，测试活动总是迭代向前的

测试版本1 --提交缺陷 --修复缺陷 – 》测试版本2 —提交新缺陷—修复新缺陷—》测试版本3

17.测试需要遵循标准

1.标准分类

• 国际分类：ISO CMM IEEE
• 国家标准：GB BG/T
• 行业标准
• 公司标准
• 用户规定
  • CMM Capability Marurity Model 软件能力成熟度模型
  • IEEE 国际电气电子工程师协会

18.其他测试理念

• 测试决定测试
  • 具体问题具体分析
  • 无责任心不成测试
  • 测试不能靠猜测

标准

• 用户规定
  • CMM Capability Marurity Model 软件能力成熟度模型
  • IEEE 国际电气电子工程师协会

18其他测试理念

• 测试决定测试
  • 具体问题具体分析
  • 无责任心不成测试
  • 测试不能靠猜测