测试管理有赞.测试团队介绍 (一) 之日常工作

吕国用 · 2017年09月22日 · 最后由心意已决回复于 2020年11月25日 · 6333 次阅读

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

一、基本概况

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

有赞.共享技术测试团队 +HR 天使团

二、我们的日常工作

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 插件呈现测试报告。

有赞.UI 自动化标准接口

2.3 线上监控开发

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

有赞.业务级可用性监控模型

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

有赞.业务级可用性监控接口输出对象及告警

2.4 合并发布运作

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

有赞.公交车系统简图

有赞.公交车发布流程步骤

2.5 工具建设

2.5.1 有赞 QA 平台

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

有赞.QA 平台

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

有赞.项目日报

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

有赞.环境健康检查

2.5.2 有赞 mock 服务

作为互联网应用，依赖部分外部系统实属正常，例如支付、短信、物流等第三方。为了实现可测性、稳定性、高效性和节约成本而构建了 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 测试工作台

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

有赞.测试工作台雏形