我们期望什么样的TA？
为什么TA有这么多好处，但是在许多实际项目中，其带来的收益却往往无法让人满意？笔者认为，与其去质疑TA的正确性，不如回到两个根本性问题上：(1) 我们期望什么样的TA? (2) 我们怎么样实现期望的TA？首先，从TA定位的角度回答第一个问题。在软件工程中，测试工作是为提升产品质量而存在的，其自身并不属于软件产品的一部分。同样，所有的TA Case和TA Library均属于辅助性的测试代码，不会发布给用户使用。其存在的价值只在于在软件发布前，尽可能地发现产品软件代码潜在的问题。笔者认为，简单(Simple)、可靠(Reliable)、可维护(Maintainable)和可读(Readable)的TA才是我们所需要的。
简单的TA
一个复杂的系统，往往意味着更多的工作量、更大的投入。而TA的辅助性质，决定了它不可能也不应该过于复杂。而且，简单是可靠、可维护、可读的基础。大道至简。那么，什么样的TA才是一个简单的TA呢？
-
TA测试系统尽可能简单。TA测试系统由被测软件、测试软件(即TA Case + TA Library)，以及运行这些软件所需的硬件设备共同构成。 一个复杂的TA测试系统，其收益往往不会高。这体现在两个方面，当系统复杂时，系统被测软件之外的模块出现问题的概率大大增加。这会严重影响TA的可信度；当系统复杂时，即使通过TA发现了软件问题，但是由于系统中的模块太多，软件问题的定位、解决和验证会花费很大的成本。笔者认为：
TA的收益与TA测试系统的复杂度成反比
为了确保TA的收益，我们的测试系统应该尽可能简单。然而在实践中，结构庞大复杂的TA测试系统却普遍存在。造成这一现象的原因可能有两种。首先，被测软件所处的系统本身就很复杂，体现在外部依赖模块太多，并且模块之间难以解耦。系统设计是否满足”高内聚，低耦合”的原则，直接决定了系统的可测性(Testability)，也间接决定了系统的质量。从测试角度，一个可测性不好的系统，往往需要等到依赖的模块全部开发完成后，才能开始对目标模块进行测试。而此时的测试必然是基于复杂系统的测试。其次，测试人员希望搭建一个与用户应用场景一致的测试环境，以此来保证测试用例的覆盖度。这本身并没有错。覆盖度确实是测试很重要的一个指标。但是，如果这个系统是用来做自动化测试的，则存在问题。软件测试有许多阶段，例如单元测试-组件测试-功能测试-系统测试等，而”接近真实用户环境”只应当是对最后一个阶段，即”系统测试”的要求。根据经验：
软件测试中，随着测试阶段(单元测试-组件测试-功能测试-系统测试)的推进，发现的Bug的解决成本呈指数级增长。
这意味着，测试的资源应该更多地投入到早期测试阶段(单元测试、组件测试、功能测试)，以期更早地发现问题、节省成本。对于系统测试之前的测试阶段，不仅完全没有必要使用真实环境，而且应该在满足测试目的的情况下，尽可能地简化测试环境。
-
TA Library尽可能简单。TA Library直接与被测系统交互，在自动化测试系统中处于中枢地位。TA Library在满足测试要求的情况下，代码量应该越小越好。成熟的测试自动化框架(例如Robot Framework)、强大的高级编程语言(例如Python)，海量的第三方库(例如Python第三方库)，为我们构建TA Library提供了充足的、可信赖的资源。我们应该充分利用已有的资源，快速、低成本地实现TA Library。
-
TA Case尽可能简单。TA Case来源于需求/设计文档，是对验收性测试用例的具体实现。为了保证测试的覆盖度，我们可能需要考虑很多的场景。但就单个场景来说，TA Case不应该做除(1)触发测试步骤(2)验证测试结果之外的事情，并且，不同的Case之间应该实现代码最大程度的复用。TA Case的简洁性，不仅有利于提升自身的稳定性，而且有利于节省后期的维护成本。
可靠的TA
自身的可靠性对于TA至关重要，甚至可以说是TA的生命。可靠性有一个经验主义的衡量标准，即当TA Case失败时，我们有多大程度的自信，能够断定失败一定是由软件Bug(或者某些环境问题)而不是由TA自身造成的？我们应当追求100%的自信度。虽然很难做到，但是我们应当树立这样的目标，并为之努力。只有这样，TA的价值、测试的价值才能够得到充分体现。
可维护的TA
软件维护花费成本，却少有实际价值。TA作为辅助性的软件，其维护成本更应当尽可能降低。在软件的生命周期中，各种各样的变化都可能要求TA Case/TA Library做适配。我们希望TA能够快速响应这种变化，在较短的时间内能够适配完毕。
可读的TA
对于TA Case来说，我们增加了可读性的要求。可读性也有一个简单的衡量标准，那就是阅读TA Case是否像阅读需求文档一样轻松易懂？首先，这是可以做到的。从功能上讲，TA Case是对软件测试步骤的代码实现。测试步骤是用户需求的直接反映，并且通常是顺序执行的，不太可能包含复杂的逻辑。其次，这是应当做到的。TA Case的可读性，能够使得任何有相关专业背景知识的人，都能够很顺利地阅读TA Case和理解TA Case的执行结果，而这对于TA Case的使用和维护都有帮助。
我是肖哥shelwin，一个高质量软件工程实践者和推动者。欢迎扫描下方二维码，添加我的个人公众号测试不将就，获得更多自动化测试, 持续集成, 软件工程实践, Python编程等领域原创文章。
