测试工作规范

文件编号：生效日期：受控编号：当前版本：当前状态：发布日期：编制人：审核人：批准人：修订记录日期修订版本描述作者2023-05-11V0.1新建 目录一、概述 41.1目的 41.2内容 4二、职责 52.1工作职责 52.2岗位职责 52.2.1软件测试工程师 52.2.2硬件测试工程师 62.2.3临床测试工程师 6三、工作目标 83.1测试的重要维度 83.2测试活动 83.3非测试活动 93.4测试目标 103.4.1核心目标 103.4.2其他目标 103.4.3阶段目标 103.5非测试目标 11四、工作流程 124.1测试阶段 124.2测试工作流程 134.2.1测试申请 134.2.2测试准备 144.2.3测试设计 144.2.4测试实施 154.2.5缺陷管理 184.2.6回归验证 204.2.7测试验收 204.2.8测试总结 214.3测试依据 224.4通过标准 224.5停止标准 224.6例外放行 24五、测试相关文档 255.1 测试计划 255.2 测试方案 255.3 测试用例 265.4 缺陷列表 275.5 测试报告 29六、日常工作规范 306.1工作任务 306.2输入输出 306.3协作要求 31七、测试过程管理 337.1测试文档 337.1.1测试文档管理 337.1.2编号规则 337.2缺陷处理 357.3过程控制 357.4测试版本管理 357.5测试报告 35八、文档管理规范 378.1文档模板 378.2文档管理 378.3文档维护 37九、责任追溯 38十、工作汇报 39十一、附件 40十二、其他 41

一、概述1.1目的该文档作为测试组各项工作的指导与部门成员工作的参照执行标准，针对测试团队的日常工作规范，主要包括测试流程、测试结果、测试文档的输出。确保测试工作流程的控制，明确项目的各阶段测试团队应完成的工作。工作实践过程中，由部门成员不断改进优化，使工作明确、有序、高效进行，使与其他各部门更好的协作，做好产品的质量控制与质量保证。1.2内容该文档明确规定了测试组的工作职责、工作目标、工作流程、文档管理规范、日常工作规范、责任追溯与工作汇报等内容。

二、职责2.1工作职责测试组同时承担有以下工作职责：1、协助研发与项目团队高质量完成产品研发，以节省开发成本；2、参与各阶段工作，对阶段成果进行测试，以保证阶段目标的达成；3、发布前进行缺陷查找和定位，发现尽可能多的缺陷，以节省维护成本，保证用户信心；4、编写测试计划、测试方案、测试用例，在尽量真实的环境下保证高覆盖度的测试，以节省运维成本；5、进行缺陷跟踪与分析，查找和监控存在的问题，推进项目质量和管理质量的提升；6、正确评价测试对象的质量现状，确定实际与预期目标的差距；7、对工作资源与成果进行管理、维护（输入、输出、交互文档、测试版本、缺陷记录等资源）。2.2岗位职责2.2.1软件测试工程师按照测试计划负责产品软件部分的测试工作及相关文档的撰写。1、编写测试用例，利用测试工具进行软件测试及管理，对测试结果进行分析；2、负责软件测试报告的撰写和测试问题的跟踪；3、协同软件工程师，完成软件设计部分的不良分析和版本故障跟踪；4、参与软件早期设计检视，保证软件可测试性需求；5、按时按质完成上级交办的其他工作。2.2.2硬件测试工程师按照测试计划负责产品硬件部分的测试工作及相关文档的撰写。1、编写测试用例并执行，对测试结果进行分析；2、负责硬件测试报告的撰写和测试问题的跟踪；3、协同硬件工程师，完成硬件设计部分的不良分析和版本故障跟踪；4、参与硬件早期设计检视，保证硬件可测试性需求；5、负责新元器件测试及承担EMC（电磁兼容性）、可靠性测试等工作；6、负责测试工装、测试仪器、测试仪表及测试设备的维护工作；7、按时按质完成上级交办的其他工作。2.2.3临床测试工程师按照测试计划负责产品临床性能参数部分的测试工作及相关文档的撰写。1、编写测试用例并执行，对测试结果进行分析；2、负责临床测试报告的撰写和测试问题的跟踪；3、协同开发工程师，完成设计部分的不良分析和版本故障跟踪；4、参与设备早期设计检视，保证设备可测试性需求；5、负责设备临床性能指标验证工作；6、负责产品临床评价咨询、产品注册、产品技术要求和说明书的编写；7、按时按质完成上级交办的其他工作。

