测试用例及其自动化实现的管理

我最近在公司做测试用例的设计和开发，有一些感受，拿了和大家分享一下。

我发现大家对测试用例是有不同理解的，而深藏在背后的原因就是“自动化”。自动化程度低，或者说是手工测试，测试用例就是文字的描述（测试使用的数据或者文件，测试的过程，期望的结果）。如果自动化程度高，测试用例就是一些测试脚本。当然，我们如果使用了向Junit一样的自动化框架后，测试用例就变成了一个个的Java类。

不同理解没啥不好呀？！那是对于一个人来说，同时那也是对于一个人做多件事情来说。大家都知道测试人员要写测试计划，要写测试用例，要执行测试，写报告。但是如果这些工作由不同的人来做该怎么办呢？如果这些做事情的人不停的更换该怎么办呢？如果公司昨天还是手工执行，今天要逐步实现自动化该怎么办呢？

测试用例的定义或许会解决部分问题。

那么，该如何给测试用例下一个定义？我的思路就是抽象。我的方法就是将测试用例的定义和它的实现分开。这里我结合一些参考文献，给出了我对这些概念的不同观点：

System Under Test(SUT): Refers to a system that is being tested for correct operation. (被测试的对象)

Test Case: A high level concept, a set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. (测试输入、前置条件和期望结果的集合)

Test Suite: A high level concept, grouping together a collection of test cases related by what they are intended to test the behavīor of a SUT. (为了达到一定目的的测试用例的集合)

Test Implementation: Actual implementation of a test case.(测试用例的实际实现)

Test Harness : A program or test tool used to execute a tests. (测试执行的程序或者工具)

Test Framework: A software framework that can be reused by different automated test implementation.(能够被不同的测试实现重用的软件框架)

Test scrīpt: Commonly used to refer to the instructions for a particular test that will be carried out by an Test Harness(能够被test harness执行的命令集合).

Test Procedure: A document providing detailed instructions for the execution of a test implementation. (对测试执行的描述)

测试用例是概念上的定义，逻辑的。测试实现是具体的。测试框架啦，测试脚本啦，只不过是测试实现的软件方案罢了。这就和面向对象技术中的OOD和OOP的关系近似。OOD中有类，OOP中也有类。两个类是不等价的。这又和数据库的逻辑模型和物理模型一样，一个叫实体（层次模型中），一个叫表（数据库中）。

为啥要把简单的问题搞复杂了？这是测试分工的需要。测试人员可以进一步细分：测试设计人员，测试开发人员和测试执行人员。为了让不同的测试人员高效的协作，必须给每种角色的人提供简单的接口，将具体的细节隐藏。基于上面定义的概念，可以让这些不同的角色做有效的沟通：

1.Test designer design Test Suites and Test Cases according to test plan.

2.Test  developer implement Test Cases using different methods  and technology under different platforms.

    2.1.Implement Test Procedure if it can only be manually executed.

    2.2.Implement Test Harness if it can be executed automatically.

           2.2.1.Implement Test scrīpt to refactor Test Harness if some things can be parameterized.

           2.2.2.Implement or use Test Framework to refactor Test Harness.

3.Test executor select proper Test Suites according to different criteria.

4.Test executor execute tests by following Test Procedure or running  Test Harness with Test scrīpt.

测试设计人员需要提供对测试用例的说明，告诉测试的目的。他不用关心测试用例是如何被实现的，他也不用关心测试用例被谁在哪一天执行了，它只需考虑使用什么方法才能更加有效的发现bug。测试实现人员需要通过理解详细的测试用例说明，使用恰当的自动的方法和技术实现测试用例。它不用关心这些测试用例的执行效果，它他们要对执行的效率和代价负责。而测试执行者，不需要关心为啥要做这些测试，测试是如何被实现的，它只需要输入简单的查询条件生成所有执行的文字步骤，并完成测试任务就行了。

听起来挺好的呀，可没有功能强大的测试管理工具的支持是无法达到这种程度的。但是不管怎么说，这是测试分工的必然趋势。唯一可以做的就是武装好自己，等待随时可能到来的改革吧！