又和leader闹翻了~被批中

pktest

wintersea

看了jackie说得，受益匪浅
但是如何判断是同类的测试用例，能够复用同一个测试过程？

bitter

wgfxman, 我不太理解什么叫"同类用例"?  你是说类似呢, 还是同一功能呢?

就你的帖子里说的:"同样是输入合法性的校验，为什么不能合并写？",  如果是说系统的两个不同功能, 同样都有输入合法性校验的话, 假如你能确定合法性校验的功能都是同一部分代码在同样的上下文(context)中处理的, 而且你的目的只是检查合法性校验的功能,那么你就可以只写一部分.

但是在这种情况下, 你所使用的就不再是黑盒技术, 因为系统的内部对你来说不再是未知的.

至于覆盖率, 我想你没有说明是哪种覆盖率, 如果是需求覆盖率,那么很简单, 每一条需求都要有对应的测试用例(一个或多个), 如果是代码覆盖率(测试执行了多少代码),就复杂的多.

一般来说, 黑盒测试又被称做基于功能的测试, 设计测试用例时要参照功能规格说明,
每一条功能都要有自己的测试用例.  不管两个功能有多么的相似, 也要有各自独立的测试用例, 因为系统是一个黑盒子, 没法知道是怎么处理的.  两个功能可能有同样的输入, 但是一定不会有同样的处理. 否则开发者就应该把他们合并为一个功能.

ax2004

非常支持楼上所说的话: "每一条功能都要有自己的测试用例.  不管两个功能有多么的相似, 也要有各自独立的测试用例, 因为系统是一个黑盒子, 没法知道是怎么处理的.  两个功能可能有同样的输入, 但是一定不会有同样的处理. 否则开发者就应该把他们合并为一个功能."

sanss

我不是很同意一把钥匙开一把锁的说法，通常单一的功能在测试后期BUG不多，但几个功能集成后BUG就会凸显出来，有些BUG需要几把锁组合后才能出现的，而这种BUG是非常之多的，所以分类的同时要考虑好组合

wintersea

同意楼上的楼上的说法，在测试的时候一定要为每一个单一的功能写测试用例
然后再考虑多个单一的功能有组合的情况。

Nio

如果影响了代码覆盖率，应该不会是同种类型的测试用例吧？

浅草

如果测试一个信息输入页面，对输入框要判断输入的合法性，如果有很多这样的页面，每个页面有很多的输入框，是否需要对每个输入框的非法输入都设计多个用例。这样的用例能否合并？

[ Last edited by 浅草 on 2004-12-14 at 15:37 ]

wintersea

在写测试用例的时候，对于这个问题我也很疑惑，怎么没人回答问题呢？

snake

Originally posted by 浅草 at 2004-12-14 03:35 PM:
如果测试一个信息输入页面，对输入框要判断输入的合法性，如果有很多这样的页面，每个页面有很多的输入框，是否需要对每个输入框的非法输入都设计多个用例。这样的用例能否合并？

[ Last edited by 浅草 on  ...

我个人觉得浅草说的这样的用例还是不合并的为好，你可以用等价类划分的方法构造用例。
因为每个输入框的非法输入都可能会导致不同的预期输出，如果合并了，那么有一个输入方式导致的输出结果异常，则整个测试用例都执行失败了，这是不合适的。
这样，测试用例的粒度太大了，不能说明当前被测试软件的质量情况。

wangying1982_0

我现在测关于专业用于网吧的一个信息平台，这个项目没有相关的文档，不要说测试用例，连用户需求都没有，测试也没有目标。每天大多数时间都在等开发那边能提供新的版本测试，请大家帮帮忙，想想我怎么样能改善目前这种状况。

ghost

这样大家也不用只看你的片面之词来指则他人了。
他的考虑是什么呀？你问过了吗？

snake

Originally posted by wangying1982_0 at 2004-12-18 01:01 PM:
我现在测关于专业用于网吧的一个信息平台，这个项目没有相关的文档，不要说测试用例，连用户需求都没有，测试也没有目标。每天大多数时间都在等开发那边能提供新的版本测试，请大家帮帮忙，想想我怎么样能改善目 ...

wangying1982_0，这个是软件测试目前存在的比较普遍的问题，公司刚成立测试部的时候开发部也是没有需求规格说明文档的，甚至有的项目是我写的需求文档（因为老板也有足够的重视），你也可以利用“在等开发那边能提供新的版本的每天大多数的时间”来思考你对你的测试有价值的需求是什么，并去找他们提出很多问题，当你的问题能够一针见血的时候，你就会发现你的测试有效性会增加，测试的目标是你自己定给自己的，而不要等着别人给你，我不太擅长言语，如果有什么词不达意的地方或者与你的想法有出入，请回帖大家讨论

[ Last edited by snake on 2004-12-20 at 17:59 ]

happymei

Originally posted by jackei at 2004-9-12 12:02 AM:
测试用例：
序号        操作过程描述
1        输入用户名。
2        输入密码。
3        确认登录。

序号        用户名                        密码        预期结果
1        正确的用户名        正确的密码        登录到系统并转到系统主界面
2        正确的用户名        错误的密 ...

偶还是喜欢这种写测试用例的方式，简单明了。测试步骤跟测试数据分离，比较方便管理！

snake

的确是简洁明了啊，可惜这样的用例在我们公司无法通过专家评审的，理论和实践之间我还要继续寻找最佳的结合点

walker_lai

可以尝试下用因果图法来确定输入的条件、动作和输出的结果来确定一条测试上应该叫做规则的东西，在其中，如果条件、动作不一样，但是结果一样，是不是可以考虑合并输入的条件、动作！

scarlet

同类用例当然可以合并，这样有利于以后的用例维护

zzytion

等价分析法也不能范围太广,细致可能更容易发现更多的BUG