本文根据11月23日第39届BQConf北京的演讲《软件测试人员该何去何从》整理，为了便于阅读，稍作修改并增加了不同级别的标题。

三个故事

01. 面试中的他

两年前的一个下午，天气有些雾霾，在三楼光线不是特别明亮的会议室里，我和另外一位工作年限跟我差不多的同事面试一位有着10年经验的候选人。

对于跟一位工作十年的候选人见面，我和同事都挺期待，提前沟通好，做好了充分的面试准备。走进会议室，看到一位身材高大、略显疲惫的男士，没有我想象的那种阅历丰富、干练自信的样子。

简单寒暄之后，我们正式进入面试流程。他介绍了自己的工作经历，详细描述了自己这些年所从事的工作的点滴，听下来并没有太多的亮点。出于对候选人负责，我们想尽力去挖掘他的一些加分项，但是，很难，最终无果…

他来自某大公司，多年一直处于一个部门，从事几乎没什么变化的手动测试工作，工作强度不大，对技能要求也不是很高，他在那里做的得心应手。不料，公司业务发展调整，需要部分裁员，他不得不另谋出路。

02. 屏幕那头的她

一年前，我写了一篇文章《微服务测试的思考与实践》。有位朋友看了我的文章，给我发来微信，她觉得我的文章内容对她很有启发，就文章内容跟我进行了咨询和讨论。

她对内容很认可，但是执行起来她觉得没那么容易。我俩聊着聊着，她开始跟我讲她现在的困境：她有简单的编码技能，但是对于更多底层技术、架构方面的知识比较缺乏，在项目团队想推进一些技术变革重重受阻。她做QA也有好些年了，这两年老觉得行业技术更新太快，自己的技术热情和时间有限。而随着工作年限的增加，别人（团队）对她的要求也就更高。

她是一位妈妈，一方面需要照顾家庭和孩子，一方面感觉到工作技能提升的压力，她感觉自己遇到了职业瓶颈。

03. 放弃测试的他们

两个月前，两位好友一起吃晚饭。很久没有相聚，自然是有很多话题聊的。

他们两个都是曾经做测试的，现在分别转做了开发和管理。席间我们聊到了这个话题，身边做QA或者测试的朋友转角色的还不少。我被问到是否考虑转角色的问题，同时，我也听到一个说法：大家都从QA转别的，毕竟QA的地位还是要低一些。

故事讲完了，大家有何感想？

我们来看一下故事里提到的测试人员面临的问题有哪些：

• 多年重复手动测试，只是关注自己手头的事情，大公司的部门壁垒，跟别的角色、别的团队较少沟通，相对比较封闭。但这些似乎并不影响做好手头的测试工作，觉得自己是“能力够用”的，在这个舒适区待着很爽，自然没有学习提高的动力。
• 长此以往，应对变化的能力会越来越弱，随着年龄的增长，本应该同样增长的技能却没有相应的增长，感受到外界的压力增加；如果还有身份的变化，成为上有老下有小的夹层，来自家庭的压力导致用于技能提升的精力减少，更加难以提高。
• 得不到技能的提高，在团队的影响力减小，话语权降低，不被重视，甚至自己也在怀疑所做工作的价值…于是，只好选择换一个角色…

当然啦，有些朋友是真的觉得测试工作不适合自己，转做别的更适合的工作，这些朋友除外。比如跟我吃饭的那两位好友，他们现在都干的很好！

那么，软件测试人员真的有这么悲惨吗？

由Capgemini、Micro Focus和Sogeti联合组织问卷调查，每年出具一份《World Quality Report》（全球质量报告），今年已经是第10期了。报告列出了大家关注的质量趋势，也会给出一些推荐的做法。报告内容非常多，每期都是70页左右的英文版文档，去年和今年的报告我都有写文章解读，大家感兴趣的可以参考我博客网站上的文章《数字化时代的软件测试》和《关于质量，大家都在关注什么》获取更多细节。

下面来看今年的这份质量报告给我们带来了什么。

我们知道，软件系统首要的是满足功能需求，所以功能是最为核心的内容，但已经不能止步于此，在功能的外层还有更高的质量目标。大家请看图，在功能需求外还有四个方面，分别是：

