转载自：友赞技术团队主页
转载原因：学习、借鉴先进生产力
一、基本概况

       有赞，旨在为商户提供强大的微商城和完整的移动零售解决方案，是一个移动零售服务商，正在新零售的潮流中激流勇进、开疆拓土，用产品技术撬动巨大的市场。有赞拥有世界级的 SaaS 电商解决方案，每天处理几百万订单、几亿条消息，且量级仍在不断攀升中，有赞还开放了有赞云，连接数十万开发者，大大提升了SaaS 对商家产生的价值。
       有赞测试团队三分之二以上成员来自于阿里、腾讯、网易等公司，他/她们分别在电商事业部、零售事业部、餐饮事业部、支付事业部及共享技术事业部等部门贡献自己的力量。

二、我们的日常工作

       测试团队负责相关项目具体测试工作、自动化建设、合并发布流程管控、设计开发线上业务级别可用性监控、同时在研发提升测试效率的工具。
       有赞测试职位主要负责度量产品质量及研发测试效率工具。从度量产品质量角度讲，有赞测试人员需要具备白盒测试能力、CodeReview能力、业务功能测试，从而实现核心系统可持续自动化测试，保障系统在频繁发布情况依然是稳定的、高可用的。对于效率工具研发，测试同学完成相关第三方mock(例如短信、支付)、应用级健康检查、线上业务级可用性监控、持续集成工具、UI自动化、测试工作台、性能测试平台、全链路性能压测等。

2.1 具体项目测试

       有赞的项目分为标准需求项目、技术重构项目、优化项目、缺陷修复项目。有限的测试资源通过不同策略支持着绝大部分业务产品的测试工作。
       第一、对于标准需求项目或者跨多个业务的项目，一定会有测试投入，并且会有一位PTM来协调测试工作。PTM需要确保所有需求点都拆分到各个业务测试同学手里，跟踪相关测试同学按时提交标准测试方案。当测试方案汇总后，PTM需要评估后续测试过程中，测试人员如何投入。即哪些业务的功能测试PTM可顺带执行掉，哪些确实需要对应业务线测试同学来完成，以避免一个项目投入过多测试同学。
       第二、技术重构改造项目，这种一般是单应用或者极少应用改造，但不改变业务使用规则。这类项目测试同学只要设计测试方案并完成测试用例落地即可，用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要，测试会在上线前做质量check。
        第三、对于小型项目，如果开发的自测场景与测试同学的测试场景基本一致，那开发自行搞定即可；或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的，测试同学把差异点向开发同学描述清楚即可。
       有赞测试同学拿到具体需求后，按照有赞测试对需求分析和测试方案统一要求，完成相关工作。

2.1.1 需求分析

       测试同学在参加需求评审或者测试方案设计之前，需要认证阅读需求文档，从获取相关的信息：
       第一、这个需求是给哪些角色使用的。例如，高级管理员、普通管理员、库管人员、核销员；还是买家，是大众买家还是特定买家。
       第二、不同角色，在什么环境下使用这个些功能。例如PC后台、店铺收银台、手机端、还是有赞的移动终端。
       第三、整个项目是否存在对象的生命周期扭转，例如订单对象、店铺等，它们在什么条件下会发生什么样的扭转。即明确状态发生变更的条件规则，确保对象生命周期是有终态的。
       第四、明确每个业务点的人机交互过程及规则，业务过程是否连贯明确；即如何使用这个需求。
       需求分析后，需要输出对象生命周期图、业务时序图、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通，直到问题得到明确答复。

2.1.2 测试方案设计

        一、功能测试设计的完整性，取决于测试人员对需求分析的深入程度及其经验。为了弥补测试同学经验不足，我们梳理了《功能测试.页面测试.基础篇》《有赞云.测试参考规范》《有赞云.carmen接口自动化参考规范》等供平时设计参考。同时，不定期组织业务分享，提高测试人员的业务全局观及跨业务耦合与风险评估能力。
       二、提供《有赞.异常测试基本场景》指导测试人员如何考虑异常。包括Redis缓存、消息、大数据定时任务处理、多系统协同等。
       三、有赞有安全测试专员及虚拟小组，提供安全测试方面的指导和工具；针对SQL注入、XSS、越权、业务规则安全、文件上传&下载、重定向定制常规安全测试用例，指导日常测试。
       四、其它的专项测试，根据实际情况定义指导案例及分享。

