其他分享
首页 > 其他分享> > 测试用例应该怎么写

测试用例应该怎么写

作者:互联网

一、背景

有些测试同学,写测试用例的时候,直接就是将需求文档上的内容抄一遍,转换成测试用例的格式。没有加入任何自己的思考和理解,没有融入任何测试方法论。测试完全依赖于需求文档的质量,依赖于产品经理保姆级的服务。需求写得细,测试用例覆盖就全面,需求写得粗,就有很多地方都没有测试用例覆盖。

让他针对一个功能设计测试用例,总是习惯性的回答:根据PRD来写呗,PRD怎么说我就怎么写,慢慢地将自己变成只会复制、粘贴的工具人。在他们眼里,做测试和进厂打螺丝没有任何区别。最后上线出bug了,就转过头来攻击PRD写的怎么那么粗糙,完全不会思考自己的用例是否有问题。

二、测试用例的作用

  1. 理清测试细节,提高测试覆盖率,避免漏测;
  2. 通过详细的用例设计反推是否有需求漏洞,提前发现需求细节问题;
  3. 提前准备测试数据,便于测试过程高效执行;
  4. 测试过程中用于判断测试进度,预知测试风险;
  5. 测试用例是测试的重要资产,便于测试内容回溯、测试工作交接;

看懂了以上测试用例的作用,请不要再将测试用例像垃圾一样用完随手丢弃,而是要好好写,好好存。

三、你真的会写测试用例吗?

传统的测试用例编写,会采用Excel的方式编写,用例中包含的内容大致如下:
测试模块、用例编号、用例标题、用例类型、用例等级、是否可自动化、预置条件、步骤描述、预期结果、备注。
在这里插入图片描述
Excel的方式适用于系统逻辑简单、清晰的需求。

如果系统需求较为复杂,需要测试人员做复杂的测试数据设计、做较多的联动场景测试时,推荐用Xmind的方式编写测试用例,通过脑图的方式,相比纯文字更有利于测试人员梳理测试逻辑。此外Xmind梳理测试点的方式也更适应如今互联网高效的模式,Excel编写维护起来会比较臃肿耗时,可读性方面也比xmind差。

测试类型:从从功能测试、UI测试、异常测试、场景化测试、功能性并发测试、兼容性测试、易用性测试、性能测试、安全测试、回归测试等多个维度去编写测试用例,用例才能有比较高的覆盖率,不容易漏测一些特殊场
景。
在这里插入图片描述

测试范围:如果需求是涉及多个终端(比如:App、小程序、PC端都涉及),或者需求是多方一起合作测试,最好单独拉一个模块写清楚:测试范围,提前划分好测试边界,确保信息对齐,各方的理解一致。
在这里插入图片描述
冒烟测试:抽出主流程冒烟测试用例,方便需求进测时先测试冒烟是否通过,并且冒烟用例也可以提供给研发自测使用。
在这里插入图片描述
用例分级:P1级用例、P2级用例、P3级用例,做好用例分级。测试过程中做好标记:测试通过、测试失败,便于统计进度。需要添加备注描述的,做好用例执行备注。
在这里插入图片描述
用例评审:比较重要的一个环节,需要拉齐测试leader、研发、产品一起评审,确认用例的正确性和完整性,排除因信息误差、理解偏差等导致错误的用例、用例覆盖率不全等问题。和研发约定好,开发需自测保证冒烟测试用例通过,才能达到提测标准。

用例平台:如果公司有专门的用例平台来管理整体的用例,也没关系,目前市面上常用的用例管理平台,或者公司自研的用例管理平台,基本都是支持Excel或者Xmind导入的。用例平台最好能支持将项目-需求-用例能关联起来存储,便于后续管理和回溯。也可以打通bug管理平台,建立用例和bug的关联关系。
在这里插入图片描述

四、测试用例模板

文章的最后,杨叔也将Excel和Xmind的测试用例模板上传到了百度网盘,搜索关注杨叔的微信公众号:程序员杨叔,下载地址在公众号同篇文章【你真的会写测试用例吗?】末尾,感谢关注~

都看到这里了,如果对你有帮助,麻烦点个赞+收藏+分享,一键三连啦~

程序员杨叔:
测开一枚,持续分享全栈测试知识干货。标签:自动化测试、性能测试、Java、Python、DevOps、CI/CD、小程序测试、测试工具、测试开发、测试框架/平台、测试管理…

标签:怎么,需求,Excel,用例,测试用例,Xmind,测试,应该
来源: https://blog.csdn.net/baidu_28340727/article/details/123607886