• 安全： 信息化时代安全的重要性不言而喻，不仅指应用程序本身的安全、对用户隐私的保护，也包括软件开发过程的安全性和软件资产的安全管理。
• 速度：互联网时代瞬息万变，都在追求速度上的质量。同样，速度不仅指应用程序本身的性能，也包括交付的速度，从idea到成品交付到用户手里越快越好，抢占先机！
• 便利性：应用程序能给用户生活提供多大的便利程度，比如说打开一个外卖软件，可以多短的时间找到需要的餐馆，是用户非常看重的一个质量指标。
• 体验：第四个是用户使用系统的综合体验好坏，易用性、页面的布局和配色等都会影响到用户是否愿意给应用买单。

这四条围绕功能而高于功能的就是终端用户的满意度，是今年质量报告反应出来的大家的最高质量目标！

质量备受关注，对质量的要求越来越高，软件测试或QA工作的重要性不言而喻，我们大家所做的工作毫无疑问是非常有价值的！

同时，随着质量要求的提高，软件测试也不再是发现缺陷那么简单，对我们测试人员的要求也有很大的变化。

为了走出前面故事中的那些困境，我们需要行动起来。

行动起来

01. 学习

面临的问题

显然，最关键的行动一定是学习！说到学习，我们有必要先来看一下大家学习可能面临的问题：

• 技术日新月异，太多的东西要学，我该从何学起呢？

的确是这样，信息化时代，学习渠道、学习的内容都是无穷的，要学习先要甄别哪一个是值得学的，无疑给学习提高了门槛，这也使得有部分人无从下手，就干脆不学了…

• 不知道从哪学起，那么我们就先学一个东西再说，学了总比没学好！

这种做法在过去知识比较匮乏的时代，是可取的，学了一定会比没学要好，说不定哪天就能用的上了。但是，现在处在信息化的时代，有些知识是可以不需要花太多精力去学，可以从互联网简单搜索获得的。毕竟精力是有限的，如果花时间学习了这种本可以轻松得来的知识，是很大的浪费。

• 目的性不强，学到了零散的知识，也很难真正派上用场，最后这个知识还是会被遗忘。

比如说，现在Python很热，小学生都在学Python编程了，觉得我们要还不会就落伍了。可是呢，学了半天，也没有实际用上，过一段时间发现也记不得多少了…这样进行几次之后，会严重影响学习的积极性，发现学了也没用，好像还不如不学。久而久之，就放弃学习了…

学习这么麻烦，我们该怎么学习呢？

学习的过程

我们先来了解一下学习的过程。学习面对的是海量的知识，我们需要从中挑选自己需要的部分，进行加工和提炼，变成自己掌握的知识。到这是不是就结束了呢？并没有。还有最后非常关键的一步，那就是把学到的知识应用到不同的领域，或者总结分享出来供他人学习和使用。

也就是一个完整的学习过程应该包括三个部分，分别是：知识输入、加工提炼、知识输出。缺失其中任何一步，都不是正确的学习。

讲到这里，我想问今天到场的各位朋友一个问题：平常大家都会读很多书，请问大家怎么定义读完了某本书？

答1：我会根据书上介绍的做Demo在团队演示。

答2：我会总结书里的内容在团队分享。

前面两位朋友回答的都非常棒！我想介绍我的一位朋友的做法，他对读完一本书的定义是必须有输出，输出可能但不限于下列的一项或多项：

• 写读书笔记分享；
• 提炼书中观点，结合自己的经验总结成博客文章发出；
• 运用书中理论到工作实践中，在团队以工作坊或小型演讲方式分享；
• 或者以演讲的方式到大会上分享给更多人。

就是在这样不断反复学习、总结、分享的经历之后，他成为了某技术领域的专家！

学习的正确姿势

了解了学习过程，我们还需要了解学习的正确姿势，以确保学习是真正有效的。关于学习的正确姿势，我认为有两个比较关键的。

首先，根据前面讲的学习过程，最终是要把学到的知识应用起来的。我们可以先搞清楚要把学到的知识应用到哪里，也就是我们学习的目标，搞清楚这个目标，然后利用目标倒逼输入，再进行学习的正向过程，也就是以终为始的做法。

比如：目前工作的项目上需要某项技术，我们有针对性的去学习这一门技术，这样的效果会比较好，能够达到事半功倍的效果。

