1. 软件测试的重要性

• 在软件开发进程中，软件测试充当着确保软件质量的关键角色。伴随软件系统规模的不断扩大以及复杂性的持续增加，对软件测试的规范性与有效性的要求也日益提升。

• 若测试无效，软件中的缺陷极有可能在发布后才被察觉，这将给用户带来严重的后果，诸如数据丢失、系统崩溃等问题。

2. TMMi 的起源

• TMMi 是在软件测试能力成熟度模型（TMM）的基础上逐步发展而来。TMM 最早由美国卡内基梅隆大学软件工程研究所（SEI）提出，为软件测试过程的评估与改进构建了一个框架。

• 其后，TMMi 基金会整合了国际标准化组织（ISO）、国际电工委员会（IEC）以及电气和电子工程师协会（IEEE）的相关标准与最佳实践，形成了 ISO/IEC/IEEE 29119 - TMMi 标准，使得软件测试能力成熟度模型更加完备且具有权威性。

1. 成熟度级别

• TMMi 模型划分为五个成熟度级别，由低到高依次为：初始级、已管理级、已定义级、量化管理级和优化级。

• 初始级

• 处于这一级别时，测试过程通常较为混乱，缺乏明确界定的测试目标与策略。测试活动往往具有临时性，依赖于个人的技能与经验，在组织层面缺乏支持与规范。例如，一个小型软件开发团队在初始阶段，可能只是在软件基本功能开发完成后，由开发人员随意进行一些简单的功能测试，既没有详细的测试计划，也没有测试用例。

• 已管理级

• 已管理级的显著特点是测试过程已被纳入管理范畴。测试目标与计划开始得到明确界定，并且具备基本的测试资源管理。例如，团队会制定详尽的测试计划，涵盖测试范围、测试进度安排等内容，同时会对测试设备和测试环境进行有效管理。

• 已定义级

• 在这个级别，测试过程被清晰地定义并文档化。拥有标准的测试流程、测试方法以及测试技术的定义。例如，企业会制定一套完整的软件测试流程手册，明确规定从测试需求分析、测试用例设计、测试执行到测试报告等各个环节的具体操作方法与标准。

• 量化管理级

• 量化管理级着重对测试过程进行量化度量与分析。通过收集与分析测试数据，如缺陷密度、测试覆盖率等指标，来评估测试过程的有效性与效率。例如，企业会定期收集测试过程中的数据，计算每个功能模块的缺陷发现率，并依据这些数据调整测试策略。

• 优化级

• 优化级是 TMMi 的最高级别。在此级别，组织能够持续改进测试过程。通过对测试过程的监控与反馈，不断引入新的测试技术与方法，优化测试流程。例如，企业会根据行业内最新的测试技术，如自动化测试框架的更新，持续优化自身的测试流程，提高测试效率与质量。

2. 过程域

• TMMi 包含多个过程域，这些过程域是实现每个成熟度级别目标的关键要素。

• 例如，在已管理级中有 “测试计划和控制” 过程域。该过程域要求组织能够制定合理的测试计划，包括确定测试目标、测试范围、测试策略、测试进度安排等内容。同时，要能够对测试计划的执行情况进行监控和控制，及时发现并解决测试过程中出现的问题，如测试进度延迟、测试资源不足等。

• 另一个重要的过程域是 “测试组织”，它涉及到测试团队的组织结构、角色和职责的定义。在已定义级中，这个过程域要求组织明确测试团队内部各个成员的职责，如测试经理、测试分析师、测试执行人员等的职责范围，并且要有良好的沟通机制，确保测试工作的顺利开展。

1. 对软件质量的提升

• 通过实施 TMMi 认证所要求的过程改进，能够大幅提高软件测试的质量。规范的测试流程与成熟的测试方法有助于发现更多的软件缺陷，降低软件发布后出现故障的几率。

• 例如，一个经过 TMMi 认证达到已定义级别的企业，其软件测试过程具有明确的测试用例设计标准。测试人员依据这些标准进行测试用例设计，能够确保测试用例的完整性与有效性，进而提高测试的覆盖率，发现更多潜在的软件缺陷。

