编写测试用例的一点体会
一是测试用例对需求覆盖的完整性；二是测试用例的有效性；三测试用例的可理解性四是测试用例的清晰性；五是测试用例的可维护性。
测试用例是基于需求的，为了测试程序是否满足需求，个人觉得要想写好测试用例必须对于需求做到完全理解，并能从全局上把握住需求。一个好的方法就是用mm图把需求分解了。把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手的多。在编写用例的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。也就是说拿到需求文档必须进行必要的分析，不能上来就盲目的写用例，新人尤其应该注意。测试用例编写完成后必须明确哪些是核心功能的用例！
（测试用例的有效性）测试用例应该包含清晰的输入数据以及预期输出，没有测试数据的用例更多的是具有指导意义，执行过程中更多的是靠个人根据指导的自由发挥。但是看看我们的基线库更多的是这样指导意义的用例。（但是输入数据又涉及到了维护的问题，以及环境或者业务发生变更后引起的有效性问题）。对于预期的结果不能仅仅是页面上或者界面上的可见结果，如果和数据库发生了交互，必须包含数据库里准确的验证结果。用例基于数据驱动。
（测试用例的可理解性）测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语，测试用例应该按照增删改的顺序进行安排，这样执行的时候效率比较高，避免不必要的重复测试，用例写完不是就ok了，我们最好通读2遍，进行修改，让单条用例流畅。
（测试用例的清晰性）测试用例的验证点必须明确清晰重点突出，按照最新的用例标准，一个用例进行一个功能点的验证，一个萝卜一个坑。对于流程性的用例也是建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。
（测试用例的可维护性）我们的用例主要是基于web的，用例存在一定的变数。
因此在测试用例因为业务需求发生变更的时候，请及时修改，维护测试用例，做到测试用例的实时性与有效性，同时也方便后来的新人同学及时学习，不会产生误解与费解。
Ro Collard在”Use Case Testing”一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。如果你在项目或者日常结束后，仔细的分析过我们的bug列表，那么你会觉的这句话非常适用。合理提高我们的测试效率就是在编写测试用例时进行测试用例优先级的划分。
1．用于冒烟测试的用例为最高优先级
2．把基本路径以及各模块主功能的测试标注为高优先级别
3．把你所有错误和边界值或确认测试标注为中优先级别
4．把可用性测试以及入口默认值校验等标注为低优先级别。
5．将功能测试用例分为严重和不严重两类，对于不严重的功能测试用例降级为低优先级用例。
几点建议：
1．你是否感觉测试的时候思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍？请明确你的需求，是否做到覆盖100%。你的用例优先级是否设置的合理。
2．在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能？那么你需要调整自己用例的优先级，顺带回去好好整理整理需求。
3．在编写测试用例的时候优先去学习，老人们优秀的做法。在学习别人优秀成果的基础上，编写自己的用例。
构造朴实的测试用例
测试用例这种东西对于刚入行的人来说是一种诱惑，初入测试的人急于掌握这门学问，所以一开始就会问测试用例怎么写，问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵，任何人没有必要注重形式问题，如果你现在或者未来的公司有套非常完善的文档管理体系，那么你可以参考标准模版，如果没有你们大可跟我一样使用下面的格式：
-----------
- ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE
-----------
我认为没有什么问题，ID代表标号（如果你愿意可以用这个ID对应需求文档的ID或者使用详细设计的文档的ID，间接连接需求），ACT代表一种动作，因为测试动作非常复杂，如果手动执行或者自动执行，或者或者是一种异常状态都可以占用此位置，但是注意不能使用性能、数据或者安全测试替代，为什么请各位自己考虑。DATA代表数据，很多的测试类书籍中虽然没有直接讲明测试数据的划分，但是通常我们引用三种数据“正常”、“异常”、“错误”，分别对应关键字“PASS”、“ERROR”、“FAIL”，对于数据的划分我以前曾经说过这里不再细谈，为什么会在一个文档中体现着点，主要是为了以后数据程序化作接口，一个不能将手动测试转为自动测试的人员注定是平庸的。EXPECTED、ACTUAL分别代表期望和实际，我们做这一行的经常对这两种值的差异感到困惑，是不是“正常”、“异常”、“错误”就看个人的经验了。T/F的引入是因为有这样的一种情况介入，如果EXPECTED、ACTUAL是不同的，但是我们还是要给个T，因为对于单项的是否通过测试人员有着使用权，但决定权在于市场或者高层决策。DATE是一种好习惯，通常记为发现“PASS”、“ERROR”、“FAIL”的时间，很多人会忽略这个值，当然对于我们来说没什么损失，对于QA团队来说，仅仅提供给他们T/F是不够的。
我觉得这就是一种构造朴实的测试用例的方式，不要过于在意一份文档的表现形式，如果你有很多的时间，如果你一年才写一个这样的文档，那么你可以从互联网上下在很多的资源把这份文档修饰的像APPLE一样。
入行的人员会更进一步的发挥测试偏执狂的能力，这时候他们急需一种数量，例如：我们一个动态库的测试用例就有3000多个厉害吧？厉害，我当然说你厉害，你难道不厉害吗？我记得有个500强的面试题就是你能为LOGIN动作写多少的测试用例？我想了半天我说就三个，或者四个，在听到了一声深深叹息后，我惶恐的说大概我能写5个吧？！当然我自己也没底，我就能写出三个。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的测试用例就是他们的衍生，一种本源的问题。我们继续讨论3000多个测试用例的事
情，有人明眼就会说：这家伙肯定是微软的，没错，除了这种大公司有了充足的资源和技术支持，哪家公司能跟他们一样呢？当然了，写3000个我想入行久了谁都可以，并且跟你对系统的熟悉程度，工作经验有莫大的关系，但是这里我又想说说关于构造朴实的测试用例的问题了。
单元测试、集成测试这些说明的是测试范围，功能测试、性能测试这些说明的是测试的手段，也可以这样说某个功能测试包含了若干个功能测试也内隐含了若干个单元测试的联动，当你开始测试的时候，实际上最终是对代码设定路径的一种验算，如果我们都生活在单线程、无UI的年代你可以更清楚的看到
“PASS”、“ERROR”、“FAIL”三种状态，可我们已经错过了这个年代，我们有了包装的UI，有了封装的API，有了各种各样的MESSAGE，所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱，出发点是好的做法是累死人的，如果你愿意你可以为机器码写1亿个测试用例，如果你还是很偏执，你可以为门电路写上1万亿个测试用例，你有命执行吗？
我通常不愿意写太多的测试用例，很多人认为我工作态度有问题，我认为这更能说明我的态度：我愿意朴实的构造我的测试用例，但是我有原则来保证我的测试用例：
1、接到任务不急于作而在于多思考，首先在纸上构造一个大致的业务流图
2、流图构造好，快速剔除公用的测试用例
3、构造测试用例先写符合主路径的三种“PASS”、“ERROR”、“FAIL”
4、精化测试用例努力为ERROR多构造1-7种假设
5、执行测试用例强化FAIL的标准化失败输出，但是对应减少PASS测试用例
6、进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10如果我还是测试，我将继续我的朴实理论，多出来的安全时间我可以看看蓝天享受享受生活！
测试用例编写的“侯式标准”
作为软件测试人员，执行测试用例是我们进行测试工作的主要手段，测试用例设计的好坏，直接影响着测试工作的质量。一个“好”的测试用例能保证测试的质量，规范测试的进程，进而提高我们的测试效率。那什么样的用例才是好的测试用例？这已经是一个老生常谈的问题，大家见仁见智 ，众说云云，不一而足。
而我的TL–候风的一句话，让我对用例的有了新的认识。他是这样说的：一个好的测试用例，就是在保证测试质量的前提下，做到以下几点：当一个不熟悉业务的人，看到你的用例后，要知道用例的测试目的什么，知道你要做什么，怎么做，为什么这样做，取得了什么什么成果。
做什么？
做任何事情，都要有的放矢。我们在编写一个测试用例的时候，应该知道我们要的是什么，这也是编写一个用例最基本的前提。
怎么做？
即具体的如何设计用例。就是要明确用例的执行过程，这样在测试的时候才能有章可循，摸着石头过河
为什么这样做？
这要求用例编写者要明确设计用例时用到的方法（如边界值，等价类等等），以及用这种方法的好处。取得了什么成果？
这要求用例编写者明确通过这个测试用例,我们将取得什么效果。比如一个采用边界值设计的用例，取得的效果是在极端的数据下，软件是否能够正常执行功能。
标准规范中包含的主要元素如下：
1测试名称(Test Name)：测试用例编号和测试用例名称。
2创建日期(Creation Date)：测试用例创建时间，系统自动产生。
3设计人员(Designer)：测试用例设计人员
4状态(Status)：测试用例状态
5描述（Descrīption）：测试用例详细描述
6步骤名称（Step Name）：测试步骤名称
7步骤描述（Step Descrīption）：测试步骤详细描述。
8预期结果（Expected Result）：测试预期结果
要是按照“候风标准”（暂且这样命名，还没申请侯哥批准），我们要对上面的标准进行规范的优化以及内容的明确
1测试名称
A）用例根据各用例的功能来命名，尽量做到简洁明了。
B）一级目录使用各项目的顶级菜单名称来命名，如功能、业务、查询三大类；
C）二级目录使用顶级菜单下的二级菜单名称类命名，用户可根据名字判别该用例是测试哪个模块的。2 描述（Descrīption）：测试用例详细描述
要用通俗易懂而又简洁的语言描述描述用例的设计目的，让其他人能够明白我们在什么
3 步骤描述
步骤描述要详细而不臃肿，条理而不凌乱。
同时，在规范上要增加以下几项
1测试目的（Purpose）：编写这个测试用例的目的
2测试方法选择依据（Foundation）：即用这样方法的好处
3测试取得的成果（Achievement）：通过执行用例取得的成果
4用例执行的前提条件（Precondition）：执行用例的需要满足的前提
这样，一个完整的用例包含的元素如下：
1测试名称(Test Name)
2 测试目的（Purpose）
3 测试方法选择依据（Foundation）
4 用例执行的前提条件（Precondition）
5创建日期(Creation Date)
6设计人员(Designer)
7状态(Status)
8描述（Descrīption）
9步骤名称（Step Name）
10步骤描述（Step Descrīption）
11预期结果（Expected Result）
12 测试取得的成果（Achievement）
.
综上所述，测试用例的“侯式标准”的精髓，就是把自己的思维过程尽可能的展现到用例中，做到即使一个完全不懂业务的人，看到我们的用例后，也能知道业务的需求和流程，知道测试的过程，能够无障碍的执行我们的用例。
以上是我学习用例编写过程中的一些体会，不足之处请大家批评指正。让我们一起交流分享，共同进步成长。
