经常有小伙伴留言,问我怎样写好一个测试用例。作为我们部门的测试OG,我认真的做了一下总结,打算今天给大家做一次分享,希望能帮到各位测试新手们。
再分享之前,我认为聊一聊“为什么要写测试用例”非常重要。因为正是它的重要性决定的。
我认为,写测试用例的理由有5个,分别是为了:
理顺思路,避免漏测和重复测试
帮助预估测试排期,把控进度
方便bug回归验证
便于发现、记录并复现问题
标记测试结果,即对于测试结果有个交代
接下来,我们来说说“优秀的测试用例是什么样”的。好的测试用例,一般有这些特征:
包含基本信息
包括测试人/开发/产品/需求文档链接地址/技术文档链接地址
包括你测试过程中需要的物料
每一条用例,有很明显的突出测试预期和测试目的
所有用例都是可执行的
逻辑脉络清晰,几乎不存在重复的用例,简约而不简单
用例做到分级分层
待测功能点覆盖全面
说到这里,我还想要强调2个观点:
千万不要纠结测试用例的格式或形式!
也千万不要觉得测试用例写得越细越好!
有了以上基础,接下来才能够讲明白如何去写好测试用例,不,确切的说是写好测试方案。
一、基础信息
摘自美团技术团队文章
这里再补充一点:测试排期/上线时间/Bug提交地址 等
所以,基础信息至少要包含:
标题:【xxx】测试用例
新功能简介(或者需求目的目标)
参考资料
干系人
测试排期
上线时间
Bug提交地址
如果项目有 业务流程图 或者 系统框架图,也可以po到测试方案里面去体现,方便熟悉业务目的或者上下游系统间的依赖。
二、测试方法
根据需求的不同,又可以分为多种测试手段(手段)
最主要的:
功能测试
单元测试
性能测试
稳定性测试
兼容性测试
安全测试
UAT测试
根据测试项目的实际情况而定,比方说:你只是测试一个搜索框改了个默认提示文案,你就没必要去单独再去硬套模版测试性能了。
其实谈到写测试用例,大家更多的还是在写功能测试用例,所以这块重点讲。
功能测试用例,要做好分层设计(至少2层):
第一层:冒烟测试用例
第二层:常规测试用例
冒烟测试用例,其实也可以当作是 提测准入测试用例 以及 验收回归测试用例
这部分用例相当于P0级的测试用例,主要是为了保证主流程是完全走通的,如果走不通,则测试有权利打回给开发,让开发把主流程跑通后,测试再继续往下进行。
(摘自美团技术团队文章)
常规测试用例,呵!这里就是八方神仙、各显神通了!
设计测试用例的时候,是有一些策略和方法可循的。
测试方法不必多言,掌握几种常用的黑盒测试方法即可:
等价类
边界值
场景法
判定法
正交试验法
因果图
状态迁移图
其中用得最多的,恐怕就是 等价类、边界值、场景法 了。
测试策略就比较有讲究,需要大量的测试实践,才能形成一套自己的测试策略。
我自己总结了几条:
1)二八原则:重点抓主流程进行测试,不过分钻牛角尖。
80%的问题,集中在20%的模块里
80%的Bug,由20%的开发者写出(日久见人心,你懂)
2)要模拟真实的用户场景,不要YY出来一个永远都不可能发生的场景。
3)相互依赖的服务之间,最容易滋生Bug。
4)金字塔原理编写法,可以自上而下或者自下而上,杜绝重复用例。
三、数据构造
很多人不注重数据的重复利用,每次测试,都花费大量时间在构造数据上。
但是假如你在些测试方案时,就把数据构造和数据构造的方法写上去,
包括一些SQL、表格数据、json数据、账号密码等等测试数据
当下次还有相同的测试场景时,可以翻一翻之前的测试方案,就不用再花费太多精力在构造数据上了。
写测试用例的五大注意事项:
第一步、明确测试范围
有些需求是多个部门一起合作的,可能会有多个测试和你一起分工合作。
你需要明确自己主要负责测试哪些地方,细化到功能模块。
这个时候,你应该明确两点:
你测试的模块到底依赖哪些其他模块
有哪些模块依赖你所负责测试的模块
设计测试用例的时候,把重点放在设计你自己负责的测试范围上;
对于有依赖的模块,也需要考虑降级和容错,也就是你要考虑,你负责的模块出问题了,对人家造成什么影响;
或者,人家负责的模块出问题了,对你所负责的模块有什么影响。
明确测试范围的2个好方法:
需求评审会一般产品会按功能模块去划分,分别评审,你需要和与你对接的产品和开发步调一致。
测前沟通,找开发和产品去做测试前的沟通,必要时,甚至要找关联的测试人员去做一次沟通,明确测试范围。
第二步、熟悉需求文档
需求文档至少要看三遍!
在你熟悉需求文档的时候,也相当于已经进入测试了,像一些公司美其名曰:文档测试。
产品经理写需求没想到的,你想到了,都可以大胆的提出来,要有质疑的精神。
另外这里还有一个小建议:尽量让产品经理把产品的流程图画上,流程图可以反映出数据流向是怎样的,这可比文字更加直观。
这样你会对整个需求文档有更深的理解。
第三步、熟悉开发文档
开发的系统设计文档、接口设计文档、数据库表结构,如果有的话,最好都看一遍。
第四步、设计和编写测试用例
现在大部分测试工程师手工测试都喜欢用Excel或者Xmind来编写测试用例。
Excel比较适合用例较少、操作步骤简单、可能性有限、结果预期比较明确的功能。
Xmind比较适合用例较多、功能相对复杂、结果预期比较多样的功能。
以下分别举两个使用场景:
(1)假如说测app的话,个人感觉用Xmind可能会更合适,
用Excel的话,由于功能比较繁琐,可能用例条数会很庞大,一方面测试起来,看太多表格,容易头晕。另一方面维护起来也比较麻烦。
而Xmind可以只是把功能点写上,本身结构化的设计思维会让测试思路比较清晰,测试用例维护起来比较方便。
(2)对于上线后的回归测试验证点(CheckList),我们可以用Excel去表达,主要是针对主流程主功能的正向操作进行验证,逐条操作也防止漏测。
但其实用哪种软件编辑测试用例,都是看个人的使用习惯,关键是自己能看懂,别人也可以看懂就可以了。
设计测试用例时的,需要结合需求文档,把测试点罗列清楚,尽量用简洁的语句表述,非常忌讳写出过于啰嗦的用例。
另外,设计测试用例的几条思路我也简单介绍一下:
按模块把功能点罗列全,切记不要照抄需求文档,这样写不写有什么区别?
软件测试的基本测试方法要有效利用上,像边界值法、等价划分类、场景法等等,都是特别实用测试方法。
不要在细枝末节上纠结太多,根据二八法则,80%的bug都集中在主流程里面,要确保主功能主流程没问题。
第五、用例评审
测试用例设计完,一定要和产品研发一起评审测试用例,漏掉的测试点要及时补充。
文章来源:网络 版权归原作者所有
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系小编,我们将立即处理