2. 对企业形象和市场竞争力的影响

• TMMi 认证是企业软件测试能力的权威证明。拥有该认证能够提升企业在软件行业内的形象，增强客户和合作伙伴对企业软件质量的信心。

• 在市场竞争中，尤其是在对软件质量要求较高的领域，如金融、医疗、航空航天等行业，拥有 TMMi 认证的企业更具竞争力。例如，一家金融软件企业如果获得了 TMMi 高级别的认证，在与其他竞争对手争夺银行等金融机构的软件项目时，就更有可能凭借其良好的软件测试能力和质量保障而中标。

3. 成本效益方面

• 从长远来看，实施 TMMi 认证能够降低软件测试的成本。虽然在认证过程和过程改进初期可能需要投入一定的人力、物力和财力，如培训员工、购买测试工具等。

• 但是，通过提高测试效率，减少软件缺陷修复成本（因为在软件发布前发现并修复缺陷的成本远低于发布后），以及提高软件的可靠性，从而降低因软件质量问题导致的损失，最终可以实现成本的节约。例如，一个软件企业在未实施 TMMi 认证前，由于软件缺陷导致的售后维护成本较高，实施认证并改进测试过程后，售后维护成本明显下降。

1. 评估准备阶段

• 组建评估团队：评估团队成员需具备丰富的软件测试经验和 TMMi 知识。通常包括内部的测试经理、质量保证专家以及外部的 TMMi 评估师。

• 确定评估范围：明确要评估的软件测试过程、项目或组织单元。例如，是对整个企业的软件测试部门进行评估，还是仅针对某个特定的软件项目的测试过程进行评估。

• 收集文档和数据：收集与测试过程相关的文档，如测试计划、测试用例、测试报告等，以及测试过程中的数据，如缺陷数据、测试资源使用情况等。这些文档和数据将作为评估的基础。

2. 现场评估阶段

• 访谈相关人员：评估团队会与测试团队成员、项目经理、开发人员等相关人员进行访谈。了解他们对测试过程的理解、执行情况以及在测试过程中遇到的问题。例如，询问测试人员如何设计测试用例，开发人员如何配合测试工作等。

• 审查文档和数据：对收集到的文档和数据进行详细审查。检查测试计划是否符合 TMMi 的要求，测试用例是否完整有效，测试报告是否准确地反映测试结果等。同时，分析测试数据，如缺陷分布情况、测试覆盖率等指标是否合理。

• 观察测试过程：如果可能，评估团队会观察实际的测试过程。例如，观察测试人员如何执行测试用例，如何记录测试结果和缺陷等，以获取第一手的评估信息。

3. 评估报告阶段

• 编写评估报告：根据现场评估的结果，评估团队编写详细的评估报告。报告中会明确指出组织的软件测试过程目前所处的 TMMi 成熟度级别，以及在各个过程域中的优势和不足。例如，报告可能会指出在 “测试环境管理” 过程域中，组织已经建立了基本的测试环境配置管理机制，但在测试环境的备份和恢复方面还存在不足。

• 提出改进建议：针对评估中发现的问题，评估团队会提出具体的改进建议。这些建议会根据 TMMi 的最佳实践和标准，帮助组织提升其软件测试能力。例如，对于测试环境备份和恢复不足的问题，建议组织建立定期的测试环境备份策略，并进行备份恢复演练。

4. 认证决策阶段

• 认证机构审核：评估报告提交给认证机构后，认证机构会对报告进行审核。审核内容包括评估过程的合规性、评估结果的准确性等。

• 颁发认证证书：如果审核通过，认证机构会根据组织的实际情况，颁发相应的 TMMi 认证证书，证明组织的软件测试能力达到了一定的 TMMi 成熟度级别。

1. 定期复审

• 获得 TMMi 认证后，组织需要定期接受复审。复审的周期一般由认证机构规定，通常是每年或每两年一次。复审的目的是检查组织是否仍然符合认证时的标准，是否在持续改进测试过程。

