软件测试规范.docx

《软件测试规范.docx》由会员分享，可在线阅读，更多相关《软件测试规范.docx（27页珍藏版）》请在三一办公上搜索。

1、软件测试规范软件测试规范 由安博测试空间技术中心 1 目录 一、简介 . 3 软件测试的定义. 3 软件测试类型的划分. 3 测试中权衡的三个重要维度 . 4 不同阶段测试精度的把握. 4 测试顺序 . 4 二、测试工作流程 . 5 测试准备 . 5 测试的实施 . 5 测试问题处理流程. 7 测试验收 . 8 测试总结 . 8 三、测试人员的组织与培训. 8 测试人员的组织. 8 测试人员的培训. 10 四、测试工作机制会议与讨论. 11 测试工作启动会议. 11 阶段性会议 . 11 专题会议 . 12 讨论 . 12 五、测试案例的编写 . 12 案例编写的原则. 12 测试案例的取舍.

2、 13 六、测试相关文档 . 14 测试计划书 . 14 测试方案书 . 15 测试报告 . 17 其他文档资料 . 18 2 一、简介 软件测试的定义 软件测试的定义是“为了发现程序中的错误而执行程序的过程”。具体地说，软件测试是根据软件开发的产品设计说明书和程序的内部结构而精心设计出一批测试案例，并利用测试案例来运行程序，以发现程序错误的过程。 软件测试类型的划分 软件测试贯穿于整个开发过程中，软件系统的开发过程是一个自顶向下逐步细化的过程，而测试过程则是按相反顺序进行的集成过程，根据测试的阶段、测试的执行人，可划分为：单元测试(unit testing)、组合测试(incremental

3、 integration testing)、集成测试(integration testing)、系统测试(system testing)、用户验收测试。根据测试内容的不同可分为:功能测试(functional testing )、安全性测试(security testing)、恢复测试(recovery testing )、兼容性测试、容错性测试、性能/压力/负载测试(performance /stress /load testing )、安装/卸载测试(install/uninstall testing )在本文中,我们使用测试阶段的划分标准。 图一:软件生命周期“台阶”模型图: 发布阶段

4、立项阶段 集成测试计划阶段 需求阶段 单元测试/组合测试 测试阶段 编码阶段 设计阶段 集成测试系统测试阶段 阶段 系统测试计划阶段 3 测试中权衡的三个重要维度 测试时间、测试成本和测试质量构成测试过程中需要关注的三个重要维度，三个维度相互制约、相互影响。在测试中，永远无法实现时间、成本和质量的三赢，为其中任何2个目标所做的努力，都必须以付出第三个目标的损失为代价，此外我们永远都不可能穷尽所有的测试内容。因此必须综合权衡作出取舍。 图二：制约测试的三个要素 不同阶段测试精度的把握 考虑到测试时间、测试成本的制约，在不同的测试阶段，对测试精度有不同的要求。从单元测试、集成测试到系统测试、用户验

5、收测试阶段，对测试精度的要求也呈现一个从粗到细的过程。单元测试是发现错误最多、预防质量隐患最重要的测试阶段，需要最大的测试精度，缺少单元测试，直接进行集成和系统测试，缺陷隐患多。 图三：不同测试阶段测试精度模型图 时间 质量 成本 单元测试 集成测试 系统测试 用户验收测试 工程安装测试 测试顺序 对于一项复杂产品的测试，遵循一定的测试顺序，可以是测试工作有条不紊，提高测试工作效率。同时按照一定的测试顺序展开测试，一定程度上可以确保测试工作的全面性。 测试顺序的原则是由浅入深、由易而难。在具体的测试内容上表现为： 先联机测试后批量测试； 首先单元测试，其次集成测试，然后进行系统测试及验收测试；

6、 4 先进行基本功能测试再进行辅助功能测试； 先进行正常情况案例的测试，再进行反常情况案例的测试； 对于一项交易先进行输入项的测试，再进行输出项的测试，然后进行账务处理的测试。 二、测试工作流程 测试准备 在技术实现编码阶段的工作结束时，进入产品的测试准备阶段，为真正开展产品测试做好前期准备工作。 测试准备阶段的主要工作包括制定测试工作计划、设计测试方案、组织协调测试人员、测试所需硬件设施等其他准备工作。测试准备阶段的工作由参加产品设计说明书的主创人员负责完成。 1、 制定测试工作计划和测试方案 相关内容见测试文档编写 2、 组织协调测试人员 根据测试计划和测试方案，组织协调相关人员，形成测试

