专题讲座资料（2021-2022年）公司软件测评过程能力提升方案

1、软件测评过程能力提升方案1 测评过程能力调研方案制定前需对公司现有测试流程及管理工具开展调研工作，对公司测评过程能力现状进行评估。现状的评估将从软件研发过程、软件测评过程、及测试相关支撑过程（质量管理、配置管理等），以及软件测评团队、研发平台及测试管理工具等方面，深入调研，并进行诊断。测评过程能力需要通过项目测评过程来体现，其能力的提高需要在平时每件工作当中不断积累，也需要测评团队中每位成员的努力，单单靠几个人不可能提高一个团队的测评过程能力。因此报告将着重对软件测评团队的现有成员状态进行评估，并对测评团队建设提出建议。在后续培训课程设计和实施上，也将针对性进行安排，培训实施计划将充分考虑现状

2、、客户目标，并力求兼顾个人意愿。测评过程能力提升课程将针面对全员开展，针对人员包括以下类型：系统应用软件开发人员、嵌入式软件开发人员、系统应用软件测试人员、嵌入式软件测试人员。通过本项目的具体实施，将会形成一套比较合理的软件测试体系和制度，不仅让公司获得一定技术过程能力上的提升，更具备良好后续的自我提升平台。在以上分析的基础上，咨询团队将在对用户现场进一步调研、诊断其软件测评流程、管理工具现状及综合需求，结合实际及软件测评专业发展的需要，出具“软件测评现状评估及改进建议报告”。1. 调研对象调研是现状评估的基础，而确定调研对象则是调研活动的基础。内部调研将分别面向开发人员、测试人员、项目管理人

3、员、配置管理人员、质量保证人员等，从以下三个方面开展：l 软件测试过程能力：包括测试体系制度、测试质量管理、测试配置管理等；l 测试团队和人的能力：包括测试基础知识和理论、对测试体系理解能力、对测试流程的熟悉度、测试管理工具应用技术、团队协作能力、文档能力、沟通技巧等；l 对RDP6.0研发控制流程和PLM管理平台的调研：为了完成将软件测评活动及过程文档模板固化在PLM管理平台上的目标，有必要对南车目前实用的研发控制流程RDP6.0和PLM管理平台进行相应调研。2. 调研过程调研的基本过程如下：l 调研准备：首先制定调研的计划，计划好所需的资源、调研的方式、结果的统计等步骤，并按照计划准备调研

4、所需的资源包括：人力、物力、资金、时间等；l 实际调查：根据制定的计划、依靠准备的各种资源，开展实际调研工作；l 数据分析：对调研所得数据进行分析；l 结果统计：根据对调研数据的分析，统计得出结论。3. 调研方法调研所采用的方法一般有：l 文案调查：通过要求项目配合方配合，以文件形式提供。对公司目前的软件测评过程能力现状进行调查，包括软件测试体系文件完善程度、软件测试流程管理能力等情况进行普查，并对试点单位的进行详细的摸查；l 调查问卷：通过发放调查问卷，对软件研发和测试部门人员对软件测试基础知识理解、对软件测试流程的了解、对软件测试体系的熟悉度等情况进行进一步的调研；l 现场访谈：随机走访公

5、司软件研发与测试人员，对其软件测试过程能力进行调查。4. 调研结果输出“软件测评过程能力现状评估及改进建议报告”。主要包括：l 测评体系现状：对公司软件测评体系的现状进行调研，调研内容包括：测评体系文件、测评流程、实际项目中对测评体系的符合程度等；l 测评团队现状：对公司软件测评团队的现状进行调研，调研内容包括：测评团队组织架构、测评人员组成、测评人员技术能力、对软件测评体系和过程的认知程度等；l 测评管理现状：对公司软件测评管理的现状进行调研，调研内容包括：测评管理制度、质量管理现状、配置管理现状、测评管理工具等；l 主要问题：根据以上调研结果，指出公司在软件测评过程能力中存在的主要问题；l

