送：《不止测试》一本，文末获取。
如果你是一个软件测试从业者，你应该会有一种感觉，那就是以前累计到的测试经验在某个时刻忽然不再起作用，以前用得很顺手的测试方法在新项目中没有发挥的余地。
以前的软件测试工作上手还是很快的。毕业之后，参加个培训，学一下用例怎么设计、边界值、等价类之类的，再学几个测试工具和管理工具，就直接上手了。 现在的话，学这些东西估计就不够了。
软件在不停的发展，业务越来越复杂、技术架构在不停的演进、基础设施不停的构建，生态越来越复杂、不确定性越来越多，质量风险越来越不可预测。
软件研发的模式一直在改变，我们积累起来测试经验和测试思维也需要不停的升级换代，测试人员需要站在更高的维度来保证产品质量，甚至还需要学习产品思维和运维思维。
首先我们看一下产品思维。测试人员需要更多的考虑产品的业务价值，帮助企业盈利，满足企业发展要求，满足用户需求、让用户使用方便。
这种业务驱动的思想使软件测试人员必须具备三种能力：测试左移能力、测试右移能力和共创能力。
测试左移需要我们把测试工作向左移动，也就是在需求分析和研发阶段就提早介入测试。
在需求分析阶段，测试需要协同产品经理，明确用户是如何使用这个产品的功能特性的。一、验证文档、操作手册是否正确编写；二、对功能的合理性、完整性提出质疑，包括用户操作流程是否繁琐、用户操作流程是否完整、是否考虑特殊人群以及其他人群的使用场景和习惯；三、挖掘用户需求，功能是否达到了用户预期。
测试人员在开展具体工作时最好不要照搬以往的经验和套路，凡事深入一步。
在思考、设计测试用例并执行测试的时候，不能简单的套用用例设计方法去机械地进行，而是要考虑用户可能的行为习惯、使用场景等。比如在视频播放时，用户可能会频繁的切换wifi信号以及蜂窝网络，这些在传统的测试中很少会测试到，测试人员需要还原真实的用户使用场景，进行测试。
对产品文档和需求分析不再停留在表面，需要不断的对流程和交互提出质疑，讨论其合理性。
站在用户角度，深入挖掘产品功能是否达到了用户的期望。比如“朋友圈”的功能流程是否能满足用户展示自我、分享心情等期望，验证点赞、评论等功能能不能被朋友正确阅读。
共创测试方案。测试方案在创建之前，跟业务人员沟通清楚对应功能特性的业务目标、业务价值，跟开发人员沟通相应功能模块的技术风险，基于风险的测试才是最能体现价值的。
传统测试思维和现代QA思维
在产品研发阶段，测试需要协同开发制定标准的代码交付流程，并加入一些特定的测试手段。
- 进行代码扫描和审计
- 进行简单的单元测试
- 建立编程规范和工程标准，制定 git 提交规范、标准上线流程。
- 进行代码覆盖率统计和分析
- diff 检测，标记哪些代码进行了修改，在回归测试时可以基于代码修改位置实现精准化测试手段
- 引入test double，进而Continuous Testing， 上下游依赖，第三方服务，数据构造，做隔离，Mock（如阿里的doom）， Stub（常见的搜索回放），能够有效模拟场景，提升稳定性，降低数据准备的成本，方便模拟异常场景，简化问题定位。
- 代码插桩。
测试右移则需要测试人员关注生产环境。 传统的测试方法通常是在测试环境进行测试，某些时候会准备预发布环境模拟生产环境，但是用户是在生产环境上进行操作，所有的真实数据和用户场景都是来源于生成环境，因此在生产环境的测试行为更贴近真实的用户使用过程。
测试人员永远不能代表所有的真实用户，永远都不能完全模拟出所有的用户行为。用户的行为路径、目的的随机性太强，很难完全模拟，因此需要把测试过程右移到真实的线上环境，从真实用户那里去获取用例、监控以及获取用户反馈。
测试右移可以进行的实践有。一、直接在生产环境测试 ；二、监控预警；三、录制用户流量，生成真实测试数据；四、收集用户反馈。由于生产环境的特殊性，在测试时需要注意很多问题，我们在下篇再讨论。
最后是共创能力。 由于测试左移和测试右移，测试人员经常需要和产品经理、研发工程师、运营人员沟通和讨论，共同制定测试计划和策略。
通过和产品经理的沟通和配合，我们能更快的挖掘出用户的真实需求，从而在用户更关注的功能特性和交互上进行测试点的提炼。
通过和研发工程师的沟通和配合，我们能更清楚的知道产品可能潜在的风险，从而实现基于风险的测试实行。
通过和运营人员的沟通和配合，我们能更快的提炼出线上环境用户的行为路径和数据，及时对用户进行监控，尽快收集到用户的反馈和意见。
这些具体的操作实践，测试界大佬已经用一本叫《不止测试》的书详细解读了。包括测试左移和测试右移的实践、如何提升测试水平、甚至有详细的职业规划路线和需要的技能。扫码领取电子版。（备注：不止测试）
