4.4 测试建设之基石——测试框架的设计

俗话说“万丈高楼从地起”，大家都知道，不管盖的房子是大还是小，都是有地基的。那么，这个测试框架就相当于一个地基。地基越牢固，抵抗外界干扰能力越强，如抗震、抗台风暴雨等。类似的，测试框架结构合理、重用率高、易移植、扩展性好、易维护、那么它就是一个好的框架。

4.4.1 相框与测试框架

说起相框，如图4-10所示，那是再平常不过的日常家居用品，我们都很熟悉它。记得小时候，家中的相框是专门请木匠师傅做的，然后由油漆师傅上漆，并画上花边以装饰，最后当然少不了压上玻璃。记忆中，那时的相框不管大大小小，清一色都是长方形的。后来，随着人们生活水平的提高，出现了各种各样的相框，如椭圆形的、心形的、月亮形的，不仅造型标新立异，材质也五花八门。此时的相框，已不仅仅是镶相片的相框了，更是一种点缀家居生活的工艺品。说这些与测试框架的设计有什么关系呢？不都是风马牛不相及的废话吗？其实未必，反过来细细思考这些看似毫不相干，甚至相差万里的事物，它们之间存在着一种内在的必然联系。关于这一点，著名教育家丰子恺先生早在其艺术教育理论中就提出了“一通百通”的观点，指出不同类别的艺术和不同艺术形式之间具有相通性。

初次看到“测试框架”一词，与大家的感觉一样，觉得很抽象，也很高深，有一种“高深莫测”的感觉。框架，在技术上是指针对某一特定领域解决方案的完整表达。框架设计，就是设计一种完整的解决方案以解决某一特定领域的问题。框架并不是空中楼阁，提出来玩玩而已，是要为解决实际工作问题而服务的。框架有它的层次骨肋，这些层次是解决某类问题的方面；骨肋是一种支撑，是一种解决问题的方法。测试框架是属于软件工程领域解决测试相关问题的方案，它里面放的是为测试活动服务的行为与方法，以及一些流程管理规则或规范，是看不见摸不着的知识库。为解决不同类别的测试问题，测试框架有类别之分，如功能测试框架、自动化测试框架、性能测试框架、流程规范框架等。而相框是用来展示照片，当然也可以陈列广告图片、宣传语等，里面放的内容是看得见、摸得着的，它为解决我们实际生活中的家居陈列或市场宣传问题而服务。后来，由于需要的服务对象变了，人们的生活品味也变了，也就出现了各种形状、材质的相框，带来了相框家族的必然发展。

以上观之，两者的表现形式是迥然不同的，相框是一种有形的实体，即使有着后期工艺美术的设计衬托，它仍是看得见，摸得着具体的有形实物；而测试框架是一种解决软件测试领域问题的技术方法与流程管理的抽象框架，是摸不着看不见的无形产物。但是，它们的本质是相同的，那就是都为解决对应领域的问题而出现，为解决对应领域问题的细化而发展。

4.4.2 化抽象为具体——测试框架内容

测试框架主要包括两方面的内容，如图4-11所示，一是业务测试技术模块，二是流程规范管理模块。前者是完成任务需用到的测试技术的集合，后者是技术应用过程中各环节需如何控制的策略。

业务测试技术模块与流程管理模块，可以理解为前者是测试技术线上的平台。后者是测试管理线上的平台。技术与管理对于一个完整的测试体系而言，它们之间并不是孤立存在的，而是相互依存相互制约的，如图4-12所示。

业务模块就像一座座小山，测试技术如同图中的箭头，多边形的边框则表示软件产品生命周期各阶段的流程规范管理手段。技术是攻破一道道难关的钥匙，不同的难关需要不同的技术。俗话说得好“没有规矩，不成方圆”，分布在技术力量外围的流程规范很重要，可以说都是通过一桩桩、一件件教训总结出来的，是管理的一种手段。技术再强，如果没有规则是行不通的，就如同我们玩游戏一样，必须遵循游戏规则，方可交锋，比个输赢。但反过来，如果流程规范约束太多，或不灵活，束缚了技术的发挥，会让事情弄巧成拙，流程规范成了绊脚石。比如用例编写规范和自动化脚本编写规范，这些规范是必要的，大家工作时遵循这些规范，设计出来的用例或代码可读性好、易维护。但如果规范过于约束，影响设计开发效率，在项目压力下，工程师做不到一直坚持遵循规范。最后往往导致“漂亮的外表后面却是一堆糟糕的代码”。换句话说，要求的功能是实现了，但是实现这些功能后面的代码却是一团糟，人见人畏，不可维护，好像有成堆的Bug危伏四起。看到这样的代码或用例，人人心里都在叫苦，重写的念头会异常强烈。所以只有技术与流程相结合，才能组成一个强有力的测试框架。

