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