(（12）-测试基础之软件测试的原则概述)

1 测试要站在用户的角度

• 这个不难理解，我们所有测试活动应该站在用户角度思考；
• 比如为什么会有测试思维和开发思维，这两个是有本质区别的；
• 简单说，什么是用户的角度？

①最起码软件测试要根据用户需求来测试，要发现软件是否满足用户的需求； ②站在用户的视角，审视软件的易用性和美观性； ③站在用户的视角，思考软件的使用的使用场景； ④站在用户的视角，软件是否具备强大的使用粘性等； ⑤站在用户的视角，软件如何体现才能为用户带来更大的利润。 当然还有很多。。。

• 可以这么说，把产品和软件“当自己儿子”对待！！！你会怎么做！！？？
• 概括说：

测试工作应该建立在满足客户需求的基础上，如果产品最终不能满足用户需求，那么开发、测试的投入都是徒劳的。

2 软件测试要尽早进行

• 场景1： 软件版本转测了，开始准备计划，设计用例等等，是不是有点迟了？

• 场景2： 在需求评审阶段，提出测试的要求，可测试性分析等，这样是不是会好点呢？

• 我们简单看下场景1和2，不难发现，肯定场景2会好点，为啥？

• 概括说：

软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早地开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制订出完善的计划和方案，提高测试的效率。

3 穷尽测试是不可能的

项目明天上线，仍有一大堆功能未测试，怎么办？

• 场景1：加班加点，全部功能测试。
• 场景2：划优先级，重点测试。

你更倾向哪个？ 其实，软件测试本身就是有风险的，不管是选择那种方式，都不可能保证软件是OK的，但因为测试的数据量大，时间短等原因，我们又不能进行穷举测试，所以我们选择场景2会好点。

• 概括说：

由于时间和资源的限制，进行完全(各种输入和输出的全部组合)的测试是不可能的测试人员可以根据测试的风险和优先级等确定测试的侧重点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。

4 遵循GoodEnough原则

说实话，我当初也不怎们理解这是啥， 基本意思就是：既不要做过多测试，也不做不充分的测试。 概括说：

测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。可通过需求分析和风险分析找到测试侧重点，制定最低测试通过标准和内容，再进行具体问题具体分析。做到适当测试。

5 测试缺陷要符合“二八”定理

• 也称为Pareto原则、缺陷集群效应；
• 一般情况，软件80%缺陷会集中在20%模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率；

6 避免缺陷免疫

• 简单用个词语来描述下“抗药性”，因为测试人员对软件越来越熟悉，可能会忽略一些细小的问题，导致发现问题的能力下降；
• 同一类或同一个测试用例被反复执行，可能导致发现问题的质量也会下降；
• 以上现象也被称为“杀虫剂”现象。改善思路是要及时更新测试用例和避免形成思维定势。

7 分阶段测试

• 这个其实如果是有完善的测试流程的话，基本都会进行分阶段测试，比如单元测试，集成测试，系统测试等等；

8 第三方体验性测试

• 体验的角色为非测试人员、非开发人员之外的人员；
• 原因：测试人员可能对自己测试过的产品已经形成思维定势，某些细节或者问题不容易发现；而软件本身就是开发人员码代码整出来的，那开发基本不会认为自己写的是有问题的。那么这个时候，如果增加第三方的体验性测试，势必可以挖掘一些问题。

9 并不是所有的缺陷都要修复

• 再不影响用户使用的前提下，如果软件缺陷修复的成本太大、修复时间紧张、不值得修复等情况，是可以考虑暂时不修复缺陷，等机会成熟了，可以考虑下；
• 还有一种情况是发现的缺陷本身不属于缺陷，这个就要根据具体情况来分析了。

10 模块缺陷越多，隐藏风险越大

• 如果我们发现某个模块发现的缺陷越多，那开发修改的地方可能就越多，则产生的未知风险就越大，那我们就要重点分析，重点投入人力进行测试。

11 测试具备破坏性

• 往往我们使用一些正规的手段或者常用的手段，无法发现更多的缺陷时候，我们需要换一种思路，比如如何破坏软件，让他的弱点呈现出来，这样才能更多发现软件隐藏的问题。

12 测试只能发现存在的缺陷，而不能证明软件没有缺陷

• 听的最多的一句话是“这问题你都发现不了，要测试是干嘛的！！？？”；
• 哈哈，也许你可以说“这么简单的、一键操作的工作都能写出bug，要开发是干嘛的？”
• 开个玩笑，做测试，我们只能说尽可能多的发现存在的、隐藏的缺陷，但是我们不能保证测试过的软件没有缺陷，没有人有这个能力和实力这样说。

13 测试因该要系统化、流程化

• 针对一个被测试对象，我们要严格进行系统化分析，制定详细的测试计划。严格执行测试流程，充分引用各种测试技术，系统化进行测试，而不是随便测一下，点一下；
• 测试也有相关的流程和制度，我们必须遵循，不能因个人意愿一意孤行。

14 软件测试需要进行迭代

• 我们不能指望一次性就发现隐藏的问题，需要进行迭代测试，循循渐进；
• 同时，因为缺陷本身也有生命周期，如果要对缺陷进行修复，可能对

15 适当做回归测试

• 每次迭代，都有可能进行回归测试，而不是只测试本版本。适当的进行回归测试可有效避免测试覆盖不全。

16 测试要遵循一定的标准

• 做测试不是随便测试，我们要遵循一定的标准；
• 比如公司方面的、部门方面的、行业当面的等标准，进行标准化测试。

17 测试之木桶原理

• 测试只是软件产品实现过程过程中的一个环节，产品质量存在各个环节，不能说产品质量由测试来决定，只能说测试对产品质量起到推进作用。如果把软件质量全部赌在测试身上，那将是灾难性的决定。

18 测试之立场

• 一句话，做测试一定要有【原则】，这个原则不仅指的是前边提及的所有原则，另一方面指的的是【立场】；
• 举例：

如果发现一个缺陷，站在产品、用户、测试的角度，确定是一个缺陷，但是开发人员认为只是自己简单的操作或者失误，不认为是缺陷，经过进犯周折后，你被开发说服了。这种情况是不允许的。 ①可以先把缺陷进行分析和记录，用充分的事实和证据说话； ②向上反馈，由部门主管、项目经理、产品经理决策，自己拿不准的不能私了； ③如果你100%确定是缺陷，就按照缺陷的处理流程来，不能因为别人的质疑而改变自己的立场。