6、 改进建议：根据调研结果和存在的问题，提出提升公司软件测评过程能力的针对性建议。5. 调研所需资源调研所需资源如下：l 人力资源：除了我方咨询人员外，还需公司相关人员配合；l 物力资源：包括本次调研活动所需的所有物力、资金。l 其他资源：调研所用时间等其他资源。2 软件测评过程能力建设方案2.1软件研发过程本项目需求中，软件的分类分级标准及软件需求管理属于软件研发过程。2.1.1建立软件的分类、分级标准一、项目需求本部分对应项目需求中软件测评流程体系（REQ01）中部分需求：1. 建立软件的分类、分级标准。2. 根据软件的分类、分级标准及软件测试需要，制定软件开发过程裁剪指导书。二、提升方案根

7、据我们的初步调研，公司的软件项目具有以下特点：l 软件多为嵌入式软件。嵌入式软件具有两个显著特点:一是软件和硬件结合紧密,软件脱离特定系统往往无法运行,软件失效与硬件故障有时难以区分,甚至相互干。二是开发环境和运行环境不同。l 软件实时性强。软件多是实时软件，不但要求软件执行实时性强,而且要求多个任务能协调执行。l 软件属于安全关键软件。软件的不可靠将带来灾难性的后果,因此对其可靠性、安全性要求很高。一般来讲，软件的分类从软件本身来讲可以从开发平台、开发语言等进行分类，也可以根据软件的应用类型进行划分；软件分级可以从软件含量、软件安全等级等进行划分，我们将在对公司项目进行充分的调研的基础，参照

8、相关国际标准/国家标准/国军标/行业标准，并结合我司在软件分类及分级标准的实践经验，制定适合公司软件特点的分类及分级标准。并根据软件的分类、分级标准及软件测试需要，制定软件开发过程裁剪指导书。2.1.2软件需求管理一、项目需求本部分对应项目招标书中的软件需求管理（REQ24），包含但不限于如下要点：1. 结合集团公司目前的软件开发工作实际及发展需要，提出并制定科学、合理的软件需求管理方式和规程。2. 提出需求管理工具的选择建议书（工具需满足与PLM系统接口的需要，或整理、提出需求管理的需求，由PLM系统实现），指导需求管理工具的选型（自主研发、联合开发或直接购买成熟的工具等）。3. 指导、协助

9、需求管理工具的实践应用，系统管理、控制软件的需求及有效跟踪。二、提升方案需求管理指的是需求工程中的所有活动,它包含了一般意义上的需求开发和需求管理阶段，涵盖了需求获取、需求分析、需求变更、需求跟踪等所有过程。要解决需求管理过程中的问题,使用需求管理工具是一个很好的途径。考察一个需求管理工具软件，可以从下面几点出发： l 需求信息是否完备l 需求的组织形式l 需求的评审及权限控制l 需求和版本、测试是如何关联的l 需求变更的支持由于公司面对的是机构客户，具有需求变更频繁的特征，因此采用工具对需求进行有效管理非常重视。由于目前的PLM未实现（很大可能也无法实现）需求管理，需寻求专业的管理工具实现对

10、需求的高效管理。但是由于需求管理贯穿于研发全过程，因此需求管理工具最好能与目前的PLM集成，可能的方案包括基于与PLM接口的定制化开发、或者退而求其次，需求原型当成文档管理起来，后续的所有需求变更均当成缺陷并应用PLM中的缺陷管理模块进行统一的管理。我们将在评估后为公司提出具体的解决方案。我们将在对公司项目对软件需求管理的现状及需求进行充分的调研的基础，提出并制定科学、合理的软件需求管理方式和规程，提出需求管理工具的选择建议书，指导、协助需求管理工具的实践应用，系统管理、控制软件的需求及有效跟踪。2.2 软件测评过程对应项目需求REQ01软件测评流程体系、REQ13软件测试管理、REQ14软件

