本次交流的目的

　　● 我们许多技术人员往往将测试简单的理解为对产品功能性能的验证。

　　● 在产品测试中他们简单的对产品需求规格说明书中所述的产品性能、功能进行分类，并按照其预想的用户操作步骤通过黑盒测试的方法来测试产品是否实现设计指标和功能。

　　● 这种方法会带来严重的缺陷：

　　1、产品需求规格说明书只会对产品外在指标和功能进行定义，而不会对产品组成的单元/单板、接口等指标功能进行描述。这样的测试可以肯定比较难以发现产品内部的设计缺陷。

　　2、产品需求规格说明书定义的指标、功能可能列写不充分。根据不充分的需求定义导出的测试用例不能够覆盖基本（正常）事件的测试，导致测试有效性的降低。

　　3、产品需求规格说明书可能不会对备选事件和异常事件进行描述，即使是一一对应需求规格而设计的测试用例也会造成对备选事件和异常事件的测试遗漏，进一步降低测试有效性。

　　4、单元测试、集成测试、系统测试所用测试用例完全一样，忽略了不同产品测试阶段所要关注的工作重点，使得产品设计缺陷难以在研发阶段暴露，后续影响量产产品的质量。

　　本次交流的目的就是增强技术人员对测试工作的理解和认识，便于后续公司测试工作流程的持续改进。

　　测试的目的和原则

　　● 一点共识：

　　→ 为使最终用户对产品满意，就必须保证产品功能性能达到用户需求。而验证产品功能性能否达到用户要求的唯一方法就是持续有效的测试。

　　● 两种角度：

　　→ 从用户的角度出发，就是希望通过测试能充分暴露产品中存在的缺陷，以便决定是否买单。

　　→ 从开发者的角度出发，就是希望测试能表明产品不存缺陷，已经完全正确地实现了用户需求。

　　● 三个问题：

　　→ 从情感角度来看，开发者是不愿意自己设计的产品被证明存在设计缺陷。

　　→ 从应用角度来看，开发者往往是认为用户一定是按照自己设计好的操作模式来对产品进行操作的。

　　→ 从实施角度来看，开发者总是对能够验证产品已经实现了预期功能的测试项目更加感兴趣。

　　● 四条结论：

　　→ 测试不仅仅是为了证明产品能够实现既定功能，还要尽可能多地发现产品中的错误和缺陷。

　　→ 测试只能证明错误的存在，但不能证明错误不存在。

　　→ 研发产品质量保证的唯一方法就是尽量大覆盖范围下的有效测试。

　　→ 测试的有效性是通过符合实际应用条件下的测试用例的设计及实施来保证。

　　测试实施原则

　　● 由于惯性思维的存在使得难以发现设计缺陷，因此尽量避免设计人员来测试自己设计的产品，但是单元测试除外。

　　● 确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结果，那么就不容易判断测试结果是否正确。

　　● 彻底检查每个测试结果。如果不仔细检查测试结果，有些已经测试出来的错误也可能被遗漏掉。

　　● 对非法的和非预期的输入也要像合法的和预期的输入一样编写测试用例。

　　● 检查产品是否做了应做的事仅是成功的一半，另一半是看产品是否做了不该做的事。

　　● 对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

　　● 测试后遗留的错误数目往往与已发现的错误数目成比例。因此当A模块找出错误比B模块多得多时，很可能A模块遗留的错误仍比B模块遗留的错误多。

　　● 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。

　　● 妥善保存一切测试过程文档，测试的重现性往往要靠测试文档。

　　● 制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

　　● “尽早和不断的测试”应该成为一个合格的开发者的座右铭。