怎样高效地设计测试用例并评审

编写出好的测试用例是每一个测试工程师的职责，但在实际工作中大家写的测试用例通常必要不断地修改才能使用，这不但浪费了时间，还轻易让测试工程师产生自我否定的感情，甚至在团队中产生各种抵牾。
那怎样高效地设计测试用例呢？团队内部又该怎样处置惩罚测试用例的编写呢？下面就个人和团队的做法给出建议，希望可以大概帮助到大家。
 个人写测试用例

个人在写测试用例时，设计方法用了很多，执行步调也写了不少，但实行测试时却发现所写的步调很大程度上无法衔接，必要进行修改才能执行下去，这种情况基本都是对软件界面操作了解不敷而引发的，而软件界面操作是有规律可循的。
以下面较常见的界面来讲解测试用例的设计思路和具体做法。
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年下半年国家正式实行《中华人民共和国数据安全法》，对数据的获取、流传和使用都有法律上要求。
 评审

有很多关于评审的做法，我这里不再累述，当前面的几点都做到了、做好了，实在评审时要评什么，怎么评，也就呼之欲出了。
个体用例的设计是否合理，与软件的操作是否符合，这是一个重点。
整体用例的前后数据是否呼应，是否能构成一套，这是另一个重点。
如果小伙伴对软件测试感兴趣，想学习，可以私信后台哦。
末了： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋侪们如果必要可以自行免费领取【保证100%免费】

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

我们学习一定是为了找到高薪的工作，下面这些口试题是来自阿里、腾讯、字节等一线互联网大厂最新的口试资料，并且有字节大佬给出了权威的解答，刷完这一套口试资料相信大家都能找到满意的工作。

口试文档获取方式：

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。