如何设计可维护测试用例!

liaoxj

测试用例设计的可维护性，现在大家都很关心，我个人认为重点要把数据、步骤必须分开，类似编码要做好封装和提供多样化的接口。让数据成为一个个结构体，结构体又可以进行多方面的组合！附件中是根据这个想法设计的一个测试用例实例。

投缘

LZ提出的这个问题太实用了！！收下，辛苦哈~~

liaoxj

补充说明：
数据自己为一个实体！
步骤中引这些实体！

暗冷夜空的风

看看先

暗冷夜空的风

LZ也好认真的在写测试用例啊！看了你的用例，结合我自己的测试情况也想说说我的一些想法，若有不合理之处还请冷静地指出哦~

1.数据准备的部分说明数据特征就行，不要写出具体的数字。实际测试时情况往往不能像预想中的那样好。但比较幸运的是数据特征是相同的。这样就不用频繁更新测试数据的内容
2.建议加上需求跟踪矩阵（用例执行记录文档），去掉“实际结果”列，把不对的地方都放在需求跟踪矩阵里。这个矩阵还包括需求更改、用例变更等的记录信息。
3.强调用例“设计”而不是用例“记录”。实际测试的时候往往会发现“啊，这个地方我怎么没想到呢？”之类的事情。实践出真知，我们自己想的东西毕竟有限。因此，我认为测试用例是应该分两个阶段的：用例设计与用例执行记录（同时结合实际情况调整用例设计）
4.操作步骤很详细（记录重现步骤时倒是必须很详细的），但是有强制流程操作的情况。想更有效率的维护用例比较有效的原则是“以不变应万变”。将测试用例设计得像面向对象程序那样就会具有很好的扩展性和适应性。
5.这部分看上去是流程用例设计，那之前的单项功能用例设计有吗？若开发流程不是瀑布式的，而是出于集成测试阶段或采用了迭代开发模式的话，一上来给你测的东西本就不是完整的。若真能按用例写的一旦步骤一失败，后面的就不执行，等修复好了再继续就好了。所以，单功能设计还是要有的。

liaoxj

感谢该同仁提出忠恳的建议！!
我会很冷静的！
同意第二点的建议，其实我们也是我这么做的！
附件只是一个例子，想说明面向对象测试用例设计的好处!
本议题重点还是在讨论设计的问题！

另：最近我写了一份《面向对象的测试用例设计思想》的文章，提交给51tesiting,现在还不知道能否采用，，如果不采用我上传该贴，大家一起讨论！

[ 本帖最后由 liaoxj 于 2009-12-16 11:42 编辑 ]

houjianling

liaoxj 发表于 2009-12-14 16:22
感谢该同仁提出忠恳的建议！!
我会很冷静的！
同意第二点的建议，其实我们也是我这么做的！

请问：面向对象的测试用例设计思想的文章没有找到，可否请教学些下