敏捷测试如何优化业务价值

发表评论

提到敏捷测试就会提到优化业务价值，优化业务价值是敏捷测试的原则之一，敏捷测试的系列活动都要围绕交付价值服务，那么具体的到底要怎么做才能真正优化业务价值呢？

我们需要从四个不同维度来思考和组织相应的测试活动以实现优化业务价值，如下图示：

01. 从终端用户角度进行测试

从终端用户角度进行测试是基本的测试思维，是测试人员必备的技能要求。

在思考、设计测试用例并执行测试的时候，不能简单的套用用例设计方法去机械的进行，而是要考虑用户可能的行为习惯、使用场景等。

下面来看两个例子：

场景一：我们在使用移动设备的时候，一般会设置自动锁屏。当测试某个移动App时，测试人员觉得移动设备的自动锁屏功能会导致测试很不方便，于是关掉了自动锁屏功能，结果后来在一台测试人员自己使用的设置自动锁屏的手机中发现了一个缺陷，就是在每一次锁屏并开启后，充值选项会新加载一遍，可以导致多个重复的充值选项存在。
场景二：测试移动设备断网的情况，通常会采用调成飞行模式或者关闭数据网络的方式，这两种方式对于iOS7以下的版本通常都需要离开所测的App去设置，这样的操作会导致某些功能不可测或者很多问题不能被发现。如果在移动中测试，也就是说打开App测试过程中，测试人员移动到一个没有网络的地方（比如电梯），将有可能发现很多意想不到的缺陷。

上面两个典型的用户场景都是我们不容忽视的，根据这些真实场景去测试，把自己想象成终端用户，就能容易发现用户可能遇到的问题。

除此之外，还要考虑终端用户的体验，比如说页面的布局、配色、易操作性、页面加载时间等都是在测试过程中需要考虑的因素。这样，有助于交付一个增强用户体验的系统，对优化业务价值是有帮助的。

在敏捷开发生命周期的需求分析、特性启动（Feature kickoff）、用户故事评审、用例设计、故事验收和故事测试等环节都可以体现出从终端用户角度考虑的价值。

02. 以业务为重点的测试

单个终端用户的操作可能只是业务流程的一部分，除了从终端用户角度去测试，还需要看到更高一点，那就是业务流程的合理性、流畅性和完整性。这就要求能够真正理解企业的业务，以业务为重点来测试。

下面来看一个业务流程的简单例子：

某购物网站提供搜索、查看详情、收藏商品的功能，用户可以将看中的商品添加购物车，并下单购买。最初的时候，只能从搜索的结果列表和商品详情页面添加购物车，而收藏是非常重要的一个功能，用户如果想把收藏的商品添加购物车还必须得一个个点开详情页面去添加…

这个例子中的搜索、收藏、查看详情和添加购物车本身的功能都没有问题，但是从整个流程来看就会发现缺失掉的场景：从收藏列表添加购物车。

敏捷中的用户故事只是覆盖其中某一个非常小的功能，对于用户故事的分析、评审、开发和测试，需要把所有相关故事串起来，甚至需要跟系统其他关联的特性或者第三方系统集成起来看，从整个业务流程角度去思考，以保证整个业务流程的合理性和相关功能的正确性，确保真正满足企业业务需求。

对于复杂业务情况下要发现缺失的路径可能没前面例子那么容易，需要敏捷团队各个角色都能加强这方面意识的培养。QA和Dev都能在敏捷开发生命周期需求分析阶段介入，尽早接触需求，有利于更好的理解业务流程。深刻理解业务流程、以业务为重点的测试，能够更容易发现关键业务流程中遗漏的点或相应的缺陷，测试带来的业务价值又上了一个台阶。

03. 映射业务影响

保证了每个业务流程的流畅性，还需要综合企业多个业务来看企业业务的优先级，能够区分哪些是关键业务和外围业务，要能理解每个业务对于企业的影响、给企业带来的价值。

举例说明：

某公司的系统为税务和移民两块业务服务，在报税忙季，跟报税相关的业务最关键，优先级最高；而在淡季的时候可能报税业务的优先级就要比移民相关业务优先级低。当我们在测试该系统的时候需要关注这种优先级的变化，测试策略上需要有相应的调整。
某公司的系统提供一种通过观看录播视频进行咨询的功能，但是由于制作视频比较费事费力，公司并没有准备马上把这个功能投入使用。这个功能目前并不完善，还有很多要改进的地方，但是由于不是当下的关键业务，它的优先级低了不少。测试人员在测试过程中，也不用投入太多精力去关注这个功能。

在测试过程中需要把系统的质量状况跟业务紧密关联起来，需要能够识别出系统缺陷对业务带来的影响，包括可能影响到的用户数、具体的影响是什么、有没有可以绕过的方法不至于中断业务的开展等。如果影响到最关键的客户，那么相同严重性的bug，对于只影响少量不怎么重要的客户来说，优先级也是完全不一样的。

下面几个方面可以帮助我们开展测试活动的时候更好的考虑业务影响：

定期跟PO等关键业务人员沟通，以保证大家对业务优先级的一致认识，测试策略、测试计划要考虑基于业务优先级来制定。
对于任何代码变更，不能是盲目的无重点的回归测试，要基于业务风险来测。
对于自动化测试，需要权衡成本和收益，更需要基于业务风险来考虑，不能盲目覆盖、事倍功半，要以最小业务风险实现最佳测试覆盖。
利用生产环境下的QA技术，收集生产环境数据并分析，我们可以更好的理解业务关键性和优先级。

04. 关联业务指标

除了前面三个维度，在度量项目/产品的测试或质量的时候，不能仅局限于项目/产品范围，要跟企业的业务指标相关联，跟踪、量化测试活动对业务指标的影响。这个维度是非常重要的。

测试不再是考虑发现尽量多的缺陷，而是要基于如何快速将产品投递到市场的战略，尽快让企业能够借助产品盈利。

做到这个维度，需要：

从相关干系人那里确认业务指标，定期跟各干系人沟通，收集对于业务指标的反馈并更新。
收集和分析生产环境的真实数据和模式，反馈到开发过程去更精确的预防缺陷，提高内建质量。

05. 小结