2.2 自动化开发

       前面提到有赞测试开发的职责，自动化是必修课。我们从接口层、端对端的数据层、端对端的UI层来做自动化建设。有赞前端应用交互与后端业务是分离的，数据通过.json请求获取或者提交数据。UI自动化依赖于前端元素的稳定性且Selenium测试具有的一定不稳定性，我们构建了在不打开浏览器的情况，对前端请求数据进行覆盖的端对端数据层自动化。各层自动化比例如下。

       一、接口自动化主要包含对Rest、Dubbo、Nova提供的业务接口进行覆盖。在youzan-boostrap框架上设计了接口自动化框架。根据不同业务线构建独立自动化应用。有赞接口自动化用例总量已经达到3000+，其中商品中心+库存中心+物流中心的用例总数就达到500+。

       二、端对端数据层，基于Spring Aop技术封装有赞帐号登录与店铺切换的前端测试插件yago。测试人员可以更关注自己的业务自动化开发。

       三、UI自动化框架是基于Selenide和Selenium框架进行的二次封装。框架支持Web和Wap页面的元素操作，其中Selenide用来支持Web页面，Selenium用来支持Wap页面。以下从三方面对框架作简要阐述。        框架结构。driver层二次封装Selenide和Selenium的接口，是操作页面元素的核心；pageObject层用于封装业务流程中需要使用的每一个页面元素，是业务流程实现的核心；dataprovider层自定义测试数据，实现测试数据的隔离；service层用于定义各模块之间的公共业务流程，实现模块间业务的调用。        用例组织。从账户登入到一个业务流程结束作为一个完整的UI自动化用例。用例由每一个pageObject接口的调用来实现业务流程。所有测试用例使用testng进行管理。
       报告展示。采用reportng收集测试数据再结合jenkins插件呈现测试报告。

2.3 线上监控开发

       随着有赞系统网络拓扑与业务场景越来越复杂，发布频率越来越高，同时系统是部署在公有云上；节假日、及频繁的发布后，有赞自己如何知道当前系统中核心业务场景的健康情况。在上半年我们开始设计建设「业务级可用性监控系统」，从商家后台业务管理，到买家端的交易前、交易中，交易后等核心业务场景执行用户真实操作，监控线上业务级可用性。
       现在，有赞发布系统完成应用发布后，调用「线上监控系统」的Rest接口发起业务级可用性检查；监控系统以多线程方式把各业务的监控点拉起，每个业务的多个检查点，也以多线程方式来运行。若发现业务失败，通过有赞告警系统向业务的开发&测试发送告警。
       在非发布时间，该系统以10分钟一次的频率监控线上业务可用性。

       Rest请求返回对象如下。对定时任务，如果检查失败，将AppResult对象转成告警对象发送给业务开发及测试人员。

2.4 合并发布运作

       今年，有赞开发小伙伴超过600+,主站每天需要发布十几至二十几个代码分支。有赞开始实行公交车发布模式，将需要发布的分支集中后由测试管控发布。统一部分，一来、测试同学能够验证一次核心场景，确保上线质量；二来，可以节省测试投入成本。我们的每次发布，需要经过前面提到的接口自动化、Ui自动化验证，及预发环境核心场景验证。

2.5 工具建设

2.5.1 有赞QA平台

       有赞QA平台提供了「构造测试数据」「项目质量报告」「项目日报」「环境健康检查」能力。由Dmm_platform提供统一工具开发标准，然后测试同学完成相关工具开发。

       构造测试数据，通过直接写DB、或调用各业务系统接口来构造测试数据。例如新建帐号、店铺、不同类型的商品、交易订单等；
       测试报告，包含项目质量报告及项目日报。用于跟踪项目过程质量、进展、风险及最终项目上线的质量。

       环境健康检查，通过检查Etcd(有赞的dubbo&Nova注册中心)服务，判别各应用本该提供的Rest、Dubbo、Nova服务是否正常。以了解测试和性能环境，全站应用的运行情况，解决过去测试遇到环境问题，但是不知道那个应用有问题的痛点。

2.5.2 有赞mock服务

       作为互联网应用，依赖部分外部系统实属正常，例如支付、短信、物流等第三方。为了实现可测性、稳定性、高效性和节约成本而构建了Mock服务。例如测试环境订单支付，真正去付钱，不现实且成本太高；测试环境短信若真的通过通讯运营商发送到手机上，也需要成本。

2.5.3 有赞安全扫描工具

       SecLab单机工具为有赞安全在线扫描系统单机版工具，工具基于Python2.7及Mac OS平台。主要功能为实现XSS、SQL注入、安全配置检查错误等问题的工具化扫描，提供与《通用基础安全测试用例》相配套的安全测试工具能力，降低在此类安全问题测试上的人力与时间投入。

