职业经验 小用例,大智慧

wyb199026 · 发布于 2017年3月15日 · 最后由 shimiao 回复于 2017年3月23日 · 2177 次阅读
本帖已被设为精华帖!

社区主要是以技术为主,但是我个人觉得测试的基本功也是非常重要的,最近面试发现要找一个靠谱的测试是真心难。。。。是世界太浮夸了么?

背景

最近面试了几个人,问了一些关于测试用例的问题,但是基本上没有能回答的让我满意。作为一个测试人员,测试用例的编写绝对是非常重要的技能。别小看测试用例,小小的用例里面包含了大大的只会。

测试用例

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

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

测试设计

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

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

  • 业务功能的覆盖
  • 开发设计中针对业务功能的补充
  • 某些专题模块的单独测试
  • 工作经验的探索设计

测试用例的颗粒度

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

粗颗粒度

优点

  • 设计的周期短
  • 可维护性强
  • 能够快速的应对频繁变更的需求
  • 执行时灵活度高,能够有效的调动执行人员的积极性
  • 占用测试资源少,少量的人员花费少量的时间即可完成

缺点

  • 漏测的可能性高
  • 项目质量过于依赖测试人员的职业素养
  • 用例数量少

适用场景

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

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

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

细颗粒度

优点

  • 漏测的可能性小
  • 风险左移,对于管理者来说容易把控
  • 用例数量多,利于申请资源
  • 不依赖测试人员的综合素质
  • 能够针对测试用例提前准备大量的测试数据

缺点

  • 测试设计的周期长
  • 可维护性极弱
  • 执行束缚大

适用场景

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

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

总结

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 30 条回复
110

基本功当然是最重要的。很多社区的人一看就是个烂测试,基本功一塌糊涂。比如:

  1. 不按规则发帖 —— 这点说明他平时工作,从来不看上下文,一个功能可能连需求都没摸清就上手测试了。
  2. 提问非常不专业 —— 这点说明他报bug,写case肯定随心所欲,毫无条理和依据。
  3. ....

楼主写的不错,顺便可以看看 https://testerhome.com/topics/7190,这篇排版烂了点,但是内容不错,一看就知道 @tmq 腾讯的风格。

110 Lihuazhang 将本帖设为了精华贴 3月15日 07:14
2606

能否列下你面试提的具体问题,以及你期望的答案呢?

5764
110Lihuazhang 回复

我感觉现在太浮夸了,都喜欢了解各种技术相关的知识,缺忽略了测试最重要的技能。

TMQ的文章还是不错的,应该是按照他们博客平台的规范来写,然后直接就copy过来了,原文排版就比较正常了

14549
5764wyb199026 回复

最近我也有些同感,感觉大家都在追求技术技术,还说什么会功能测试+懂点自动化的人以后路越来越窄。。。。 我就不明白了, 我们技术肯定是要为业务服务的, 如果整天追求牛B的最新技术,但是不适用于当前的项目,脱离了实际, 感觉没有什么毛线用。 我觉得需要根据自己的项目来选择相对应的技术(这个技术不一定是现在最流行和牛B的),但是是适合的,这种基本的手工测试还是不能抛弃的。。。 或者有的公司已经直接抛弃了手工而是,全是用代码测试代码???求大神们指导下

110
5764wyb199026 回复

tmq的内容是不错,我从来没否定过。但是他不遵守社区的规则。既然合作了,那就互相遵守规则尊敬合作伙伴。从他发帖来看,tmq不值得我尊敬,因为他不尊敬我啊。

96

测试用例设计,推荐Lee Copeland的A Practitioner's Guide to Software Test Design
https://www.amazon.com/Practitioners-Guide-Software-Test-Design/dp/158053791X
虽然有10多年了,但基本的用例设计方法还是这些,作为测试人员,最基础的这些方法理论要精通

5764
2606michael_wang 回复

我的问题就是,在测试资源不同时,如何有针对性的设计测试用例。

文章的内容当然也是我后来经过思考整理出来的结果,当时我期望面试者能够说出测试资源宽松和测试资源紧缺时的设计方案,即使说的不详细,起码针对这些情况会有一些不同点。但是面试者给我的答案永远是 按照需求产出用例。。。。

5764
110Lihuazhang 回复

这个图好棒

5764
32kanchi240 回复

多谢,有时间一定去读读

96
5764wyb199026 回复

哈哈,不客气,上次还在你博客问你问题的呢

5764

我觉得排版还是很重要的,写文章有一个好的排版,是对读者基本的尊重。

5764
32kanchi240 回复

哈哈

110 Lihuazhang 散了吧 中提及了此贴 3月15日 11:36
5512

这里是测试技术的社区,对于测试来说美观、排版、体验,这些都是作为一个测试职业病。这跟社区高不高端一点关系都没有。

1517

感谢社区管理员,好的东西不仅内在好,外在也要好;好的排版真心很重要;

2606
110Lihuazhang 回复

哈哈哈

2606
5764wyb199026 回复

嗯,对。
但是没有独立带过项目的普通tester可能没有这个意识

110

真正能做好用例设计的不多。类似这样的书籍和文章也越来越少了。

5764
110Lihuazhang 回复

恩,是啊,能找到的都是一些简单的东西,稍微深入的知识就没了

4181

我喜欢这篇文章。好的用例都没有搭20个牛逼的自动化测试框架,满脸的macaca appium意义何在?这些技术框架只是一些招式,如果过于崇拜技术测试行业就要剑走偏锋了。

96

赞,学习了,来了这个社区思考问题的角度更全面了

12260

感觉每天逛逛社区总能获益良多.楼主说的正是最近在深度思考的,值得借鉴.👍

2071

感觉自己也有这种盲目追求技术,而忽视了测试基本功的感觉 ,学习了,谢谢!

5764
2071kaige201314 回复

其实我也是最近一直在看技术,结果写案例的时候发现基本功有点落后了,然后才有这种感想

1870

学习啦,开发文档中也是简简单单的接口文字,特别的耦合的那部分会漏测试用例。说真的,现在最好的补充一点是从代码上找出关联的测试用例。特别是不同开发者中对相同功能的重构。起码现在一旦修改到那些功能,设计测试用例如下
1、按照需求
2、按照文档(而且最好和开发这者)
3、查看该涉及到的旧功能代码(这可以看到关联性)
其实探索性的测试用例本身就是属于后期维护添加的测试用例

4442

非常感谢楼主的分享,受益匪浅,我也曾想过这个问题,一直没想清楚。另外就同一个公司而言,不同的测试人员设计出来的测试用例也是差别很大的,很多时候组长审核时也比较难把握,到底哪些人设计的更合理呢,如何培养他们去设计,根据不同的项目或业务又改采用什么样的设计策略也值得我们深思~

—— 来自TesterHome官方 安卓客户端

104

记得更新打赏二维码

5764
104seveniruby 回复

已更新😀

96

业务永不过时,脱离了业务的技术没啥用。新技术可以有,要结合业务使用,而且能发挥作用,不然也是浪费时间。

16087

社区主要是以技术为主,但是我个人觉得测试的基本功也是非常重要的。。。。。哈哈哈

13575

之前觉得测试用例无所谓,现在跟你一样的感觉,测试用例太重要了,在写用例的时候能发现需求逻辑漏洞,能把流程完全弄懂吃透,在测试思维混乱的时候,看看用例一切都明白了,都感觉用例就是依靠

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册