测试分层

# 背景

纯属个人总结，总结下目前接触到测试方法/体系

# 个人总结

从开发架构上来分层

目前接触到项目，基本上都是如下图的架构模式（MVC），每一层都衍生出对应的测试

对应的测试：

看看市场上的测试岗位，大多数都是围绕这这些来设定的：功能测试，自动化测试，测试开发，性能测试，服务端测试

个人最近几年都是服务端测试，基本上也是在接口层，但目前偏重数据层，也明白了数据的重要性，业务的根源在数据，从数据上可以反应业务的健康度

不要被表象中的自动化，性能所迷惑，觉得做测试往上走就是搞自动化，性能，这样太局限了；

有这么一种情况值得思考：即使你自动化搞的非常牛逼，性能也是吊炸天，然而业务没了怎么办？ 即使你是工具组的测试开发，没有业务团队接入也是扯淡。因此测试的本质的业务的质量，而不是为了测试而测试

自动化是为了提高效率，是为了保证的解决业务的稳定性，性能是为了保证业务的体感

从流程上来分层

上图是公司大致的研测流程，应该都是大同小异，备注是测试可以涉及的点

质量体系的建设都跟跟随研测流程，好的质量体系是非常有必要的

说下目前团队的建设：

需求阶段：研发怼产品在这边很常见，公司的文化就是人人都是产品，这也是对业务的一种帮助，

要勇于对产品需求提出建议看法，要产品提出数据支撑，不能你想做什么功能就做什么功能，要有预期的值的估算，如做了XX项目，可以预计xx指标上升20%；

提测：提测需要研发保证主功能没有问题，列出测试点和自测结果、测试难点，测试记录打回次数，这是质量的体现，还有单元测试要全部通过，push代码触发；

回归测试：回归测试平台保证之前积累的回归用例全部pass，上线卡点

线上：监控体系建设，服务器资源的监控依赖于公司部署平台，如500错误，CPU资源；核心业务场景接口监控，保证核心业务无误；接口可用性监控；第三方接口拨测监控...保证线上无重大问题；

数据层：大盘数据的监控（阈值，波动值），数据分析衡量业务健康度；

监控体系是保证线上的无重大故障，或者提前感知问题；

自动化是测试效率的提升，保障业务迭代的稳定性；

数据分析是数据的累积，业务健康度的考察；

# 最后

以上每一项展开的话，都是一个个课题，测试的水也很深，个人期望自己也能成为某一方面的专家，随着细化，测试也在慢慢细化，如现在的app专项测试，大数据测试，算法测试....

路很长...