11、测试项目管理，包括但不限于以下内容：1. 在集团公司既有RDP开发体系下，制定软件测试流程和规范（包含软件测试各个阶段，如：单元测试、集成测试、系统测试、验收测试；软件测试与软件设计开发工作相配合和衔接的原则；规范每个阶段的参与角色及参与方式、进入准则、业务活动、输出成果、退出准则，等等）。2. 制定软件测试管理总体规程（含：测试需求、测试计划、测试用例、测试脚本、测试执行、测试结果、测试资源、测试度量，等等）。3. 制定软件测试项目管理规程（含公司内部软件测试项目、公司外部软件测试项目）。4. 我们将分别从如何定义软件测评流程及测评规范进行阐述。2.2.1测评流程软件测评流程一般包括项目接收

12、、软件测试需求分析、软件测试策划、软件测试设计、软件测试执行、软件测试结果分析、软件测试问题跟踪、软件回归测试、软件测试报告等活动，我们将分别针对内部测试和外部测试定制软件测评流程，包括各项活动、准入/准出准则、活动产出、涉及角色等。表 1 软件测评流程一览表测试过程活动描述活动产出涉及规范项目接收确定项目的等级；组成项目测试组，任命项目负责人测试项目成员配置表被测件的接收和保管程序测试需求分析确定测试级别测试类型测试项测试优先级等测试需求规格说明测试需求规格说明编写规范测试策划根据测试需求分析结果，测试内容、测试资源安排、测试进度安排软件测试计划软件测试计划编写规范测试设计与实现设计测试用例

13、；编写测试脚本软件测试说明软件测试说明编写规范建立测试环境，对测试环境设备进行标识测试环境建立记录测评过程配置管理程序测试执行首轮测试执行测试用例及测试脚本；对测试中发现的问题进行分析，填写问题报告单；软件测试问题跟踪测试记录测试问题报告测试记录的编写规范测试问题报告的编写规范回归测试对软件的更改情况作相应的影响域的分析说明，挑选、新增测试用例，并确定回归测试用例集；根据回归测试用例集执行测试回归测试说明测试记录测试问题报告回归测试说明编写规范测试总结对测试记录及问题报告单进行统计分析，出具测试报告测试报告测试报告的编写规范下面对主要过程的技术要求加以描述。一、测试需求分析1. 测试人员应根据

14、被测软件的需求规格说明书、软件设计文档等，对被测软件进行测试需求分析，测试需求分析一般包括：l 确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试阶段、测试类型匹配；l 确定测试类型中的各个测试项及其优先级；l 确定每个测试项的测试充分性要求。根据被测软件的重要性、测试目标和约束条件，确定应覆盖的范围及范围所要求的覆盖程度；l 确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。2

15、. 测试人员应建立测试类型中的测试项与软件测评任务书、被测软件的需求规格说明、设计文档或其他依据文件的追踪关系。3. 测试人员应将测试需求分析结果，按所确定的文档要求形成测试需求规格说明。4. 测试需求规格说明应经过评审，并应受到变更控制和版本控制。5. 测试需求规格说明的内部评审，主要对以下内容进行内部审核，保证测试质量：l 测试级别和测试对象所确定的测试类型及其测试要求是否恰当；l 每个测试项是否进行了标识，并逐条覆盖了测试需求和潜在需求；l 测试类型和测试项是否充分；l 测试项是否包括了测试终止要求；l 文档是否符合规定的要求。二、测试策划1. 测试人员应根据被测软件的需求规格说明书、软

16、件设计文档等进行测试策划，策划一般包括：l 确定测试策略；l 确定测试需要的技术或方法，如：测试数据生成与验证技术、测试数据输入技术、测试结果获取技术等；l 确定受控的测试工作产品，并列出清单；l 确定用于测试的资源要求，包括：软硬件设备、环境条件、人员数量和技能等要求；l 进行测试风险分析，如：技术风险、人员风险、资源风险和进度风险等；l 根据被测软件的需求规格说明书、软件设计文档和被测软件的特点，确定测试任务的结束条件；l 确定被测软件的评价准则和方法；l 应根据测试资源和测试项，确定测试活动的进度；l 应根据测试的要求，确定需采集的度量及采集要求，特别是用例度量、风险度量、缺陷度量等，并