三、工作目标3.1测试的重要维度测试时间、测试成本和测试质量构成测试过程中需要关注的三个重要维度，三个维度相互制约、相互影响。在测试中，永远无法实现时间、成本和质量的三赢，为其中任何2个目标所做的努力，都必须以付出第三个目标的损失为代价，此外我们永远都不可能穷尽所有的测试内容，因此必须综合权衡作出取舍。3.2测试活动测试组的测试活动如下：1、计划和控制；2、提取测试需求、选择测试环境和条件；3、设计测试用例；4、实施和执行各阶段的测试；5、检查测试结果；6、评估出口准则；7、报告测试过程及被测系统；8、总结各阶段的测试工作；9、为进入下一开发过程，或将系统交付给用户，测试组提供质量评估等足够的信息，帮助利益相关者决定是否发布。3.3非测试活动测试组的非测试活动如下：1、部门日常工作；2、部门工作文档管理；3、部门团队管理工作；4、部门工作成果管理；5、部门工作结果汇报；6、部门团队成员技能提升；7、协助其他部门完成非测试工作任务。根据公司领导、部门经理的管理要求和工作目标，有效、规范、高效的非测试活动将有助于推动测试活动高质量的完成，达成工作目标，实现团队效益。3.4测试目标3.4.1核心目标总体来说，测试组的核心目标是：通过对被测对象的源代码、程序、文档，进行静态分析、评审和执行动态测试，以提供信息来改进被测对象的质量，以及改善开发和测试的过程质量。3.4.2其他目标1、发现缺陷；2、增加对质量的信心；3、为决策者提供信息；4、预防缺陷。3.4.3阶段目标1、需求分析的过程中对需求文档测试，主要目标是识别和解决问题，避免将缺陷引入设计和代码；2、早期进行测试设计的过程中，主要目标是检测测试依据，避免将缺陷引入代码；3、开发和测试中（如单元测试），主要目标是尽可能的发现bug，从而识别和修正尽可能多的缺陷；4、系统测试中，主要目标是为了评估系统的特征，比如可靠性、可用性、安全性等；5、验收测试中，主要目标是确认系统是否按照预期工作，是建立满足需求的信心；6、发布测试中，主要目标是对软件质量进行评估，从而为利益相关者提供信息：在给定时间点发布或可能存在的风险；7、维护测试中，主要目标是验证在开发过程中的软件变更是否引入新的缺陷。3.5非测试目标1、规范工作流程，采用合理的工作方式，有序的推进工作；2、高质量完成工作任务，达成工作目标；3、建设高效能的团队组织；4、实现团队价值，提升各成员素质；5、营造良好的工作氛围。

