zoukankan      html  css  js  c++  java
  • 重读《从菜鸟到测试架构师》-- 从专家到高手

    上回说到,工作了不长时间的小艾努力地梳理着软件尤其是测试领域的知识,比如团队中的角色有哪些分工,每一个分工都在做什么需要掌握什么。在测试的领域里如何判断软件质量的好坏,用什么样的方法来保障软件的质量,发现了bug如何定位及分析……做好了笔记的小艾发现自己跟刚入职时候的疑惑与迷茫有了明显的区别。

    他开始对组织结构有了一定的认识,对工作内容及工作方法有了自己的一点理解,及对测试相关的专业技能也有了些许的掌握。从这里可以看到,小艾的工作能力也确实蛮强的,果然爱思考的孩子进步快~哈哈……

    此时的小艾开始好奇自己是否已经摆脱了菜鸟的头衔,什么样的自己可以骄傲地称为测试专家?也开始疑惑,专家是不是就意味着技术上已经达到了巅峰?别人又是怎么定义优秀的测试工程师呢?

    这不,小艾又一次屁颠屁颠地去找导师聊天,不,请教去了~~ 说到这里,我也想要有这样一位导师啊,知无不言,言无不尽,求带飞啊~~ 好吧,我们跟着小艾一起飞吧~

    新手、专家、高手

    导师再一次细心而又耐心地向小艾解说了起来。刚开始接触一个新的领域时,对这个领域一无所知或者知之甚少,对于这个领域,我们就是新手。然而,同一个人,在一个领域是新手,并不妨碍他在另一个领域是专家。

    作为测试工程师新手,要成长为专家,需要对测试的相关专业技能进行系统的学习和实践,学习曲线主要包括学习测试和开发方法、测试计划和测试设计、测试文档的编写、发现和解决问题的一般方法等。随着经验的累积,总有一天会成长为测试专家。

    测试专家对相关的测试技能和工具都已经熟练地掌握,能够以标准化的方式策划并完成任务。专家的特点表现在对流程的严格把握。

    而高手则是专家更进一步的发展方向,高手对于发现问题、解决问题,有更多超出一般步骤的灵感和直觉,这种灵感和直觉是建立在对系统的深入理解及高手本身强大的洞察力基础上的。

    如果说新手到专家的成长过程是学习硬技能的过程,那么专家成长为高手更在于软技能的修为。软技能归根结底是思考能力和分析能力的提高,而重点在于思考的方法和技巧。

    像外行一样思考,像专家一样实践

    前面我们一直在重申测试的本质是发现问题和解决问题的过程。上一章节也说到了自顶向下与自底向上的方法来帮助分析问题,但对于一些非常规的问题,这两种方法未必有效,可能需要一双不走寻常路的鞋子,hmm....跑题了……应该需要一些非常规的方法来应对。

    作为一名测试领域的新人,小艾在遇到这样非常规的问题上可能会有两种情况,第一种是束手无策,另一种是天马行空。当然,看官们可能会说,还有一种情况,他会去找导师聊天……hmm...好吧,无论是现在还是曾经,同样作为新人的我们会选择怎么做呢?看官们先停下来稍微想一想吧~

    回到小艾身上,束手无策估计是很多新人们面对未知问题的第一反应,然而小艾作为一枚热爱思考的好苗子,不排除有天马行空的想法,那么天马行空在应对非常规问题上来说好不好?其实不绝对,可能不着边际的想法会扰乱问题的本身,但也可能会带来一些意想不到的效果。这种天马行空的方式估计是思维受限的测试专家们往往想不到的,因为这种方式太冒险,也给人感觉太外行了,一些测试专家们听了你的天马行空的想法,估计还会气得一塌糊涂:你竟然不用测试应该有的思维来解决问题,还在那里瞎想?

    其实作为测试人员,在发现和解决问题时,外行的思考方式可以成为有效的切入点,但是真正的实践还是必须以专家的严谨和慎重来验证想法是否正确。

    然而作为测试专家,往往会下意识地对一个方法的技术可行性进行判断,这种下意识很多时候能够有效的帮助我们,但它也往往阻碍了创造性灵感的萌生。因此,强调像外行一样思考,追求的是一种新的方法或者角度,仅仅考虑某个问题是否可能存在或某种方法是否能解决问题,而不考虑是否有理论依据,也避免过多地考虑可行性。

    遇到棘手问题的时候,测试高手往往就能跳出既有的条条框框,像个外行一样重新审视系统的整体,当然,像外行并非真的是外行,高手们在大胆假设的前提下也依然会小心地求证假设是否正确。这便是如同标题说的:像外行一样思考,像专家一样实践。

    说到这里,小艾总结出来专家与高手的一些区别了:测试专家能够在测试中发现绝大部分的问题并能够使用合理的分析方法找到解决绝大部分缺陷的方案,而高手则能够更进一步,最棘手的问题也能够有效解决。因此,能否以这种收放自如的思维方式应对测试中遇到的问题,是高手和专家的一个重要分野。

    工欲善其事必先利其器

    对于测试工程师而言,虽然发现和解决问题时体现其价值的事,然而却不得不花大部分时间执行测试。

    或许看到这句话很多人都有同感,就是就是,每天每天我都是在执行测试尽可能发现问题,可是哪有那么多时间来分析解决问题呢?这本书写得太垃圾了,尽写我知道的但做不到的东西……

    停停停,什么鬼!执行测试浪费了我们的时间,所以我们就没空分析问题了?是这样么?从某种程度来说确实如此,执行测试太浪费时间了,那么,我们是不是可以提高下我们自己的效率呢?先别急着问怎么提高,先来看看提高效率后的我们会迎来什么样的表现?

    对于同一个测试人员来说,可能使用相同的时间可以完成更多的测试用例执行,也可能对于同一个或者同一类的测试用例,耗费的时间减少了。

    相信后者很多人有体会,自己对测试执行的生疏耗费的时间远远比熟练之后执行得慢得多,因此提高技能的熟练程度,自然能够提高效率。当然,通过熟练程度提升的效率非常有限,因此进一步提高效率的方向应该是减少对测试的人工干预。看官们想的没错,就是自动化测试。

    然而自动化也会对团队带来额外的负担。如果追求全局的自动化,那么一个完善的自动化测试框架必不可少,但搭建测试框架本身就是一个规模不小的工程。再者,即使有完善的自动化测试框架,测试人员依然得完成基于自动化测试开发的测试用例,测试完成后,也还要对这些自动化执行资源进行维护。 

    可以说,没有经过深思熟虑而仓促上马的自动化执行方案,可能不但不能提高执行效率,反而会增加测试团队的负担。

    或许有不少人有这样的经验:项目刚刚启动不久,测试团队就开始要求编写自动化代码,因此开发人员每一次尝试性的变更,我们都不得不去更改测试的代码,加上测试人员对项目还不熟悉,往往编写代码的逻辑也是错误百出,如果还被要求较高的测试通过率,那日子,真是没办法过了…… 

    因此,自动化测试从某个角度来说,更加适合敏捷项目在回归测试中不断需要被测试的部分,而不应该是开发人员新增的功能仓促地自动化。

    小艾这才明白,原来除了完成测试任务,提高测试的效率和质量,也是测试工程师的一个重要任务,而测试高手区别于一般测试人员的关键在于测试高手更善于运用创新,在实践中不断提高。

    从拿来主义到创新

    大家都知道,整个信息技术领域都是快速发展的,变化之快可以用日新月异来形容,因此一名技术专家,如果不能紧跟着技术发展的步伐是很容易被技术抛弃的。新的技术常常是伴随着新的业务模式的流行而产生的,除了紧跟技术,有前瞻性的技术专家还应该洞察业务模式的发展。

    业务在变化,技术在更新,测试技术也同样需要创新。

    创新不是空想,它是以对现有技术和业务的清晰理解为基础的。对于测试工程师而言,一开始往往需要学习和借鉴现有的经验,如测试流程,测试技术,分析问题的方法等。随着学习和实践的深入,在特定产品中会出现特定的需求,而这些特定的需求往往技术上找不到现成的答案,此时,这种需求就会被作为创新的目标,而寻找新的解决方法的过程就是一个创新的过程。

    可是创新却也没有那么简单,它需要建立在对本领域最新技术的深入学习及对这些技术无法满足的业务需求的充分理解基础之上。

    创新可以是对实践方法的创新,也可以是对指导实践的理论的创新。对于测试工程师而言,这两种创新都非常有价值。

    测试的广度和深度

    在设计测试方案时,可以涵盖的分支非常繁多,从广度来说,体现在对更多功能的涵盖,当一个功能点发生变化时,具有高广度的测试用例需要验证所有可能受影响的功能。而深度体现在对功能细节的深入,除了涵盖正常分支以外,还有涵盖异常分支和错误分支,把每一个功能点的每种可能的情况都包含在测试用例中。

    由于选择众多,小艾很好奇拿到一个测试功能点的时候,由于时间有限,到底应该如何权衡测试的涵盖度呢?其实可以先确定测试的可用资源和测试方法,确定之后能够完成的任务数量是可以进行估算的。每增加一个深度或者广度级别,对测试资源的消耗会成线性或者非线性增加,因此权衡的时候,考虑该方案在覆盖深度和广度的提升在逻辑上是否必要,是否有业务需求,来确定是否需要将其记录在案。

    但这里不得不提的是,与测试的覆盖相对应的重要指标是软件失败的风险。将有限的资源投放到风险最大的关键点,来设计相应的测试深度和广度,我们需要在矛盾中追求平衡。

    对于测试高手来说,有助于决策的,除了清晰的目标、丰富的经验以外,判断时的直觉也不可或缺。

    无招胜有招

    作为专业技术人员,测试工程师应该具有优秀的理性思考能力和逻辑分析能力。

    除此之外,直觉和灵感对于测试高手而言也十分重要。有一类原因比较复杂或很不明显的bug,使用通常的逻辑分析方法很难找到原因,因而对于测试高手而言,直觉可以给予方向性的帮助。

    有人要问了,难道只有测试高手有直觉和灵感,新手和专家都没有么?当然不是,但测试高手往往能得到更多有效的直觉和创新的灵感,为什么?这取决于输入信息的有效性,包括知识、经验及问题本身。知识通过学习获取,经验通过实践积累,而对问题本身的理解,是一种从表面现象进行抽象提取的过程。

    掌握的知识越多,经验越丰富,对问题的理解更加深入,那么提供给非逻辑处理的输入就越有效、越准确,得到高质量的输出机会就越大。

    尾声

    尽管这篇文章提到的是测试新手、测试专家和测试高手,但即使成为了测试高手,在测试的领域,依然还有许多值得追求的事物。随着对测试的理解越来越深,测试工程师可以对测试的哲学提出独创性的见解,这种见解也许是技术上的,也许是方法上的,或者是管理上的。能够提出这种见解,测试工程师已经达到了测试大师的水平了。新的技术、新的方法论和新的测试哲学不断出现,推动着整个软件测试领域乃至信息科学领域的不断进步。

    在导师的一番解说下,小艾发现,在测试的专业领域上,可以做的事情还有很多,优秀的测试工程师,除了专业技能,最重要的还在于懂得如何思考。与其说解决问题的能力是不同水平的测试工程师的分野,不如说是思考的能力把不同的层次区分开来。

    通过导师耐心细致的一番番长篇大论,小艾可以说是迅速了解了整个测试领域的情况,目前摆在他面前还有一个很重要的问题,对职业生涯的考虑,小艾知道测试领域中的路有两条——技术和管理,但其中还包含了哪些可以选择的发展方向以及自己该如何做出选择,依然困扰着他,下回我们就来看看小艾是如何找寻到答案以及找寻到自己的方向的吧~

    想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月

  • 相关阅读:
    阿里DatatX mysql8往 Elasticsearch 7 插入时间数据 时区引发的问题
    通俗易懂 k8s (3):kubernetes 服务的注册与发现
    ReplicaSet 和 ReplicationController 的区别
    使用Go module导入本地包
    k8s之statefulset控制器
    终于成功部署 Kubernetes HPA 基于 QPS 进行自动伸缩
    Atitit drmmr outline org stat vb u33.docx Atitit drmmr outline org stat v0 taf.docx Atitit drmmr out
    Atitit all diary index va u33 #alldiary.docx Atitit alldiaryindex v1 t717 目录 1. Fix 1 2. Diary deta
    Atitit path query 路径查询语言 数据检索语言 目录 1.1. List map >> spel 1 1.2. Html数据 》》Css选择符 1 1.3. Json 》map》
    Atitit prgrmlan topic--express lan QL query lan表达式语言 目录 1. 通用表达语言(CEL) 1 1.1. 8.2 功能概述 1 1.2. Ongl
  • 原文地址:https://www.cnblogs.com/Ribbon/p/5973222.html
Copyright © 2011-2022 走看看