记录一个项目测试过程中遇到的问题

目的：回顾本项目实施过程中问题，避免以后再次发生类似问题。

 

问题：

1：逻辑较为复杂的需求在评审时，考虑不够周全，导致的开发阶段对需求进行频繁变更（测试还不知道变更的内容）且变更的需求逻辑没有形成文本说明，导致开发的功能和预期不符。

回顾：公众号通过二维码和公众号查询时，第一版提测后的功能和预期功能不一致，在XXX产品发布一版查询逻辑流程图后，才确定最后的逻辑。

解决方案：涉及复杂逻辑时，制定逻辑流程图

2：测试环境测试正常功能，部署到生产环境会出各种意外的情况。

回顾：某次部署，由于生产环境数据量过大，导致数据库卡死。

解决方案：测试时需要考虑生产环境实际情况

3：需求信息的传递不规范，导致开发的功能和原始需求不一致。

回顾：公众号后期的需求信息的流转是：产品通知开发，开发通知测试开发的什么功能，然后测试找产品确认功能是否满足需求（信息传递是有衰减的）

解决方案：能评审评审，不能评审起码群里发下通知并同时@测试&开发

4：需求评审不够充分，导致开发功能不符合业务。该情况出现多次

回顾：某个需求提测后，测试整理开发逻辑发布时，发现不符合实际业务。

解决方案：同行评审

5：开发的功能急于提测，导致提测各种卡流程问题（此类问题没有记录在禅道，导致禅道看着BUG比较少）

解决方案：测试如果有资源，可以找测试协助自测。

6：禅道使用不规范，导致BUG修复及跟踪不方便。

回顾：该项目BUG的通知及修复确认多数是通过钉钉通知的。出现BUG已修复禅道还是未确认状态或者有BUG不知道或下班才发现BUG指派错了。

解决方案：先规范BUG的流程为：测试提交BUG->开发确认BUG->BUG修复后且部署到测试环境—>指派给测试->测试验证BUG关闭或重新激活

7：BUG记录不规范，由于项目上线时间过急，很多BUG没有记录到禅道。

解决方案：所有BUG需记录的禅道，时间过急后期补录。

8：上线后主流程功能回归占用时间过长。

解决方案：后期已经实行了主要流程的接口自动化测试或UI自动化（需前端配合）

9：存在BUG漏测情况，在部署阶段才发现BUG。

解决方案：待定（一起加班）