四、工作流程4.1测试阶段产品或项目的实现，在公司内分为多个阶段进行：立项、需求、计划、设计、实施、测试、确认、发布。其中，测试阶段的工作主要由测试组的测试活动完成。其他各阶段，主要由研发中心完成，测试组会参与各个阶段，根据各项目的实际情况参与度不同。需要明确的是，非测试活动测试部门至少参与评审，且评审意见应得到重视。在产品或项目的各阶段，测试组的测试活动与研发中心的工作并行开展。4.2测试工作流程4.2.1测试申请开发组向测试负责人提交《测试申请表》，该文档主要说明：申请测试人员数量、进行哪些阶段的测试、需要提交哪些测试文档、测试周期及测试环境要求。（1）研发应当提交详尽可用的文档，包括但不限于历史版本、当前版本、功能修改详细信息、需求变更详细信息以及期望任务完成时间等；（2）所交付的测试任务需具备可测试性。若配套的客户端程序、终端机固件、服务器程序等均进行了改动，交付测试任务时需配套交付；（3）由测试经理对所有交付的测试任务进行过滤，对不符合测试交付条件的测试任务进行拒绝、协调和反馈。4.2.2测试准备在技术实现编码阶段的工作结束时，进入产品的测试准备阶段，为真正开展产品测试做好前期准备工作。（1）制定测试计划和测试方案；（2）组织协调测试人员；根据测试计划和测试方案，组织协调相关测试人员，形成测试工作组。（3）测试人员的培训；正式开展测试工作之前，对所有测试人员进行测试工作的集中培训。通过测试培训，使测试人员明确测试目标和要求、了解待测系统、统一测试方法和流程，保质保量的开展和进行测试工作。（4）测试所需硬件设施和其他准备工作；与相关部门联系协调对接测试工作所需的设施：服务器、测试机等在测试准备阶段全部到位。4.2.3测试设计测试组负责人可以要求研发中心为测试预留足够的时间。在整体计划定稿后，测试人员开始编写合理的计划方案、搭建符合用户的测试环境、撰写和设计测试用例、准备测试资源。测试计划、测试方案、测试用例设计均需进行评审。测试组内部评审后，交于研发中心评审。产品线经理负责明确重要功能、逻辑复杂度高的功能，并基于架构设计和代码层面指出计划、用例、环境的不足之处，测试组采纳合理意见。测试设计应兼顾阶段性成果测试的规划。提倡尽早测试，阶段交付，以便分散压力、工作量和风险。4.2.4测试实施测试实施是软件测试工作的核心阶段，测试实施阶段严格按照测试计划和测试方案展开。（1）搭建测试环境根据产品的实际需要搭建运行环境及准备相关测试所需初始数据，包括：测试人员、测试工具等。搭建测试环境，需要尽可能与客户使用环境一致，如果实难满足，差距较大，应对不同环境下，存在的各种隐患及风险进行分析并备案，在质量评估报告中注明。（2）冒烟测试满足以下条件，测试人员进行冒烟测试：必须提供资料：任务单、测试版本、测试标准、修改说明；测试标准必须是需求规格说明书或其他文档形式的标准；修改说明必须包含5个信息：历史版本号、当前版本号、修改功能、修改原因、影响点；必须说明期望测试任务完成的时间、测试要求、环境配置、重点关注内容；本次测试任务相关的最近一次测试中提交了bug，bug需被全部修改；测试版本必须保证功能是可测的；当安装卸载正常、可测试的功能达到80%以上时，才认为该版本的功能是可测的。除非有特殊理由，否则，不满足以上条件测试组将拒绝该测试任务，并由测试组负责人回复邮件说明原因。待研发中心修改后，再提交。（3）测试执行冒烟测试通过，正式执行测试。测试执行过程中，测试人员要注意以下几点：测试人员对测试版本进行确认并记录；测试人员要及时记录发现的缺陷，并在每日下班前对缺陷进行整理；研发人员要即时对测试人员提交的缺陷进行查阅，并且最迟在次日修改缺陷状态并给出详尽说明；测试完结后，测试组需要提交对应的书面文档，上交测试记录、测试结果或测试报告；测试人员应尽力定位bug产生的原因。如遇到重要、可复现性低的问题，应及时与研发人员联系，进行联调，现场定位原因。此类问题，应使测试组负责人知晓，且如有需要，由测试组负责人出面协调。若是正式测试，每一轮测试，测试人员应将计划的测试用例完整执行一遍。测试发现的bug提交至缺陷管理工具上，研发人员进行查阅并修改。原则上，研发需修改完所有bug，才可提供完整包进行下一轮的测试。在下一轮测试开启前，允许研发提交新版本进行bug验证，bug验证通过后，需重新打包提交进行下一轮测试。每一轮测试结束后，测试组需提交阶段性的测试报告。（4）用例维护用例维护是指测试过程中根据每项测试结果，发现先前的测试用例不合理之处并对其进行相应的调整和改正。先前的测试用例设计不全面或者不够准确，随着测试过程的深入和对产品功能特性的更好理解，发现测试用例存在一些逻辑错误需要及时更新；所发现的、严重的软件缺陷没有被目前的测试用例所覆盖，需要及时更新；新的版本中添加新功能或者原有功能的修改，要求测试用例做相应改动；测试用例不规范或者描述语句的错误；旧的测试用例已经不再使用，需要删除。（5）需求维护需求维护是指测试过程中根据每项测试结果，发现前期需求不合理之处并对其进行相应的调整和改正。需求维护工作贯穿整个测试过程。4.2.5缺陷管理提交缺陷的测试人员，需对缺陷进行跟踪直至缺陷被修复。测试人员有责任协助研发人员解决问题，并在问题修改后进行验证。为了保证缺陷的有效性：（1）测试一旦开启，在未结束前，不得更新测试版本；（2）原则上，现有缺陷全部修改后方可提交验证；（3）定期清理缺陷，关闭过期未处理和无效缺陷。由测试组负责人决定，哪些阶段需要对缺陷进行分析，以此评判工作中暴露的问题，以便及时更正。被拒绝修改的缺陷，由测试组负责人决定是否可以不作修改。如同意不改则责任追溯时，测试组负责人需承担责任。缺陷按其严重程度分为4个等级，如下：等级程度具体描述1致命阻碍开发、测试工作；造成系统崩溃、死机、数据丢失；主要功能、基本模块丢失、一级菜单不能使用2严重功能设计与需求严重不符；数据数值计算出错；程序接口调用出错；错误的波及面广，影响到其他重要功能正常实现；非常规操作导致的程序崩溃、死机、死循环；外观难以接受的缺陷3一般功能未实现但不影响使用；操作时间较长；数据错误显示；操作界面错误；输入限制4建议页面建议性问题不影响正常使用；用户体验感不好；界面显示不美观；辅助说明描述不清楚；界面存在文字错误4.2.6回归验证待回归的bug：（1）说清楚bug产生的原因；（2）必须要有详细的定位信息、在哪个版本中修改、测试建议、影响范围；（3）定位修改信息包括：修改了哪里，会影响到哪里；（4）不予解决、设计如此、延期处理的bug一定要有详细且合理的原因，此类bug需经评审再决定是否关闭。回归bug：（1）注明bug回归时间；（2）注明bug回归版本；（3）注明bug回归步骤，若引发了新的bug并提交新的bug单后，在此处注明单号；（4）若开发在定位修改中写得不详细，经过沟通之后才了解，在此处写上对开发定位信息的详细补充；（5）对回归通过的bug进行关闭，否则重新打开，并备注重新打开的理由。4.2.7测试验收测试验收阶段的主要工作是：以客户使用的角度，再次确认系统的可操作性、正确性、全面性和完整性，为产品的上线应用、推广营销最后把关。测试验收阶段依旧沿袭测试实施阶段使用到的各种测试形式和方法，依据测试实施阶段产生的测试问题报告单、测试用例单、阶段性测试总结等各种文档和资料展开。4.2.8测试总结测试总结阶段是测试工作的最后一个阶段，要进行以下四项工作：（1）总结对测试阶段工作完成情况、工作方法进行总结。一方面总结好的方法和经验用于指导将来的测试工作；另一方面发现不足需改进之处引起借鉴，并在今后的工作中加以避免。（2）汇总分析对测试验收阶段的遗留问题进行汇总、统计和分析，并提出解决和修改建议。（3）整理文档包括：产品设计说明书、产品培训教材、产品操作手册、用户使用说明书以及测试阶段生成的各种文档资料。（4）编写测试报告把测试的过程和结果写成文档，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。4.3测试依据1、需求规格说明书或需求变更说明；；如有例外的要求，需要列入需求变更或变更后的需求规格说明书，一同作为测试的标准。如果是临时任务，需要将标准列入任务单，作为测试的标准；2、详细设计文档；一定要认真阅读开发详细设计文档，真正弄懂系统需求及设计思路；3、开发交付的修改说明文档；测试范围为修改或变更的点及与其相关联的功能；4、各项工作规范及工作流程图；参照工作流程图，有序开展工作。5、行业标准和惯例；引用行业标准和惯例的时候，需要测试人员有足够的经验。大部分情况没有需求支持，则会用现存的成熟标准来实现测试。4.4通过标准1、被测版本满足需求原型；

