从开发架构上来分层
目前接触到项目，基本上都是如下图的架构模式（MVC），每一层都衍生出对应的测试。
对应的测试：
看看市场上的测试岗位，大多数都是围绕这这些来设定的：功能测试，自动化测试，测试开发，性能测试，服务端测试
个人最近几年都是服务端测试，基本上也是在接口层，但目前偏重数据层，也明白了数据的重要性，业务的根源在数据，从数据上可以反应业务的健康度
不要被表象中的自动化，性能所迷惑，觉得做测试往上走就是搞自动化，性能，这样太局限了；
有这么一种情况值得思考：即使你自动化搞的非常牛逼，性能也是吊炸天，然而业务没了怎么办？ 即使你是工具组的测试开发，没有业务团队接入也是扯淡。因此测试的本质的业务的质量，而不是为了测试而测试
自动化是为了提高效率，是为了保证的解决业务的稳定性，性能是为了保证业务的体感。
从流程上来分层
上图是公司大致的研测流程，应该都是大同小异，备注是测试可以涉及的点
质量体系的建设都跟跟随研测流程，好的质量体系是非常有必要的
说下目前团队的建设：
需求阶段：研发怼产品在这边很常见，公司的文化就是人人都是产品，这也是对业务的一种帮助，要勇于对产品需求提出建议看法，要产品提出数据支撑，不能你想做什么功能就做什么功能，要有预期的值的估算，如做了XX项目，可以预计xx指标上升20%；
提测：提测需要研发保证主功能没有问题，列出测试点和自测结果、测试难点，测试记录打回次数，这是质量的体现，还有单元测试要全部通过，push代码触发；
回归测试：回归测试平台保证之前积累的回归用例全部pass，上线卡点
线上：监控体系建设，服务器资源的监控依赖于公司部署平台，如500错误，CPU资源；核心业务场景接口监控，保证核心业务无误；接口可用性监控；第三方接口拨测监控...保证线上无重大问题；
数据层：大盘数据的监控（阈值，波动值），数据分析衡量业务健康度；
监控体系是保证线上的无重大故障，或者提前感知问题；
自动化是测试效率的提升，保障业务迭代的稳定性；
数据分析是数据的累积，业务健康度的考察。