以业务为导向的测试，主要的是思维方式的转变，各个环节要加强对业务的关注。基于前面四个维度去思考，有利于帮助我们把优化业务价值落地。

一页纸测试策略

发表评论

【摘要】测试策略文档通常是篇幅较长、文字为主的形式，编写成本较高，并且写完了很少有人去看，形存实亡。本文介绍可视化的方式，将测试策略用图来表达，并且在一页纸上搞定，这样的策略图非常清晰，关键信息一目了然，并且提供更大的讨论空间，防止僵化，真正能够发挥策略的作用。

“测试策略是什么样的？”
“测试策略嘛，还不是包括#&~+-=～*-+$这些…”
“你们项目的策略有什么特别的吗？”
“我们项目嘛，测试策略的内容有点多，从哪说起呢？”

前面那个场景有没有似曾相识？你是否清楚目前你们正在使用的测试策略是什么样的？

01. 常见测试策略

测试策略的内容与形式

我们都知道，测试策略包括以下两方面的内容：

测什么（What）？ 测什么是指质量需求是什么、需要关注质量的哪些方面，比如应用的功能范围、性能、安全、易用性等非功能需求。
怎么测（How）？ 怎么测就是采用什么办法来帮助系统实现质量需求，而不仅仅是手动和自动化的测试方法，也包括一切为质量保障服务的流程、环境、基础设施和人员等。

为了描述清楚要测的内容以及如何来测，测试策略通常篇幅较长的文档，包含多个章节；以文字描述为主，只加上少量的配图。

【图片来自网络：https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html】

测试策略的痛点

长篇大论的文字给人带来居多不便：

1. 编写困难

篇幅较长的测试策略文档要写好还真不是件容易的事情，尤其是对于理工科出身的不是那么擅长写作的测试人员来说，更是比较麻烦，成本较高。

2. 不易阅读

长篇大论的测试策略文档，要从中快速找出关键信息可没那么容易，可能一不小心错过的细节就是最关键的部分，因为篇幅太长，通常不太重要的信息挺多的。

3. 维护、更新痛苦

策略文档不可能一成不变，这种篇幅较长的文档要更新和维护简直是噩梦。往往刚开始还好，随着时间推移，更新和维护越来越麻烦。

4. 失去了策略的价值

由于不易阅读，也不易维护和更新，事实上团队可能有很多人并不是很清楚策略文档上的内容，这样的策略文档形存实亡，不能真正起到策略的指南作用。

5. 反敏捷

敏捷开发强调的是缩短反馈周期，快速交付高质量的软件产品。花费太多精力编写、维护一份不能起到策略作用的长篇幅文档，显然是不利于敏捷的，也是非常痛的。

测试策略的重要性不言而喻，是否可以找到一种更好的表达方式，让测试策略不那么痛呢？Jamie McIndoe在“Testing Stuff – A One-Page Test Strategy”中首次提出可以把测试策略图视化，用一页纸来搞定。

我们都知道，图示化的表达方式直观、清晰，容易识别关键信息，并且易于记忆。如果能够用图示化的方法将测试策略在一页纸上搞定，一定非常棒。

下面一起来看看图示化表达的测试策略是什么样的。

02. 图示化测试策略

一页纸搞定

顾名思义，图示化就是用图来描述测试策略的内容，但并不是把原来文字描述的每个章节直接翻译成图。我们考虑用图来表示测试策略的各个关键组成部分，并且绘在一页纸上。

当然，一页纸的测试策略只是将关键信息以图示化的方式呈现出来，并不是整个测试策略的全部，在一页纸的背后是团队的充分沟通和对策略各个方面达成的一致认识，是需要团队一起来做很多工作的。这种高度简化的呈现形式，是为了给团队更多的讨论空间，一页纸也更易于修改，从而更能适应变化，真正满足需求。

基于Jamie McIndoe的可视化测试策略思想，我建议的测试策略图包含下列信息：

指导性原则：团队为质量负责
如何测：测试左移、精益测试、测试右移，涵盖测试流程、测试类型、测试方法等
测什么：包括功能、性能和安全等

下面将以蓝鲸项目为例来介绍这几个部分的内容。关于蓝鲸项目，是一个历经10年的离岸交付项目，采用的是敏捷开发的模式，每四到五周一次发布，遵循敏捷开发的各种实践。

例如，蓝鲸项目的测试策略如下图所示：

各部分详细介绍

下面，我们来看看该测试策略各组成部分的具体含义。

1. 指导性原则

蓝鲸项目采用的是敏捷开发模式，质量不是某个单一角色的事情，团队为质量负责是项目质量保障的指导性原则，需要所有团队成员对此有一致的认识，人人都要有关注质量的意识。更多关于团队为质量负责的内容，请参考我的博客文章说好的团队为质量负责呢。

2. 测试左移与质量内建

敏捷测试最关键的两点就是尽早测试和频繁测试（Test early, test often），也就是测试左移与质量内建的思想。

测试左移要求在需求分析阶段开始对需求本身的合理性进行验证，不仅要正确的构建产品，更重要的是构建正确的产品，这就需要把好源头需求这一关。因此，我们可以看到策略里的流程是从需求分析开始的。

质量内建则是在软件开发生命周期的每个阶段都有质量相关的活动，把质量融入到开发的每一个步骤，通过CI/CD等方式获取快速反馈，做好软件缺陷的预防，以减轻缺陷暴露太晚带来的大量修复成本。

蓝鲸项目的开发生命周期主要体现在下图的七个环节，每个环节都有相应测试活动的开展，并且每个活动都有不同角色的参与。

3. 精益测试

精益测试可以理解为以业务价值为目标，以尽量少的成本交付高质量的软件，也就是说测试要测在能体现价值的点上，要做到有效覆盖、减少浪费。蓝鲸项目的策略图里有两个框架帮我我们更有效的测试，分别是测试象限和测试分层。

测试象限

在Lisa Crispin和Janet Gregory合著的书籍《敏捷软件测试：测试人员与敏捷团队的实践指南》中，我们看到了敏捷测试象限的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境，我在这里称之为测试象限。