2、评审通过的用例覆盖率达到100%，所有测试用例均执行通过；

3、所有遗留问题都已有解决方案（延期解决/暂不解决/需求优化/挂起）；4、性能指标达到要求，验收测试满足预期。4.5停止标准停止标准规定了测试工作在满足何种条件时停止测试。停止测试分为正常停止和非正常停止两种情况。正常停止的情形：1、按照测试计划，完成了规定的所有工作，达到准出标准，可以停止测试；2、系统的功能和性能满足需求规格说明书的要求；3、测试中发现的缺陷，各级缺陷的修复率达到标准；现存bug中，不存在致命级别、严重级别的缺陷；现存bug中，存在的一般级别缺陷的个数，不超过总缺陷的5%；现存bug中，存在的建议级别缺陷的个数，不超过总缺陷的10%；4、功能测试的覆盖率达到100%;5、执行完全部用例发现的缺陷，不低于总缺陷的96%；6、平均每100行代码，遗留的缺陷不多于2个；7、最近3轮测试，新缺陷数量的走势趋于平缓下降；8、遗留缺陷的风险在安全范围内。非正常停止的情形：1、现有测试环境不再支持继续测试，则停止测试，测试执行挂起；2、系统有大量或严重的错误，可测性极差，则停止测试，等待修改；3、项目计划变更或人员变动，导致测试执行无法继续，则停止测试，测试执行挂起；4、需求变更，导致测试标准较大范围的变动，则停止测试，测试执行挂起；5、出现风险事故，导致测试执行无法继续，则停止测试，测试执行挂起；6、有紧急任务和高优先级任务，将导致较长时间，则停止测试，测试执行挂起；7、提交测试结果的时间到，无可计划的时间继续测试，则停止测试。4.6例外放行测试组会在测试报告中给出合格或者不合格的评价，研发中心自己决定是否修改，如果不修改，则需要开会讨论确认是否例外放行。而测试组依据质量评估报告或测试报告，提出发布建议。以下情形，测试组将不同意例外放行：1、硬器件质量存在安全隐患；2、硬器件质量存在性能缺陷；3、固件程序遗留有重大性能缺陷；4、软件质量存在重大性能缺陷；5、软件质量存在重大功能缺陷；6、设备临床性能指标不达标。

