标签归档：技术雷达

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

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

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

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

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

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

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

回顾与总结

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

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

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

软件测试新趋势

发表评论

2015年11月，ThoughtWorks发布了新一期的技术雷达。技术雷达是以独特的形式记录ThoughtWorks技术顾问委员会对行业产生重大影响的技术趋势讨论的结果，为从CIO到开发人员在内的各方利益相关者提供价值。这期雷达的技术趋势主要体现在：受到热捧的微服务相关技术，逐步成熟的以Docker为典型的容器化生态系统，备受企业和用户关注的信息安全问题。本文就从这几个新趋势来分析一下给软件测试带来了哪些影响。

自动化测试是王道

在这个快速变化发展的时代，任何一款产品想要在市场具备竞争力，必须能够快速适应和应对变化，要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付，自动化测试将必不可少。同时，自动化测试也不是用代码或者工具替代手工测试那么简单，有了新的特点和趋势：针对不同的产品开发技术框架有着不同的自动化技术支持，针对不同的业务模式需要不同的自动化测试方案，从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。来自技术雷达的下列主题分别体现了自动化测试的这些特点：

– 针对微服务的消费端驱动的契约测试（Consumer-driven contract testing)，有助于解决随着服务增多带来集成测试效率低和不稳定的问题。消费端驱动的契约测试是成熟的微服务测试策略中核心的组成部分。

– 专门用于测试和验证RESTful服务的工具REST-assured，它是一个Java DSL，使得为基于HTTP的RESTful服务编写测试变得更加简单。REST-assured支持不同类型的REST请求，并且可以验证请求从API返回的结果。它同时提供了JSON校验机制，用于验证返回的JSON数据是符合预期的。

– 安卓系统功能测试工具Espresso，其微小的内核API隐藏了复杂的实现细节，并帮助我们写出更简洁、快速、可靠的测试。

– ThoughtWorks开源的轻量级跨平台测试自动化工具Gauge，支持用业务语言描述测试用例，支持不同的编程语言，支持所支持平台的并行执行。

– 用于针对UI的自动化测试构建页面描述对象的Ruby库Pageify，该工具关注于更快的执行测试以及代码的可读性，并可以很好的配合Webdriver或是Capybara使用。

– 专门用于iOS应用开发的开源行为驱动开发测试框架Quick，支持Swift、Objective-C，它和用来做测试验证的Nimble捆绑发布。Quick主要用于Swift和Objective-C程序行为的验证。它和rspec和jasmine具有相同的语法风格，基础环境很容易建立。Quick良好的结构和类型断言使得测试异步程序更加容易。Quick拥有现成的Swift和Objective-C规范文件模板，开发者只需4步，即可对应用进行快速测试。

工具很重要，设计不可少！自动化测试工具云集，但做自动化也不要冲动，需要重视以下几点：

– 综合考虑项目技术栈和人员能力，采用合适的框架来实现自动化；

– 结合测试金字塔和项目具体情况，考虑合适的测试分层，如果能够在底层测试覆盖的功能点一定不要放到上层的端到端测试来覆盖；

– 自动化测试用例设计需要考虑业务价值，尽量从用户真实使用的业务流程／业务场景来设计测试用例，让自动化优先覆盖到最关键的用户场景；

– 同等看待测试代码和开发代码，让其作为产品不可分割的一部分。

自动化测试

云技术、容器化和开源工具使得测试成本下降

测试环境的准备在过去是一个比较麻烦和昂贵的事情，很多组织由于没有条件准备多个测试环境，导致测试只能在有限的环境进行，从而可能遗漏一些非常重要的缺陷，测试的成本和代价很高。随着云技术的发展，多个测试环境不再需要大量昂贵的硬件设备来支持，加上以Docker为典范的容器技术生态系统也在逐步成长和成熟，创建和复制测试环境变得简单多了，成本大大的降低。技术雷达推荐的凤凰环境（Phoenix Environment），它能够以自动化的方式支持测试、开发、UAT和灾难恢复所需的新环境准备。这一技术由上期的评估环上升到了采用环，表明它已经得到了验证和认可，是可以放心使用的技术。

