1.项目背景
项目名称：
用户：
测试版本：
2.测试目的
为了要找出错误，通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。保证整个软件开发过程是高质量的，同时满足用户指定的需求（功能、性能、安全性、兼容性）。
3.对象框架
4.标准
5.术语
软件测试：使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
硬件环境：指测试必需的服务器，客户端，网络连接设备，以及打印机扫描仪等辅助硬件设备所构成的环境。
软件环境：指被测软件运行时的操作系统，数据库及其他应用软件构成的环境。软件环境又可分为主测试环境和辅助测试环境。
验收测试：是软件产品交付用户正式使用前的最后一道工序。它是以用户为主的测试，软件开发和质量保证人员也应参加。
6.参考文献
7.受众、读者
受众、读者：主要针对项目经理，管理人员、测试工程师人员。
8.测试对象范围
9.测试环境
硬件设备
辅助工具：测试管理工具：禅道 版本控制工具：SVN
10.测试资源
PM:
TL：
小组人员分配：
| 角色 |
所推荐的最少资源 |
具体职责或注释 |
| 测试组长 |
进行管理监督。 职责： 提供技术指导 生成测试计划，测试方案 参与测试 |
|
| 配置管理员 |
确保测试环境得到管理和维护。 职责： 管理测试系统 管理VSS 授予和管理角色对测试系统的访问权 参与测试 |
|
| 文档管理员 |
确保测试文档得到管理和维护。 职责： 管理文档 维护文档 生成工作日志 参与测试 |
|
| 质量监督员 |
外派他组进行质量监督。 职责： 质量监督 参与测试 |
|
| 需求分析员 |
对文档需求调研及需求反馈的分析。 职责： 分析需求 参与测试 |
|
| 记录员 |
记录会议内容及各种组内信息。 职责： 记录会议内容 生成会议记录文档 参与测试 |
|
| 测试员 |
执行测试。 职责： 执行测试 记录结果 从错误中恢复（返测报告） 收集测试用例 生成缺陷报告 |
测试组长
进行管理监督。
职责：提供技术指导生成测试计划，测试方案
参与测试
配置管理员
确保测试环境得到管理和维护。
职责：管理测试系统
管理VSS授予和管理角色对测试系统的访问权
参与测试
文档管理员
确保测试文档得到管理和维护。
职责：
管理文档
维护文档
生成工作日志
参与测试
质量监督员
外派他组进行质量监督。
职责：质量监督
参与测试
需求分析员
对文档需求调研及需求反馈的分析。
职责：
分析需求
参与测试
记录员
记录会议内容及各种组内信息。
职责：
记录会议内容
生成会议记录文档
参与测试
测试员
执行测试。
职责：
执行测试
记录结果
从错误中恢复（返测报告）
收集测试用例
生成缺陷报告
11.测试策略
功能测试：
测试目标
系统提供的功能与需求或用户手册相符。
测试范围：
方法：
· 集成测试阶段主要针对所有主要的功能实现进行测试，系统测试阶段依据需求规格说明书逐项测试，验收测试阶段依据说明书逐项测试。
· 重要的功能应该投入更多的精力进行测试，并及时小结。
完成标准：
· 功能实现，且可以正确执行。
· 所发现的缺陷尽量解决，留下的问题已经进行相应的处理或提供其他的解决方法。
需考虑的特殊事项：
· 注意开发组可能的功能变化和需求变更。
· 注意其中一些重要功能是与实际效果相关，并不是简单的功能实现。
· 注意值域测试的提示信息。
12.业务测试
业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性。
13.功能测试检查项：
例子：
表单测试：必填项，提示信息，边界值，数据类型，字符长度，特殊字符
链接测试：风格，链接正确，导航文字描述，图片链接
图形测试：图片大小，位置，相关说明，字体，大小，颜色，背景等
表格：样式
内容测试：信息归类是否正确，显示位置，检索功能
浏览器测试：功能，风格显示等
14.常见错误类型：
页面链接和风格、相关性检查、按钮功能、字串长度、字串类型、重复提交、回退、上传下载、必填项、快捷键、刷新、信息重复、功能错误、功能遗漏、界面错误、外部数据库错误。
15.任务分配
16.文档管理
对各种文档进行管理，以及给不同角色的人（项目经理、开发人员、测试人员）设置不同的权限；以下文档模板：会议记录、工作日志参考附件。
17.用例管理
测试用例是为实施一次测试而向被测系统提供输入数据、操作或各种环境设置；它来源于测试需求。是对测试需求的一个细化，它是整个测试的基础。
测试用例的优先级别
1.小版本确认测试（BVTs）：一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。
2.高：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
3.中：这是使给出的功能区域或功能变得更详细，检查功能的多数方面。
4.低：通常最少被执行的测试用例，们在项目的生命期间里不是常常被运行。
测试用例的元素：5W1H
1.测试目标：Why—为什么而测试？功能 、可用性、安全性等。
2.测试对象：What—测试什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等；
3.测试环境：Where—在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议 等单机或网络环境。
4.测试前提：When—什么时候可以测？测试用例运行时所处的前提或条件限制。
5.输入数据：Which—那些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。
6.操作步骤：How——如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等
测试用例模板参考附录
18.缺陷管理
缺陷报告用于记录缺陷，对缺陷进行分类，为解决不同的缺陷分配合理的资源，并通过缺陷报告对处理缺陷的过程进行跟踪，从而使软件缺陷得以修复。
缺陷报告包括的元素：缺陷标题、复现缺陷的操作步骤、缺陷的实际结果、缺陷的预期结果、缺陷的优先级别、缺陷的严重程度、缺陷的基本信息、缺陷的类型、测试的软件和硬件环境、测试的软件版本、注释文字和截的缺陷图像。
缺陷严重程度
（1）致命性错误：数据丢失、数据传递错误，造成操作系统或其他支撑系统崩溃、应用系统崩溃，非正常关闭和非正常死机。
（2）严重性错误：规定的主要功能没有实现或不完整；设计不合理造成性能低下。
（3）一般性错误：不影响业务运行的功能问题。
修改优先级：
P1：立刻修复；
P2：如果时间允许就修复；
P3：可以在将来的某个版本修复；
P4：推迟修复；
P5：不进行修复。
缺陷报告模板参考附录
19.风险控制
系统风险
需求或设计的变更未及时通知。
需求不明确可能导致开发的产品与目标不一致。
影响计划的潜在因素
在测试计划执行过程中，可能存在以下因素影响计划的按时完成：
时间紧迫，任务繁重；
测试人员对的熟悉进度慢；
测试人员对被测试产品不够熟悉，对测试工具的使用熟悉程序不够；
被测试产品存在重大错误，以致于测试无法继续；
测试资源未及时到位（设备和人员）；
硬件、软件或网络环境出现故障等；
测试人员获取的需求与开发人员产生分歧；
测试人员与开发人员的协调与沟通。
应急措施
如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。
测试的局限性
系统硬件配置存在不可预测的问题；
测试范围不能覆盖所有的可能情况；
测试时间的限制；
测试数据可能不全面；
测试工具自身的缺陷；
测试人员的失误。
20.质量评估标准
测试模块通过标准
测试项的通过标准目前定义为：当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，则认为此项测试通过。
验收测试通过标准
验收测试的通过标准目前定义为：对于每一类测试，当没有发现致命性错误和严重性错误，一般性错误数量小于测试用例总数的5%，则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。
21.关键里程碑
里程碑任务
日期
输出结果
需求分析
需求分析报告
完成测试计划
测试计划
编写测试用例
测试用例
测试用例评审
功能测试
执行用例、缺陷报告
缺陷报告
项目测试总结
测试总结
22.附录及其他
联系方式
会议记录模板
测试用例模版
工作日志模板
缺陷报告模版