我的测试用例设计实践(1)

    前期写了一个关于用例优化的一点经验,见测试用例优化和bug提交的一点经验。但显得空洞,没有实践性。因此根据目前所做的项目进行一些举例,把这个过程具体出来。欢迎大神出来指点和分享经验。

1、测试用例目录:
采用树状结构,一般不超过3级 我的测试用例设计实践(1)_第1张图片
         项目1、项目2也一般为目录,用excel管理用例为列,那么前面两级树一般都是文件夹,二级模块名称一般为excel文件名,可以根据具体项目的层级深度进行划分,最好提前做好规划,否则模块越多越容易混乱。
2、测试用例设计:
(1)方式1 详细型
Mode(子模块名)
TestCase Name
(用例名)
Summary
(摘要)
Preconditions
(预置条件)
setps(步骤)
expectedresults
(预期结果)
result
(执行结果)
keywords
(关键字)
importance
(优先级)
status
(状态)
execution
(执行方式)
用连接线‘-’连接模块
条件-功能点
视情况简
要描述测
试目的或
特殊原因
前提条件
1、步骤
2、步骤
1、结果
2、结果
 
冒烟
功能
场景
UI
流程
1、重要
2、一般
3、次要
1、未评审
2、已评审
1、手工
2、自动化

         这种方式是传统的用例设计方式,包含了步骤、结果等很多详细信息。每个公司大同小异,不多说了,给你一个眼神自己体会。
优点:步骤、结果、条件等信息非常详细;适合变化不频繁的项目(如V模型项目组);
缺点:设计和执行用例比较耗费时间。

(2)方式2 名称型用例
Mode(子模块名)
TestCase Name
(用例名)
result
(执行结果)
用连接线‘-’连接模块
条件-页面-操作-结果
页面-条件-操作-结果
 
这是我在项目实践中总结出来的一种方式。说一下产生的背景,公司是做自有产品的互联网公司,当时接手的项目比较大,在不断的版本迭代中我们用例维护已经达到5000条以上,当时搭建了testlink进行用例管理,采取的是方式1的设计方式。但是产品需求也是频繁变更,测试部的工程师们已是非常痛苦,大领导找到我想办法,然后就有了这种方式。
这是通过用例名称直接执行测试的方式,但对用例名称的设计要讲究技巧,这样才能让执行人员一眼就看出用例要测什么怎么测。我们通过统计计算,执行和设计用例的效率提高约30%。大大缩短了执行时间。目前这种方式已经在多个项目中进行了推广执行。
优点:执行效率高,适合需求变更频繁的项目;能根据测试点,快速修改相关用例;执行效率会随人员对系统的熟悉程度的提高而增加;
缺点:对设计用例的人员的思维及对项目业务的熟悉程度有更高要求;对语言的使用及归纳总结能力有要求;当多个人同时设计一个项目的用例时需要有一致性。
(3)方式3 图型用例
我的测试用例设计实践(1)_第2张图片
这是不少人都用过的思维导图,这个想必大家都不陌生。这是当时做出方式2时的备选方案,这里为什么提到它,是因为,我们发现结合方式2和方式3,可以发挥很大的能量,非常适合快速迭代的小项目。目前公司有个以接单方式运行的中小项目正在使用这种用例设计方式。能快速执行。
优点:很直观,简单清晰。执行效率与方式2不分上下。
缺点:不方便统计,这点非常深刻,做测试报告的时候通过率这块比较头疼。


    下一节将讲一下用例设计的思路和格式方面的内容。欢迎交流。











你可能感兴趣的:(软件测试)