我写过的软件之UniversalTestForSoftcell

本篇记录一下UniversalTestForSoftcell的来龙去脉。。。^_^。

自从公司re-org之后，开发和测试就严格区分开，分别汇报给不同的manager，经常会出现掐架的现象。某种程度上，开发和测试之间比较紧张的关系会利于产品的质量，当然，也不能天天吵架。所以Director希望看到开发测试互相掐架的现象，但是又得控制掐架的程度--平衡的艺术。

 

以前开发花了大量的时间来建立CT的自动化测试框架，但是re-org之后这个测试框架就自然而然地归给CT用了，而函数级别的UT其实没有太大的作用。Code Review有点作用，但是成效不太明显，毕竟不能指望通过Code Review来消除全部的bug。开发人员失去了比较有效的QA手段了，Test Manager则时不时challenge说DEV做出来的产品质量有多差。权衡了一下，就决定把“提高UT到CT层次”作为最总要的team objective。我原来以为，team里面的骨干有不少，做一个新的UT框架应该不是问题，应该有人能够跳出来做一个框架。不过有点失望，任务布置下去几个月之后基本上没有实质性的进步。分析了一下，估计是几方面的原因导致的：

1、  技术积累不足

2、  时间不足

3、  主动性不足

 

想了想，决定自己又跳出来做一套新的测试框架。已经做过几个测试框架和测试工具，做一个新的框架对我来说基本上没有什么技术难度，只是工作量的问题。上班的时间太零碎，经常开各种会，参与各种讨论，基本上没有整块整块的时间来做开发。公司才能有开发环境，很多时候还得晚上周末都得在公司继续开发。痛苦了差不多2个月，终于做好了一个给softcell3的，取名为UniversalTestForSoftcell，接下来又痛苦了1个多月，弄好了另外一个，取名为UniversalTestForCCA。

 

新的框架尝试做几个方面的改进：

1、  消除多个函数参数的问题。CA的有些功能比较复杂，要做某一件事情得需要几十个参数。以前开发的UniversalHST中的自动化测试框架被N个人进行了开发，不断地扩展，原来会有意识地进行重构，但是换个manager之后，测试人员基本上只有扩展功能的意识，但是并没有做重构的意识。后来有些函数的参数都飙到30多个参数来，代码可维护性越来越差。通过把相关的控制参数归并到结构体中可以消除这个问题。

2、  剥离一些hardcode的参数。让TestCase可以以不同的配置运行，把一些运行参数从原来的代码中剥离出来，存到配置文件中，运行时加载进来。

3、  绑定Test Case描述和运行步骤。以前的测试框架中的test case描述和具体步骤是分开的，这就导致了更新test case步骤的时候往往得单独更新test case描述。更要命的是test case描述往往是有序号的，在某一个地方插入一个步骤的话会导致后面的步骤的序号也受影响了。为了解决这个问题，引入了2个宏：ADD_GROUP和ADD_STEP绑定test case的描述和具体要执行的测试步骤（函数调用）。测试步骤的序列号也能自动生成。

 

UniversalTestForSoftcell是针对Softcell3的测试框架，包含一个MiniKMS模块，利用CreateLib生成的Network，包含了ECM、EMM、CAT、PMT等信息，作为给softcell3的输入，同时把softcell3的VD和CA Task API进行封装，形成闭环进行验证。

 

做完之后给大家做了一个培训，讲解设计的原则、test case的基本实现、如何添加test case等，然后退居二线，让兄弟们去大量扩展test case了。