说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！

一、 软件测试的原则

1.所有的测试都应追溯到用户需求

1.1 缺陷的源头

• 根据相关调查，软件缺陷出现最多的地方是软件需求规格说明书（即软件需求定义），而不是程序代码。

1.2 如何应用此原则

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

2.尽早启动测试工作

2.1 缺陷雪崩

2.2 测试的成本

2.3 如何应用此原则

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

3.早做测试计划

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

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

• 完全测试、完美测试、充分测试。
  

4.1 无法穷尽测试的主要原因

• 测试数据输入量太大、时间不够等。

4.2 如何应用此原则

• 如果决定不去测试所有的情况，那么我们就面临了很大的风险。
• 如果时间不够，无法进行充分的测试怎么办?
  ✰ 使用风险分析，确定测试的重点和优先级，控制测试的开销（时间、成本、资源）。
  ✰ 风险分析需要判断技能、常识、感觉和经验。

5.测试工作的 Good-enough 原则

5.1 含义

• 既不要做过多测试，也不做不充分的测试。

5.2 如何应用此原则

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

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

6.1 含义

• Pareto（帕累托）法则由意大利经济学家帕累托提出，又称为 28 效率法则。
  √ 一般情况下 80％的缺陷聚集在 20％的关键核心业务模块中。
  √ 在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的缺陷，而系统测试又能找出其余缺陷中的 80%，最后的 4%的缺陷可能只有在用户的大范围、长时间使用后才会曝露出来。
  

6.2 如何应用此原则

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

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

• 单元测试→集成测试→系统测试→验收测试
  √ 代码规模不断加大

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

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

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

• 软件测试可以报告软件缺陷存在，却不能报告软件缺陷不存在；
• 既使在测试过程未发现软件的失效，也不能证明被测软件没有错误。

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

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

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

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

12.杀虫剂怪事

• 用于描述软件测试越多，其对测试的免疫力越强的现象。
• 程序员对测试人员的“惯用伎俩”已经可以主动躲避了！
  √ 为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷。

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

• 没有足够的时间；
• 不算真正的软件缺陷；
• 修复的风险太大；
• 不值得修复。

14.使用木桶原理

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

15.前进两步，后退一步

• 测试中的一个基本问题是——缺陷修复总会以（20-50）%的机率引入新的缺陷。
• 每次修复之后，必须做确认测试和回归测试。
  √ 再测试/确认测试
  ✰ 测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，验证之前的提交的缺陷是否真正修复。
  √ 回归测试
  ✰ 测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，确保对程序修改改没有给软件其他未改变部分带来新的缺陷。软件修改或者环境变更后，必须进行回归测试。

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

• 无论项目采用何种开发模型，测试人员总是一个版本接一个版本地测试，其测试活动总是迭代向前的
  √ 测试版本 1->提交缺陷->修复缺陷->测试版本 2->提交新缺陷->修复新缺陷->测试版本 3->…

17.测试需要遵循标准

17.1 什么是标准

• 你家的某个电器或家具脱落了一个螺丝钉，你可能会很随意地到街市买一个回家安上，这说明什么——制造业的标准在起作用。家用电器是依据标准制造的，所以随之而来的各种标准配件也会很容易找到。

17.2 标准的分类

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

17.3 案例

• 测试 5 层居民楼的电梯
• 1+0.1=？

18.其他的一些测试理念

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

二、软件测试行业概述

1.乐趣

• 破坏程序纯粹的快乐
• 破坏行为具有价值
• 体现出魔术般的力量
• 学习的乐趣

2.烦恼

• 必须追求完美
• 由他人来设定目标，供给资源，提供信息
• 测试往往是线性收敛
• 投入了大量辛苦，用户发现的致命缺陷将否定全部工作

3.第三方测试

• 是指独立于软件公司自身测试的测试，所谓的第三方是指在软件公司和软件用户之间的另一方。

4.机遇

• 微软公司的测试
  
• 国内的测试
  
• 在认识上重开发、轻测试；
• 在管理上随意、简单，没有建立有效、规范的软件测试管理和评判体系；
• 缺少自动化工具的支持。

三、 软件测试工程师的要求

1.行业知识与软件测试

• 高效的测试团队应该由具备各种专门技术的成员（具备行业知识、专业技能、测试技术等）组成，同时也应该由具备各种经验的成员（测试新手和测试专家）组成。
  √ 目前被测软件正在变的多元化，各个行业的软件都有可能会碰到，如何判断需求是否已经包含所有可能的细节？
  √ 如何高效准确的进行测试，在最短的时间内确定问题的所在？

2.优秀的软件测试工程师品质

• 态度
  √ 有责任心
  √ 破坏的态度
  √ 对事不对人
• 三心二意
  √ 细心、信心、耐心
  √ 团队合作的沟通意识、时刻保持怀疑的态度（即缺陷预防意识）
• 具备一定的开发技能
  √ 了解开发原理
  √ 便于与开发沟通
  √ 习惯打破砂锅问到底（善于思考）

3.改善测试员和其他小组成员之间的沟通和相互关系的方法

• 以合作而不是争斗的方式开始项目
  √ 时时提醒项目的每位成员：共同目标是追求高质量的产品。
• 对产品中发现的问题以中性的和以事实为依据的方式来沟通
  √ 不要指责引入这个问题的小组成员或个人。比如，客观而实际地编写缺陷报告和评审发现的问题。
• 换位思考
  √ 尽量理解其他成员的感受，以及他们为什么会有这种反应。
• 有效沟通
  √ 开发与测试具有不同的思维方式，确信其他成员已经理解你的描述，反之亦然。
• 提高开发技能