一、测试过程简述
a项目依赖b项目新功能，ab项目一起提测
1、测试人员：两老一新
2、测试过程：第一轮，三人执行用例
第二轮，三人各自模块发散
第三轮，三人交叉测试
第四轮，两老投入b项目性能以及接口，一新继续做基本功能回归
二、上线问题简述以及头脑风暴
1、其中一个服务上线配置未更新：qa于前一天站会时说明--------开发未引起注意--------提测当天qa没有检查配置-------------近期解决方案：qa在confluence上形成一个checklist文档，以任务项指派给模块负责人，需要各模块负责人完成之后才能发送测试报告--------远期解决方案：目前已经有根据dev自动生成qa和prod部署文档的方案，可以形成自动化任务
2、uiux原定在提测前走查，本次版本与第三轮介入走查，开发在第三轮频繁修改代码，导致代码不可控：已经项目组约定后续版本提测前走查---------qa方面提测之后不允许有跟bug单无关的代码提交，如开发自测发现问题可以反馈给qa提单或者自己提单，commit信息里必须加上bug单号
3、线上管理员后台中重要数据被更改：回收所有qa管理员后台权限，管理员后台用户不多，上线之后由线上后台管理员回归
4、其他项目接口测试和性能测试安排太偏后：后续ab项目并行的时候，在a项目第一轮测试以及回归结束之后就可以开始b项目的接口和性能，降低由于其中一个项目来不及产生的整体延期风险
5、线上bug：
| bug类型 | 引入原因 | 深层原因 | 解决方案 |
| 测试环境能稳定复现bug1 | 1、用例有覆盖该功能，未写明前置条件，新人测试没有理解到该用例的前置条件，导致没有测试完全，没覆盖到上线场景 | 1、用例不够细致---测试用例编写时间安排不足-----用例编写的工作量评估不准 | 学习用例编写工作量评估的方法，多积累经验 |
| 测试环境没有，线上环境稳定出现bug | 线上配置未更新，参见问题1 | ||
| 上线修改之后引入问题 | 修改响应时间较长的bug引入其他bug |