作者：郑达夫

ThoughtWorks高级软件质量保证工程师。5年软件测试经验，曾任职于IBM，负责Cognos商业智能大数据平台测试。熟悉ETL测试、自动化测试，性能测试及WEB安全测试。加入ThoughtWorks后先后为海外电信公司、海外车企提供软件系统质量保证服务，熟悉复杂业务的端到端测试。

云与性能测试

郑达夫 评论

近年来，随着云计算技术的发展和各种诸如AWS、GCP、阿里云等云平台的日趋成熟，越来越多的的用户选择把系统搭建在云端，因此云测试的概念随即产生。云测试看字面意思就是关于云计算、云平台的测试，而它大体又可以分成两种类型：测试云（Test Cloud）和用云测试（TaaS）。 测试云，顾名思义测试的目标是云，测试者通过设计测试去保证云平台本身和部署在云端的应用正确性。而用云测试是指利用搭建在云端的测试服务 — TaaS （Test as a Service）来进行更高效的测试。云计算有着超大规模、虚拟化、高可靠性、高可伸缩性和按需服务等诸多优点，但平台的特殊性也给测试带来了新的挑战和机遇，其中性能测试受其影响颇深，本文旨在针对云测试的两种类型探讨云与性能测试。

测试云

云环境最大的特点就是能够通过高伸缩性按需为用户分配资源，也正是因为这个特点，我们对于基于云平台的性能测试与普通系统性能测试的最大的区别就是要考虑测试云服务的伸缩功能，因为云服务的伸缩功能可能存在以下风险：

  1. 云服务的auto scaling 不能执行
  2. Auto scaling会造成服务崩溃
  3. Scaling up时资源不足

因此我们设计的测试应该包含以下内容：

测试目标

  1. 确认auto scaling能够根据所制定的策略执行
  2. 确认auto scaling能得到相应的资源
  3. 确认云服务的性能能够满足不同的压力变化

测试方法

给云端系统一直施加压力到性能边界值后继续加压，随后给系统减少压力，观察系统在边界值前后的性能表现。

测试技术

  1. 利用load profile进行施压
  2. 边界值分析
  3. Process cycle test

测试步骤

  1. 给系统施加压力，压力不会超过性能边界值
  2. 维持压力一段时间，确保系统在压力下的错误率在可接受范围内
  3. 给系统施加更多的压力，使系统超过性能边界值，我们期望系统会自动scale up
  4. 系统scale up之后，我们期望response time会下降，但是不会触发scale down
  5. 维持压力一段时间，确保系统在scale up后一段时间内的的错误率在可接受范围内
  6. 降低系统的压力到性能scale up前的状态，确保系统可以自动scale down
  7. 系统scale down之后，我们期望response time会有上升但不会重新引起scale up

期望结果

TaaS

在TaaS出现前，性能测试一般都是在本地的测试环境中通过几台电脑对被测环境加压进行的，在这种模式下，测试环境的搭建和维护不仅要耗费大量资源，而且测试环境由于并不能完全模拟真实生产环境以至于测试结果存在一定的局限性。而云计算出现后，一些基于云端性能测试服务（CLT – Cloud Load Test）相比于本地的性能测试展现出了很多优点：

  1. CLT更简单，大多数情况下, 云端的资源更好管理，环境更容易搭建，用户只需设置简单的一些参数或者提供简单的测试脚本就能在云端执行测试。同时，很多CLT工具允许用户把不同性能测试工具的自动化脚本如Gatling，Jmeter，Selenium直接移植使用，为用户节省了二次开发时间。
  2. CLT工具可以提供更多的load generator，压力测试中用户通过在云端启动load generator对被测系统进行施压，因为在云端可以调用资源体量巨大，因此用户可以完全模拟生产环境中可能面对的超大压力。
  3. 测试成本低。CLT提供的测试服务是按照云端机器的运行时间进行收费。在没有测试需求时，用户并不用为机器的运行和维护买单，大大降低了用户实施性能测试的成本，为一些没有大型长期性能测试需求的企业节省了许多开支。
  4. CLT提供的测试硬件资源大多分布在全球不同区域，在进行性能测试时，用户可以根据可能的实际情况选择不同区域的机器定制化的为被测系统加压，所得的测试结果由于更接近真实的网络情况而更加准确。

目前市面上可以提供CLT的的产品很多，他们都有着自己不同的优点，比如SOASTA提供全面的云测试服务，功能强大，但收费较高，又比如最新技术雷达上新增的Flood IO也是一款简单好用的CLT服务，其优点在于允许客户把已有的Selenium，Gatling或者Jmeter的测试脚本直接在其平台上使用，为客户节省了许多迁移成本。现实中，大家可以通过自己项目的具体需求选择适合自己的云测试平台。

更多精彩洞见，请关注微信公众号：思特沃克

Share

Offshore敏捷交付团队QA生存指南

郑达夫 评论

序

跨地域性的offshore敏捷交付一直以来都是一个充满挑战的工作，对于需要与各种角色进行交互的QA而言更是如此。我在2016年初进ThoughtWorks时就经历了这样一个项目。此间个人也经历了从忐忑不安到得心应手。现在此离岸项目已经交付完成，我也想总结一下这一年来的项目生存实践。

项目背景

客户：澳洲大型电信公司Digital部门,我所在的电商产品部门下有3个交付团队和1个Devops[1]团队，每个交付团队有3-4个开发，1-2个QA，1个IM[2]，BA[3]则是按项目分配且全部都在Onshore。

系统与架构：基于AWS部署的Oracle的内容管理和电子商务系统，系统较重，且需要通过中间件从核心系统拿到数据。

