由遗漏BUG引发的思考

---

由遗漏BUG引发的思考

本文出自51Testing软件测试博客  作者：爱菱

来淘宝已经五年多了，做多大大小小的项目日常已经自己也数不过来了。虽然在项目和日常中，我总是竭尽全力去保证质量，但是无可避免，也会遗漏bug。想对以前遗漏的bug和自己知道的其他人遗漏的bug做一个总结，反思总结才能让自己进步，不要犯相同的错误。

（1）   不一致问题。

（2）   紧急情况。

（3）   性能问题。

（4）   兼容性问题。

（5）   并发问题。

（6）   交互问题。

（7）   沟通问题。

（8）   特殊场景。

（9）   未通知回归。

（10）  需求遗漏。

（11）  浏览器测试不全面。

（12）  关联的问题。

（13）  用户体验问题。

（14）  应用发布顺序问题。

（15）  需求“搭车”发布导致问题。

（16）  优化代码导致错误。

一、需求阶段

1.沟通问题。双方理解不一致，最后导致实现的需求不一致。这个问题需要有一个牵头人，组织相关人员碰头，进行评审，把需求明确，并把会议纪要以邮件的形式发给相关人员。实例：一个需求需要两个团队合作完成，需求评审时，没有沟通清楚，大家都按照自己理解的需求来开发，最后的判断原则却两边相反的，多么可怕。

2.需求遗漏。测试要往前走，参加需求评审和技术方案、详细设计的评审，而不能只停留在UC评审后。需求能找出问题，是代价最低的。实例：底层应用改动，需要评估上层修改和回归，大家重点都放在大应用上，结果小应用的主流程都被影响，无法通过。

二、设计阶段

1.兼容性问题。新系统上线，没有兼容老数据，新老方案不兼容，会引起严重问题，大批量用户数据不能使用。实例：增加一个关键字段，而该字段是不能为空，那么老数据就必须要进行初始化该字段为一个合理的值。还有数据结构变更，老数据迁移到数据结构，结果导致数据错乱。

2.并发问题。成尤其是对于多线程的功能，需要特别注意。实例：两个线程都在处理数据，并发锁时间设置过短，导致锁被提前释放（任务未执行完），任务状态未被置为成功，导致任务被重复执行。又或者任务在第一天没有执行完，第二天任务又开始，会重复处理。

3.交互问题。两个系统交互，调用超时没有处理得当。实例：被调方超时，调用方一直没有得到响应，如果不设置合理的timeout时间，系统一直得不到对方的应答，最后系统无法执行。

三、开发阶段

1.紧急需求。时间紧，考虑也不够全面，有些模块修改了，另外模板没有修改；有些应用修改，另外的应用没有修改，就会出现问题。紧急需求更需要进行代码review并提交给测试同学测试，并通知回归。（紧急需求，流程可以特殊，流程短，测试能尽快响应测试）。实例：特殊节日，要做活动，有deadline，开发在没有评审，没有代码review，甚至没有测试的情况下紧急上线。

2.优化代码。影响到非优化的模块，而又未回归，导致出错。首先优化代码不能私自优化，需要走正常流程，测试通过并全网回归通过后才能发布。实例：优化重构，开发修改了代码，把其他非优化的模块的代码修改错了，但是测试没有回归被修改的模块，全网回归也没有覆盖该功能点的脚本，就导致bug遗漏了。

3.未通知关联应用回归。关联紧密的应用，其中一个应用修改功能，若不通知其他应用修改、回归，会导致关联应用都出现问题。比如底层应用修改，上游的应用都需要修改或者回归测试，这种情况就必须要通知，邮件通知是一种形式，但是必须要确认大家是否都测试完成。如果发生这种情况就属于责任心的问题。实例：应用出现问题，排查了很久才知道底层应用升级了，但是完全没有收到通知。

四、测试阶段

1.性能问题。存在模块需要处理大数据量，必须专业的评估是否存在性能问题，而不是开发测试想当然觉得性能没问题，很有可能导致重要模块功能异常。实例：项目中有一个接口是用于删除数据，开发和测试认为删除逻辑简单，性能应该没问题，结果超时导致操作失败，因为删除数据需要进行递归，出现性能问题。

2.特殊场景。有些特殊场景功能和接口测试无法模拟，需要采取新的技术手段，在测试阶段就应该模拟，如果无法实现，可以让开发帮忙。实例：消息堆积导致消息无法发出去，但是消息是否收到对功能是至关重要的影响。

3.浏览器测试不全面。对于自己的应用，需要和相关人员确定都要测试那些浏览器，也要关注有没新的浏览器出现和版本的问题。实例：新出现的浏览器，大家认为用户量会比较小，bug 就later了，但是随着时间的推移，新浏览器的用户量也增大，就变成了较大问题。

4.用户体验问题。这个很容易被忽略，测试同学总是在关心功能是否正常，忘记用户体验也是非常重要的一个问题。用户体验如果不好，很容易丢失用户，让用户对产品失去信心，进而不想用。实例：后台应用，面对的是内部小二，开发的工具没怎么考虑用户体验，觉得到时候培训一次就可以了，但是用户全更新，操作流程也只能通过口口相传才可以，到最后很少有人会用功能，有些好功能都荒废了。

5.关联的问题。是测试同学容易遗漏的，这需要对功能十分了解，需要知道架构，如何交互，如何调用。需要提高能力和透彻的分析。实例：应用中有些数据是通过接口从其它应用读取的，如果其它应用返回的是空或者是其他应用挂了没有返回，自身应用没有对这些异常进行处理，导致自身功能也异常。

五、发布阶段

1.不一致问题。日常环境和线上环境不一致，beta机器上和线上代码不一致，比如配置、数据存储方式，都有可能导致问题，测试同学在日常环境和预发环境测试通过，但是发到线上就有故障。这个在发布前需要有checklist进行确认，尽量beta测试。实例：daily的数据是数据库，而线上是走缓存，结果测试通过后发布却出现问题。

2.应用发布顺序有问题。应用之间有些是有依赖关系，如果发布顺序有问题，也会引起线上问题。这个是需要发布之前制定发布，然后项目组全体同学评审才能发布。实例：两个应用，一个是底层应用，一个是上层服务，上层服务需要调用底层服务，新加一个字段，上层服务先发，底层应用后发导致数据写不进去。

3.需求“搭车”发布导致问题。项目发布时，有日常要和项目一起“搭车”发布，两者技术方案或者代码有冲突，导致未测试通过的代码被发上线，引起事故。实例：项目测试完成后自动化回归通过，在不知情的情况下开发把一个需求的代码也合并到已经测试通过代码中，此时没有经过自动化回归就发布了，发布后就出现问题了。

以上的总结是我今后做项目和日常要借鉴的，希望能对大家有帮助。