目录1.引言 (4)1.1.目的 (4)1.2.内容 (4)2.职责职权 (4)2.1.职权 (4)2.2.工作职责 (5)2.3.岗位职责 (5)2.3.1.软件测试工程师 (5)2.3.2.硬件测试工程师 (5)3.工作目标 (6)3.1.测试活动 (6)3.2.非测试活动 (7)3.3.测试目标 (7)3.3.1.核心目标 (7)3.3.2.其他目标 (7)3.3.3.阶段目标 (8)3.4.非测试目标 (8)4.测试流程 (9)4.1.任务来源 (9)4.1.1.任务来源： (9)4.1.2.转交形式 (9)4.1.3.转交内容 (9)4.1.4.例外处理 (9)4.2.接受标准 (9)4.3.测试设计 (10)4.4.测试执行 (11)4.5.作业依据 (11)4.6.退出标准 (12)4.7.测试报告 (13)4.8.例外放行 (13)4.9.缺陷管理 (13)5.日常工作规范 (15)5.1.同行测试 (15)5.2.工作任务 (15)5.3.输入输出 (15)5.4.协作要求 (16)5.4.1.对研发中心 (16)5.4.2.测试部内部成员协作要求 (16)6.文档管理规范 (17)6.1.文档模板 (17)6.2.文档管理 (17)6.3.文档维护 (17)7.责任追溯 (17)8.工作汇报 (18)9.附件 (19)9.1.附录A 文档目录 (19)9.2.附录B 缺陷处理 (20)10.其他 (21)1.引言1.1.目的该文档作为测试部各项工作的指导与部门成员工作的参照执行标准。

针对测试团队的日常工作规范，主要包括测试流程、测试结果、测试文档的输出。

确保测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。

工作实践过程中，由部门成员不断改进优化，使工作明确、有序、高效进行，使与其他各部门更好的协作，做好产品的质量控制与质量保证。

1.2.内容该文档明确约定了测试部的工作职责、测试流程、文档管理规范、日常工作规范、责任追溯与工作汇报等内容。

2.职责职权2.1.职权测试部具有以下权利，以保证测试工作的独立主动性。

2.2.工作职责测试部同时承担有以下工作职责，是为使命：1）协助研发与项目团队高质量完成软件或产品，以节省开发成本；2）参与各阶段工作，对阶段成果进行测试，以保证阶段目标的达成；3）发布前进行缺陷查找和定位工作，发现尽可能多的缺陷，以节省成本，保持用户信心；4）编写测试计划、测试用例，在尽量真实的环境下，保证高覆盖度的测试，以节省运维成本；5）进行缺陷跟踪与分析，查找和监控存在的问题，推进项目质量和管理质量的提升；6）正确评价测试对象的质量现状，确定实际与预期目标的差距；7）对工作资源与成果进行管理、维护（输入、输出、交互文档、测试版本、缺陷记录等资源）。

2.3.岗位职责2.3.1.软件测试工程师按照测试计划负责公司产品软件部分的测试工作及相关文档的撰写。

1)编写测试用例，利用测试工具进行软件测试及管理，对测试结果进行分析。

2)负责测试报告的撰写和测试问题的跟踪。

3)协同软件工程师，完成软件设计部分的不良分析和版本故障跟踪。

4)参与软件早期设计检视，保证软件可测试性需求。

5)按时按质完成上级交办的其他工作。

2.3.2.硬件测试工程师按照测试计划负责公司产品硬件部分的测试工作及相关文档的撰写。

1)编写测试用例并执行，对测试结果进行分析。

2)负责测试报告的撰写和测试问题的跟踪。

3)协同硬件工程师，完成硬件设计部分的不良分析和版本故障跟踪。

4)参与硬件早期设计检视，保证硬件可测试性需求。

5)负责新元器件承认测试，及承担EMC（电磁兼容性）、可靠性测试等工作。

