关于系统测试的思考

网络产品的系统测试也做了几年，主要都是黑盒测试。黑盒的系统测试更关注于从应用场景出发，从测试数据，SUT(System Under Testing)的配置，DUT(Device Under Testing)的操作三个方面，运行系统测试方法进行测试。对从目前的实践看，目前我们所采用的系统测试策略在项目中取得了很大的成效，我归纳了一下，主要得益于如下几点：

（1）稳定性叠加的测试策略。目前的系统测试，关于两个层面的稳定性内容。一个是SUT，整个被测系统间设备的交互；一个是DUT，被测设备开启的各功能间的交互。对SUT层面，我们是通过功能的部署达到交互的效果。这里头有一个很重要的技术问题需要解决，即设备的定位，功能，性能都存在较大差异，如何进行部署？我们采用的方法主要有2个：一个是应用场景的叠加；一个是根据ISO/RM参考模型，DUT间对等层功能的叠加。通过这2种策略，能很好解决这个问题。那DUT内部功能的叠加如何进行？这个主要是通过设备的功能需求规格，我们将需要开启叠加的功能，根据ISO/RM模型，逐个进行叠加。这2个层面的设计，在实践中，是统一一起进行考虑。

（2）系统稳定性测试方法的应用。目前的实践中，我们归纳总结出的方法主要有容量测试，压力测试，负面测试，功能交互和攻击测试。在具体测试应用中，一个好的测试例，综合应用了上述的多种方法。

目前我们的系统测试主要是关注于被测设备的稳定性。在项目测试实践中，系统的稳定性测试策略主要包括2块内容。一个是内测阶段，我们更关注于SUT/DUT的稳定性增长测试。在项目内测准入/准出阶段，我们更关注于SUT/DUT的稳定性验收测试。

上述的测试实践，确实能为项目带来很好的稳定性bug绩效产出，也最大程度降低了系统测试对测试执行人员技能的依赖。一个测试执行人员掌握上述（2）中的方法和经过初步的执行培训，即使对被测对象了解不深，也可以获得一定的稳定性测试执行产出。

不过，上述的方法还是存在很多的问题。主要是测试质量和测试效率的问题。分析如下：

（1）测试质量。在稳定性增长测试阶段，上述的方法，从目前的评估看，只能达到中级的稳定性测试质量。从项目度量数据的统计看，还是存在一定的测试遗漏。另外测试执行质量对执行人员的依赖比较大，资深测试执行人员的绩效产品明显高于初级和中级测试执行人员；

（2）测试效率。主要还是手工操作，虽然有脚本，不过顶多只是做到半自动化。复杂用例的执行周期太长。

上述的2个主要问题，是制约系统测试发展的最主要技术问题。这里提出一个想法，看是否能解决上述问题。采用模型-类测试方法，我姑且称为MCT（Modal-Class Testing）。首先研究被测对象，建立被测对象模型MUT（Modal Under Testing），MUT也采用类的概念进行设计，主要的属性为MUT的静态属性和动态属性，动作为状态变迁，定时器，状态机等。测试模型，建立各种测试类，测试类中封装了该类型的通用测试方法。将方法施加于被测对象上，即进行系统测试。

上述想法，应该需要一个自动化的框架进行支撑。