测试立方体TestCube - 以证券期货行业测试规范为例

本文借助于证券期货行业测试规范，介绍了测试立方体TestCube的这个测试策略模型。在原先测试级别和测试类型的基础上，加上业务优先级，从而形成所谓的测试立方体，以指导研发组织形成务实、经济且高效的测试策略，达成最大的投入产出比。

测试服务菜单TaaS

稍微成熟一点的测试团队，在建立测试体系的过程中，通过对价值流的梳理，通常都会将测试活动划分为各个阶段Test Phase或者是各种级别Test Level,再结合软件质量和团队能力所形成的测试类型，最终可以梳理出来一个二维表格，类似一个测试服务菜单，以安排测试团队在项目的不同交付阶段的测试活动，笔者将其称为TaaS 测试即服务。

例如，证监会曾经在2019年9月发布的《证券期货业软件测试规范JR/T 0175—2019》中，提供了如下的二维表，

《规范》明确，“根据软件生命周期和测试周期自然形成的阶段，测试级别包含单元测试、集成测试、系统测试、 系统集成测试、验收测试。待上线系统应经过五个测试级别及全市场测试之后，才能达到上线要求，允许上线。“

“根据行业机构角色及软件产品来源的不同，明确各机构的测试职责范围，以指导行业机构履行职责、把控软件质量”

考虑团队职能的测试立方体

如果要在测试类型和测试级别两个维度的基础上，再新增一个维度，如团队组织的测试资源投入，考虑哪些组织或角色在不同级别和不同类型上的测试活动，那么就形成了类似以下的的两张二维表，

上表指明了在不同级别级别上的测试责任主体。

类似的，也可以就测试类型和测试资源形成如下的二维表。

整合起来之后，就形成了第一个测试立方体，也就是测试级别-测试类型-测试资源的三维测试立方体。

在实践中，康威定律说软件架构是组织架构在软件架构上的投射。

软件交付生命周期中各阶级别、阶段划分背后也其实是各方职责的划分，也就是测试流程其实体现的是组织架构和各方职责的边界。

例如说单元测试、集成测试，基本上是由开发团队完成，系统测试。系统集成测试，则由专职的测试团队或者是测试岗位人员来实施。而验收测试，则由需求方或者用户代表来完成。这样的话，测试级别或者测试阶段，其实已经暗含了团队职责划分，也就是这个测试立方体，其实可以退化成为原先的测试服务菜单这样的二维表。

那对于小型测试团队或者固定负责某个或者若干个微服务的研发团队来讲。上述二维的测试服务菜单基本上就够用了，能够把团队的测试活动比较好地进行一个组织。

考虑业务优先级的测试立方体TestCube

资源永远是有限的，测试资源也是如此。怎么把有限的资源投入到最有价值的活动当中产生最高高的收益。这是基于风险的测试策略出发点，也是通常大家会在测试实践活动中所使用的一种非常务实的测试策略，追求经济效益的最大化，或者是风险消除或者规避的最大化，也就是测试效用的最大化。这种情况下，引入另外一个维度的考量，也就是业务的视角。

当给定一个研发任务或者进入一个测试项目之后啊，利用这个测试立方体就可以根据业务、级别和类型来策划相关的测试活动，以有限但合理的测试投入来达成预先设定的质量目标。

例如在前述这个规范当中，就提供了以下的业务分类。

该规范根据发生故障之后的影响，将证券期货行业的系统划分成了A\B\C三类。根据此类划分，就可以制定不同的测试质量目标。在原先测试级别、测试类型的基础上，再增加业务优先级的维度，就形成了所谓的测试立方体Test Cube。

测试立方体TestCube的论证

首先分别从业务优先级-测试级别以及业务优先级-测试类型这两个平面来论证该测试立方体存在的必要性。

从业务优先级和测试级别的划分上来讲，通常大家所能见到的就是所谓的双模。生产线。或者双态交付模式。传统的核心系统基本上都遵循稳态的交付模式。实验性的项目、面向互联网用户的业务，或者一些边缘的业务系统，通常会采用敏捷交付模式，从而形成了所谓的双模生产线。不同模式的生产线，在考虑业务优先级之后，测试类型的划分可能就不再兼容。因此，业务优先级的维度是必须必要的。

再来看业务优先级与测试类型的关系。通常高优先级的业务也伴随着全面和全高质量的要求。例如证券期货行业中的交易系统来说，各个级别上的性能测试都是必须的，而不仅仅是专职测试团队的职责，更不要说功能测试了。而边缘业务或者探索性的项目，可以甚至只要实施部分必须必要的功能测试，一些非功能要求的可以尽量避免，或者只做一些基础性的验证。

在介绍了测试菜单双模以及分级分类质量要求三个二维平面之后，将测试级别-测试类型-业务优先级这三个维度整合起来，就形成了测试立方体。也就是如下的一张图。

通过这个三维的测试立方体，只要在原先类型和级别所形成的二维平面上，再根据业务的优先级。进行分模分级，也就是形成了所谓的组织级测试策略。

测试资源投入的案例

例如在证券期货行业，大家都会对核心交易系统进行最为充分的测试，投入最大的资源。不仅仅是测试团队要进行系统的、全面的测试。开发团队也往往是一半时间投入在测试，一半时间投入在开发。类似的还有结算系统。在这个策略下，开发测试比往往需要投入1 : 1，甚至1 : 2。因为核心交易类的系统的质量问题所产生的影响或者损失几乎是组织所无法承受的。而一般类的业务系统啊，或者边缘的系统的低级别的系统，那么通常会采取自由人员加外包人员的方式进行测试，甚至由开发人员进行自测，并不投入专门的专职的测试人员。这也是测试立方体在指导测试资源人力资源投入时的一种应用。