开发计划（排期）
出现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数量线形图，分析凹凸函数。