又或者，目前工作中暂时用不上，但是自己很感兴趣的技术，可以作为学习目标，深入学习和研究，最终的输出可以是集结成文，或者演讲的方式分享出来。这样，不仅可以让他人获益，更重要的是对知识总结提炼的过程，加深了自己对知识的掌握，最获益的还是自己。

这就是我要说的第一个正确姿势：目标驱动，以终为始！

这里，我们要搞清楚三个问题，也就是

• Why – 为什么要学？输出是什么？
• What – 要学什么内容？输入是什么？
• How – 如何学？学习的方式，对于不同的内容需要采用不同的学习方式。

第二个学习的正确姿势是持续学习。这一点，其实没有太多可讲的，知识在发生着日新月异的变化，现在是特别需要活到老学到老的时代，不然很容易落伍，跟不上变化的步伐。

可能有朋友会说，我在目前工作中的技能已经完全够用了，我也没有很明确感兴趣的方向，该如何提升自己呢？

接下来，我们来看如何确定学习目标的问题。

学习的方向指导

对于目标不是很明确的朋友，不太知道如何从海量知识选择自己需要学习的内容，可以多关注一些趋势性的内容，以此作为自己学习方向的指导。

比如，前面我们提到的全球质量报告（World Quality Report）就是一份很好的趋势方面的内容。

质量报告里提到大家关注的质量趋势集中在五个方面：AI和测试、敏捷和DevOps、测试自动化、环境和数据，以及质量保障方面的成本投入问题，报告分别列出了这几个方面的现状以及未来几年的发展趋势。

同时，报告还给出了一些推荐的应对策略。我们拿其中的质量工程技能方面的策略来详细介绍一下，包括以下几个方面的技能：

• P0 – 敏捷测试专家，包括必备的自动化技能和领域测试技能。敏捷和DevOps的越来越普及，使得对敏捷测试专家的需求成为最高优先级的。一方面，自动化测试是敏捷的基础，要求敏捷测试人员必备自动化技能；另一方面，敏捷测试提倡测试左移，测试人员需要在需求分析阶段开始介入，对领域知识和业务理解能力有相当的要求。
• P1 – 测试开发技能，处于P1的优先级，要求必备高级自动化、白盒测试、开发技能和平台构建能力，同时，对于AI方面的基础算法应用处理和自然语言处理技能是个加分项。
• P2 – 接下来的是专项技能集，包括安全、性能等非功能测试、测试环境和数据的管理技能等。前面提到过安全、性能的迫切需求程度，同时报告也指出测试环境和数据的管理水平低下，导致这些专项技能的培养的优先级还是很高的。
• P3 – 最后一个是高级QA专家，主要是AI架构技能，要求能够构建执行重复、智能任务的“智能测试资产”。鉴于目前AI技术的运用水平，对于这方面技能的培养可以稍缓，但的确是未来的一个发展方向。

下面再给大家推荐一个非常值得关注的技术趋势类读物，那就是ThoughtWorks的技术雷达。ThoughtWorks TAB（ThoughtWorks技术咨询委员会）根据我们在多个行业中的实践案例，每年为技术者产出两期技术雷达，对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。

关于技术雷达，也有朋友说上面跟测试相关的条目越来越少，对测试人员的参考价值不大。我们来一起看一下今年上半年发布的第20期技术雷达。

技术雷达是按照技术、平台、工具、语言&框架四个维度，根据每个维度技术条目的成熟度分成暂缓、评估、实验、采纳四个环。乍一看，带测试字眼的条目较少，但这不代表跟测试相关的内容少。我尝试按如图所示的思维导图的方式做了一个总结，摘出测试人员需要关注的几个方面，并列出对应的技术条目。大的方面有DevOps&基础设施、微服务、自动化测试、线上监控与分析、安全、数据分析与机器学习、区块链等，对于每一块我们都可以相应的思考测试人员需要关注的点有哪些，这里就不详细讲了，更多的细节大家可以参考我的博客文章《软件测试人员的挑战与机遇》。

除此之外，还可以多关注一些技术社区、技术大会、技术类公众号，了解别人都在做什么、有什么新的技术等。相信大家也会有不少这方面的关注，欢迎一起来分享。

02. 沟通

学习是提升自身能力的途径，要想职业生涯更加顺畅，还有很关键的一个行动是需要增加跟他人的沟通，不可以独自处于封闭的状态下闷头学习。

首先，项目团队内跟不同的角色的沟通