五、测试相关文档测试计划1、确定测试内容简要的说明本系统的功能，详细描述工作的范围，估计测试设计和实施测试所需工作量。2、确定测试方法及标准说明本次测试采用的方法和测试标准，针对可能的测试结果，说明将采取的处理方法。3、确定资源列出测试任务的负责人及所有参与人员，说明本次测试的时间安排，要求与开发计划中的实施计划对应，确定所需所有资源（人力、硬件、软件和工具）。4、风险评估填写测试风险列表，分析本设备测试过程中可能出现的风险并采取相应的措施。测试方案1、测试范围针对项目进行的功能测试，列出项目所包含的主要功能模块。2、测试策略确定测试范围、测试人员、测试时间、测试方法及测试工具。3、测试准备测试环境、硬件要求、数据库的数据量、测试工具等是否准备齐全。4、测试用例严格按照《测试用例规范》编写，评审通过后使用用例管理工具进行维护。5、测试通过标准定义测试通过及产品发布标准。6、测试输出输出测试报告、测试用例执行记录及缺陷分析列表。7、测试风险定义测试风险（如测试范围风险、测试进度风险及测试环境风险），提供规避方案。测试用例1、用例编号由字母、字符、数字组合而成的字符串，有唯一性、易识别性。2、用例标题对测试用例的简单描述，用概括的语言描述该测试用例的测试点，测试用例标题不能重复。3、前置条件执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行或无法得到预期结果。4、用例级别从基本功能、核心业务、重要特性、实际使用频率等方面将用例级别分为高、中、低三个级别。5、操作步骤执行当前测试用例需要的操作步骤，需要明确的给出每一个操作的详细描述，测试人员可以根据对应操作步骤完成测试用例执行。6、测试数据测试用例执行时，需要输入的外部信息，包括数据库连接、用户信息、用户角色权限等和测试相关的数据。7、实际结果按照步骤执行当前测试用例，被测设备的实际输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等，一个测试步骤对应一个测试结果。8、预期结果当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。缺陷列表1、bug编号缺陷的唯一标识，根据该标识能追踪到具体的某个缺陷。2、所属模块bug出现的模块，能更快找到bug且为后续bug统计提供依据。3、bug标题描述bug的标题，用一句非常简洁的话语将问题的核心描述出来，不要有歧义，字数最好不要超过20个。4、严重程度bug出现后造成的影响，根据影响大小对bug进行了分级，一般可以分为四级：致命、严重、一般、建议。5、优先级定义bug被修复的先后顺序，优先级高的先被修复，一般可以分为四级：紧急、高、中、低，可与bug严重程度结合使用。6、bug状态是缺陷跟踪过程的进展情况，状态分为：激活、已解决、已关闭。7、bug类型根据缺陷产生的来源和根源划分出的缺陷种类，如代码错误、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关等。8、所属版本发现bug所在的软件版本，有助于问题更快复现及解决。9、复现步骤按照此步骤能复现该bug，复现步骤是bug提交的一个非常重要的要素，包括：前置条件、发生时间、操作步骤、预期结果、实际结果和相关附件。10、附件出现bug时所产生的文件均需上传，如截图、视频、数据库、日志等。注意：不要把几个bug录入到同一个ID，即使这些bug的表面现象类似，或者是在同一个区域出现，或者是同一类问题，也应该一个缺陷对应记录一个bug，因为这样才能清晰地跟踪所有bug的状态，并且有利于缺陷的统计和质量的衡量。测试报告测试报告分为4类：1、正式测试报告；2、临时测试报告；3、器件确认测试报告；4、质量评估报告；对质量现状进行评定，判断是否满足预期结果，分析实际与预期之间的差距。各类测试报告中，需要对测试结果进行总结，得出结论性的问题说明和质量评价，以提供给管理者直观清晰的汇报。遗留的问题一定要讨论评审，确定可遗留到下个版本，而且要在测试报告中，注明已知问题&风险。测试组负责人应即时上报测试报告，一般在测试完成后的当天进行汇报。