另一方面是大量开源工具的出现，这些工具往往都是轻量级的、简单易用，相对于那些重量级的昂贵的测试工具更容易被人们接受。测试工作有了这些开源工具的帮助，将更加全面、真实的覆盖到要测试的平台、环境和数据，将会加快测试速度、降低测试成本；更重要的一点，有了这些工具，让测试人员能够腾出更多的时间来做测试设计和探索性测试等更有意思的事情，使得测试工作变得更加有趣。新技术雷达提到的开源工具有：Mountebank、Postman、Browsersync、Hamms、Gor和ievms等。

– 在企业级应用中，对组件进行良好的测试至关重要，尤其是对于服务的分离和自动化部署这两个关系到微服务架构是否成功的关键因素，我们更需要更合适的工具对其进行测试。Mountebank就是一个用于组件测试的轻量级测试工具，可以被用于对 HTTP、HTTPS、SMTP和TCP进行模拟（Mock）和打桩（Stub）。

– Postman是一个在Chrome 中使用的REST客户端插件，通过Postman，你可以创建请求并且分析服务器端返回的信息。这个工具在开发新的 API或者实现对于已有API的客户端访问代码时非常有用。Postman支持OAuth1和OAuth2，并且对于返回的 JSON和XML数据都会进行排版。通过使用Postman，你可以查看你通过Postman之前发起过的请求，并且可以非常友好的编辑测试数据去测试API在不同请求下的返回。同时，虽然我们不鼓励录屏式的测试方法，但是Postman提供了一系列的拓展允许我们将它作为跑测试的工具。

– 随着网站应用所支持设备的增多，花在跨设备测试上的代价也在不断增大。Browsersync能够通过同步多个移动设备或桌面浏览器上的手工浏览器测试来极大的降低跨浏览器测试的代价。通过提供命令行工具以及UI界面，Browsersync对CI构建非常友好，并且能够自动化像填写表单这样的重复任务。

– 在软件开发领域，盲目地假设网络总是可靠，服务器总是能够快速并正确的响应导致了许多失败的案例。Hamms可以模拟一个行为损坏的HTTP服务器，触发一系列的失败，包括连接失败，或者响应缓慢，或者畸形的响应，从而帮助我们更优雅的测试软件在处理异常时的反应。

– Gor可以实时捕获线上HTTP请求，并在测试环境中重放这些HTTP请求，以帮助我们使用到这些产品环境数据来持续测试我们的系统。使用它之后可以大大提高我们在产品部署，配置修改或者基础架构变化时的信心。

– 尽管IE浏览器的使用量日益萎缩，但对很多产品而言IE浏览器的用户群依然不可忽视，浏览器兼容性仍然需要测试。这对于喜欢使用基于Unix的操作系统进行开发的人来说还是件麻烦事。为了帮助解决这个难题，ievms提供了实用的脚本来自动设置不同的Windows虚拟机镜像来测试从IE6到Microsoft Edge的各种版本浏览器。

测试成本降低

安全测试贯穿整个生命周期

“安全是每一个人的问题”！互联网安全漏洞频繁爆发，安全问题已经成为每个产品迫切需要关注和解决的问题，安全测试将需要贯穿于软件开发的整个生命周期。同时，给软件测试人员带来了更多的机遇和挑战，要求具备更多的安全相关知识（其中还包括更多的计算机基础知识），掌握已有的安全测试相关技术，从而在软件开发的各个阶段做好安全相关的分析和测试工作。尽管有些团队已经将安全跟整个开发实践结合起来，但培养每个人在每个阶段的安全意识还相当的重要，探索新的安全测试技术、方法还有很多空间。

安全测试贯穿软件生命周期

技术雷达上列出的安全测试相关的技术和工具有：Bug bounties、威胁建模（Threat Modelling）、ZAP和Sleepy Puppy。

– Bug bounties是一个安全漏洞举报奖励制度，越来越多的组织开始通过Bug bounties鼓励记录常见的安全相关的Bugs，帮助提高软件质量。

