hw 协议测试套编写

纯协议测试，近乎100%的自动化率。

如何快速的让测试人员编写测试脚本？提升测试工作效率，压缩测试脚本编写调试周期，从而更有效的支撑TDD敏捷开发模式。

IDE工具为GTR，自研工具。语言为TTCN3，通信界的协议描述语言。具有非常强大的模板匹配机制，可以很方便的构造出协议结构。对于复杂的通信协议来说，很大一部分的字段其实都是固定的，测试中需要修改的通常和业务强相关。譬如主被叫呼叫号码等等。所以通过开放业务相关的字段给脚本编写者，隐藏底层的字段就显得很重要。一方面接口参数不多，方便高效率编写。同时，更少的接口参数意味着更少的出错性。

一个好的测试框架应该从哪几方面去评估？或者设计之初，应该考虑哪些方面？

首先第一个，肯定是易用性。不要让拿到接口的童鞋一头雾水，不知道从何下手。不知道参数究竟该如何填写。所以在设计api接口的时候，参数应该适宜，3-5个参数为佳。参数太多，无疑增加写脚本的同学的难度。虽然参数多，灵活性大，但损失了工作效率。尤其是很多测试执行的同学，语言功夫不是非常好，越简单的，跟业务越贴近的，越能降低他们写脚本过程中的难度。

第二个则是可调试性。能够有效的支持写脚本的同学迅速的定位脚本问题。IDE自带的调试功能就不说了。测试框架中，应该设计一套日志系统，记录脚本的运行轨迹，能够根据日志确定错误发生的地方。详细的日志能够为定位问题提供详细的信息。如果不能使用类似于log4j这种类库的话，可以使用system输出。在框架合适的地方打印出合适的日志。再者，通过写文件的方式去记录日志。方便秋后算帐。

第三个则是扩展性。项目需求发生变更后，当前的测试框架如果不满足测试需求，可以方便的进行扩展。而扩展的同时，需要兼容老版本的用例。让脚本做到平滑升级。通常可以维护一个结构体，当需要扩展的时候，可以通过扩展这个结构体来扩展框架所支持的测试功能。

第四个则是测试代码的结构一致性。协议测试无外乎这三个过程，测试前期准备（初始化工作环境，譬如电信测试中的复位所有电路），测试执行（测试主要的代码都在这个部分），测试执行结束后的清理工作（譬如电信测试中的挂断电话，避免占用电路导致后续呼叫无法进行）。建议所有的测试代码都保持这个结构，一方面对于每一个场景，可能高级工程师写好一个示范后，初中级工程师即可ctrl cv根据具体业务进行修修改改即可。极大的降低写作难度。提升写作效率。

框架中具体的api接口的设计，应该遵循什么样的法则？

第一个，也是核心法则，贴近业务。最好能偶抽象出具体的业务，然后参数配置为和该业务强相关的字段。酱紫，一串api调用下来，就是一个完整的业务流程。直观，形象，具体。譬如一个电话呼叫的api，可以设置为function makecall_sip(sipusercaller,sipuser called)。其中名字makecall_sip表明这是一个电话呼叫的api，使用的协议是sip。而不是ISUP，或者BICC.参数只有两个，分别主被叫的号码。当然，在这个api实现里，实现了具体的电话呼叫细节，上层只需要根据业务需求，填入主被叫号码而已。

第二个，不要开放过多的参数。如上所述，过多的参数会增加脚本难度，同时降低脚本可阅读性。

第三个，api中的参数需要有可扩展的结构体。方便到时功能扩展。譬如上述的sipuser这个结构体，如果功能需要，可以扩展相应的字段，以便于新增功能。而接口保持不变，使得测试代码可以平滑升级。

协议测试，无非就是构造字段，然后通过网络发送到服务器，再处理服务器的回包，进行分析。

如何快速的构造消息？TTCN3提供了模板功能，通过模板，可以在协议描述基础上，定义出常用的协议结构。api在组装消息的时候再灵活选择不同的模板即可满足快速构造协议请求的需求。

而其实比对服务器返回的结果才是重点，通常，我们只比对感兴趣的字段。通过设置一些匹配机制进行。也就是过滤器。感兴趣的字段可以置入预期结果值，如果通不过匹配器，说明服务器返回结果和预期不同。该条case是执行不通过的。而很多字段，并不care。此时可以通过通配符来进行匹配。只要该字段存在，而不关心其具体值，可以通过？来匹配。如果一个字段可有可没有，则可以通过*来匹配。

项目经历了V3 V5两个大的版本，框架也在不断的优化中，V3版本api漫天飞，一个呼叫功能就有多个api。譬如makecall_sip_180,makecall_sip_200等等。api一多，自然整个脚本就凌乱不堪。各有各的风格，测试代码风格迥异，而有的api只是满足当时的一个测试需求，后期可能已经不再维护，但大伙不一定知情，极大的增加了后续脚本维护的工作量。所以在V5版本中，对api进行了统一，根据业务剥离出数量有限的api，先组内评审，确定满足需求后，一部分将老api的功能移植到新api中，同时后续的api设计也遵循上述的一些规则，使api得以规范化。同时，开发脚本更新工具，对老的脚本，通过一系列替换原则，将老api替换为新的api。统一了最上层的测试代码。