标准软件测试流程V3.X

开发计划（排期）

出现bug

自测报告问题

前后端联调自测，参考基础测试用例自测目标:1、走完主流的测试用例，防止有阻碍测试进度的Bug。2、减少BUG数量，避免测试参与后大量Bug涌现，节省交互时间。自测人员:1、后端负责并和前端人员协同测试。2、项目Leader全局监督执行。

开发修改，自测通过后发版，标明版本号

提交Bug至

需求阶段

N

部署测试环境

综合评估：说明提交多少bug，严重的有哪些，一般有哪些，哪些已经解决哪些还未解决，未解决影响上线的bug就不能上线，必须清理完teambition重要级别的Bug成才能上线。

每轮迭代测试结果统计

不通过

参加评审

用户验收

teambition

运维(目前测试)

需求分析

测试

验收测试、线上验证

代码编写单元测试

概要设计

线上部署

结束

项目立项

详细设计

成功

正式测试（接口、功能、性能、易用性、安全）

Y

加入项目

开发测试阶段

测试总结报告

接口文档八要素1.封面：封面最好是本公司规定的封面，有logo，内容标题，版本号，公司名称，文档产生日期；2.修订历史：表格形式较好些，包括：版本、修订说明、修订日期、修订人、审核时间审核人等；3.接口信息：接口调用方式，常用的GET/POST方式，接口地址；4.功能描述：简洁清晰的描述接口功能，比如：接口获取的信息不包括哪些；5.接口参数说明：每个参数都要和实际中调用的一样，包括大小写；参数的含义言简意赅的说明，格式，是string 还是int 还是long等格式；说明部分，说明参数值是需要哪里提供，并详细说明参数怎么生成的，例如时间戳，是哪个时间段的，参数是否必填，一些参数是必须要有的，有些是可选参数等；6.返回值说明：①最好有一个模板返回值，并说明每个返回参数的意义；②提供一个真实的调用接口，真实的返回值；7.调用限制，安全方面：加密方式，或者自己公司一个特殊的加密过程，只要双方采用一致的加密算法就可以调用接口，保证了接口调用的安全性，比如常见的md5；8.文档维护：文档在维护的时候，如有修改一定要写上修改日期，修改人，对大的修改要有版本号变更；

BUG修改原则1.简单Bug尽量当日清理，不应当超过3天；2、团队协作，提高效率(BUG实时关注、他人BUG协助排查)；3.解决环境首选开发，如需测试人员的数据，需要提前告知，包括后续的数据更改、删除等操作，只使用自己的账号，避免照成干扰；4、不要擅自操作测试环境！！！

参考产品研发流程V2.0https://www.processon.com/view/link/5f9a1a5b0791291771370d29参考公司文档和历史记录https://www.processon.com/view/link/6167f7307d9c0866513ac8a0

接口文档或swagger

测试提供一级用例

失败，代码问题，打回开发组

部署文档

通过

编写测试用例

失败

是否成功部署

出现部署问题

详细设计文档

用例评审

回归测试（多次迭代）

科力软件测试流程V3.X

参加评估

线上验证

冒烟测试

概要设计文档

开发自测报告

综合评估

产品经理/项目经理/用户

开发

项目经理

需求评审

测试申请需要提交：1.自测报告2.部署文档3..操作系统，中间件，固定版本号，提交测试单，写清楚版本号，部署流程。

明确后续时间节点：1.概要设计完成节点2.详细设计完成节点3.代码开发完成节点4.测试/验收完成节点5.正式发布节点邮件通知所有项目有关人员和部门负责人，形成具有约束力的规则。若未完成，或高质量的按时完成需要有惩奖措施！

测试申请

需求文档

根据公司现有研发流程无详细设计，具体参考产品研发流程V2.0提供实现设计所需要的文档

线上验证可能会有问题，需要定位问题：1.如果是部署的问题，需要转到部署流程2.如果是开发Bug，需要teambition提交bug

前后端联调开发自测

测试计划（排期）

主要做以下简略统计：1.本轮测试提交多少Bug2.本轮测试bug的等级和个数，回归修改次数，不同级别的分别是多少，假如设定：每个开发者，严重的不超过10，一般不超过20，轻微不超过40，累计重复修改回归数不超过10，否则影响绩效考核。（具体由开发leader在测试初期给出设定值）3.绘制每轮Bug数量线形图，分析凹凸函数。