测试反模式的思考 -凯发app官网

测试交流1057字数 1799阅读5分59秒阅读模式
测试反模式:有效规避常见的92种测试陷阱
45.28

最近在看《测试反模式:有效规避常见的 92 种测试陷阱》,书中的内容划分得太细了。但它引导笔者去做了更多的思考,虽然这本书的出版时间比较早(2015 年),但很多测试陷阱依旧存在,推荐大家阅读。下面分享几个自己的观察和思考。

所谓的反模式, 是指用来解决问题的带有共同性的不良方法。它们已经经过研究并分类,以防止日后重蹈覆辙,并能在研发尚未投产时辨认出来。文章源自玩技e族-https://www.playezu.com/710798.html

01

沉迷功能测试,忽视代码能力文章源自玩技e族-https://www.playezu.com/710798.html

虽然说业务测试是测试工作的本质,所有的技术都应该为业务服务,有了一定的代码能力后,可以更好地辅助测试,不论是从风险分析还是测试效能提升来看,都是有益无害的。但很多人却不屑去学习代码,认为那是开发的事,如果测试人员有代码能力了,为什么不去做开发(开发比测试高一等?)。测试学习代码是不务正业,点点点的业务测试才是测试的王道。文章源自玩技e族-https://www.playezu.com/710798.html

这类想法其实很危险,因为业务能力的可迁移性很小(特殊行业如银行、证券类、专业领域性强的行业除外),那么当你换家公司时,你的业务积累并不能成为很大的优秀。而代码能力是通过用的,它可以协助你完成代码走读,快速熟悉系统,对系统做更高层次层次地分析。同时,有一定代码能力的人,还可以通过编写各类小工具,来提升测试效率。文章源自玩技e族-https://www.playezu.com/710798.html

懂代码,一定会让你在测试路上走得更远,它不影响你对业务的理解。两条腿走路,会更稳。文章源自玩技e族-https://www.playezu.com/710798.html

02

沉迷自动化测试,忽视实际效果文章源自玩技e族-https://www.playezu.com/710798.html

自动化测试仿佛成为测试团队的标配。理想情况下,自动化测试确实能提升效率,但是它有很多前提和约束条件,并不是写个框架,跑几个用例就能够解决的。笔者见过太多自动化测试平台,每天执行的有效用例数不超过 100 个,那有什么意义呢?文章源自玩技e族-https://www.playezu.com/710798.html

在落地自动化测试前,需要从研发侧产出标准化的内容,比如接口测试,如果没有标准、有效的接口文档,而是让测试通过抓包来编写接口测试用例,其实是没什么意义的。维护成本过高。如何设计接口业务场景,如何准备测试数据,如何设计有效的断言,才是接口测试的核心,而不是去追求所谓的接口覆盖率。文章源自玩技e族-https://www.playezu.com/710798.html

标准化、自动化、持续化,自动化测试才能形成有效的战斗力,为业务提供更多质量保障。文章源自玩技e族-https://www.playezu.com/710798.html

03

沉迷马上就干,忽视测试策略和设计文章源自玩技e族-https://www.playezu.com/710798.html

在敏捷测试的环境下,速度并不是唯一追求。时间紧,任务重,直接开干最重要?如果没有全局的思考,只依赖当前迭代的需求内容进行测试,很容易一叶障目,忽略全局。设计测试策略的目标是 “减少缺陷的出现和发布”。其中 “减少缺陷的出现” 可以通过测试前移等方法来解决,在进行软件需求分析和架构设计的时候发现缺陷;而 “减少缺陷发布” 可以使用各种测试方法、技术来验证和测试编码完成的功能。文章源自玩技e族-https://www.playezu.com/710798.html

在一些核心特性的迭代中,在一些基础能力构建的迭代中,还是需要停下来,好好思考一下如何开展更有效的测试方法,我们需要提前为这个迭代的测试活动做些什么。文章源自玩技e族-https://www.playezu.com/710798.html

当然,这份测试策略不宜太长,一页内最好,要保证团队所有成员能够随时看到这份策略并得到团队的整体认可。文章源自玩技e族-https://www.playezu.com/710798.html

04

沉迷发现缺陷,忽视缺陷预防文章源自玩技e族-https://www.playezu.com/710798.html

