如何优雅编写测试用例 - 测试蔡坨坨

如何优雅编写测试用例 - 测试蔡坨坨 - 博客园

转载请注明出处❤️

作者：测试蔡坨坨

原文链接：caituotuo.top/df5003b8.html

你好，我是测试蔡坨坨。

上次我们说到测试用例的设计（可参考往期文章「测试用例设计的底层逻辑」）。

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

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

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

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

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个；

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

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

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