在面试中，发现很多测试同学由于公司限制，都是基于需求的测试，基于界面功能的测试，无法接触到开发的代码，甚至有的公司，测试人员都无法控制测试环境、数据库等，这些活都是有开发来干的。对于有些公司的现状，是可以理解的，但是对于测试人员的发展以及对于产品的质量都是很不好的。
　　有些同学工作多年，但是也都是基于需求的测试，测试用例完全是需求文档的复制版。这样对于测试来说，失去了很大的作用；因为很多问题缺陷往往是由于需求没有考虑到，需求没有描述、开发功能 遗漏或误解导致的，所以如果测试仍然是死板的按照需求一步一步去测，那往往会漏掉很严重的问题，测试之作用将失去大半。
　　测试不只要测试需求，还得关注隐式需求，也是用户的真实需求，真实意图，真实场景。另外除了需求，我们必须要关注开发的实现，开发是通过什么方式什么技术实现的，开发是怎么设计的？他们设计的是否正确，是否合理？是否满足了需求？是否高效？是否具有可扩展性？是否健壮？流程是否可控，是否兼容了异常情况，是否形成了闭环？底层数据处理的是否合理？等等，其实需要我们测试人员关注的有很多很多。
　　为了保证新入职员工与我们的老员工能够统一测试思路，能够快速融入我们的团队，我们团队建立了一些测试策略模型，此处分享一下。分层测试策略模型，以下模型属于我本人编写，仅供参考；是否适合您的团队，是否全面，还需要根据实际团队，实际项目进行调整。