• 在复审过程中，评估团队会再次对组织的软件测试过程进行评估，重点关注之前发现的问题是否已经得到解决，以及是否有新的问题出现。例如，如果在初次认证时发现测试用例管理不够规范，复审时就会检查组织是否已经采取措施改进了测试用例管理。

2. 过程改进计划的实施

• 基于 TMMi 认证的评估结果和改进建议，组织应该制定详细的过程改进计划。这个计划应该包括改进的目标、具体的改进措施、责任人和时间进度安排等内容。

• 例如，目标是将软件测试过程从已管理级提升到已定义级，具体的改进措施可能包括完善测试流程文档、对测试人员进行新的测试技术培训等。由测试经理作为责任人，在接下来的 6 - 12 个月内完成这些改进工作。并且，组织需要对过程改进计划的实施情况进行跟踪和监控，确保改进工作按计划进行。

3. 与其他标准和实践的结合

• TMMi 认证可以与其他软件质量标准和实践相结合，如 ISO 9001（质量管理体系标准）、CMMI（能力成熟度模型集成）等，以实现更全面的软件质量保障。

• 例如，将 TMMi 与 CMMI 结合，可以在软件开发的整个生命周期中，从需求管理、设计、开发到测试和维护，建立一套连贯的过程改进体系。这样可以确保软件的各个环节都能得到有效的质量控制，提高软件整体的质量和可靠性。

（一）测试政策文档

1. 组织测试政策声明

• 正式文件对组织软件测试的总体方针与策略予以阐述。涵盖组织对软件质量的承诺，明确测试在软件开发周期中的地位，以及测试活动与业务目标的关联。

• 例如，声明中可能表述为：“本组织矢志通过高效的软件测试，确保交付高品质的软件产品。测试活动应贯穿软件开发生命周期的各个阶段，以满足客户对软件可靠性与功能性的需求。”

2. 测试战略规划

• 描述组织在中长期（通常为 3 至 5 年）内对于测试能力提升的战略方向。包括计划达成的 TMMi 成熟度级别，以及为实现该目标所采取的主要战略举措。

• 如：“未来三年内，本组织计划将 TMMi 成熟度级别从已管理级提升至已定义级，主要通过完善测试流程文档、引入先进的测试工具以及加强测试团队培训来实现。”

（二）与高层管理相关的支持材料

1. 管理层决议或备忘录

• 该文件记录高层管理层对测试政策和战略的认可与支持。可以采用董事会决议、总经理办公会纪要等形式，彰显组织高层领导对软件测试工作的重视以及推动 TMMi 认证的决心。

• 例如，一份董事会决议可能包含：“决议支持软件测试部门依照 TMMi 标准进行过程改进，并提供必要的资源保障，包括人力、物力和财力，以确保组织顺利通过 TMMi 认证。”

2. 资源分配计划

• 详细说明为测试活动和 TMMi 认证过程分配的资源，涵盖人力资源（如测试人员数量、培训预算）、财务资源（如购买测试工具的资金、认证费用）以及物力资源（如测试设备、测试环境的配置）。

• 例如，资源分配计划表格可能呈现如下内容：
  

  
  

  资源类型	具体资源	数量/金额	分配时间
  人力资源	测试工程师培训	20 人 / 次	第一季度
  财务资源	测试管理工具购买	50,000 元	第二季度
  物力资源	高性能测试服务器	3 台	第三季度

（一）测试流程手册

1. 测试流程总体框架

• 以流程图等形式展示软件测试从起始到结束的完整流程，明确各个阶段（如测试需求分析、测试用例设计、测试执行、缺陷管理和测试报告）的先后顺序及相互关系，清晰界定每个阶段的输入与输出。

• 例如，简单的测试流程流程图可显示测试需求分析阶段的输出（测试需求规格说明书）为测试用例设计阶段的输入，而测试用例设计阶段的输出（测试用例集）则是测试执行阶段的输入。

2. 各阶段详细流程描述