2.5.4 有赞性能测试平台

       性能测试平台简化了性能测试的步骤，提高了测试的效率，使得普通测试工程师也能方便地进行性能测试。平台后端引擎采用普遍使用的Jmeter，并能实时收集、展示性能数据（响应时间、TPS、并发用户数等），自动采集并实时展示监控数据（如Linux系统的CPU使用率、系统负载等，JVM GC的eden、S0、S1、old区的使用率，垃圾回收的次数、时间等）。

2.5.5 建设中的工具

2.5.5.1 Carmen测试平台

       该平台开始一种新的尝试，即实现测试用例管理，又能够将用例自动化与用例绑定在一起；重点解决开发也可以帮忙维护自动化用例，并提供精准用例验证开发代码质量。第一版提供用例维护、单用例测试，批量用例测试。该项目后期将整合到测试工作台中。
       用例维护，可以录制用例的基本信息，运行的环境、用例执行结果校验。
       批量用例测试，开发或者测试人员，可以根据项目的需求，选择需要的测试用例群，并创建一个用例任务。过后，再回头查看任务的运行情况。
        用例测试执行，按照Carmen的调用规则，组装测试执行。这里重点解决用例依赖、测试结果检查。测试结果检查分三期：一期、根据静态检查数据，检查返回数据；二期、采用Goovy等方式支持能够到数据库核查。三期，接入Diffy平台，实现测试分支与master环境测试结果的去燥比对。

2.5.5.2 持续集成平台

       持续集成平台一期主要实现可流程化配置业务应用发布顺序并与测试自动化相结合的工作流，同时提供自动运行及外部触发的运行模式。
       随着有赞系统的SOA服务化进程，系统依赖越来越复杂，根据事先定义的系统依赖关系，计算合理的应用发布顺序；并最终与Sona、自动化项目等相结合；实现发布、单侧覆盖率统计存储、测试覆盖率统计存储等。
       持续集成同时实现与Gitlib对接，根据应用代码commit情况，自动或定时更行应用代码；同时提供Restfull接口，供外部触发工作流或查询相关数据。

2.5.5.3 测试工作台

       该工作台的目标是把测试小伙伴平时奋斗的成果展示出来，即可以回顾，也可以预警。例如某个产品线，近一个月自动化用例及相关应用的覆盖率变化曲线如何；测试同学参与了哪些项目，项目的提测质量、测试质量、相关报告及风险点。第一期的 主要目标，从应用到项目到人员的维度，及从项目到应用到人员的维度查看当前的团队工作情况。

#有赞.测试团队介绍(二)之团队建设 之前，我们在 《有赞.测试团队介绍(一)》介绍了有赞测试团队日常工作情况。本文来讲讲从我入职有赞后看到的整个测试团队发展与变化。
       我16年加入有赞，当时测试团队只有17位测试同学，一年半以后的今天，测试团队已经有50+同学了。大部分同学已在互联网行业深耕多年，当然也有从传统行业转型过来的。我从事通讯运营商产品测试6年。同学们的能力各有所长，包括在白盒测试、安全测试、性能测试、工具研发……。测试同学的职责也从之前的业务测试，向度量产品质量与研发测试效率工具转变。
       下面，我们从小伙伴能力培养与融入团队两方面展开介绍。
##一、小伙伴能力培养

       这里我们主要从新人到老人，从初级到高级的过程介绍。

1.1 新人入职

       在有幸加入有赞的第一天，办理完入职手续后续后，HR天使会领着小伙伴到各团队办公地点参观并作些必要的介绍，以便于大家了解公司的情况。之后，有伴会去把新同学带回来。
       有伴，顾名思义，就是新伙伴的Buddy，由团队TL指定，在新伙伴入职时介绍给对方；直至转正，需要持续的关注新同学和提供帮助，陪伴融入，共同成长；下面介绍测试团队关于新人融入的培养。
       新人可以拿到《有赞环境知多少.key》文档，介绍如下内容。

