3.5 好钢用在刀刃上：测试技术应用之合适设计

不同行业不同业务，测试方向会不同，如测试手机产品等的嵌入式软件与测试Web互联网软件就有很大不同。面对林林总总、错综复杂的测试对象，选择什么样的测试技术，如何应用，正是测试技术的应用设计需考虑的。

下面通过“通信的心跳在狂蹦”及“解开用例失效之迷”两个案例的分享，希望能帮助读者理解测试技术应用设计的重要性。当出现漏测后，如何分析问题、解决问题，并做如何改进以防患未然。

3.5.1 通信的心跳在狂蹦

通信心跳是当今通信技术应用中常采用的一种方法，指服务端每隔一段时间发一指令包到客户端，客户端收到后，再反馈应答指令包，以表示自己还处于连接状态。否则，如果间隔一定时间未收到这样的指令包，则服务器认为客户端已经断开，而进行相应的客户端断开逻辑处理。

【案例】通信的心跳在狂蹦

背景描述：一天，某市三甲医院检验科的医生特别忙碌，等在门外边排队取微生物检测报告的用户明显比往日多。据当班的陈医生说是因为PC端的数据接收软件出了问题。原来与检测仪连接后，系统可一边在仪器端测量样本，一边在PC端进行数据处理，同时PC可自动打印报告单，但现在接收软件很容易报错，严重影响了检查速度。据陈医生说，前几天按仪器厂家维护人员要求，对仪器软件进行了升级，但这些天用过此仪器，也可以在PC通信软件上打印数据。今天人多，软件却出了问题。

说明：背景中描述的检测仪与PC端数据接收软件通信的物理示意图如图3-13所示。

事故影响分析：从前面的背景描述中，可清楚看到对终端用户医院所造成的不良影响，更严重的是一些急诊病人不能及时得到检验报告单而延误了病情的诊断，更是间接造成了人的生命安危问题，影响非同小可，是一个急需解决的问题。

问题分析：该医院用的微生物检测仪与数据通信接收软件并不是同一家公司的，但它们都遵守行业的通信协议，所以双方的数据可以通信。医院先找到数据接收软件的公司，该公司分析说是由于仪器端软件快速发送心跳包，打破了原来的通信规则，把接收端的缓冲很快挤满了，而造成了内存溢出错误。于是问题很快被转到仪器软件的研发部门。

问题进一步分析：仪器软件的开发人员接到反馈后，马上组织相关人员进行分析，发现是由于开发人员在解决通信速度慢问题时，把通信心跳的3秒延迟去掉了，导致仪器（服务器端）一旦与PC数据接收软件（客户端）建立连接后，一直不停地发心跳包给客户端，使得通信协议工作紊乱。在客户的内存处理机制欠佳的情况下，很快造成溢出，软件工作失常。问题的原因找到了，开发人员快速地通过修改代码，对编译版本进行处理，测试人员复测后，第二天对院方的仪器软件做了升级。

漏测分析：分析当时的测试记录，通信的功能测试用例存在，用户常规使用场景测试用例也存在，采用的都是黑盒功能测试方法。而问题恰恰是出在与时间相关的通信连接上，且这种连接是在服务器端没有数据包（测量数据）传输的情况下才发生。测试为什么会遗漏这个测试点？要如何做才能发现这个问题，又要如何做才能在日后规避这个问题呢？

改进测试方法：对通信的测试，不能仅停留在业务功能。有效可行的方法之一是通过网络抓包工具截获通信端口直接出来的数据进行分析，可以透明地发现通信双方收发数据的正确性。一旦存在丢包严重，协议工作将紊乱，在通信端口截获的数据流中可以很快反映出来，并及时发现存在的问题。

一个人的成长过程中会遭遇很多挫折，只有从不断地跌倒中爬起来，再跌倒再爬起来，才能抵达一站又一站的成功彼岸。测试也一样，需从一次次的漏测分析中吸取教训，找到测试的盲点并进行突破。什么类型的测试，需应用哪些测试技术，并没有一个通用的标准。失败是一种财富，能否合理应用各种测试技术关键要在测试对象的深度分析上下工夫。

3.5.2 解开用例失效之谜

【案例】解开用例失效之谜

背景描述：某精密仪器有对自身部件进行自检功能，此自检的功能是通过软件发命令给硬件板卡上的控制处理器实现的。部件A有3种状态，“初始位”、“到上位”、“到下位”，用户单击“初始位”，不管当前部件正处于哪一个位置，都回到“初始位”；只有当前部件A在“初始位”时，单击“到上位”、“到下位”才有效。在“初始位”状态，表示部件准备就绪，当仪器工作时始终在这3种位置来回运动，完成一件工作后，重新回到初始位。如图3-14所示是仪器自检工作的接口示意图。

从用户使用角度看，仪器部件A进行自检的人机交互界面如图3-15所示。

在对测试对象的分析中，自检可以理解为软件的一个功能项，而此功能项又包括3个小点，包括“初始位”、“到上位”、“到下位”。设计测试用例时，需要针对这3个测试点分别进行设计。其中，“到上位”对应的测试用例及执行记录如表3-2所示。

就“到上位”自检本身的功能正确性来说，有上面SelfTest-001正向用例1条，SelfTest-002、SelfTest-003逆向用例2条，完全达到了对需求点的覆盖要求。

但不好的事情发生了，此产品上市不久，终端用户反馈“自检功能使用失效”。测试部收到这个消息后，每个人都非常诧异。测试经理马上派人进行追查，测试工程师A找出当时的测试记录来看，如表3-2所示，很清楚写着是“PASS”的。用户就是公司的上帝，投诉电话已接到，投诉单很快会收到。于是测试经理亲自在仪器上进行再次确认，结果是自检功能好好的。依往常经验，用户的投诉常有描述不准确，或误操作的可能，这已是常有的事了。测试工程师A于是打电话和用户进行沟通，了解问题发生的详细情况。最后了解到“并不是自检功能失效，而是做了自检功能后，接着做一个用到此部件的测量，测量不成功，仪器报故障”。

当测试工程师A了解到此信息后，已明白了事情的一半原因，再进行测试，果真是这样的结果。这条路径测试确实没走到，是用户场景测试的重大遗漏，须马上出ECR（Engineering Change Request，工程变更申请）补救。

事故影响：一旦出现这种使用场景，用户将不能正常使用到此部件的测量功能，部分功能丧失。

问题分析：对于测试来说，表面上看是测试用例的缺失，没有像用户那样操作，对用户使用场景缺乏全面足够的认识。而往深层次思考，是缺乏对设计实现原理的理解，而恰好设计对这一点也没考虑周全。正如前面所说，仪器部件A的工作状态任何时候开始前都要在“初始位”。用户投诉的此事件，是因为部件A在自检中途退出时，没有复位，接着使用它，仪器状态不正确，所以上报了故障。理解了原理后，设计相关的测试用例也是自然而然的事了。开发最后解决此问题实际上也是增加了复位命令，即不管部件A当前在哪一个位置，调试完成后，如果当前位不是“初始位”，都要回到“初始位”。

解决措施：紧急解决措施（临时解决）是用户关机，再开机，即重新启动仪器即可。但作为厂家，需考虑用户使用的满意度，彻底解决此问题才是上策。须及时出ECR，以支持已售仪器的全线升级。

案例中的漏测是用例的缺失造成的，但什么原因导致做测试设计时没有考虑到这种情况，是值得重点思考的。也只有从教训中找到防范的控制措施，才能避免类似的问题重复出现。

小贴士：