在做TTCN3测试的时候，如果项目稍微大一点，那么TTCN的代码就比较多了，同样的，这也是有人编写的code，与SUT的code一样，TTCN3测试系统同样会存在bug，那如何减少测试系统的缺陷，提高测试效果呢？
很多时候，当测试人员编写好TTCN用例后，就只有等SUT发布，然后把用例一个个的跑，结果很可能就是，每个case都可能遇到错误。这里的错误可能是TTCN3脚本的错误。而且测试用例代码的维护也是一个重要的工作，现在大家可能都比较重视产品code的文档，但是对于测试脚本的文档控制，可能就相对较少。接手测试项目的人可能需要自己直接读原来的测试脚本来熟悉测试系统。
在<<Validation of a TTCN-3 test system>>中提到了几种常见的TTCN3测试系统的问题：
1、Templates中错误的信息，包括错误的值或者发送没有初始化的字段等
2、测试用例中错误的消息序列，或者缺少某些消息。然后在编写用例的时候，有些类似的用例经常使用copy/paste，所以这些错误很容易扩散到很多地方
3、一些TTCN3编码错误，比如substr一个长度不恰当的字符串，通常在runtime的时候才会报错
4、测试系统底层的一些错误，比如SA与codec有错误。比如以太网帧的最大长度是1500，而你尝试发一个1501长度的包，如果SA没处理好，那就有了错误隐患
5、在执行测试时候的一些人为错误
所以如果把测试系统的编写作为一个软件开发过程来对待，用测试SUT的方法来测试我们的TTCN代码，那测试系统的质量不就可以得到提升，从而可以提升SUT的质量，提高效率。文章也提到了几个方法来提升测试系统的质量，可以归纳为下面的几点：1。减少测试用例代码的复杂程度。这可以通过搭建一个测试中间平台来实现。2。可以在SUT发布之前，用一个伪的SUT来跑一遍测试用例。 3。减少人为的操作动作，尽量实现所有测试用例的自动化。比如设置一些环境参数，你可以通过脚本来自动做，而不需要自己去手动配置SUT。 4。保持测试文档的及时更新
第一点非常好，平时在测试活动中，我们也自觉或者不自觉的都实现了一写公用的TTCN函数，或者编写了一些常用的Framework， 这些也属于测试中间平台的一部分。 如果我们在编写测试代码之前就规划好一个测试中间平台，设计好平台所提供的各种API，然后首先实现这个平台。 实现之后，用各种软件测试的方法对之实行测试，比如单元测试，功能测试等。更重要的
是，结合TTCN3测试环境提供的PA，SA，codec来对这个平台进行测试。 那如果SUT没有发布，怎么测试这个平台呢？
第二点可以回答上面的问题， 简单编写一个SUT的simulator。就象开发人员在做单元测试时候的桩函数，我们不需要这个simulator实现所有SUT的功能，仅仅需要它实现与周边环境的interface。这样，就可以通过这个simulator来测试TTCN3测试系统。这样可以预先排除一些错误，肯定比直接放到SUT上测试提高效率。
在测试平台测试完成后，可以把测试用例运行到这个平台和simulator的环境上，再来预跑一次测试用例，同样，这可以减少测试用例中的错误。
测试活动的目标就是提高产品质量，引入TTCN3不能只是为了实现自动化的测试，与此同时要尽量减少测试代码中的错误，才能达到我们的测试目标。