如何优雅编写测试用例

Myth丶恋晨 2023-09-24 20:10 61阅读 0赞

上次我们说到测试用例的设计。

当你学会了如何设计测试用例之后，接下来便是开始用例的编写。

在设计阶段，更准确的说应该是识别测试点的过程，而编写阶段则是将测试点细化成一条条测试用例的过程，有了比较全的用例场景后，如何让别人更舒服、更方便、更清晰地去使用你的测试用例，如何更优雅地展示你的测试用例，如何让领导对你的测试用例满意呢？（“降本增效”，这里的“效”有时也指的是“效果”）

测试用例的编写是每一个测试工程师安身立命的家伙，也是测试的基础，更是软件测试的核心内容，正所谓“基础不牢，地动山摇”，所以一定要掌握好，有些转行的小伙伴一上来就开始自动化、性能的学习，却忽略了最基础的东西，这是不对的。

正好最近有小伙伴问到关于用例模板的问题，借此机会来聊一聊“如何优雅编写测试用例”这个话题。

![b7bf9bb401dd47c9a677e88a2eaea113.png][]

PS：需要用例模板的加V获取。

在编写测试用例之前，首先应该根据所在公司、项目组的特点，提前制定好对应的测试用例模板以及用例维护方式，比如：Excel、XMind、TestLink、禅道等。

测试用例的组成通常包含以下内容（具体字段根据业务需要取舍）：

*  **用例编号**
    
    作为测试用例的唯一标识。编号取值规则可以根据`项目名称各中文首字母大写`\+`六位数字`构成，例如：“蔡坨坨电商项目”在登录功能子模块的第一条用例编号可取值为`CTTDS_000001`。
 *  **用例标题**
    
    又称之为测试点，用一句话来描述测试用例的关注点，每一条用例对应一个测试目的。
    
    一个好的测试用例应该关注标题的规范性，一般来说如果设计用例标题不规范，别人在使用你的测试用例时，就无法做到清晰明了，就会浪费很多时间在沟通上。
    
    并且需要控制用例的粒度，从测试执行者的角度来说，过细的测试用例会让执行者感到疲惫繁琐，过粗的测试用例又容易导致检查点遗漏。所以测试用例标题一般控制在30个字以内。
 *  **功能模块**
    
    根据项目模块层级关系填写，例如：组织权限。
 *  测试目的
    
    简要的测试目的，例如：账号密码功能校验。
 *  **前置条件**
    
    用例在执行之前需要满足的一些条件，否则用例无法执行，如测试环境，需要提前执行的操作等，例如：进入到某一页面。
    
    测试用例其实就是在某种场景下，执行一定的动作，达到什么样的结果。而前置条件决定了“在某种场景下”，所以是不可或缺的。
 *  优先级
    
    根据需求的优先级来定义，高优先级要覆盖核心业务，重要特性以及使用频率比较高的部分。
    
    级别的枚举值也有多种形式，比如：P0\\P1\\P2\\P3，1\\2\\3\\4，高\\较高\\中\\低。
    
    冒烟测试（高）、基础用例（较高）、特殊场景用例（中）、错误场景用例（低）。
 *  **操作步骤**
    
    测试用例的步骤描述，执行人员可以根据测试步骤完成测试的执行，一般只需要写和测试目的密切相关的步骤，一些基础的步骤可以放在前置条件中，例如：1.输入正确的账号2.输入错误的密码3.点击登录按钮4.查看结果。
    
    用例步骤一般不多于7步，不少于2步。
    
    操作步骤也是不可或缺的一部分，因为它关系到如何执行。
 *  测试数据
    
    在执行测试时，需要输入一些外部数据来完成测试。这些数据根据测试用例的统计情况来确定，有参数、文件或数据库记录等，例如：账号：admin，密码：123456。
 *  **预期结果**
    
    测试用例中最重要的部分，主要用来判断被测对象是否正常，例如：提示用户名或密码错误。
    
    预期结果关系到用例需要达到什么样的结果，所以也是不可或缺。
 *  **执行结果**
    
    每条用例的实际执行结果，只有三个枚举值：PASS（通过）、FAIL（不通过）、N/A（未执行）。
    
    预期结果一般不超过5个，不少于1个。
 *  对应的 Bug Id
    
    每条测试用例执行不通过后再记录对应一条Bug，例如：BUG-1219。
 *  编写人
    
    用例对应的编写人员，填写编写人员姓名，例如：测试蔡坨坨。
 *  执行人
    
    用例对应的执行人员，填写执行人员姓名，例如：测试蔡坨坨。
 *  **备注**
    
    每条测试用例的备注，备注内容可以按实际情况填写，一般有备注的测试用例都比较重要，需要格外关注。

测试用例的编写并没有好坏和对错之分，每个人编写用例的思路也是各不相同，适合当前团队就是最好的，不要盲目把所有的字段都加上，应根据实际场景进行取舍。

除此之外，还有一些注意事项值得关注。

例如：

标题要清晰，推荐采用 `场景`\+`预期结果` 进行描述，比如：输入正确的用户名和密码，成功登录系统；

控制用例的粒度，比如：标题字数不超过30个字、步骤数控制在2-7步、预期结果数在1-5个；

用例之间要解耦，日常工作中经常遇到几个用例有先后顺序的情况，比如：在测试编辑之前肯定要先新建一条数据，最好把新建放在编辑用例的前置条件中，每条用例都能实现闭环；

预期要明确，不要出现一些模糊字眼，对于不明确的点应该跟产品沟通；

拒绝冗余，用例可以多，但不要冗余，尽可能以最小场景覆盖最全的范围，同一个等价类只需测一条数据，当然，因为测试不可穷尽性，测试场景肯定不会最全面，往往会受限于时间和资源等成本，这时需要在有限的资源下，寻求质量和效率之间的平衡点，优先级这个字段就起到了作用，再引申就是测试策略的问题了，整体上采取基于风险驱动的模式，有侧重点地去验证一些场景，优先核心功能，或者增加资源和延长周期，同时寻求自动化相关技术去提升整体效率。

**最后：** 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取**`【保证100%免费】`**

![在这里插入图片描述][ed4627a964d644e285a28f9b5dd81dae.png_pic_center]

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！

![c2060c10e255418e9704f020c3219085.gif][]

[b7bf9bb401dd47c9a677e88a2eaea113.png]: https://img-blog.csdnimg.cn/b7bf9bb401dd47c9a677e88a2eaea113.png
[ed4627a964d644e285a28f9b5dd81dae.png_pic_center]: https://img-blog.csdnimg.cn/ed4627a964d644e285a28f9b5dd81dae.png#pic_center
[c2060c10e255418e9704f020c3219085.gif]: https://img-blog.csdnimg.cn/c2060c10e255418e9704f020c3219085.gif