6)负责测试工装、测试仪器、测试仪表及测试设备的维护工作。

7)按时按质完成上级交办的其他工作。

3.工作目标测试部的工作分为2类：测试活动和非测试活动。

产品或项目的实现，在公司内分为多个阶段进行：立项、需求、计划、设计、实施、测试、确认、发布。

其中，测试阶段的工作主要由测试部的测试活动完成。

其他各阶段，主要由研发中心完成，测试部会参与各个阶段，根据各项目的实际情况，参与度不一而同。

需要明确的是，测试部门至少参与评审，且评审意见应得到重视。

可查阅各部门的工作流程图。

3.1.测试活动测试活动包括以下内容：1)计划和控制。

2)提取测试需求、选择测试环境和条件。

3)设计和执行用例。

4)实施和执行各阶段的测试。

5)检查测试结果。

6)评估出口准则。

7)报告测试过程及被测系统。

8)总结各阶段的测试工作。

9)为进入下一开发过程，或将系统交付给用户，测试部提供质量评估等足够的信息，帮助利益相关者决定是否发布。

在产品或项目的各阶段，测试部的测试活动与研发中心的工作并行开展。

3.2.非测试活动非测试活动包括以下内容：1)部门日常工作。

2)部门工作文档管理。

3)部门团队管理工作。

4)部门工作成果管理。

5)部门工作结果汇报。

6)部门团队成员技能提升。

7)部门活动的组织。

8)协助其他部门完成非测试工作任务。

根据公司领导、部门经理的管理要求和工作目标，有序、规范、高效的非测试活动将有助于推动测试活动高质量的进行、完成，达成工作目标，实现团队效益。

3.3.测试目标3.3.1.核心目标总体来说，测试部的核心目标是：通过对被测对象的源代码、程序、文档，进行静态分析、评审和执行动态测试，以提供信息来改进被测对象的质量，以及改善开发和测试的过程质量。

3.3.2.其他目标测试部另有其他如下目标，以提升工作价值：1）发现缺陷。

2）增加对质量的信心。

3）为决策提供信息。

4）预防缺陷。

3.3.3.阶段目标各测试阶段，由于工作目标的导向，测试的具体目标也不相同。

1)需求分析设计的过程中，对需求文档测试。

主要目标是识别和解决问题，避免将缺陷引入设计和代码。

2)在软件生命周期的早期进行测试设计的思维过程和活动。

主要目标是检测测试依据，避免将缺陷引入代码。

3)开发和测试中，如单元测试、集成测试、系统测试等。

主要目标是尽可能的发现失效，从而识别和修正尽可能多的缺陷。

4)验收测试中，测试的主要目标是确认系统是否按照预期工作，是建立满足需求的信心。

5)有些情况下，如发布，测试的主要目标是对软件质量进行评估，从而为利益相关者提供信息：在给定时间点发布，可能存在的风险。

6)维护测试中，测试的主要目标是验证在开发过程中的软件变更是否引入新的缺陷。

7)运行测试中，测试的主要目标是为了评估系统的特征，比如可靠性、可用性、安全性等。

运行测试是指如软件在发布前，进行试运行时进行的测试。

不同阶段，参照不同的目标，调整工作方式，提交的工作成果包含和体现的信息将不同。

3.4.非测试目标测试部的非测试活动的目标：1)规范工作流程，采用合理的工作方式，有序的推进工作。

2)高质量完成工作任务，达成工作目标。

3)建设高效能的团队组织。

4)实现团队价值，提升各成员素质。

5)良好的工作氛围。

4.测试流程4.1.任务来源4.1.1.任务来源测试部只接收由研发中心提交的工作任务，其他部门如需测试部协作，则先提交至研发中心，由其转交。

4.1.2.转交形式应使用书面形式，通过邮件递交至测试部负责人处。

任何口头或者即时通信方式转交的任务将被拒绝。

