sy070904 发表于 2013-7-11 23:38:12

场景式用例编写的疑惑

各位前辈,最近遇到用例设计的问题,请帮忙指点一下。
之前我们的用例编写是以功能模块来划分的,每个用例只测试一个小功能点,用例是写在TD上的,每个用例的测试目的很明确,一般来说只有一个测试点。
最近领导想让我们换用场景方式编写。我试着用场景方式编写,但写出来的用例缺感觉不像那么回事,不方便执行,每个场景中有大堆用例,场景中的步骤感觉也是一个用例,这样的场景不好跟踪问题、不便统计执行效率。
我说下我们的某个功能:
用户使用不同的认证方式登录,分配一个虚拟的pc,且自动进入到该pc中。
输入部分:
分配的pc可以是工作组环境A1,也可以是域环境A2
用户的用户名密码有多种多样的,要覆盖各种不同的用户名密码情况B1 B2 B3 B4
认证方式有五种C1 C2 C3 C4
如果pc是工作组环境,则需要额外配置该pc的一个管理员账号及密码,用户登录后,使用该管理员账号及用户自己的密码登录进pc(会先自动修改管理员密码为用户自己的密码)D1 D2 D3 D4
如果pc是域环境,则需要额外配置域的域名、域管理员账号密码信息,用户登录后,使用用户的账号密码登录进pc(此时的用户就是域中的账号)E1 E2 E3


这么多不同的输入条件该怎么组用例呢?实际上还有其他一些细小的输入条件,头痛啊

丝路 发表于 2013-7-15 09:58:10

可以写两个测试用例,分别为《工作组环境A1下的登陆_测试用例》,《域环境A2下的登陆_测试用例》

如果用户的用户名密码会导致不同的认证方式,A1下的场景有五个或者更多。至少要覆盖B1 B2 B3 B4还有管理员登陆的情况,在场景中描述这些数据及他们会产出的结果C1 C2 C3 C4。可以通过画图的方式分析是否还有其他分支流。那么像这个场景中,会存在很多测试点:比如说文本框的验证、按钮的验证。根据对测试用例粒度的定义,去决定测试点写到什么程度。但是究其根源,从功能和流程上,已经达到了最大程度的覆盖。文本框啊验证点啊神马的都是测试人员必备的一些基本素质,即便不写这么细,我们默认是会测试到的!

域环境A2的测试用例设计方式同上。

sy070904 发表于 2013-7-20 16:34:35

谢谢丝路的提醒,明白你的意思了。
可能是因为老的用例编写思路深深地印在了脑海里,所以总写不出满意的场景用例,不过我相信,这得慢慢地改变思路,得有个过程。
页: [1]
查看完整版本: 场景式用例编写的疑惑