• 环境，介绍有赞现有测试工作环境，包括开发环境，测试环境、预发及线上环境。
• 基础应用，支持整个系统运行的基础服务，包括ZK、yz-haunt、Nginx等；介绍这些基础应用是如何配置及如何查看日志等工作中需要涉及的内容。
• 应用依赖关系，有赞系统现在的基本情况、系统间依赖关系，现在有赞有那些类型的系统。
• 卡门测试，介绍通过有赞卡门测试业务时，该怎么入手。
• 系统间调用，介绍各类型系统间是如何调用的。例如，主站系统如何调用其他Restfull Soa服务，如何调用Dubbo\Nova Soa服务；Php服务化项目如何调用其他项目。这些调用依赖是如何配置的。

       同时文档《2017年4月12日XXXXX分析思路.pdf》会给出基于上面的介绍内容，从实战角度介绍在有赞工作中，如何排查问题。

       为期3个月的试用期里，有伴还会在很多方面手把手指导新同学如何快速适应有赞的日常工作。当然包括如何使用Mac Book电脑。
       公司层面会组织一个礼拜脱产入职培训，介绍公司发展历程、公司文化、如何开店等。还有脱产两天到有赞技术大学学习以下内容。

1.2 业务梳理与分享

       我们坚信测试方案设计的深度如何及项目风险评估能力高低等在一定程度上，取决于测试同学对业务熟悉程度及对周边业务的了解程度。所以，我们要求测试同学阅读自己负责的业务线代码，并整理成文档，文档需要从宏观到微观描述业务。总体上包含如下内容

• 该业务的全景概况，描述它有哪些业务，每个业务的使用角色都有哪些。
• 该业务的总体数据模型。
• 该业务里存在哪些业务对象，例如交易订单，物流单、退款单等。
• 该业务里的业务对象是否存在生命周期，生命周期如何扭转。例如交易单，它会有待支付、已支付、已发货、已关闭等状态。
• 对于每个业务点的描述，除了文字外，还应该有流程图或者时序图，能够直观的描述业务。
  

       业务文档整理好了，小伙伴可以把业务分享约起来了。用最通俗的语言，让不知道该业务的同学，了解该业务，以便于他们在工作中做参考。例如他手里有个项目，他可以评估，他的项目对你是否有影响。
       经历这个过程，小伙伴的文档能力与演讲能力都会在一定程度上得到提升。

1.3 测试能力培训

       随着有赞系统的复杂度越来越高，系统用户越来越多。我们对系统的要求也随之提高，那么，测试能力也需要不断提升。从一般的业务测试、再到专项测试。

1.3.1 测试基本功-业务测试能力

       业务测试能力的培养，我们准备了从测试小白到测试进阶分三个阶段的能力培养教程。

       第一阶段，测试入门级培训,从最简单的，以实例介绍出发，讲解如何测试。

       以页面基本元素为例，介绍了常见的Html标签如何测试。

       对于文件上传测试，除了测试文件是否能够正常上传，上传后验证外；测试时，还需要再考虑下如下内容。

       第二阶段，中级能力培训，主要以项目实战为例，介绍一个项目的测试方案设计该如何思考。

       这里以具体中型项目为例介绍项目如何拆解，该从哪些方面思考测试关键词，每个业务点如何思考和设计。例如，什么时候需要考虑幂等，什么时候需要考虑资损防控。

       这里就需要知道对于有赞系统，哪些是用户资产，例如，钱、用户资源、可用消息资源。例如微信公众号每个月只能给用户推送3次消息，那这3次就不能随便浪费，不能因为系统设计缺陷导致浪费，否则就是资损。

       第三阶段，大型项目测试方案如何设计、项目管控与管理进行介绍

       该阶段，部分比较抽象，偏向理论，需要有一定的测试工作经历。这里就展开介绍。

1.3.2 测试专项-安全测试

       有赞今年成立安全测试小组，负责公司安全意识培训与安全检查。同时，我们制定日常项目安全测试培训及实战案例，并搭建环境给小伙伴亲身实战安全测试。

       日常项目测试培训大纲内容。这里会详细介绍每个测试点的解释、如何测试、如何避免等。

 

1.3.2 测试专项-性能测试

       性能测试已成为我们日常工作的一部分。如果你是性能测试的老司机，入职有赞后，你可以成为专项测试小组一员，给其他小伙伴提供帮助。如果你在性能测试刚入门，你可以到专项测试小组里寻求指导和帮助，学习如何做性能测试和性能测试分析。这个后面我们推出性能测试入门博客来专门介绍。

1.4 技术提升计划

       在《有赞.测试团队介绍(一)》提到，我们在做一些效率提升工具。这些工具建设，由资深测试开发工程师设计，带领其他测试开发工程师实施完成。前端使用AdminLte或者Vue框架，后端以Spring、Spring boot、Goovy等来开发。这里就会遇到之前没有学过的，那就需要学习。
       学习就会学习计划和作业。我们给不同同学指定不同学习任务，然后每天发学习日报。每周做一次学习分享。学习了2、3周后，开始投入到项目。