IBM对测试计划的评审记录
最近公司做的项目要由IBM监理进行评审才可。呵呵，这也让我们看到了IBM是怎样做测试的。呵呵。下面把测试计划的评审记录放在这里，希望大家能共同学习一下呀。
1. 会议评审内容。
（1） 测试计划的名称不合理，应改为系统集成测试&用户接收测试测试计划，如果用以前的测试计划的名称则应包括单元测试部分。
（2） 测试计划文档的名称应加上版本1.0，以便以后对文档版本的管理。
（3） 文档2.0中用户接收组应与用户沟通确定用户测试组的负责人
（4） 文档3定义一部分应加入Uat和Sit的定义目标，定义要再清楚的补充一下，详细资料杨威那有可以借鉴一下
（5） 文档4参考资料一部分将b、c去掉，同时添加参考资料的版本信息。
（6） 文档5测试内容部分应添加场景部分、数据部分、回归部分（哪些需要做回归、哪些不需要做回归）。要写清楚测试的重点是什么，关键回归路径确定清楚。
不需要测试的地方要写明白（安装、备份、维护测试），系统厕所和用户确认两个测试阶段的测试重点不同，应在此处体现出来。
本次测试共分两种测试即功能测试和非功能测试，其中功能测试包括业务测试和功能测试，非功能测试为压力测试。
（7） 文档6.1部分应写明了进入系统集成测试和用户确认测试的准则，即一些量化指标，如程序已经达到了这个量化指标（某些重点功能已经完成），才能进入系统集成测试或用户确认测试。
（8） 文档6测试环境准备就绪前建议加一个测试数据的准备，写清楚系统集成测试采用模拟数据测试，用户确认测试采用真实数据测试，这一方面还需要会后再具体讨论一下。
（9） 文档7.2测试进度中只有两个测试人员，比较紧张，要将人员紧张的风险列出来。
SIT和UAT可以并行进行，建议添加UAT执行计划和SIT执行计划，也可以将这两个执行计划都写在总计划中。
回归主要场景和业务功能在此处应该写明白。测试中回归需要几轮回归，每轮回归所执行的场景和功能也要写明白。关键的回归路经很重要，建议写出来。也可以采取两轮迭代的方式回归测试。建议添加用例规约。
（10）文档7.3缺陷的等级定义不明确，会后再考虑一下，看IBM是否可以建议一下。
（11）文档7.4应添加程序更新的工作流程，如几点更新，由谁来做更新。测试跟踪汇总建议每天进行一次，每天与项目经理进行一次测试汇总。
（12）文档7.5与6结合一下，或去掉7.5的准入准出规则
（13）文档8里面添加人员风险。
（14）文档9测试环境中应写明系统集成测试和用户确认测试的环境是否相同，添加外围系统接口实现的拓扑图。
（15）文档10和文档11结合起来叫做测试工具，写明没有回归测试工具，并分析其风险。
文章来源于领测软件测试网 https://www.ltesting.net/