• 针对每个测试阶段，提供详尽的操作步骤与规范。

• 测试需求分析

• 包含需求收集的方法（如与客户沟通、分析业务文档）、需求分类和优先级确定的规则，以及需求规格说明书的模板和内容要求等。

• 例如，需求规格说明书模板可能涵盖功能需求、非功能需求（如性能、安全性）、接口需求等部分，且每个部分均有详细的填写说明。

• 测试用例设计

• 阐明不同类型测试用例（如功能测试用例、边界值测试用例、异常测试用例）的设计方法与技术。提供测试用例文档的模板，明确用例编号、用例名称、测试步骤、预期结果等字段的定义与填写规范。

• 例如，对于功能测试用例设计，可能详细介绍等价类划分法的操作步骤，以及如何依据功能需求编写测试步骤和预期结果。

• 测试执行

• 涵盖测试执行的环境准备要求、测试用例执行的顺序与方式，以及执行过程中的记录要求（如记录实际结果、执行时间）等。

• 例如，规定在执行测试用例前，必须先检查测试环境是否满足测试用例要求，执行过程中若发现缺陷应及时记录缺陷的详细信息，包括缺陷出现的步骤、实际结果与预期结果的差异等。

• 缺陷管理

• 包括缺陷的发现、报告、跟踪和关闭流程。定义缺陷的严重程度和优先级分类标准，以及缺陷管理工具的使用方法。

• 例如，缺陷严重程度可分为严重、较严重、一般和轻微四个等级，每个等级均有明确定义，如严重缺陷是指导致系统崩溃或数据丢失的缺陷。同时，说明如何使用缺陷管理工具（如 JIRA）进行缺陷的提交、分配、解决和验证。

• 测试报告

• 说明测试报告的内容与格式，包括测试项目概述、测试范围、测试结果（如通过的测试用例数、发现的缺陷数）、测试结论等部分。规定报告的发布时间和受众范围。

• 例如，测试报告应在测试执行结束后的一周内发布，受众包括项目团队成员、管理层和客户（根据需要）。报告应清晰展示测试的整体情况，为决策提供依据。

（二）流程变更管理文档

1. 流程变更请求记录

• 当需对测试流程进行变更时，记录变更请求的提出人、提出时间、变更原因和内容。例如，一份变更请求记录可能显示：“变更请求人：测试经理；提出时间：20XX 年 X 月 X 日；原因：发现现有测试用例设计流程在处理复杂业务逻辑时效率较低；内容：在测试用例设计流程中增加同行评审环节。”

2. 变更评估和审批文件

• 包含对变更请求的评估报告，分析变更对测试过程、资源、进度和质量的影响。以及变更的审批记录，显示审批人、审批意见和审批时间。

• 例如，评估报告可能指出：“增加同行评审环节预计会使测试用例设计阶段的周期延长 10%，但可提高测试用例的质量，减少缺陷逃逸率约 20%。” 审批记录可能显示：“审批人：质量总监；意见：同意变更；时间：20XX 年 X 月 X 日。”

3. 变更实施计划和跟踪记录

• 详细的变更实施计划，包括变更的步骤、责任人和时间进度安排。以及变更实施过程的跟踪记录，显示变更是否按计划进行，遇到哪些问题以及如何解决。

• 例如，变更实施计划可能包括：“第一步：制定同行评审的标准和流程，责任人：测试过程改进小组，时间：20XX 年 X 月 X 日 - 20XX 年 X 月 X + 5 日；第二步：对测试人员进行同行评审培训，责任人：培训部门，时间：20XX 年 X 月 X + 6 日 - 20XX 年 X 月 X + 10 日。” 跟踪记录会记录每个步骤的实际完成时间和效果。

（一）测试组织架构图

1. 当前组织架构图

• 以图形方式展示测试部门在整个组织中的位置以及测试部门内部的组织结构。包括各级测试管理人员、测试团队（如功能测试团队、性能测试团队）的分布和相互关系。

