如何高效的编写测试用例
测试用例执行过程高质量的标准：
1、覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑，注意隐性业务会产生的场景）
2、覆盖到所有的典型用户场景（正常和异常场景）
3、覆盖到所有的需求点（当前版本涉及的所有功能）
4、测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短（测试计划起到非常关键的作用）
5、没有冗余的用例（相同的用例可以复用）
6、测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚（从这点上，写用例要体现的关键点很重要）
So，如何能高效的达到目标？
一、基于业务逻辑的用例设计过程：
A、用例编写过程：
1、优先完成业务逻辑图（建议画思维导图，画出测试点），需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，并且自己能够理解为什么这样处理
2、分析每个逻辑的处理是否完善，是否有没有覆盖到的地方（考虑要周全，重心放在大方向流程上）
3、根据业务逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖（有条件性的用例覆盖）
4、编写业务逻辑用例的过程中，并思考如何去改进该用例的测试过程（这个看个人理解能力），比如：接口测试，自动化测试，脚本。并且，能够及时让研发提供对应的接口和调试方法（可以找开发帮忙）
5、用例要按照10分钟原则，即保证10分钟内能够执行完成（规定时间内完成）
B、用例评审过程：
1、先讲解整个业务逻辑图，需要保证参与评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这样做（提前作好准备，通知到位）
2、分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况（可以采用头脑风暴的方式）
3、分析业务逻辑的异常处理情况（是否每个业务逻辑都有对异常情况进行处理，也可采用头脑风暴的方式）
4、是否将业务逻辑的用例分类比较合理，让大家通过业务逻辑很容易就找到对应的用例（分类方法清晰明了，一看就能明白）
5、分析是否所有的逻辑都能够找到对应的用例（通过业务逻辑找到对应的用例）,包括前面没有考虑到的逻辑（隐性业务场景）
6、分析用例是否有冗余，是否多个用例都是覆盖的同一个逻辑（同样的测试用例，测试步骤和检查点）
7、分析用例的测试方法是否有改进，是否能够直接通过代码静态走读、接口测试、自动化测试（包括编写脚本）、引入工具等等来进一步提高我们的测试效率（如果测试不懂代码，这个可以让开发帮忙完成）
C、友情提醒：
1、仅仅只能保证已有的逻辑没有问题，但是可能出现部分情况没有处理导致失效的情况，可以通过后面的场景用例和需求用例来补充覆盖（或者过程发现新的问题，新增用例）
2、逻辑里面异常情况考虑不充分，导致测试用例也相对比较欠缺，可以通过对每个逻辑进行头脑风暴，分析是否有其他异常情况，并且评审时重点评审这块（取重点的业务逻辑进行讨论还可以，这块看实际情况去评定，不一定所有人都有时间去参与）
3、研发的逻辑有可能本身就是错误的，但是如果顺着研发的逻辑去编写用例时会导致用例也有问题，达不到测试目的，所以需要从需求和设计的角度去提前分析逻辑是否有问题（测试不能在开发的角度去写用例，根据确定的需求去写用例才是王道）
4、过程中研发的逻辑可能变化比较快，这样会导致逻辑测试用例也要经常变化，所以需要保证研发的编码是与设计一致的，并且逻辑是尽量根据设计来进行的（需求、开发和测试在版本研发的过程一定要协商好）。另外，逻辑用例的设计可以在编码中后期进行，这样的改动会少点
A、用例编写过程：
1、搞清楚客户的原始需求，为什么需要这个功能，能够给客户带来的价值是什么（根据实际去评定，客观）
2、查看需求说明书里面的客户使用的典型用户场景，并且整合到场景用例里面（正常场景和异常场景要先设定好）
3、在需求说明书的基础上进一步分析客户还可能有哪些实际的使用场景（主要是整个客户的拓扑结构）（最好自己画流程图，方便理解）
4、客户会怎样去配置该模块以满足什么样的需求（评审需求的过程就要确定下来了）
5、过程中客户会有哪些操作（客观去分析，多站在客户角度去分析）
B、用例评审过程：
1、通知到相关模块负责人、产品经理、项目经理和主管来进行评审，主要是分析还可能有哪些场景没有考虑到，最好是能够有具体的客户（细节根据具体需要去评审，可以内部先评审）
2、安排讲解该模块的场景，保证用例责任人对模块场景是非常熟悉的，并且过程中分析是否可能会有其他情况，来进一步完善场景用例（对应写用例的人一定要清楚自己做什么，评审过程也要知道项目整体做什么）
C、友情提醒：
1、模块用户场景尽量是有真实的客户，而不是自己yy出来的（客观分析）
2、模块用户场景最好是完整的客户使用过程，而不是某一个测试点（系列功能流程）
3、并不是所有的模块都有场景用例
三、基于需求文档的用例设计过程：
A、用例编写过程：
1、参照需求表（功能清单或者需求规格说明书），并且对照前面的业务逻辑用例和场景用例，检视是否覆盖到所有需求，没有的分析下原因，是否业务逻辑用例or场景用例考虑的还不充分，是的话补充到上面，不是的话则补充到需求用例里面
2、充分利用相关的用例编写技术，包括：边界值分析法、等价类分析法、 错误类推测法、路径覆盖法、因果分析法、正交分析法等（测试用例编写用到的方法一定要清楚）
3、分析用例是否能够通过自动化or其他测试手段来覆盖到（过程所用到的工具，是否能满足到）
B、用例评审过程：
1、对照需求表（功能清单或者需求规格说明书）来进行检视，是否全部覆盖到，不仅仅是测试用例，还包括测试步骤和期望结果，避免因为依赖研发的逻辑来设计用例导致问题（如果没有需求文档之类的，一定要先和需求搞清楚要做什么，才知道怎么写，怎么测试）
2、评审该部分用例是否跟前面的逻辑用例和场景用例冗余
3、分析用例是否能够通过自动化or其他测试手段来覆盖到
C、友情提醒：
1、基于需求的用例仅仅是针对前面没有覆盖到的用例的补充，所以这部分用例应该相对比较少，如果发现比较多的话可以分析下是否研发的一些逻辑没有覆盖到相关地方（或者开发的过程是需求变更了）
四、模块测试方法说明（提高该模块的用例执行效率）：
1、将该模块的业务逻辑图（思维导图和流程图）放到用例的指定目录，这样方便给评审人员讲解，以及后面相关人员的学习
2、将该模块的排查和定位问题的方法给出来，并放到指定目录，能够有效指导后面人员排查和定位问题（这个看个人能力去执行）
3、将该模块的测试思路和测试重点给出来，并放到指定目录，能够有效的指导该模块的测试策略（关键的测试计划，一定要先定义好测试策略）
本文有个人建议，略作修改。
相关文章引自http://www.51testing.com/html/25/181625-851759.html