17、应明确相应的数据库测试需求度量；2. 测试人员应建立测试计划与测试需求规格说明的追踪关系。3. 实验室应将测试策划结果，按所确定的文档要求形成测试计划。4. 测试计划应经过内部的审核，并应受到变更控制和版本控制。三、测试设计与实现1. 测试人员应根据测试需求规格说明和测试计划进行测试的设计和实现，应完成以下工作：l 按需要分解测试项。将需测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有的接口和要测试的接口；l 说明最终分解后的每个测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等；l 设计测试用例；l 确定测试用例的执行顺序；l 准备和验证所有的测试

18、用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等；l 准备并获取测试资源，如测试环境所必须的软、硬件资源等；l 必要时，编写测试执行需要的程序，如开发部件测试的驱动模块、桩模块以及测试支持软件等；l 建立和校核测试环境，记录校核结果，说明测试环境的偏差。2. 测试人员应将以上测试设计的工作结果，按照所确定的文档要求编写测试说明，测试说明一般应包括：l 测试名称和项目标识；l 测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项标识（编号）；l 测试用例说明。简要描述测试的对象、目的和所采用的测试方法；l 测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条

19、件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）的那个的初始化要求；l 测试用例的输入。每个测试用例输入的描述中包括： 每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等） 测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）； 测试输入是真实的还是模拟的； 测试输入的时间顺序或事件顺序。l 测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不

20、确切的概念或笼统的描述。必要时，应提供中间的期望结果；l 测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如： 实际测试结果所需的精确度； 允许的实际测试结果与期望结果之间差异的上、下限； 时间的最大或最小间隔； 事件数目的最大或最小值； 实际测试结果不确定时，重新测试的条件； 与产生测试结果有关的出错处理； 其它有关准则。l 实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括： 每一步所需的测试操作动作、测试程序输入或设备操作等； 每一步期望的测试结果； 每一步的评估准则； 导致被测程

21、序执行终止伴随的动作或指示信息； 需要时，获取和分析中间结果的方法。l 测试用例的前提和约束。测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响；l 测试终止条件。说明测试用例的测试正常终止和异常终止的条件。3. 确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。4. 测试说明应经过内部审核，得到全体测试人员的认同，受到变更控制和版本控制。根据测试实际情况，修订测试说明。5. 测试说明审核：l 测试说明是否完整、正确和规范；l 测试设计是否完整和合理；l 测试用例是否可行和充分。6. 测试就绪审核。再测试

22、计划审核和测试说明审核后，还必须进行测试就绪审核，以确定能否开始执行测试。测试就绪审核应包括：l 通过比较测试环境与软件真实运行的软件、硬件环境的差异，审查测试环境要求是否正确合理、满足测试要求；l 审查测试活动的独立性和公正性；l 审查测试需求规格说明、测试计划和测试说明评审中的遗留问题是否得到了解决；l 审查是否存在影响测试执行的其它问题。四、测试执行1. 测试人员应按照测试计划和测试说明的内容和要求执行测试。2. 实验室应如实填写测试原始记录，当结果有量值要求时，应准确记录实际的量值。原始记录应：l 受到严格管理；l 规范格式；l 至少包括测试用例标识、测试结果和发现的缺陷。3. 实验室

23、应根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。4. 当测试用例不通过时，实验室应根据不同的缺陷类型，采取相应的措施：l 对测试工作中的缺陷，如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等，记录到相应的表格中（如问题及变更报告），并实施相应的变更；l 对被测软件的缺陷应记录到软件问题报告中；软件问题报告的格式应规范。5. 当所有的测试用例都执行完毕后，实验室应根据测试的充分性要求和有关原始记录，分析测试工作是否充分，是否需要进行补充测试：l 当测试过程正常终止时，如果发现测试工作不足，或测试未达到预期要求时，应进行补充测试。补充测试应

