软件测试人员的职业发展之路

2条回复

在《关于软件质量，大家都在关注什么》一文中，我们了解到软件测试领域新的关键趋势主要体现在以下几个方面：

AI的发展与软件测试
敏捷与DevOps
自动化测试
环境和数据
成本与效能

在这样的趋势下，测试人员的职业发展之路有什么变化呢？我们先来看看测试人员的技术发展方向有哪些。

技术方向

基于前面提到的新趋势，测试人员的职责由单一的测试软件系统是否工作、是否满足业务需求变得更加多样化，测试人员可以全流程参与软件开发，让测试活动贯穿软件开发整个生命周期。因此，测试人员的职业发展技术方向有：

敏捷测试专家
高级测试开发专家
专项测试专家
QAOps专家

1. 敏捷测试专家

敏捷测试强调的是尽早测试和频繁测试，测试人员需要能够从需求分析阶段开始介入，全流程参与，跟整个团队一起实现团队为质量负责。对敏捷测试专家的技能要求有：

领域测试能力：测试人员需要丰富的业务知识、较强的业务敏感度和业务理解能力，熟悉各种不同类型的业务模式，包括新兴业务IoT、智能服务、区块链等，能够制定相应的测试策略，有效协助团队做好质量内建，实现交付价值最大化。

自动化测试能力：自动化测试是敏捷开展的必要条件，自动化测试技能是测试人员的必备技能。成为敏捷测试专家，要求测试人员了解不同的自动化测试框架的优缺点，能够指导项目自动化工具的选型；了解测试分层的思想，能够帮助团队制定合适的自动化测试策略；能够实现业务功能层的自动化测试，能够跟开发人员一起参与底层自动化测试（接口测试、单元测试等）的评审工作；了解持续集成工具，能够在持续集成流水线上配置和运行自动化测试。

沟通协调能力：敏捷测试要求团队为质量负责，测试人员作为主力，需要承担起质量的分析者和协调者的角色，要求有很好的跟不同角色沟通和协调团队合作的能力。

2. 高级测试开发专家

高级测试开发专家的必备技能要求有高级自动化测试、白盒测试、开发和平台构建能力，要求有很强的测试代码编写能力，能够自行开发自动化测试工具、搭建自动化测试框架、构建自动化测试平台和服务。

同时，最好还有AI应用的基础算法应用能力和自然语言处理技能，需要了解和掌握AI相关知识，以及AI知识在测试中的应用，以帮助实现自动化测试的智能化。

3. 专项测试专家

专项测试技能集包括安全、性能等跨功能测试技能，需要有扎实的计算机基础知识，了解安全问题的类型、安全测试工具的优缺点，能够提供安全测试解决方案；熟悉性能影响因素、性能测试关注点以及提供性能调优方案等。

专项测试技能也包括测试数据和测试环境的管理，要求熟悉虚拟化、云计算技术、数据匿名化等数据处理技术，能够提供测试数据和环境管理的方案。

4. QAOps专家

测试右移已经越来越被重视，这意味着测试活动需要右移到生产环境，需要测试人员跟Ops人员更紧密的合作，QAOps专家也应运而生。QAOps专家需要了解基础设施相关技术与实践，了解日志管理、日志监控以及日志分析技术，同时还要有用户行为分析能力，通过跟Ops的合作，充分利用生产环境的各种类型的信息来优化软件开发和测试流程，以实现最终优化业务价值的目标。

管理方向

管理岗位在新的趋势下有些将不复存在，一般在相对传统的组织架构下才会有，但是目前来看还是有相当的企业是适用的，在此也简单聊一下。根据每个公司的情况不同，测试人员直接相关的管理岗位也会有些不同，大体有如下这些：

测试组长
测试经理
项目测试负责人
测试总监

1. 测试组长

测试组长一般带几个测试工程师，负责任务分派和人员管理等工作。除了必备的测试技能外，测试组长需要的管理技能有：

任务优先级识别能力：需要能够识别任务的优先级，并根据当前工作合理分配给不同的人去完成。

培养团队成员的能力：带领团队需要对团队成员进行培养和发展相应的能力，需要能够识别不同人员的自身特点，有针对性的培养相应的技能。

沟通协调能力：要带领好团队，较强的沟通协调能力必定能事半功倍，让团队工作更顺畅。

2. 测试经理

测试经理一般是管理一个测试部门，下面可能有多个测试小组。测试经理除了需要关注技术外，还需要关注部门的发展、绩效等。需要的相应技能有：