7、工作组。 3、 测试人员的培训 正式开展测试工作之前，对所有测试人员进行测试工作的集中培训。通过测试培训，使测试人员明确测试目标和要求、了解待测系统、统一测试方法和流程，保质保量的开展和进行测试工作。 4、 测试所需要硬件设施和其他准备工作 与相关部门联系协调对测试工作所需的设施：服务器、测试机等在测试准备阶段全部到位。 测试的实施 测试实施是软件测试工作的核心阶段，测试实施阶段严格按照测试计划和测试方案展开。 1、 搭建测试环境 5 根据产品的实际需要搭建的运行环境及准备相关测试所需初始数据。包括：测试人员、测试工具等。 2、 单元测试 单元编码完成后，进行单元测试。单元测试指构建者的角度出

8、发，检测产品的各个部分是否是正常、合理、安全的，换句话说，就是通过检测要保证软件产品满足用户操作的质量标准。 单元测试关注的重点是产品的内部结构、框架以及技术实现是否符合产品设计说明书等等。 单元测试可以并行进行。对于彼此独立的单元，进行并行测试可以加速测试的进程。 单元测试按照测试进程可分为联机功能测试和批量功能测试两个阶段，其中批量测试阶段需要建立手工账，以便于同系统处理结果相互核对。 3、 集成测试 集成测试在所有单元测试完成之后进行。集成测试也称综合测试，即将已分别通过测试的单元按要求组合起来再进行的测试，以检查这些单元之间的接口是否存在问题。或按设计要求把通过单元测试的各个模块组装在

9、一起之后，进行测试以便发现与接口有关的各种错误。 集成测试的重点是各个模块之间的接口的功能进行测试。 4、 系统测试 系统测试是整个测试阶段的最后一步，所有的开发和测试在这一点上，集中表现为生成一个具有一定功能的软件系统，整个系统开发完成，即将交付用户使用。 系统测试主要对系统的准确性及完整性等方面进行测试。分别进行：运行测试、强度测试、恢复测试、安全性测试等。 目前系统测试的主要工作由技术人员完成，业务测试人员协助工作。 5、 需求维护 需求维护指测试过程中根据每项测试结果发现前期需求不合理之处并对其进行相应的调整和改正。 需求维护工作贯穿整个测试过程。 测试阶段的需求维护工作是整个产品产生

10、过程中需求维护工作的一部分。 6 测试问题处理流程 测试问题处理流程可以采用以下两种形式 形式1： 底 层程序问题，*人员修改 形式2：备选 开发人员完成单元测试，填写“功能测试申请单” 给测试人员进行测试 底层程序问题， *人员修改 将“问题报告单”返回给测试人员 测试人员再次测试确认 仍存在问题，返回开发人员 开发人员完成单元测试，填写“功能测试申请单” 给测试人员进行测试 测试人员签收，进行功能测试。发现问题，填写“问题报告单”给后开发人员处理 开发人员，根据“问题报告单”进行分析处理 界面问题，*人员修改 涉及接口问题，填写“界面变更申请单”，由底层与界面人员共同协商 将“问题报告单”

11、返回给测试人员 业务人员再次测试确认 仍存在问题，返回开发人员 确认无误，通过 测试人员签收，进行功能测试。发现问题，分析问题缘由，填写“问题报告单” 界面问题，*人员修改 涉及的接口问题，填写“界面变更申请单”，由底层与界面人员共同协商 确认无误，通过 7 形式1与形式2之间的主要差别在于测试问题的分析流程，形式一由开发人员对测试问题统一分析，查明原因后交给相应的人员解决修改；形式二业务人员在测试中发现问题后，继而分析问题缘由，由测试人员将问题交给相应人员解决修改。 测试验收 测试验收阶段的主要工作是：以客户使用的角度，再次确认系统的可操作性、正确性、全面性和完整性。为产品的上线应用、推广营

