51Testing软件测试论坛

标题: 测试用例编写技巧 [打印本页]

作者: lsekfe 时间: 2017-9-28 15:01
标题: 测试用例编写技巧
测试用例是软件测试工作中非常重要的一步，很多软件测试工程师都会编写测试用例，但测试用例设计的质量可能存在一些不足，下面咱们就来说说，如何编写优秀的测试用例，有哪些技巧可寻。
　　一．首先我们来说说好的测试用例的标准：
　　A.覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑），即正常流和异常流；
　　B.覆盖到所有的典型用户场景；
　　C.覆盖到所有的需求点；
　　D.测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短；
　　E.没有冗余的用例；
　　F.测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚；
　　二．如何达到以上的标准：
　　达到上述所说标准，需要从三个方面着手；
　　1.基于需求的用例编写过程；
　　2.基于逻辑的用例编写过程；
　　3.基于用户场景的用例编写过程；
　　下面我们针对这三个方面展开详细的讲解；
　　（1）基于需求的用例设计过程：
　　A、用例编写过程：首先参照需求文档以及项目原形交互图，划分模块，以及具体的测试点，然后整理出详细的测试点文档，然后根据文档一条条编写测试用例；充分利用相关的用例编写技术，包括：边界值分析法、等价类分析法、错误类推测法、路径覆盖法、因果分析法、正交分析法等；分析用例是否能够通过自动化或者其他测试手段来覆盖到；
　　B、用例评审过程：首先对照需求表来进行检查，是否全部覆盖到，不仅仅是测试用例，还包括测试步骤和期望结果，避免因为依赖研发的逻辑来设计用例导致问题；其次评审该部分用例是否跟前面的逻辑用例和场景用例冗余；最后分析用例是否能够通过自动化或者其他测试手段来覆盖到；
　　（2）基于逻辑的用例编写过程
　　A.用例编写过程：首先进行全面的需求分析，分析系统包含哪些功能模块，各功能模块下富含哪些子模块，每个模块之间的逻辑关系，分析一下这个需求是否存在不合理的地方；其次完成业务逻辑图或者流程图，需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，正常的逻辑过程以及异常的逻辑过程，并且自己能够理解为什么这样处理；再根据自己的理解分析每个逻辑的处理是否完善，是否有没有覆盖到的地方，整合成具体的文档，小组讨论并提交缺陷预防bug；另外根据逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖；最后有一个原则要注意，用例要按照10分钟原则，即保证10分钟内能够执行完成，此原则针对较复杂的逻辑操作，对于大部分的测试用例都可以保证；
　　B.用例评审过程：前期要求参与审核的人员自己先进行需求分析，然后把自己不理解或觉得有问题的地方记录下来；
　　然后项目主负责人先讲解整个业务逻辑图，需要保证评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这样做；并且分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况（采用头脑风暴的方式），大家在一起讨论各种可能存在的情况，然后进行评判和筛选，找出更多的测试点；
　　分析业务逻辑的异常处理情况（是否每个业务逻辑都有对异常情况进行处理，也采用头脑风暴的方式）；
　　是否将逻辑的用例分类比较合理，让大家通过逻辑很容易就找到对应的用例；
　　分析是否所有的逻辑都能够找到对应的用例（通过逻辑找到对应的用例）,包括前面没有考虑到的逻辑；
　　分析用例是否有冗余，是否多个用例都是覆盖的同一个逻辑（包括测试步骤和检查点）；
　　分析用例的测试方法是否有改进，是否能够直接通过代码静态走读、接口测试、自动化测试（包括编写脚本）、引入工具等等来进一步提高我们的测试效率；
　　C、此方法可能存在的一些风险：仅仅只能保证已有的逻辑没有问题，但是可能出现部分情况没有处理导致失效的情况，可以通过后面的场景用例和需求用例来补充覆盖；逻辑里面异常情况考虑不充分，导致测试用例也相对比较欠缺，可以通过对每个逻辑进行头脑风暴，分析是否有其他异常情况，并且评审时重点评审这块；研发的逻辑有可能本身就是错误的，但是如果顺着研发的逻辑去编写用例时会导致用例也有问题，达不到测试目的，所以需要从需求和设计的角度去提前分析逻辑是否有问题；过程中研发的逻辑可能变化比较快，这样会导致逻辑测试用例也要经常变化，所以需要保证研发的编码是与设计一致的，并且逻辑是尽量根据设计来进行的另外，逻辑用例的设计可以在编码中后期进行，这样的改动会少点；
　　（3）基于场景的用例设计过程：
　　A、用例编写过程：整理清楚客户的原始需求，为什么需要这个功能，能够给客户带来的价值是什么；查看需求说明书里面的客户使用的典型用户场景，并且整合到场景用例里面；在需求说明书的基础上进一步分析客户还可能有哪些实际的使用场景（主要是整个客户的拓扑结构）；客户会怎样去配置该模块以满足什么样的需求（头脑风暴）；过程中客户会有哪些操作（头脑风暴）；
　　B、用例评审过程：安排相关项目经理和主管来进行评审，主要是分析还可能有哪些场景没有考虑到，最好是能够有具体的客户；；安排讲解该模块的场景，保证用例责任人对模块场景是非常熟悉的，并且过程中分析是否可能会有其他情况，来进一步完善场景用例
　　C、友情提醒：模块用户场景尽量是有真实的客户，而不是自己臆想出来的；模块用户场景最好是完整的客户使用过程，而不是某一个测试点；并不是所有的模块都有场景用例；
　　三、模块测试方法说明（提高该模块的用例执行效率）：
　　1、将该模块的业务逻辑图放到用例的指定目录，这样方便给评审人员讲解，以及后面相关人员的学习；
　　2、将该模块的排查和定位问题的方法给出来，并放到指定目录，能够有效指导后面人员排查和定位问题；
　　3、将该模块的测试思路和测试重点给出来，并放到指定目录，能够有效的指导该模块的测试策略。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)