技术洞察力：测试经理需要对技术趋势和先进测试工具有较多了解，需要能够帮助团队确定测试技术和测试工具的研究和使用，以提高团队的工作效能。

风险识别能力：测试经理需要能够很好的理解业务需求、识别项目风险，负责制定测试策略和具体的实施方案，并能进行总结、报告，及时反馈项目质量状态。

培养团队成员的能力：团队成员的能力培养非常重要，测试经理跟测试组长一样需要这个技能。

沟通协调能力：测试经理不仅需要协调测试部门内部的各种情况，还需要横向跟公司其他部门进行沟通协调，沟通协调能力更加重要。

3. 项目测试负责人

项目测试负责人主要负责一个项目的质量保障工作，需要有跟测试经理相似的技能：技术洞察力、风险识别能力和沟通协调能力。

4. 测试总监

测试总监是测试经理的延伸，属于质量部门的最高负责人，需要负责公司所有项目的质量活动，所要求的的技能跟测试经理类似。

易转型方向

除了测试直接相关的管理岗位外，根据测试人员的职业特点，以下两个岗位是比较适合转型的方向：

项目经理
产品经理

1. 项目经理

测试人员，尤其是敏捷团队的测试人员，涉及到项目质量相关的方方面面，自然有着能纵观大局的机会，成功转型项目经理的例子非常常见。相应的技能要求有：

团队管理能力：管理团队，包括人员风险识别、协调沟通等方面，需要掌握一定的人际关系相关的软技能。

客户关系管理能力：项目经理除了要搞定团队，还有最为关键的是要处理好跟客户的关系，客户关系管理技能特别重要。

决策能力：决策能力是一种综合的判断能力，即面对几个方案或错综复杂的情况，能够做出正确的判断并采取行动。

2. 产品经理

软件测试人员都需要能够很好的理解业务需求，一般都有很强的业务能力，转型当产品经理是一个不错的方向。产品经理相应的技能要求有：

用户需求挖掘能力：产品经理需要有包括挖掘潜在用户需求、确定需求优先级、构建用户画像的能力。

多维度思考能力：产品经理需要能够从基本维度、外在维度、核心维度和商业价值维度思考的能力。

抽象能力：产品经理不仅要能从事物本身进行抽象，还需要能够考虑不同层次的抽象；抽象完后，还需要把抽象的对象回归到展示层面，需要有抽象回归具象的能力。

三个转变

测试人员要培养前面介绍的技能，首先需要实现下面三个转变：

1. 对测试的认知

测试活动不仅是验证系统功能，可以更加的多样化。比如，测试左移就包括对需要的澄清和验证，测试右移则包括生产环境的监控和信息收集等。

测试人员不是质量的把关者，好的质量意味着要交付更多的价值，而不是没有缺陷那么简单，测试人员不再是发现缺陷越多越有成就，而是要想着如何跟不同角色高效合作，使得交付的产品能够优化业务价值。

2. 对技术的关注

由于测试活动的多样性，不能只关心测试相关技术，要把视野扩展到软件开发过程中各个环节接触到的领域知识和不同类型的技术，不同业务类型、技术架构和基础设施等都会对测试有不同的影响和要求。

3. 测试不可以独立存在

测试不能再以独立部门自居，需要跟不同的角色更多的沟通和合作。比如，需求分析阶段需要跟需求人员有密切的沟通，实现自动化测试过程中可以跟开发人员结对或其他方式的深度合作，生产环境下的测试需要跟Ops人员紧密合作等。

同时，测试人员对于系统所采用的技术架构、技术方案的设计思路都需要有所了解，从而更好的理解开发的工作、理解架构演进对于测试的影响，更好的开展测试工作。

最后

了解了发展方向，如何才能让自己的职业生涯更圆满呢？更多的学习建议可以参考我去年在BQConf的演讲《BQConf演讲：软件测试人员该何去何从》里提到的那几个方面：

确定方向，目标驱动
持续学习，把知识变成技能
勇于突破，系统思考

愿各位测试同仁的职业发展之路更加顺畅！

速度（Velocity）不背这个锅

发表评论

01. 那些对速度（Velocity）的误解

误解1 – 点数跟天数对应？

用户故事的估点跟天数对应，1个点的故事对应2天的工作量；
统计每个用户故事所耗费的天数，如果点数对应的天数到了，先标记为“开发完成”，第二天Desk check就不用增加天数了；
为了赶进度，由结对改为不结对，原来结对的两人并行做不同的task，天数还是按照结对的情况来统计…