12、销最后把关。 测试验收工作相关业务由上海总部及西安研发部共同组织人员负责。 测试验收阶段依旧沿袭测试实施阶段使用到的各种测试形式和方法，依据测试实施阶段产生的测试问题报告单、交易记账凭证、报表、测试案例单、阶段性测试总结等各种文档和资料展开。 测试总结 测试总结阶段是测试工作的最后一个阶段，要进行以下四项工作： 1、 对测试阶段工作完成情况、工作方法进行总结。 一方面总结好的方法和经验用于指导将来的测试工作；另一方面发现不足需改进之处，引起借鉴，并在今后的工作中加以避免。 2、对测试验收阶段的遗留问题的进行汇总、统计和分析，并提出解决和修改建议。 3、整理文档。 包括：产品设计说明书最终版本、

13、产品培训教材、产品操作手册以及测试阶段生成的各种文档资料。 4、编写测试报告。 详见相关测试文档规范。 三、测试人员的组织与培训 测试人员的组织 1、具体组织形式 8 项目经理 测试组 支持组 * * * * 测试工作的组织形式分为项目经理、测试组、支持组。项目经理负责全面地组织和协调工作。测试的工作实体(最小组织单位)是测试组和支持组，分别设组长全权负责。测试组由测试人员组成，负责测试案例的编写、具体的测试操作、测试问题的记录与反馈，以及对已修改问题的回归测试和验收等工作。根据测试工作内容的具体需求，测试组可以按照业务种类或其他分为若干小组开展工作。支持组由朱莉负责主要工作是测试的后勤保障和

14、日常管理工作，如网络管理、数据备份、文档管理、设备管理和维护、日常事务管理和检查等。 2、主要职责 项目经理 职责： 拟定产品测试阶段的总体工作思路、测试方案等。 产品测试阶段测试人员、支持人员的组织工作。 把握工作进度，监督、控制、督促产品测试工作按计划进行。 对测试组和支持组的工作进行必要的沟通和协调，建立测试组与支持组相互配合、支持、协作的桥梁。 对产品测试阶段工作的总结和评估；包括分阶段性工作、总体工作的总结与评估。 与相关部门就测试工作所需的软、硬件设施进行沟通和协调；如：测试工作场地、网络环境、所需设施、其他凭证、报表等。 参与产品测试阶段的具体测试工作。 测试组组长 9 职责：

15、拟定产品测试阶段的总体工作思路、测试计划、测试方案等。 组织本组测试人员的开展本组负责的测试工作，包括组员的工作安排、工作检查和问题反馈等。 把握工作进度，监督、控制、督促本组测试工作按计划进行。 与支持组互相配合、支持、协作。 对测试组工作的总结和评估；包括分阶段性工作、总体工作的总结与评估。 对产品测试中发现的问题总结、分析，形成问题报告单，与支持组进行沟通。 参与产品测试阶段的具体测试工作。 支持组 职责： 对测试组的测试工作进行业务、技术以及后勤设备各方面的支持。 与测试组互相配合、支持、协作。 日常测试支持性工作。 参与产品测试阶段的具体支持工作。 测试人员 职责： 根据测试方案编写

16、测试案例。 按照测试计划开展所负责的测试工作。 提交问题，协助测试组长完成问题报告单。 测试工作中需求的解释和维护工作。 配合测试组长对测试阶段工作进行总结；包括分阶段性工作、总体工作的总结。 组长分配的其他工作。 测试组成员应对熟悉负责测试的业务，参加过产品测试工作，掌握一定的测试方法和技巧。 测试人员的培训 1、培训人员的选择 在测试准备阶段要首先确定进行培训的人员。 10 进行测试培训的培训人员应参加过前期产品设计，对所测产品的创意、产品构架、业务流程、主要功能等方面非常熟悉；具测试工作经验，参加过产品测试工作，熟悉测试工作流程，掌握一定的测试方法和技巧；同时具有培训经验，擅长沟通和表达

17、。 2、培训内容 测试培训包括两方面内容：一方面是测试方法和技巧、测试形式、相关测试工具等；另一方面围绕产品设计说明书对待测产品进行详细的介绍和讲解，其中重点在于新产品的突破创新之处、整体架构、业务流程、主要功能等。 3、培训形式 培训形式以授课方式为主，包括讲授和基本操作的演示。培训课程之外可以采用测试经验交流、提问和讨论等各种形式对培训课程未能涉及的方面进行补充。 四、测试工作机制会议与讨论 会议是测试工作中进行沟通和交流的有效的方式和手段。 测试工作启动会议 在启动会议中要明确测试工作的目标、任务，协调人员配置，强调工作纪律。同时会议应详细介绍测试工作计划和方案，使与会的测试组成员明确测