六、日常工作规范6.1工作任务测试组的工作任务由测试组负责人统一分派。任务分派和流转应通过邮件形式转发，附带任务来源提供的所有资料和信息。任务执行人在完成任务后，需将任务记录在文档中。任务单在公司全范围内流转，从任务请求开始，直到任务完成结束。包含：任务每个环节的负责人、输入或输出文档路径、结果概述等信息。6.2输入输出测试组的测试工作分为3类：正式测试、临时测试、其他测试。各类任务的输入信息和输出成果如下：1、正式测试工作的输入：任务单、符合接受标准的测试对象、测试计划；2、正式测试工作的输出：任务单更新后提交、测试版本入库管理、缺陷入库跟踪、测试用例、测试报告；3、临时测试任务的输入：任务单、符合接受标准的测试对象、任务安排；4、临时测试任务的输出：任务单更新后提交、测试版本入库管理、缺陷入库跟踪、测试用例、测试结果上报；5、其他测试任务的输入：任务单、测试所需的资料和文档、测试对象、任务安排；6、其他测试任务的输出：任务单更新后提交、测试版本入库管理、问题上报跟踪、测试结果上报；完成任务后，任务执行人负责上报任务结果，然后将任务记录更新至任务清单列表中。同时，将输出成果提交至文档库统一管理、使用。6.3协作要求测试组外部协助要求：1、研发中心提交测试组请求协助的工作任务均需通过邮件形式，附带书面材料，发送至测试组负责人邮箱；2、研发中心应保证测试组从产品或项目立项开始介入，并遵照达成一致的工作流程和规则进行操作。如有特殊情况，应事先知会测试组负责人，协商一致；3、如研发中心未按照规定的流程行事，测试组负责人有权拒绝接受研发中心的任务，并给出说明；测试组内部成员协作要求：1、工作事务的沟通，采用邮件方式；2、工作流转需按照规定的工作流程操作；3、工作过程中，完成规定的工作记录，以备查验追踪；4、不得擅自从其他各处接受工作任务；5、工作过程中，与其他部门沟通时，重要问题需测试组负责人知悉；6、工作过程中，主动上报任务进度，遇到问题应主动寻求帮助；7、接受任务时，首先检查任务资料、工作资源、技术难度等，如存在工作困难，应第一时间与测试组负责人沟通；8、完成工作时，需按工作规则提交完整的工作成果，提交符合要求的文档记录和规范的工作文档；9、对自身岗位职责内的事情，尽责完成。对团队发展和自身提升有益的事情，可主动提出并实施。

