曾经做过一个卡片发行设备的项目，我的工作是依据通讯协议文档，测试发行设备的固件。测试过程不太复杂，主要是组织各种命令帧，目的是测试固件对正确指令帧和异常指令帧的处理能力。本文从沟通和文档撰写的角度，整理测试中发现的问题。

　　项目初期，在立项的会议上，研发负责和生产沟通的接口人，暂称他为A君吧，拍板定下了固件下载的方式，采用JTAG方式下载。接着，项目经理指定测试人员撰写固件下载说明书，并提供给生产的同事。于是，这个任务自然而然的落在了我头上，那就开始干呗。先把下载的那套环境搭起来，然后对下载过程左拍照，右拍照，最后，费了半天功夫整理出一篇说明文档，颇有成就感的提交到了CC服务器上。结果，一周不到，厄运降临。在项目例会上，A君突然改口说，生产上要求采用先烧写芯片再焊接的方式。这可真让人浑身不舒服，事先不和生产沟通好，拍脑袋定方案，现在又要求改方案。之前的文档不是白写了吗。抱怨归抱怨，工作还得继续，于是多花了半天的时间，不得不按照新的下载方式重新写了一遍文档。这次，内心充满了各种不乐意。再到以后的项目，例会上只要和测试相关的，我都轻声多问一句，你确定是采用某某方式吗？

　　这次经历让我印象深刻，作为一个团队的接口人，如果不能和生产的沟通一步到位，甚至靠自己的主观推测，这会给团队其他成员带来不少麻烦，造成时间成本的增加。这次经历也只是麻烦的开始，接踵而至的是技术文档暴露出来的问题。

　　作为测试唯一可参考的技术文档，我很快就发现了发行设备通讯协议不一致的问题。第一代发行设备的通讯协议对其中IDTYPE标识的定义是1表示广播地址、0表示专用地址，二代的通讯协议对其中IDTYPE标识的定义是0表示广播地址、1表示专用地址，显然，两份通讯协议对IDTYPE标识的定义是不一样的。由于测试的是第二代发行设备，然而此发行设备程序中沿用的却是一代的标准，直接导致了我报告了“错误”的BUG。

　　这件事说明，发行设备升级后，新的通讯协议没能向前兼容老的通讯协议。之后，研发很放心地给了我一份最新的技术文档，随后，用坚定的眼神告诉我，”拿去，不会在文档上出问题了”。随后的测试说明，真是怕啥来啥，我又发现了通讯协议表述不准确的问题。按照通讯协议的说明：标准的数据帧有个LEN字段，后面是DATA字段和BCC字段。协议里对LEN字段的定义是表示DATA字段的长度，但是当BCC为FF的时候，程序做的处理是，FF要拆成FE 01 ,此时LEN应为DATA数据域所有字节的和+1，但是，这个在协议里却没有任何的说明，导致误判。

　　我很无语，只能说，老天，如果这个项目能重来，先让我测试技术文档吧。怀着一颗纠结的心，我发现发行设备通讯协议的另一个问题，字段定义不严格，数据帧有个RENUM标识，协议里定义此标识为：重发次数。若RENUM=1,按照此定义理解，应为重发一次，也就是发两次，但是，实际上，发行设备只发了一帧数据。因此，这个定义不准确，应改为发送次数。

　　整个项目下来，我很累，研发也不轻松。回头想想，有效沟通是多么重要。另外，技术文档的撰写也很重要，一定要严谨，准确，不能是是而非，甚至出现歧义和错误，这都是不可取的。

版权声明：本文出自 jifang  的51Testing软件测试博客：http://www.51testing.com/?112793

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。