小用例，大智慧
本帖最后由 博为峰网校 于 2017-9-14 11:47 编辑背景最近面试了几个人，问了一些关于测试用例的问题，但是基本上没有能回答的让我满意。作为一个测试人员，测试用例的编写绝对是非常重要的技能。别小看测试用例，小小的用例里面包含了大大的只会。测试用例毫无疑问，测试用例的编写是一个测试人员的基本功，无论做什么方式的测试，都离不开测试用例，一份好的测试用例能够在测试执行过程中给予非常好的指导意义。测试用例的产出一般来说，是根据产品（业务）的需求分析后得出测试需求，再根据测试需求进行细分，得到测试用例。这中间的学问就非常大了。测试设计软件测试的目的就是保证软件的质量，漏测是最大的忌讳，因此在测试设计过程中，如何防止设计遗漏是非常关键的。产品（业务）的需求对功能上描述是比较清晰的，按照功能来设计，只要设计的方法正确，那么功能上基本不会有问题。但是这仅仅是从业务的角度来分析问题，还需要分析开发的设计文档，根据开发的设计，适当的补充一些需求文档上没有覆盖的点。最后，还需要用自己的经验做一些探索性的测试用例。所以一个好的测试设计应该包括以下几个部分：· 业务功能的覆盖· 开发设计中针对业务功能的补充· 某些专题模块的单独测试· 工作经验的探索设计测试用例的颗粒度这个问题在早期工作中有专门尝试过，不同的设计方式对后续的维护以及执行影响非常大，因此在项目的初期就要想好用例设计的颗粒度。在网上看了一些文章，对于这点的理解都不深，我简单列一下，不同颗粒度的优缺点如下：粗颗粒度优点· 设计的周期短· 可维护性强· 能够快速的应对频繁变更的需求· 执行时灵活度高，能够有效的调动执行人员的积极性· 占用测试资源少，少量的人员花费少量的时间即可完成缺点· 漏测的可能性高· 项目质量过于依赖测试人员的职业素养· 用例数量少适用场景粗颗粒度的测试用例相对适合小团队适用，人少，时间短，而且能够快速的相应变化的需求。当然，缺点也是非常明显的，没有了详细的测试用例的束缚，每个点的质量就非常依赖测试人员的素质，需要测试人员有很高的职业道德，并且对于业务的理解程度，系统的架构的熟悉程度都有很高的要求。在大项目中也并不是不能使用，我曾经在项目中这么干过，说实话，效果还不错，在大项目中，开发人员数量多，对于业务的理解也是参差不齐，很有可能他们没有按照约定的方式进行实现，而这种情况在大项目中会导致大量的测试用例需要维护，而粗颗粒度的设计，能够低成本的快速响应这些变化。我在缺点中的列的用例数量少，不是开玩笑随便列的。一般来说要拿资源都是以数据说话，测试用例数量少就意味着，你的谈判筹码就少，能申请到的资源也就少，但是在项目不减少的情况下，工作量是固定的，因此每个人的工作量就会相应的增加，这也是进行粗颗粒度拆分时需要注意的地方细颗粒度优点· 漏测的可能性小· 风险左移，对于管理者来说容易把控· 用例数量多，利于申请资源· 不依赖测试人员的综合素质· 能够针对测试用例提前准备大量的测试数据缺点· 测试设计的周期长· 可维护性极弱· 执行束缚大适用场景细颗粒度的好处也显而易见，能够把所有风险集中到设计阶段，对于管理者来说省了非常大的精力来做其他事，但是由于精细的设计，导致小团队没有很多的资源往测试设计中投入，因此细颗粒度的设计比较适合大团队，对于测试人员的要求非常低，即使是刚入职的新人也能够快速的上手进行测试。在测试颗粒度细的情况下，能够非常清晰的了解将来执行阶段需要使用的数据，环境等资源，因此能够将数据提前准备，这将极大的减少测试执行阶段的时间。当然，缺点也是显而易见的，需求做一点变更或者开发不老实一点，马上就会血崩，案例维护的成本非常之高，尤其是大项目的用例，维护起来非常的折磨人。而且在执行过程中实际结果和用例产生一点偏差，都会让执行人员非常的尴尬。总结总结了那么多内容，都是一些理论，在实际的工作中是可以穿插起来进行的。测试用例的颗粒度在一个项目中是可以共存的，并不是所有的用例都要粗或者都要细，可以根据自身的情况做一些调整，比如按照业务进行拆分的时候，可以把自己熟悉的业务做粗颗粒度的编写，变化非常小的部分做细颗粒度的编写，提前做好分工的情况下，根据不同执行人员的素质也可以做颗粒度的拆分。理论知识永远是死的，人才是活的，根据自己的实际情况合理的利用理论知识才是自我提升的途径。
重要通知：
博为峰网校助力2017求职季，特别推出测试集训营，更多精品课程打折、送券……惊喜不停歇，最低五折起限时抢购，快来~活动链接：http://h.atstudy.com/activity/
用例是基础 说得好！ 好久没写过用例了 有没有编写测试用例的经典书籍？感谢推荐
页:
[1]
