模板
教程
环境
性能
功能
管理
如何制定软件测试计划
大家做项目或产品过程中，遇到最多的，也觉得最有风险的就是测试计划。关于如何做测试计划，每个人都有自己的经验，这里不发表个人观点，而是翻译国外某位大师的对于制定测试计划的一些思想，希望对大家将来制定测试计划有用。而且关于测试计划的大部分问题我想都可以在这里找到答案，本人英文水平有限，翻译有不妥之处，请指正。作者为James Bach
制定计划
1. 分析产品
分析什么
用户(他们是谁，他们做什么的)
操作(这个操作是干什么用的)
产品结构(代码，文件，等)
产品功能(这些功能是干什么用的)
产品数据(输入的，输出的，状态，等)
平台(外部的硬件和软件)
怎么分析
走一下产品/原型的主要流程
评审产品和项目文档
咨询设计人员和用户
与类似的产品做比较
可能的工作产出
产品的功能范围概要
注释性的文档
产品的问题列表
执行状态检查
设计人员有没有确认以及批准了产品的功能范围概要?
设计人员有没有认为你已经正确理解了这个产品?
你能不能将这个产品形象化并且预测正确的行为?
你能不能造出产品的测试数据(输入和结果)?
你能不能配置和操作这个产品?
你有没有理解这个产品是怎么样被使用的?
你有没有注意到设计中的漏洞或不一致的地方?
关于这个产品你还有没有未解决的问题?
2. 分析产品的风险
分析什么
产品受到的威胁
产品的易受攻击的地方
失败的方式
失败后的影响
怎么分析
评审需求和规格说明书
评审出现问题的一些事件
咨询设计人员和用户
通过探索性风险分析和质量判据列表来评审产品
识别基本的错误/失败方式
可能的工作产出
组件风险列表矩阵
失败模型概要
执行状态检查
设计人员和用户有没有对风险分析达成一致?
你有没有发现所有的重要的问题，而这些问题是否在测试过程出现呢?
你是否知道在哪些地方要集中测试精力并获得最大的效率呢?
设计人员有没有做一些事情使得重要的问题更容易的发现，或减少其发生的概率呢?
如果你的风险分析是正确的，你是怎么发现的呢?
3. 设计测试策略
基本策略
Domain testing(包括边界值)
用户测试
Sequence testing
State testing
基于文档的测试
结构化测试(单元测试等)
怎么计划
对于风险和产品功能匹配策略
将特殊的和实际的策略形象化
分析是否可用自动化的机会
使用原型去测试probes和harnesses
不要强加计划，让测试人员自己决定
可能的工作产出
各个类型的报告怎样应用的测试策略文档
风险/任务的matrix
已选择的策略中存在的问题或挑战列表
对产品覆盖比较少的部分提供的建议
测试用例(如果是必须的)
执行状态检查
设计人员对这个测试策略达成一致了吗?
这个策略对于项目每个参与人员以及协助人员都有用吗?
这个测试策略是否很基本了?是否也容易的应用到这个产品中?
这个测试策略是否透露了所以的重要的问题
4. 计划安排
安排的内容
测试时间的评估和计划
易测性的工程分析
测试团队人员(详细的能力)
测试人员的培训和监督
测试人员的任务的指定
产品开发信息的收集和管理
项目会议，沟通，协调的方式
与其他已存在的功能之间的关系，包括开发过程中
测试平台的认购和配置
测试工具盒自动化
需要用到的测试桩和mock
测试套的管理和维护
建立和输出协议约定
测试周期管理
问题报告系统和约定
测试状态报告的约定
代码冻结和增量测试
测试后期的压力管理
项目阶段输出协议约定
测试效率的预估
可能的工作产出
问题列表
项目风险分析
任务和责任matrix
测试时间表
与开发之间的约定和协议
执行状态检查
这个项目所列的安排是否支持测试策略?
是否存在一些问题会阻碍测试的执行?
在可见性的问题面前，这些安排和策略是否适合?
你现在是否开始测试还是以后整理剩下的问题?
5. 分享计划
分享的方式
让设计人员和股东都参与到整个测试计划的制定过程中
更主动的获取关于测试计划的意见
尽最大可能帮助开发人员保持进度
帮助开发人员理解他们做什么会影响测试
与技术支持和写技术文档的人分享产品质量信息
让设计人员和开发人员评审并且批准所以相关的文档
记录并加强与开发之间的约定
让参与人员评审测试计划的细节
在测试计划中尽量减少没必要的信息以增加评审的效率
目标
对于测试过程达到一致的理解
