项目范围说明：
1，项目背景说明；
2.功能需求列表（如果功能比较大，可以加一列对功能进行解释）；
3。测试交付件（策略、方案、计划、用例、报告、说明资料等，把各责任人写好，一般这些材料都需要评审的，把关人也写上去）
重要的功能点分析，包括：
将重要的功能点抽取出来进行详细说明，第一点准备怎么测第二点准备怎么测
测试活动描述：
1。测试计划（从研发转测试到发布上架的安排），哪个阶段投入大概多少人耗多少时间
2。测试活动范围说明：功能测试、界面测试、性能测试、安全测试、易用性测试、文档测试、升级测试。。。（要根据不同项目来规划不同的测试活动范围。同一类项目的测试活动范围相对固定，可以做个模板，每次就在各个测试活动中标记要不要测，要测成什么样，这样可以留底，可以进行自我梳理，接下来活动范围就很明确了）
软件及硬件环境说明：
1。硬件说明，根据软件的要求搭配的硬件信息搜集。包括这个软件支持在什么硬件上运行，对硬件的要求
2。软件说明，系统平台支持哪些平台，浏览器支持哪些类型哪些版本的浏览器，软件组网图是什么样子的（没有就网上下一个参考吧，其实一般厉害一点的研发，你去请教一下，给他纸和笔，他刷刷就能画给你个草图。像比较成熟的BS架构的，网上挺多的）
测试准入准出说明：
1。对入口材料进行规范：
a.需求文档要满足什么条件才准收（这条一般挺难实现的，看大环境吧，但是恰恰是这条能决定你将来一段时间是苦逼还是质检，需求人员们上点心吧）
b.研发转测包要满足什么条件才准收开展测试活动，一般做法是对着需求列表操作一遍没什么大问题就准入（这对需求列表要求比较高，测试都懂，有的列表真的靠不住）。或者测试提供签收用例，发出来给开发，签收的时候对着用例过一遍，都能跑起来就签收通过了。
2。上架标准
对上架标准进行说明，约定好你满足了上架标准就可以上架了，别到时候别赖账。上架标准是需要提前评审通过大家同意的。
1。测试活动得到保障的情况下（用例执行到位比如百分百执行，需求覆盖到位比如百分百覆盖），对缺陷的约束（比如严重致命问题一定要改好了才能发布）
质量规范要求：
这里是对整个版本中间的一些“代谢物”进行统计和规范
1。缺陷代码量比例：比如这个版本最终上架了，但是虽然修改点少，问题非常多，那这样的版本就会被怀疑质量不过关，我要对这块进行管控，修改代码和问题单数量要在一定比例范围内才行（这个应该是行业经验，其实挺难定的，很多小公司都不这么考量）
2。功能规模和用例的比例：多少规模的功能，就要响应产生多少规模的测试用例，测试用例太多那可能事先没评估功能到位，测试用例太少可能用例覆盖不全（这个危害我认为大一些，如果用例本身没有包含全，用例全部执行了也还是会漏掉）
3。用什么方式写用例说明和模板，用什么方式录缺陷的约定。
风险：可以对项目还可能产生的风险进行报备，比如硬件可能无法如期到位，比如人力资源不够