测试象限矩阵一共四个部分，称为四个象限。下侧是面向技术的测试，上侧是面向业务的测试；左侧是支持团队的测试，右侧则是评价产品的测试。

1) 支持团队的测试

支持团队的测试是用来告诉团队要写什么代码，起到明确需求、辅助设计的作用。其中，第一象限是面向技术的支持团队的测试，主要是TDD，帮助构建产品的内部质量，也就是代码质量的保障，比如单元测试和API测试等；第二象限则是面向业务的支持团队的测试，从更高层次以业务专家可以理解的方式确定系统期望的行为，做到产品外部质量的保障。

这两个象限的测试能够快速提供反馈信息，并确保快速的解决问题，既指导了功能的开发，又提供了防止重构和新代码的引入而导致不期望行为发生的安全网。

2) 评价产品的测试

程序员编写的代码可以使得左侧面向业务的测试通过，但也可能没有产生客户真正想要的东西，因此还需要第三、第四象限的评价产品的测试。

第三象限是面向业务的评价产品的测试，通过模仿真实用户使用应用的方式，帮助确认是否构建了真正需要的产品；第四象限是面向技术评价产品的测试，主要采用工具和相应的技术来评价产品的性能、健壮性和安全性等非功能特性，并且在开发周期的每一步都要考虑这些测试的开展。

这两个象限的测试中产生的信息应该反馈到象限矩阵的左侧，并用于创建新的测试来驱动下一步开发，形成良性的增强环路。

3) 测试象限的使用

象限的顺序跟测试执行的顺序无关，敏捷开发往往开始于客户测试（面向业务的测试）。与测试执行时机相关的因素通常有：

产品发布的风险
客户方对产品目标的要求
是基于遗留系统的开发还是从零开始构建的新系统
可利用的测试资源等

测试象限提供一种需要哪些测试来保障质量的思考框架，可以根据项目具体情况，结合考虑以开展对应的测试。策略图所示蓝鲸项目的测试象限体现的测试类型跟Lisa书里介绍的就不太一样，这是根据项目当前跟客户的合作方式、业务需求、质量要求等来确定的当下需要执行的测试，比如其中的安全测试就分为业务部分和技术部分。

测试分层

关于测试分层的思想，大家可能比较熟悉的是测试金字塔，主要是针对自动化测试，根据测试所能覆盖的范围分成不同的层。金字塔的含义是测试比例的多少，体现为底层单元测试较多，越往上层测试比例越少，呈现为金字塔结构。

越往底层的测试越接近代码，编写成本更低、执行速度更快、定位问题也更准确，但是离业务较远，不能很好的体现业务价值；越往上层的测试越接近业务，更能反应业务价值，但有着不够稳定、执行速度慢、实现成本较高的不足。因此，需要权衡利弊，根据项目具体情况，真实的目标来确定每层测试的比例。

至于具体的比例是金字塔结构，还是蜂巢结构或其他，并不是一定的，也不会是一成不变的，可能受到价值目标、痛点、质量要求、技术架构、技能水平等因素的影响。

蓝鲸项目的策略图里的是当前的测试分层结构，类似于蜂巢机构，那是因为基于微服务架构的特点，蓝鲸项目更多的自动化测试是保障服务间连通性的API测试部分，而对于单元测试和端到端测试的比例则都有减弱。更多的关于蓝鲸项目测试策略的详情，请参考我的博客文章微服务测试的思考与实践。

4. 测试右移

由于软件系统所处生态环境越来越复杂，技术架构的演进、业务复杂度和数据量的增加、基础设施的发展带来更多的不确定性，软件系统的质量保障在测试环境已经搞不定了，我们需要把目光右移到生产环境。这就是测试右移的思想，其实也就是生产环境下的QA(QA in Production)。

生产环境有着不同于测试环境的特点，生产环境的QA并不是测试环境的QA的直接后延，而是需要利用其特点通过技术手段收集生产环境一切可利用的数据，包括日志、用户行为、用户反馈等，利用这些数据来分析和优化业务以及开发过程的开发和测试工作，形成一个开发过程与生产环境信息分析的良性循环系统。

蓝鲸项目在这方面做了不少工作，更多相关的详细内容，请参考我的博客文章生产环境下的QA和QA与Ops通力合作打造反脆弱的软件系统。

5. 测什么

之所以把这个放到最后介绍，是因为前面介绍“怎么测”的各个部分都已经涵盖到要测试的内容，蓝鲸项目的测试内容主要有：功能、性能和安全。

这三个方面的测试类似，都是从需求分析到生产环境每个环节都要考虑相关测试，做到质量内建、安全内建和持续的性能测试。关于功能方面的质量内建，前面【测试左移与质量内建】部分有介绍，对于安全和性能方面的策略，可以参考如下图示，由于篇幅有限，本文不做赘述。

03. 测试策略的正确打开方式

一页纸搞定的测试策略，优势非常明显，比传统策略文档更加简洁、清晰，关键信息一目了然。我们再来看一下测试策略图示化以后，还有哪些需要注意的方面。

目标驱动

虽然上网搜索能找到很多测试策略模板，但测试策略不应该是千篇一律的，不可以死搬硬套通用的模板。测试策略受到多种因素的影响，比如：业务价值、质量要求、当时痛点、技术架构、技术能力、工作重心、绩效要求、项目状态等等。

制定测试策略需要明确目标，综合考虑各种因素，权衡利弊，找到最适合自己项目当前状态的策略。也就是说，测试策略应该是目标驱动的。

演进式

项目处于不同阶段会有不同的质量目标，同时随着架构的演进和业务的发展，对软件系统的质量保障工作也需要随之调整。因此，测试策略还应该是演进式的、随需调整的。

图示化的测试策略是高度精简的，具有更大的讨论和发挥空间，在防止僵化、保持演进方面的优势明显。

04. 总结

测试策略举足轻重，内容很重要，需要以价值目标驱动，持续度量，并根据项目特定情况适时调整、演进。策略文档不要拘泥于形式，利用图示化的方法，直观、清晰的表达，是非常好的组织形式，能有效克服常规文字为主的文档所带来的痛，推荐大家使用。

05. 延伸阅读