手里有锤子,哪里都是钉子。缺陷是质量保障活动过程中的伴随物,并不是最终的目标。测试不应该以发现缺陷为荣。片面所求缺陷数量,测试的目标会变成破坏软件,测试人员绞尽脑汁多提 bug。而开发的目标是实现功能,bug 越多说明实现效率越低。这种追求数量的度量方式很容易引发团队的割裂、针对重大线上问题的追责、质量工作重点的偏离等现象。文章源自玩技e族-https://www.playezu.com/710798.html

测试活动多数情况已经由验证质量、发现问题,转化为构建质量,预防问题,更多地从全员质量意识构建的场景下,去思考如何提升测试效率,更符合当下研发团队对测试的要求。文章源自玩技e族-https://www.playezu.com/710798.html

05

沉迷测试环节,忽视整体效能文章源自玩技e族-https://www.playezu.com/710798.html

当我们提到提升测试效率时,往往想到的都是提升测试执行效率、提升自动化水平。这些活动确实能在一定程度上提升测试环节的效能。但是从更大的软件测试生命周期(stlc)来看,测试是否是流程链路上的最大瓶颈?最大的返工和浪费是否发现在的测试环节?文章源自玩技e族-https://www.playezu.com/710798.html

在测试活动的执行过程中,我们不要忽略了团队的目标。我们需要从更高的维度去保障质量。测试左移,确认验收条件,避免返工。测试右移,线上产品监控,提前发现问题。都是测试人员可以去改进的点,可能会有更大的发现和收获。文章源自玩技e族-https://www.playezu.com/710798.html

06

习惯了的事,也不总是对的。当下舒服的,也不一定是正确的。软件行业已经发生了很大的变化,不怪企业对测试人员的技术要求不断的提高。而是应该庆幸测试的门槛越来越高,你才有更多的机会脱颖而出。文章源自玩技e族-https://www.playezu.com/710798.html

否则,凭什么是你?

继续阅读

风险通知:非原创文章均为网络投稿真实性无法判断,侵权联系

免责声明:内容来自用户上传发布或新闻客户端自媒体,切勿!切勿!切勿!添加凯发k8国际官网首页入口的联系方式以免受骗。

评论  10  访客  10
  1. vanessa

    内容划分得细,就说明还是得具体问题具体分析,具体业务具体分析,容错率低的业务只能做预防,容错率高的就可以做预警,毕竟灰度发布做好了比多招十个测试效果都好

  2. zhaohyperion

    提个 bug 代码能力是通(过)用的。
    其他的都很赞同,实际上也是测试在项目实践中必然要走的路子,随着敏捷开发的流行,测试左移,全员测试,测试的代码能力,线上监控都是必须的,不然很难保证项目质量和流转速度,同时要辅助建立开发的测试能力 or 测试思维,加强自测效果,减少测试部门耗时,加强项目需求的评审质量,提前构建测试边界和测试策略。

  3. ckl的思考

    我也是自己在反思,有时候也会犯错,哈哈。

  4. ckl的思考

    没那么严格的界线,相对而言,研发过程还是比较透明的,不认论是测试人员还是测试组长,都能看的见。可以适当的去尝试推进。或者找一些 “帮手”,或者和开发维护下感情,都是可取的。不要被自己的限制了。

  5. ckl的思考

    两条腿走路,极端了都不行。技术辅助,业务主为。

  6. 王稀饭

    很不错,这里面提及的问题我自己踩了个遍,甚至有些点到了现在还会因为自己的角色职能所限不会第一时间意识到,要反复给自己提醒

  7. smobee

    这篇文章,我总结了几个关键点:
    1.“两条腿走路,会更稳。”
    2.“每天执行的有效用例数不超过 100 个,那有什么意义呢?”
    3.“如何设计接口业务场景,如何准备测试数据,如何设计有效的断言,才是接口测试的核心,而不是去追求所谓的接口覆盖率。”
    4.“其中 “减少缺陷的出现” 可以通过测试前移等方法来解决,在进行软件需求分析和架构设计的时候发现缺陷”
    5.“沉迷测试环节,不可忽视整体效能”
    6.“应该庆幸测试的门槛越来越高,你才有更多的机会脱颖而出。”

  8. smobee

    第六点,我觉得,讲的真好,“海上风浪越大,鱼越值钱”

  9. smobee

    第五点那个,我觉得对于大部分测试人员,很难去实现,这个应该只有测试组长,测试主管级别的才能接触到吧。

  10. ouroboros

    我司存在过渡强调代码能力,忽略了业务的问题。。。积弊多年,导致业务断层相当严重,哈哈

发表评论

匿名网友