我们一直在讲团队为质量负责，但是团队不同的角色对质量的理解可能不够透彻、对质量关注的意识也会不太够，作为团队的QA，是需要承担起质量协调者的角色的，需要把自身对质量的理解、当前项目产品的质量状态及时的跟团队反馈，需要跟不同角色有足够的沟通，让团队不同的角色能够更好的一起为质量负责。

当下流行的全流程测试，更是强调测试人员在各个环节的参与，跟不同角色的合作，比如说需求分析阶段需要跟业务分析人员合作，自动化测试需要跟开发人员合作，在生产环境下的QA又需要跟Ops的人员合作等。

在跟不同角色的合作过程中，不仅可以从对方角色那里学习到自身欠缺的技能，以丰富自身能力；同时，也可以让跟你合作的角色从你身上学习到测试考虑的角度，更好的做好质量的每一步。这是一个双赢的过程，1+1>2。另外，合作多了，大家也走得更近，工作更好开展，自然在团队的影响力就会增加，地位感也随之增加了。

其次，更大范围的沟通

项目团队的充分沟通，有利于项目工作的顺利开展，但是，团队还是太小，需要扩大到更大范围。比如说，多参与技术社区、技术大会、技术讨论微信群等。相信今天来到现场的朋友们都是体会到这个方面的优势的，都非常积极的参会。

这里，我们要注意一点，如果只是看或者听别人分享的话，参与感是不太够的，效果不会太好。要多发表自己的看法，或者抛出自己的疑问，多跟人沟通，不是单向的吸收。除了一对一沟通，可以参与群体的讨论，或者对一些技术文章、所读书籍发表评论、读后感，还可以通过写文章、演讲的方式分享自己的经验所得。

请记住，有输出才会有收获。这个非常关键！

03. 突破

刚接触测试的从业人员，可能非常关键的一项技能就是要能尽可能的发现bug，于是我们有着很大的一个优势就是比较容易发现很多细节上的问题。这也同样带来一个问题，那就是有的测试人员过度关注细节，导致工作好几年还是容易抠细节，看不到大局。因此，我们的第三个行动是需要跳出来，做到突破，要有破局思维！

首先，要培养系统思考能力。世间万事万物都是有联系的，构成众多大小不一的系统。

小的系统比如目前正在做的产品，当你发现某个功能有bug的时候，它真实的问题可能出在另一个你想象不到的模块，这个时候如果只是停留在你发现问题的模块，可能就浪费很多时间也难以定位问题；或者你发现一个bug，觉得它很严重需要紧急修复，但是当你结合市场情形、业务发布优先级、对终端用户的真实影响、修复所需成本以及开发人员手头其他工作的优先级综合来看，最后可能发现那个bug的优先级低了很多…

这是系统思考的两个简单的例子，由于系统思考不是我今天要讲的重点，在此就不多讲了。大家感兴趣的可以找相关资料，运用前面所介绍的学习方法去获取相关知识。

其次，需要扩大视野。前面讲到的关注技术趋势、参加技术讨论等都是扩大视野的途径。通过吸收这些信息，视野变大了，个人看问题的角度就会变的不一样，也就更容易去发现问题或者提出建设性的解决方案。

最后，遇到问题时，要运用系统思考的能力，跳出单一的小系统，利用曾经吸收到的各类有价值的信息，逐步建立自己的大局观。

这几点，我认为都是测试人员非常需要培养的能力，也是帮助我们拓宽职业之路的有力助手。

前面讲到这么多，有些是通用的适合所有人，但是，我们还是需要结合自身特点去选择适合自己发展的方向和提升的方法，要结合自己的兴趣特长、性格特征来选择。如果没有跟自己兴趣特点匹配的也不用太过担心，相信兴趣特点也是可以培养的。我想送大家两句话：

选自己所爱，爱自己所选！

坚持就是胜利！

回顾与总结

今天通过三个我亲身经历的故事，我们看到了测试人员可能面临的问题。同时，给大家分享了我们可以采取的三个行动。最后总结一下，希望大家能够记住下面几个关键词：

• 以终为始，持续学习
• 沟通交流，让知识翻倍
• 勇于突破，系统思考
• 选自己所爱，爱自己所选

今天分享的这些是我在学习、摸索中的一些总结，我不是什么成功人士，所以这也只是抛砖引玉，希望大家更多的来一起分享和讨论，愿我们各位测试同仁们都有一个好的职业发展的明天！

