1. 目的
制定完整且具体的测试线路和流程，为快速、高效高质量的软件测试提供流程框架，实现软件测试的规范化、流程化及标准化。
2. 适用范围
适用于公司常规软件的测试管理工作。
3. 主要职责
3.1 开发设计部门：负责按照需求编制开发计划执行软件开发。
3.2 测试部门：负责按照需求编制测试几乎并执行测试任务。
4. 定义
4.1 BUG状态定义：New:（新的）；Assigned（已指派的）；Open（打开的）；Fixed（已修复的）；Pending Reset（待在测试的）；Reset(再测试)；Closed（已关闭的）；Reopen（再次打开的）；Pending Reject（拒绝中）；Rejected(被拒绝的)；Postponed（延期）。
4.2 致命BUG:造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
4.3 严重BUG：系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，以及功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启，自动退出，关联程序间调用冲突，安全问题、稳定性等；
4.4 一般BUG：功能没有完全实现但不影响使用，功能菜单存在缺陷但不影响系统稳定性；
4.5 建议BUG：界面，性能缺陷，建议类问题，不影响操作功能的执行等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。
5. 流程
5.1 文件执行流程
5.2 测试执行流程
6. 内容及要求
6.1 需求收集
软件设计开发部门在接收到客户需求后，根据合同协议要求获取客户提供的《需求规格说明书》、《详细设计内容》、《概要设计》及界面原型图等资料。测试需求是制定测试计划的基本依据，只有确定了测试需求才能为测试计划提供客观依据；是设计测试用例的指导，只有确定了要测什么、需要测哪些方面，才能有针对性的设计测试用例；是计算测试覆盖的分母，没有测试需求就无法有效的进行测试覆盖。
6.2 需求分析
开发部门在拿到相关需求资料之后，进行需求分析。分析开发人员功能实现的可行性情况。
6.3 需求沟通
6.3.1 开发部门组织安排测试部门进行需求沟通分析，确保测试人员理解需求及解答疑问，以便根据需求编写测试用例。
6.3.2 开发人员根据需求中的功能点，进行软件开发排期，制定《开发计划》，然后发送参与项目的所有人员进行评审。
6.3.3 测试部门负责人依据需求、开发设计部门的《开发计划》及公司资源实际情况进行分析，编制相应的《测试方案》，测试方案得到管理层许可后，分配任务给部门测试人员，相关测试人员针对《开发计划》的完成时间节点，相应的进行测试计划排期，制定合适的《测试计划》，然后发送给参与项目的所有人员进行评审。
6.3.4 待《开发计划》与《测试计划》评审通过后，确定项目可执行后，各部门人员按照计划执行项目启动。
6.4 软件开发
6.4.1 开发人员按照《开发计划》要求，进行软件开发。
6.4.2 程序自测：开发人员在完成某一节点所有功能后，对自己的功能进行一个自测，自测完成后提交给测试人员进行基线。
6.5 软件测试
6.5.1 编写测试用例：
测试人员按照《测试计划》要求及程序需求文档，执行《测试用例》的编写，完成后，测试人员将用例发送给相关人员，以便他们了解用例将对哪些功能进行验证以及验证的细节情况实施用例的评审，参与人员需要对用例中与实际功能不符合的地方或格式不规范的地方提出修正意见，直至用例通过各方评审无异议。
6.5.2 转测：
1）测试人员接收到开发人员提交的基线后，对基线进行审核，审核不通过的话打回给开发人员返工，若审核通过，测试人员开始执行第一轮系统测试。
2）第一轮系统转测试，测试组会执行所有测试用例，发现缺陷提交问题单，并按期汇报测试进度。第一轮测试结束后，测试组将所有的问题单提交给开发人员进行修改，并跟踪实际修改情况。
3）进行基线后的第二轮测试，第二轮测试会对第一轮测试中发现的问题进行重点回归。
4）在开发修复BUG期间，测试组会根据第一轮系统测试对测试组的测试用例进行修改和增加，开发修改BUG结束，提交一个新的版本给测试组。首先是回归缺陷，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问题继续提交缺陷进行修复，知道缺陷率低于用户要求，测试组将进行最后一轮大版本测试，结束系统测试，具体测试轮次根据版本质量和项目复杂程度而决定。
5）经过几轮的测试后，直到没有发现新的问题，或只存在暂时无法解决、不紧急重要的问题，通过上级确认，可以让测试通过，开始编写测试报告。
6.5.3 编写测试报告：
软件测试通过后，测试人员编写《测试报告》，测试报告包括对软件功能的结论，说明该项目软件的开发是否达到预定目标，是否可以交付使用。总结测试工作的资源消耗数据：如工作人员的水平级别数量、机时消耗等，记录测试结果与发现及本项目测试工作所得到的各项输出的承载体，根据输入与计划、要求的对比来总结此次项目所获得的经验。
6.6 BUG的管理要求
6.6.1 bug的生命周期及状态实时更新，bug包含的内容：包含了所属项目，所属模块，版本，指派给相应的人员，BUG标题，步骤，优先级，以及bug环境、附件（可以附上出现的缺陷截图）等。
6.6.2 开发、测试双方有争议的bug，必须与产品确认才可进行下一步的操作；测试需及时验证已修复bug；谁提交的bug要由谁验证关闭。
6.7 测试输出文档的基本要求：
6.7.1 《测试计划》应包含而不限于以下内容：
1）引言：目的、背景、范围、定义、参考资料；
2）测试内容：测试功能清单；
3)测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具；
4)测试环境：硬件环境、软件环境、特定测试环境要求；
5)项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结；
6)实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件；
7)风险管理。
6.7.2 《测试方案》应包含而不限于以下内容：
1）项目简介：概括的对这个系统做一个描述，让别人知道系统是做什么的，简洁而有重点；
2）测试目标：对于本次系统测试要达到什么样的标准，缺陷率应该控制在多少以内，定一个合理的目标；
3）测试策略：这个部分主要包括（1）数据流图描述；（2）本项目测试难点；（3）本项目测试的关键点；（4）需要特别申请的测试资源；（5）性能测试；
4）测试的内容和方法：这部分主要包括：（1）场景测试；（2）功能测试；（3）功能模块衔接测试；（4）接口测试；（5）界面测试；（6）兼容性测试；（7）性能测试；（8）兼容性测试；（9）安全性测试；（10）可靠性测试。
5）测试数据：包括（1）系统参数；（2）存量环境数据；（3）业务参数；（4）交易参数；（5）接口文本数据；
6）测试环境：（1）各应用测试环境的版本基础；（2）测试环境硬件要求；（3）测试环境连接图；
7）测试工具及其模拟器：根据项目实际是否使用
8）测试人员安排：
9）测试计划：（1）主要工作安排；（2）测试轮次安排；（3）批量计划；
10）人力资源评估；
11）风险及依赖。
6.7.3 《测试用例》应包含而不限于以下内容：
1）内容：包括用例编号、测试项目、测试标题、预置条件、测试输入、测试步骤、预期结果、实际结果等。
2）用例级别划分：对测试用例进行优先级的划分，一般需要从三个方面考虑：
P1：确保系统基本功能及主要功能的测试用例
P2：确保系统功能的完善方面的测试用例
P3：关于用户体验，输入输出的验证以及其他较少使用或辅助功能的测试用例对应的，我们可以对测试用例分为三个级别：高、中、低
高（优先执行）：即关键路径的测试用例，包括最常执行的功能、基本流程的输入以及界面数据有效性校验作为高级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件功能渐趋稳定；
中（次级执行）：即可接收级测试的用例，包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件可以进行发布了；
低（最后执行）：即建议执行的测试用例，也就是说该级别的测试用例不是不重要，而是该级别的用例在整个项目的生命周期内不是常常被运行，包括：GUI、界面显示、错误信息提示不统一、可用性、压力和性能测试等。
6.7.4 《测试报告》应包含而不限于以下内容：
1）概述：一般会在概述中添加项目背景、需求描述等信息；
2） 测试过程：主要包含评审记录、测试范围、测试用例；
3）功能实现清单：列出是否已按本次测试计划实现功能；
4）测试统计：包括资源统计、执行情况、问题统计、问题列表、遗留问题；
5）测试总结：主要总结本次测试测了哪些内容、用例覆盖程度、bug解决程度等，以及最终是否决定通过本次测试。
7. 引用文件
7.1 《需求规格说明书》
7.2 《详细设计内容》
7.3 《概要设计》
7.4 《合同》/《技术协议》等
8. 记录
8.1 《开发计划》
8.2 《测试方案》
8.3 《测试计划》
8.4 《测试用例》
8.5 《测试报告》