18、试工作的整体思路、各自的主要工作和责任，做到心中有数。测试工作启动会议是测试工作的开端，标志着正式进入产品测试阶段。 测试工作启动会议由测试主管主持，测试工作组全体成员和非测试组成员代表参加。 阶段性会议 不同测试阶段的测试工作重点不同，召开阶段性会议，对前阶段的测试工作进行总结，同时对下阶段的测试工作进行安排。包括强调测试重点、介绍此阶段的测试方法和形式、人员的调整和分工、需要完成的相关文档等内容。 阶段性会议由测试主管支持，测试工作组全体成员参加。 阶段性会议也可由测试组、支持组组内定期召开，对本组阶段性工作进行总结和下阶段工作的安排。 11 专题会议 测试过程中测试组、支持组，或测试组与

19、支持族之间针对某个测试工作中具体问题的商议、解决可以采用专题会议的形式 针对具体问题的专题会议可以召集会议主题涉及到成员参加。 讨论 讨论是测试工作中进行沟通和交流的另一种有效的方式和手段。 对于测试工作中发现的一般性问题，由测试组通过组内讨论，研究解决方案，组内自行解决。 对于测试工作中发现的重大问题，测试组以及其他相关开发人员展开讨论，共同协商，寻求解决方案. 五、测试用例的编写 测试过程中每笔交易或每项操作都要根据专门编制的具体案例进行。 案例编写的原则 案例编写应遵照完整性、针对性、关联性和规范性四项原则。 1、完整性 完整性也可以理解为全面性，指设计测试案例要同时考虑到系统实际运行情

20、况中可能会出现的各种情况，并通过测试案例的模拟操作，发现问题，完善产品。 为了保证案例编制的完整性，在编制案例时从以下方面入手： 从案例编制的整体考虑，应覆盖所测产品业务流程中的每项交易； 针对单项交易编制的案例应从人机交互、业务逻辑、账务处理等方面考虑。 一般情况下，首先该交易操作的每项输入项都是一个测试点，根据输入性的性质取值类型分别设定该输入项的正常值、边界值以及越界值进行测试。对于列表选择的输入项，要充分考虑到不同输入项的不同列表取值的组合情况。对于不同的组合测试案例中要穷举。 其次考虑单个交易内部的业务逻辑，例如：各输入项之间的相互制约、相互控制的关系 12 产品自身状态对交易的限制

21、、相关制度对具体产品的规定等。 要考虑到每项金融性交易的相应的账务处理。 通过对每项交易输出项是否完整、正确， 能否如实反映账务处理的检验，验证系统对该项交易的处理过程。 对于每项交易的每个测试点，不仅仅要考虑正常发生的情况，还要同时兼顾反常情况下系统的处理及反映。如：对于错误信息的输入，系统是否进行控制、是否给与相应的错误提示等。 确保案例编制的完整性，可参考技术人员提供的错误信息代码，根据错误信息提示的情况，编制案例。 系统每个层次的显示界面是否合理、全面、美观，是否符合操作者的使用习惯。 2、针对性 针对性指每个测试案例要明确测试意图。一方面要考虑各种复杂的实际应用情况系统地规划，避免出

22、现对任何功能的遗漏，同时编制一个案例应尽可能多的涉及该系统各项功能，避免出现大量案例重复编制，无意义地加大工作量，降低了效率。 3、关联性 关联性，一方面指整个系统各个交易之间的关联性；另一方面指单项交易涉及到的各个要素之间的内在关系。 例：一个用于贷款业务的测试案例设计时要考虑放款、还款、展期、形态转移等一系列交易及相互的影响和控制。另外所有查询类、报表类交易也都基于基本交易的结果和基础上进行。 单项交易涉及到的各个要素包括：产品科目、期限、利率及静态表的维护之间的相互关联。 4、规范性 测试案例要严格依据产品设计说明书编制。同时为了便于统计和管理，应按照统一的格式、编码、内容和规范进行编制

