我们经常都知道一个测试用例里面包含以下几个要素：
1，用例编号
2，模块
3，场景
4，用例名称
5，前置条件
6，测试等级
7，操作步骤
8，预期结果(需求要求的结果)
9，实际结果
10，创建日期
11，是否通过
我们分析下，这些要素到底是有什么用？
用例编号：
工作场景一没有用例编号：
测试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”哪个好？
必须第二个好，我连数据都不用动脑子直接粘进去测试了，能不好？不服来战！！！
预期结果（需求中要求的结果）：
佛说：万事万物，有因就有果。
刀哥说：软件测试，有操作就有结果，只不过，在软件没出来之前，我们心里得有个预期吧，所以就有了预期结果，要不你怎么知道对错？
实际结果：
丑媳妇总要见公婆的吧。
哪怕你的软件写的再烂，你也得有个实际结果，哪怕与预期不符呢，我提单你改不就完了。所以软件测试还是蛮友好的，至少错了还能改，要是真的取个媳妇，你就不管丑与美，都得负责了。。。
创建日期：
古人有云：天时地利与人和。
天时说的就是时间，你写个用例，好歹给人家个出生日期吧，你说刀哥说的对不。。。
是否通过：
事情总有个对与错，软件测试也是一样，总有过关和不过关
不过关咋办，那就是问题，提单吧，但是你也得记录下这个用例未通过吧。
