如何评价一个项目的过程质量？是从代码的层面，还是从发现的 BUG 来统计，或者是其他信息。如何有效记录并分析每个测试阶段（冒烟测试、系统测试等等）的问题以及反馈提测质量？
今次的目标是：打通整个软件生命周期
分层自动化的目标
实现代码、服务、界面分层自动化的整体架构目标，满足金字塔式一体化分层管理
20180730注：图中，待实现的 sonar, gatest均已实现，且mock service 统一为go mock
优势：
- 各层测试目标清晰，资源统一管理；
- 代码层级持续
日构建，支持 merge 后自动构建，作为冒烟测试检查手段； - 可以集成新测试工具和测试框架，展现测试报告，提升管理效率，利于
各层各节点质量数据统计分析； - 统一自动化测试入口，便于测试、开发自测统一管理（基础建设完成后，后期考虑）。
基于现状，有必要提高开发自测参与度，从【单元测试】和【接口测试】层面都需要更自动化，给到测试更多的质量反馈数据。接着，渐进式的改进测试流程的状态，最终完成实现平台化，完成测试平台入口的统一
测试散点态 ----> 测试流程化 ----> 测试平台化
分层测试设计思想：
测试基础服务
主要是指：持续构建服务（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
结尾
各层的测试报告单独给出，每层测试报告中汇总测试的功能模块，测试用例，通过率等。
每个点的数据统计。----[数据服务需要修改的内容]
