软件测试用例要素详解

我们经常都知道一个测试用例里面包含以下几个要素：

1，用例编号
2，模块
3，场景
4，用例名称
5，前置条件
6，测试等级
7，操作步骤
8，预期结果(需求要求的结果)
9，实际结果
10，创建日期
11，是否通过

如果对软件测试、接口、自动化、性能测试、测试开发、面试经验交流。感兴趣可以加裙485187702，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。

我们分析下，这些要素到底是有什么用？
用例编号：
工作场景一没有用例编号：
测试A：开发你的软件出了bug！
开发B:什么bug？
测试A：就是那个执行@#￥%……&用例出现的bug
开发B：什么？
测试A：就是那个#￥%……&
开发B；你到底说了个what？
测试A：你让我怎么给你说，你才明白
开发B：世界上最远的距离不是我站在你身边你不认识我，而是你占我身边连个问题都给我表述不清楚。。。

工作场景二有用例编号：
测试A：开发你的软件出了bug！
开发B:什么bug？
测试A：就是那个编号为BCBX-007的用例出现测试不通过
开发B：好，我去看看
测试A：好的
开发B；刚看了，按照用例执行确实有问题，我改下。
测试A：嗯嗯，谢谢
开发B：不谢，世界上最幸福的事情不是猫吃鱼，奥特曼打怪兽，而是我跟你配合，一个开发一个测试
测试A：基情无限。。。。

模块：

在软件的世界里，有不同的功能，那么如何在庞大而又复杂的系统中，梳理出一条有序的目录或者test checklist
我个人认为我们只有划分出对应的模块，然后逐一攻破！！！ 

场景：
很多人把场景和模块可能归为一类，也对，也不对，其实独立出一个场景，我个人认为更多的是为了 细化模块，举个例子：
一个大型的门户网站，可能有生活，工作不同的模块
但是工作模块下可能会有兼职，全职，包括不同工作类型的场景，甚至对于测试来说还有正常的和异常的场景 

用例名称：

人不可无名！！！同样我们的测试用例也得有个名字叫用例名称，要不你都不知道叫个啥！！！ 

前提条件：

古人有云：完事具备，只欠东风！！！
我个人认为一个好的前提条件就是一股东风，祝你成功，并且我们在测试软件的过程中，往往会遇到业务逻辑较复杂的软件，如果能够很好的利用好前提条件，你的用例会非常的beautiful

测试等级：

一件事都用重要不重要之分，软件测试也是一样
在我们测试的过程中，一个功能如果出问题，会影响其他功能的使用，并且这个功能是用户的高频操作，那么你说他重不重要？
至少和刀锋老师在你们的心里一样重要吧（自恋一下，嘻嘻！！！）

 操作步骤：

我们做任何事情都有个step1，step2，step3.。。。何况软件呢？
谁要说用例里面测试步骤可有可无，下课别走！！！

那么一个好的操作步骤，是需要很多的积累和沉淀的，举个例子你的操作步骤里面说“输入一个正常的手机号”，与“在手机号栏位输入手机号：15991710589”哪个好？
必须第二个好，我连数据都不用动脑子直接粘进去测试了，能不好？不服来战！！！

预期结果（需求中要求的结果）：

佛说：万事万物，有因就有果。
刀哥说：软件测试，有操作就有结果，只不过，在软件没出来之前，我们心里得有个预期吧，所以就有了预期结果，要不你怎么知道对错？

实际结果：

丑媳妇总要见公婆的吧。
哪怕你的软件写的再烂，你也得有个实际结果，哪怕与预期不符呢，我提单你改不就完了。所以软件测试还是蛮友好的，至少错了还能改，要是真的取个媳妇，你就不管丑与美，都得负责了。。。

创建日期：

古人有云：天时地利与人和。
天时说的就是时间，你写个用例，好歹给人家个出生日期吧，你说刀哥说的对不。。。

是否通过：

事情总有个对与错，软件测试也是一样，总有过关和不过关
不过关咋办，那就是问题，提单吧，但是你也得记录下这个用例未通过吧。

 总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

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

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。