测试技术的框架设计，犹如编织通用的不同类的网，以便捕到不同类的鱼。同样地，我们可以设计不同类的测试框架，以能更专注、更有效地发现不同类的Bug。根据常用的测试类型，可把业务测试框架的类别分为功能测试框架、性能测试框架、自动化测试框架等，如图4-13所示为业务测试技术框架组成示意图。

在流程规范管理框架的设计中，我们可以考虑测试规范系列、测试工作流程系列、测试设计模板系列，如测试方案设计模板、测试用例设计模板、测试报告模板等内容，如图4-14所示。

业务测试技术模块、流程规范管理模块都是框架的抽象。从图4-12中可看出，它们分散在不同的地方使用。流程管理方法的位置也是相对的，在不同项目的应用场景、不同的阶段，它需要做适度的改变。正如“3.4.2让大家一起忙起来”提到的一样，它们都需要在过程中得到发展与变化。

业务测试技术框架与流程规范管理框架，不管它们之间的关系如何，能给新的测试项目带来多少重用部分，都需纳入到新项目的测试套件设计中，最终为测试项目的各业务模块服务，如图4-15所示。

4.4.3 突破起点——搭建测试框架的方法

测试框架设计的主要目的是项目的测试都能以框架平台为基础，并在框架的控制内实施，使得在不断的项目测试历练中积累的经验能够沉淀、传承、复用，从而提高测试的整体效率，降低项目研发与维护成本。就框架设计的具体方法，比如我们该如何操作去突破从无到有，到进一步的改进，再不断地改进，以致日臻完善。笔者接下来结合自身的经历，谈谈具体的做法。

一个公司，在做第一个项目时，谈测试平台的建设，可能性不大。但如果测试负责人有过带项目的经验，在执行相关的测试设计时，即使没有这方面的安排，也能感受到这方面的必要。如果你是第一次做项目，比如刚毕业的学生，可能没有这方面的经验，但当做第二个类似项目时，对于相同或类似的产品功能需求及性能需求，自然而然你会知道如何去做，这是因为你有了一定的积累。这个积累不仅仅指解决问题的方式方法，是指有了一些可重用或部分可重用的测试套件，如某测试对象的测试方案、测试用例、自动化测试脚本、一系列的测试数据、测试工具等。一般一个公司总是有自己的产品方向的，不可能什么产品都做。另外，在项目研发中如何节省人力与时间成本、提高项目开发效率、缩短开发周期，向来是公司老板的追求。这样，我们在做第二个类似项目的测试时十分有必要考虑平台化的测试需求，让后续的项目能在框架的基础上进行工作。这就要求框架是通用的、可重用的，当然重用的范围我们可按前面也提到过的测试类别来分，如业务功能测试、自动化测试、性能测试等。现就框架的搭建提出如下几点看法：

● 业务功能测试框架，可重用的是测试思路，框架中可列出各测试点及其测试方法。

● 测试数据，特别是一些影响性能测试的数据，包括一些测试数据生成程序，集中一起管理，并写好使用说明，以便各项目测试过程中需要时取用。

● 自动化测试脚本、接口函数等测试套件，需无条件纳入配置库进行版本管理。对各项目通用的接口函数考虑封装为独立的中间库，把此库作为自动化测试框架的元素之一进行扩展与维护。

● 回顾Bug库中历年发生的Bug，对这些Bug进行分类，分析这些Bug的发生原因，拿出日后如何控制的可行方法，并对原有的测试框架做改进或补充。

● 测试文档设计模板，可结合公司内部开发流程要求，重点考虑测试文档本身应有的内容，模板中给出例子为宜。

● 制定测试设计评审机制、测试用例设计规范、Bug录入规范、测试代码设计规范，并在项目的执行过程中不断完善。

小贴士：

框架有它的优点，如与项目无关（跨项目）、可重用、易扩展。反过来，它也有缺点，如使测试设计在一定程度上受到约束，当不熟练规范的要求时反而会影响测试工作的进度。另外一个致命的问题就是“牵一发，动全身”，如果框架中漏了某个测试点，会导致用这个框架的所有项目都漏了这个测试点，直到发现了这个漏洞为止。

测试框架的设计是一个过程，正如前面所说，当反复测试相同或类似项目的业务时，自然而然萌发了测试平台化的需求，从而有了首次的测试框架。随着后面一个个测试项目的开展，测试框架得到不断重用，同时随着不同项目需求的变化，失败教训和成功经验的积累，不断地推动着测试框架的更新、发展，如图4-16所示。

小贴士：