1. 测试计划
测试计划是对测试的范围、方式、资源及测试所需的时间做出一个预先的指定方针，而计划的内容必须包括进行测试的项目、产品功能的测试、所需进行的测试工作、每位测试人员所应该负责的测试工作，以及与测试有关的风险。如果再加上测试计划的目标及测试的重点所在，测试计划的定义就更加完整了。
1) 编写测试计划的目的
a) 帮助软件测试进行的更顺利：对软件测试来说，它的风险包括：项目终止、测试中断、设计规格不断的变化、人员不足、人员流失、人员测试经验不足、测试进度不足、测试进度被压缩、软件硬件资源不足、软件硬件资源流失、测试方向错误，以及其他可能会影响测试过程的种种议题。这些都是不可预期的风险。对测试计划而言，凡是会影响到测试的议题，最好都纳入测试计划的内容中，这样除了可以让测试过程更加顺畅外，对管理而言也是一大帮助。
b) 明确测试方向、促进彼此沟通
c) 让软件测试更易于管理：测试计划中包含了两种重要的管理方式：一个是WBS（Work Breakdown Structure，工作分割结构），另一个是DC（Divide and Conquer，分化后逐一征服），这都是管理上的技巧。对软件测试计划来说，WBS就是将所有的测试工作一一单位化，这有利于测试人员的工作分配。在进行软件测试时，管理人员可以利用DC技巧来监督过程，掌握测试进度。
2) 计划的种类
a) STP（单一文件测试计划）
就是将测试计划所有的议题编写在同一份文件上
b) MTP与DTP
MTP（主要方针测试计划）与DTP（详细运作测试计划），这两种计划通常在一起使用。基本上MTP的内容是将测试分成不同的阶段，对于每个阶段规划出概略的测试方针，至于各阶段的详细测试计划则编写在DTP内，因此通常一个MTP会伴随好几个DTP。较大的、周期较长的项目、人员组织复杂、开发模式复杂的项目更能体现出测试计划的重要性和测试计划更新的必要性
c) 另外一种划分方法可分为：做样子的测试计划（BTP，Beautiful Test Plan）和有帮助的测试计划（UTP，Useful Test Plan），BTP可以让人升官发财，但被称赞的永远是UTP
3) 计划的纲要：5W（who、how、when、where、what）
2. 其他文件准备
1) 软件开发所应准备的文件类别
a) 销售用途
i. White Paper：产品白皮书
ii. Product Road Map：产品未来方向报告
iii. Performance Report：使用性能报告
iv. Compatibility Report：兼容性报告
v. Product Presentation Files：产品演示文稿说明
b) 设计用途
i. Product Requirement Document：产品功能需求，提出产品所要具备的功能
ii. Architecture Document：产品基础设计文件，产品的底层设计
iii. Design Spec. Document：产品设计规格，产品的详细规格设计内容
c) 产品用途
i. Brochure：产品目录，介绍产品的文件
ii. Readme File：自述文件，伴随产品一同发行的文件
iii. Help File：帮助文件
iv. User Manual：使用手册
v. Product Licensed File：产品授权书
d) 客服用途
i. Know Issues List：已知问题列表
ii. FAQ：常见问题解答
iii. Survival Guide：危机处理指南
iv. Trouble Shooting：问题诊断指南
e) 测试用途
i. Test Plan：测试计划
ii. Test Case：测试用李
iii. Bug Report：问题报告
iv. Testing Report：测试结果报告
v. Test Tool User Manual：测试软件使用手册
vi. Test scrīpt：测试脚本（测试步骤），基本的测试程序指南
2) 准备文件的目的
a) 知识的交接
b) 知识的管理
c) 减少重复的工作
d) 促进人员彼此的沟通
3) 如何准备工作
a) 准备工具：比如word、excel、visio等
b) 定义文件形式：定义文件的编写形式，包括内容的编排、内容的专业程度和所采用的字句
c) 搜集资料
d) 分析资料
e) 组织文件
4) 测试人员应准备的文件及模版
a) Bug Report用例
i. Daily Bug Report：重点在程序bug的状态还是处于open的情形，所代表的意义是目前整体项目修改bug的进度是什么，还可以了解每天新增的bug数量的多少
ii. Weekly Bug Report：重点在项目在本周内所发现的重大问题的原因及解决方法，通常这些重大问题会影响到项目的开发进度和质量优劣
iii. Bug Repor要素：
1. 产品名称（Product Name）
2. 版本（Version）
3. 建构版本（Build）
4. 日期（Date）
5. Bug的总数量（Overall Bug Number）
6. 根据优先级分配的Bug数量（Bug Number by Priority）
7. 新增的Bug数量（New Submitted Bug）
8. 等待处理的Bug数量（Remain Open Bug）
9. 已经解决的Bug数量（Bug Closed）
10. Bug的ID号码（Bug ID）
11. Bug的名称（Bug Title）
iv. FAQ用例
v. Test scrīpt用例
vi. Performance Test Report用例
vii. Compatibility Test Report用例
