我们所熟知的传统黑盒测试用例编写起来比较复杂，在大型信息系统产品快节奏的迭代项目、敏捷项目、耦合度高的产品中，传统的用例编写方法明显滞后或带来较多冗余的工作量，它使测试设计人员过度关注测试用例步骤的编写、修改、再修改，甚至根据现有测试用例的设计原则，为保证唯一性与可追溯性，会出现同一条测试用例经过多人执行永远得到相同的结果，这让人不得不想到另一个具有挑战性的词汇：自动化测试。这种传统的用例设计方式，一次编写，多人运行相同的结果，没有思考的过程，严重阻碍了测试执行人员或者相关人员的创新意识，并且加大了他们的工作量。这种方式问题很多也会不可杜绝的，问题解决的过程也是测试用例设计发展的过程。下面我们从传统的测试用例的定义和用例设计所包含的内容说起。

测试用例定义：测试用例（Test Case）通俗一点来讲就是编制一组测试测试输入、执行条件、预期结果，去完成对某个特定需求或目标的测试。

完整的测试用例通常包括：

●测试用例的编号

●测试日期

●测试用例设计人员和测试人员

●测试用例的优先级

●测试标题

●测试目标

●测试环境

●测试数据/动作

●测试的操作步骤

●测试预期的结果

根据上面的内容，我们甚至编写了一个非常标准的测试用例设计模板，如图7-1所示。

根据以上的定义和模板，我们经历了N多项目之后，发现工作起来已经越离越力不从心。因为在现在软件行业的发展和快节奏下，任何一个测试项目，都需要经过高强度、快速的迭代，而每次迭代设计编写的测试用例都包含所有的测试要素，遇到项目与任何丁点的变更，测试步骤必须重新修改完善，在这种高度紧张以及多人更改测试用例之后，感觉现在的测试用例越来越冗余，甚至有些鸡肋。根据上述所发现的问题，重新定义了测试用例模板，如图7-2所示，弊端依然十分明显。

在上述几个阶段，虽然对用例设计或编写方法进行适当改革，提高了快速响应当今软件行业交付节奏的能力和对产品质量的控制能力，并有利于项目过程中的用例评审，但是依然存在下列问题：

1）测试用例里面写死了数据、业务步骤。

不同测试人员都按照具体步骤来测试，就好比车载导航，变成了“导航测试”了，如果需要测试其他路径、其他业务呢？有些测试人员就再复制一个用例出来，稍微改一个数据，造成用力例泛滥。

2）测试用例依然没有思考的过程。

负责第一次编写的测试人员有思考，但负责执行的测试人员，没有再有再继续跟研发人员交互测试过程，没有更深入的思考，而是仅仅按照用例执行，那这种效果等于走过场。

3）遇到十几个、甚至几十个步骤的功能，用例编写耗时。

例如：开启路由器设备，通过浏览器正确登录到管理界面。这些其实是不必要展示的的步骤，做测试就要熟悉业务，测试人员更加关注的应该是开发是否做了正确的功能，功能是否做了正确的事情，因为测试人员的时间是有限的，不要陷入过分的步骤细节里面去深究，要把重点思路放在运用哪些测试方法、如何组合更加有效的覆盖率和更高的测试场景中。