产品质量很难孤立的去看，不管是自动化测试团队还是业务测试团队，最终的目的都是为了产品质量服务，从而打造很酷很好的产品来赋能客户。但是现实的情况很多时候并不是这样的，往往是测试开发团队会开发很多的工具，也会做很多的自动化测试，业务团队的测试人员并没有感到轻松，随着产品的体系越来越大的时候，这种压力会递增式的增加，在这个过程中，就得需要重新来思考自动化测试的价值和质量内建这部分。
回归到具体的测试本质工作，其实可以总结为测试的工作就是质量管理以及测试效率的提升。质量管理是一个比较大的话题，它包含了组织建设以及流程改进，质量度量以及质量标准的推进等等。而测试效率，就是通过测试技术的手段来提升测试效率。依据自动化金字塔模型，具体模型如下：
在模型中，最底层的是单元测试，也就是UnitTest，中间是服务层，更多的就是API的测试手段，最底层的是UI层也就是界面化的测试。它的核心思想是金字塔的底部测试提供快速反馈，随着测试层级的上移，测试速度会变的慢而且测试范围会扩大。
回归到自动化测试本身，应该首先追求质量而不是数量。现实往往是追求数量而忽略本身。很多时候为了追求漂亮的数据，往往会反馈自动化测试已经覆盖产品功能百分之多少，但是这中间对业务侧的同学来说可能就会很疑惑，数据的背后自己的工作任务并没有减少，而是增加。所以这中间就存在逻辑上的错误，至少在业务侧的同学而言，随着产品功能自动化测试覆盖度越来越多的时候，它的工作量应该更多的是聚焦于新迭代的功能，而很少去关注系统之前已有的功能，如果非要关注，那也是关注的是在新的迭代中涉及到系统之前的逻辑需要重新梳理或者是存在很大的调整。如果没有，业务侧的同学聚焦于新的迭代，而少关注之前的功能，因为之前的功能会自动化测试团队来保障，它的质量好坏让自动化测试来出具体的数据，前提是自动化测试都已经覆盖了100%。当然可能很难100%的覆盖，或者更加精确的说已经覆盖了的，业务侧同学就不需要参与进去这部分的质量负责。
自动化测试的结果数据要具备权威性，不容置疑性。在产品迭代的过程中，测试结果的反馈可以分为两个维度的展开以及合并，两个维度具体说的是
业务侧负责自动化测试未覆盖到的质量情况，而自动化测试负责覆盖到的质量情况，并且最好是需要具体的责任人。这样对质量结果合并后就是测试的最终输出的测试报告。所以这个过程中自动化测试需要注意的是测试场景的覆盖率，而不是自动化测试代码的覆盖率，过于追求自动化测试代码的覆盖率是非常脆弱的，而且具备伪命题，即使自动化测试代码100%的覆盖率又能代表什么了？可以代表覆盖了100%的业务场景吗？答案显然是不能的。这地方谈到测试的脆弱性，测试的脆弱性具体体现为：
- 测试场景没有很好的理解，断言的预期结果没有考虑到实际的情况
- 数据冲突，垃圾数据导致测试用例执行失败
- 在执行端到端的测试过程中，加载浏览器资源导致超时
- 追求过高的测试代码覆盖率
使用更多的API测试技术来保障产品质量，这个过程中至少可以做的事情很多，具体可以总结为：
- 通过API的测试技术来测试业务的流程和场景化
- 保障核心业务流程中的微服务的API，针对这部分API需要考虑它的异常性
- 引入线上巡检的机制实时的轮训检查服务的健康度，具体看线上巡检机制
- 微服务架构下集群的可持续验证，也就是说在上线后如何通过一套测试代码验证到不同集群
针对UI自动化测试的引入，由于UI自动化测试更多的是针对界面化的测试，它在某些程度上是存在脆弱性的，虽然可以解析的页面来解决这个问题，但是页面它是一直呈现变化的，所以针对这部分建议只编写业务的核心流程部分，其他部分认API自动化测试技术来解决。针对如上阐述的，自动化测试的价值具体为：
- 回归测试，批量的回归测试任务让自动化测试去承担
- 持续部署后快速验证被测服务的可测试性
- 线上环境以及预发布环境部署后快速的验证系统的可用性
自动化测试的核心本质就是让自动化测试回归产品质量的本质，为业务团队服务，赋能业务测试团队。对测试而言，不同的职能只是工作内容不同，核心的东西都是一样的，就是产品质量的保障，提供让客户满意的产品。
