研发提测的项目流程规范

前言

文档的目的是:制定基本测试流程方案,基本流程方案本身足够保证产品质量,并且能够以此文档,开发和测试能够根据文档进行实际操作。然后随着产品质量要求提高和测试能力提升再逐步加流程。

主体分为两部分:接口测试流程与接口测试归档;集成测试流程与集成测试归档。

一、接口测试阶段

根据测试金字塔我们可以知道:
接口测试优点:测试人员的介入往前移,获得更大的收益;此阶段暴露问题后修复成本降低,开发效率会提升;测试人员的工作量会大大减少,因为在接口层面去验证了服务是正常的,集成测试去测试时,基本就大量关注ui的页面渲染问题。

1.1 测试准入规则

1.1.1 详细的接口文档

除了需求阶段的需求文档与UC和研发阶段的系分外。还需要详细的接口文档,以企业微信接口文档为例:
post接口创建部门 - 接口文档 - 企业微信开发者中心
需要:接口名称、请求方式、请求地址、请求包体、参数说明(重点)、权限说明、返回结果、返回结果参数说明(重点)
get接口删除部门 - 接口文档 - 企业微信开发者中心
需要:接口名称、请求方式、请求地址、参数说明(重点)、权限说明、返回结果、返回结果参数说明(重点)

  • 开发以swagger,作为接口文档,作为准入。

1.1.2 可部署的测试环境

可测试的环境。
需要可部署的文档,并且测试可以根据文档,完成可测环境的部署。可测试的环境可以不需要像正式环境完全一致,但功能需要相同。测试同学需要清晰的了解自己负责测试项目的环境部署。
例如:OB-制品部署文档https://yuque.antfin-inc.com/ob-dev/wtaxcg/yofe6e
杜绝:没有部署方案,直接在某环境测试。

1.1.3 具体的接口测试清单

开发同学需给出明确的测试接口。
清单内容需要清晰的说明:待测试的接口有哪些;如果测试环境不能真实执行,则给出帮助信息。

1.1.4 自测完成

开发同学提交的接口是经过自己单侧过的;并且符合基本的代码规范;通过评审;通过安全扫描;
给出阿里测代码通过的链接证明。

1.1.5 冒烟通过

接口的正向功能没有任何问题。ps:一般自测过的,冒烟基本没有问题。冒烟结果会体现测试报告中。

1.1.6 缺陷管理软件,给出迭代

aone中,待测试的接口内容,给出迭代版本

1.1.7 系统设计已基本稳定,频繁变动的接口不多余10%

稳定的系统设计减少接口测试人员无效的工作,一个频繁变更的系统设计往往会使测试人员对系统产生误解和迷惑,进而导致错误的用例和测试代码。
根据接口变动数量和次数/总接口数=百分比;体现在测试报告中。
接口开发完成后,进行前后端联通时,如果也有接口变动,也会计入次数。

1.2 测试过程产出

1.2.1 画出接口业务关系;

根据需求文档、uc、系分、接口文档、接口清单,画出业务关系图。
demo地址:业务关系图demo
主要目的:
作为测试人员,我想要调用这个接口,需要干些什么操作?这个接口的主要业务是什么?做到心中有数。

1.2.2 制定测试方案

根据根据需求文档、uc、系分、接口文档、接口清单,制定测试方案;
demo地址:测试方案模板
主要目的:
根据项目真实需求,作为测试人员该怎么去分析、设计、实现,达到项目中接口的要求。

1.2.3 评估测试时间

根据自己画的图、和制定的测试方案,评估自己所需的测试时间;

1.2.4 编写接口用例

demo地址:接口用例demo
不必要在编写用例时就将url、请求体、响应体填写进去。
重点关注:所有的业务场景覆盖
如:电商系统关键的业务就是:下单、支付、订单、售后、红包、优惠卷、
下单:非登录下单、登录下单、下单单商品、下单多商品、放入购物车、web端下单、app下单、小程序下单、形成待购买商品等,还有关键业务的组合。