24、视情况按前面所述的测试需求分析、测试策划和测试设计与执行的要求进行；l 当测试过程异常终止时，应记录导致终止的条件、未完成的测试或未被修正的错误。6. 再执行测试的过程中，可根据测试的进展情况补充测试用例，但应留下用例记录，并在执行测试后，变更测试说明。五、测试总结1. 测试人员应根据被测软件文档、测试需求规格说、测试计划、测试说明、测试记录、测试问题及变更报告和被测软件问题报告等，对测试工作和被测软件进行分析和评价。2. 对测试工作的分析和评价应包括：l 总结测试需求规格说明、测试计划和测试说明的变化情况及其原因；l 在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由；l 确定无法解

25、决的软件测试事件并说明不能解决的理由。3. 实验室对被测软件的分析和评价应包括：l 总结测试中所反映的被测软件与软件需求之间的差异；l 可能时，根据差异评价被测软件的设计与实现，提出改进的建议；l 当进行配置项测试或系统测试时，当需要时，测试总结中应对配置项或系统的性能做出评估，指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。4. 分析本测评项目中的数据和文档，以供以后的测试适用。数据如：缺陷数据（包括缺陷描述、类型、严重性等）、用例数据、管理数据（如生产率、工作量、进度等）；文档如：用例设计、需求规格说明等。5. 测试人员应该根据软件测评任务书、合同（或其它等效文件）、被测软件文档、测

26、试需求规格说明、测试计划、测试说明、测试记录和软件问题报告单等有关文档，对测试结果和问题进行分类和总结，按所确定的文档要求编写测试报告或测评报告。测评报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议，测评报告和测试报告有时可以合并。6. 测试总结评审应在以上的各项工作完成后进行，以确定是否达到测试目的，给出审核结论。审核的具体内容和要求是：l 审查测试文档与记录内容的完整性、正确性和规范性；l 审查测试活动的独立性和有效性；l 审查测试环境是否符合测试要求；l 审查软件测试报告与软件测试原始记录和问题报告的一致性；l 审查实际测试过程与测试计划和测试说明的一致性；l 审查测试说明

27、评审的有效性，如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性；l 审查测试结果的真实性和正确性。2.2.2测评规范测评规范的制定将覆盖以下内容：1. 规范对测评人员及测试环境的要求2. 规范对被测软件的状态要求3. 规范不同软件等级的测试要求l 不同软件等级对测试级别的要求l 不同软件等级对某一测试级别中测试类型的要求4. 规范对每个过程的技术要求5. 规范不同测试阶段测试所需文档和程序要求6. 规范每个阶段的参与角色及参与方式、进入准则、业务活动、输出成果、退出准则7. 制定软件测试项目管理规程（含公司内部软件测试项目、公司外部软件测试项目）2.3 软件测评支撑过程2.3.

28、1 配置管理一、项目需求本部分对应项目需求测试管理（REQ13）中软件测试变更管理及软件配置管理（REQ29）。包含但不限于如下要点：1. 根据集团公司实际及软件测评规范化的需要，制定合适的配置管理办法（至少包含：在配置管理中定义测试相关的配置发布流程和配置发布状态报告，支撑预测试、版本回退、临时版本、版本事故的处理等）。2. 制定软件数据包命名及管理规范。3. 制定软件版本命名及管理规范。4. 制定软件测试变更管理规程（如：测试方案变更、测试用例变更、测试脚本变更，等等）。二、提升方案配置管理作为软件研发流程中一个重要支撑过程，同样适用于软件测试流程管理，配置管理的目的是为了保证项目产品的安

