前言
文档的目的是：制定基本测试流程方案，基本流程方案本身足够保证产品质量，并且能够以此文档，开发和测试能够根据文档进行实际操作。然后随着产品质量要求提高和测试能力提升再逐步加流程。
主体分为两部分：接口测试流程与接口测试归档；集成测试流程与集成测试归档。
一、接口测试阶段
根据测试金字塔我们可以知道：
接口测试优点：测试人员的介入往前移，获得更大的收益；此阶段暴露问题后修复成本降低，开发效率会提升；测试人员的工作量会大大减少，因为在接口层面去验证了服务是正常的，集成测试去测试时，基本就大量关注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 测试准出规则
-
用例执行度100%，并全部通过；
-
bug全部解决，并合理关闭；包括有争议的bug、模糊不清的需求产生的bug。
-
给出测试报告；
-
所有文档更新为最新状态；（需求报告、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 测试准出规则
四、 功能测试归档
和接口一致。