软件质量管理之软件测试计划编写方法

　　A.引言

　　1.目的

　　旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。

　　2.测试计划内容

　　预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。

　　3.测试摘要

　　这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员。

　　4.重点事项

　　列出测试的重点事项。可以将问题按重要程度和优先级罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。

　　例如，(以测试均匀派发更新包为例)

　　a)新进门店如果没有最近三天的交易数据，系统将按默认值插入到IS_BD_TrafficSpread表中

　　b)新进门店如果有最近三天的交易数据，但运行时间每天都小于6小时， 系统将按默认值插入到IS_BD_TrafficSpread表中

　　c)新进门店如果有最近三天的交易数据，且运行时间有一天大于等于6小时，则系统按这三天的时段平均交易量计算时段派发比率

　　d)运行后的门店将按最近三天的时段平均交易量计算时段派发比率

　　e)运行后的门店，如果每天运行时间8小时，而某天又突然要运行10小时，那么将有2小时派发不出赠品和奖品，此时需手工更改IS_BD_TrafficSpread表中剩余的2小时的比率才有派发

　　5.争议事项

　　简要说明争议事项(例如，数据查询系统，说明其中“自定义查询功能”，部分暂未开放，不作处理)

　　6.风险评估

　　通过对技术文档的阅读，对被测系统可能存在的问题：系统设计，数据库设计，响应时间，因测试环境不足可能存在的测试缺陷事先评估出来，以指导测试方案，进行有重点的测试。(例如：客户端上传下载程序，说明在这里用了6台机器做一个客户端程序下载测试，但不能做到大型的压力测试，十几台机器同时下载时可能出现的滞后现象或下载不成功现象在公司内无法进行测试，发布下去后再进行人工跟踪，请相关人员注意此点)

　　7.时间进度

　　简要说明测试开始时间与发布时间。

　　8.测试目标

　　简要说明测试发布的质量目标;

　　测试计划中所有测试方法和模块已经执行通过(例如，模板测试已经根据《模板及配置程序测试用例标准V2.0.xls》进行测试，并且执行通过测试);

　　所有的测试案例已经执行过;

　　所有的重要等级为1/2的Bug已经解决并由测试验证。

　　B.项目背景

　　1.测试范围

　　说明本计划涵盖的测试范围，比如系统程序更新包测试，模板测试，更新包测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。

　　a)简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能;

　　b)如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设;

　　c)列出可能会影响测试设计、开发或实施的所有风险或意外事件;

　　d)列出可能会影响测试设计、开发或实施的所有约束。

　　提示和技巧：(以下几点举例均以“处理派发错误和赠品修改错误”更新包为例)

　　a)需要测试和特别注意测试那些部分?(例如，数据查询需要测试“更新包执行情况”“更换赠品”“自定义查询”三个部分内容，特别注意删除更新包所牵涉的数据表变动以及更换赠品所影响的两张表dbo.PM_PP_NonCouponPromotionProduct与 PM_PP_SubPromotionQuota 是否有变化)

　　b)测试是否专门针对与某些问题的解决?(例如，主要针对均匀派发问题和数据查询赠品修改错误问题进行的更新包)

原文转自：http://www.uml.org.cn/Test/200906256.asp