测试左右移浅淡

1. 左移之前：较早的测试过程，待提测后正式开始测试，提bug，回归，发布UAT/生产，会产生的问题或风险

    1> 需求问题：敏捷模式下需求不够清晰，细化是常态，导致需求；

    2> 用例问题：未了解开发的设计方案，认识不了改动范围，导致功能点或场景遗漏；

    3> 成本问题：各个阶段修复问题的成本相关很大，越早修复成本越低；

    4> 需求风险：产品功能或交付的用户体验不够友好，不符合习惯行为；

    5> 延期风险：转测前未把控迭代版本开发进度，可能导致转测延期；

    6> 质量风险：转测的版本质量完全依赖开发个人能力的高低；

2. 左移之意：  测试左移简单来说其实就是通过测试人员提前介入项目，推动需求明确/细化，把控各节点/风险等前期一系列的活动，保证按需开发，转测质量，以达到缩短测试周期的目的

   1> 提前介入：测试人员提前介入项目，了解产品故事，需求背景；

   2> 推动需求：深入梳理，分析需求，发现需求中的问题；

   3> 把控节点：版本各关键节点的把控，如需求评审，开发设计，用例评审，提测质量；

   4> 识别风险：了解版本开发进度是否正常，技术是否有困点，是否能按时转测，风险规避方案；

   5> 核对输出物：核对产品原型，UI是否相符，是否遗漏；

   6> 冒烟测试：正式测试的准入标准，以保证后面测试工作的开展；

3. 可做之事：不同阶段，左移可具体落实的动作

    1> 需求分析：需求分析不只是了解需求， 更应该评估需求质量，分析需求的合理性和完整性；

         a> UI交付时间点；

         b> 需求结合原型或UI，加强理解且核对二者；

         c> 依据后端开发设计文档，分析表和接口的设计；

         d> 前端需要把需求拆分成很小的功能点清单列举出来，细到特殊字段需要加校验的粒度；

         e> 需求分析时，需要注意各需求之间的关联性，保证功能统一性，正确性；

         f> 分析正常场景时，结合业务背景/业务意义进行分析，可能会发现因需求不够具体化而不符合实际业务场景的问题；

    2> 需求评审/管理： 需求的准入，管理标准是版本迭代的基石

        a> 评审：需求评审时，产品说明需求市场价值，让团队人员更好理解和把关需求开发条件是否成熟

        b> 管理：Bug区分出是需求问题或需求变更类型

        c> 插入：插入需求需要评估审核，tapd标识，回归阶段不接紧急需求；

   3> 开发设计：前后端开发针对需求的实现方案，后端提供接口，客户端与数据库的桥梁，抽象对象来组织数据给到客户端

        a> 业务逻辑：复杂业务逻辑画出业务逻辑图，结合数据落库说明实现过程；

        b> 表设计：三大范式五大约束，表的索引，字段类型，结构；

        c> 接口业务性：           

             <1>充分存在的理由，必须设计这一接口意义价值；
             <2>职责明确：一个接口只负责一个业务功能；
             <3>接口要处理的业务逻辑尽量单一；
             <4>高内聚低耦合：一个接口要包含完整的业务功能，而不同接口之间业务关联尽可能的小；
             <5>API级别和重要性划分；

        e> 接口规范性：

            <1>有统一的接口设计规范说明；
            <2>接口和参数的命名有意义且清晰；
            <3>入参格式统一，输入的校验，禁止随意拓展参数；
            <4>接口的异常处理能力，如错误码/错误信息与业务/业界挂钩

   4> 用例评审技巧：高质量的用例是测试工作的重要保证，所以用例评审是测试工作最关键的环节，没有之一

         a> 设计思路：用例设计前，先出设计思路给到测试负责人，对齐思路后再进行用例设计；

         b> 用例类型：正常，异常，UI，数据，权限，平台兼容性，业务数据兼容性；

         c> 用例描述：用例描述精练准确，清晰明了；

         d> 发出时机：用例提前半天发出给到相关人员；

         e> 参与人员：用例提前半天发出给到相关人员；

         f> 评审优先级：按需求优先级高到低进行评审；

   5> 测试准备： 执行测试需要的一些环境，数据等相关事项需要在转测前完成，以保证执行测试的效率

        a> 业务数据：测试所需的数据提前准备，如账号，角色，业务数据(保险公司，调度规则配置)等；

        b> 真实数据：测试业务，与业务数据有关时，拿到真实的业务数据例子，按真实业务数据进行正常测试；

        c> sql脚本：涉及到数据测试时，提前梳理表关系，编写sql脚本用于测试；

        d> 数据流：完成正向的业务流程测试，更需要关心业务流和数据流的关系，提前熟悉了解；

4. 右移之意：在生产环境上加监控，监控线上产品可用性和性能

     1> 提升体验：从目标用户那里得到反馈和评价，优化产品，以确保客户满意；

     2> 产品性能：在真实的生产环境下使用产品，测试产品是否有性能问题；

     3> 自动化范围：市场是检验需求最好的地方，经市场反馈比较好的功能一般比较稳定，可以实现自动化提长测试效率；

     4> 市场价值：从用户那里可以了解产品功能的业务背景和意义，明白功能点的市场价值；

     5> 生产环境：得到生产上真实用户使用场景，用于在测试时模拟场景；

     6> 质量服务：给用户提供了质量服务，增加用户对产品的相信度；

 5. 右移之事：

     1> 灰度上线：灰度上线后，进行核心功能测试；

     2> 线上监控： 时时监控服务日志，关注每日服务器指标；

     3> 线上预警：及时发现并预警问题，保证问题第一时间反馈过来；

     4> 线上问题：确认且跟进解决线上问题，将影响范围降低到最低；

     5> 用户反馈：关注线上用户价值高，使用率高的功能，得到版本必测清单；

     6> 收集目标用户的反馈和评价，用于提升产品体验；