七、测试过程管理7.1测试文档7.1.1测试文档管理本项目对测试文档进行集中管理，文档集中存放在项目经理处。测试文档由不同角色分别创建，各角色创建的文档如下：文档名称编制者其他说明《测试计划》项目经理《测试需求表》测试需求制定人员《测试用例说明书》测试设计人员《测试执行记录表》测试执行人员《缺陷记录》缺陷报告人员《缺陷跟踪汇总表》缺陷报告人员《测试总结分析报告》项目经理7.1.2编号规则子系统编号规则目的是定义要测试的各子系统的编号，以唯一标识各子系统。本项目需要测试的各子系统的编号如下：阶段子系统名称编号XXXX子系统01XX子系统02XXXX子系统11XX子系统12XXXX子系统21XX子系统22测试项编号规则这里的测试项，是指测试需求和测试用例等。为了便于区分和管理测试项，并且唯一地标识测试项，需要对测试项规定一种编号规则。我们制定编号规则如下：编号名称说明定义系统识别码测试项目/系统的标识，在项目开始时自行定义，要求不与其他项目的标识冲突。测试项识别码用于标识是何种测试项（测试用例、测试需求）测试需求R测试用例C缺陷记录D子系统编号各子系统的编号与子系统编号中定义的一样模块编号唯一标识同一子系统中的各模块7.2缺陷处理本项目特定义缺陷处理过程如下：1、测试人员每天记录当天发现的缺陷；2、测试人员每天下班前将记录的缺陷发送给项目经理；3、测试结束时测试人员将所有缺陷整合成一个完整的缺陷文档；4、测试结束时项目经理组织对本次不修改的缺陷进行评审。7.3过程控制1、各阶段开发组或测试组需提供的文档必须完备，负责人或测试者必须具体化；2、各阶段的时间节点及周期控制需具体化；3、如有任何一环节出现延期或意外需提前告知。7.4测试版本管理测试人员对开发每次提交的版本和程序代码都要做好记录与备份工作，尽量保证交付