1.2.5 用例评审

开发、测试、产品、项目经理;围绕你写的接口测试用例,去评估,查漏补缺。形成项目大一统。
主要检查单接口的测试、以及这个接口涉及的业务,有没有覆盖完全。重点关注:所有的业务场景覆盖
如果该接口有性能、安全等其他要求,也需要专门设计。

1.2.6 执行用例

在执行阶段,将所有场景的用例,请求url、方法、请求体构造、相应体、测试结果等,再次输入用例中;为后续自动化、你的执行证明、归档等做依据。

1.2.7 测试报告

完成测试后,需要给出测试报告
将整体的接口测试过程,每个节点记录,给出对应的评价。
demo地址:测试报告demo

1.3 测试准出规则

  1. 用例执行度100%,并全部通过;

  2. bug全部解决,并合理关闭;包括有争议的bug、模糊不清的需求产生的bug。

  3. 给出测试报告;

  4. 所有文档更新为最新状态;(需求报告、uc、系分、接口文档、测试方案、测试用例)暂时没有测试计划

二、 接口测试归档

  • 归档这里太low了,直接舍弃了!

怎么去做归档?

使用一个局域网共享文件夹,放入项目不同阶段产生的文档或者相关文档的连接地址(镜像数量多并且比较大,那么就可以使用地址的方式)测试只用管文档,不用管镜像,只要地址即可。

主测分,负责所有文件的归档;
主系分,负责检查。

测试文档基本都是在语雀上编写,不同项目都有自己的语雀主目录,那么可以创建一个测试文档目录写测试文档,语雀上写完后直接导出一份;语雀自己也保存一份,使用也方便。
语雀上创建文件夹,进行归档也OK。

三、功能测试阶段

接口阶段完成后,可能会有一段时间开发和前端进行联调,可以写下自动化。

3.1 测试准入规则

3.1.1 接口测试通过

接口测试完成,作为集成的准入。

3.1.2 可部署的测试环境

可测试的环境。和接口测试阶段一样。

3.1.3 功能清单

开发同学需给出明确的测试功能。和接口阶段类似,这个是功能清单。

3.1.4 自测完成

开发同学提交的代码是经过自己测试过的;功能清单中的全部功能的正向操作自测。
并且符合基本的代码规范;通过评审;通过安全扫描;
给出阿里测代码通过的链接证明。

3.1.5 冒烟通过

ui集成的正向功能没有任何问题。ps:一般自测过的,冒烟基本没有问题。冒烟结果会体现测试报告中。

3.1.6 缺陷管理软件,给出迭代

接口测试阶段和集成阶段,需要分开标记。

3.2 测试过程产出

3.2.1 制定测试方案

根据根据需求文档、uc、系分、功能清单,制定测试方案
测试方案demo:测试方案模板
根据项目真实需求,作为测试人员该怎么去分析、设计、实现,达到功能要求。

3.2.2 评估测试时间

根据自己制定的测试方案,评估测试时间。建议:根据项目大小,多预留1到3天时间;万一某个节点突然崩了呢?

3.2.3 编写用例

经过接口测试阶段后,集成测试的测试点:
着重点 在业务场景、ui页面渲染、最终数据存储。

3.2.4 用例评审

大家的看重点,在于所有的业务流程,有没有覆盖到;

3.2.5 执行测试

业务流程为重点,ui渲染次重,每个阶段的数据和数据落库是否一致,重点;
需要验证的方式是什么;最终确认是否保存数据库,和保存数据的正确性。

3.2.6 测试报告

完成测试后,需要给出测试报告
将整体的测试过程,每个节点进行记录,从冒烟提测开始。
demo地址:测试报告demo

3.3 测试准出规则

四、 功能测试归档

和接口一致。

1 Like

23期小光头来占楼啦!

文档看不了哦

链接已更新

关闭