通用版的测试流程

前提:针对一个从零开始的全新的项目

一、目标

结合公司现有的项目情况制定合理规范的测试流程,提高测试效率和产品质量,尽可能减少客户对产品的问题反馈,

核心还是要加强项目组成员之间的工作交流和沟通,保证整个项目的高效率的按质按量的交付。

二、测试流程说明图

通用版的测试流程_第1张图片

 

三、测试流程

1.需求分析

  参与人员:客户、项目经理

       由项目经理(项目负责人)与客户相关人员开会确定需求,明确主要功能点,具体到某一个的小功能,一旦和客户那边确定了需求,就可以开始启动整个项目的工作

2.需求评审

  参与人员:开发、测试、设计、产品

  所有的从零开始的项目都需要需求评审,在需求评审过程中,开发从技术角度来分析实现方案,实现的难易程度。设计(美工)人员从视觉交互的角度给出适当的建议,有没有不合理的交互流程,哪些地方需要再优化,测试从用户角度来给出产品的用途逻辑上是否存在不合理的建议,在需求评审结束之后,明确相关人员的具体职责工作,评估设计,开发周期,测试周期,制定项目计划

       项目计划由项目经理制定,内容分为:成员职责(把开发任务分配到每一个成员身上)、项目进度(成员在限定日期前需完成哪些功能,版本打包上线的最后时间期限)

3.测试计划

  参与人员:测试组长、测试成员

  测试组长把任务下发到具体的测试人员,对应具体的测试模块或任务

  测试组长制定测试计划,计划的内容有以下:

    ①测试内容:所测试的功能清单

    ②测试规则:测试方法、测试要点、测试工具

    ③测试环境:硬件环境、软件环境、其他特定环境

    ④项目任务:测试规划、测试设计、执行测试的准备、测试执行、测试总结

        最终以文档形式输出:测试计划

4.编写测试用例

  参与人员:测试人员

  测试人员依据制定的测试计划和功能点,编写高质量的测试用例 

  最终以文档形式输出:测试用例(excel表格)

5.用例评审

  参与人员:开发、测试、产品

  目的:确认细节规则和测试结果的准确性,避免功能点的遗漏

  根据项目大小或者项目的上线时间来决定是否需要开评审会,此项视情况而定,若时间紧急,可直接测试组长和测试成员进行评审,由测试组长把关测试用例的质量。

6.执行测试用例,提交缺陷

  参与人员:测试人员

  在执行测试用例之前,先做个冒烟测试,验证项目基本的主要功能点是否通过,这项操作的目的是来评判这个版本的功能是否可测,若初步的冒烟测试都没有通过,则打回开发组,要求开发组返工。第一轮简单的系统测试后,开始执行测试用例,发现缺陷,在bug管理工具JIRA上提交缺陷,分配到对应的开发人员,由他们进行修改。

  测试内容:①功能测试    核心业务流程,功能完整性,需求的覆盖性,体验性

              ②兼容性测试  多个测试平台覆盖

              ③接口测试    权限的处理,状态的约束

              ④性能测试    压力测试,并发测试

              ⑤安全测试    传输数据加密,用户访问认证,日志记录等

  文档输出:缺陷记录,测试的数据,已执行的测试用例

7.Bug跟踪直至缺陷关闭

    Bug内容:编号,功能模块,缺陷描述,截图,优先级,严重程度,版本号,处理 人,状态,开始时间,结束时间,环境(测试)

    缺陷状态:新建,已处理,已拒绝,已解决,已关闭,延迟处理,重复缺陷

通用版的测试流程_第2张图片

 

 

  缺陷处理流程:

  ①开发认为是缺陷的处理

  测试人员发现并提交缺陷,由开发人员进行处理,开发人员修改了这个缺陷就会将 这个缺陷的状态置为已解决状态让测试人员进行验证。测试人员对这个已修复的缺 陷进行回归测试,如果回归测试通过,则将缺陷状态置为已关闭,如果回归测试没 有通过,则将缺陷状态置为新建状态等待开发再次修复,直到修复成功。

  ②开发认为不是缺陷的处理

测试人员发现并提交缺陷,由开发人员进行处理。但是开发人员认为不是缺陷,则 将该缺陷的状态置为已拒绝状态并提交回测试人员,可简单描述拒绝原因。测试人 员如果认为确实误报了缺陷,则直接关闭,如果经过测试人员和开发人员沟通交流 过后认为是bug,则测试人员重新打开(新建)让开发人员继续修改,开发人员修 复这个缺陷置为已解决,提交给到测试人员进行回归测试,直到回归测试通过为止。

  ③开发认为重复缺陷的处理

测试人员发现并提交缺陷,由开发人员进行处理。但是开发人员认为是重复缺陷, 则将该缺陷状态置为重复缺陷,测试人员一定要确认该缺陷是否确实重复,如果确 实是同一个缺陷,则将重复的缺陷直接关闭。如果不是同一个缺陷,则重新打开该 缺陷,继续跟踪。

  ④延迟缺陷的处理

测试人员发现并提交缺陷,由开发人员进行处理。但是因为项目和时间等因素,某 些缺陷无法在项目周期内完成,则需要进行延迟处理(备注:延迟处理的缺陷本身 被确定为有效缺陷),对于延迟的缺陷需要经过开发、测试、项目经理、客户代表 共同认可方可延迟。对于延迟的缺陷,置状态为延迟处理。到了下一个版本,测试 人员就应该把所有延迟处理状态的缺陷重新置为新建状态,让开发人员继续修复。

  经过两到三轮或四轮的测试后,直到没发现新的问题。或暂时无法解决,或不紧急的问题,跟项目负责人确认后,可以通过。

8.测试结束,生成测试报告

  当测试通过后,需生成一份测试报告,测试报告内容(重点):

  ①测试项目的版本,测试项目内容的概述

  ②测试用例的执行情况

  ③测试结果的统计:总bug数,bug级别分类统计,已解决数,遗留数

  ④测试评估:基于软件缺陷的质量评估,写明在当前版本,已实现的功能和未实现 的功能

  测试报告文档输出:说明该项目软件的开发是否达到预定目标,是否可以交付使用

            记录测试结果与发现及本项目测试工作所得到的各项输出的承载体

            根据输入与计划、要求的对比来总结此次项目所获得的经验

9.备注

  前期的准备工作和最后的交付件:

通用版的测试流程_第3张图片

 

你可能感兴趣的:(通用版的测试流程)