“好多QA转PM，因为QA（的地位）始终是要低一些”

“我现在做的事情跟几年前没有区别”

“资深QA在项目上做的事情新来的毕业生也能做”

上面的话你是不是也有同感？我相信大部分人会这么认为，因为这些表面上看起来的确是这样的！

那么，软件测试人员或者说QA真的有这么惨淡吗？

对于开篇引用的几句话，我们一一来分析一下。

测试工作的价值不容置疑

“好多QA转PM，因为QA（的地位）始终是要低一些”

说这话是没有看到QA所做工作带来的价值。相反的，我认为QA之所以可以转PM是QA工作过程中获得的锻炼挺多的，不仅可以转PM，可以转PO，技术型的QA还可以转Dev。

其实，QA和PM并没有地位高低之分，只是分工和职责不一样，QA转其他角色并不是地位的改变，可能只是更加适合自己。积极主动的做好本职工作，都能为团队带来很大价值；做的不好的话，都同样的不能带来价值。况且，做的不好的PM可能影响到整个团队，所带来的价值远不如一个优秀的测试人员带来的价值大。

我们应该以合作的心态看待这个问题，一直强调的团队为质量负责，需要每个人都有团队的意识，有分工只是因为兴趣特点和擅长领域不同而已，并没有高低贵贱之分。

质量越来越受到各行各业的关注，质量问题不容忽视。软件质量的保障工作，软件产品的测试当然也是非常重要有价值的，这一点根本不用怀疑。

只是，质量的好坏带来的价值不是那么直接可见的。反而需求人员多分析了几个需求，开发人员多开发了几个功能点，又或者多写了几个自动化测试，这些都是显而易见的，似乎带来的价值更大，更容易被人认可和重视。而另一方面，需求的验证、测试的设计、质量状态的关注、风险的把控、快速的发现和定位问题，这些是不容易被量化的，也就不容易被重视或尊重。

能力提升是关键

“我现在做的事情跟几年前没有区别”

这是只看到所做的事情似乎没有差异，比如说都是一起分析需求、设计测试、测试story、写自动化测试等，可能的确几年前就做这些事情，现在还是做这些事情。但是，我相信只要你在做每件事情都能认真对待，有自己的思考和总结，就不会一样。比如：

• 同样的分析需求，几年前可能只看到BA写出来的需求，看看有没有边角case漏掉了；而现在的你可以从行业业务角度去看待这个需求整体考虑的合理性，是不是能给用户带来价值、能给企业带来竞争力。这两者还是有很大的区别的。
• 同样的测试story，几年前可能只是根据验收标准和自己想到的一些边角case去测试，一个story需要一天才能测试完；而现在的你，利用自己对于领域知识的掌握、技术的了解、系统功能的熟悉，结合自身这么多年阅历和增加的常识，半天估计能测试包含几个story的一个feature，或者一个junior测试人员测试过的story，你拿过来一下就能发现一些问题。这就是成长，这就是价值！

“资深QA在项目上做的事情毕业生也能做”

如果只是看所做的事情，可能还是停留在表面，跟上一条讲的几年前的自己和今天的自己一样。

当然，有很重要的一点，资深QA不能仅仅是工作年限长，得是有真正的能力，不然的话可能还不如优秀的毕业生。

QA能够随着年龄和工龄的增长，让自己的能力也能不断的提高，才能让测试工作有更多价值的体现。因此，能力提升至关重要！

那么，能力该如何提升呢？

能力提升路径

看似相同的事情，不同能力的人做出来的效果不一样。为什么他解决问题的能力那么强？我们来了解一下学习提升的过程。

第一阶段，知识积累

通过阅读、听课、观看视频等方式可以获取到知识点，将这些知识点总结归纳之后，变成自己理解的知识。

这是第一阶段知识积累的过程。

第二阶段，经验积累

将所学知识进行试验，进一步用于实际项目，获取实践经验，不断反复的实践可以获得经验的积累。

这一阶段还不够，还没变成真正解决问题的能力。

第三阶段，能力提升

在实践中坚持回顾和总结，对实践过程进行批判和改进，并且举一反三的运用所学知识，将会实现能力的积累。

到此，就实现了知识到能力的转变过程。

积累和分享很重要

