编写出好的测试用例是每一个测试工程师的职责，但在实际工作中大家写的测试用例往往需要不断地修改才能使用，这不仅浪费了时间，还容易让测试工程师产生自我否定的情绪，甚至在团队中产生各种矛盾。

那如何高效地设计测试用例呢？团队内部又该如何处理测试用例的编写呢？下面就个人和团队的做法给出建议，希望能够帮助到大家。

2023完整版软件测试入门实战教程，从基础到项目实战学完即可入职。挑战年薪40+！_哔哩哔哩_bilibili2023完整版软件测试入门实战教程，从基础到项目实战学完即可入职。挑战年薪40+！共计97条视频，包括：1、软件测试学习路线图、2、软件如何实现月薪过万、3、码尚教育VIP开班典礼等，UP主更多精彩视频，请关注UP账号。https://www.bilibili.com/video/BV14G411s7yZ/?spm_id_from=333.337.search-card.all.click

 个人写测试用例

个人在写测试用例时，设计方法用了很多，执行步骤也写了不少，但实施测试时却发现所写的步骤很大程度上无法衔接，需要进行修改才能执行下去，这种情况基本都是对软件界面操作了解不够而引发的，而软件界面操作是有规律可循的。

以下面较常见的界面来讲解测试用例的设计思路和具体做法。

1.1 界面功能分析

• 首先，图中红色加粗的信息项是必填项，在界面设计时往往都放在前面。非必填项则放在必填项的后面

• 软件并不会在输入某个数据时立即校验该数据的合法性和正确性，而是在点击“保存”按钮，提交数据时进行数据校验

• 数据项校验顺序：从左至右、从上至下。非必填项若无数据则不校验

• 校验提示原则1：根据校验顺序逐项校验，遇到错误立即弹框提示，终止校验过程，数据提交失败

• 校验提示原则2：首先检验整体数据的完整性，然后注意检验合法有效。即先检验所有必填项都有没有数据，然后才检验数据对不对！

1.2 信息提示规则说明

当发现一个问题时，就已经无法完成任务，后面的数据项是否还有问题已不重要了。软件无法控制用户的操作行为，不会一次性提示出所有的数据项错误，因为用户如果没改完、没改好、不小心把对的数据改错了等等行为，都会导致这种一次性的提示没有意义。最关键的是这些信息显示在提示框中，用户点击“确定”按钮后就消失了，他能完全记住吗？

1.3 测试数据设计

对每一项数据均采用多个技术设计出若干个非法无效数据和有效数据，所有必填项的有效数据拼成一组组的完整数据，数据组的个数按最多的有效数据项来算，有效数据个数不足的数据项可将已有的有效数据进行复制，补齐个数的不足。

1.4 测试用例设计大体步骤

1) 所有必填、非必填均为空，然后点击【保存】，系统提示：【姓名】不能为空

2) 给【姓名】填入一个非法数据后点击【保存】，系统提示：【年龄】不能为空

3) 给【年龄】填入一个非法数据后点击【保存】，系统提示：【性别】不能为空

4) 给【性别】填入一个非法数据后点击【保存】，系统提示：【学历】不能为空

5) 给【学历】填入一个非法数据后点击【保存】，系统提示：【身高】不能为空

6) 给【身高】填入一个非法数据后点击【保存】，系统提示：【体重】不能为空

7) 给【体重】填入一个非法数据后点击【保存】，系统提示：【姓名】数据错误。注意：至此所有必填项的必填性已测完

8) 依次给【姓名】填入其它非法数据后点击【保存】，系统提示：【姓名】数据错误。注意：填一个非法就点击【保存】

9) 给【姓名】填入一个合法数据后点击【保存】，系统提示：【年龄】数据错误。注意：此时对【姓名】的所有非法已测完，并测试了一个合法

10) 循环第8和第9步，对其余必填项都做相同的操作，先填当前数据项的所有非法，最后，跟一个合法。至此，所有必填项的非法数据均测完，而合法数据测试了一组

11) 将必填项的剩余未测的多组数据，按组填入，然后点击【保存】，完成剩下的必填项测试。至此对必填项的合法与非法测试已完成

12) 非必填项单独测试，可将前面必填项的合法数据拿出一组来配合

 团队写测试用例

团队工作最大的问题就是每个人的测试数据都是按自己的思路和要求来设计的，当大家的测试用例放在一起时，无法构成一套，不能完整的对系统进行测试，改动量很大。尤其对查询、统计、报表类功能影响巨大，几乎不能测试！

团队编写测试用例的原则是：

• 功能滞后的用例，编写时需向前置功能的用例提出数据要求

• 前置功能的用例在满足自己测试的需求基础上要考虑后续测试的数据要求，最好能融合（留下的就是满足后续功能要求的数据）

例如：

张三写【材料入库】，增删改功能执行后保留在系统中有两条数据。

李四写后续的【材料出库】，则首先利用张三保留在系统中有两条数据，若数据不够，李四要对张三提出添加数据的具体要求来满足自己的测试工作。

依此类推，则整个团队的测试用例就能写成一套，这样的测试用例可用性非常高，执行时基本不过脑子，只看预期结果。

建议一开始就召开专门的测试用例设计会议来沟通测试数据的问题

笔者做测试经理时就是这样做的，测试工程师刚开始的时候很抵触，觉得这样做很麻烦且进度慢，但当进入测试执行阶段，他们都很开心，因为测试用例执行的很流畅，也没有以往的那些改用例的活了。

 高效

就是做一件事当几件事来用。具体说就是一个测试数据可以测多个方面，这就是高效！

而测试的高效就是测试数据的高效，那么怎么做呢？

3.1 关于非法数据

非法的数据要测，且要用心设计，但无法进入系统中

3.2 关于合法数据

从功能角度说，测试用例有合法与非法之分，一般合法数据的设计只要合法就行，但往往不满足业务，此时要为业务测试重新设计数据，费时费力。需要合并合法数据与业务数据，提高用例的效率，即高效！

合并时，使用业务数据来替代合法数据。对测试工程师而言，很可能不懂业务，没关系用户懂，并且用户手头就有很多的业务数据，可以找用户获取这些业务数据。

要注意用户业务数据的保密！21年下半年国家正式实施《中华人民共和国数据安全法》，对数据的获取、传播和使用都有法律上要求。

 评审

有很多关于评审的做法，我这里不再累述，当前面的几点都做到了、做好了，其实评审时要评什么，怎么评，也就呼之欲出了。

个体用例的设计是否合理，与软件的操作是否相符，这是一个重点。

整体用例的前后数据是否呼应，是否能构成一套，这是另一个重点。