软件测试学习19-准备阶段：测试方案评审

为什么要进行评审

目前,开发有需求说明会、设计评审会、代码复审会等各种会议。但多是站在开发的角度，从需求和代码层面进行复审和风险规避。在测试环节和测试阶段缺少以测试为主体的评审机制和沟通机制

容易造成以下几方面的问题

• 仅从文档、沟通获取信息，可能会造成信息不对称，认识片面理解错误或不深入等问题
• 缺少同行交叉评审和开发评审机制，无法充分发挥集体智慧，个人的思维难以突破，可能会出现测试遗漏的情况

评审目的

• 呈现测试的工作
• 与开发达成共识
• 不同的思维方式碰撞出火花，借鉴被人的思考方式
• 培养这样的行为模式：愿意为团队或他人出谋划策
• 发挥团队协作，最大限度发挥个人的经验，特长，实现技能互补

评审重点

• 采用的测试方法
• 等价类划分的依据
• 测试数据的选取和准备方法
• 流程测试的路径组合
• 数据比对选取的对象和数据检查点
• 是否需要模拟数据及模拟数据的方法

---

拓展：如果你是一个测试经理，测试饱和状态，如何决定测试的优先级？

假设你是一个部门的测试经理，团队有5-8个小伙伴，但是目前分配下来的测试任务非常多，过饱和状态，那么你会根据哪些情况分配这些测试任务，决定测试工作的优先级？
基本思路大概这样的，以风险为核心判断是比较常用的方式，优先高风险：

• 首先测试变更的部分，再测试没有变化的部分，修改和变更意味着新的风险
• 首先测试核心功能，再测试辅助功能
• 首先测试功能，再测试可靠性。也就是先测试功能是否可用，再深入检查功能在不同条件下的表现
• 首先测试常见情况，再测试少见、异常情况。也就是先使用常用的数据和使用场景，再使用不常用的数据和场景
• 首先测试常见威胁，再测试罕见威胁。用最有可能出现的压力和错误情况进行测试
• 首先测试影响大的问题，再测试影响小的问题。测试在出现问题的情况下会产生大师破坏的部分

个人补充：跳出"优先级"这个命题的，当出现时间不足时其他解决方案
时间

• 用例颗粒：划分用例颗粒大小（模块、功能、用例、检查点），颗粒大意味着用例少，优点是消耗时间少，缺点是质量有所下降；颗粒小意味着用力多，缺点是消耗时间多，优点是质量能够有所保证。适当调整颗粒可以提升效率
• 用例编写：如果用例编写的时间也不足，可以只编写用例标题
• 用例执行：执行一条用例维护一条用例是比较消耗时间的，可以尝试执行一批用例用例之后再批量维护。但是这里要考验你对用例的熟悉程度，不过不建议死记硬背，可以尝试在设计用例时按照一定的"规则顺序"进行编写
• 提前进行功能测试：可先交付基础模块、设置模块，分批入测试阶段
• 提前进行接口测试：若接口先完成开发但是前端工作尚未完成时，可以先进行接口测试，有页面之后再进行页面“页面元素、数据渲染、交互流程”等内容的补测
• 调整项目时间：与项目组其他人员沟通，是否需要延期或者其他时间调整

成本

• 资源协调：产品、测试、开发、技术支持都可以参与测试，负责模块或低优先级的用例执行，主导人进行质量兜底
• 辅助工具：自动化进行重复操作或场景参数化操作、数据库进行数据对比

质量

• 调整项目目标：与项目组其他人员沟通，当前建议切割部分模块不放在下个版本中迭代
• 调整项目质量：与项目组其他人员沟通，部分优先级较低的用例不执行，只提供有限的质量保证，如95%