前面每个阶段都可以获取新的知识，然后经历同样的知识-经验-能力的转变，不断的积累，将会实现能力的提升；每个阶段都可以把知识或经验分享给他人，在帮助他人获得相应知识的同时，更是自身能力提升的一个非常好的方式。

多次反复的知识-经验-能力的转变，达到一定积累之后就会带来惊人的效果，这不是一个线性的增长。

在整个过程中不断发掘自己的兴趣点，将学习、兴趣有机结合起来，会达到事半功倍的效果。

终身成长

了解了能力提升路径，很重要的一点还有可能是我们需要转变固有的思维模式。这里给大家推荐我非常喜欢的一本书《终身成长》，书中讲到两种思维模式：固定型思维模式和成长型思维模式，具备成长型思维模式的人将更容易获得成功。我们需要更多的关注自身的成长，而不是关注外界、跟外界进行比较。

前面所讲并不只是跟软件测试人员相关，可以适用于任何角色、任何职业的朋友，只是同样作为质量工作者，听到不少人的担忧，才撰写此文。

相信积累多了，就会发生质变！

最后，让我们一起多阅读、多学习、多实践、多思考、多总结、多分享，做到终身成长！

“我们公司的测试好多都转业务或开发了，还有的转管理了，测试做不长久…”

“现在好多公司已经不招测试人员了，感觉测试没有什么前途…”

“ThoughtWorks技术雷达上都是开发相关的内容，测试相关的内容越来越少…”

软件测试总是被看做没有技术含量、没有前途的工作，很多做软件测试的朋友也比较迷茫，表示发展受限。在这个技术飞速发展的时代，各行各业都在实行数字化转型，各种高新技术似乎离测试人员越来越遥远…

那么，测试人员真的是前途渺茫吗？本文将根据ThoughtWorks最新发布的第20期技术雷达来分析当前流行的技术给软件测试人员带来的影响是什么，有哪些机遇与挑战。

技术雷达上的内容涵盖有技术、平台、工具和语言&框架四个维度，我观察到其中跟测试人员关系比较紧密的主要有以下几个方面：

1. 支持快速、持续交付的基础设施与DevOps实践

质量和速度是最关键需求，为了适应各行各业对速度的要求，配套的支持快速、持续交付的基础设施与DevOps实践是成功之必备。技术雷达上与之相关的条目有很多，比如：Terraform生态系统和四个关键指标等。

• Terraform生态系统

Terraform是一种安全有效地构建、更改和版本化基础架构的工具，可以管理现有和流行的服务提供商以及定制的内部解决方案，正在迅速成为通过声明式定义来创建和管理云基础设施的首选工具。本期雷达Terraform相关的内容重点包括Terratest（用于测试基础设施代码)，以及GoCD的新提供商（可以使用Terraform配置GoCD)。

基础设施不仅是Ops或者开发人员需要关注的领域，作为测试人员，同样需要加强这项知识的掌握：

1. 了解了基础设施知识，结合已有的测试sense，测试人员可以和开发或Ops一起测试基础设施；
2. 了解基础设施特点，可以指导测试的设计，在测试的时候更有针对性的关注比较脆弱的节点、环节，规避风险，增强系统的反脆弱性；
3. 利用基础设施知识，可以指导测试环境的搭建和维护、自动化测试数据的准备和管理等。

• 四个关键指标

埃森哲发布的DevOps报告指出组织绩效跟软件交付性能关系紧密，而衡量组织绩效的四个关键指标分别是前置时间、部署频率、平均修复时间(MTTR)和变化失败率。本期技术雷达采纳了这项技术。

作为测试人员，我们需要了解每个指标的真正含义，并且思考我们测试策略是否需要做某些调整来提供对应的指标值。比如说为了提高部署频率，可能不需要那么高的E2E自动化测试覆盖率，而是达到覆盖效果和执行效率最佳平衡的一个状态即可。

2. 支持业务灵活扩展的微服务架构

引入微服务令我们受益匪浅，使用微服务，团队可以扩展那些独立部署和维护的服务的交付，从而方便业务的灵活扩展。微服务架构正在逐渐被越来越多的企业采用。我们看到技术雷达上应对微服务的相关条目有服务网格、混沌工程、API测试框架Karate等。

• 服务网格（Service Mesh）

服务网格是一种安全、快速、可靠的运行微服务生态系统的方式。这种方式为轻松地大规模采纳微服务奠定了基础。它提供了检测、保障、跟踪、监控和故障处理功能。它提供的这些跨功能能力无需共享API网关等资产或将很多依赖库纳入到每个服务中。