Jamie McIndoe的Testing Stuff – A One-Page Test Strategy：https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
说好的团队为质量负责呢：https://www.bylinzi.com/2019/07/14/everyone-is-responsible-for-quality/
QA in Production：https://martinfowler.com/articles/qa-in-production.html
蓝鲸项目测试策略之微服务测试的思考与实践：https://www.bylinzi.com/2018/06/28/microservices-testing/
生产环境下的QA：https://www.bylinzi.com/2016/06/13/qa-in-production/
QA与Ops通力合作打造反脆弱的软件系统：https://www.bylinzi.com/2018/10/15/qaops/

我的节奏，由我掌控

发表评论

01

作为一个重度季节性过敏性鼻炎患者，每年的春季都是非常难熬的，2019年的春天感觉尤其严重，含激素的抗过敏药成为了最好的陪伴。这样的后果就是食量大增，体重飙升，到达了一个自己不敢正视的数值。

4月份，跟朋友一起大吃了一顿红油火锅之后，突然觉得非常腻，再也不想摄入大油的食物。其实是身体在给我发出警告，告诉我需要做点什么了。

2019年4月，开始了我的减重之旅。

方法：调整饮食+适量运动

我一直不喜欢节食，因为挨饿太难受。调整饮食结构很简单，主要是控制主食和油脂类的摄入，把我最爱吃的白米饭换成了五谷杂粮饭或者荞麦面，戒掉肥肉和大油食品，多吃瘦肉、鱼类、蔬菜和豆制品，适当控制饱餐程度、少吃撑。

另一方面是运动。为什么说适量运动呢？其实，我有断断续续跑步运动多年，但是效果不好，运动完不是舒服的感觉，而是很容易生病。后来我才知道，那是因为那些运动超出了身体的负荷。这回开始关注运动时的心率，跑步不再追求速度和跑量，而是控制在自己感觉相对舒服的心率范围。天气冷热适中的秋季，我坚持了两个月晨跑，其他时间保持每周一到两次运动。

八个月以来，我并没有挨饿，也没有很大的运动量，但效果是不错的：体重成功的减少到十年前的水平，睡眠质量更好了，精力也变得更加充沛。

这是我分享的第一个故事，也是我2019年最有成就感的一件事情。我真正找到了自己健康的节奏！

02

作为曾经在学生时代最害怕写作文的我，工作之后竟然喜欢上了写文章。技术文章可以没有太多的文采，只需要对技术实践进行总结和提炼，每一次写作自己都能有很大的收获。慢慢的写多了，看待事情的角度和深度都会发生变化，从而会引出更多的思考。

从2015年的第一届博客大赛开始，我保持每届大赛都有输出，但是写出文章首先需要积累，需要不少时间和精力去阅读大量资料、进行各种实践，每一篇文章的出来并不轻松。另一方面，每一次写作都有点即兴的味道，并没有太系统的体系，也没有很持续的节奏。

同样是在2019年4月，我创建了自己的个人博客网站，也开启了个人公众号。同时开始整理自己的知识体系，希望能够更加系统化的输出。

比不了洞见帝的更新频率，也比不了台长文章的访问量，我只是尽量持续的总结分享一些我的经验和想法。

八个月以来，感谢各位朋友的关注，收到不少对我文章的肯定反馈，给我带来很大的激励我前行的动力。

这是我分享的第二个故事，2019年的这段经历让我不再那么着急和焦虑。我渐渐的找到了自己成长的节奏。

03

刷刷抖音，逛逛朋友圈，还有各种励志鸡汤文，别人的生活是多么的幸福美好；而自己，面临的是工作、生活的压力，还有孩子的教育问题……就这样，人们都特别的容易焦虑，出现各种浮躁和沉不住气。

在这样的大环境下，找到并掌控自己的节奏，非常重要！

“我的节奏，由我掌控”是一个非常远大的目标，不知道什么时候才能实现，也许根本没法实现。但是，并不妨碍我们从能掌控的事情开始，脚踏实地，少些浮躁，尽力去做好自己能做的一切，包括学习、工作和生活。

写于2019年底，与大家共勉！

新一代支持BDD的测试框架Gauge+Taiko

发表评论

BDD是什么

BDD，Behavior Driven Development，行为驱动开发。

如果你不是很了解BDD，可以参考我四年前的一篇文章说起BDD，你会想到什么，其中介绍过BDD的理论和应用。

我们可以这样来概括BDD：

BDD采用统一的领域特定语言（DSL）来描述业务场景和用户行为，让团队各个不同角色对业务需求有一致认识，从而做到更有效的沟通和更高效的协作；
BDD的目的不是自动化测试，但是BDD可以有效指导自动化测试，基于BDD的自动化测试相当于维护了一份需求活文档，对项目需求的维护和管理非常有价值。

BDD应用框架之Cucumber

BDD的应用

BDD是为解决下面三个方面的问题而生：

协作：多个角色在一个团队，如何从一致理解需求开始高效协作？
语言：不同的角色业务、开发和测试人员分别说自己的语言，如何统一语言，更有效的沟通？
文档：编写和维护的成本都很高，如何低成本的维护一份有价值的文档？

Cucumber是一款支持BDD的框架，有助于帮助团队解决以上问题。

Cucumber支持用自然语言描述业务场景，需要遵循Given-When-Then的格式，这样就可以容易的对应到自动化测试的3A步骤Arrange-Act-Assert，从而实现业务场景的自动化测试。

Cucumber的理想是将可执行的需求规范、自动化测试和活文档有机的结合，如下图所示：

图片来源：https://cucumber.io/docs/guides/overview/

理想很丰满，现实很骨感。Cucumber在实际应用中的情况又如何呢？

Cucumber的痛点

Cucumber框架实现Web自动化测试包括两个部分：Feature（特性）文件和Step Definition（测试实现），在实际应用中人们普遍感觉到它的复杂。

Cucumber特别强调的是协作，Feature文件通常由偏业务的人员来编写，要求遵循Given-When-Then的格式。这种固定的语法对编写人员要求较高，写起来比较费劲，尤其对新人不友好，很多团队反映要写出好的Feature文件特别费时费力。
Cucumber支持多种语言实现测试代码，但它本身并不能实现自动化，对于Web自动化测试需要跟其他自动化工具结合，比如Selenium-WebDriver。实现代码不仅复杂，还有着元素定位难、执行时间长、不够稳定的痛点。

