写测试计划的正确姿势

lsekfe

　测试计划是测试生命周期中非常重要和关键的部分。良好的测试计划可以确保了良好的软件质量。　　简单地说，测试计划是一份文档，该文档中会描述测试过程中所涉及的所有内容。
　　当然内容是相当的多啊，这篇文章会给大家一个概括，让大家知道在编写测试计划时我们应该着重写哪些重要项。
　　那么，一份详尽的测试计划主要包括以下内容：
　　测试计划标识符
　　提供文档的唯一标识符，根据公司配置管理，标识号可以是数字或字母数字。
　　参考文献
　　本章节列出所有编写测试计划需要参考的文档。
　　比如：系统需求规范、用例文档、项目计划等。
　　介绍
　　介绍或总结项目的目的和范围。
　　比如测试的产品是什么，目标是测试产品的功能。
　　需要测试的功能
　　此章节需要列出项目中需要测试的所有功能。
　　不需要测试的功能
　　此章节列出项目中不需要测试的功能，并且说明排除原因，如无影响/受影响较小/优先级较低的功能。
　　测试策略
　　包括测试类型、如何测试和测试重点。
　　比如哪些模块使用自动化测试，哪些模块使用手动测试，压力测试要执行多少天，尤其关注内存泄漏等。
　　测试可交付成果
　　测试的所有可交付成果，如测试用例、测试报告，bug分析等。
　　项目通过/失败标准
　　我们将指定用于确定测试项通过或失败百分比的标准。
　　示例：产品所有主要功能都符合需求，测试用例的通过率应大于95%，并且不应有任何严重bug。
　　停测标准
　　指定何时停止测试。
　　比如冒烟测试不通过就停止测试。
　　测试任务
　　要执行的所有任务/步骤。
　　比如测试环境应该在测试执行阶段之前准备好，编写测试用例，准备测试总结报告等。
　　资源需求
　　人力资源，测试环境所需的硬件、软件和任何其他工具的列表。
　　职责
　　指定了每个测试任务的角色和职责列表。
　　比如测试计划应由测试负责人编制。测试的准备和执行应由测试人员进行。
　　人员配置和培训需求
　　培训/招聘需要弥补现有技能和预期技能之间的差距。
　　进度安排
　　完成关于何时开始、何时结束以及每项任务应进行多长时间的详细信息。
　　比如执行测试执行10个工作日，总结测试报告1个工作日。
　　风险评估
　　详细说明项目中可能遇到的风险和应对措施。项目中经常碰到的有需求变更，人员变动，被重大缺陷block住。
　　批准
　　谁应该签署并批准测试项目。
　　以上就是一份测试计划中该有的内容，大家可以在脑海里与自己正在做的项目对号入座一把。
　　唯一的不变就是变化
　　人们可能倾向于不谈计划的一个原因是，他们知道任何计划都可能改变。测试计划也不例外。但是它不应该成为阻止你创建测试计划的借口。如何让测试计划变得弹性和灵活去应付变化呢？
　　答案就是基于简单原则。文档中，比如名称、日期、风险和技术细节等方面，如果计划越详细和具体，则发生更改时，测试计划就越脆弱。
　　但是，问题又来了，如果没有细节，测试计划又有什么价值？
　　当涉及到测试目标、范围和其他更稳定的方面，它们相对更能经受住变化。
　　但对于日程安排、人员和其他相对容易发生变化的方面，一个好的做法是以一种可以记录更改的方式去描述它们，而不需要创建测新版本的测试计划。
　　写在最后
　　测试计划是测试中的一项基本且必须的环节，测试计划就像”测试版”的项目计划。
　　在测试的许多方面，需要一定程度的计划和准备，以便在需要时获得所需的资源。
　　一些资源，如人员和环境，可能需要大量准备。测试计划是定义这些资源并表达测试需求的地方。
　　测试计划还有一个主要目标是与团队的其他成员，也许还有其他团队沟通如何计划进行测试。没有测试计划，关于测试的交流就变得非常动态，人们可能在任何给定的时间都不知道测试的目标和期望。
　　记住没有一个测试计划是完美的，但是你在编写测试计划中获得的经验越多，计划就越容易。

Miss_love

支持