软件测试流程规范

测试启动阶段(需求分析)

    参与软件需求调研,以测试的角度分析需求的可测性,可构思将来对测试进行的方法、原则等。更重要的是对不可测或难以测试性问题要及时与客户或者项目经理协调解决。

全面了解需求,从客户角度考虑软件测试需要达到的验证的状态,即哪些功能需要重点测试,哪些则无需测试,以便将来制定测试计划。

测试人员参与研发人员项目需求会议,明确需求及任务完成时间,研发人员需向测试人员提供产品需求文档、详细设计说明书、数据库设计说明书等,明确测试任务,确定测试周期

制定测试计划

    根据产品需求分析,制定测试计划目标、测试内容、测试工具,给出测试参考文档、测试风险分析,对测试人员进行分工。测试人员根据项目大小及项目紧急度商讨是否需要写测试计划。

提取测试要点

    根据产品需求文档以及详细设计文档提炼出测试要点,形成一个测试要点的文档(提取测试需求)。

设计测试用例

    在拿到产品功能列表和测试版本之后,参考测试要点文档,测试人员就开始着手设计测试用例了。测试人员根据产品功能列表尽可能多的设计测试用例,尽可能多的覆盖所有的测试需求。由评审组对测试用例进行评审——修改——再次评审——初步定稿。测试用例最好能录入到禅道系统,以便及时跟踪执行测试用例。

搭建测试环境

    研发人员需告知搭建好的测试环境的服务器,如需测试人员搭建环境,研发人员需提供测试环境搭建文档或手册。准备测试数据,尽量按照真实有效的数据来测试系统,这样更加符合业务场景。

执行冒烟测试

    列出冒烟测试的主要功能、测试点。运行主要流程测试用例与测试数据,检查主要功能是否已经基本正确实现,初步运行主要功能的性能测试,是否存在明显的性能缺陷。对测试发现的问题定时进行归纳与总结,预测以后测试可能会存在的风险。需要每天进行一次对当天的测试情况的回顾。

执行测试用例

    当测试用例设计完成之后,测试人员就开始全力实施每一条测试用例,当预期结果和实际结果不符时,这时就产生了Bug,测试人员要争取每个Bug都能重现,便于开发修改;测试人员将Bug记录到禅道反馈给相关开发人员,开发人员进行修复,测试人员对已修复的Bug进行再次验证,直到Bug解决为止,把状态置为关闭,并将测试结果记录下来。在测试的过程中,如果出现了Bug但研发人员不认为这是Bug,这时应该与需求负责人或者产品经理一起讨论判定是否属于Bug。对于测试过程中发现的不在测试用例范围的问题应补充到测试用例中,不断的完善测试用例,提高测试覆盖率。

Bug跟踪处理

1、测试人员提交Bug=>开发人员解决Bug=>测试人员验证关闭;

2、测试人员提交Bug=>开发人员解决Bug=>测试人员验证未通过=>激活Bug=>

重新解决=>测试人员验证关闭。

测试报告输出

    在约定的测试周期内,在所有的用例都执行完,所有的Bug都修复完,测试人员需要针对本次测试项目编写测试总结报告,将测试结果反馈,以及容易出现Bug的模块给予建议,相关负责人在下次开发中予以借鉴,避免类似错误的出现,测试报告输出后,可通过邮件形式让相关研发人员知晓。

 

2.测试结束条件

  1. 测试遇到的所有问题已经记录下来;
  2. 测试覆盖率>95%,所有测试用例都已运行95%的测试用例已经成功通过;
  3. 测试结果已经记录,测试分析报告已经提交项目经理检查;
  4. 无1,2级BUG,BUG解决率大于95%
  5. 基本功能都已实现,一些建议性的Bug可以在下一个版本中修复
  6. 如遇项目紧张,急于上线,测试人员测试基本功能没问题,对于用户后续发现的Bug可以进行跟踪,可与用户的项目对接人保持不定期的联系,询问客户使用软件的情况;这种情况也与公司售后直接联系。

备注:测试流程将在以后的测试项目中慢慢的修正和完善,一旦进入测试过程中,不接受任何大模块更改,如需更改需求请走需求流程。

猜你喜欢

转载自blog.csdn.net/w13632910369/article/details/84956097