Cucumber-js+Selenium WebDriver实现的代码长这样：

Feature定义:

Feature: Google Search
  Scenario: Finding some cheese
    Given I am on the Google search page
    When I search for "Cheese!"
    Then the page title should start with "cheese"

Steps实现

Given('I am on the Google search page', async function () {
    await driver.get('http://www.google.com');
});

When('I search for {string}', async function (searchTerm) {
    const element = await driver.findElement(By.name('q'));
    element.sendKeys(searchTerm, Key.RETURN);
    element.submit();
});

Then('the page title should start with {string}', {timeout: 60 * 1000}, async function (searchTerm) {
    const title = await driver.getTitle();
    const isTitleStartWithCheese = title.toLowerCase().lastIndexOf(`${searchTerm}`, 0) === 0;
    expect(isTitleStartWithCheese).to.equal(true);
});

新一代BDD框架

蓝鲸项目曾经就是用Cucumber+Selenium WebDriver实现的UI层自动化测试，由于上述痛点，大家觉得UI自动化测试越来越难写，我也因此对BDD丧失了信心。

自从遇到了两款新的工具Gauge+Taiko，我又重新对Web系统的实现基于BDD的自动化测试燃起了希望。

Gauge

Gauge是一款开源的轻量级跨平台自动化测试工具，它的愿景是用更少的代码、更少的维护工作实现更多的自动化测试，有如下特性：

采用Markdown格式，支持用自然语言编写Spec，语法自由，编写工作简单易上手，不管是对业务人员还是技术人员都很友好；写出来的文档格式清晰，很好维护。
Gauge本身可以实现对Web页面的访问和控制，支持多种语言，各种API封装的很好，代码实现部分比Selenium要简单很多，尤其对于编程技能不是那么强的QA来讲非常友好，易上手，代码的可读性也更强一些。

Taiko

Taiko也是一款开源浏览器自动化测试工具,它的特性如下：

交互式的录制体验。Taiko提供类似于irb的REPL，直接输入命令，可以看到浏览器执行结果，同时后续还可以把成功执行的命令直接生成JS代码，非常方便。
Taiko不仅提供常见UI自动化测试工具那样根据Id、name、CSS、Xpath等方式选择页面元素的功能，还提供智能选择器（Smart selector），支持直接根据显示的文本来定位各种类型的页面元素，同时还有支持上、下、左、右这种根据某个元素的相对方位去定位元素的API，很好的解决UI测试页面元素定位难的问题。
Taiko采用隐式的等待（Wait）方式，也可以手动设置超时时间以防有些访问等待时间过长。这种隐式等待相比其他自动化工具需要手动设置等待时间的显式等待方式要更高效、更稳定。
与Gauge的完美结合：Taiko在REPL里执行的浏览器操作步骤，可以通过一个简单的命令直接生产Gauge支持的Step，只需要再去简单的加上step名称就可以，操作及其简单。

Gauge+Taiko的代码长这样：

Spec定义

# Google Search

This is an executable specification file. This file follows markdown syntax. 
Every heading in this file denotes a scenario. 
Every bullet point denotes a step.
To execute this specification, use
    npm test

## Finding some cheese
* Goto Google search page
* Google for "Cheese!"
* Page title starts with "Cheese"

Steps实现

step("Goto Google search page", async function() {
    await goto("www.google.com");
});

step("Google for <query>", async (query) => {
    await write(query);
    await click("Google 搜尋");
});

step("Page title starts with <content>", async (content) => {
    await title().then((pageTitle) =>{
        assert.ok(pageTitle.startsWith(content));
    });
});

总结

协作是人的问题，工具可以起到辅助作用，但是不能解决根本问题，过于严格的工具缺乏灵活性，反而阻碍了高效协作的可能。

Gauge不强调协作，可以作为自动化测试工具独立存在，同时又支持高效协作、支持实现BDD，是一款灵活性更好的框架。它的秘密武器Taiko是一款优秀的Web UI自动化工具，两者的结合堪称完美，让需求规范、自动化测试和活文档的有机结合真正成为可能。

本文只是将Gauge和Taiko跟Cucumber框架从对BDD的角度做简单的对比，更多的关于Gauge和Taiko的高级特性，请参考【延伸阅读】部分相关文章。

BQConf演讲：软件测试人员该何去何从？

发表评论

本文根据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的优先级低了很多…

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

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

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

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

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

选自己所爱，爱自己所选！
坚持就是胜利！

回顾与总结

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

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

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

一起离奇数据丢失案件引发的思考

2条回复

最近生产环境出了一起数据离奇丢失案件，调查过程很曲折，几度进入死胡同…下面跟大家分享整个事件的来龙去脉。

数据丢失案件

8月初，用户批量导入了一批（300+）委托人数据，导入后检查过数据都没有问题。最近（10月中），处理那些委托人的时候，发现所有委托人的某几个列表（list）类型的自定义字段的值都没有了…

这是用户报过来的问题，客户对此特别紧张，涉及到数据丢失，那是优先级非常高的！

团队随即展开调查。

背景信息

委托人的信息存在于两个系统中：从A系统导入，存入A系统的数据库，同时会有同步机制把数据同步到B系统的数据库；在B系统也可以修改这些数据，修改完会同时写入A、B两个系统。

问题排查过程

