研发流程中的产品测试概论.pptxVIP

研发流程中的产品测试本次交流的目的 我们许多技术人员往往将测试简单的理解为对产品功能性能的验证。 在产品测试中他们简单的对产品需求规格说明书中所述的产品性能、功能进行分类，并按照其预想的用户操作步骤通过黑盒测试的方法来测试产品是否实现设计指标和功能。 这种方法会带来严重的缺陷：本次交流的目的1、产品需求规格说明书只会对产品外在指标和功能进行定义，而不会对产品组成的单元/单板、接口等指标功能进行描述。这样的测试可以肯定比较难以发现产品内部的设计缺陷。2、产品需求规格说明书定义的指标、功能可能列写不充分。根据不充分的需求定义导出的测试用例不能够覆盖基本（正常）事件的测试，导致测试有效性的降低。本次交流的目的3、产品需求规格说明书可能不会对备选事件和异常事件进行描述，即使是一一对应需求规格而设计的测试用例也会造成对备选事件和异常事件的测试遗漏，进一步降低测试有效性。4、单元测试、集成测试、系统测试所用测试用例完全一样，忽略了不同产品测试阶段所要关注的工作重点，使得产品设计缺陷难以在研发阶段暴露，后续影响量产产品的质量。本次交流的目的就是增强技术人员对测试工作的理解和认识，便于后续公司测试工作流程的持续改进。提纲 测试的目的和原则 测试的分类和方法 测试实施测试的目的和原则测试的目的 一点共识： 为使最终用户对产品满意，就必须保证产品功能性能达到用户需求。而验证产品功能性能否达到用户要求的唯一方法就是持续有效的测试。测试的目的 两种角度： 从用户的角度出发，就是希望通过测试能充分暴露产品中存在的缺陷，以便决定是否买单。 从开发者的角度出发，就是希望测试能表明产品不存缺陷，已经完全正确地实现了用户需求。测试的目的 三个问题： 从情感角度来看，开发者是不愿意自己设计的产品被证明存在设计缺陷。 从应用角度来看，开发者往往是认为用户一定是按照自己设计好的操作模式来对产品进行操作的。 从实施角度来看，开发者总是对能够验证产品已经实现了预期功能的测试项目更加感兴趣。测试的目的 四条结论： 测试不仅仅是为了证明产品能够实现既定功能，还要尽可能多地发现产品中的错误和缺陷。 测试只能证明错误的存在，但不能证明错误不存在。 研发产品质量保证的唯一方法就是尽量大覆盖范围下的有效测试。 测试的有效性是通过符合实际应用条件下的测试用例的设计及实施来保证。测试实施原则 由于惯性思维的存在使得难以发现设计缺陷，因此尽量避免设计人员来测试自己设计的产品，但是单元测试除外。 确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结果，那么就不容易判断测试结果是否正确。 彻底检查每个测试结果。如果不仔细检查测试结果，有些已经测试出来的错误也可能被遗漏掉。测试实施原则 对非法的和非预期的输入也要像合法的和预期的输入一样编写测试用例。 检查产品是否做了应做的事仅是成功的一半，另一半是看产品是否做了不该做的事。 对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。测试实施原则 测试后遗留的错误数目往往与已发现的错误数目成比例。因此当A模块找出错误比B模块多得多时，很可能A模块遗留的错误仍比B模块遗留的错误多。 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。 妥善保存一切测试过程文档，测试的重现性往往要靠测试文档。测试实施原则 制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。 “尽早和不断的测试”应该成为一个合格的开发者的座右铭。总结一下 对于测试重要性的理解我们都相差不多，唯一的区别在于对测试所关注问题的不同看法。 我们的核心问题是如何提高测试效率。 测试会占用开发周期，特别是测试覆盖率要求越高周期就会越长，这与开发进度要求一定是矛盾的。 开发人员、测试人员较少测试经验，不具备良好的测试技能和测试工具，使得测试进度更加不可保证。广义的测试 测试应该贯穿产品开发周期，测试不仅仅是测试所实现的产品性能与功能，还要测试开发周期中各种设计文档。 需求阶段、总体（概要）设计阶段、详细设计阶段所输出的技术文档，包括需求规格说明、总体（概要）设计、详细设计、源程序（SCH、PCB）、用户文档等，都是测试的对象。测试的分类测试的分类 按测试方法划分，有静态测试和动态测试。 动态测试：使被测试产品或模块有控制地运行，并从多种角度观察运行时的行为，以发现其中的错误。 静态测试：就是指人工评审设计文档，借以发现其中的错误。作为研发质量控制的重要手段，评审经常作为具体实施前的检查手段，其目的是保证设计的正确性、减小设计风险、尽早发现设计缺陷。测试的分类 按测试功能划分，有黑盒测试和白盒测试。 白盒测试：对模块内部是不透明的。从