问题：

虽然按照故事点来估算，但是每个点都跟天数对应起来，而且不是理想人天，是实际耗费人天；
把这种估算当做一种承诺，要求故事需要在点数对应的天数内完成；
用户故事的只是关注开发完成。

到底该如何估算？点数又该如何使用呢？

误解2 – 做不完了给用户故事涨点？

如果用户故事没有在预定的天数内完成，需要涨点，那么得先说服客户；
列出涨点原因并且跟客户解释不是一件容易的事情，团队有时候宁愿加班加点按照原来的估点完成也不要去跟客户解释…
或者，为了避免以后涨点的各种麻烦，在估算的时候多估一些点，导致估点不准确…

问题：

开发团队的估算不应该受到外部因素的影响；
虚估点导致的估算不准确失去了估算原本的价值和意义。

估算的意义是什么？什么时候需要调整点数进行重估？

误解3 – 速度驱动一切？

周报里的速度保持稳定，每周每对pair在2个点上下；
性能调优，客户觉得目前看不到价值不给点，所以团队就不做了；
技术改进，同样的，客户看不到价值不给点，就不做了；或者团队实在无法忍受想要改进，那就从别的功能用户故事里多估算一些点来留时间给做技术改进；
目前组内开发速度不够，用户故事都做不完了，生产环境的support能给别的组就给别的组做吧，那个太耽误开发进度了！

问题：

一切围绕速度，如果比较顺利，满足了速度要求，团队可能就放松了，不一定会做更多的特性开发；如果不顺利，速度赶不上，那就可能面临着加班或者愁着怎么能给故事涨点以增加速度；
不再是业务价值驱动，不会正常的从价值的角度去考虑工作的优先级，速度被严重的误用。

速度有什么用？又该如何利用呢？

带着这些误解中引发的疑问，我们一起来探讨一下。

02. 两种估算方法

1. 基于故事点的估算

故事点是纯粹对用户故事大小的相对度量，不应该跟任何的天数或者工作量等关联。

用户故事本身的大小属性不会发生变化，基于故事点的估算不会过期，不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如，一个点数为3的用户故事，它的复杂度相对于那个点数为1的基准故事来说不会发生变化，不管谁、也不管用什么技术来开发这个用户故事。

故事点的大小是指团队所有角色工作加一起的统一估算数值，需要多个角色一起合作讨论才能得出这个估算，因此，故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意，不应该按照开发的点数、测试的点数去估算用户故事的大小，需要结合一起给出一个唯一的数值。

2. 基于理想人天的估算

理想人天的估算需要基于这样的假设：

所估算的故事是唯一要做的工作
所有需要的东西在故事开始前都会准备好
故事开发过程中不会被打断。

在不考虑其他因素的情况下，这种理想人天的估算是类似于故事点的估算方法，同样是一种相对大小的估算。

理想时间跟耗用时间是不同的。比如一场NBA比赛的理想时间为12分钟一小节，但是实际比赛耗用时间需要比这个时间长很多，因为中间有暂停、死球等时间。理想人天的估算是基于理想时间的，在软件开发过程中会有多个因素导致实际耗用时间跟理想时间会有很大的不同，比如开会、讨论等。

理想人天的估算方法很容易让人根据一个故事所需完成的任务多少去估算，而不是从这个故事跟其他故事的相对大小角度去考虑；不同人估算的理想人天也会有不同，导致估算可能会不太准确。这在估算的时候是需要特别注意的。

在团队不熟悉故事点估算方法的初期，理想人天的估算方法更容易开始；理想人天的估算对于团队外部人员更容易解释清楚，也更方便预测速度。

哪种方法更好

从前面的介绍可以看到，两种估算方法各有利弊，都是对于用户故事大小的相对度量，不能跟实际完成天数关联起来。通常，更推荐使用故事点的估算方法，根据团队自身情况也可以选择采用理想人天。

03. 什么情况需要重估

前面提到的误解里对于用户故事没有在预定的天数内完成考虑给故事涨点，也就是重估，这种以进度来驱动重估的做法是不对的。没有在估算天数内做完可能有两个方面的原因：
1. 估算不准确，低估了；
2. 被其他工作所打断，或者团队技术原因导致进度较慢…

发现估算不准确的情况可能需要调整，但不能是因为做不完赶不上进度而调整。当所有用户故事的相对大小是准确的时候，不需要重估；只有当其中一个或多个用户故事的相对大小不准确的时候，需要调整该部分用户故事的点数大小。