29、全性、机密性，保证软件产品的完整性、有效性及可追性。软件配置管理主要包括五个主要方面，即配置项的标识、对配置项修改的控制、配置管理状态报告、配置管理活动审计和实现自动化的构建与发布。在软件配置管理的五个主要方面中，很明显，标识是基础，即首要的第一步是要确定哪些对象需要纳入到配置管理的控制之下；接下来需要确定如何控制对这些配置项的修改，包括环境的搭建，用户授权，开发流程等等；随后，要及时向团队成员报告软件配置管理的状态，履行告知的义务，以及进行审计，确认相关的软件配置管理活动确实按照预定的计划高质量地完成了。这五个方面，软件配置管理工具都要进行强有力的支持，使得日常事务减至最少，这是一个成熟的软

30、件配置管理工具应具备的基本特征。企业要实施软件配置管理常常面临的第一步就是要选择合适的工具，在此将列出一个成熟的软件配置管理工具应该具备的特征：v 配置项（对象）管理 版本控制 配置管理 并行开发支持 基线支持v 构建与发布管理 能利用流行的构建工具:ANT/MAKE 支持多平台构建 支持并行构建 能自动处理构建依赖关系 能收集和维护重新产生之前构建所需要的信息v 工作空间管理 能自动跟踪工作空间中所有类型的变更 能应用不同配置填充工作空间 工作空间既允许隔离又允许更新v 流程管理 不同类型的对象都应具备流程定制能力 流程的范围可定制 支持测试与发布流程v 分布式开发的支持 负载均衡v 与其他

31、工具的集成能力 变更请求工具 开发工具 其他CASE工具 命令行，SDKv 易用性、易管理性 报告能力 架构的弹性我们将在对目前公司既有配置管理工具进行调研和诊断的基础上，选定适合公司企业需要的配置管理工具，并指定相关配置管理办法，包括软件版本命名及管理规范、数据包命名及管理规范、软件测试配置项（如测试方案、测试用例、测试脚本等）变更管理办法。对于配置工具的使用，根据我们的实践经验，建议以PLM为统一的产品管理平台，将所有过程文档通过PLM进行版本管理。软件代码编写过程的版本管理由于独立性较强，现阶段可在软件未定型时选用现有的操作较简单的SVN进行配置管理，编译定型后统一提交到PLM进行管理。

32、下一阶段建议试用PLM新版本中新增的代码版本管理模块softwareLink，在成熟稳定时将软件配置管理统一到PLM里。2.3.2 质量管理本项目招标书中对质量管理的需求定义：1. 制定整个软件生命周期中的软件缺陷闭环管理机制（至少包含：缺陷分类定义、属性定义、度量指标定义、完善的软件缺陷管理流程等），视情况选择相应的缺陷管理工具（可提出相应的缺陷管理工具功能需求，由PLM系统改进、完善实现缺陷管理功能，或者提供专业的缺陷管理工具，但需考虑并实施与PLM系统的接口、融合）。2. 制定软件测试质量的衡量准则。3. 制定软件产品质量度量准则。4. 培训、指导软件测试质量度量的技术与方法。5. 培训

33、、指导软件度量及其过程、软件质量的度量、质量度量的统计方法，等等。我们认为以上需求涉及软件质量管理、未涉及对测试本身如何进行质量管理与控制，我们将在软件测评过程能力提升方案中补充测试过程的评审、测试过程质量保证、测试数据的核查与控制。一、 软件质量管理针对项目需求，以下将从软件质量评价、软件测试质量评价及软件缺陷管理进行阐述：1. 软件质量评价目前比较常用的软件质量评价标准有：国际标准ISO/IEC 9126软件质量特性、国家标准GB/T162601996软件产品评价、质量特性及其使用指南，我们将参照这些标准从软件产品的使用质量、外部质量及内部质量定义软件的质量特性及子特性，结合南车项目的特点，分别明确不同度量指标的权重范围，形成易于操作的软件质量度量模型构建的指导书。基于确定的质量度量模型，根据收集测试缺陷的数量、等级、来源、等情况，针对不同软件项目的性质，给出相对客观的评价结果。2. 软件测试质量评价至于软件测试工作的评价，则不能简单地