团队第一反应是怀疑双写和同步之间出了问题，但仔细想想好像没法成立…
怀疑B系统的用户有不当操作，把数据抹去了。但是，通过检查数据变更event，没有发现来自B系统的event…况且，现在是一批数据都没有了，B系统并没有批量操作的入口…
是不是A系统进行过批量操作，导致数据被重写？开发人员看代码，测试人员尝试重试各种相关场景，也是没有成功。同时，从event里也没有找到跟这批委托人相关的任何可疑event…
会不会是第三方的系统写入导致数据没了？随即查看第三方的api和相关event，也是没有找到任何可疑迹象…
能想到的用户相关操作都试过了，也没有任何相关event的记录，难道是直接运行SQL脚本了？客户的相关人员不会无故去运行脚本，怀疑可能我们提供的某次修复生产环境问题的脚本搞得鬼…查看最近这段时间的脚本记录，大家放心了，没有脚本会导致数据丢失！
真的是见鬼了！怎么可能数据就这么莫名其妙的丢了呢？！调查小组几经折腾已经筋疲力尽了，请来了小陈同学。
小陈同学听了前面的排查过程，好像真的天衣无缝，但他还是不甘心，决定再去看看event和log。他重新查了前面提到的那些委托人相关的event，的确没有发现任何可疑。又仔细看了看用户报过来的问题，竟然只是list类型的值丢失了！这一定有什么不对！他赶紧去查看那几个list字段相关event，终于真相大白了！原来是有用户把list里的选项删除又重新以不同顺序添加了一遍，从而导致原来用这些选项的字段值都没有了！（该用户应该是觉得原来顺序不合适……）

我的思考

找到了罪魁祸首，这个案件也就侦破了，日子又恢复了往日的平静。作为QA的我，除了记录下这个过程，也想分享一下我的思考：

数据丢失通常都会比较严重，一般不可恢复或难以恢复，给企业和用户都会带来损失。团队接到这种问题务必引起重视，投入足够的人力去进行调查，如果一波人查到走投无路的话，要及时求助外部力量，往往旁观者清，可能会事半功倍，带来不一样的效果。
调查过程需要结合业务、开发和测试人员的力量，考虑可能会影响的业务场景，从界面操作和系统代码两方面入手，同时排查各种可能性。前面的调查过程大家看着可能觉得挺轻松的，事实上排查各种可疑场景不是一件轻松的事情，因为对于一个复杂系统来说，不是很容易想到每一个场景的…
对于丢失数据的字段本身也是可由用户添加删除的情况，一定要想到还有可能是字段本身被删除了！同时，这里也暴露一个设计和实现上的问题，对于这种字段选项的调整会导致数据丢失的情况，竟然不给用户任何提示…这是需要注意的，后续再有类似的字段一定不可以由用户自由的删减！
日志记录非常重要，而且要记录足够的、清晰的信息，方便对问题的调查。
数据库脚本用版本控制工具管理非常有必要，出问题的时候，执行过的任何脚本都有利于帮助排查可疑情况。

软件测试人员该何去何从？

发表评论

“好多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能够随着年龄和工龄的增长，让自己的能力也能不断的提高，才能让测试工作有更多价值的体现。因此，能力提升至关重要！

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

能力提升路径

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

第一阶段，知识积累

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

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

第二阶段，经验积累

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

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

第三阶段，能力提升

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

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

积累和分享很重要

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

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

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

终身成长

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

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

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

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

高效会议的13条军规

发表评论

每天的会议太多了，我都没有时间写代码了…
最近天天各种讨论，我有好多story都没测了…

在蓝鲸项目经常能够听到这样的声音。这也难怪，团队大了，总有各种会议和讨论，沟通成本上升不少。但是我们不能只是抱怨，如何提高开会的效率才是关键。

前同事李光磊写过一篇《极限会议》就是讲的怎么提高会议效率，写的非常好。但其中的原则要真正实践起来可能还是不那么容易让所有人都能快速理解并实施。

本文通过故事的方式分享日常会议的常见问题，并试图从会前、会中、会后三个阶段来列一些相对比较基础的、比较容易落地执行的规则。

会前

场景一：突如其来的会议

一天早上，小青看了看时间，已经是9点半，半个小时后有个面试，这是上周HR就约好了的，他把候选人的简历拿出来看了看，想提前准备一下。
“小青，咱们几个去开个会，头脑风暴一下下周跟客户的catch up XXX的内容！” 突然听到有人叫他，小青回头一看，原来是老王。
“大概要多久？我十点有个面试呢。 ”
“看进度吧，估计得一个多小时，我半个小时前给你们几个发了邀请了。”
“那我肯定不行！我只有半个小时，你不提前看下日历么？再说你现在才发邀请，也没有提前准备啊，我对XXX不是很了解，感觉我没啥可以输入的…”
“快来不及了，时间不好安排，最近大家都忙。要不你先参加半个小时吧！”
小青没办法，只好去参加会议了，大家陆陆续续来到会议室，等人都到齐已经是9:40了…

小青非常不爽，对于老王来说，似乎这一切很正常，因为这样的情形在项目上并不少见。

从这个场景，我们看到有几个方面的问题：

会议没有提前预定参与人员的时间，也没有查看参会人员的时间是否有冲突；
会议没有准时开始；
没有时间提前准备；
小青可能不是合适的参会人员

场景二：Feature kickoff

BA组织某个team做feature kickoff，这是一个在原来某个复杂feature上的功能扩展，由于业务需要，对原feature的设计有改动。在讲解新feature的设计过程中，大家发现BA目前提供的设计可能有些问题，于是大家开始讨论和澄清原来feature的相关设计是什么样的，时间过去了一个小时，还没有正式回到新的feature的kickoff上来…

这个场景存在这样的问题：

会议的目的是kickoff新的feature，但是新feature的设计并没有相关人员的确认（这种确认并不需要全team的人参加），而导致全team人都在的情况下，浪费了很多时间来讨论设计的合理性。这是会议之前没有足够准备的原因。

（图片来源：https://www.smartlinkin.com.tw/article/3137）

从前面两个场景的问题，我们来总结一下会前的规则有哪些：

1. 确定会议目标：每次会议一定会有一个目标，只有明确目标，这是会议高效的前提。目标不明确的会议，可能没有开展的必要。

2. 确定会议议程：根据会议目标，把会议议程定义清楚，这样才能在开会的时候严格按照议程，准时结束。

3. 确定参会人员：尽量准确的确定参会人员。如果是讨论，要求参会人员都能有输入；如果是宣布某个决定，确保参会人员是需要被通知到的。如果邀请了不一定要在场的人员参会，对双方都是一个浪费。

4. 提前通知参会人员：定好会议时间、地点，要尽早发出邀请，这样有利于参会人员提前安排好其他工作或会议。同时，在发出邀请的时候，需要告知参会人员是否需要有提前准备的内容，比如组织某个讨论可能要提前收集、思考讨论的素材，组织workshop需要提前准备环境或者相关知识等。

