可重复使用的测试用例该从哪些方面来考虑呢

大妮 · 发表于 2005-8-21 20:37:37

最近在编写测试用例，觉得其实每个项目的用例有很多是类似的，而每次都要重新编写测试用例，每次编写要浪费很多时间，考虑是否可以用通用的测试用例来解决呢？

大家谈谈自己有什么想法

Tender · 发表于 2005-8-22 08:53:05

通用的测试用例？我理解是不是就是类似用例模板呢？我觉得可以试试。比如登陆这个功能，几乎每个产品都会有，那么可以设计这样一个模板，凡是登陆的功能都按照这样一个模板做就OK了。但是一些产品自身的功能还是应该自行设计用例。我也知道，写用例是个苦差事，可从另一方面讲，如果你自己不熟悉产品的功能，会让你写吗？这是领导对你肯定嘛！

大妮 · 发表于 2005-8-22 09:36:30

Tender真看的起我，老板不让我写让谁写呢，公司只有我一个测试啊，我哭～～～

只是看到开发人员，在功能相似时有类或模块可以直接调用，所以在想，对开发人员直接调用的模块，其测试用例应该也是相同的。

功能是相同的，可是不同项目之间的数据应该是不同的，困难的就是数据：（

rien2128 · 发表于 2005-8-22 10:43:10

既然相同的话，那有一个方法就是最简单的，COPY！

迎风 · 发表于 2005-8-22 11:17:39

测试用例当然是可以复用的，它的配置管理应该和被测件的基线管理相对应，这样在你回归测试（无论是手工还是半自动）时工作量就会大大减少了。对于相似测试特征的不同项目，则可以象Tender兄说的那样，建立起相应的用例类模板库，其中先包含验证普通的基本功能点，待用例重新复用时再根据不同项目测试粒度与特征的不同将其特殊化（其实就是面向对象派生的思想啦），这样也就在一定程度上避免了“重新制造轮子”的重复工作。当然，上面讲的思路与机制不是一朝一夕就能建立起来并做到与所在的软件环境无缝衔接的，它必须通过项目团队中大家的不懈配合、充分支持并不断完善才能达到～～

大妮 · 发表于 2005-8-22 12:07:31

"当然，上面讲的思路与机制不是一朝一夕就能建立起来并做到与所在的软件环境无缝衔接的，它必须通过项目团队中大家的不懈配合、充分支持并不断完善才能达到～～"

看来我需要换公司了～～～～:|

Tender · 发表于 2005-8-22 12:22:42

楼主，怎么公司就你一个测试人员？不会吧。这样的话，你岂不是什么都要做！看开，你应该到大公司去了。支持跳槽！我推荐你去微软亚洲工程院，里面的测试团队人比较多，而且比较规范！

大妮 · 发表于 2005-8-22 14:18:13

总觉得自己现在的经验还是太少，小公司也有小公司的好处的，因为我自己全包，所以我的经验能成倍增加，比如这个测试用例的重复应用，如果我仅仅是个测试执行者，就不会想到这个问题。。。
谢谢Tender的建议，等偶的经验值再增多些，一定跳槽 ^_^

迎风 · 发表于 2005-8-22 15:01:38

支持楼上的朋友这个观点，踏实的学习与提高，只有真正学会把握现在的朋友才能更好的开拓明天～～

free_xiaoyu · 发表于 2005-9-12 17:52:46

学习。。。。

takiro · 发表于 2005-9-12 19:36:06

楼上的有个地方说的好：要根据自身行业和产品的特点来建立用例库无论是针对之后重复性的用例设计或是测试自动化都是有很好的借鉴意义的
不过大家最常见的可能就是一个页面很多内容步骤几乎差不多但根据一些测试方法所驱动设计的数据组合却有很多这样的是比较多的还有就是一个业务流或是数据流模块间（页面间）的相互作用

zhangmike · 发表于 2005-9-28 04:02:45

楼主，一个测试用例包含多种情况，只会给你带来无穷麻烦。
不要追求通用测试用例。
这不符合测试执行的规律。

所以前文提到的Copy /past方法，是个不错的方案。

bigmeg · 发表于 2005-10-18 14:45:41

一直学习中

free_xiaoyu · 发表于 2005-10-20 11:45:33

在应用软件测试用例中，像什么新增、删除、修改、复制粘贴、所有、刷新、统计这些的测试用例是不是也可以进行管理

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 可重复使用的测试用例该从哪些方面来考虑呢

相关帖子

站长推荐 /1