业务测试疑问：
你觉得业务测试就是点点点吗？
你觉得业务测试就是依据需求设计case并全部执行通过就OK了吗？
你觉得业务测试就是功能测试+兼容测试+性能测试+接口测试+自动化吗？
你觉得业务测试中的“业务”就是一个个的需求吗？
你觉得业务测试中的“测试”就是对研发提测内容的质量保证吗？
现在行业里流行测试左移和右移的说法：
左移，业务流，成长方向：让执行的事情变少，并拿到等价甚至更好的成果；
右移，技术流，成长方向：通过技术的手段让事儿做得更快，支持更多并行，减少变更成本；
在我看来，左移和右移，不是互斥的。如果把一个项目的生命周期定义为：需求调研和整理、需求评审、技术设计、需求研发（测试分析）、需求测试、业务验收、上线跟进、工具沉淀。那么左移和右移的起点，是在何处？我的工作习惯里，这个起点在“需求评审”。左移，是为了尽我所能的确保需求的合理性、可行性、业务逻辑的严谨性、页面和交互设计的合理性、技术设计的正确性；右移，是为了确保测试内容的高覆盖度、测试手段的灵活、测试执行的高效率、测试工具的持续优化，测试平台的不断完善。两者的终极目的，都是为了质量和效率服务的，但侧重点却截然不同。左移，更多的是为质量服务，并且是将质量的含义从软件质量扩展到产品质量，将质量保证从测试执行提前至对产品方案和技术方案的审视，与此同时，少走弯路的结果也就间接的提高了效率。右移，更多的是为效率服务，通过创新的测试方法、灵活的测试手段，多样的测试工具、完善的测试平台，提高测试效率，当然，右移中的并发、性能、兼容、内存泄露等专项测试，又进一步加强了质量保证。
测试左移方向：
今天，我们重点说说“左移”。很多时候，上文提到的“需求的合理性、可行性、业务逻辑的严谨性、页面和交互设计的合理性、技术设计的正确性”会让人觉得是在喊口号，一个小小的qa怎么会有这样的判断能力呢？其实不然。
业务研发、业务测试都是为“业务”的迭代服务的，而“业务”的迭代必然指向一个目标，一个目标往往又指向一个背景，这个背景也许是一个用户痛点、痒点、爽点（C端、B端、平台自己人），然后业务方基于这些提出了诉求，接着产品设计了方案，然后拿到了技术这里，一次“业务迭代”里的一个需求就出现了。绝大多数情况，业务测试会在接下来的需求评审会与这个需求相遇、相知，然后相守。
基于对需求背景的了解、理解，我们可以初步判断，业务方所认为的用户痛点、痒点、爽点是否合理且正确？产品给出的解决方案，是否能满足业务方的诉求，是否立足于产品现状，是否会带来其他问题，是否还有更好的解决方案，ROI能否达到预期？这些就是“合理性”的判断；产品给出的解决方案，是否在规定的时间、既定人力、现有的技术储备资源下可实现？这些就是对“可行性”的判断；产品设计的细节，业务逻辑是否严谨、完整，页面和交互设计是否符合用户使用习惯、是否符合平台定位和风格？这些就是对“业务逻辑的严谨性、页面和交互设计的合理性”的判断；数据库设计、实现逻辑设计、接口设计是否满足需求，是否具有较好的扩展性，前后端交互的设计是否符考虑到用户体验和异常场景兼容？这些就是对“技术设计的正确性”的判断。以上这些判断能力，一个优秀的业务测试应该是要具备的。当然，这些能力不是凭空出现的，是行业经验、业务知识积累、产品现状了解、数据库知识、测试思维演化等等一系列的积累和成长后的产物。
为什么我们要测试左移呢？因为发现问题的时间越晚，修复的成本就越高。
图中橙色线条代表了传统测试发现缺陷的时间，大多数 bug 都是在功能测试和集成测试时发现的，最后导致的结果就是发布前加班加点，祈祷不要有 bug 漏到生产环境。
设想我们把测试活动向左移动，那就意味着修复成本大幅下降。
那么我们又该如何在具体的项目中，逐渐的了解业务、了解产品现状，快速且深入的左移到项目实施中呢？
整理了一些心得，与大家分享：
1、提前预习：
时间允许的情况下，应在需求评审前完成阅读需求，罗列好需要确认的问题
2、需求评审：
需求评审时，专心参与评审，积极思考在当前业务背景新需求的下可行性、合理性、逻辑严谨性，主动表达自己的疑问和建议，深度参与到评审+脑暴的环节里，对最终敲定良好的产品方案贡献力量，同时也可收获对产品方案的细致了解
3、需求分析：
评审后，如有必要（视需求的复杂度、规模、影响范围而定），进行需求分析和测试用例编写，在此环节，会加深对需求的进一步理解，可能会衍生出新的疑问和建议，积极与pm沟通，同时确保沟通结果同步相关人员、记录至需求文档
4、技术评审：
如果项目有技术评审，相关QA要参加，需要了解技术设计的思路，接口设计、表结构设计、数据流转关系，需要思考设计的合理性，是否满足需求等
5、上线保证：
基于对业务、技术设计等情况的了解，对于上线前准备工作有足够的认识，包括但不限于：DB侧新库新表的建立、表结构的调整、ES中索引的建立、业务基础数据的准备、各模块上线的依赖关系等
6、知识积累：
做好测试用例积累，分模块梳理业务知识并沉淀至wiki，整理sql语句等，测试leader组织周期性知识分享
测试左移的概念给整个测试角色带来了巨大的转变。软件测试不仅仅是 “发现 bug”，而是致力于 “尽可能早的检测和预防 ‘bug’ ”。
