数据质量检查模块V0功能规范
- 格式:doc
- 大小:141.00 KB
- 文档页数:7
软件测试中的一致性与完整性检查简介在软件开发过程中,软件测试是一个非常重要的环节。
其中,一致性与完整性检查是保证软件质量的关键之一。
本文将讨论软件测试中一致性与完整性检查的概念、原理、方法和实践经验,旨在帮助读者更好地理解和运用这一测试策略,最终提高软件的质量和可靠性。
一、一致性检查的概念与原理一致性检查是指检查软件中各个模块、组件及其之间的接口是否满足一致性要求。
一个软件系统可能包含多个模块,而且这些模块通常是由不同的开发人员编写的。
一致性检查的目标是确保这些模块之间能够正确地交互和通信,以达到整体系统功能的一致性。
在进行一致性检查时,需要关注以下几个方面:1. 接口一致性:检查软件模块之间的接口定义、参数传递、数据格式等是否符合规范,以保证模块之间能够正确地交换信息。
2. 数据一致性:检查软件中使用的数据是否一致,包括数据格式、数据类型、数据命名规范等,以避免由于数据不一致而导致的错误。
3. 功能一致性:检查软件模块的功能是否一致并符合预期,以保证整体系统功能的正确性和一致性。
二、完整性检查的概念与原理完整性检查是指检查软件是否包含所有必要的功能、模块和组件。
一个软件系统的完整性是指系统的各个部分是否完全满足需求规格说明书中定义的功能和性能要求。
在进行完整性检查时,需要关注以下几个方面:1. 功能完整性:检查软件是否包含所有在需求规格说明书中定义的功能,并验证这些功能是否按照规格要求正常运行。
2. 模块完整性:检查软件中的各个模块是否完整,并验证其功能是否满足系统需求。
3. 组件完整性:检查软件中的各个组件是否完整,并验证其在系统中的相互依赖关系是否正确。
三、一致性与完整性检查的方法与实践经验1. 静态检查:通过代码审查、技术评审等方式,对软件的各个模块进行静态检查,发现并纠正其中的一致性和完整性问题。
2. 功能测试:对软件进行功能测试,验证软件的各个功能是否一致并完整。
可以使用黑盒测试和白盒测试等方法进行测试。
XX信息中心网络设备巡检服务工作规范(H3C设备网络)V1.0信息中心2011年8月目录1概述 (5)2巡检工作流程 (5)2.1巡检前期准备 (6)2.2数据采集阶段 (7)2.3数据分析和报告生成阶段 (7)2.4汇报和满意度调查阶段 (7)3网络巡检数据采集方法 (7)3.1手工数据采集方法 (8)3.2网络管理平台数据收集方法 (8)3.3巡检工具数据采集方法 (8)4网络巡检服务基准数据库的建立 (8)5网络巡检工作内容 (9)5.1巡检工作的主要内容 (9)5.2网络巡检工作技术涵盖 (10)6网络系统巡检基本判断标准 (10)7设备相关信息收集 (12)7.1软件版本及硬件信息分析 (12)7.1.1当前设备硬件信息 (13)7.1.2当前设备运行软件信息 (14)7.2设备板卡硬件配置信息分析 (14)7.3设备运行状况检查 (15)7.3.1设备CPU工作状态检查 (16)7.3.2设备CPU利用率分析 (16)7.3.3设备MEMORY使用状态检查 (17)7.3.4设备MEMORY利用率分析表 (18)7.4设备运行状态检查 (18)7.4.1电源的工作状态 (18)7.4.2风扇的工作状态 (19)7.4.3设备工作温度 (19)8 端口的可用性、准确性检查 (19)8.1端口状态检查 (19)8.1.1基本网络接口状态分析 (22)8.1.2接口半/全双工模式和链路类型 (23)8.1.3接口稳定性统计信息 (23)8.2端口状态检查表 (23)9 设备端口负载及流量检查 (24)9.1设备缓存信息检查 (24)10 网络架构、配置信息分析 (24)10.1网络结构检查 (24)10.1.1检查内容 (24)10.1.2检查方式 (24)10.2网络配置信息检查 (27)10.2.1检查内容 (27)10.2.2检查方式 (27)11 LOG信息检查 (30)11.1标准的LOG格式 (30)11.2LOG日志等级 (30)11.3日志信息分析表 (30)关于文档为保障XX信息中心网络的平稳运行,将在每月进行网络巡检,并根据巡检结果给出相应的网络系统改进和优化建议。
软件外包项目交付与验收标准操作手册第1章项目启动与规划 (4)1.1 项目启动会议 (4)1.2 需求分析与确认 (4)1.3 项目规划与时间表 (4)1.4 资源分配与团队搭建 (5)第2章外包团队选择与评估 (5)2.1 外包团队筛选标准 (5)2.2 评估方法与流程 (5)2.3 合作伙伴选定 (6)2.4 合同签订与保密协议 (6)第3章项目进度监控与管理 (6)3.1 项目进度跟踪 (6)3.1.1 制定项目计划:在项目启动阶段,需明确项目各阶段的目标、任务、里程碑及预计完成时间,形成项目计划。
(7)3.1.2 设立关键时间节点:在项目计划中,识别并设立关键时间节点,作为项目进度监控的重要依据。
(7)3.1.3 定期更新进度:项目团队需定期(如每周)更新项目进度,保证项目实际进度与计划相符。
(7)3.1.4 进度报告:定期向项目甲方及项目相关人员提交进度报告,包括已完成任务、正在进行中的任务、待完成任务及预计完成时间。
(7)3.1.5 跟踪进度偏差:对项目进度进行持续跟踪,发觉偏差时及时分析原因,制定相应的调整措施。
(7)3.2 风险识别与应对 (7)3.2.1 风险识别:项目团队需定期进行风险识别,包括技术风险、人员风险、质量风险、进度风险等。
(7)3.2.2 风险评估:对已识别的风险进行评估,分析其影响范围、发生概率及潜在损失。
(7)3.2.3 风险应对策略:根据风险评估结果,制定相应的风险应对策略,包括避免、转移、减轻和接受等。
(7)3.2.4 风险监控:在项目执行过程中,持续监控风险变化,及时调整应对措施。
(7)3.3 沟通协调机制 (7)3.3.1 项目沟通渠道:明确项目各方之间的沟通渠道,包括邮件、电话、会议等。
(7)3.3.2 定期项目会议:设立固定的项目会议时间,保证项目各方定期沟通,了解项目进度、解决问题。
(7)3.3.3 项目问题解决:对项目中出现的问题,及时沟通协调,制定解决方案并跟踪实施。
“智慧住建”建筑工程安全监管系统全市联网及运维服务项目技术规范和服务要求一、项目背景在建筑工程的快速发展过程中,安全监管一直是一个重要的话题。
为了提高建筑工程安全监管的效率和质量,我市决定引入智慧住建建筑工程安全监管系统,实现全市建筑工程安全监管的联网和运维服务。
本项目的目标是通过技术规范和服务要求的制定,确保智慧住建系统的高效运行和良好服务。
二、技术规范1.系统架构要求:智慧住建建筑工程安全监管系统应采用分布式架构,实现数据的统一管理和共享。
系统应具备高可靠性和灵活性,能够适应不同规模的建筑工程监管需求。
2.功能模块要求:系统应包括监管平台、数据采集与分析、预警预报、监督检查等功能模块。
监管平台应提供实时监控和管理建筑工程安全情况的功能,数据采集与分析模块应用于收集和分析建筑工程的安全数据,预警预报模块应实现对潜在安全风险的及时预警,监督检查模块应帮助监管人员进行现场检查和核查。
3.数据安全要求:系统应具备数据加密和权限控制功能,确保建筑工程的安全数据不被泄露或篡改。
系统应符合相关法规和标准,保证数据的完整性和可靠性。
4.用户界面要求:系统的用户界面应简洁直观,易于操作。
监管人员和相关部门应能够通过系统实时查看建筑工程的安全状态和监管情况,及时进行处理和决策。
5.系统性能要求:系统应具备高可靠性和高性能,能够满足大规模建筑工程监管的需求。
系统应能够实现多用户同时访问和操作,并能够实现数据的快速处理和查询。
三、服务要求1.运维服务要求:系统的运维服务应包括日常维护、故障处理、备份恢复等内容。
运维人员应具备系统配置和故障排除的能力,保证系统的稳定运行和数据安全。
2.培训服务要求:系统的培训服务应针对监管人员和相关部门进行培训,包括系统操作和数据管理等内容。
培训内容应与系统功能和使用方法相适应,确保用户能够熟练操作系统并进行监管工作。
3.技术支持服务要求:系统的技术支持服务应包括系统升级、功能扩展、问题解决等内容。
2019-11-30发布XXXX 有限公司企业标准XXXX 代替XXXXDC-DC 转换器开发设计规范编制校对审核标准化批准2019-12-30实施XXXX 有限公司发布XXXX-LX.—1—前言为了保证XXXX有限公司的DC-DC转换器产品设计的合理性和适用性,为DC-DC转换器开发工作提供设计依据,特编制本标准。
本标准代替XXXX《DC-DC转换器设计规范》,与XXXX相比,除编辑性修改外主要技术变化如下:——增加了性能指标、软件版本要求、设计开发流程(见4.3、4.13、5);——修改了工作环境温度(见4.2.1,2017年版的4.2.1)。
本标准由XXXX有限公司技术研究院提出。
本标准由XXXX有限公司技术研究院起草并负责解释。
本标准主要起草人:本标准所代替标准的历次版本发布情况为:——XXXX-JG-087-2017。
IDC-DC转换器设计规范1范围本规范规定了XXXX有限公司开发的DC-DC转换器的术语和定义、技术指标、设计开发、设计验证和包装标示。
本规范适用于XXXX有限公司开发的DC-DC转换器。
2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件,其最新版本适用于本规范。
GB/T2423.1-2008电工电子产品环境试验第2部分:试验方法试验A:低温GB/T2423.2-2008电工电子产品环境试验第2部分:试验方法试验B:高温GB/T2423.17-2008电工电子产品环境试验第2部分:试验方法试验Ka:盐雾试验方法GB/T4208-2017外壳防护等级(IP代码)GB/T14711-2013中小型旋转电机通用安全要求GB/T17619-1998机动车电子电器组件的电磁辐射抗扰性限制和测量方法GB/T18384.1-2015电动汽车安全要求第1部分:车载可充电储能系统(REESS)GB/T18488.1-2015电动汽车用驱动电机系统第1部分:技术条件GB/T18655-2010车辆、船和内燃机无线电骚扰特性用于保护车载接收机的限值和测量方法GB/T24347-2009电动汽车DC/DC变换器QC/T238-1997汽车零部件的储存和保管QC/T413-2002汽车电气设备基本技术条件3术语和定义下列术语与定义适用于本规范。
11.1 缺陷记录信息对缺陷的描述包含以下的内容:展现层错误、未实现、未容错 控制层错误、未实现、未容错 业务层错误、未实现、未容错 数据层错误、未实现、未容错功能性1 惟一的缺陷 ID ,可以根据该 ID 追踪缺陷 缺陷的状态,分为 11 种(见 3.2.8 节) 对缺陷简单描述缺陷所属类型(见 3.2.1 节)缺陷的严重程度, 普通分为“致命”、 “严重”、 “一 般”、“轻微”和“其它”五种(见 3.2.2 节) 引入缺陷的开辟阶段(见 3.2.3 节) 发现缺陷时所属的阶段(见 3.2.4 节) 重现缺陷的步骤对缺陷的详细描述; 因为对缺陷描述的详细程度直接影 响开辟人员对缺陷的修改,描述应该尽可能详细 发现缺陷时产品的内部版本号发布给客户使用的版本号。
在缺陷提交后,由项目经理/开辟经理指定修复缺陷的 责任人项目经理/开辟经理指定修复缺陷的截止日期缺陷的紧急程度, 修复的优先级, 从 1-3,1 是优先级 最高的等级, 3 是优先级最低的等级(见 3.2.6 节) 对修复内容(将什么改成什么)的描述,如果对代码进行 了修改,要求在此处体现出修改排除缺陷的解决方案类型(见 3.2.7 节) 修复缺陷时所属的阶段(见 3.2.5 节) 估计修复该缺陷所需的工时 修复该缺陷实际使用的工时缺陷关闭后,项目经理/开辟经理评估修复缺陷所花的 工作量和修复缺陷的工作质量项目经理/开辟经理对缺陷修复工作量和工作质量的评 估赋予必要的解释说明缺陷 ID 缺陷状态 标题 缺陷类型严重程度缺陷来源 发现阶段 重现步骤现象描述内部版本号外部(正式)版本号修复责任人修复期限优先级修复描述解决方案 排除阶段 估计工时 实际工时 工作分数 工作量系数 工作质量系数 工作分数评估描述功能实现不完整 功能实现错误 数据不一致数据不完整 数据重复信息填充错误 业务流程操作繁琐 界面布局不合理 操作不习惯 tab 键顺序不合理尽量保证一屏能显示,横向滚动条尽量避免,违反此规范的缺陷提示信息不充分,或者不友好,甚至错误提示 按钮摆放位置不符合正常习惯设计图标,展示不符合常规,给人误解 布局设计不合理(静态页面显示) 风格不统一图片、色调不符合业务系统要求 系统的故障恢复艰难可维护性系统的升级操作艰难 系统的响应时间差 并发处理性能差 过负荷处理处理机制差致命是指系统任何一个主要功能彻底丧失,或者用户数据受到破坏,造成 系统崩溃、悬挂、死机或者危机人身安全。
测试⽤例规范版本号撰写⼈撰写时间备注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 测试⽤例命名规则由于项⽬的实际需求和测试的⼯作需要,分以下⼏个等级来规范测试⽤例的命名:⼀级⽬录使⽤各项⽬的顶级菜单名称来命名,如维护、业务、查询三⼤类;⼆级⽬录使⽤顶级菜单下的⼆级菜单名称类命名,⽤户可根据名字判别该⽤例是测试哪个模块的;各⽤例根据各⽤例的功能来命名,尽量做到简洁明了。
PCM接入设备技术协议规范2023年3月目录1概况.................................................................................................... 错误!未定义书签。
2原则和规范........................................................................................ 错误!未定义书签。
3PCM设备技术规定.......................................................................... 错误!未定义书签。
3.1环境条件.............................................................................................................. 错误!未定义书签。
3.2使用保证.............................................................................................................. 错误!未定义书签。
3.3重要技术参数技术协议...................................................................................... 错误!未定义书签。
3.4PCM设备技术特性............................................................................................ 错误!未定义书签。
3.5PCM网络单元管理系统.................................................................................... 错误!未定义书签。
CALIS学位论文和特色库本地系统数据质量检查模块V2.0功能规范CALIS管理中心2006年10月一、概述《CALIS OAI Record格式和发布规范》定义了“CALIS数据发布模式2”。
对于该模式中的“数据质量检查模块V2.0”,本文给出了具体功能规范。
“数据质量检查模块V2.0”(简称“数据质量检查模块”)需作为学位论文或特色库本地系统的一个组成部分。
该模块有两种使用方式:✧方式1:该模块用于对“CALIS数据发布模式2”中的OAI记录文件(该文件遵循“CALIS OAI Record V2.0格式”,可以在同一条OAI记录中同时包含元数据和数字对象)进行校验。
✧方式2:本地系统在将数据送入OAI-DP之前,自动调用该模块对拟发布的元数据和数字对象进行质量检查和校验。
数据质量检查模块的使用者主要图书馆中学位论文或特色库本地系统的系统管理员或者数据管理员。
对于学位论文本地系统,需设置一个系统参数“论文必备性校验分界日期(CALIS__ETD_verify_sep_date)”,若某篇学位论文的“论文授予日期”大于等于指定该分界日期,则采用“CALIS学位论文元数据必备性规则2”进行校验,否则采用“CALIS学位论文元数据必备性规则1”进行校验。
二、界面规范管理员首先使用本地系统的OAI文件导出模块进行OAI记录文件(遵循“CALIS OAI Record V2.0格式”)的导出。
然后,管理员再使用“数据质量检查模块”对OAI记录文件中的数据在数据格式、必备性、一致性等方面进行检查和校验。
校验无误后,管理员才能将这些文件通过FTP上传,或者通过OAI-DP自动对外发布。
数据质量检查模块的界面应尽量简单易操作,提示信息明确。
该界面至少应包含以下部分:1.oai记录文件夹(文件名)输入框,可以手工输入要检查文件存放的文件夹或文件名。
2.oai记录文件夹选择按钮,可以用可视对话框的方式选择要检查的文件夹或文件3.oai文件检查按钮4.结果提示文字框数据质量检查模块的界面如下图所示:图1:数据质量检查模块V2.0的界面示意【特别注意】对于学位论文本地系统,参数CALIS__ETD_verify_sep_date(论文必备性校验分界日期)应能由管理员统一配置。
三、功能规范“数据质量检查模块V2.0”对于“CALIS数据发布模式2”的OAI记录文件进行校验时可能会发现一些错误,这些错误提示应遵循《CALIS学位论文和特色库本地系统的数据质量检查模块的错误代码规范》规范。
“数据质量检查模块V2.0”对OAI记录文件的校验分为以下两种情形:1)用于对OAI记录文件进行校验;2)与本地系统联动,用于对OAI-DP中即将发布的OAI记录数据进行校验。
3.1对OAI记录文件的校验对“OAI记录文件”,按照“CALIS OAI Record V2.0格式”要求进行校验,该校验工作包括以下几个方面:(1)对OAI Record文件名称的校验(a)文件名称是否采用以下拼接形式生成:“完整的MetaID”+“@”+“导出时间戳”+“.oai.xml”——这种校验的错误代码为01002A。
(b)“完整的MetaID”部分是否采用以下拼接形式生成:“仓储标识”+“-”+“本地应用系统前缀”+“/”+“本地元数据标识”——这种校验的错误代码为01003A。
(c)“完整的MetaID”部分是否进行了application/x-www-form-urlencoded MIME格式转换,型如:oai%%3Aetd-dr%2FA1002——这种校验的错误代码为01003B。
(d)“导出时间戳”部分是否为型如“2005-01-01T10:02:30Z”的20位零时区时间格式——这种校验的错误代码为01004A。
(e)“导出时间戳”部分是否进行了application/x-www-form-urlencoded MIME 格式转换,型如:2005-01-01T10%3A02%3A30Z——这种校验的错误代码为01004B。
(f)OAI Record文件名称是否型如:oai%%3Aetd-dr%2FA1002@2005-01-01T10%3A02%3A30Z.oai.xml ——这种校验的错误代码为01002B。
(2)对OAI Record文件的内容进行校验(a)用Record Schema(record.xsd)校验XML文件是否合法,schema地址为:/metadata_ns/oai/record/record.xsd——这种校验的错误代码为01009。
(b)取出record->header->identifier下的元数据标识符的值,并同OAI Record文件名称中的“完整的MetaID”进行比较,这两个值应该一致——这种校验的错误代码为01010。
(c)取出record->header->datestamp下的元数据时间戳的值,该值应该是一个20位的零时区时间值——这种校验的错误代码为01011。
(d)取出record->metadata下的元数据XML片断,对元数据内容进行校验a)该部分的元数据,当符合不同元数据格式时,所使用的元数据Schema是不同的,所以,需要取出根元素的xsi:schemaLocation属性值,并获得其中包含的schema的地址,利用该schema对当前元数据XML片断进行校验——这种校验的错误代码为01012。
b)根据对应格式的元数据规范和著录规则,逐一对各个元素和子元素修饰词的必备性([1,1]或[1,∞])和不可重复性([0,1]或[1,1])进行校验对于学位论文系统,若该元数据的“论文授予日期”大于等于指定的“论文必备性校验分界日期”,则采用“CALIS学位论文元数据必备性规则2”进行校验,否则采用“CALIS学位论文元数据必备性规则1”进行校验。
对于特色库,没有上述分界日期。
但type取值必须在《专题特色库信息资源名称规范列表》中取词。
——对于学位论文,按照“CALIS学位论文元数据必备性规则1”进行校验所用的错误代码为02001-02001E;按照“CALIS学位论文元数据必备性规则2”进行校验所用的错误代码为02001-02001E。
——对于特色库,这种校验的错误代码为02001-02001E。
c)当语种元素(language)的编码体系修饰词为“scheme=’ISO 639-2’”时,语种值必须符合ISO 639-2(/iso639-2.html)——这种校验的错误代码为02009。
d)当与时间相关的元素或子元素修饰词的编码体系修饰词为“scheme=’W3C-DTF’”时,其时间值必须符合W3C-DTF(/TR/NOTE-datetime)——这种校验的错误代码为02010。
yyyyyyyy-mmyyyy-mm-ddyyyy-mm-ddThh:mm:ssZ当该元数据含有对应的数字对象时,需要在元数据中携带CALIS-OID(1)需要在元数据中携带CALIS-OID,型如:<identifier scheme=’CALIS-OID’>urn:CALIS:211011-ETD/C2005000001</identifier> ——这种校验的错误代码为02001F。
(2)需要在元数据中携带format(从《CALIS METS包结构规范》附注一中取值)——这种校验的错误代码为02001G。
e)当含有CALIS-OID时,CALIS-OID的构成方式必须符合《CALIS数字对象唯一标识符命名规范》中复杂对象CALIS-OID的命名方式,即型如:“urn:CALIS:”+“高校馆代码或资源商代码”+“-”+“本地集合名”+“/”+“本地标识”——这种校验的错误代码为01015。
f)当元数据中含有学科信息时,需要提供相应的学科代码信息。
i.对于教育部学科代码,型如<subject scheme=’disciplineList’>教育部学科代码</subject>——这种校验的错误代码为02008。
ii.对于其他的学科代码,采用相应的学科代码值表进行校验(e)取出record->about下的METS包XML片断,并按以下步骤对其进行校验a)利用METS 1.3的Schema对METS数字对象文件进行校验,schema地址为:/standards/mets/version13/mets.xsd——这种校验的错误代码为01014。
b)取出mets元素的属性LABEL的值,该值必备,而且必须与OAI Record文件的文件名称中的“完整的MetaID”部分的值一致——这种校验的错误代码为02007A。
c)取出mets元素的属性OBJID的值,该值必备,而且必须元数据(metadata)中的CALIS-OID的值一致——这种校验的错误代码为02007B。
d)取出mets元素的属性PROFILE的值,该值有则必备——这种校验的错误代码为02007C。
e)取出mets->metsHdr的属性LASTMODDATE的值,如有数字对象(存在mets->file)则该值必备,而且必须为20位零时区时间——这种校验的错误代码为02007D。
3.2对OAI记录数据的校验对“OAI记录数据”,按照“CALIS OAI Record V2.0格式”要求进行校验,该校验工作包括以下几个方面:(1)对OAI Record内容进行校验(a)用OAI-PMH Schema(record.xsd)校验XML文件是否合法,schema地址为:/OAI/2.0/OAI-PMH.xsd——这种校验的错误代码为01008。
(b)取出record->header->datestamp下的元数据时间戳的值,该值应该是一个20位的零时区时间值——这种校验的错误代码为01011。
(c)取出record->metadata下的元数据XML片断,对元数据内容进行校验f)该部分的元数据,当符合不同元数据格式时,所使用的元数据Schema是不同的,所以,需要取出根元素的xsi:schemaLocation属性值,并获得其中包含的schema的地址,利用该schema对当前元数据XML片断进行校验——这种校验的错误代码为01012。
g)根据对应格式的元数据规范和著录规则,逐一对各个元素和子元素修饰词的必备性([1,1]或[1,∞])和不可重复性([0,1]或[1,1])进行校验对于学位论文系统,若该元数据的“论文授予日期”大于等于指定的“论文必备性校验分界日期”,则采用“CALIS学位论文元数据必备性规则2”进行校验,否则采用“CALIS学位论文元数据必备性规则1”进行校验。