万里航行总舵手——业务测试架构的设计

万里航行总舵手——业务测试架构的设计

    目前，国内的很多公司，包括一些知名大公司，可能都还没有这个职位，但应会有这样一个角色的存在，比如这个角色落在测试经理或是测试主管的肩上。笔者不敢 称自己是一个专业的测试架构师，只是有一天发现业界有这个职位时，并对着职位描述的定义，发现自己很幸运地在不知不觉中做了一些这方面的事情。

    对于架构，更具体一些指架构模式，如第6章 介绍的关于测试对象分析的三层架构模式。一边是深不可测、充满挑战的技术与艺术的高度体现，一边是“又恐琼楼玉宇，高处不胜寒”的担忧。高深的东西如何平 民化，即那些高调的架构，能不能具体应用到工程实践中，很好地达到预期，而不是成为束之高阁、脱离实际的一堆废话或模型。这里站在项目测试的实用角度，总 结工作中的经验与教训，提出架构设计的操作模型，如图4-9所示。从图中我们可以看到一个完整的测试架构设计过程包括以下几个阶段。

1 业务测试框架设计：它包括业务测试技术与流程管理两个部分，基本框架的设计离不开业务需求与公司流程体系。其表现形式可以是一种测试方法、一块代码程序、一系列的流程规范等。
2 提取测试需求：广义上理解，包括与测试工作相关的业务及非业务需求，只有有了需求（工作中出现的问题也可认为是一种需改进的需求），才可进一步完善框架。
3 决策/部署测试策略：为测试需求服务的一系列解决方案。
4 开发测试套件：具体解决测试需求的措施集，如测试用例集、脚本程序、测试工具等。

图4-9  测试架构设计过程示意图

    这4个 阶段，它们之间是相互作用，相互影响的。细心的读者也许已注意到，位于图中内侧的“提取测试需求”，它与测试框架的设计并不是一种直接关系，没错，它们之 间的关系要通过后续的工作体现在框架中。可以理解为一个新的测试项目开始了，以新的测试需求为起点，通过部署测试策略，开发新特性的测试套件，来完善测试 框架。如此往复，依托一个个测试项目，不断改进、壮大测试框架。以使后续的项目测试能重用测试框架的内容或方法，并使整个测试过程始终在有序可控的状态下 进行，最终能以高质量且减少项目的整体测试时间来完成测试工作，这也是架构设计的最主要目的。

    对这4个阶段，可以理解为它是一个系统级的最顶层划分，对于每一个阶段，它又可划分为不同的节点。其包含的意思及操作的方法，将在接下来的章节中进行详细讲述。

一个好的架构，只有在应用中收到实际的效果后，方显它的价值，比如节省了多少测试时间或提高了测试的全面性等。

    主动向他人提需求，是一种架构能力的体现，从而影响开发、需求，甚至其他用户、市场部门为测试部门服务。测试架构设计，需重视过程，它是个不断发展的过 程。架构必须由经验丰富的设计人员设计，很大程度上依赖于过去项目的成功与失败的经验。但是正因世界上万事万物都在不停地发展变化着，软件开发的方法、模 式、具体项目的要求也不同。随着过程中遇到问题的不同，需要做出快速响应，并进行合适的调整，从而提高架构的应用性，丰富它的内涵。提升它应用的高度与广 度，为它画上更大的外延，这也是符合事物的发展规律的。

本文节选自《软件测试之魂：核心测试设计精解（第2版）》一书

肖利琼著

电子工业出版社出版