如何评价一个项目的过程质量？是从代码的层面，还是从发现的 BUG 来统计，或者是其他信息。如何有效记录并分析每个测试阶段（冒烟测试、系统测试等等）的问题以及反馈提测质量？

今次的目标是：打通整个软件生命周期

分层自动化的目标

实现代码、服务、界面分层自动化的整体架构目标，满足金字塔式一体化分层管理

20180730215739.png

20180730^注：图中，待实现的 sonar, gatest均已实现，且mock service 统一为go mock

优势：

各层测试目标清晰，资源统一管理；
代码层级持续日构建，支持 merge 后自动构建，作为冒烟测试检查手段；
可以集成新测试工具和测试框架，展现测试报告，提升管理效率，利于各层各节点质量数据统计分析；
统一自动化测试入口，便于测试、开发自测统一管理（基础建设完成后，后期考虑）。

基于现状，有必要提高开发自测参与度，从【单元测试】和【接口测试】层面都需要更自动化，给到测试更多的质量反馈数据。接着，渐进式的改进测试流程的状态，最终完成实现平台化，完成测试平台入口的统一

测试散点态 ----> 测试流程化 ----> 测试平台化

20180730220001.png

分层测试设计思想：

测试基础服务

主要是指：持续构建服务（Jenkins）、静态代码分析服务（Sonar）、配置管理服务（Git）、统一构建工具管理（Maven），可以使用 Docker 来构建。

20180730^注：目前CI 采用 gitlab Runner ，也未使用 Maven

测试基石层

主要是指：Unit Test

在该层，通过自动化单元测试的持续构建，可以作为测试阶段的第一道关卡，完成冒烟测试工作。流程要以下步骤实现：

建立提测项目的单元测试环节，在 Gitlab CI上完成构建；
构建项目，进行代码编译，执行不通过，打回，要求开发人员修复直到构建成功为止，并且记录打回节点和原因，作为提测质量的依据；
单元测试，单元测试失败、覆盖度不符合标准，打回，要求开发人员修复直到单测成功为止，并且记录打回节点和原因，作为提测质量的依据；只有通过第一轮 UnitTest 冒烟测试之后，才能进入下一个环节；
静态代码分析，对源代码进行度量分析，比如代码风格、单元测试覆盖率、圈复杂度、耦合度等，如不通过，记录打回节点和原因，作为提测质量的依据，自动化审核工具运行通过后，才有获得提测准入资格。

`流程上 —— 增加 Sonar 静态代码分析测试`

目前第1-3步，主要依赖开发自主完成，但是目前缺少必要的工具，无法做到有效监控，所以，暂时先从简单的第4点入手。

Sonar 具有代码静态检查、单元测试覆盖率分析、代码复杂度分析、jar依赖关系分析等多种功能；提供了对 IDE 的支持，可以在 Eclipse 和 IntelliJ IDEA 这些工具里联机查看结果；同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar。

Go 可用 go report ，sonar 在18年5月份开始支持go

测试中坚层 Service & Integration Test

主要是API测试，缓存服务，日志服务等。API 测试包括 HTTP、CBin 协议等。

测试用例完全掌握在测试人员手里，开发修复 BUG 之后，只能等待测试人员验证，交付过程效率低。正确的姿势是开发、测试协同工作，开发人员修复 BUG 后即可通过平台执行用例，快速回归，实现 0 等待，驱动过程质量的提升。

因此，必要的API 冒烟测试显示尤为重要，开发自助执行测试提供的冒烟测试用例。如果此环节不通过，会记录节点并且发送邮件通知开发人员，开发人员根据测试报告，排查存在问题的API，进行修复之后，再次提测，直到通过为止。

测试技术实现上

针对 HTTP API，如支付网关，支付 PHP API，采用 SoapUI 工具生成用例，以 XML 方式存储，进行测试。
针对 CBin 协议等，例如账号网关，采用新的 PHPUnit 框架下，引入旧协议 lib 包进行测试。
针对 gRPC 服务，采用开发功能代码与 go test 结合的方式进行测试。—— 待优化

`流程上 —— 增加冒烟测试`

重大变化的点：流程上,测试人员需要在开发完成任务前给到 API 测试用例

引入冒烟测试的目的：

提升QA概念，纳入质量监控
提高准入标准
减少时间损耗
快速响应
理清接口数量，服务数量，版本个数，应用场景，冒烟用例数

流程实施分两个阶段，分步前进：

第一阶段，测试点覆盖，Xmind 给出功能点，开发进行冒烟测试。

人工统计节点数据。可能存在的痛点是，提测，冒烟，打；再提测，再冒烟，再打回，而在上线时间紧凑的情况下，这样的流程会增加开发的处理时间，压缩测试时间。

第二阶段，系统评估质量和执行用例。

设定由开发、测试都认可的预设条件作为冒烟测试阶段，通过之后则相当于具备了正式提测条件。如未通过，则打回，同时记录打回的节点，作为提测质量依据。开发自助通过冒烟测试，完成冒烟阶段的任务，可双向节省时间，更加关注业务实现。

但是，此阶段测试给出的测试功能点，旧接口有现成的测试用例可以直接部署，新接口需要Mock Service 才能实现。因此，我们的流程上还需要将 Mock Service 纳入考虑范围。

方案传送带：http://gitlab.xxx.cn/testing-group/base/issues/20

`新增 Mock Server`

Mock Server 在们的支付网关测试和新接口开发过程中，显示尤为重要，最突出的一个贡献应该是可以解决接口只在文档中定义，而实操中界限不清，逻辑含糊模糊不清，人工沟通出现纰漏不断的问题。如，常见的返回格式，编码不统一，类型出错，多版本逻辑，返回码定义模糊。当存在这样一个Mock系统时，我们随时可以告知任何人，按照我们的要求来接入。

方案传送带：http://gitlab.xxx.cn/testing-group/base/issues/18

`新增统一 API 管理平台`

方案传送带：http://gitlab.xxx.cn/testing-group/base/issues/18#note_35670

测试表现层

UI 测试的投入需要非常慎重。如果页面元素频繁变动，一般不建议马上开展UI自动化测试，但可以转变测试思想：

业务主要入口和页面样式兼容性可以与业务逻辑分离，只做页面版本检查。利用生成的快照，在上下两个版本之间进行对比，如此，只需要在大版本需要切换时，做基准数据准备即可。日常兼容性校验均可由检测快照来完成自动化 check 工作。技术方案采用 Selenium。
长期（6 个月以上）稳定的功能，并且页面元素有清晰的定义，可以投入核心业务的UI自动化测试。区分主要业务逻辑和分支结构，进行常规元素检查。可使用关键字驱动，也可采用行为驱动 BDD 的方式。目前我们采用Cucumber。

方案传送带：http://gitlab.xxx.cn/testing-group/base/issues/19

结尾

各层的测试报告单独给出，每层测试报告中汇总测试的功能模块，测试用例，通过率等。

每个点的数据统计。----[数据服务需要修改的内容]

分层测试架构