– 威胁建模（Thread modeling）是一组技术，主要从防御的角度出发，帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时，这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。

– ZED Attack Proxy (ZAP)是一个OWASP的项目，允许你以自动化的方式探测已有站点的安全漏洞。可以用来做定期的安全测试，或者集成到CD的Pipleline中提供一个持续的常规安全漏洞检测。使用ZAP这样的工具并不能替换掉对安全的仔细思考或者其他的系统测试，但是作为一个保证我们的系统更安全的工具，还是很值得添加到你的工具集里。

– Sleepy Puppy是Netflix公司近期开源的一款盲打XSS收集框架。当攻击者试图入侵第二层系统时,这个框架可用于测试目标程序的XSS漏洞。XSS是OWASP的Top10的安全威胁，Sleepy Puppy可以用来同时为几个应用完成自动安全扫描。它可以自定义盲打方式，简化了捕获，管理和跟踪XSS漏洞的过程。Sleepy Puppy还提供了API供ZAP之类的漏洞扫描工具集成，从而支持自动化安全扫描。

优化业务价值

大多数软件都是做项目的模式，在不同的档期内进行计划、实现和交付。敏捷开发极大的挑战了这种模式，通过在开发过程中各个阶段进行的分析和测试工作，持续的发现新的需求，使得需求更趋于合理化，更能体现业务价值。精益创业的技术，如观察需求的A/B测试，进一步削弱了这种心态。技术雷达推荐“产品优于项目（Product over project）”，认为大多数的软件开发工作应该遵循精益企业的引领，将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付，更多的是一个探索如何更好的支持和优化业务流程的过程，只要业务依然有价值就会不断持续下去。

作为软件开发中的关键角色、负责软件测试的QA人员，通过从用户角度对软件的测试，结合自身对软件产品的了解，对优化业务价值将会起到举足轻重的作用。软件测试不仅是检验软件是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程，还需要有意识的对需求进行持续的验证和优化，对业务的趋势和风险进行分析。如果能在开发过程中结合使用BDD（行为驱动开发）的思想，统一团队对需求的认识，利用团队的力量来优化业务将会达到事半功倍的效果。

传统方式下，QA的角色主要专注于保证软件产品在类产品环境下的质量。随着持续交付的出现，QA的角色逐渐转变到需要分析软件产品在产品环境下的质量。产品环境下的QA（QA in production），就是要求QA角色在做好产品上线前的质量保证工作前提下，做好软件产品在产品环境下的质量分析。具体做法有：

（一）引入产品系统的监控，制定检测条件，找出产品环境下使用的质量度量。比如，利用网站分析工具收集用户使用应用程序的数据，分析数据量需求、产品的性能趋势、用户的地域特征、用户的行为习惯和产品在同类型产品市场的占有率等。

（二）收集产品环境下最终用户的反馈，对反馈进行分类分析。这些反馈可能有：

– 缺陷：需要进行优先级划分，确定是否需要修复；并且对这些缺陷进行根源分析，在以后的开发过程中尽量避免同类型的缺陷再次出现。

– 抱怨：对于抱怨需要分析其背后的原因，可能正是能够帮助我们改进和优化业务价值的好机会。

– 建议：一般用户可能难以提出高质量的建议，需要我们在收集反馈的时候下点功夫，有针对性的去收集。一旦收集到了建议，将是对业务价值优化非常有利的。

通过对产品环境下的软件质量进行分析，将有利于协助“产品优于项目”实践，帮助优化业务价值，做好企业产品的创新工作。需要注意的是，产品环境下的QA可能会导致有些组织走的太远而忽视产品上线前的质量保证，它只对那些已经执行并有一定程度持续交付实践的组织有价值。

总结

软件测试是一项技术工作，但软件测试领域的问题不仅仅是技术问题。随着自动化程度越来越高，不断有人怀疑QA存在的必要性，从前面的分析可以看到，新趋势给QA提出了更高的要求，带来了更多的机遇和挑战，相信好的QA是不可能简单的被取代的。

（此文发表于TW洞见和InfoQ）