项目质量报告，如图11：
1） 项目基本信息
2） 自动化测试概览，与应用质量基线数据做比较
3） 环境构建结果信息
4） 各应用对应的自动化测试结果信息以及与历史运行记录的比较信息
应用质量报告，如图12：
1) 项目基本信息
2) 单项目各应用评分
3) 应用通过率、覆盖率、PMD问题数、FindBugs问题数、应用评分等趋势信息
4) 各应用对应的自动化测试结果信息
报告发送，如图13：
1) 自动生成邮件标题、描述、关联人员等信息
2) 支持修改自动生成的相关信息，然后提交发送
4. 应用质量趋势，如图14：
1) 应用基本信息
2) trunk和branch级别的应用质量趋势
5. 应用评分
综上所述，我们可以拿到应用级的持续集成的各项指标数据，结合SQPG组织的评分方式，提供应用维度的代码评分（如图15），便于管理者或测试负责人进行质量决策分析。
6. 全站回归
本平台也提供发布级、产品域级、全站级等分层回归功能，这里提供一份业务团队级的回归报告（主要包括用例通过率、失败用例原因分布、自动化测试明细等），供大家有个初步的了解，如图16，至于这块的业务，后续我们会逐步分享出来。
六．方案总结
实践出真知，多一些倾听、多一些尝试、多一些沟通、多一些思考，多走进业务，多寻求业务的痛点，没有业务支撑的工具平台也许只是空中楼阁。
工具团队的研发有其自身的特点，在工具平台内部，我们坚守人人都是产品经理、人人都是开发、人人都是测试的理念，实行专人专职专事，坚持基础技术体系（如基础组件、前端资源、通用模块）建设和业务开发并驾齐驱。
此外，非常感谢我的主管、我的同事、我的HR的指点以及各研发团队同学的建议和协助，AQC持续集成平台才会前进如此顺利。
缺陷预防胜于修复，质量从源头（源码）抓起，打造本持续集成平台，也是期望本持续集成平台能够助力研发人员，通过质量数据驱动，尽早发现问题，尽早修复问题。此外，有几点启发，补充如下：
专职工具团队，不同的团队也有过尝试自己搭建持续平台，在扩展性、可集成性方面均有较大的瓶颈，由专职的工具团队打造变的尤为重要，可以做到专精深的同时，也避免了业务团队重复造轮子的可能。
业务高度抽象，在这里，想和大家强调的是，一定要透过现象看本质，对业务做高度抽象，以最大限度降低平台建设和用户使用的成本。例如，在自动化建设过程中，对于执行调度，在蛮多的研发团队，单元测试和接口测试用一套执行调度体系（如Jenkins），而WebUI自动化测试用另外一套管控体系（自主研发），使用成本和维护成本均偏高，需要了解和维护两套执行调度体系。
走进研发团队，在持续集成平台建设过程中，除了要理解公司的研发流程和质量体系，还要多和研发团队互动以寻求业务的痛点，如果可能的话，可以找一些研发团队做一定的试点，实践出真知，不能闭门造车。
作者简介：王超，花名于龙，支付宝-高级技术专家；李国栋，花名富曲，支付宝-测试开发专家
本文章节选自 《程序员》杂志3月A