4.1.3.转交内容研发中心递交任务时需提供任务单等相关资料，任务单中应当明确：完成时间、任务要求、修改内容等。

4.1.4.例外处理如任务的紧急程度和优先级较高，影响较大，由测试部负责人灵活掌控。

4.2.接受标准1、研发部应当提交详尽可用的文档，包括但不限于历史版本，当前版本，功能修改详细信息、各相关部门签字确认后的技术支持表或需求变更详细信息以及期望任务完成时间，否则测试部将有权拒绝接受测试版本。

2、所交付的测试任务需具备可测试性。

如果配套的客户端程序、终端机固件、服务器程序等，均进行了改动，交付测试任务时需配套交付，否则测试部将拒绝接受所交付的测试任务。

3、经过各相关部门签字确认的技术支持表所列类容一项（含）不符合，将直接拒绝本次测试，不会再执行下一步详细测试。

4、研发提交版本应当在每日上午，除非有紧急需求，那么下午提交的版本将会视为次日上午提交。

5、由测试部经理对所交付的测试任务进行过滤，对不符合测试交付条件的测试任务进行拒绝、协调和反馈。

测试部接到研发中心的测试请求，首先判断是否满足接受标准，如不满足，测试部有权拒绝测试请求，研发中心需要修改后，重新提交。

1）研发中心的测试请求必须通过邮件形式提交至测试部负责人处。

2）必须提供后述4份资料：任务单、测试版本、测试标准、修改说明。

3）测试标准必须是需求确认书或需求规格说明书或其他文档形式的标准。

4）修改说明必须包含4个信息：历史版本号、当前版本号、修改了哪些功能、为什么修改。

5）请求必须说明期望测试任务完成的时间、测试要求、环境配置、重点关注内容。

6）如果本次测试任务相关的最近一次测试中提交了BUG，BUG未被全部修改，则拒绝接受此次测试任务。

7）测试版本必须保证功能是可测的。

满足以上6条时，测试人员进行冒烟测试，当安装卸载正常、可测试的工作达到80%以上时，才认为该版本的功能是可测的。

除非有特殊理由，否则，不满足以上7条时，测试部将拒绝测试任务，并由测试部负责人回复邮件说明原因。

待研发中心修改后，再提交。

4.3.测试设计测试部负责人可以要求研发中心为测试预留足够的时间。

在整体计划定稿后，测试人员开始编写合理的计划方案、搭建符合用户的测试环境、撰写和设计测试用例、准备测试资源。

测试计划、测试用例、测试环境设计均需进行评审。

测试部内部评审后，交与研发中心评审，产品线经理负责明确重要功能、逻辑复杂度高的功能，并基于架构设计和代码层面指出计划、用例、环境的不足之处。

测试部应采纳合理意见。

测试设计应兼顾阶段性成果测试的规划。

提倡尽早测试，阶段交付，分散压力、工作量和风险。

搭建测试环境，需要尽可能与客户实用环境一致，如果实难满足，差距较大，应对不同环境下，存在的各种隐患及风险进行分析并备案。

在质量评估报告中摆明。

4.4.测试执行测试执行过程中，测试人员要注意以下几点：1）首先，测试人员对测试版本进行确认并记录。

2）其次，测试人员要即时记录发现的缺陷，并在每日下班前对缺陷进行整理。

3）再次，研发人员要即时对测试人员提交的缺陷进行查阅，并且最迟在次日上午修改缺陷状态并给出详尽说明。

4）测试完结后，测试部需要提交对应的书面文档，上交测试记录、测试结果或测试报告。

5）另外，测试人员应尽力定位BUG产生的原因。

如遇到重要、可复现性低的问题，应即时与研发人员联络，进行联调，现场定位原因。

此类问题，应使测试部负责人知晓，且如有需要，由测试部负责人出面协调。

如果是正式测试，每一轮测试，测试人员应将计划的测试用例完整执行一遍。