测试流程及规范标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]1目的侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。
测试技术和策略等问题不在本文档描述范围内。
本规范作为所有测试组成员工作前必须掌握的工作规范，也供给其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发工作。
2概念与术语在整个产品的研发过程中，测试类型按照先后顺序主要分为：单元测试、集成测试、系统测试及产品确认，整个过程如下面的W模型所示：公司研发流程的实际情况，此测试也可由设计研发人员执行。
2）集成测试是验证模块间接口及匹配关系，测试依据主要为概要设计。
一般采用自底向上或自顶向下的模块集成方法，逐步集成。
在此环节中测试组还负责验收研发人员提供的转测试的材料，如果材料不完备，测试组可以拒绝接收。
3）系统测试是对系统的一系列的整体、有效性、可靠性的测试，测试依据主要为设计规格及产品需求规格。
目的是确认产品与设计规格、需求、行业标准及公司标准的符合性，同时还要确认性能和系统的稳定性，与之前的集成测试应遵循“相同的被测对象不要做两遍相同的测试”的基本原则。
4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理，保证产品质量，提高客户满意度。
确认与实验室内部测试的区别在于：实验室内部测试要尽可能多做，多发现问题；确认要在达到质量目标的情况下尽可能少做；两者要在质量和成本之间权衡、综合考虑。
5）TD：全称Mercury TestDirector，一种测试管理工具。
6）黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。
3职责组建测试小组协调测试小组内外部的沟通组织编制测试大纲（含测试用例）和计划组织测试准入检查测试过程中的进度控制、风险管理测试过程报告编写测试报告召集测试评审识别测试需求参与编制测试大纲（含测试用例）和计划协助测试准入检查执行测试用例，测试结果记录测试缺陷记录与跟踪协助测试评审为测试工作提供技术支持，比如环境安装、版本布署、测试工具支持等备注：该角色可选，可根据项目实际情况设置，一般情况下由研发人员担任。
【注】：当某个项目仅有一个测试人员时，该测试人员同时也为该项目内的测试主管，需要担负起测试主管的职责。
4测试类型和测试方法4.1测试类型测试工作通常分为4个类型，功能测试、联合测试、性能测试及稳定性测试。
确保功能符合需求定义确保所有功能可以正常完成工作一个新产品或一个产品的新版本发布时，要确保与之相配合的产品可以正常配合使用在产品有性能要求的部分，进行性能测试和调优，确保产品性能符合需求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行4.2测试方法以手工黑盒测试为主，手工执行功能测试用例。
正规测试和随机测试相结合：根据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写的不全面，所以在进行常规测试过程中，可以加入随机测试。
同时，对预测试出来的缺陷，将其执行过程写成一个测试用例，添加到测试用例集合中，以完善测试用例；采用测试工具TD进行测试用例的管理和缺陷记录、跟踪。
性能测试要求满足两种情况：1）产品在特定工况下可以达到的最高性能（例如：测试时将日志等影响性能的选项关闭）；2）模拟用户真正的使用环境（如：日志功能打开，在一定的用户数量的情况下），产品真实可以达到的性能；稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行【注】：黑盒测试过程的参考准则：（1）必须采用边界值分析法；（2）必要时采用等价类划分法补充测试用例；（3）采用错误判断法，追加测试用例；（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。
如果没有达到要求的覆盖标准，应当补充更多的测试用例；（5）测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证；5工作流程、模式及规范5.1测试提交文件及裁剪说明5.2评审点评审点定义参照《设计开发控制程序》。
5.3敏捷测试模式5.3.1敏捷测试概念敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
5.3.2敏捷增量测试方法测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。
整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，验证测试和系统测试。
验证测试：静态测试和关键的功能测试。
系统测试：功能测试、联合测试、性能测试、稳定性测试。
5.3.3敏捷测试流程敏捷测试流程依据业务场景制定测试策略。
在每次敏捷测试的过程中包括验证测试和联合测试。
并且不断的进行迭代测试。
在系统的所有业务场景都经过敏捷测试过后，进入系统测试阶段。
进行所有业务场景的功能测试、联合测试、性能测试、稳定性测试。
根据业务场景制定测试策略流程图产品业务场景业务场景。
业务场景模块一 模块二 模块三 。
模块N模块四 业务场景缺陷管理 业务场景业务场景业务场景业务场景敏捷测试流程图根据缺陷性质来判断更新提交测试的依据：1）严重级别为Urgent和High的修改后立即更新，要保证更新后不能影响其他功能测试。
2）功能级别为Medium以下的可以等待下一次提交敏捷测试的时候更新。
5.4传统瀑布模式5.4.1测试需求分析5.4.2成立测试小组或确认测试人员确认项目的测试人员，若整个项目的测试需要若干个测试人员，则需要成立一个测试小组；为测试小组任命一名测试主管，若只有一个测试人员，则该测试人员同时也为该测试组的测试主管，同时确定测试小组的其它构成人选；小组内进行必要的培训。
若以前的测试任务已成立过测试小组，则可以复用以前的组织人员和形式5.4.3编制测试计划测试大纲至少包括以下关键内容：测试目标——对本次测试的要求和要达到的目标测试范围——需要测试小组测试的范围，和各个测试需求的测试优先级工作分工——明确测试小组内部及外部配合方的相关责任和工作关系测试策略——整体测试的总体测试策略、环境、方法和工具等完成标准——达到何种条件可以认为测试完成交付文件——测试完成时应提交的文件，比如测试大纲（含测试用例）、测试报告等等测试计划至少应包括以下关键内容：主要任务——每项任务的时间计划、前置条件及资源主要里程碑——关键任务及完成时间点在项目研发过程中，要适时的对测试计划进行跟踪，以评估此计划的完整性、可行性，在项目结束时还要最后评估一下测试计划的质量对于多个系统参与的同一个测试任务，可由主项目组或牵头方统一编制测试大纲和计划，不用每个系统单独编制和出具测试计划可以在测试大纲中直接详细列明，而不用单独编制5.4.4编制测试大纲、设计测试用例在技术规格书评审通过以后，测试小组需要针对项目的测试范围编制测试大纲、设计测试用例。
在实际测试过程中，测试用例可根据实际需要进行更新和调整。
在测试用例的设计过程中，具体的任务和责任人如下：准备本次测试的测试用例测试用例在该产品的测试用例库中进行选择，如有需要，可以进行增加；每个测试用例须包括用例编号、测试概述、测试数据、操作步骤说明、预期结果等要素；测试用例须覆盖所有的测试需求和功能点；采用统一的模板进行用例设计。
5.5测试实施阶段5.5.1测试准入检查测试主管根据本项目的特点，事先确定测试准入标准中哪些条目可以进行裁剪，并与项目经理及研发人员商讨确认准入标准中“计划准入标准”是指编制测试计划、测试大纲、测试用例设计时就需要具备的前提条件，应提前进行检查；“执行准入标准”是指在执行测试之前需要进行的检查。
以上两类检查应分两次进行测试主管和测试人员根据测试准入标准，逐项进行检查，并填写测试准入检查表对于不满足条件的检查项，要求相关方面进行解决，解决后重新进行检查必须要通过的检查项，而没检查通过的，视为准入检查不通过，不能进入下一阶段工作5.5.2执行测试用例测试人员根据计划，执行相应的测试用例，并做好测试记录测试人员进行缺陷登记，并跟踪解决情况，及时复测，关闭缺陷测试主管跟踪测试用例执行情况，了解影响测试用例执行的因素，及时跟进有关的协调、报告测试状态测试主管根据项目的情况，选择有关的报告形式，将测试进展情况及时通报5.5.3回归测试在每轮测试结束之后，当研发人员解决完相关问题，重新提交，进行回归测试。
5.5.4缺陷管理测试人员在测试过程中，记录被测产品缺陷，跟踪缺陷的分析、解决过程研发人员及时分析处理缺陷，并按要求记录缺陷的分析处理信息，更新缺陷状态，填制缺陷起源；对需要其它人员参与分析处理的时候，需及时将缺陷分配给下一环节人员测试人员对待验证的缺陷需及时进行复测，测试通过后关闭缺陷5.6测试收尾阶段测试实施阶段结束或即将结束时，测试小组可以开始着手准备进行总结报告及收尾工作。
5.6.1编制测试报告在测试实施完成之后，测试主管或测试人员需根据实施测试情况，编制测试报告。
测试主管或测试人员根据测试的结果，按照测试报告的文档模板编写测试报告，测试报告必须包含以下重要内容：测试用例执行情况分析――测试阶段用例执行的数量、轮次、通过率等测试过程中已发现缺陷分析――分析缺陷的数量、分布、起源等未执行用例的风险分析――分析未执行的用例对系统形成的风险未关闭缺陷的风险分析――分析未关闭的缺陷对系统形成的风险测试结论――评价测试大纲中定义的测试完成标准是否达到，被测系统的质量评价，存在的风险，以及有关建议5.6.2测试工作过程改进测试过程改进在测试实施阶段工作全部结束以后进行。
它的目的是评估本次测试工作，总结经验，使下一次的工作做得更好。
本项工作不是一个必须的过程，各项目可根据情况采用。
测试主管召集测试参与人员，讨论本次测试过程得与失，总结经验，提出改进方法和意见编写测试工作过程改进报告5.6.3测试成果提交测试资产提交在测试实施阶段工作结束以后进行，对测试过程中涉及到各种标准文档进行归类，存档。
5.7软件测试执行模式目前采用3+1模式。
即三轮系统测试加一轮回归测试。
6缺陷管理机制缺陷通过测试管理工具TD进行管理测试团队研发团队缺陷的严重级别以及如何分类7新产品测试流程7.1新产品测试输入输出7.2新产品测试流程图8生产缺陷测试流程8.1生产缺陷测试输入和输出8.2生产缺陷测试流程图9新增和修改需求测试流程9.1新增和修改需求测试输入和输出9.2新增和修改需求测试流程图10发布评估标准检验合格依据:遗留问题中不能有Urgent、High级别的问题；遗留问题中Medium级别的问题数要小于等于8，并且经过研发、测试及产品经理讨论一致同意。