23、。 测试案例的取舍 在测试过程中，如果待测试软件功能复杂，在受测试时间和测试资源限制的情况下，不可能将测试资源平均用于所有案例测试，因此我们在测试案例的编写过程和测试过程中需要 13 对测试内容按照功能和内容对测试案例进行优先等级的划分，以把握测试和验收重点。 测试案例划分的方法简单总结如下，供参考： “功能优先级”的划分标准为： 󰀀3.重要功能； 󰀀2.一般功能 󰀀1.不常用功能； “内容优先级”的划分标准为： 󰀀3.正常情况； 󰀀2.重要的异常情况； 󰀀1.不重要的异常情况。 案例优先级 功能优

24、先级 X 内容优先级 󰀀其取值范围为：9、6、4、3、2、1 举例：“ *宝客户签约，正常情况” 功能优先级=3 内容级别=3 案例优先级=3*3=9 六、测试相关文档 测试计划书 测试工作计划是测试工作开展的基础，测试计划为整个测试工作建立完整的框架结构，是测试工作的起始步骤和重要环节。制定测试工作计划书应该包括以下方面： 1、测试项目的基本简介 通过测试产品基本情况简介使测试者对所测试的产品有所了解，形成整体认识。 测试产品基本情况的介绍应该围绕该产品创意展开，主要包括产品项目背景、项目目标、业务范围、产品及核算架构、与其他子系统的关系等五方面内容。 2、测试工作进度安排

25、测试工作时间安排是测试计划的核心内容之一，按照测试工作内容、进程，排定时间表。测试工作时间表不仅统筹整体工作进展，并且应将具体的工作内容细化到周或工作日。另外，14 时间表中还应考虑到测试工作分阶段进行的阶段性总结与反馈。 3、测试策略 测试策略对测试工作进行指导，针对具体问题具体分析，对不同情况提供具体的处理和解决方法。例如：对于测试中出现的重大事故问题，集合技术人员和业务人员共同召开会议研究；对于测试组内对于某问题产生的不同意见，采用小组讨论的形式解决等等。 4、测试记录 测试记录指对测试工作详细、完整的文档纪录。包括：阶段性的测试工作总结、测试问题报告单、测试问题工作量统计表、测试案例单

26、等。 5、测试资源配置 一方面包括测试工作所需的硬件设施：测试环境等。另一方面包括测试工作需要的测试人员的组织。 测试计划完成之后，应与技术人员进行讨论、协商，对完成的测试计划进行评审，形成反馈意见，并对测试计划修改和完善，形成最终予以实施的版本。 测试方案书 测试方案具体指导测试工作的开展、进行；是测试工作实施的依据。全面、合理的测试方案一定程度上能够推动测试工作的进展，提高工作效率。 设计出全面、合理测试方案，做到心中有数，是测试准备阶段的重要工作之一。完整的测试方案应包括以下方面： 1、测试目标、原则和要求 测试是保证软件产品质量最重要的手段。目的在于检验软件是否满足规定的需求或是弄清实

27、际结果和预期结果之间的差别。寻找程序错误，寻找与用户需求不一致和存在的缺陷。以较少的案例、时间和人力找出软件潜在的各种错误和缺陷，以确保系统的质量。具体表现在以下几个方面：(1)确保软件产品达到需求功能的说明；(2)确保软件产品满足性能需求；(3)确认程序能够处理用户要求的负载；(4)确保软件产品在要求的硬件和软件平台上工作正常。 测试工作按照全面性、有效性和正确性的原则进行。 全面性指测试工作应涵盖所测系统所有交易，包括金融类和管理类交易，并需检测系统在各时段运行时的功能实现情况。 15 有效性指以实际业务情形为基础，从可操作性等方面进行测试，检测系统是否已满足营业网点和管理行各项业务处理和

28、管理的需要。 正确性指检测系统业务处理流程的正确合理性、账务组织的完整性、金融性交易账务处理的正确性以及会计和业务统计报表真实、准确性. 测试工作的要求包括测试工作的完成情况和工作态度两方面的要求。 2、测试内容、范围 根据所测试的金融产品的主要业务和功能，确定测试内容和范围。例如资产业务系统的测试工作内容指主要的资产业务，包括个人贷款、对公贷款、质押贷款、系统内拆借、同业拆借、委托贷款、贴现、转贴现以及额度管理等业务的测试。 3、测试方式 测试方式指测试工作不同的切入点和不同方面。即测试工作需要从几下方面分别进行： 常规性测试指模拟实际业务正常发生情况进行的测试。 反常规性测试指针对除实际业