5. 准备好会议需要的东西：不管是组织者还是参会人员，对要提前准备的材料、环境等都务必提前准备好，有时候可能还需要准备一些物料等。一旦有其中一人或者某一件东西没有ready，都会影响会议的高效开展。

会中

场景三：某会议室10来人约两个小时的讨论

某team正在会议室开会讨论A话题，讨论已经进行到快两个小时，看得出来屋子里的人都有些疲惫，只剩下少数人还在说话讨论，其他有几个人在看手机或电脑，还有昏昏欲睡的。会开了这么久，原本要讨论的A话题没有得出结论，现在大家已经跑题到讨论B了。
“咱们原定时间是一个小时，现在超时太严重了！再这样下去也不会有结果…先结束吧！”终于有人受不了了。
组织者也发现大家有些失控，只好草草结束了会议…
小明本来很想参与A话题的讨论，但是跟另一个会议冲突，他没能参加。赶在会议结束时刻来到会议室，想了解一下大家讨论的结果。没想到并没有得出结论，想找组织者问问是否有大家发言的记录，他想整理一下看是否有什么发现，结果也令他失望，并没有记录…

从这个场景，我们可以看到会中的几个问题：

严重超时
没有控制大家的讨论范围
有部分人并没有全身心投入到讨论中
没有板书或者记录
会议草草结束，没有结论，没有下一步行动计划

因此，总结会中的规则如下：

6. Timebox：严格控制每项内容的时间，避免会议超时。

7. 如果会议不能围绕目标展开从而没有价值，组织者应该提前结束会议；如果某参与者贡献有限或者没有贡献，TA可以选择提前离开后者组织者请TA离开。

8. 严格按照议程进行：讨论过程中很容易走偏，要注意及时拉回来，如果有新的需要讨论的内容，可以记下来下次再讨论。

9. 集中精力参会：非必须要用的情况下，所有参会人员盖上电脑和手机，专心参与会议内容。既然已经承诺可以参会，就不要担心其他工作被此次会议耽误，修build也不是会上看电脑的理由。如果真的有比会议更紧急的事情，可以不参会。（经常有code review或者feature kickoff的时候，有同学带着电脑一直低头忙着，不知道是在听会议内容，还是在忙什么。这样的情况需要尽量避免。）

10. 确定下一步行动计划：每次会议都需要在会上确定下一步行动计划，如果没有该次会议相关的下一步计划，也需要明确。

11. 做好会议记录：清晰记录会议的内容很关键，不仅可以share给没能参会但需要了解的人，也可以作为后续参考用。最好是在开会期间有人直接记录，而不是会后会议再记，这样能够记得清晰也更省事。

会后

场景四：某team的回顾会议

按照惯例，回顾会议开始都先回顾一下上一次的action。今天的组织者是小树，他找了半天没有找到上次回顾会议的总结邮件，也不知道上次有什么action… 原来是上次的组织者在回顾会议结束之后，忘了发邮件了，好在当时拍的照片还在。对照着照片上的action，发现其中有两三个并没有完成…

这个场景的问题是：会议总结没有在会后发出，action也没有好好执行。

由此，我们可以得出会后需要遵循的规则有：

12. 发出总结：组织者需要针对会议结果进行总结，并且发送给所有需要知晓的相关人员。总结需要包括会议讨论事项、讨论结果、action及其owner等内容。

13. 执行相应的action事项：所有参会人员都要按照会上讨论的结果，执行好自己own的action，不要到下一次会议的时候发现action还没有做，这样非常影响会议的效果。

写在最后

大团队的沟通成本很高，高效沟通非常关键，而涉及多人的会议或讨论更是需要高效开展。前面描述的规则执行起来并不难，但是需要大家都能有这个意识，齐心协力，严格执行。

说好的团队为质量负责呢？

2条回复

问：谁应该为质量负责？
答：QA是负责测试把关，主要负责吧，DEV也要在设计和代码上对质量负责。
问：那其他角色呢？
答：BA还好吧，跟质量的关系没那么大。
……

在蓝鲸项目，似乎大家对质量的关注意识有些欠缺，于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈，上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题，肯定不会有人回答不出。可是，事实并非如此 …

为什么会这样呢？我猜想可能是大家对质量的理解不一致的缘故，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责。

因此，我们来看看质量到底是什么？

质量是什么

产品质量不是检测出来的，从产品生产出来后质量就已经在那了。
——著名的质量管理专家戴明

在讲什么是质量之前，我们有必要区分两个不同的概念：测试只能检测、发现缺陷，而质量要通过缺陷预防来实现。 测试与质量不可同日而语，以后再也不要说“上线这么多问题，测试是怎么测的”这种话了。

那么，质量到底是什么？对于不同的角色、不同的利益相关者，质量有着不同的含义。总的来说，可以分为外部质量和内部质量两种。

1. 外部质量

顾名思义，外部质量就是软件呈现给用户的外部形态，是否有缺陷、是否稳定、是否有性能问题等。也就是最终用户在软件使用过程中的各种体验，包括软件可学习、高效、不易出错、有用、难忘等特性，都属于外部质量范畴。外部质量也可以称为使用质量，主要是从使用软件的用户角度来看的。

外部质量能够被用户直接感知到，直接影响用户的使用，因而显得特别重要，客户/用户一般也比较容易为外部质量买单。

2. 内部质量

同样的，内部质量就是指软件系统内部的质量状态，包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性等。内部质量主要从开发人员角度来看，也称为代码质量。

内部质量不会被最终用户感知到，不容易被客户/用户买单，也常容易被团队忽略。但是，内部质量会影响外部质量，需要团队引起重视，加强设计、开发等环节的质量把控。

3. 内建质量

质量不能被检测出来，要提高软件产品的内、外部质量，都需要通过质量内建（或质量内嵌）的方式，做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试：

自动化测试：从多个层次（单元、组件、端到端等）写自动化测试，并将其作为部署流水线的一部分来执行，每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时，都要执行这些测试。同时，随着项目业务和技术架构的演进，自动化测试策略也需要随之调整、不断改进。
手动测试：手动测试也是很关键的部分，如需求验证、演示、可用性测试和探索式测试等，在整个项目过程中都应该持之以恒的做下去。

