信息系统测试管理规范.docx
- 文档编号:16324781
- 上传时间:2023-07-12
- 格式:DOCX
- 页数:26
- 大小:28.41KB
信息系统测试管理规范.docx
《信息系统测试管理规范.docx》由会员分享,可在线阅读,更多相关《信息系统测试管理规范.docx(26页珍藏版)》请在冰点文库上搜索。
信息系统测试管理规范
信息系统测试管理规范
文件状态:
[√]草稿
[]正式发布
[]正在修改
文件标识:
当前版本:
1.1
作者:
佚名
发布日期:
修订记录
版本/状态
作者
参与者
起止日期
备注
V1.0
1.引言
1.1.目的
本细则定义了测试管理过程中所涉及到的项目及非项目类测试范围管理、规划管理、缺陷管理、问题管理、变更管理的管理要求及规范。
本细则作为测试管理部测试管理工作的指导性文档。
1.2.范围
本细则适用于测试管理部所有测试工作。
1.3.参考
1.4.术语
2.测试范围管理
2.1.管理目的
对于测试而言,测试范围管理是测试管理的重要环节。
测试范围的变化将影响到测试的整体工作量、测试质量、资源调配等诸多活动,测试范围确认是否清晰、准确将直接影响测试的整体质量和进度。
通常,在测试管理中,“范围”这一术语有两种含义:
产品范围——某项产品、服务或成果所具有的特性和功能。
项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
根据测试管理中对范围的定义(产品范围和项目范围),结合测试范围的特殊性,对测试范围的具体定义如下:
测试类型的范围:
功能、性能。
被测系统的范围(例如:
核心系统、柜面系统、信贷管理系统、网上银行系统等),以及因测试需求所影响到的系统的范围(例如:
提供验证的系统、提供数据来源的系统等)。
工程过程的活动范围(例如:
测试工程过程包括测试的分析、设计、执行等)。
被测系统中包括具体的功能或性能的测试范围(例如:
业务交易清单、测试场景、性能指标等)。
2.2.活动定义
测试范围管理是确保测试成功完成所需全部工作的过程。
管理测试范围在于定义和控制哪些工作应包括在测试工作内。
测试范围管理具体活动包括以下内容:
1.测试需求的采集:
根据提供的相关资料采集、提取测试需求。
至少包括以下内容:
项目建设要求、通过评审的需求文档、项目计划、软件产品的交易清单或功能列表等。
测试需求采集过程中,需满足以下管理要求:
(1)测试管理人员应检查所采集文档的完整性(例如:
是否存在章节的缺失或重要信息的缺失等);
(2)测试管理人员应检查所采集文档的有效性(例如:
确保与开发使用文档版本的一致性或是最新版本等);
(3)测试管理人员需研读所采集的文档,查找与测试范围相关的信息,针对存在二义性或表达不清晰的内容,向文档提供者提出问题,获得清晰、准确的回复,确保语义理解的唯一性。
(4)测试管理人员需参与项目启动会议。
2.测试项目范围的确认:
通过测试范围确认会,实现对测试范围的最终确认,从而实现开发、业务与测试就测试范围理解的一致性。
为后续测试的工作量评估提供决策依据。
《测试范围确认书》应包含但不限于以下内容:
(1)测试的基本信息;
(2)测试的业务范围;
(3)测试涉及的系统;
(4)测试环境和数据要求;
(5)测试范围约定(例如:
培训、工具等);
3.测试项目范围的管控:
测试范围确定过程中,范围发生变更、则需测试管理人员重新确认《测试范围确认书》。
具体管理要求如下:
(1)测试范围确认阶段,测试管理人员检查项目范围的变化(例如:
是否引入新的测试类型、是否存在新增交易、是否测试环境不满足现有测试的条件等);
(2)若出现测试范围的变更,需求部门发起变更流程,测试管理人员对测试范围进行修改,评估变更对工作量和质量的影响情况;
2.3.角色和职责
表2-1:
角色和职责
角色
主要职责
测试管理人员
✓参与需求阶段过程,与开发人员、需求人员、运维人员沟通测试范围
✓组织对测试过程的定义和裁剪
✓根据需求文档的进行需求采集
✓根据采集的文档编制测试范围确认书
✓对测试范围确认书的修订和版本提交
✓申请测试范围评审
测试人员
✓参与测试范围评审
需求人员
✓提供通过评审的需求文档及所约定的相关文档
✓提供性能需求指标。
✓参与测试项目范围评审
开发人员
✓参与测试项目范围评审
运维人员
✓参与性能测试范围评审
质量控制人员
✓组织对测试范围确认书的内部评审
✓监控测试范围及过程
✓核实收尾阶段的测试范围
质量管理人员
✓管理所有时间节点及交付物
2.4.管理文档
✓测试范围确认书
3.测试规划管理
3.1.管理目的
测试规划管理指在测试规划阶段,根据《测试范围确认书》、需求文档、开发计划等文档,制定测试管理的一系列活动。
测试计划是测试工作的总体计划,确定了执行、监控和结束的方式和方法,包括需要执行的过程、测试生命周期、里程碑和阶段划分等内容。
测试计划是其它计划制定的依据和基础,指导测试工作的有序进行。
3.2.活动定义
测试计划是干系人通信、管理审查、进度衡量和项目控制的基准。
测试计划帮助测试管理人员管理测试团队并评价测试状态。
测试计划随着环境或项目的变化而变化。
对于制定一个完整的测试计划需要包括但不限于下列活动:
1.确定类型(类型、承建方式等)。
根据测试目标的规模和特点,确定目标类型(新建项目测试、阶段性项目测试、非项目测试)、承建方式(自测、外包)。
目标类型判定:
(1)新建测试项目
(2)阶段性测试项目
(3)非项目测试(处于运维阶段的业务需求、生产问题、缺陷修复工作)
2.确定测试目标。
测试计划中,应建立客观且能够量化的目标。
目标主要包括:
进度、质量、交付、管理、效率五类指标。
为确保目标的有效性,应满足下列管理要求:
(1)每类指标都需要测试管理人员根据团队资源的实际情况,提供具体的量化数值作为承诺;
(2)在测试实施过程中,质量管理员将对测试目标值进行监控和统计,并作为验收考评依据。
3.测试工作量评估。
确定目标后,测试管理人员对测试工作量进行估算。
对于测试的工作量估算,评估方法可参考一下内容:
(1)分析阶段的工作量估算,根据测试分析的平均效率(5个情景/人天)和业务需求规模(交易的平均情景数量)来进行估算(例如:
20个交易,100个业务情景,其分析的工作量为100/5=20人天);
(2)设计阶段的工作量估算,根据项目的交易数量和测试强度,及历史项目的经验值,估算项目规模(例如:
10个交易,测试强度为30个案例/交易,项目预估设计案例数量为10*30=300,设计效率为20个案例/人天,测试设计所需工作量为300/20=15人天),此估算值可与经验值比较来进行验证,保证估算的准确性;
(3)测试强度要求:
新建系统的测试强度不得低于50个案例/交易;改造系统的测试强度不得低于20个案例/交易;验证系统的测试强度不得低于10个个案例/交易;
(4)执行阶段的测试工作量估算,考虑数据准备量和测试执行轮次(建议至少按照3个轮次评估),同时测试执行累计案例数量,不得低于总体测试案例的1.3倍,重要级测试案例(业务级、流程级)需完成至少1次全回归测试;
(5)设定测试的分析、设计和执行阶段,并按照各个阶段高、中、初测试工程师的投入工作量进行统计;
(6)工作量估算应考虑管理消耗的整体工作时间,视项目管理能力而定,通常为整体工程工时总量的20%。
(例如:
分析、设计和执行的总工时为100人天,那么管理工时应为100*20%=20人天,项目的总体工作量为120人天)。
4.制定测试的人员计划。
根据测试周期,将不同角色的测试工程师合理分配到测试周期中的各个阶段。
具体管理要求如下:
(1)针对每个阶段,以周为单位,明确不同角色的测试工程师所需投入的数量,并核算工作量;
(2)按照角色汇总工作量,其汇总值与分阶段投入工作量汇总值一致;
(3)按人员计划评估的工作量与测试工作量估算得出的工作量进行比对,检查人员计划中的工作量是否存在较大差异。
若出现较大差异,分析产生差异原因,调整人员投入计划。
5.制定测试的进度计划。
在进度计划中,具体管理要求如下:
(1)制定具体时间点的测试里程碑计划。
明确里程碑的交付成果物和过程文档;
(2)按阶段制定成果物的交付进度计划,明确每阶段的交付成果物数量;
(3)交付数量应不少于目标承诺的交付数量,作为质量管理员过程检查和度量的标准;
(4)提供进度控制策略。
针对客观情况(例如:
业务支持、测试数据、环境准备等),提供相应的进度控制策略,确保团队能够按计划完成项目的实施工作。
通常进度控制策略包括:
提前安排人员入场、安排熟悉关联系统的测试工程师准备测试数据、采用自动化技术进行数据准备等。
3.3.角色和职责
表4-1:
角色和职责
角色
主要职责
测试管理人员
✓编制(功能/性能)测试计划
✓组织(功能/性能)测试书的内部评审
✓提出测试计划外部评审申请
✓(功能/性能)测试计划评审后修订
开发人员
✓参与(功能/性能)测试计划的外部评审
需求人员
✓参与(功能/性能)测试计划的外部评审
运维人员
✓参与(功能/性能)测试计划的外部评审
质量控制员
✓参与(功能/性能)测试计划的外部评审
✓组织《性能测试方案》的内部评审
✓参与(功能/性能)测试计划的外部评审
质量管理员
✓管理所有时间节点及交付物
3.4.管理文档
✓(功能/性能)测试计划
✓会议纪要
4.测试缺陷管理
4.1.管理目的
缺陷管理是测试管理的重要环节,通过对缺陷全生命周期的监控,加快缺陷关闭。
通过找寻、分析和处理缺陷的共性原因,促进开发质量的改进和测试水平的提高,进而实现缺陷预防。
缺陷管理要达到以下目标:
✓确保每个被发现的缺陷都能够被解决
✓确保每个被发现的缺陷的处理方式能够在组织中达成一致意见
✓收集缺陷数据并根据缺陷状态识别测试过程是否结束
✓收集缺陷数据并进行分析,作为组织的测试资产
4.2.活动定义
缺陷全生命周期管理包括以下活动:
1.缺陷提交;
2.缺陷确认;
3.缺陷监控(缺陷修复、缺陷复测、缺陷关闭);
4.缺陷仲裁
5.缺陷分析,主要包括:
缺陷严重等级分析、缺陷趋势分析、缺陷原因分析、缺陷状态分布分析等。
在项目实施的测试执行阶段中,测试管理人员需及时对发现的测试缺陷进行分析。
在每轮测试结束后,测试管理人员结合分析结果,形成轮次测试总结报告;
6.缺陷评审:
系统上线后,针对运维部门提供的缺陷问题单进行缺陷评审。
通过缺陷评审来查找缺陷的引入原因,是项目后评估工作的重要组成部分。
4.3.角色和职责
表5-1:
角色与职责
角色
主要职责
质量控制员
✓监控缺陷管理过程
开发经理
✓分析缺陷
✓分配缺陷修改任务给开发人员
✓跟踪缺陷的解决
✓仲裁缺陷
测试管理人员
✓分析缺陷
✓仲裁缺陷
✓跟踪缺陷的解决
测试人员
✓分析缺陷
✓提交缺陷
✓跟踪缺陷的解决
✓测试缺陷复测
✓关闭缺陷
开发人员
✓分析缺陷
✓修改缺陷
需求人员
✓修改需求缺陷
✓仲裁缺陷
4.4.流程描述
1.测试人员提交缺陷至开发人员或需求人员,缺陷状态置为待确认;
2.缺陷类型分为需求缺陷和开发缺陷:
1)当缺陷类型为需求缺陷时,需求人员对缺陷进行仲裁,若判定为缺陷,则需修改需求,并走需求变更流程,开发人员根据需求开发,待测试人员测试完毕后,将此缺陷置为已关闭状态;若需求人员判定暂不解决,会将其状态直接置为已搁置;若需求人员判定为非缺陷,则说明拒绝原因,测试人员将该缺陷状态修改为无需修改,流程结束;
2)当缺陷类型为开发缺陷时,开发人员对缺陷进行修复,修复完毕后,缺陷状态置为待发布;新版本发布后,提交给测试人员进行复测,缺陷状态置为已修复;
3.对于已搁置的缺陷,若具备缺陷解决的条件,则通知相关人员修改缺陷,缺陷状态变为已修复;若已搁置的缺陷在项目结束时仍不做解决,则仍搁置;
4.测试人员进行复测,复测通过后,缺陷关闭,缺陷状态置为已关闭,流程结束;若测试人员复测不通过,缺陷状态置为重打开,开发人员重新修改缺陷。
返回上述步骤,直至缺陷复测通过,流程结束。
4.5.启动条件
✓发现缺陷
4.6.退出条件
✓缺陷处理完毕:
缺陷设置为已关闭、已搁置或无需修改状态
4.7.缺陷属性
4.7.1.缺陷属性字段解释说明
表5-2:
缺陷属性说明
属性
属性描述
M(必选)/O(可选)
缺陷ID
由IT管理平台(测试管理平台)自动生成
M
缺陷名称
缺陷的简单描述
M
类别
项目类
非项目类
M
缺陷状态
缺陷的当前状态–待确认/重打开/已拒绝/待仲裁/已搁置/已修改/待发布/无需修改/已关闭
M
优先级
1-紧急,2-特急,3-普通
M
缺陷严重等级
1-致命,2-严重,3-较严重,4-一般缺陷,5-改进建议
M
项目名称
缺陷的项目名称
M
交易(或功能点)
缺陷的交易名称
O
缺陷描述
缺陷的详细描述
M
缺陷发现阶段
缺陷被发现时系统所处的阶段
O
缺陷来源
缺陷的类型分析,分析缺陷产生的根本原因
O
应用系统
关联的系统
O
提交者
缺陷提交者
M
接收者
被分配的负责判断缺陷,修复缺陷或复测的人
M
缺陷原因
缺陷原因,应由负责修复缺陷的人指出,包括:
安装配置,对其他方的影响未做分析,非缺陷,需求模糊,缺乏沟通,未遵守规范,系统缺陷,修改原有程序发生的错误等
O
评论
缺陷修复方法,内容,修复的影响分析。
测试人员与开发人员主要通过此字段进行沟通。
对于测试人员此字段为只读,如果测试人员要添加内容则在"添加影响分析,处理内容"字段上添加
M
测试案例号
缺陷所对应的测试案例号
O
测试日期
缺陷提交日期,格式为:
2009-4-10
M
4.7.2.缺陷状态定义
通过监控缺陷的状态,实现缺陷全生命周期的管理,同时也能够形成对缺陷引发工作量的分析。
表5-3:
缺陷状态定义表
缺陷状态
描述
待确定
新提交的缺陷状态
无需修改
测试管理人员或需求人员判定不是缺陷,该状态是缺陷的最终状态
待发布
开发团队确认是缺陷,修改后还未提交版本。
已拒绝
开发:
拒绝“新建”的缺陷或“重打开”的缺陷,不需要修改或不是缺陷
已修改
开发:
修改后已发布版本
待仲裁
开发团队与测试团队有分歧,需要提交仲裁组(需求人员)做最终确认
已搁置
缺陷暂不做处理,该状态是缺陷的最终状态
重打开
测试人员复测后,相同缺陷依然存在
已关闭
缺陷提出人对缺陷重新验证,确认缺陷被修复,将其关闭。
该状态为缺陷的最终状态
4.7.3.缺陷严重等级
参考其他银行及国际通用惯例,通常将缺陷的严重程度定义为五级标准。
缺陷的严重等级将影响到测试阶段和具体上线的准入和准出标准。
其具体缺陷严重等级描述请参考下表。
表5-3:
缺陷严重等级
等级
说明
缺陷判定准则
可能情况举例
备注
1级
致命缺陷
导致系统crash、上线后可能导致无法进行正常业务、用户数据受到破坏、系统数据完全混乱无法再继续进行测试、任何一个主要功能完全缺失或丧失、主要进程死锁或挂起、日终或批处理无法完成而不能进入下一工作日等。
1引起死机、宕机或系统异常退出
2导致系统崩溃
3造成数据丢失或损坏
4引起系统性能下降或无法响应
5导致某类业务整体流程中断或某类业务的多个交易流程中断
6多个客户账务或会计账务发生错误(例如:
分录、利息、账务状态等
重要数据)
7与数据库链接错误
8数据通讯错误
9严重影响其它系统运行或其它模块功能
2级
严重缺陷
系统主要功能部分缺失或丧失、任何一个次要功能完全缺失或丧失、影响客户账务正确性、影响银行会计账务正确性、多个业务无法正确执行且无绕行方式、外部重要接口无法联通或内容错误而影响业务完成、功能设计不对而导致业务无法正确完成、系统性能表现不符合设计要求、系统所提供的功能或服务受到明显的影响等。
1单个客户账务错误
2程序运算或统计错误
3多个业务无法执行,且无绕行方式
4外部重要接口无法联通或内容错误而影响业务完成
5系统所提供的功能或服务受到明显的影响
6功能设计不对而导致业务无法正确完成
7数据库的表、业务规则、缺省值未加完整性等约束条件
8程序运行不稳定,如出现无法继续进行操作的错误,或缺陷导致某个交易流程中断
9程序运行不稳定,如出现难以捕捉和不可再现的错误
10数据库表中有应赋值而未赋值的空字段
11系统性能的关键或重要指标与需求或设计不符
12影响其它业务流程的错误
如账务类系统,是指交易类功能和维护类功能
3级
较严重缺陷
系统辅助、支持类功能缺失、实现不正确或无法使用,但不影响业务流程中其他功能测试的缺陷。
错误功能导致主要业务无法正确执行且暂时有绕行方式、客户回单/对账单等重要凭证内容错误、有关重要
业务信息的页面回显错误、非重要数据错误等。
1关键或重要业务、交易的内容打印、格式错误
2辅助功能实现与需求不符合,如打印、查询等交易
3性能表现的一些非关键指标不符合设计要求
4简单输入限制未放在前台进行控制
5删除/退出操作未给出提示
6功能不完整,如菜单、按钮不响应
7重要及基本业务、统计类报表内容错误
8非重要数据不正确,如客户回单/对账单等重要凭证内容错误
9对错误没有处理或提示信息
如账务类系统,是指查询和打印类功能
4级
一般缺陷
功能实现基本正确,但在表达方面不符合行业规范或不利于使用的缺陷。
错误功能导致次要业务无法正确执行但暂时有绕行方式、统计类业务报表格式错误、客户回单/对账单等重要凭证内容有瑕疵,虽不影响业务进行,但影响客户满意度。
1帮助/辅助说明不准确
2输入输出不规范,或备注类、留存类等非重要字段的打印、显示格式
3提示窗口文字未采用行业术语
4界面不够友好,或界面造成客户使用不便或产生歧义性理解
5可输入区域和只读区域没有明显的区分标志
6界面风格不一致
7操作界面错误(包括数据窗口内列名定义、含义是否一致)
8操作界面文字表述中有容易导致使用人员做出异常操作的错别字或歧义文字
5级
改进建议
系统整体风格以及使用习惯等的改进建议。
虽然是功能错误但不属于上线需要的业务功能问题。
使用不便等修饰性问题,或对系统使用的确认问题,界面不够友好性或界面造成客户使用不便的问题等。
1测试人员根据用户(或业界)缺省习惯(或隐含需求)所提出的建设性意见(需求变更除外)
2窗口中的按钮或者控件缺少快捷字母,或快捷字母冲突
3操作界面文字表述中有不影响正常操作的错别字
4Tab键跳转不正常
4.7.4.缺陷优先级
定义缺陷优先级,保证对批量缺陷修复的重点,可指导开发人员有计划、有安排的修复缺陷问题,将缺陷引发的损失降到最低。
表5-4:
缺陷优先级表
缺陷优先级
修复时间要求
特急
需立即响应并进行修复,修复时间原则上不超过当日。
紧急
在发现的两个日历日内(含缺陷发现的当日)须完成缺陷修复(对于“程序运行不稳定,如出现难以捕捉和不可再现的错误”,错误定位后两日内修复或上线前必须修复)
普通
原则上七个日历日内须完成缺陷修复,亦可按照正常排队等待修复。
4.7.5.缺陷来源
定义缺陷来源,通过对缺陷来源的统计和分析,能够确切查明缺陷引入的原因,指导过程改进,可有效地降低和控制缺陷的引入。
表5-5:
缺陷来源表
缺陷来源定义
描述
需求引入
由于需求的问题引起的缺陷
编码引入
由于开发编码的问题引起的缺陷
数据环境引入
由于数据和环境引起的缺陷
缺陷修复引入
由于修复缺陷引起的新的缺陷
其他
由于其他原因引起的缺陷
4.7.6.缺陷发现阶段
定义缺陷发现阶段,通过对各个阶段发现缺陷的统计,可分析各个阶段有关缺陷的拦截情况。
表5-6:
缺陷发现阶段
缺陷发现阶段
描述
开发内部测试发现
在开发内部(单元和集成)测试阶段发现的缺陷
系统测试发现
在系统测试阶段发现的缺陷
验收测试发现
在用户验收测试阶段发现的缺陷
4.8.管理文档
✓《测试缺陷记录表》
5.变更管理
1.
2.
3.
4.
5.
6.
5.1.管理目的
变更管理是管理测试过程中有关范围、目标、环境、数据、进度、质量等各个因素发生变化,要求测试计划进行部分变更或全部变更,并实施测试变更的过程。
测试变更管理的目的是管理测试变更过程,对变更影响范围进行详细分析和评估,确保实施变更过程中,能够有效的控制测试范围和确保测试覆盖质量,减少变更对整体的影响。
5.2.活动定义
测试过程中的变更根据其来源可以分为两类:
✓来自信息科技部内部发起的变更。
由各项目负责人发起,包括
(1)不涉及更改总体计划的变更(例如性能优化、代码优化、自行发现的缺陷优化等),此类变更由项目负责人先报告后实施变更,质量管理员跟踪变更结果;
(2)需要更改总体计划的变更,需求人员需向质量控制员提出变更申请,申请通过后,方可执行变更,质量控制员对变更情况给予跟踪和记录。
✓来自信息科技部外部发起的变更。
对于外部变更,测试管理人员应根据外部变更的内容,对变更及变更影响范围进行分析,提供变更影响分析报告,报告评审通过后,由测试管理人员修改测试计划书,执行变更,质量控制员对变更情况给予跟踪、质量管理员进行记录。
针对两类变更,测试项目变更管理包括下列活动:
1.变更影响分析。
测试管理人员接收内部或外部变更需求,都需要对变更及变更影响的范围进行分析。
具体管理要求如下:
(1)根据变更内容,对测试范围进行重新评估。
检查是否存在范围变化(例如:
被测交易的数量增减,被测系统或影响系统的增减等);
(2)根据变更内容,对测试进度进行重新评估。
检查测试进度的变化(例如:
测试周期是否被延迟或被压缩等);
(3)根据变更内容,对测试实施过程进行重新评估。
检查是否需要增加或减少某些测试活动(例如:
根据变更内容,发现需要增加报表测试、接口测试等);
(4)根据变更内容,评估项目工作量的变化,根据变更后的周期,为确保工作的目标和进度,需对团队的人力资源需求重新进行评估,提供执行变更的工作量估算;
(5)根据变更内容,检查测试工作目标的量化指标是否存在变化;
(6)根据变更影响分析报告,修改测试计划。
并组织评审报告和计划。
2.变更评审。
针对测试管理人员提交的测试变更影响分析报告组织评审。
具体管理要求如下:
(1)参与变更评审人员包括但不限于:
测试管理人员、质量控制员、需求人员、开发人员、技术支持人员、运维人员、信息安全部等;
(2)评审变更的可行性。
根据测试影响分析报告,从范围、工作量评估、进度、人员、风险等方面来评估测试的可行性;
(3)重新确认工作目标。
检验工作目标是否发生变化,修订部分量化指标,确保变更前后工作整体目标的一致性。
3.执行变更。
评审通过后,修改测试计划和,执行测试变更。
具体管理要求如下:
(1)修改测试计划。
重新启动实施过程(例如:
组织对计划的评审、开展变更测试业务的分析工作等);
(2)质量管理员记录测试变更影响范围和工作量的统计。
记录测试的变更频次,为验收的度量活动提供依据(例如:
需求变更导致测试项目变更次数、因各种变更导致增加的合计工作量等)。
5.3.角色和职责
角色
主要职责
质量控制员
✓按照质量控制员变更管理流程管理变更
✓参与内部或外部需求变更评审会
✓参与测试计划变更评审会
✓提供外部变更影响分析报告(开发、业务)
项目经理
✓提出变更申请
✓提供内部变更需求单
✓发起内部需求变更评
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息系统 测试 管理 规范