• 例如，一个简单的组织架构图可能显示测试部门隶属于质量管理中心，测试部门下设测试经理、测试组长，测试组长领导各个测试小组，每个测试小组负责不同软件产品或模块的测试工作。

2. 未来组织架构规划（如有）

• 若组织在 TMMi 认证过程中有计划调整测试组织架构，则提供相应的规划图和说明。例如，计划在达到更高的 TMMi 成熟度级别后，设立独立的测试过程改进小组，负责持续优化测试流程。架构规划图应清晰展示这个新增小组的位置和职责范围。

（二）人员角色与职责文档

1. 角色说明书

• 针对每个与测试相关的角色（如测试经理、测试分析师、测试执行人员、缺陷管理员），详细说明其职责、权限和任职要求。

• 例如，测试经理的职责可能包括制定测试计划、管理测试团队、协调测试资源、监控测试进度和质量等。权限包括对测试资源的调配权、对测试人员的考核权等。任职要求可能包括具备一定年限的软件测试管理经验、熟悉 TMMi 标准等。

2. 人员分工计划或记录

• 对于每个软件测试项目，记录测试人员的具体分工情况。包括每个人员负责的测试阶段、测试模块或测试任务。

• 例如，一个软件测试项目的人员分工记录可能显示：“测试分析师张三负责测试需求分析和功能测试用例设计，测试执行人员李四负责执行功能测试用例，缺陷管理员王五负责缺陷的跟踪和管理。”

（三）人员培训与能力提升材料

1. 培训计划

• 涵盖测试人员培训的总体计划，包括培训目标（如提升测试人员的 TMMi 知识水平、测试技术能力）、培训内容（如 TMMi 标准讲解、测试用例设计技巧培训）、培训方式（如内部培训、外部培训、在线学习）和培训时间安排。

• 例如，一个培训计划可能包括：“第一季度：安排外部专家进行 TMMi 基础培训，培训对象为全体测试人员；第二季度：内部开展测试用例设计技巧培训，采用案例分析和实践操作相结合的方式，培训对象为测试分析师和测试执行人员。”

2. 培训记录

• 记录每次培训的详细情况，包括培训课程名称、培训时间、培训讲师、参加人员名单、培训考核结果等。

• 例如，一份培训记录显示：“培训课程：自动化测试工具使用；时间：20XX 年 X 月 X 日 - 20XX 年 X 月 X + 3 日；讲师：某自动化测试工具厂商技术专家；参加人员：自动化测试团队全体成员；考核结果：80% 的人员通过考核，能够独立使用该自动化测试工具进行简单的测试任务。”

3. 人员能力评估记录

• 用于评估测试人员的能力水平，包括技术能力（如测试工具使用能力、测试用例设计能力）、TMMi 知识掌握程度等方面。可采用考试、实际操作评估、上级评价等多种方式。

• 例如，一份人员能力评估记录可能显示：“测试人员李四：技术能力评估得分 80 分（满分 100 分），其中测试用例设计能力较强，自动化测试工具使用能力有待提高；TMMi 知识掌握程度评估得分 70 分，对 TMMi 的量化管理级相关内容理解不够深入。”

（一）测试计划文档

1. 项目测试计划模板和实例

• 提供适用于本组织的测试计划模板，包含项目概述、测试目标、测试范围、测试策略（如采用的测试方法、测试类型）、测试进度安排、测试资源需求（如人力、设备）、风险评估和应对措施等部分。同时，提供实际项目的测试计划实例，展示模板的应用情况。

• 例如，一个测试计划模板的测试进度安排部分可能包括里程碑节点（如测试需求分析完成时间、测试用例设计完成时间、测试执行开始和结束时间）的设定，以及每个阶段的详细时间跨度。实例则会根据具体项目的情况填写这些内容，如某软件项目测试计划中显示：“测试需求分析：20XX 年 X 月 X 日 - 20XX 年 X 月 X + 5 日；测试用例设计：20XX 年 X 月 X + 6 日 - 20XX 年 X 月 X + 15 日。”

2. 测试计划变更记录（如有）

