|
一、测试评审会背景 目前，开发有需求说明会、设计评审会、代码复审会等各种会议，但多是站在开发的角度，从需求和代码层面进行复审和风险规避。 在测试环节和测试阶段缺少以测试为主体的评审机制和沟通机制，容易造成以下几方面的问题： 1、由于文档的质量良莠不齐，以及书面语言的局限性，仅从文档获取信息，可能会造成信息不对称，认识片面，理解错误或不深入等问题。 2、缺少同行交叉评审和开发评审机制，无法充分发挥集体智慧，个人的思维难以突破，可能会出现测试遗漏的情况 3、开发同事无法了解测试工作的进展程度，不利于双方更好的配合。 鉴于以上原因，定期开展测试评审是非常必要的。 本文档针对前期开展的版本测试评审会存在的不足和问题，总结一些经验和教训，制定评审议程，希望能帮助大家更有效率和效果的开展测试评审。 此文档只适用版本的测试评审，项目的测试评审需参考规范。 二、测试评审会目的 通过测试评审会，一方面，测试人员对需求和系统实现方式的疑问能得到开发的解答，并最终与开发达成共识；另一方面，测试人员对测试方法，测试策略，测试思路进行展现，开发和其他评审人员进行提问和补充，目的是能在有限的时间和人力条件下，以高效的测试手段，达到比较理想的覆盖率。 1、呈现测试的工作 2、与开发达成共识 3、不同的思维方式碰撞出火花，借鉴被人的思考方式 4、养这样的行为模式：愿意为团队或他人出谋划策。 5、发挥团队协作，最大限度发挥个人的经验，特长，实现技能互补。 三、测试评审会准备 订会议室（时间地点确认清楚是开会的基本前提） 发出会议邀请（至少提前一周预约，以免发生会议冲突） 对需求进行充分的分析（详细请参考文档《由浅入深分析测试需求》） 如有严重阻碍测试分析的问题，需事先跟开发个别沟通，以保证在评审前能完成基本完整的测试分析。 如需求复杂，可以先邀请其他测试人员，进行同行交叉评审后，再邀请开发进行评审，以保证开发参与评审会的效率和效果。 四、测试评审会议程 由于在需求评审甚至设计评审阶段，需求和设计方案都具有很多不确定因素。后期测试人员只能通过文档获取最终信息，但仅仅通过文档又无法完全保证信息的完整可靠。所以，我们通过测试评审会针对重要逻辑进行口头确认的方式来作为文档确认的补充。 另一方面，测试方会对测试思路，测试方法，测试点进行呈现，开发等其他评审人员提问和补充修正，以达到完善测试案例的目的。 测试评审会主要包括三部分: 1、确认答疑： 测试方针对需求和程序实现方式提出疑问，开发给予解答（时间控制在30分钟内） 2、测试呈现: 3、测试呈现测试思路，方法，策略等（详细参考文档《由浅入深分析测试需求》中的测试分析部分）（时间控制在30分钟内） 4、评审提问： 开发等其他评审人员进行提问和补充修正。（时间控制在20分钟内） 五、测试评审会技巧 1、会议需要主持人： 推动讨论，控制节奏，适时转移和终止。 2、控制会议时间： 聚焦时间在50-80分钟，不要让一次会议超过2个小时。 3、需要做会议记录： 评审中无法确定的问题和后续需要跟踪的任务，需要通过会议纪要记录并跟进。 4、有侧重的进行评审： 区分重点难点，需求中已明确的无需重复哪些是需要一笔带过的，哪些是需要重点详细评审的。 5、评审的目的是提出问题而非解决问题，所以终止对细节和不确定问题的讨论，记录跟踪即可。 6、测试呈现的重点： 采用的测试方法 等价类划分的依据 测试数据的选取和准备方法 流程测试的路径组合 数据比对选取的对象和数据检查点 是否需要模拟数据及模拟数据的方法 基于风险的测试取舍。 文章来源：网络 版权归原作者所有 上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理 |
|
|