• 混沌工程（Chaos Engineering）

混沌工程是对系统进行试验的一门学科，旨在建立对系统抵抗生产环境中不确定条件的能力的信心。在去年，我们看到混沌工程从一个备受关注的 、想法，转变成公认的主流方法，来改善并保证分布式系统的弹性。主要用于以下几类故障时增强系统的弹性：基础设施故障、网络故障和应用程序失败，对应的工具有Gremlin和Chaos Toolkit等。

• Karate

Karate是一款API测试框架，其特色在于，直接使用Gherkin来编写测试，无需依赖常用编程语言来实现测试行为。Karate是一个领域特定语言，用来描述基于HTTP的API测试。虽然该方法很有趣，可以为简单的测试创建非常易读的规范，但用于匹配和验证负载的专用语言可能会变得语法晦涩、难以理解。从长远来看，使用此风格编写的复杂测试是否将可读且可维护，仍有待观察。

微服务带来灵活性的同时，也带来很多的复杂性和不确定因素，尤其是对质量保障带来了挑战，因此微服务系统的测试也备受关注。作为测试人员，只有了解了微服务架构与服务网格的特点及其对测试的影响、混沌工程对质量保障的帮助、API测试的框架选择与测试优化等，才能更好的做好微服务系统的测试。

3. 多样化数据形态的支持

随着数据源的增加、数据规模的扩大、数据种类越来越多，相应的数据形态也呈现出多样性，包括NoSQL、时间序列、像CockRoachDB和Spanner这样提供全局一致性的SQL存储，以及提供聚合日志文件查询功能的事件流。不再是关系型数据库解决一切存储的时代了，要考虑真实需求，采用合适的策略和工具。

数据形态的变化，必然对测试也提出不同的要求。作为测试人员，需要了解不同的数据规模、不同的存储形态、不同的数据类型分别该如何验证、测试该如何设计、测试数据该如何准备，还有数据安全、数据匿名化、数据分析等数据相关技术对测试的支持等。比如，对于大量数据处理的项目，测试人员需要了解数据处理的技术与处理逻辑，分别从功能层面验证处理逻辑的正确性，以及从非功能方面考虑大量数据处理的性能、数据处理的安全规约等。

4. 网络安全始终是重中之重

网络给我们生活带来便利性的同时，其安全性也是备受关注。2018年欧盟颁布了GDPR法令，使得众多企业不得不紧急调整系统功能做好个人身份信息的保护工作。网络安全始终是质量保障的重中之重，绝对不容忽视。本期技术雷达推荐的安全相关条目有密码即服务、容器安全扫描、密钥销毁技术等。

• 密码即服务（Secrets as a service）

在构建和运维软件的价值流中，密码凭据在多个场合都需要使用：构建流水线需要使用密码来与容器注册中心等安全基础设施进行交互，应用程序需要使用API密钥作为密码凭据来获得业务功能访问权限，而服务间通信则需要以证书和密钥作为密码凭据来保护其安全，这些密码凭据不建议通过源代码的方式管理，而是采用密码即服务的技术来存储和访问。利用这种技术，可以使用Vault或AWS Key Management Service(KMS)等工具来读写HTTPS端点上的密码凭据，同时实现精细的访问控制。

• 密钥销毁技术（Crypto shredding）

密钥销毁是指主动覆盖或删除用于保护敏感数据的加密密钥，以保护敏感数据不被读取。对于审计应用程序或区块链这样不应该或不能删除历史记录的系统来说，密钥销毁技术对于隐私保护和GDPR合规非常有用。

• 容器安全扫描（Container security scanning）

围绕Docker的容器革命显著减少了应用在跨环境迁移时的阻力，并推动持续交付和持续部署的采纳。但尤其是后者，对于传统的投产控制带来了相当大的漏洞。容器安全扫描技术是对该威胁载体的必要响应。构建流水线中的工具，会自动检查流水线中的容器是否存在已知漏洞。

作为测试人员，对于上面的安全相关技术可能不需要掌握的很深，但是需要了解有这样的一些技术，以及对应的使用场景。这样，才能对于系统整体的安全质量有更好的把握。此外，测试人员需要了解相应的安全测试技术，需要关注业务方面的安全需求，了解不同领域的安全规范和要求，从需求阶段做好威胁建模开始，跟团队一起在软件开发生命周期做到安全内建（Build Security in）。

