测试用例设计工作本身是一个很难直接定量的工作，也不可能像开发代码一样，只要编译通过可执行认为完成了任务。那么在测试用例设计过程中，我们如何才能促进测试用例设计水平的提高呢？测试用例的设计和编写基本上只有依靠测试工程师自己精益求精的态度才能保证测试用例设计的质量。测试人员自身精益求精的态度，不但影响着测试用例的设计质量，而且直接影响着测试人员之间测试水平的高低。
在设计测试用例时，精益求精的精神需要我们在完成每一个功能测试点的基本测试方法设计后，再继续投入时间和大脑，并继续发散思维，在基本测试方法的基础上多写出一两倍的测试方法，希望所设计的用例能发现更多的bug，使测试的质量取得更好的效果。有你会发现正是这些多写出的测试方法更容易发现bug，帮助测试人员提高自己绩效的同时得到测试的乐趣。因为基本的应用模式，90%的人都会比较容易地想到和覆盖到；而质量提升的后10%，则可能只有很少的人，也许是10%的人才能去实现和达到。所以当我们在进行功能测试的测试用例设计时，每多想一个测试方法，越接近99%的质量目标。

案例

一个即时通信产品的服务器与客户端通信功能模块的测试用例

基本测试要求：服务器与客户端之间传送文本信息的功能测试（不包括压力测试和性能测试）。

大多数人很容易想到如下测试方法：

（1）服务器向客户端发送一段文字，如果客户端能收到完整的信息，则验证通过。

（2）客户端向服务器发送一段文字，如果服务器端能收到完整的信息，则验证通过。

倘若只是进行基本的通信功能验证，好像如上两个测试方法已经覆盖了服务器与客户端通信的全部功能。可是，如果我们能追求测试用例设计的精益求精，则该功能的测试用例还可以再进行如下补充。

测试策略1--测试数据集

服务器与客户端通信的测试数据分为：全中文（不同编码格式）、英文、日文、中英文+数字+其他符号（@、#、!、～、&等）的组合、以数字及各类符号作为传送信息的后一个字符。

以服务器能输入字符信息的大数量为依据，输入一个大化的数据，判断客户端能否完整显示。

以客户端能输入字符信息的大数量为依据，输入一个大化的数据，判断服务器能否完整显示。

应用测试策略1，服务器端与客户端1:1同时进行双向通信。

应用测试策略1，服务器端与客户端1:n同时进行双向通信。

应用测试策略1，服务器端与客户端n:1同时进行双向通信。

测试策略2--临界状态测试

在服务器和客户端同时发送空数据信息给对方。

在服务器和客户端同时发送满数据信息给对方。

在服务器和客户端启动过程中，分别向对方发送空信息、满信息。

测试策略3--异常处理

模拟双向数据传输时，传输过程中不断发生传输中断和恢复，服务器和客户端不发生不合理的现象。

数据发送瞬间，接收端发生意外关闭、正常关闭或接收端重启，是否服务器和客户端不发生异常，接收端能正常接收完整的发送信息。

在对端软件未启动和传输通信不通时，如果数据发送失败，发送方进行合理处理。

测试策略4--长时间工作

通过转换为自动化测试的方式，将测试策略1、测试策略2和测试策略3按先后顺序循环执行多次或10小时以上，寻找测试策略1、测试策略2和测试策略3所能覆盖的逻辑处理代码中是否有内存泄漏的情况。

到目前为止，我们已在开始的测试设计基础上进行了很多的扩展。那么我们现在是否还可以有新的测试策略来进一步提高测试用例的质量呢？

测试策略5--模拟资源紧张情况下的测试

长时间（10小时以上）同步模拟服务器和客户端在各自接收端口和发送端口同时受到网络攻击，在有限的通信系统资源紧张的情况下是否还能进行正常的文本通信，而不出现异常。

测试策略6--真实环境测试

将服务器和客户端挂在Internet上进行真实环境的测试，验证是否会有在真实环境应用中我们未想到的测试情形。

我们现在还能继续设计新的测试策略吗？只要你坚信测试无止境，坚持凡事精益求精，向自己的思维潜力挑战，肯定还可以设计出新的测试策略。

笔者于是在前面已有的测试策略的基础上又有新的突破，秉承对功能测试质量精益求精的态度，继续对该模块进行测试方法的挖掘。

测试策略7--安全性测试

服务器和客户端在通信过程中进行安全性测试。当两端正在持续正常通信过程中，同时启动对服务器和客户端的各类安全性测试攻击。例如：通过向接收端进行伪造的源IP数据攻击；向接收端发送一些畸形的数据文件格式；向接收端发送一些错误的协议报文等方式，来判断接收端是否会出现异常。

后限于笔者对即时通信软件客户端与服务器通信测试的有限功力，这个功能点的测试设计先到此为止。希望通过这个案例如何进行精益求精设计的过程，来让读者体会"精益求精"对于提升测试用例设计水平的意义和价值。读者如果感兴趣，还可以在此基础上提出更多好的测试策略，不断完善这个案例的测试用例设计。

测试用例设计的精益求精除了多创造测试方法外，还有另一个很重要的领域--在测试用例设计规范上追求精益求精。笔者曾见过不少测试用例由于写得过于草率和简单，导致执行测试的人在工作时压力非常大，需要花费很大的精力和时间来啃测试用例中描述的真实含义。请大家不要误认为这只是因为我们中国测试起步晚，才有这样的现象。笔者曾见过两家欧美电信设备公司老外工程师写的测试用例，其测试方法过于简单，测试步骤描述基本没有，基本上每个执行这些测试用例的中国工程师都叫苦连天。

你说这些欧美企业没有规范的流程吗？可他们是CMMI5（软件能力成熟度模型集成模型5级）都过了的，这些测试用例也是经过了每一个需要评审的流程才正式进入测试用例库的。那为什么这些外国人写的用例方法如此简单？因为测试流程和测试规范只关注测试用例的骨架是否完成，而附着在骨架上的肌肉状况，则很难由流程来规范和考评。这样有的老外偷懒，用一句简单的句子描述完了一个测试方法，给后来者带来了极大的痛苦。

据笔者所知，后来在这两家欧美企业的中国工程师一改他们的老外同事留下的弊病，在写测试方法时，尽量做到非常详细的文字描述，并尽可能地把所有的操作步骤和命令都补充在对应的测试步骤后面。使用这种精益求精的态度写出的测试用例，完全可以让任何一位测试用例执行者只看一遍测试用例即可完成测试用例的执行。测试用例设计工程师通过自己多付出些时间来完善和丰富测试用例的描述，不但大大提高了未来测试用例执行的效率，而且为公司节省了时间和成本。