• 记录测试计划在项目执行过程中发生的变更情况，包括变更的原因、变更的内容和变更的影响。例如，“变更原因：项目需求变更导致测试范围扩大；变更内容：增加了三个新功能模块的测试；变更影响：测试进度推迟 5 天，需要增加一名测试人员。”

（二）测试用例文档

1. 测试用例模板和案例集

• 测试用例模板应包括用例编号、用例名称、测试目的、测试步骤、预期结果、实际结果（在测试执行后填写）等基本字段。提供完整的测试案例集，展示针对不同软件功能和特性的测试用例编写情况。

• 例如，一个功能测试用例可能如下：
  用例编号：TC - 001
  用例名称：用户登录功能测试
  测试目的：验证用户能够使用正确的用户名和密码成功登录系统，并检查登录后的权限是否正确。
  测试步骤：

2. 打开系统登录页面。

3. 输入正确的用户名和密码。

4. 点击 “登录” 按钮。
   预期结果：系统跳转到主页面，显示用户对应的功能菜单，权限与用户角色匹配。
   实际结果：（在测试执行后填写）

5. 测试用例评审记录（如有）

• 若对测试用例进行了评审，记录评审的时间、评审人员、评审意见和评审结果。例如，“评审时间：20XX 年 X 月 X 日；评审人员：测试组长、测试分析师；评审意见：部分测试用例的预期结果描述不够准确，需要修改；评审结果：根据评审意见修改后通过评审。”

（三）测试执行记录

1. 测试执行日志

• 详细记录测试执行过程中的情况，包括每个测试用例的执行时间、执行结果（通过 / 失败）、发现的缺陷信息（如缺陷编号、缺陷描述）等。

• 例如，一个测试执行日志可能显示：“测试用例 TC - 001，执行时间：20XX 年 X 月 X 日 10:00 - 10:10，执行结果：通过；测试用例 TC - 002，执行时间：20XX 年 X 月 X 日 10:15 - 10:30，执行结果：失败，缺陷编号：DEF - 001，缺陷描述：在输入非法用户名时系统未给出正确的提示信息。”

2. 测试环境配置记录

• 记录测试执行时的测试环境配置情况，包括硬件环境（如服务器型号、客户端设备）、软件环境（如操作系统版本、数据库版本、应用服务器版本）、网络环境（如网络带宽、网络拓扑结构）等。

• 例如，“硬件环境：服务器采用戴尔 PowerEdge R740，客户端设备为联想 ThinkPad 笔记本；软件环境：操作系统为 Windows Server 2019，数据库为 Oracle 19c，应用服务器为 Tomcat 9.0；网络环境：1000Mbps 以太网，网络拓扑为星型结构。”

（四）缺陷管理文档

1. 缺陷报告模板和实例

• 缺陷报告模板应包括缺陷编号、缺陷标题、缺陷发现日期、发现人、缺陷严重程度、缺陷优先级、缺陷描述、重现步骤、预期结果、实际结果、缺陷状态（如新建、已分配、已修复、已验证、已关闭）等字段。提供实际的缺陷报告实例，展示模板的应用情况。

• 例如，一个缺陷报告可能如下：
  缺陷编号：DEF - 001
  缺陷标题：用户登录时非法用户名提示错误
  发现日期：20XX 年 X 月 X 日
  发现人：测试执行人员李四
  严重程度：较严重
  优先级：高
  缺陷描述：在用户登录页面输入非法用户名后，系统未按照要求给出 “用户名错误” 的提示信息。
  重现步骤：

2. 打开系统登录页面。

3. 输入非法用户名。

4. 输入任意密码。

5. 点击 “登录” 按钮。
   预期结果：系统弹出 “用户名错误” 的提示框。
   实际结果：系统无任何提示，直接返回登录页面。
   缺陷状态：已分配

6. 缺陷跟踪记录

• 记录缺陷从发现到关闭的整个跟踪过程，包括缺陷的分配情况（分配给谁、分配时间）、修复情况（修复时间、修复人）、验证情况（验证时间、验证人、验证结果）等。

