软件测试用例怎么写？这份最佳实践指南讲透了

如果测试用例质量差, 浪费的不仅仅是测试人员自己的时间, 还会影响整个交付环节的时间安排。关于测试用例的设计和具体执行, 是存在一套成熟的应对方法的, 这种做法并不是单纯依靠个人的直觉来盲目编写。

用例设计的底层逻辑

在动手编写测试用例之前, 一定要先把需求吃透。要和产品设计人员以及开发人员把那些模糊的地方完全聊清楚, 弄清楚功能方面、性能方面以及安全方面各自都有什么样的具体要求, 不然你写出来的步骤全都是靠猜的, 在执行的时候会出现反复返工的情况。

每条用例都必须带上唯一的编号, 同时还要包含前置条件、操作步骤、预期结果以及对优先级的标签标识。优先级的划分被明确设定为高、中、低这三个档次, 当可用的资源变得吃紧的时候, 必须首先去运行那些属于高优先级的模块, 这被视为一种能够保障系统稳定运行的必要手段。

等价类划分和边界值

等价类的核心思路, 其实就是把输入内容按照特定的规则进行分组, 然后在每一个分组里面只选取一两个具备代表性的取值来进行测试, 比如针对年龄这个字段的情况来说, 正常取值、零、负数、还有超大数这几类数值中的每一种都各自提取一个代表值进行测试, 这种方法可以用非常少量的一些数据信息去覆盖到数量极其庞大的各种输入情况。

边界这个位置它特别轻易地就会冒出各种各样的bug, 当你的输入范围被划定在1一直到100的这个区间的时候, 你就应当把重点放在去测试0、1、100以及101这几样特别特定的数值点上, 在实际进行项目开发的过程里面, 有非常多的缺陷它就是悄悄地隐藏在那些处于边界的区域里面的, 所以你可千万不能只顾着去监视和测试那些位于中间地带的那一些值啊。

复杂逻辑用因果图和场景法

当符合条件的情况变多的时候, 组合的数量就会急剧增加。因果图法可以帮助用户把多个输入内容之间的关系用图形的方式表达得更加清晰明了。在把这些关系表达清楚之后, 可以进一步将其转化成判定表的形式。

通过这种做法，能够有效防止遗漏任何可能的组合情况。这种方法是专门用来应对那些对规则要求严格的场景的, 比如处理订单相关的事务或者是负责控制用户的各种权限等情形时非常适用。

所谓场景法, 这个词语所指代的意思, 其实就是模拟用户那一些很真实的操作路径。那么在进行这一种方法的操作之前呢, 需要先搞清楚那个主要的流程, 然后再去补充那些异常的情况以及分支。

比如说在下订单这一个环节之中, 首先是要选择商品, 然后是填写地址, 接着是进行支付, 最后是生成订单。在这样的每一个步骤里面啊都需要分别地去设计出那一条正常的路线以及那一台异常的路线, 这是必须要做到的。

执行前的准备别偷懒

在环境没有搭建妥善之前, 绝对不要着急去执行用例。务必确认服务器配置是否正常, 数据库处于可用状态, 网络连通性无误, 并且提前准备好正常数据、边界数据以及脏数据, 防止在测试进行到一半时发现数据出现错误情况。

先把用例按照它们的优先级排好队列, 高优先级的模块就先跑起来。要是团队里的人数比较多的话, 可以按照模块拆成好几批来并行执行, 在执行之前得花五分钟的时间仔细扫一遍这些用例, 看看有没有过期的或者描写不清楚的情况。

执行中抓牢缺陷记录

发现bug别只在脑子里记，立刻按模板写缺陷报告: 标题、复现步骤、实际结果、期望结果、严重级别、截图或日志。一样不能少, 漏了信息开发没法修。

回归测试这个事儿, 它不仅仅是为了去验证那个缺陷到底修好没有, 还得确认在修复的过程之中, 有没有把周边的那些功能给破坏了。所以, 每次进行修复以后, 大家一定要把那些相关的模块的用例重新跑一遍才行, 目的就是为了防止因为修复了一个缺陷的结果, 反倒又引出了三个新的问题出来这样子的情况。

让执行效率再快一步

冒烟测试和回归测试重复量大, 最适合搞自动化。使用Selenium或者Appium写脚本来让机器跑那些重复劳动, 让人把精力放在探索性测试和复杂场景上。

用例这东西, 它是活的, 而不是说写完了之后就直接被锁进文件里, 在执行的过程当中, 如果发现步骤描述得不清楚, 或者发现预期结果有错误的话, 就要当场进行修改, 如果需求发生了变化, 就需要同步地更新用例, 如果不这么做的话, 那么下一轮的执行工作就全都白费力气了。

请问大家在使用用例管理工具的时候, 有没有经历过特别让人头疼的糟糕情况呢? 希望大家能够在评论区里面把经历说出来分享一下, 如果觉得这篇文章的内容是确实有用的, 那就请点击赞, 并且把它转发给你的同事们看一看。