QA职责

  1. 参加需求评审和技术评审会议，与BA讨论AC[4]，与开发讨论实现方案。根据需求和技术方案制定测试策略。
  2. 准备测试数据，测试数据大多来自于第三方系统，可以自己手动创建，有时需要其他团队帮助。
  3. 对已开发完功能进行测试，即测试故事卡。
  4. 负责新功能上线。QA需组织系统发布启动会议，完成集成测试和回归测试，在上线后对系统进行主要功能的回归测试。

项目困难

Offshore的项目中存在的主要困难来源于三个方面：时间不同，空间不同，文化不同。

  1. 澳洲时间比国内早三个小时，算上各自午饭时间，与onshore团队的工作重合时间可能不到5小时，一旦过了澳洲的下班时间，有问题需要找onshore的团队就会很困难。
  2. 澳洲距离远，国内团队和澳洲团队只能通过视频会议、邮件、即时聊天软件等方式进行远程沟通交流。
  3. 基于国内的网络环境，在与澳洲团队工作的时候，网速、VPN都会对沟通和工作效率产生影响。
  4. 澳洲距离国内坐飞机大概要13个小时，较长的路途决定了不会有很多机会和预算让两地团队频繁的出差、相互交流。
  5. 同时由于不在一个地方工作，几乎没有比如团建活动，茶歇等能够促进团队成员互相了解、建立良好团队关系的机会，这对于敏捷团队的建立是非常不利的。
  6. 澳洲是移民国家，虽然相对于欧洲国家人们的思想更开放，更能接受不同的文化，但中西方文化的截然不同还是会在某些场合带来一些意想不到的问题。而且如果彼此双方对对方的文化完全不了解，交流起来也会缺乏共同话题，难以建立同属感。

生存指南

为了减少时差带来的工作时间重合度不高的问题，国内团队相应会提前上班时间，并且在非工作时间内也会注意澳洲团队是不是有紧急的问题需要解决，时刻保证澳洲团队能通过电话顺利联系上国内团队。

做好每天的工作计划，在有限的共同工作时间里，把需要澳洲团队帮忙解决的问题设置较高的优先级，然后预计会有阻碍或者依赖的工作点要优先提出来。而作为QA，我们应该合理利用共同的工作时间，把需要与onshore团队沟通的任务比如需求澄清, 故事启动，客户展示等工作优先完成，把可以独立完成的测卡工作优先级相对降低，这样就不会因为某些流程必须要两岸团队共同完成而阻碍。

网络环境的不同有时候会给测试工作会带来很多不便。为了最低程度降低网络环境带来的影响，首先我们要依赖于Techops团队搭建稳定可靠的VPN，再者作为QA在测试过程中如果遇到一些奇怪的问题，在分析问题原因的过程中应该考虑到网络的因素，必要的时候可以请onshore团队帮忙测试排除网络因素。

在解决两地团队相隔较远的问题上，我们制定了定期派遣项目人员去客户现场进行知识传递的计划。对于时长6周的现场出差，出差人员一定要提前做好计划，定时追踪知识传递的进度，在客户现场要尽可能的多了解项目的有关知识并和onshore团队建立良好的关系。作为QA，首先，一定要找到客户的质量经理一起安排好自己六周的知识传递计划并定时追踪进度。然后在客户现场需要找到一个onshore 的QA和他一起结对工作，在这个过程中你会很快的了解到一切关于QA的流程和工具，包括测试环境、测试数据、CI工具、Bug管理工具等等。同时，QA也需要找到一个对系统十分了解的开发工程师给你仔细讲解系统的架构和技术实现。最后，在知识传递过程中一定要学会记笔记，快速准确的把有用的信息及时分享给自己off shore团队，以个人带动团队共同成长。出差在客户现场，还有一点很重要的就是要利用面对面的机会与onshore团队建立良好的同事关系。茶歇和下班后的聚会都是很好了解对方的文化背景，兴趣爱好，建立团队认同感的机会。

虽然敏捷团队提倡“工作的软件高于详尽的文档”， 但是对于分隔两地的团队来说，有时候详尽的文档恰恰是提高沟通效率的必要手段。比如一个团队共享的wiki就能够帮助团队在不知道从谁获取知识时高效的查找到所需信息。作为QA，在离岸交付团队中，我们更需要注重测试的文档化。比如我们不仅应该详尽的对每张故事卡的测试案例和测试步骤文档化，而且还要记录测试环境的配置和测试工具使用说明，甚至有时为了使团队知道Bug如何重现，我们需要把重现步骤用截图的方式记录在Bug里。总之，在离岸交付中我们提倡并强调把自己所掌握的知识第一时间文档化分享给大家。

最后，为了提高团队的融洽度，获得彼此的信任。团队成员不仅要在技术等硬技能上体现出专业性，还要提高自己的软技能，学会怎样与有着不同语言，信仰，文化的同事进行无障碍沟通。这就需要首先努力提高自己的英语水平，适应不同的口音，再者要了解对方国家文化习俗，如果能在节日时送上祝福，或者闲时聊聊对方的文化，都能使对方感到亲切，获得认同感。同时，我们也要适时输出自己的文化，创造一个多文化的融洽的工作环境。

跋

短短一年多的离岸交付因为限制很多，无法像在其他项目上一样积累足够多的经验，但在这个过程中，我在不断的突破限制、找到最佳实践的过程中也获得了个人能力的提升。现在我把这些经验总结出来，希望能帮助到现在或以后有相同工作场景的小伙伴们。

注：

  1. Devops: Development&Operations, 负责环境搭建，流水线配置，部署等工作。
  2. IM：Iteration Manager, 敏捷团队中负责管理迭代工作
  3. BA：Business Analyst, 业务分析师
  4. AC： Acceptance Critiaria, 故事或需求的验收标准。

更多精彩洞见，请关注微信公众号：思特沃克

Share