测试手记

作为测试工程师，每天最主要的工作是什么？我相信绝大多数人一天的工作就是提CQ、写规程或者协助其他部门解决问题的情况，特别是提CQ更是我们最大的任务。只要提CQ就必定会遇到被拒绝或者挂起的情况。我也不例外：

 

刚到中兴的时候负责测试动态数据管理功能，向前台发送一条命令，返回超时信息，于是提交了一个CQ。可是第二天开发抱怨了：这样的问题通常是因为网络状况不好导致的，一般刷新一下或者等几分钟再发送一条命令就好了。如果要求开发用写代码的办法解决所有问题根本不可能办到！扯皮了半天也只能不了了之。

 

应该说提出CQ，只是测试流程的第一步，后面还有很多步骤：确认是否是问题；定位问题根源；提出解决方案；验证解决方案是否达到要求。每个步骤都做到位，我们才能说一个CQ是被彻底解决了。从这个角度分析被拒绝、挂起的故障很多都是第一步、第二步没有做好导致的：或者提出来后发现根本不是问题；或者提出来后发现这个问题根本不能解决或者解决花的代价远比不解决来得大。反过来如果这两步能解决好那么一个CQ距离被彻底解决也就指日可待了。

 

要确认CQ是否要提，和开发的沟通至关重要。刚开始我也是发现点风吹草动就急急忙忙地提CQ， 结果常常因为不能复现或者干脆不是问题而被退回来。直到后来改变“战术”：每天先定期通过邮件形式把问题类型、内容和可能原因集中发给开发，让他们先看看确定一下是否是问题，必要时甚至让他们直接上来看看问题类型（通常是因为有的问题比较复杂，邮件描述不清楚）。最后确定哪些是问题，哪些不是问题；问题的根源在哪里；该怎么解决？这些细节确定后才开始提批量CQ。这样一来大大提高了CQ质量，减少了拒绝挂起的CQ数量，更重要的是通过这样的流程还发现了不少隐藏很深的问题：

 

6.20d版本下测试BSC配置管理部分时，偶尔会出现打开A口管理界面时弹出“77777”错误提示框，而且这个问题出现没有任何规律可以遵循，要捕捉它难度很大。当时我也没有立即提交CQ，而是先把提示框截图和问题描述了一下发给开发人员，请开发人员协助定位。果然不久以后开发人员就把问题找到了，返回一封内容详细的邮件说明问题的根源和可能解决方案。经过沟通，最终确定用第三种方案解决问题。这样一个隐藏很深的问题在开发和测试双方共同努力下终于被发现了。

 

还有一次，在修改基站小区配置时也出现了内容不明的提示框。在经过与开发人员简单沟通后提交了CQ。但是审核过程中有人提出在别的测试环境中没有出现类似的情况，怀疑是配置数据有问题导致的，于是只好请开发人员详细定位一下问题的根源。当时我心里也有点七上八下，毕竟测试环境是我维护的，如果最后发现是配置数据有问题，那进一步就说明测试环境本身也有问题了，而其它环境上没有类似问题更加重了我的担心。但是我还是提醒自己，在开发人员没有最终排查出问题之前不要轻易下结论。果然不久开发人员就发现了问题根源：程序在启动过程中没有调用一个必须调用的方法。这样一来又一个险些遗漏的错误被抓住了。

 

要想从彻底避免拒绝挂起情况的发生，避免错提漏提情况的发生，不但需要测试人员对通信原理、软件需求、软件结构有相当了解；还需要掌握熟练地测试技术；更要求软件开发流程中严格控制需求变更。而除此之外就是需要大家通力合作、及时沟通，才能最大程度避免上述情况发生。毕竟“术业有专攻”，谁也不可能做到样样精通，只有互相取长补短才能尽可能把大多数故障消灭在版本发布之前。