29、务正常发生情况以外的非正常情况进行的测试。通过反常规性测试，检验系统是否进行了相应的控制，能否做出正确的反馈。 验收测试是从用户的角度出发，也可以由产品的使用者来对产品进行的检测。使用者关注的重点是使用产品的感受，关心软件的界面是否美观、菜单的位置是否合适，各个交易的操作是否方便，是否能够满足使用者的需要等，通过验收测试认定该软件产品是否满足规定的质量要求。 回归测试指对测试过程中发现并提交问题的修改结果进行再次测试和验收。 完整的测试工作应同时从以上方面着手，兼顾全面。 4、测试依据 测试依据指测试工作得以正常开展所参考的相关制度和资料。包括产品设计说明书、测试计划、相关管理制度和规定等。

30、5、测试环境 测试环境指建立测试硬件环境、软件环境、网络环境、测试数据、账务环境等。 6、测试人员与职责说明 测试方案中应根据所测试系统的具体内容和要求，对参加测试的人员进行安排和分工。包括人员分组、指定责任人并根据测试进程确定每个测试人员具体工作任务等。 7、测试问题处理流程 测试问题处理流程指测试人员、后台技术人员、前台技术人员对测试中发现的问题处16 理解决的具体的过程。即谁发现问题，交由谁进行分析，由谁具体解决等，建立统一的责任和规范。 测试方案要对测试处理问题处理流程进行明确。 8、测试案例 根据实际业务发生情况模拟编制的用于检测每项交易的输入项、输出项、账务处理等方面正确性、全面性

31、、合理性的实例。 详见附件。 测试报告 完整的测试报告应包括以下几方面： 1、测试任务 概要说明本次测试所承担的具体任务及应达到的目标。 2、测试组织方案 测试时间 描述整个测试工作的起止时间。 测试地点 描述测试工作的具体地点。 测试环境 描述测试工作所应用的硬件及软件环境。 硬件 设备类型 主机 终端 打印机 软件 软件类型 操作系统 数据库 开发工具 应用软件 配置 数量 名称 17 其他 人员安排 描述参与测试的人员应承担的工作任务及职责。 姓名 所属部门 职责 3、测试情况回顾 测试数据准备 描述为测试工作进行的必要的数据准备。 测试案例准备 概要描述案例种类及数量等，并将测试案例单

32、作为附件。 测试功能及结果 按照具体交易分别描述交易功能及测试结果。 交易代码 交易名称 功能描述 测试结果 测试员 测试中出现问题的统计 交易代码 4、总体评价 对整个测试工作的任务完成情况、与其他部门配合情况及需要在以后的测试中注意的其他问题等进行总结。 其他文档资料 附件一：测试案例单 18 交易名称 问题描述 类型 测试员 附件二：测试问题报告单 附件三：测试问题汇总统计表 附件四：需求变更申请单 附件五：需求变更记录表 附件六：功能与案例对照表 附件一： 测试案例单 编号: 子系统 名称 测试说明 交易码 名称 人员 时间 交易测试测试测试初始数据准备 测试案例 预期结果 实际结果

33、是否通过 是 否 19 测试案例 预期结果 实际结果 是否通过 测试案例 预期结果 实际结果 是否通过 附件二： 测试问题报告单 报告单编号： 子系统名称： 测试案例单编号： 交易码： 交易名称： 是 否 是 否 涉及平台：UNIX AS400 ES9000 测试日期： 问题描述： 问题发现人签字： 日期： 测试问题报告单 20 测试负责人签字： 日期： 问题修改人签字： 日期 备注： 报告单编号： 子系统名称： 涉及平台：UNIX AS400 ES9000 测试日期： 问题描述： 问题发现人签字： 日期： 附件三： 测试问题汇总统计表 产品名称 程序版本 程序提交日 开发人员 结果 测试负责人签字： 日期： 问题修改人签字： 日期 备注： 测试案例单编号： 交易码： 交易名称： 序号 案例编号 测试问题描述 测试人员 是否修改 修改方案/不修改原因 21 附件四： 需求变更申请单 年 月 日 编号： 业务种类： 申请人： 组长： 希望完成日期： 实际完成日期： 需求描述： 22 反馈意见： 经办人： 组长： 附件五： 需求变更记录表 修订时间 修订人 修订内容 版本 审批人 备注 23 附件六： 功能与案例对照表 序号 功能编号 功能名称 案例编号 案例名称 24 25