2.2.5　设计用例框架

这里的设计用例框架指的就是测试框架。那么，我们是否可以用开发的思想来解决测试的问题呢？当然，目前已经有了相关的实践，比如，自动化测试思想，从线性结构到数据分离、再到面向对象这一系列的演变过程，已经承载了开发的思想。“用例即代码”，对于测试人员来说，用例是测试思维的具体实现，如果与开发进行类比，“用例库”就是测试的核心代码库、测试思维的承载库。那么如何才能有效地管理用例库呢？如何才能提高撰写测试用例的效率呢？如何才能更高效地维护测试用例呢？

由于我们的客户主要是各大企业，因此面向一般客户的结构设计是无法满足需求的。企业的各种定制化需求比较多，不同的企业还存在不同的定制逻辑，如果按照传统的模式设计测试用例，那么很多定制逻辑的测试用例都会被埋没，最终会出现漏测或者重复撰写测试用例的情况。

领域驱动设计（Domain Driven Design，DDD）的概念出自著名建模专家Eric Evans于2004年出版的图书Domain-Driven Design：Tackling Complexity in the Heart of Software（《领域驱动设计—软件核心复杂性应对之道》）。领域设计一般分为两个阶段：第一，以一种领域内通用的语言作为交流工具，在不断交流的过程中发现一些领域概念，然后将其设计成领域模型；第二，由领域模型驱动软件设计，用代码来表现该领域模型。领域模型只反映业务，与任何技术实现都无关。

那么，我们是否能将每个业务领域都抽象成一个业务模型呢。每个定制的逻辑都可以组装成一个最小的原子，我们可以根据不同的企业和业务需求对定制逻辑进行组装，供我们需要的时候直接使用。

DDD的思想并不能完全地引入领域能力的概念，其彻底颠覆了原来的模块化思想。企业订餐还处于成长期，以业务需求为主，目前还未全面落实领域能力的概念，如果仅仅是为了测试方便来改变测试用例沉淀的框架则是有风险的，综合考虑并结合模块化思想，我们的最终设计是对两种思想进行组合。

如图2-8所示的是DDD思想用例设计框架效果图，是一个初略版本，包含基础层、渠道层和应用层。其中，基础层（类似于原子层的概念）是按照领域能力的概念来划分模块的，比如基础领域、供给交易和财务等模块。每个模块有对应的功能用例，如果存在特殊的逻辑，其中的模块封装就会分在这个模块下，但是要以原子的类型存在，并且必须保证容易识别，以方便日后自己或者其他同事在渠道层进行复用，针对应用层，用例层如果对企业采用隔离的方式进行维护，则这种做法是非常不可取的，这里主要针对存在特殊定制逻辑的企业进行业务功能组合，对于具有公共需求的企业，使用标准版本即可。

图2-8　DDD思想用例设计框架效果

测试人员在进行测试的时候，可能会经历这样的场景：感觉某个案例不是测试用例中的，但是突然会下意识地认为这种场景可能存在问题，然后通过测试发现其果然存在问题。如何让这种潜意识中的感觉沉淀下来并变成可复制的方法呢？笔者认为最好的办法就是多思考、多总结、多复盘自己的用例，让这种思考从片断性的变成可持续性的。

测试用例的设计也是一个可持续的过程，并不是设计完成且通过评审后就不更新了，而是一个不断补充的过程。测试用例的质量可以反映出测试人员的测试思维，如果没有事后的不断复盘，测试用例就不会不断地丰富和更新，曾经的测试用例就会下沉，而这显然不是我们想要的结果。

针对测试用例进行复盘也很重要。如果将测试人员的测试用例类比为开发人员的代码，那么我们需要经常扫描测试用例中存在的问题，然后根据线上问题以及平时的思考来丰富自己的用例库。