关于测试流程思考

上周遇到了6天都是22点～23点下班，实在是累～
今日终于有空了，得赶紧赶上进度才行。

第一次分享思考
关于测试流程的思考：

第一次分享有提到测试流程中有几个必备的流程
1.需求评审
2.用例评审
3.UI评审
4.迭代总结
5.迭代报告
现公司测试流程：
web端：1.需求评审(会出需求文档，文档出来后开始写测试用例)2.开发确定任务点和出版本时间3.出版本提测4.回归测试5.上线（上线前会开发会提测N次，回归测试N次）6.迭代总结
android端：1.开发出版本提测（提测是会告诉我新增了那些功能，要测哪些，log怎么看）2.测试通过上线3.迭代总结

这周工作中遇到的情况：
1.web端和android端同时出版本，两边都在催，一会android一会web，根本没有时间看用例，中途还要来几个线上问题，乱套了。
2.一会android一会web，次数多了大脑根本切换不过来，懵b了。
3.开发对需求的理解不清，导致大量功能不全BUG，功能设计和需求对不上。
4.提测版本质量粗劣，动不动就404，500的。
5.设计文档的缺失。
6.android端零文档，只能凭借经验和之前自己总结的旧测试用例去测。
7.android的需求都是口头说，事情一多就忘。
目前的解决方案：
1.web端和android端同时出版本的情况必须有先后次序，一件一件事情来。
2.开发必须出设计文档（web和android都是），这样能及早发现功能设计和需求对不上问题。
3.增强自己的web技术水平（包括接口测试方面），这样更能快速定位问题和描述清BUG。
4.提升看log能力
5.回看老徐之前关于web测试的文章，把常规用例写出来

---

7月5日
今天听了老徐的分享，问下关于web端和android端同时出版本的情况
下面是听完回答后的新想法
1.代码管理有问题
2.开发一定要指明测试重点在哪里，而不是随便改个东西就全回归。

后续有新想法再修改。