Linux培训

亿元级外企Java培训企业

  • 全国服务监督电话4001118989
linux培训 > Linux职场 > 软件测试小用例 大智慧
  • 软件测试小用例 大智慧

    发布:linux培训  来源:网路  时间: 2017年03月22日

  • 测试用例的编写是一个测试人员的基本功,无论做什么方式的测试,都离不开测试用例,一份好的测试用例能够在测试执行过程中给予非常好的指导意义。...

  • 测试用例的编写是一个测试人员的基本功,无论做什么方式的测试,都离不开测试用例,一份好的测试用例能够在测试执行过程中给予非常好的指导意义。

    测试用例的产出一般来说,是根据产品(业务)的需求分析后得出测试需求,再根据测试需求进行细分,得到测试用例。这中间的学问就非常大了。

    测试设计

    软件测试的目的就是保证软件的质量,漏测是最大的忌讳,因此在测试设计过程中,如何防止设计遗漏是非常关键的。产品(业务)的需求对功能上描述是比较清晰的,按照功能来设计,只要设计的方法正确,那么功能上基本不会有问题。但是这仅仅是从业务的角度来分析问题,还需要分析开发的设计文档,根据开发的设计,适当的补充一些需求文档上没有覆盖的点。最后,还需要用自己的经验做一些探索性的测试用例。

    所以一个好的测试设计应该包括以下几个部分:

    · 业务功能的覆盖

    · 开发设计中针对业务功能的补充

    · 某些专题模块的单独测试

    · 工作经验的探索设计

    测试用例的颗粒度

    这个问题在早期工作中有专门尝试过,不同的设计方式对后续的维护以及执行影响非常大,因此在项目的初期就要想好用例设计的颗粒度。在网上看了一些文章,对于这点的理解都不深,我简单列一下,不同颗粒度的优缺点如下:

    粗颗粒度

    优点

    · 设计的周期短

    · 可维护性强

    · 能够快速的应对频繁变更的需求

    · 执行时灵活度高,能够有效的调动执行人员的积极性

    · 占用测试资源少,少量的人员花费少量的时间即可完成

    缺点

    · 漏测的可能性高

    · 项目质量过于依赖测试人员的职业素养

    · 用例数量少

    · 适用场景

    粗颗粒度的测试用例相对适合小团队适用,人少,时间短,而且能够快速的相应变化的需求。当然,缺点也是非常明显的,没有了详细的测试用例的束缚,每个点的质量就非常依赖测试人员的素质,需要测试人员有很高的职业道德,并且对于业务的理解程度,系统的架构的熟悉程度都有很高的要求。

    在大项目中也并不是不能使用,我曾经在项目中这么干过,说实话,效果还不错,在大项目中,开发人员数量多,对于业务的理解也是参差不齐,很有可能他们没有按照约定的方式进行实现,而这种情况在大项目中会导致大量的测试用例需要维护,而粗颗粒度的设计,能够低成本的快速响应这些变化。

    我在缺点中的列的用例数量少,不是开玩笑随便列的。一般来说要拿资源都是以数据说话,测试用例数量少就意味着,你的谈判筹码就少,能申请到的资源也就少,但是在项目不减少的情况下,工作量是固定的,因此每个人的工作量就会相应的增加,这也是进行粗颗粒度拆分时需要注意的地方

    细颗粒度

    优点

    · 漏测的可能性小

    · 风险左移,对于管理者来说容易把控

    · 用例数量多,利于申请资源

    · 不依赖测试人员的综合素质

    · 能够针对测试用例提前准备大量的测试数据

    缺点

    · 测试设计的周期长

    · 可维护性极弱

    · 执行束缚大

    适用场景

    细颗粒度的好处也显而易见,能够把所有风险集中到设计阶段,对于管理者来说省了非常大的精力来做其他事,但是由于精细的设计,导致小团队没有很多的资源往测试设计中投入,因此细颗粒度的设计比较适合大团队,对于测试人员的要求非常低,即使是刚入职的新人也能够快速的上手进行测试。在测试颗粒度细的情况下,能够非常清晰的了解将来执行阶段需要使用的数据,环境等资源,因此能够将数据提前准备,这将极大的减少测试执行阶段的时间。

    当然,缺点也是显而易见的,需求做一点变更或者开发不老实一点,马上就会血崩,案例维护的成本非常之高,尤其是大项目的用例,维护起来非常的折磨人。而且在执行过程中实际结果和用例产生一点偏差,都会让执行人员非常的尴尬。

    总结

    总结了那么多内容,都是一些理论,在实际的工作中是可以穿插起来进行的。测试用例的颗粒度在一个项目中是可以共存的,并不是所有的用例都要粗或者都要细,可以根据自身的情况做一些调整,比如按照业务进行拆分的时候,可以把自己熟悉的业务做粗颗粒度的编写,变化非常小的部分做细颗粒度的编写,提前做好分工的情况下,根据不同执行人员的素质也可以做颗粒度的拆分。理论知识永远是死的,人才是活的,根据自己的实际情况合理的利用理论知识才是自我提升的途径。

  • 上一篇:我们需要使用Linux的十个原因

    下一篇:没有下一篇了

网站导航
2001-2016 达内时代科技集团有限公司 版权所有 京ICP证8000853号-56