测试用例设计的误区（原创）

山风寂寂

4、测试用例不应该包含实际的数据；     
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。

对于这点在实际项目中的可操作性，我有很大的疑问。
就我自己目前测试的项目来说，每一个表单的操作都涉及到十几二十个的字段输入域，如果要对每一个输入域建立完整的测试数据用例，还有某些字段间的组合输入情况，那单单一个新建功能就会产生一个庞大的测试用例。而项目时间往往不允许这样做。
这是我一直以来的困惑，目前我们公司的实际做法就是类似于生成指导意义的测试用例，没有具体的测试数据，只关注主要逻辑。所以，在测试执行时，就在很大程度上依赖于执行人员的个人测试素养和经验，具有相当的风险。
书上的理论总看得人热血沸腾，但实际操作时却常常发现有心无力，如何理论实践结合是个难题，很想学习借鉴大家的做法。

jackei

一个完整的测试用例应当是由测试步骤和测试数量这两个不可分割的部分组成的。
在以往提到的测试用例中是否包含测试数据的话题中，可以明确的是在测试步骤中可以不包含测试数据，而将测试数据参数化，然后每个测试用例中应该包含另一个表格，其中对应到步骤中的各项数据。如果出现变更，应当同时维护。

k0c0b0

写的不错，一见地

zibeikehappy

学习学习

Hellen_lyy

我们公司目前在规范开发和测试工作，我在写测试用例的时候写的很详细，但在执行过程中，才发现，原来，花了很长时间完成的测试用例，有的甚至于花了几分中就执行完了。
     楼主说的对，既然是对系统非常熟悉的测试人员执行测试用例，就没必要写得过于详细，写重点的就好。
     感谢楼主！

木乃伊

要覆盖需求真难！
有些需求上没写，但业务上要注意的问题，这就很麻烦！

niceleafage

to  dennis_d:
     把测试过程中测试用例设计所遇到的问题（或者说误区）写的非常客观，本人也是深有体会；对于编写测试用例有时的确很难把握：写的简单吧担心别人看不懂，写的详细吧，感觉比较琐碎，费时；所以想请dennis_d给出一个测试用例编写的比较好的方法，多谢！（如果其他人有好的编写测试用例的心得、经验、方法，请贴出来大家一起共同学习！）

dolphin90

最近想把公司的测试用例库建立起来
真正做的时候才发觉不是那么容易
把测试用例写好难
把测试用例管好更难

dolphin90

最近想把公司的测试用例库建立起来
真正做的时候才发觉不是那么容易
把测试用例写好难
把测试用例管好更难

null2

同感，测试用例不要写了太详细，要留给测试执行人员以发挥的空间。

测试有前途

对第五点测试用例中不需要明显的验证手段；
照楼主说来，那测试用例中是不是要把预期结果写得很详细 方方面面都要照顾到呢？

请楼主赐教

secat

刚写完测试用例，虽然不是很想写，但为了交差还是写完了。
很同意作者的看法，不应该有详细的测试数据，简单描述即可，否则写的太累、维护也太累了。至于验证我是尽可能的写的比较详细，当然不用把能验证的都写出来，把关键的写出来就可以了。例如新增数据，可以去数据库中查询，也可以到其他可以查询该记录的模块查看，能写到根本，可以验证其正确性就可以了。
但是我一直担心我的这种做法能不能得到上级肯定，要求我写，但发现没人理，郁闷啊！俺的口才不好，不知道等他们发现简单时会不会来找我麻烦，我可说不过他们：（

jsfzdd

4、测试用例不应该包含实际的数据；
5、测试用例中不需要明显的验证手段；

对于我们公司不太可能遵守，因为根本就没有正规的测试人员，随便从生产线上拉一批人就测试，对于实际的测试数据要他们自己发挥实在有些牵强，让他们到数据库中使用SQL语句查找更是不可能的了，所以说实践和理论总是有差距的。

sara_li

受益匪浅，谢谢

littleqiang

qiang

SayeWang

顶 不错

nanayulin

我觉得测试用例没必要写那么详细，因为即使对系统不熟，但起码的测试经验还是有的，所以应该可以执行，这样可以减少很多工作量，因为很多项目都是很急的，容不得测试人员写的那么仔细，无奈之下的选择

Amsure

我前几天就遇到很麻烦的问题，我们写的测试脚本跑在自己开发的框架下，提高了测试的效率，但是上面说看不懂，要写文档，最后还补了大批的文档，唉～～～郁闷，其实文档只是个形式上的东西，我们最精髓的脚本没有人看。

jtiger

非常之赞同，接触测试一段时间了，用例的详尽程度是最困扰的事情。

sogoc

4、测试用例不应该包含实际的数据；
这个我觉得楼主有点问题，不应该有实际数据那应该有什么？没实际数据怎么对比BUG的存在呢？