项目测试的准入和准出标准

开发转测试的准入条件和测试之后的准出条件在我们多个项目迭代中,已经大概形成了默契,但是,公司内部还没有形成文字化的统一的标准,包括本人在多个项目测试之中,每个项目的不同版本测试中,定义哪些项目可以通过测试,哪些项目不能通过测试时,也都没有固定的标准。开发,测试,产品心中都是约莫着差不多没有严重Bug了,就发社区去了。今天在网上看到一些前辈的总结,觉得挺好,就拿过来用一下,因为我觉得,我么刚好也需要。


测试准入条件

  1. 开发人员编码完成,并且在开发环境上完成单元测试。

    我们目前的开发环境的单元测试是没有补齐的。

  2. 评审之后的需求文档上规定的功能均已经实现;如没有完全实现,研发需要提供准确的测试范围。

    我们这方面做的还挺好,因为有我们测试主动追踪 🙂

  3. 开发已经完成模块之间的集成测试,界面上呈现出来的功能均以实现;代码经过评审并符合软件编码规范。

    这个我们好像还不够完善。

  4. 开发提交最新版本代码 ,并且以此为基线版本。

    项目转测试时提供的版本基线,后续的Bug修复也是基于该基线。

  5. 兼容性测试要求需要明确。

    转测试时,需要兼容哪些平台,这些都要明确说明,如果没有特别说明的,那就意味着不需要特别测试,测试可以根据自己的情况进行安排随机测试。

  6. 安全性测试和性能测试范围和要求需要明确

    对安全测试和性能测试的范围和对比指标需要明确,如没有特别说明,默认不需要测试。


测试暂停、停止标准

  1. 冒烟测试时,便发现了阻塞测试的Bug,如系统死机,无法登录系统等。直接终止测试,返回开发。
  2. 冒烟测试时,发现的严重Bug过多,超过了项目之初设定的阈值,比如严重Bug不超过2个,直接终止测试,返回开发。
  3. 项目测试过程中,被测项目因为特殊原因需要调整的,可以暂停测试。
  4. 项目测试过程中,存在更优先级的任务时,可以暂停测试。
  5. 整个项目经过系统测试,满足了准出标准,可以停止测试。

测试准出标准

  1. 被测试项目的需求完全实现。

    这作为最基本的要求,必须要满足的条件。未实现的需求,需要提供详细说明,解释原因。

  2. 所有的测试用例都经过了评审。

    这个要求在我们的系统测试或者软件测试时,几乎没能做到(遗憾)。

  3. 所有的测试用例都已成功执行。

    所有测试用例都已经执行才能保证测试是全面的。

  4. 评估测试覆盖了是否达到100%。

    这个如果从黑盒测试的角度,只能通过识别需求,是否所有的需求都被测试到。
    如果从白盒测试的角度,可以通过工具来直观查看,如gcov,lcov工具。

  5. 所有已发现的缺陷都被记录,跟踪。

    这个我们都能做到。

  6. 致命、严重Bug都100%修复。

    这个按道理是没有异议的,一个有致命,严重Bug的系统是不能发布的。

  7. 遗留的一般、提示Bug,满足项目之初设定的阈值。

  8. 所有遗留的问题都清楚后果以及后续的解决方案。

    遗留的未解决的问题的影响范围都是心中有数的,并且后续的修复计划需要明确。

  9. 性能测试是否达到要求。

  10. 兼容性测试是否达到要求。

  11. 安全测试是否达到要求。

  12. 产出系统测试总结报告。

    报告要学会写,经常写。

发表评论

电子邮件地址不会被公开。 必填项已用*标注