另外，质量内建不仅要考虑功能测试，对于跨功能测试同样是需要做到内建的，比如安全内建、持续性能测试等。

软件构建过程中多大程度上做到了质量内建，有多少缺陷做到了提前预防，这是“内建质量”。内建质量虽然跟内、外部质量不在一个维度，但也是体现质量好坏的一个方面，在此也把它作为衡量质量的一个维度，测试或使用过程中发现的缺陷数量可以作为度量指标。

因此，我们可以从这三个维度来度量软件产品的质量，可以通过以下方式来度量：

外部质量：用户反馈、Support的问题数量

内部质量：code review、结对编程、静态代码质量检查

内建质量：测试环境、生产环境缺陷，Support的反馈

了解了三个维度质量的含义，我们不难理解：

❌质量不是零缺陷，不是百分百的测试覆盖率，也不是没有技术债；
✅质量是快速反馈，任何改变能够快速验证，并且快速修复；
✅质量是把精力都集中在正确的事情上；
✅质量是团队在代码、设计和交付上有信心做出改变；
✅质量是团队对任何改变负责。

容易忽视的质量

从前面对质量的定义，广义的质量其实包括软件产品交付流程中的方方面面，每个环节的一点疏忽都可能对软件质量造成不同程度的影响。下面列举一些从项目上经历的对质量关注有所欠缺的内容：

需求分析过程仓促，或者参与人员角色比较单一，导致业务上下文了解不够，关键场景缺乏考虑等；
忙于交付更多的feature，忽略了对代码质量的关注，该重构的没有重构，在原本不太健康的代码基础上继续增加更多的代码，导致混乱，筑起高高的技术债；
没有足够的测试覆盖，导致新增代码容易破坏已有功能；
Dev提交代码后，就投入新代码的开发，对所提交代码缺乏关注，CI pipeline红了不能及时修复，可能影响后面QA的测试进度；
大面积的重构发生在release前夕，无法全面回归，带来很大的风险；
项目初期只考虑少量用户的场景，随着业务的发展，系统功能难以扩展，导致严重性能瓶颈；
技术选型失误，开发困难，没有及时改进，一错再错，最后问题严重到无法弥补；
第三方组件评估不够充分，导致线上环境无法承载等；
开发缺少对异常情况的处理，测试过程缺乏探索，只覆盖到主干路径，边角case可能引发问题；
开发或者测试都只考虑当前功能模块，缺乏更广范围的考虑；
缺乏跨功能需求的关注，导致严重的安全或者性能问题；
对线上环境了解不够，而且没有足够日志信息记录，线上问题难以定位，导致宕机时间过长；
……

这样的问题还有很多很多，无法一一枚举。每个角色，每个环节都有可能出现纰漏，导致产品质量问题。

那么，谁该为质量负责是不是已经很清楚了？

谁该为质量负责

前面已经讲到，质量是贯穿项目整个生命周期的非常关键的部分，质量保障工作也是需要在每个环节加强关注，每个角色都需要为质量负责。

上表列出的是敏捷开发流程中的各个实践活动，它们都与质量有关，每个活动都要求多个不同的角色同时参与。

下面从敏捷团队三个主力角色BA、QA和Dev的不同视角来看看各自怎么为质量负责。

BA：Busines Analyst，业务分析师

BA主要负责业务需求的分析工作，要理解客户的业务，并将业务分解成便于Dev和QA理解的功能点，同时，还要能够帮助用户验证开发完成的软件系统功能，并展示给客户。需求作为软件开发的源头，是极为关键的。

BA视角的质量，主要是需求分析的准确性和清晰度，要帮助团队对需求有一致的认识，从用户旅程的角度关注交付给最终用户的产品是否真的带来了价值。

Dev：Developer，开发人员

Dev作为软件系统实现的主力，对质量内建是至关重要的。从需求的理解、整洁的代码实现、测试覆盖率的保证、频繁的代码提交、持续的集成、对生产环境的关注、运维的支持等方面，都有着不可替代的职责，每个环节都不可忽略。

因此，Dev视角的质量不仅是按照需求实现功能的开发，还要把功能高效的交付给最终用户。

QA：Quality Analyst，质量分析师

QA作为软件质量的倡导者，是唯一一个全流程都要参与的角色，从需求到上线后的支持，每个环节都不可缺。清晰理解需求、制定质量保障策略、做好各个环节的测试工作（手动、自动化、探索式、跨功能、非功能测试，以及生产环境的QA等）、关注项目整体质量状态、及时反馈质量信息给团队、识别业务风险和优先级、帮助优化业务价值，这些都是QA的职责。

三个主力角色中的BA一般都会有从用户旅程的角度去考虑，其实Dev和QA也需要同样的思维模式，不能把story或者AC割裂来看，而是要从整体的用户旅程的角度、端到端的去考虑需求的实现和测试工作。

除了三个主力角色，团队还有其他角色也都是要对质量负责的，比如：架构师要负责项目架构的健康，基础设施负责人要管理和维护好基础设施以保障开发和运维工作的顺利开展，PM要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等，这些都是跟质量相关的。

写在最后

质量不仅是某个角色的事情，团队每个成员都撇不开质量这个话题。团队为质量负责要求所有质量角色都将质量推向看板的左侧，从每个用户故事的开始就将质量融入其中。

软件开发生命周期的每个环节、每个实践活动都不可轻视，只有在每个点上都做好质量的工作，才能实现真正的高质量交付，每个角色对此都有着非常重要的职责。

软件测试人员的挑战与机遇

发表评论

“我们公司的测试好多都转业务或开发了，还有的转管理了，测试做不长久…”
“现在好多公司已经不招测试人员了，感觉测试没有什么前途…”
“ThoughtWorks技术雷达上都是开发相关的内容，测试相关的内容越来越少…”

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

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

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

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

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

Terraform生态系统

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

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

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

四个关键指标

埃森哲发布的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的竖表示能力深度。前面提到的方方面面都属于广度，包括不同技术和不同业务领域的扩展，而深度就是对于其中一个领域进行深入的学习研究，发展对应的测试技能。

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

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