我们来举例解释这个问题：

1. 不需要重估的情况

假设一个团队有4个复杂度相当的用户故事，原本估算均为3，预计能够在一个迭代完成的。在第一个迭代结束后，只完成了其中的两个用户故事，也就是完成了6个点，团队感觉这两个用户故事比预估的要大，想调整为原来点数的两倍，由6变成12；由于四个用户故事的大小相当，剩下的两个用户故事也需要调整为原来的两倍，剩下的工作量也变成了12，同样的可能还需要一个迭代才能完成。这样的重估就没有意义。

因此，如果只是发现用户故事实际耗费时间比原来预测的要多，但是故事的相对大小并没有问题的时候，不需要重估，而是要去回顾和分析耗费时间长的原因，并采取相应的措施去改进。

2. 需要重估的情况

假设团队由A、B、C、D四个用户故事，刚开始给每个故事的估点均为3。在开发故事A的过程中发现A比原来估算的值要大，需要调整为5才合适，另一个类似的故事B也是一样，需要调整为5；但是C和D跟它们不一样，估算值应该是准确的，还可以保持为3。这种情况下对A和B的重估是有价值的，因为相对大小发生了变化。

04. 速度的作用

速度是对团队的进度生产率的度量，可以通过计算团队在一次迭代中完成的用户故事所分配的故事点数的总和来得到。比如，完成5个3个点的用户故事，速度是15；如果完成了2个5个点的用户故事，速度是10。关于“完成”的定义不能只是到“开发完成”，而应该是“交付完成”，开发完成不能说明什么，可能后续测试还不能过关、有很多缺陷需要修复等情况。

速度可以修正计划的误差。估算把对工作量的估算和对工作时长的估算完全隔离开来，将必须完成的所有用户故事的点数总和除以迭代的速度，可以推算出迭代的次数，也就是项目持续时间。我们通过一个例子来看速度如何修正误差：

假设团队估算出项目中包含了200个故事点的工作，一开始认为可以在每次迭代中完成25点，也就是将用8次迭代来完成工作。但是，在项目开始以后，团队发现速度只能达到20点。这样，不用对任何工作进行重估，就可以正确的认识到项目需要10次迭代，而不是8次。

速度不会是稳定不变的。根据团队对技术和业务领域知识的熟悉程度，速度可能会增加；而随着团队人员调整，有新人加入以后，速度可能会下降。在故事点估算准确的情况下，速度正好是反映团队状态的一个参数。不应该为了保持速度的不变去调整估算的结果，而应该根据速度的变化来观察和分析团队的健康程度。

05. 估算与计划

估算是为了更好的做计划，通过估算推算出的持续时间是一种可能性，而不是对交付时限的一种承诺。估算的是用户故事固有的属性，其大小不应该受到交付时长的干扰。老马在文章《WaterfallProcess》里讲到敏捷开发里的计划应该是适应性的，而预测性的、承诺性的计划不属于真正的敏捷。我们需要认真做好估算，尽量的准确，利用速度并根据团队状态和其他项目因素来适时地调整、修正计划。

适应性计划(https://martinfowler.com/bliki/WaterfallProcess.html)

客户都会希望更短的时间交付更多的功能，但是不要让客户只把目光关注到进度上，要引导客户更多的关注交付的业务价值。因此，在考虑任务的优先级的时候，需要以价值为导向，而不是进度为导向。比如，重构等技术改进、性能调优、生产环境的支持，这些可能比新的特性开发带来的价值更大、有着更高的优先级。

06. 小结

不管是故事点还是理想人天的估算方法，估算的都是用户故事的相对大小，跟实际完成时间没有直接关系。
不能因为用户故事没有在预期的时间内完成而进行重估，只有相对大小发生变化的时候需要重估。
估算是为了更好的计划，不能把估算当做一种承诺；速度是可变化的，可以用来修正计划的误差。
始终要以价值为导向，更多的关注质量而不仅仅是进度，计划应该是可适应性的。

07. 参考文献

《敏捷软件开发实践：估算与计划》，作者：Mike Cohn，译者：金明
《点之殇》，作者：冉冉，https://insights.thoughtworks.cn/story-point/
《WaterfallProcess》，作者：Martin Fowler，https://martinfowler.com/bliki/WaterfallProcess.html

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

发表评论

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

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

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还没有做，这样非常影响会议的效果。

写在最后

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