1）在测试策略中要包括产品的背景信息。在测试策略文档的第一段回答- stakeholder（项目利益相关者）为什么要开发这个产品？回答这个问题会帮助你更好更快地理解项目，并为所做的事情优先级排序。
2）测试环境，它应该包括你在那个操作系统平台上做测试，系统是基于那些补丁和安全更新。例如，一个测试环境可能必须包含Window XP SP2
3）列出你将要测试的所有重要特征。如果你认为有些特征不属于本次发布的一部分，那么就标注“不会被测试的特征”。
4）写下在此项目测试中将应用到的测试方法。清楚的列出你将以那些类型的测试作为测试引导。例如：功能测试，用户交互界面测试，集成测试，压力测试，安全测试等等。
5）回答以下问题：你如何进行功能测试？手动还是自动化？测试工具是什么？你将执行在测试管理工具中的所有测试用例吗？
6）用什么作为测试错误报告跟踪工具？当测试人员发现一个新的bug之后，流程应该是什么？
7）测试进入和结束的标准分别是什么？
8）如何去跟踪测试进度？什么度量可以用来记录测试结束？
9）任务分布 – 定义每个组员的角色和职责，包括测试组长，测试员，项目经理等。测试战略将由开发人员review，确保测试的覆盖率全面且没有重叠处。测试经理和部门经理都要同意测试策略之后，测试工作才能展开。测试小组的划分及分工。
10）有哪些风险会阻碍测试的完成？例如，代码的依赖性，测试工具的局限性等等。要提前想到风险发生的解决办法。
11）测试日程表- 每个测试计划都应该包含一个预估时间来估计完成测试所需要的时间。这需要几个阶段：一，测试人员必须至少完成一次的执行全部用例。二，如果一个错误被测试人员发现，开发人员将修复此错误。测试员重新测试此用例，直到其功能正确为止。最后，但很重要的一点是测试员必须对修改过的地方执行回归测试以保证开发人员在修复一个错误的时候没有引入另外的代码错误。测试日程表要包含每个测试部分涉及的测试人员。时间往往很难估计，因为测试中有很多不确定性的事情发生。其中一个比较好的办法是参照前一个发布来估计。
12）回归测试的方法- 一个错误被修复后，必须要保证产品功能按用例标准运行。回归测试是为了在修复一个问题时不引入另外的错误。因此相关的测试用例要在被执行一次，从而确保没有特殊的东西被引进。在这个阶段，就要定义回归测试的方法。有的公司讲相关模块的单元测试用例全部遍历一遍，从而确保产品的质量。 弄清楚这些问题，你就可以写一个详细的测试策略出来了。