• 例如，对于上述缺陷，跟踪记录可能显示：“分配时间：20XX 年 X 月 X 日，分配给开发人员张三；修复时间：20XX 年 X 月 X + 2 日，修复人：张三；验证时间：20XX 年 X 月 X + 3 日，验证人：李四，验证结果：通过，缺陷已关闭。”

（五）测试报告文档

1. 测试报告模板和实例

• 测试报告模板应包括项目基本信息、测试目标、测试范围、测试方法、测试结果（如测试用例执行情况、缺陷统计情况）、测试结论（如软件是否可以发布、需要改进的方面）等部分。提供实际的测试报告实例，展示模板的应用情况。

• 例如，一个测试报告实例可能显示 “项目基本信息：项目名称为 XX 软件系统 V1.0；测试目标：验证软件功能和性能是否满足需求；测试范围：包括用户管理、订单管理、报表生成等功能模块；测试方法：采用黑盒测试和性能测试；测试结果：共执行测试用例 500 个，通过 480 个，失败 20 个，发现缺陷 30 个，已修复并验证 25 个；测试结论：软件功能基本满足需求，但部分功能存在缺陷需要修复，性能测试结果符合预期，建议在修复剩余缺陷后发布软件”。

（一）度量指标定义文档

1. 测试报告模板和实例

• 列出用于度量测试过程的各种指标，如测试覆盖率（功能测试覆盖率、代码测试覆盖率）、缺陷密度（按功能模块、按阶段）、测试效率（如测试用例执行速度、缺陷发现率）等。

• 例如，一个度量指标清单可能包括：

  
  

• 定义	计算公式
  功能测试覆盖率	已测试的功能点数量与总功能点数量的比率	（已测试功能点数 / 总功能点数）×100%
  代码测试覆盖率	被测试执行的代码行数与总代码行数的比率	（已测试代码行数 / 总代码行数）×100%
  缺陷密度（按功能模块）	每个功能模块发现的缺陷数量与该功能模块规模（如代码行数、功能点数）的比率	缺陷数量 / 功能模块规模
  测试用例执行速度	单位时间内执行的测试用例数量	执行的测试用例数量 / 执行时间
  缺陷发现率	在测试过程中发现的缺陷数量与潜在缺陷估计数量的比率	（发现的缺陷数量 / 潜在缺陷估计数量）×100%

（二）数据收集与存储文档

1. 数据收集计划

• 说明针对每个度量指标的数据收集方法、收集频率和负责收集数据的人员。例如，对于功能测试覆盖率，收集方法是通过测试管理工具统计已测试的功能点和总功能点，收集频率为每周一次，负责人员为测试分析师。

2. 数据存储格式和位置

• 描述数据存储的格式（如电子表格、数据库）和存储位置（如服务器路径、数据库名称）。例如，测试数据存储在公司内部服务器的 “测试数据仓库” 数据库中，以关系型数据表的形式存储，每个表对应不同类型的数据，如测试用例执行数据表、缺陷数据表等。

（三）数据分析与报告文档

1. 数据分析方法和工具

• 介绍用于分析测试数据的方法，如统计分析方法（平均值、标准差计算）、趋势分析方法（绘制数据随时间变化的曲线）、相关性分析方法（分析两个指标之间的关联）等，以及使用的分析工具（如 Excel、SPSS 等）。例如，使用 Excel 的图表功能绘制缺陷发现率随测试阶段变化的折线图，以分析缺陷发现的趋势。

2. 数据分析报告模板和实例

• 提供数据分析报告的模板，包括报告标题、报告日期、分析目的、分析的数据指标、分析方法、分析结果（如数据图表、数据之间的关系）和结论（如对测试过程的评价、改进建议）等部分。同时，提供实际的数据分析报告实例，展示模板的应用情况。例如，一份数据分析报告可能显示通过对缺陷密度的分析，发现某个功能模块的缺陷密度明显高于其他模块，结论是需要对该模块的开发和测试过程进行重点检查，改进建议是加强该模块的代码审查和测试用例设计。