5. 自动化测试与线上质量的关注

要快速交付，必然离不开自动化测试，而要做好自动化测试，更是离不开相应工具的支持。本期技术雷达上列出的Cypress、TestCafe和Puppeteer被誉为后Selenium时代的Web UI测试的三驾马车，值得关注。这三个工具不同于WebDriver时代的自动化测试工具，具有更加轻量级、更加稳定、速度更快的优点。

随着技术架构的演进和业务领域的发展，软件系统生态越来越复杂。过于重视预生产环境的测试，不仅不能很好的保证生产环境的质量，而且影响交付速度。因此，我们要把质量关注点拓宽到生产环境，做到测试右移。本期技术雷达列出的相关工具有：日志管理工具Humio，Honeycomb，以及前面提到的混沌工程相关条目等。

• Humio

在日志管理领域，Humio是一款相对较新的工具。该工具完全从零开始构建，通过基于定制设计的时序数据库的内置查询语言，在日志提取和查询方面性能非常快。从提取、可视化和报警提醒的角度来看，该工具能够与几乎所有工具相集成。

• Honeycomb

Honeycomb是一个可观测性工具，它从生产环境中提取出丰富的数据，并通过动态采样使其可管理。开发人员可以记录大量丰富的事件，并在之后决定如何划分和关联它们，这对于大型分布式系统的问题诊断很有帮助。

作为测试人员，自动化测试成为了必备技能，需要关注自动化测试工具的发展，了解新工具的特点与适应场景，更好的让自动化测试工作发挥最大的价值。另外，测试右移的思想也越来越被大家接受，需要测试人员更多的了解基础设施相关技术、线上监控技术等，跟Ops紧密的合作，做好QA in production。同时，利用生产环境的数据，为预生产环境的测试设计和数据准备等提供帮助，构建反脆弱的软件系统。

6. 新兴领域不容忽视

最火热的新兴领域当属AI，这也是未来的发展方向。本期技术雷达上列出的有机器学习和神经网络训练等内容，比如：机器学习持续交付模型、NLP的迁移学习和fastai等。

另一个热门新技术是区块链，技术雷达上区块链相关技术条目有智能合约、超越以太坊的EVM和企业版以太坊Quorum等。

技术雷达上还提到一个新的内容，那就是随着社会对科技的依赖程度日益增长，建议软件开发团队在制定决策时必须考虑道德问题，思考自己所构建的软件会在未来产生什么影响。相应的工具有技术塔罗牌和道德风险手册。

作为测试人员，这些都是大家可以关注并深入了解的方向。新兴领域必然会对测试有不同的要求，比如：关于AI的测试需要考虑两个方面，一个是对于AI产品的测试，另一个是把AI技术运用于测试中，比如自动化测试的智能化、生产环境数据的智能分析等。另外，对于区块链，需要考虑它对测试带来什么挑战、有什么样不同的测试方法来支持；对于道德风险的把控，我们软件测试人员又该注意些什么？能够提供哪些支持呢？

写在最后

前面列的这几项，除了自动化测试工具以外，其他的内容通常被认为跟测试人员没多大关系。其实，软件测试已经不再是那个简单的通过模拟用户行为点击去验证功能是否满足的时代了，测试人员的眼光要放更开阔一些，考虑更多的质量相关因素。对于前面总结的这些项目，我认为不是跟测试人员没有关系，而是给测试人员带来了新的挑战，提出了新的要求。同时，机遇跟挑战并存，这些挑战同样也给测试人员带来了很多新的发展机会。

那么，在众多机会面前，测试人员该如何把握呢？推荐大家可以根据T型能力模型去提升自己的能力。

T的横表示能力广度，T的竖表示能力深度。前面提到的方方面面都属于广度，包括不同技术和不同业务领域的扩展，而深度就是对于其中一个领域进行深入的学习研究，发展对应的测试技能。

广大的测试朋友们可以结合自己的兴趣特点，找到最适合自己的那个领域，深入发展。了解足够的相关知识，通过实践将知识转换为经验，然后总结归纳、不断锻炼，以获得利用经验解决问题的能力，拥有一技之长。

同时，要拓宽视野，了解更多领域的知识，做到广度和深度协调发展。