软件集成测试工作流程规范V1.0
系统集成测试记录
长沙合珏信息科技有限公司系统测试记录版本修订目录1范围 (3)1.1标识 (3)1.2系统概述 (3)1.3文档概述 (4)1.4与其他计划之间的关系 (4)2引用文档 (4)3系统集成测试 (4)4项目列表功能测试 (4)1范冃1.1标识本文档适用于睿联信项U,为系统集成测试记录。
文档标志号：HJ-RLX-20160301-XTJCCSJL名称：集成测试记录版本号：V1.01・2系统概述睿联信（II Link）是市面上先进、全面的数据访问、集成、分析及报告系统。
通过对数据字段的组合处理，建立能够唯一标识一个实体的对象，利用对象之间的共性，建立关联关系，这也是E-R （实体-联系）图的宗旨内容，它是描述现实世界概念结构模型的有效方法。
通过该方法，睿联信系统完成了数据到信息的转换，利用人的业务经验和思考逻辑, 建立合适的模型，完成数据、信息、知识的结合，以达到智能分析数据的目的。
项LI建设一套先进强大的集数据管理、分析、挖掘和模式发现技术于一体的大数据软件系统。
系统主要分为服务器端和客户端，服务器端包含数据源管理、用户/权限管理、建模与模型管理等；客户端包含搜索、关联搜索、视图、报表等内容。
1 -3文档概述本文档对系统集成测试结果进行必要的记录说明，并提供给项口需求分析人员、软件系统设计、开发和测试人员、测试人员以及最终用户使用。
未经甲方书面许可，不得提供给上述规定对象以外的人员阅读或使用。
1-4与其他计划之间的关系无2引用文档《软件技术要求》《需求规格说明书》《系统设讣说明》《软件测试计划》《软件测试规范》《软件测试说明》3系统集成测试一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。
一些局部反映不出来的问题，在全局上很可能暴露出来。
系统集成测试将已经通过单元测试的模块组装成子系统或者更完整的功能模块（如创建对象、创建关联组装在一起形成完整的创建模型功能），测试两个独立的模块经过组装后是否能够按照设计完成所需功能的过程。
集成测试计划-V1
可行性分析报告编号: S201001-05版本: V1.3 通用仓库管理系统集成测试计划项目组：Sixers编写人：复查：2010-3-31文档修改记录说明目录1.引言 11.1目的 (2)1.2范围 (2)1.3术语 (2)1.4测试环境 (3)1.5参考文件一览 (3)2.集成策略 (4)2.1进入标准 (4)2.2集成元素 (4)2.3集成策略 (4)2.4集成顺序 (5)3.测试步骤描述 (6)3.1软件集成测试 (6)3.2软件/硬件集成测试 (8)3.3子系统集成测试 (8)3.4功能测试 (8)4.集成测试验收标准 (9)4.1模块验收标准 (9)4.2集成测试验收标准 (9)5.测试工具 (10)5.1测试工具 (10)6.挂起、恢复和退出条件 (11)6.1挂起 (11)6.2恢复 (11)6.3退出 (11)7.责任人和时间表 (12)8.记录和解决问题 (13)9.重新测试程序 14第1章引言1.1目的本文是描述图书管理系统的集成测试的大纲文章, 主要描述如何进行集成测试活动, 如何控制集成测试活动, ,集成测试活动的流程以及集成测试活动的工作安排等。
保证程序连接起来也能正常的工作, 保证程序的完整运行。
1.2范围本次测试计划主要是针对软件的集成测试: 不含硬件, 系统测试, 以及单元测试（需要已经完成单元测试）主要的任务是：1.测试在把各个模块连接起来的时候, 穿越模块接口的数据是否会丢失；2.测试各个子功能组合起来, 能否达到预期要求的父功能；3.一个模块的功能是否会对另一个模块的功能产生不利的影响；4.全局数据结构是否有问题；5.单个模块的误差积累起来, 是否会放大, 从而达到不可接受的程度。
主要测试方法是: 使用黑盒测试方法测试集成的功能。
并且对以前的集成进行回归测试1.3本文主要的读者对象是：项目负责人, 集成部门经理, 集成测试设计师。
1.4术语软件测试: 软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例, 并利用这些测试用例运行软件, 以发现软件错误的过程。
SOP_Test_V1.0(白盒测试指导书)
白盒测试作业指导书技术文件编号：版本：版本变更记录文件编号版本拟制人/修改人拟制/修改日期主要更改内容1.0 吴威2009-4-21 无1.1 吴威2009-6-30 新增静态测试和覆盖率实施标准。
注1：每次更改归档文件（指归档发布数据库）时，需填写此表。
注2：文件第一次归档时，“主要更改内容”栏写“无”。
目录版本变更记录 (2)目录 (3)1. 简介 (4)1.1概念 (4)1.2目的 (4)1.3分类 (5)2. 静态白盒测试 (6)2.1概念 (6)2.2人工静态测试 (6)2.2.1测试方法 (6)2.2.2桌面检查 (6)2.2.3代码审查 (8)2.2.4代码走查 (8)2.2.4静态分析 (9)2.3静态工具分析 (10)2.4实施标准 (10)3. 动态白盒测试 (10)3.1概念 (10)3.2单元/代码功能测试 (11)3.3代码覆盖测试 (11)3.3.1语句覆盖 (11)3.3.2判定覆盖 (12)3.3.3条件覆盖 (13)3.3.4判定/条件覆盖 (13)3.3.5条件组合覆盖 (14)3.3.6路径覆盖 (14)3.4测试实例 (15)3.4.1程序控制流图 (15)3.4.2测试步骤 (17)3.5实施标准 (20)4代码质量度量 (21)4.1、功能性 (21)4.2、可靠性 (21)4.3、易用性 (22)4.4、效率 (22)4.5、可维护性 (22)4.6、可移植性 (22)1.简介1.1概念白盒测试(White-box Testing，又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。
利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。
白盒测试又称为结构测试和逻辑驱动测试。
1.2目的由Capers Jones与McGraw-Hill的统计表明：若将问题发现、定位与解决都计算进去，单元测试效率最高，是集成测试的2倍，是系统测试的3倍。
软件开发流程
软件开发流程V1。
0目录1.目的 (2)2.适用范围 (2)3。
定义 (2)4.输入 (2)5.输出 (2)6.角色职责 (2)7。
流程图 (2)8。
流程活动说明 (2)9.纪录和表格 (7)10。
相关文件 (8)11。
流程评测指标 (8)12。
流程负责人 (8)1.目的规范软件开发过程，指导软件开发人员执行软件开发活动，保障软件开发的顺利进行,确保软件开发进度、开发质量，达到预期目标；并为智力资产库提供输入。
2.适用范围本流程适用于产品研发过程中所有软件(包括固件)开发活动的执行过程3.定义4.输入《产品总体需求规格书》、《产品总体设计方案》5.输出5.1《软件概要设计报告》5。
2《软件详细设计报告》5.3《测试报告》5。
4 源程序（代码）5.5 可执行程序6.角色职责6。
1 PDT经理（LPDT)：根据需要参与软件过程中的评审.6。
2 系统工程师（SE）：参与软件开发过程中的评审,指导QA完成评审报告；6。
3 软件工程师（SWE）:编写软件概要设计报告、软件详细设计报告;进行软件编码并自测；进行单元测试、集成测试、系统测试，更新系统测试计划。
6.4 测试工程师（TE）：参与制定测试计划；参与软件开发过程中的评审；参与实施单元测试、集成测试以及系统测试。
6。
5 质量保证（QA）：组织、监控软件开发过程中的评审，开发文档的基线化。
6.6 软件配置管理员（CMO）：负责开发过程中的文档及代码的基线化.6.7 软件需求管理员（RMO）:负责开发过程中的需求跟踪.7.流程图见附件: 软件开发子流程-流程图。
8.流程活动说明010 制定软件项目计划开发组组长＆系统工程师&软件工程师&测试工程师根据产品的开发计划，制定产品软件部分的开发计划，包括进度、任务安排、风险、人员、开发工具、相关规范等内容.每个任务都需指定一个责任人;对于需要多人完成的任务,应当努力分解为多个单人可承担的子任务，以便计划的落实和跟踪.输入：《软件总体设计方案》输出:《软件项目计划》时间控制:得到《软件总体设计方案》后5个工作日内。
软件集成测试计划-模板
XXXXXX软件集成测试计划SRIJS-T0-/V0.0XXXX年XX月—1—目录1.介绍 (4)1.1目的 (4)1.2定义和缩写 (4)1.3参考资料 (4)2.测试内容 (4)3.集成测试策略 (4)3.1测试方法 (4)3.2测试环境 (5)3.3测试工具 (5)3.4测试接口 (5)4.测试活动计划进度 (5)5.准入/准出原则 (5)6.测试用例 (6)6.1维护接口 (6)6.2通信接口 (6)6.3I/O接口 (6)7.输出文档 (8)附录 (9)缺陷状态定义 (9)缺陷严重程度定义 (9)XXXXXX软件集成测试计划1.介绍1.1目的请在这里描述编制本文档的目的，并指明读者对象。
1.2定义和缩写1.3参考资料2.测试内容请描述本次集成测试的内容。
如：通过对XXXXXX设备中通信功能、服务接口功能、I/O功能进行软件集成测试，尽可能发现并改正软件中的错误，提高软件的可靠性，并且验证是否满足EN50128标准中关于SIL2等级认证和软件概要设计的相关要求。
3.集成测试策略集成测试也称子系统测试，是在所有模块都通过单元测试和子系统额功能测试成功的基础上，按照XXXXXX概要设计说明书的要求组合起来进行的接口测试。
3.1 测试方法集成测试将对概要设计中涉及到的对外接口进行黑盒测试。
3.2 测试环境描述测试所需的电气或自然环境、试验地等。
3.3 测试工具3.4 测试接口4.测试活动计划进度5.准入/准出原则准入原则：准出原则：如下表。
6.测试用例6.1 维护接口追溯编号测试用例对应的设计文档的功能编号，例如SWIOMGD003用例ID TC+项目缩写+测试阶段+XXX（001-999），例如TCIOMIT001功能描述例如，维护接口功能用例目的例如，测试维护接口功能是否正常前提条件例如，CPU模块硬件工作正常，以太网连接正常输入/动作期望的输出/响应测试结果例如，启动程序更新命令例如，下载完毕后，程序是否正常启动6.2 通信接口追溯编号SWIOMGD001用例ID TCIOMIT002功能描述CPU模块外部MVB通信功能用例目的测试与外部MVB设备通信是否正常前提条件CPU模块硬件工作正常，MVB设备连接正常输入/动作期望的输出/响应测试结果半实物仿真平台给出指定端口数值维护软件收到正确数值维护软件强制指定端口数值半实物仿真平台收到正确数值6.3 I/O接口6.3.1数字量输入接口追溯编号SWIOMGD004用例ID TCIOMIT003功能描述DI数字量输入功能用例目的DI数字量输入功能是否正常前提条件DI模块工作正常输入/动作期望的输出/响应测试结果I/O测试平台给DI模块的第1路采集通道输出高电平信号维护软件接收DI模块的第1路采集通道数字量信号为“1”I/O测试平台给DI模块的第1路采集通道输出低电平信号维护软件接收DI模块的第1路采集通道数字量信号为“0”I/O测试平台给DI模块的第2路采集通道输出高电平信号维护软件接收DI模块的第2路采集通道数字量信号为“1”I/O测试平台给DI模块的第2路采集通道输出低电平信号维护软件接收DI模块的第2路采集通道数字量信号为“0”I/O测试平台给DI模块的第3路采集通道输出高电平信号维护软件接收DI模块的第3路采集通道数字量信号为“1”I/O测试平台给DI模块的第3路采集通道输出低电平信号维护软件接收DI模块的第3路采集通道数字量信号为“0”I/O测试平台给DI模块的第4路采集通道输出高电平信号维护软件接收DI模块的第4路采集通道数字量信号为“1”I/O测试平台给DI模块的第4路采集通道输出低电平信号维护软件接收DI模块的第4路采集通道数字量信号为“0”I/O测试平台给DI模块的第5路采集通道输出高电平信号维护软件接收DI模块的第5路采集通道数字量信号为“1”I/O测试平台给DI模块的第5路采集通道输出低电平信号维护软件接收DI模块的第5路采集通道数字量信号为“0”I/O测试平台给DI模块的第6路采集通道输出高电平信号维护软件接收DI模块的第6路采集通道数字量信号为“1”I/O测试平台给DI模块的第6路采集通道输出低电平信号维护软件接收DI模块的第6路采集通道数字量信号为“0”I/O测试平台给DI模块的第7路采集通道输出高电平信号维护软件接收DI模块的第7路采集通道数字量信号为“1”I/O测试平台给DI模块的第7路采集通道输出低电平信号维护软件接收DI模块的第7路采集通道数字量信号为“0”I/O测试平台给DI模块的第8路采集通道输出高电平信号维护软件接收DI模块的第8路采集通道数字量信号为“1”I/O测试平台给DI模块的第8路采集通道输出低电平信号维护软件接收DI模块的第8路采集通道数字量信号为“0”I/O测试平台给DI模块的第9路采集通道输出高电平信号维护软件接收DI模块的第9路采集通道数字量信号为“1”I/O测试平台给DI模块的第9路采集通道输出低电平信号维护软件接收DI模块的第9路采集通道数字量信号为“0”I/O测试平台给DI模块的第10路采集通道输出高电平信号维护软件接收DI模块的第10路采集通道数字量信号为“1”I/O测试平台给DI模块的第10路采集通道输出低电平信号维护软件接收DI模块的第10路采集通道数字量信号为“0”I/O测试平台给DI模块的第11路采集通道输出高电平信号维护软件接收DI模块的第11路采集通道数字量信号为“1”I/O测试平台给DI模块的第11路采集通道输出低电平信号维护软件接收DI模块的第11路采集通道数字量信号为“0”I/O测试平台给DI模块的第12路采集通道输出高电平信号维护软件接收DI模块的第12路采集通道数字量信号为“1”I/O测试平台给DI模块的第12路采集通道输出低电平信号维护软件接收DI模块的第12路采集通道数字量信号为“0”I/O测试平台给DI模块的第13路采集通道输出高电平信号维护软件接收DI模块的第13路采集通道数字量信号为“1”I/O测试平台给DI模块的第13路采集通道输出低电平信号维护软件接收DI模块的第13路采集通道数字量信号为“0”I/O测试平台给DI模块的第14路采集通道输出高电平信号维护软件接收DI模块的第14路采集通道数字量信号为“1”I/O测试平台给DI模块的第14路采集通道输出低电平信号维护软件接收DI模块的第14路采集通道数字量信号为“0”I/O测试平台给DI模块的第15路采集通道输出高电平信号维护软件接收DI模块的第15路采集通道数字量信号为“1”I/O测试平台给DI模块的第15路采集通道输出低电平信号维护软件接收DI模块的第15路采集通道数字量信号为“0”I/O测试平台给DI模块的第16路采集通道输出高电平信号维护软件接收DI模块的第16路采集通道数字量信号为“1”I/O测试平台给DI模块的第16路采集通道输出低电平信号维护软件接收DI模块的第16路采集通道数字量信号为“0”7.输出文档●软件集成测试计划●软件集成测试报告●软件集成测试缺陷报告附录缺陷状态定义缺陷严重程度定义。
软件测试方案
1软件测试方案目录1概述.............................................................................................错误!未定义书签。
1.1软件测试流程实行方案................................................................. 错误!未定义书签。
1.2软件测试流程图............................................................................. 错误!未定义书签。
1.2.1测试工作总体流程图...................................................................... 错误!未定义书签。
1.2.2计划、用例阶段流程图.................................................................. 错误!未定义书签。
1.2.3单元/集成测试阶段流程图 ........................................................... 错误!未定义书签。
1.2.4系统测试阶段流程图...................................................................... 错误!未定义书签。
1.2.5验收测试流程图.............................................................................. 错误!未定义书签。
2测试资源和环境.........................................................................错误!未定义书签。
2-《信息化项目软件开发费用测算规范》（报批稿）V1.0D
2-《信息化项⽬软件开发费⽤测算规范》（报批稿）V1.0DICS35.080L77 DB11 北京市地⽅标准DB 11/T XXXXX—XXXX信息化项⽬软件开发费⽤测算规范Specification for software development cost estimating of information technologyprojects点击此处添加与国际标准⼀致性程度的标识（报批稿）（本稿完成⽇期：2013-5-6）-XX-XX发布-XX-XX实施北京市质量技术监督局发布DBXX/ XXXXX—XXXX⽬次前⾔ (III)1 范围 (1)2 规范性引⽤⽂件 (1)3 术语、定义和缩略语 (1)3.1 术语和定义 (1)3.2 缩略语 (4)4 软件开发费⽤构成 (4)4.1 费⽤构成 (4)4.2 直接⼈⼒成本构成 (5)4.3 直接⾮⼈⼒成本构成 (5)4.4 间接⼈⼒成本构成 (5)4.5 间接⾮⼈⼒成本构成 (5)4.6 ⽑利润构成 (5)5 软件开发费⽤测算 (5)5.1 软件开发费⽤测算过程 (5)5.2 规模测算 (6)5.3 ⼯作量测量 (7)5.4 ⼯期测算 (8)5.5 费⽤测算 (8)附录A（规范性附录）功能点计数基本规则 (10)附录B（规范性附录）参数表 (13)附录C（资料性附录）常⽤模板样例 (15)附录D（资料性附录）测算⽰例 (19)参考⽂献 (22)IDBXX/ XXXXX—XXXXII 前⾔本标准按照GB/T 1.1-2009的规则起草。
本标准由北京经济和信息化委员会提出并归⼝。
本标准由北京经济和信息化委员会组织实施。
本标准的主要起草单位: 北京软件和信息服务交易所有限公司、北京软件⾏业协会过程改进分会、北京宇信易诚科技有限公司、中科宇图天下科技有限公司、北京国铁华晨通信信息技术有限公司、北京中科汇联信息技术有限公司、北京合⼒⾦桥系统集成技术有限公司、远光软件股份有限公司、北京云星宇交通⼯程有限公司。
测试用例规范
测试⽤例规范版本号撰写⼈撰写时间备注v1.0.0⼤帅2021年2⽉01⽇创建⽂档1.⽬的统⼀⽤例编写的规范，为测试⼈员提供测试⽤例编写的指导，提⾼编写的测试⽤例的可读性，可执⾏性、合理性。
为测试执⾏⼈员更好执⾏测试，提⾼测试效率，最终提⾼公司整个产品的质量。
2.范围适⽤于集成测试和系统测试测试⽤例的编写，现在编写⽤例的辅助⼯具为禅道。
3.术语解释集成测试:集成测试是在软件系统集成过程中所进⾏的测试，其主要⽬的是检查软件单位之间的接⼝是否正确。
系统测试:系统测试是对已经集成好的软件系统进⾏彻底的测试，以验证软件系统的正确性和性能等满⾜其规约所指定的要求，检查软件的⾏为和输出是否正确并⾮⼀项简单的任务，它被称为测试的“先知者问题”。
4.测试⽤例原则4.1 系统性对于系统业务流程要能够完整说明整个系统的业务需求、系统由⼏个⼦系统组成以及它们之间的关系；对于模块业务流程要能够说明清楚⼦系统内部功能、重要功能点以及它们之间的关系；4.2 连贯性对于系统业务流程来说，各个⼦系统之间是如何连接在⼀起，如果需要接⼝，各个⼦系统之间是否有正确的接⼝；如果是依靠页⾯链接，页⾯链接是否正确；对于模块业务流程来说，同级模块以及上下级模块是如何构成⼀个⼦系统，其内部功能接⼝是否连贯；4.3 全⾯性应尽可能覆盖程序的各种路径;应尽可能覆盖系统的各个业务;应考虑存在跨年、跨⽉的数据;⼤量数据并发测试的准备;4.4 正确性输⼊界⾯后的数据应与测试⽂档所记录的数据⼀致;预期结果应与测试数据发⽣的业务吻合;4.5 符合正常业务惯例测试数据应符合⽤户实际业务流程⼯作;兼顾各种业务变化的可能;要符合当前业务⾏业法律，法规;4.6 仿真性⼈名、地名、电话号码等应具有模拟功能，符合⼀般的命名惯例;不允许出现与知名⼈⼠、⼩说中⼈物名等雷同情况;4.7 可操作性测试⽤例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果;5.测试⽤例主要元素标准规范中包含的主要元素如下:测试名称(Name)Test：测试⽤例编号和测试⽤例名称；创建⽇期(Creation Date)：测试⽤例创建时间；设计⼈员(Designer)：测试⽤例设计⼈员；状态(State)：测试⽤例状态；描述（Descrīption）：测试⽤例详细描述；步骤名称（Step Name）：测试步骤名称；步骤描述（Step Descrīption）：测试步骤详细描述；预期结果（Expected Result）：测试预期结果；6.测试⽤例编写规范对于每个功能，从类型1⾄类型N依次撰写相应⽤例;对于不满⾜要求的⾮常规类型，可以不写相应的⽤例;对于边界、空值、格式错误、溢出这⼏个类型，⼀个功能如有多个数据项测试类型相同，则可以放在⼀个⽤例⾥;测试⽤例均为最⼩的⽤例覆盖要求；对于没有提及的⽤例类型，视业务需求情况，撰写相应⽤例;在测试过程中，输⼊数据可在测试⽤例规定的范围内做⼀定变化;6.1 常规的测试⽤例对于⼀个功能⼀个模块（页⾯），每个数据项输⼊或选中典型的取值，⽣成⼀个⽤例;对于⼀个功能多个模块（页⾯），多个模块（页⾯）⼀起⽣成⼀个⽤例;对于多个功能⼀个模块（页⾯），每个功能⽣成⼀个⽤例;每个功能操作需覆盖，如删除对话框点击确定、取消分别⽣成2个⽤例步骤;输⼊框测试，在允许范围内尽可能覆盖多的字符类别，如中⽂、英⽂、数字等;对于每个功能点，必须通过⼀组（⼀个或多个）⽤例满⾜其业务覆盖：对于某条记录的每个状态，对于能进⾏的每个操作，都⽣成⼀个⽤例（即对业务功能流程中的每个⾓⾊，每个功能操作，⽣成⼀个⽤例）;6.2 初始化的测试⽤例进⼊功能模块（页⾯）后，某些控件会初始化填⼊数据，⽣成⼀个⽤例确保所有的初始数据正确6.3 边界的测试⽤例每个数据项，⽣成⼀个边界⽤例（含最⼤、最⼩两个边界值）;字符串数据以字符串长度为计量单位;布尔值数据的所有取值都需测试;多个复选框⼀组时，需测同时都被选中及都不被选中;下拉菜单、列表框、单选按钮组为最⼤、最⼩的2个取值;6.4 空值的测试⽤例对于每个必填数据项，都⽣成⼀个⽤例（不提供空值的除外，⽐如⽆空值的下拉框、有缺省值的单选按钮组），则预期结果提⽰该数据项为空;6.5 格式错误的测试⽤例对于输⼊框数据项，都⽣成⼀个⽤例，预期结果提⽰该数据项格式错误:⽇期输⼊框数字输⼊框字符串输⼊框：Email、邮编、⽤户名等带格式要求的6.6 溢出的测试⽤例对于输⼊框数据项，都⽣成⼀个取值范围外的测试⽤例，预期结果提⽰该数据项超出范围⽇期输⼊框:范围的⽇期输⼊框，需添加上边界⽇期⼩于下边界⽇期的⽤例;数字输⼊框（如‘⾦额’⼀般为正整数，填⼊⼀个负数）;字符串输⼊框：超出规定长度的字符串;6.7 关联的测试⽤例对于相互关联的两个或多个数据项，⽣成⼀个⽤例，确保当⼀个数据项改变时，其他数据项的变化正确;6.8 唯⼀值的测试⽤例某些业务的数据字段要求是唯⼀的，⽣成⼀或两个⽤例（新建、编辑），使得输⼊数据与原有数据在该字段重复，预期结果为页⾯返回该数据已存在的提⽰;6.9 权限不⾜的测试⽤例对于功能模块，⽣成⼀个⽤例，以没有权限的⽤户⾝份访问，预期结果为提⽰权限不⾜;6.10 ⾓⾊权限的测试⽤例业务功能流程涉及⼀到多个⾓⾊，对于每个⾓⾊，都⽣成⼀个⽤例，预期结果为⽤户以这个⾓⾊登陆时，他仅能执⾏权限允许的操作;7.测试⽤例编写细则7.1 测试⽤例命名规则由于项⽬的实际需求和测试的⼯作需要，分以下⼏个等级来规范测试⽤例的命名:⼀级⽬录使⽤各项⽬的顶级菜单名称来命名，如维护、业务、查询三⼤类；⼆级⽬录使⽤顶级菜单下的⼆级菜单名称类命名，⽤户可根据名字判别该⽤例是测试哪个模块的；各⽤例根据各⽤例的功能来命名，尽量做到简洁明了。