commit 32676a314f09b63672a59e8010757cf94aede742 Author: Wyle.Gong-巩文昕 Date: Mon May 12 14:34:50 2025 +0800 init diff --git a/assets/.DS_Store b/assets/.DS_Store new file mode 100644 index 0000000..dedae6d Binary files /dev/null and b/assets/.DS_Store differ diff --git a/assets/images/.DS_Store b/assets/images/.DS_Store new file mode 100644 index 0000000..946aa80 Binary files /dev/null and b/assets/images/.DS_Store differ diff --git a/assets/images/RESTful/RESTful.txt b/assets/images/RESTful/RESTful.txt new file mode 100644 index 0000000..c26d3fb --- /dev/null +++ b/assets/images/RESTful/RESTful.txt @@ -0,0 +1,323 @@ +RESTful接口设计要求 +1.使用范围 +本设计要求旨在基于标准的RESTfuI协议，对部分内容的使用加以约束，指导RESTfuI接口的设计人员设计出相对统 +一的接口，提高接口的可复用性，增强系统的扩展性。 +2.参考文档 +RESTful官方文档 +HTTP官方文档 +3.基本规范 +3.1命名规约 +【推荐】RESTfuI接口采用以下格式进行命名：[协议]：//[域名]/[项目代码]/[模块名称]/[版本]/[资源路径]。模块名称可 +以有多级，使用斜线（/)分开，根据项目的情况确定。 +正例：https://api.example.com/auth/v1/users/{user_id}//版本v1的查询用户列表的APl接口 +https://api.example.com/ +3.2域名 +【推荐】在不会引起跨域问题的前提下，应该尽量将API部署在专用域名之下。 +正例：https://api.example.com +3.3模块 +【强制】模块命名尽量采用全小写单词，如果需要连接多个单词，则采用中划线（一），如果要把多个单词连接起来形 +成一个具有描述性的名称则使用下划线（二）连接。 +3.4资源路径 +1.【强制】资源的路径应该从根到子依次如下： +/{resources}/{resource_id}/{sub_resources}/{sub_resource_id}/{sub_resource_property} +2.【强制】URL中不采用大小写混合的驼峰命名方式，尽量采用全小写单词，如果需要连接多个单词，则采用连接 +符，不能出现一。 +正例：/api/task_groups +反例：/api/task-groups +3.【强制】接口路径使用资源名词而非动词，动作应由HTTPMethod体现，资源组可以进行逻辑嵌套 +正例：POST/api/tasks或/api/task_groups/1/tasks表示在id为1的任务组下创建任务 +反例：POST/api/create_task +4.接口路径中的获取复数资源的时候使接口路径中的获取复数资源的时候使用复数 +正例： +/api/tasks +反例： +/api/task/list +3.5请求参数 +1.【强制】如果有请求参数，请求参数使用小驼峰。 +2.【推荐】header中要加入一个唯一的追踪标识符“X-Trace-ID”（TraceID），用于请求的跟踪和对账。 +1 X-Trace-ID: 123e4567-e89b-12d3-a456-426614174000 +3.POST请求参数放入body中，使用json编码方式。 +正例： +1PoST http://www.eXample.com HTTP/1.1 +2 Content-Type: application/json;charset=utf-8 +3X-Trace-ID:123e4567-e89b-12d3-a456-426614174000 +4 +5["title":"test","subValue":[1,2,3]} +6 +3.6过滤信息 +【推荐】在请求时推荐使用过滤，排序和分页，减轻服务器的负担和网络通信的数据量。 +1.分页参数 +limit：指定每页显示的资源数量。 +offset：指定从哪里开始获取资源。 +1 GET /api/items?limit=10&offset=20 +。或者使用page参数： +1 GET /api/items?page=3&limit=10 +2.排序参数 +sort：指定排序的字段。 +order：指定排序的方向(升序或降序)。 +1GET/api/items?sort=created_at&order=desc +3.筛选参数 +filter：根据特定条件筛选资源。 +。可以使用多个筛选参数来细化条件。 +1 GET/api/items?filter[status]=active&filter[type]=premium +4.搜索参数 +search：对资源进行搜索。 +1 GET /api/items?search=widget +5.日期范围 +date_from和date_to：指定日期范围进行筛选 +1 GET /api/orders?date_from=2023-01-01&date_to=2023-01-31 +4.响应 +【强制】HTTP请求的返回码是200的情况下，响应数据应该包含三个属性，状态码（code）、信息描述 +(message)、响应数据(data)。 +4.1状态码 +（code) +【推荐】状态码分成三类，业务逻辑错误（1xxx）、数据验证错误（2xxx）和其它（3xxx） +·业务逻辑错误 +A +B +C +错误代码 +错误消息 +描述 +2 +1001 +InvalidOperation +请求的操作无效或未被支持。 +3 +1002 +ResourceNotFound +请求的资源不存在。 +4 +1003 +ResourceAlreadyExists +请求创建的资源已经存在。 +1004 +ResourcelnUse +资源正在使用中，无法执行请求的操作 +1005 +PermissionDenied +用户没有足够的权限执行请求的操作。 +7 +1006 +QuotaExceeded +请求的操作导致配额超限。 +8 +1007 +ServiceUnavailable +服务当前不可用，可能是临时的。 +9 +1008 +DependenciesFailed +请求的操作依赖于其他服务，而这些服务失败了。 +10 +1009 +PaymentRequired +请求的操作需要支付，但未提供支付信息。 +数据验证错误 +A +B +C +错误代码 +错误消息 +描述 +2 +2001 +ValidationError +请求的数据验证失败。 +3 +2002 +MissingField +请求中缺少必要的字段。 +4 +2003 +InvalidField +请求中的字段值无效。 +5 +2004 +FieldFormatError +请求中的字段格式错误。 +6 +2005 +FieldRangeError +请求中的字段值超出允许的范围。 +7 +2006 +FieldLengthError +请求中的字段长度不符合要求。 +8 +2007 +DuplicateEntry +请求中的数据已经存在，导致重复。 +其他错误 +A +B +C +1 +错误代码 +错误消息 +描述 +2 +3001 +Timeout +请求处理超时。 +3 +3002 +NetworkError +网络错误，如DNS查询失败或连接拒绝。 +寸 +3003 +ConfigurationError +服务配置错误，如数据库连接失败。 +5 +3004 +SystemMaintenance +系统正在维护中，暂时无法提供服务。 +6 +3005 +UnknownError +出现未知错误，无法确定具体原因。 +4.2信息描述（message） +【强制】信息描述填写项目定义的状态值。 +正例： +1//object类型数据 +2 +3 +"code":500002, +4 +"meSSage":"UNKNOWN" +5 +"data":{} +6 +4.3响应数据（data） +1.【强制】array类型数据。通过list字段，保证data的Object结构。 +正例： +//array类型数据。 +2 +3 +"code":100000, +4 +"message":"SUcCESs" +5 +"data":{ +6 +"list": [] +8 +2 +【强制】空数组使用[]，而不是null。 +正例： +"code":100000， +3 +"message":"sUcCESs" +4 +"data":{ +5 +"id":1, +6 +"role_ids":[] +反例： +1{ +2 +"code":100000, +3 +"message":"SUcCESs", +寸 +"data":{ +5 +"id":1, +6 +"role_ids": null +8} +9 +5.异步策略 +RESTfuI接口的异步策略是指在设计和实现RESTfuIAPI时采用的一种方法，它允许服务器在处理请求时不必立即返 +回结果，而是可以在处理完成后通过某种机制将结果通知给客户端。这种策略适用于那些处理时间较长或者需要等待 +其他操作完成的请求，如大量数据的处理、远程服务的调用等。 +5.1复杂业务逻辑 +利用webhooks、事件源（Server-SendEvent)、websocket等技术。 +5.2大文件上传下载 +白 +【推荐】对于大文件的上传下载建议使用异步策略，接口快速返回，文件参与的事务分别进行处理，在返回结果中携 +带可查询进度的接口地址。 +【推荐】文件上传成功返回文件ID，避免暴露内部路径。 +【推荐】设计独立的文件上传和下载接口，并独立部署避免和其它服务使用相同的网关，造成其它服务的延迟。 +6.说明文档 +接口描述 +详细解释接口的用途，包括业务场景、处理逻辑等。例如： +此接口用于获取系统中已注册用户的基本信息，包括用户名、年龄、性别等，以及它的处理逻辑和可能的业务场 +景。 +请求头 +·列出必须包含的请求头信息，如Content－Type：application/json用于表示请求体的格式为JSON。 +·对于需要身份验证的接口，说明认证相关的请求头，如Authorization：Bearer[token]。 +请求体 +·如果请求方式允许有请求体（如POST、PUT），详细说明请求体的结构。 +·给出请求体数据类型，并给出示例数据。例如： +2 +"username":"testuser" +3 +"password":"123456" +响应头 +【强制】列出可能包含的响应头信息，如“Content-Type:application/json”表示响应体为JSON格式。 +响应体&状态码 +根据不同的状态码，详细说明响应体的结构。 +给出成功和失败情况下的示例数据。例如，对于获取用户信息成功的响应： +1{ +2"id":1, +3"username":"testuser +4"age":25， +5 "gender":"male" +6} +对于错误情况，给出错误返回的示例数据： +1{ +"error":"Invalidusernameorpassword" +3} +数据格式 +数据格式 +【推荐】参数或者返回值如果有表示状态的字段，要用枚举类型定义出来。 +【推荐】时间字段以ISO8601格式返回：YYYY-MM-DDTHH:MM:SS+08:00 +【推荐】如果时间的精度要求到毫秒级别，使用UNIX时间戳。 +格式 +含义 +人人人人 +是公历中0000到9999年的十进制数字。 +“”（连字符）在字符串中实际出现两次。 +MM +是一年中从01（1月）到12（12月）的月份 +DD +是一个月中从01到31的日期。 +T +“T"出现在字符串中，表示时间元素的开始。 +HH +是自午夜以来经过的完整小时数，以00到24的两位小数表示。 +：（冒号）在字符串中实际出现两次。 +mm +是自小时开始以来的完整分钟数，从00到59的两位小数。 +55 +是自分钟开始以来的完整秒数，从00到59的两位小数。 +“（点）按字面意思出现在字符串中。 +ssS +是自第二个开始以来的完整毫秒数，以三位十进制数字表示。 +是指定为*Z”（UTC）或"+"或"-"的时区偏移量，后跟时间表达式HH:mm +正例： +1#原时间 +2Updated Date:2017-12-04T18:07:57+08:00 +3 CreationDate:2017-12-04T18:07:44+08:00 +4 Registry Expiry Date:2018-12-04T18:07:44+08:00 +5 +6#换算成北京时间： +7UpdatedDate:2017-12-05 02:07:57 +8 CreationDate:2017-12-05 02:07:44 +9Registry Expiry Date:2018-12-05 02:07:44 +7.安全 +7.1网络环境划分 +【推荐】将网络环境划分为三种，即互联网环境、石油内部网络环境以及系统内部微隔离网络环境。接口设计人员要 +依据使用环境来确定接口设计时所采用的安全策略。 +·互联网环境：与外部互联的环境。 +·石油内部网络环境：中石油的内部网络。 +7.2认证和授权 +应使用安全的身份验证和授权机制来验证客户端的身份，并确定其是否有权访问特定的资源， +7.2.1APIKey +【推荐】APTKey通常用于简单的API访问控制，适用于不需要用户授权的场景，服务器根据APIKey识别客户端并允 +议在石油内部网络或者微隔离网络中使用。 +7.2.2OAuthtoken +【推荐】OAuthToken是一种复杂的认证机制，涉及到授权流程，设置有效期，并且可以提供更细粒度的控制，在需 +要更复杂授权流程的场景建议使用OAuthToken。建议在互联网环境或者石油内部网络环境中使用。 diff --git a/assets/images/RESTful/RESTful_easy.txt b/assets/images/RESTful/RESTful_easy.txt new file mode 100644 index 0000000..e859b3a --- /dev/null +++ b/assets/images/RESTful/RESTful_easy.txt @@ -0,0 +1,389 @@ +RESTful接口设计要求 +1 +使用范围 +本设计要求旨在基于标准的 RESTful 协议。对部分内容的使用加以约束。指导 RESTful接口的设计人员设计出相对统 +-的接口。提高接口的可复用性。增强系统的扩展性。 +2.参考文档 +RESTfuI官方文档 +HTTP官方文档 +3.基本规范 +3.1 命名规约 +[推荐] RESTfuI 接口采用以下格式迸行命名: [协议]:[域名]1[项目代码]1[模块名称]/[版本]1[资源路径] 。模块名称可 +以有多级。使用斜线(1)分开。根据项目的情况确定。 +正例: https:llapi.example.comlauthlvlusers/{user_id} II 版本 V1 的查询用户列表的 API 接0 +注意: +个产品无论辰端有多少个服务组成也应该只有 +ARI入O, 示例中的 API 入0为: +https:llapi.example.coml +3.2 域名 +[推荐] 在不会引起跨域问题的前提下 +应该尽量将 API 部署在专用域名之下。 +正例: https:llapi.example.com +3.3 模块 +[强制] 模块命名尽量采用全小写单词。如果需要连接多个单词。则采用中划线( -)。如果要把多个单词连接起来形 +成-个具有描逑性的名称则使用下划线( +)连接 + +3.4 资源路径 +[强制] 资源的路径应该从根到子依次如下: +Iresources}Iresource_id}l{sub_resources}l{sub +FeSOUTCe_ +_id}l{sub_resource +property} +(强制] URL 中不采用大小写混合的驼峰命名方式。尽量采用全小写单词; +如果需要连接多个单词 +则采用连接 +符 _ +不能出现 +正例: +/api +task_ +吕rOUps +反例: +Japi +task-groups +[强制] 接口路径使用资源名词而非动词。动作应由 HTTP Method 体现。资源组可以迸行逻辑嵌套 +正例: POST +Japi +tasks 或 /apiltask_ +Broups /I/tasks 表示在 id 为1的任务组下创建任务 +反例: POST +Japilcreate_ +ta5k +接口路径中的获取复数资源的时候使接口路径中的获取复数资源的时候使用复数 +正例: +Japi +tasks +反例: +Japi +task/list +3.5 请求参数 +(强制] 如果有请求参数。请求参数使用小驼峰 +[推荐] header中要加入一个唯 +-的追踪标识符" X-Trace-ID" (Trace ID) , 用于请求的跟踪和对账。 +X-Trace +ID: +12324567-2896-1243-3456-426614174000 +POST 请求参数放入 +body 中 +使用 json 绢码方式。 +正例: +POST http: +LWWVI +examp Le +COm HTTP/I.1 +Content-Type: +applicationyjson;charset=UCF_ +X-Trace +ID: +12324567-2896-1243- +3456-426614174000 +{"title" +Itesti +sUbValue +[1,2,3]} +3.6 +过滤信息 +[推荐] 在请求时推荐使用过滤。排序和分页。`减轻服务器的负担和网络通信的数据量 +1。分页参数 +limit +指定每页显示的资源数量。 +ffset +指定从哪里开始获取资源。 +GET +/apilitems ? limit= IO&offset- 20 +或者使用 page 参数: +GET /apilitems +page= 381imit-10 +2。排序参数 +SOrt +指定排序的字段。 +order +指定排序的方向 (升序或降序) +GET +1api/iems +sort=created_atgorder-desc +3。筛选参数 +filter +根据特定条件筛选资源。 +可以使用多个筛选参数来细化条件。 +GET +1api/items +filter [status ]=activegfilter [type] =premium +4。搜索参数 +Search +对资源迸行搜索。 +GET +1api/iems +search-widget +日期范围 +date_ +from +date +to +指定日期范围进行筛选。 +GET +1api/orders +date +From-2023-01-018date_ +t0=2023-01-31 +4.响应 +[强制] HTTP请求的返回码是200的情况下。响应数据应该包含三个属性。状态码 (code) +信息描述 +(message) , 响应数据 (data) _ +4.1 状态码 (code) +[推荐] 状态码分成三类。业务逻辑错误 +(1XXX) +数据验证错误 +(2xxX) 和其它 +3XXXI +业务逻辑错误 +错误代码 +错误消息 +描述 +1001 +Inyalidoperation +请求的操作无效或未被支持 +1002 +ResourceNotFound +请求的资源不存在 +1003 +ResourceAlreadyExists +请求创建的资源已经存在。 +1004 +ResourcelnUse +资源正在使用中。无法执行请求的操作。 +1005 +PermissionDenied +用户没有足够的权限执行请求的操作。 +1006 +QUOtaExceeded +请求的操作导致配额超限。 +1007 +SericeUnavailable +服务当前不可用 +可能是临时的。 +1008 +DependenciesFailed +请求的操作依赖于其他服务_ +而这些服务失败了 +1009 +PaymentRequired +请求的操作需要支付。但末捉供支付信息 +数据验证错误 +错误代码 +错误消息 +描述 +2001 +ValidationError +请求的数据验证失败 +2002 +MissingField +请求中缺少必要的字段 +2003 +InvalioField +请求中的字段值无效_ +2004 +FieldFormatError +请求中的字段格式错误。 +2005 +FieldRangeError +请求中的字段值超出允许的范围。 +2006 +FielaLengthError +请求中的字段长度不符合要求。 +2007 +DuplicateEntry +请求中的数据已经存在。导致重复= +其他错误 +错误代码 +错误消息 +描述 +3001 +Timeout +请求处理超时 +3002 +NetworkError +网络错误 +如DNS查询失败或连接拒绝 +3003 +ContigurationError +服务配叠错误。如数据库连接失败。 +3004 +SystemMaintenance +系统正在维护中。暂时无法提供服务 +3005 +UnknownError +出现未知错误。无法确定具悴原因_ +4.2 信息描述 (message) +[强制] 信息描述填写项目定义的状态值。 +正例: +object类型数据 +Icodel +500002 +"message +UNKNOWNI +I0ata" +4.3 响应数据 (data) +[强制] array 类型数据。通过 list 字段。保证 data 的 Object 结构 +正例: +/1 +array类型数据 +Icodel +100000 +Message +WSUCCESSI +Tdatal +IZist": [] +[强制1 空数组使用 [],而不是 null +正例: +Icodel +100000 +Message +ISUCCESSI +Tdatal +IiOI +IIrOLe_ +1d5" +反例 +Icodel +100000 +"message +ISUCCESS +I0ata" +Iid"; +IIFOLe_ +T05" +nU11 +5.异步策略 +RESTfuI 接口的异步策略是指在设计和实现 RESTfuL API 时采用的一种方法。它允许服务器在处理请求时不必立即返 +回结果。而是可以在处理完成后通过某种机制将结果通知给客户端。这种策略适用于那些处理时间较长或者需要等待 +其他操作完成的请求。如大量数据的处理 _ +远程服务的调用等。 +5.1 复杂业务逻辑 +在业务逻辑比较复杂 +不能第 +时间获取到结果的接口 +建议使用异步的策略。另外设计一个查询结果的接口。或者 +利用Nebhooks. 事件源 +(Server-Send Event) _ +Websocket等技术。 +5.2 大文件上传下载 +[推荐] 对于大文件的上传下载建议使用异步策略 +接口快速返回。文件参与的事务分别迸行处理。在返回结果中携 +带可查询迸度的接口地址。 +(推荐1 文件上传成功返回文件I0; +避免暴露内部路径。 +[推荐1 设计独立的文件上传和下载接口。井独立部署避免和其它服务使用相同的网关。造成其它服务的延迟。 +6。说明文档 +接口描述 +详细解释接口的用途 +包括业条场暴 +处理逻辑等。例如: +此接口用于获取系统中已注册用户的基本僖息 +包括用户名。年龄。性别等。以及它的处理逻辑和可能的业条场 +请求头 +列出必须包含的请求头信息。如 Content +TyDe: +application/json 用于表示请求体的格式为JSON +对于需要身份验证的接0 +说明认证相关的请求头。如 Authorization: +Bearer +[token] +请求体 +如果请求方式允许有请求体 (如POST PUT), 详细说明请求体的结构 +给出请求体数据类型 +并给出示例数据。例如: +Iusername +wtestuseri +Ipassword" +01234561 +响应头 +[强制] 列出可能包含的响应头信息。如"Content +Type: applicationljson " 表示响应体为JSON格式= +响应体&状态码 +根据不同的状态码。详细说朋响应体的结构 +给出成功和失败情况下的示例数据。例如。对于获取用户信息成功的响应: +Iid": +WUsername +Wtestuserl +Iagel +25, +genderw +Imale" +对于错误情况。给出错误返回的示例数据: +WeFrori +Invalid +UISername +passwordi +粝堰枚 +数据格式 +[推荐] 参数或者返回值如果有表示状态的字段 +要用枚举类型定义出来。 +(推荐1 时间字段以 ISO 8601格式返回 +YYYY-MM-DDTHH:MM:55+08:00 +[推荐] 如果时间的精度要求到毫秒级别, +使用 UNIX 时间戳。 +格式 +含义 +YYYY +是公历中0000到9999年的十进刮数字 +(连宁符〉 在字符串中实际出现两次。 +是一年中从01 (1月〉到12 (12月 的月份 +足 个月中从01到31的日期 +'T"出现在字符串中 +表示时间元秦的开始 +是自午夜以来经过的完整小时数; +以00到24的两位小敬表示。 +{冒号〉在字符串中实际出现两次。 +足自小时开始以来的完整分钟数 +从00到59的两位小数 +是自分钟开始以来的完整秒数 +从00到59的两位歆 +{总)按字面意恩出觋在字符串中 +是自第二个开始以来的完整亳秒数。以三位十进制数字表示。 +是指定为乙" {UTC) 或"+"或"-"的时区偏移显, +后跟对间表达式HHmm +正例: +原时间 +Updated +Date: 2017-12-04T18:07:57+08 +Creation Date: 2017-12 +04T18:07: 44-08:00 +ReBistry Expiry +Date: 2018-12-04T18:07:44+08:00 +换算成北京时间: +Updated +Date: 2017-12-05 02:07:57 +Creation Date: 2017-12 +05 02:07:44 +ReBistry Expiry +Date: 2018-12-05 +02:07:44 +7.安全 +7.1网络环境划分 +[推荐1 将网络环境划分为三种 +即互联网环境。石油内部网络环境以及系统内部微隔离网络环境。接口设计人员要 +依据使用环境来确定接口设计时所采用的安全策略。 +互联网环境: 与外部互联的环境。 +忑油内部网络环境: 中石油的内部网络。 +系统内部微隔离网络环境: 使用微隔离技术为 +组微服务隔离出来的独立环境。 +7.2认证和授权 +应使用安全的身份验证和授权机制来验证客户端的身份 +并确定其是否有权访问特定的资源。 +7.2.1 +API +[推荐] API Key通常用于简单的AP1访问控制。适用于不需要用户授权的场景。服务器根据API Key识别客户端并允 +许或拒绝请求。通常没有过期时间 +一旦发放 +除非手动撤销 +在这种需求情况下。使用 API Key 机制较为适宜。建 +议在石油内部网络或者微隔离网络中使用。 +7.2.2 OAuth token +[推荐] OAuth Token是 +-种复杂的认证机制。涉及到授权流程 +设置有效期 +井且可以提供更细粒度的控制。在需 +要更复杂授权流程的场景建议使用OAuth Token。 建议在互联网环境或者石油内部网络环境中使用。 +Key diff --git a/assets/images/RESTful/截屏2025-04-30 16.51.45.png b/assets/images/RESTful/截屏2025-04-30 16.51.45.png new file mode 100644 index 0000000..34e73a5 Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.51.45.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.51.55.png b/assets/images/RESTful/截屏2025-04-30 16.51.55.png new file mode 100644 index 0000000..43bc398 Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.51.55.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.52.07.png b/assets/images/RESTful/截屏2025-04-30 16.52.07.png new file mode 100644 index 0000000..482d12c Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.52.07.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.52.17.png b/assets/images/RESTful/截屏2025-04-30 16.52.17.png new file mode 100644 index 0000000..aaebbd0 Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.52.17.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.52.28.png b/assets/images/RESTful/截屏2025-04-30 16.52.28.png new file mode 100644 index 0000000..c519708 Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.52.28.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.52.38.png b/assets/images/RESTful/截屏2025-04-30 16.52.38.png new file mode 100644 index 0000000..b7cc98f Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.52.38.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.52.49.png b/assets/images/RESTful/截屏2025-04-30 16.52.49.png new file mode 100644 index 0000000..2ab2bfe Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.52.49.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.53.00.png b/assets/images/RESTful/截屏2025-04-30 16.53.00.png new file mode 100644 index 0000000..e68cab4 Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.53.00.png differ diff --git a/assets/images/RESTful/截屏2025-04-30 16.53.07.png b/assets/images/RESTful/截屏2025-04-30 16.53.07.png new file mode 100644 index 0000000..0d27c10 Binary files /dev/null and b/assets/images/RESTful/截屏2025-04-30 16.53.07.png differ diff --git a/assets/images/__pycache__/paddleocr.cpython-312.pyc b/assets/images/__pycache__/paddleocr.cpython-312.pyc new file mode 100644 index 0000000..eb0c434 Binary files /dev/null and b/assets/images/__pycache__/paddleocr.cpython-312.pyc differ diff --git a/assets/images/classification/.DS_Store b/assets/images/classification/.DS_Store new file mode 100644 index 0000000..5008ddf Binary files /dev/null and b/assets/images/classification/.DS_Store differ diff --git a/assets/images/classification/classification.txt b/assets/images/classification/classification.txt new file mode 100644 index 0000000..03807ea --- /dev/null +++ b/assets/images/classification/classification.txt @@ -0,0 +1,338 @@ +Q/SY KLD +昆仑数智科技有限责任公司企业标准 +Q/SY KLD +软件测试缺陷分类规范 +Specificationforsoftwaretestdefectclassification +（草案） +20XX-XX-XX发布 +20XX-XX-XX实施 +昆仑数智科技有限责任公司 +发布 +目 +次 +前言. +1范围... +2规范性引用文件. +1 +3术语和定义.. +3.1软件缺陷SoftwareDefect. +3.2时序TemporalSequence. +3.3时限TimeConstraint. +1 +4软件测试缺陷分类. +4.1缺陷来源类... +1 +4.2质量属性类.. +.5 +5软件测试缺陷严重等级. +7 +5.1致命.. +5.2严重.. +7 +5.3一般.. +8 +5.4轻微... +8 +参考文献... +9 +前 +言 +本文件按照GB/T1.1一2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定 +起草。 +本文件是Q/SYXXXXX《XXXXXXXX》的第1部分。Q/SYXXXXX已经发布了以下部分： +第1部分：XXXXXXXXXXXXXXXX； +第2部分：XXXXXXXXXXXXX。 +（分部分标准应有此段描述，只写出已经发布的，没有发布的可在引言中描述。） +本文件由数字和信息化管理部提出。 +（信息标准提出单位只可以是”数字和信息化管理部”或中国石油天然气集团有限公司标准化委 +员会信息技术专业标准化技术委员会”） +本文件由中国石油天然气集团有限公司标准化委员会信息技术专业标准化技术委员会归口。 +本文件起草单位：数字和信息化管理部、共享运营公司、勘探开发研究院、昆仑数智。 +（起草单位写到局级单位且为简称【在每年标准制修订计划中有简称，可查询】，应与编制说明中 +的单位对应一致，集团公司企业标准至少应由3个局级单位共同起草） +本文件主要起草人：XXX、XXX。 +（专家审查会之前，起草人应确定，排名顺序应按照编写标准的责献程度排名。） +本文件主要审查人：XXX、XXX。 +1范围 +本文件规定了软件测试缺陷的分类、等级划分的要求。 +本文件适用于软件单元、部件、配置管理、系统各个测试中的缺陷分类和分级。 +2规范性引用文件 +下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， +仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 +文件。 +GB/T15532-2008计算机软件测试规范 +GB/T38634.3-2020系统与软件工程软件测试第3部分：测试文档 +GB/T38634.4-2020系统与软件工程软件测试第4部分：测试技术 +GB/T20001.3-2015标准编写规则第3部分：分类标准 +3术语和定义 +GB/T11457中确立的以及下列术语和定义适用本标准。 +3.1 +软件缺陷SoftwareDefect +软件缺陷是指软件产品或系统中存在的错误、缺陷或不足，导致其无法满足需求规格、设计预期或 +用户期望的功能、性能、安全性等质量属性。 +3.2 +时序TemporalSequence +时序指程序执行过程中，不同操作或事件发生的时间顺序及其逻辑依赖关系。 +3.3 +时限TimeConstraint +时限指程序或任务必须在特定时间范围内完成执行的强制性要求。 +3.4 +WCAG标准WebContentAccessibilityGuidelines +WCAG（WebContentAccessibilityGuidelines，Web内容无障碍指南）是由方维网联盟（W3C）制 +定的国际标准，旨在确保残障人士能够平等访问和使用网络内容。 +4软件测试缺陷分类 +软件缺陷采用双维度分类体系，按软件测试缺陷来源和质量属性双维度分类，避免交叉重复。 +4.1缺陷来源类 +4.1.1需求缺陷 +需求缺陷指虽然软件的设计、实现与相应的系统需求及软件需求文档一致，但是系统需求或软件需 +求实际存在缺陷，产生潜在错误。 +4.1.1.1需求偏离缺陷 +需求偏离缺陷一般包括： +a）软件不能满足顾客或系统的需求，包括研制总要求、研制方案、研制任务书、需求规格规格说 +明等文档中描述的需求； +b）偏离实际使用目标，包括功能、性能、安全等需求不能满足最终用户实际使用要求； +c)需求的逻辑关系存在错误。 +4.1.1.2环境缺陷 +环境缺陷一般包括： +a）在现有的资源限制内，无法实现所有的需求； +b）不能满足软件实际运行环境需求，如软件运行环境受环境干扰，但需求中未明确抗环境干扰的 +要求。 +4.1.1.3需求描述缺陷 +需求描述缺陷一般包括： +a）需求描述不清晰或具有二义性； +b）需求描述不正确； +c）需求描述不完备。 +4.1.2设计缺陷 +设计缺陷指虽然软件实现与设计文档一致，但是软件存在设计缺陷，产生潜在错误。 +4.1.2.1容错与防错缺陷 +容错与防错缺陷一般包括： +a)缺少对中断发生的响应设计； +b）缺少对边界条件下响应设计； +c)缺少功能、性能的降级情况设计； +d）缺少对各种误操作模式响应设计； +e）缺少对各种故障模式（如数据超范围、死锁响应设计。 +4.1.2.2计算和算法设计缺陷 +计算和算法设计缺陷一般包括： +a）计算和算法设计不能满足功能需求； +b）算法设计未考虑异常数据的处理。 +4.1.2.3流程设计缺陷 +流程设计缺陷一般包括： +a）对程序逻辑路径考虑不全面； +b）功能分支设计不完善； +c）逻辑判断不正确； +d）不正确循环； +e)重复逻辑； +f）不必要的功能。 +4.1.2.4操作性和理解性缺陷 +操作性和理解性方面缺陷一般包括： +a）界面设计不科学、不合理，操作性差，界面不友好； +b）输入数据未作有效性检查； +c)参数设置不易于选择，未作缺省值设计； +d）界面缺少有效提示能力； +e）缺少运行状态监控的能力。 +4.1.3程序缺陷 +程序缺陷指软件实现与相应的文档不一致，而文档是正确的。 +4.1.3.1接口实现缺陷 +接口实现缺陷一般包括： +a）接口不正确： +1）发送的报文格式与协议不一致： +2)接收正确/异常输入（报文、参数等）处理不正确，或不处理； +3）接收不同频率报文处理不正确。 +b）中断处理不正确： +1）未对必要的数据或寄存器进行保护： +2)PUSH和POP操作不匹配； +3）中断嵌套考虑不全面； +4）中断处理不够精简，导致中断时间过长。 +4.1.3.2数据处理缺陷 +数据处理缺陷一般包括： +a）数据初始化不正确： +1）堆栈初始化不正确； +2)数组初始化不正确； +3）指针初始化不正确； +4局部变量初始化不正确； +5）全局变量初始化不正确； +6）循环变量初始化不正确。 +b）数据访问或存储不正确： +1）标志或索引设置不正确； +2)压缩或解压缩数据不正确； +3）引用了错误的数据变量； +4数据引用越界； +5）共享资源冲突； +6）内存分配与使用不正确。 +c）数据单位不正确： +1）计算后的数据单位不正确； +2)显示的计算结果单位不正确。 +d）数据的维数不正确： +1）维数定义的类型不正确； +2)数组下标使用不正确。 +e）数据范围不正确。 +f）数据定义及结构不正确。 +9）输入/输出数据不正确或遗漏。 +h）操作数据不正确或遗漏。 +4.1.3.3计算实现缺陷 +计算实现缺陷一般包括： +a）计算不正确： +1）等式中操作符不正确； +2) +等式中操作数不正确； +3) +括号使用不正确； +4亮除数为零； +5) +）对负数求平方根。 +b）精度缺陷： +1) +舍入进位或截断进位缺陷； +2) +混合运算缺陷； +3) +符号约定故障； +4) +常数有效位不够； +5) +定点比例尺选择不当。 +4.1.3.4时序时限缺陷 +时序或时限与正确的文档要求不一致，缺陷一般包括： +a）消息处理顺序不正确/不合理： +b）软件实现的运行时序不正确； +c）传输频率与规定的文档不一致； +d）I/O定时故障或不正确。 +4.1.3.5边界或端点运行状态缺陷 +软件处在边界或端点情况下运行状态缺陷一般包括： +a）软件的输入域或输出域的边界或端点运行状态缺陷； +b）状态转换的边界或端点运行状态缺陷： +c）功能界限的边界或端点运行状态缺陷； +d）性能界限的边界或端点运行状态缺陷； +e）容量界限的边界或端点运行状态缺陷。 +4.1.3.6UT界面操作显示缺陷 +UI界面实现的正确性、一致性缺陷一般包括： +a）操作和显示界面与文档要求的不一致/不符合； +b）界面文字、字符不正确； +c）界面显示风格不一致； +d）界面的菜单或功能按钮失效。 +4.1.3.7编码缺陷 +编码缺陷一般包括： +a）编程和程序输入错误； +b）违反编程风格或标准； +c）程序结构不正确： +1）控制流和顺序不正确； +2）程序处理不正确。 +4.1.4文档缺陷 +文档缺陷指软件实现与相应的文档不一致，而程序是正确的，或文档本身存在缺陷，但不影响软件 +功能性能。 +4.1.4.1文档一致性缺陷 +文档的不一致性包含文文不一致及文实不一致，其中文文不一致是指提交文档内容描述不一致，文 +实不一致是指软件实现与相应的文档不一致，而程序是正确的。 +一致性缺陷一般包括： +a）文档内容、缩略语及术语的含义前后不一致； +b）文档与程序实现不一致； +c）书面文档与联机帮助文档不一致； +d）文档之间描述不一致。 +4.1.4.2文档完整性缺陷 +文档完整性包含了文档章节内容的完整性及软件需求描述的完备性。 +完整性缺陷一般包括： +剪是否满足相关要求)； +b）文档封面内容是否完整、正确，是否包括了文档名称、版本、密级、编号、单位、编写时间； +c）文档签署是否完整，包括拟制、审核、批准等信息。 +4.1.4.3文档准确性缺陷 +文档准确性指文档内容是正确的，且在技术上和法律上是可行的。 +文档准确性缺陷一般包括： +a）存在有二义性的定义、术语或内容； +b）描述文档内容不正确、不准确（例如需求描述是不可实现的/不可测试的)； +c）存在错别字，影响对文档理解。 +4.2质量属性类 +4.2.1功能实现缺陷 +功能实现与正确的文档要求不一致，缺陷一般包括： +a）功能缺失：需求中明确要求的功能未在系统中实现； +b）逻辑错误：功能流程或业务规则实现错误，导致输出结果异常； +c）接口不一致：模块间接口定义与实现不一致，导致数据传递失败； +d）边界条件处理缺陷：未正确处理输入值的边界情况（如极值、空值、非法字符）； +e）异常处理：异常条件未处理或处理不正确； +）状态管理缺陷：系统状态（如登录状态、事务状态）切换错误或未同步。 +4.2.2性能实现缺陷 +软件性能实现不满足指标要求，缺陷一般包括： +a）处理精度：处理精度不满足指标； +b）负载能力：负载能力不满足指标； +c）高延迟缺陷：用户操作或请求响应时间过长，超出可接受范围； +d）资源泄漏缺陷：未正确释放内存、连接或文件句柄，导致资源耗尽； +e）并发处理缺陷：高并发场景下系统吞吐量下降或出现错误； +）扩展性缺陷：系统无法通过增加资源（如服务器节点）线性提升性能； +9）配置优化缺陷：代码或环境配置未针对性能优化，如缓存策略、索引缺失。 +4.2.3安全缺陷 +安全缺陷一般包括： +a）认证与授权缺陷：用户身份验证或权限管理机制的漏洞； +b）输入验证缺陷：未对用户输入进行有效过滤或验证，导致注入攻击； +c）加密缺陷：数据加密或传输过程中的安全漏洞； +d）访问控制缺陷：权限管理不当，导致未授权访问敏感功能或数据； +e）日志与监控缺陷：缺乏安全事件记录或实时监控，无法及时发现攻击行为。 +4.2.4兼容性缺陷 +兼容性缺陷一般包括： +a）浏览器兼容性缺陷：页面或功能在不同浏览器内核（如Chrome、Firefox、Safari）中表现异常； +b）操作系统兼容性缺陷：系统行为因操作系统版本（如Windows、macOS、Linux）不同而产生差 +c）设备适配缺陷：界面或功能在不同设备类型（PC、平板、手机）或分辨率下适配不良； +d）第三方依赖缺陷：因外部库、框架或服务版本更新导致的兼容性问题； +e）区域化缺陷：本地化配置（如语言、时区、货币格式）引发的问题。 +4.2.5可靠性缺陷 +可靠性缺陷一般包括： +a）容错性缺陷：系统对异常输入或环境变化的处理能力不足； +b）恢复性缺陷：故障后无法自动恢复或恢复流程不完整； +c）稳定性缺陷：长时间运行后出现性能下降或内存泄漏； +d）并发性缺陷：多用户/线程同时操作时出现竞态条件或死锁。 +4.2.6易用性缺陷 +易用性缺陷一般包括： +a）导航缺陷：用户难以找到关键功能或返回路径； +b）反馈缺陷：操作后无明确状态提示或错误信息模糊； +c）一致性缺陷：同一功能在不同页面的设计或术语不一致； +d)无障碍缺陷：不符合WCAG标准，影响残障用户使用。 +4.2.7可维护性缺陷 +可维护性缺陷一般包括： +a）代码可读性缺陷：代码命名混乱、缺乏注释或模块化不足； +b）耦合性缺陷：模块间过度依赖，修改一处引发多处错误； +c）配置缺陷：硬编码参数或配置分散，难以调整； +d）测试覆盖缺陷：关键逻辑缺乏单元测试或测试用例过时。 +4.2.8可移植性缺陷 +可移植性缺陷一般包括： +a）平台依赖缺陷：代码或组件绑定特定操作系统或硬件； +b）环境配置缺陷：系统对运行时环境（如JDK版本、库依赖）敏感； +c）数据迁移缺陷：数据格式或存储方式导致跨平台迁移失败； +d）本地化缺陷：语言、时区或区域设置未适配目标市场。 +5软件测试缺陷严重等级 +软件缺陷按其影响严重程度分为：致命（P0）、严重（P1）、一般（P2）、轻微（P3）四个等级。 +5.1致命（PO） +妨碍运行或任务的主要功能的完成；妨碍操作员完成运行或任务的主要功能。 +一般包括： +a）软件系统崩溃、主要功能完全丧失等； +b）软件主要任务没有实现； +c）软件无法通信，导致主要任务数据无法传输； +d）软件主要任务数据丢失； +e）设计架构存在致命缺陷，导致主要任务失败。 +5.2严董(P1) +对运行或任务的主要功能的完成造成不利的影响，以致降低效能，且没有变通的解决办法；给操作 +员完成由基线要求所规定的运行或任务的主要功能造成不利的影响，以致降低效能，且没有变通的 +解决办法。 +一般包括： +a）影响软件基本能力的实现，且没有已知的变通解决方案； +b）软件性能指标不满足要求； +c）软件主要功能部分丧失，次要功能全部丧失； +d）设计架构存在严重缺陷，导致主要功能无法实现； +e）软件主要功能在文档中描述不正确。 +5.3一般（P2） +对运行或任务的主要功能的完成造成不利的影响，以致降低效能，但已知有变通的解决方法；给操 +作员完成由基线要求所规定的运行或任务的主要功能造成不利的影响，以致降低效能，但已知有变通的 +解决办法。 +一般包括： +a）软件次要功能实现不完整或不正确，或影响软件基本能力的实现，但已知变通方案； +b）软件接口实现与协议不一致； +c）软件界面显示不正确（包括页面刷新有残留等）； +d）文档存在文文不一致、文实不一致等错误； +e）存在控制流、数据流等代码方面错误： +）软件边界数据或状态未处理或处理不正确； +9）软件对异常条件（包括操作、数据、命令、通信频率等）未处理或处理不正确； +h）除致命、严重、轻微外的其他缺陷。 +5.4轻微（P3） +给操作员带来不方便或麻烦，但不影响所要求的运行或任务的主要功能；所有的其他错误。即对功 +能几乎没有影响的缺陷。 +一般包括： +a）文档存在文字、排版等小缺陷； +b）界面存在错别字、显示位置不友好； +c）错误提示信息不合理/不友好。 diff --git a/assets/images/classification/classification_easy.txt b/assets/images/classification/classification_easy.txt new file mode 100644 index 0000000..f44a4c8 --- /dev/null +++ b/assets/images/classification/classification_easy.txt @@ -0,0 +1,436 @@ +Q/ISY KLD +昆仑数智科技有限责任公司企业标准 +QISY KLD +软 件 测 试 缺 陷 分类 规 范 +Specification for software test defect classification +2OXX-XX-XX 发布 +2OXX-XX-XX 实施 +昆仑数智科技有限责任公司 +发 布 +次 +前言 +范围 +2 规范饪引用文阵_ +3 术语和定义 +3.1 软件缺陷 Software Defect +3.2 莳序 Temporal Sequence。 +3.3 莳眼 Time Constraint +软件测试缺陷分类_ +4.1 +缺陷来源类 +4.2 质量屈性类 +软件测试缺陷严重等级 +5.1致命 +5.2 严重 +5.3 +5.4 t畿_ +参考文酢 +前 +言 +本文件按照 GB/T 1.1- +2020 +《标准化工作导则 +笫1部分: 标准化文件的结构和起草靓则》的规定 +起草 +本文件是 Q/SY XXXXX 《XXXXXXXX》 的笫 +部分。Q/Sr XXXXX 已经发布了以下部分: +笫1部分: +XXXXXXXXXXXXXXXX; +部分: XXXXXXXXXXXXX。 +(分部分标准应有此段描述 +只写出己经岌布的,没有岌布的可在引言中描述。) +本交件由数宁和信息化耸理部提出。 +(信息标谁提出单位兴可以是" 数字和信息化管理部" 或 +中国石油天然集团有限公司标准化委 +员会信息技术专业标淮化技术委员会 +本文件由中囤石油天然巢团有限公司标谁化委员会信息技术专业标堆化技术委员会归月。 +本交件起草单位: 数字和信息化耸理郜。共字运菅公司。勘探开发研究院。昆仑数智。 +(起草单位写到局级单位且为简称 (在每年标}制修订计划中有简称, +可查询1 +应与绢制说明中 +的单位对应一致,巢团公司企业标稚至少应由 +个局级单位共同起草) +本文件主婴起草人: +XXX +XXX +(专蒙申查会之前 +起草人应确定,排名顺序应按照编写标稚的贡献程度排名。) +本文件主婴审查人: +XXX +XXX + +范围 +本文件规定了软件浏试缺陷的分类。等级划分的婴求。 +本文件适用于软件单元。部件 +配置管理。系统各个测试中的缺陷分类和分级。 +规范性引用文件 +下列文件中的肉容通过文中的规范。引用而构成本文件必不可少的条款。其中 ,注日期的引用文件, +仅该月期对应的版本适用于本文件; 不注日期的引用文件,其最新版本 (包括所有的修改单)适用于本 +文件。 +GB T 15532-2008 计算机软件测试规范 +GBIT 38634.3-2020 系统与软件工程 软件测试 笫3部分: 测试文档 +GBIT 38634.4-2020 系统与软件工程 软件测试 第4部分: 测试技术 +GBI 20001.3-2015 标稚编写规则 笫3部分: 分类标谁 +术语和定义 +GBIT 11457 中确立的以及下列术语和定义适用本标准。 +3.1 +软件缺陷 Software Defect +软件缺陷是指软件产品或系统中存在的错误。缺陷或不足,导致其无法满足箫求规格。设计预期或 +用户期望的功能。。能。安全。等质量属。。 +3.2 +时序 Temporal Sequence +时序指程序执行过程中,不同摒作或事件发生的时间顺序及其逻辑依赖关系。 +3.3 +时限 Time Constraint +时限揖程序或任务必须在特定时间范围内完成 行的弹制。婴求 +3.4 +WCAG 标准 Web Content Accessibility Guidelines +WCG +(Web Content Accessibilit +Gudcllnes +WebH 容元障碍指南) 是由万维网联盟 +(IC〉 制 +定的国际标| +旨在确保残障人士能够平等访问和使用网络肉容 +软件测试缺陷分类 +软件缺陷采用双维度分类体系。按软件浏试缺陷来源和质量属性双维度分类。避免交叉虿复 +41 +缺陷来源类 +4.1.1 +需求缺陷 +需求缺陷指虽然软件的设计。实现与相应的系统需求及软件需求文档一致,但是系统需求或软件需 +求实际存在缺陷 +产生潸在锴误。 +4.1.1.1 +需求偏离缺陷 +需求偏商缺陷一 +~殷包括: +软件不能满足顾客或系统的需求 +包括研制总婴求。研制方案。研制任务书。箫求规格规格说 +明等交裆中描述的需求; +偏离实际使用目标 +包括功能。性能。安全等需求不能满足最终用户实际使用婴求; +箫求的逻#关系存在错误。 +4.1.1.2 +环境缺陷 +环境缺陷一殷包括: +在现有的资源限制肉。无法实现所有的需求; +不能满足软件实际运行环境需求 +如软件运行环境受环境干扰,但需求中未明确抗环境干扰的 +要求。 +4.1.1.3 +需求猫述缺陷 +需求描述缺陷一 +~殷包括: +需求描述不消晰或其有二义性; +需求描述不正确; +需求措逑不完备。 +4.1.2 +设计缺陷 +设计缺陷指虽然软件实珧与设计文档一致, +但是软件存在设计缺陷,产生潸在锴误。 +4.1.2.1 +容错与防错缺陷 +容锴与防锴缺陷一 +殷包捂: +缺少对中断发生的响应设计; +缺少对边界条件下响应设计; +缺少功能。性能的降级情况设计; +缺少对各种误操作模式响应逡计; +缺少对各种故障模式(如数据超范围。死锁)响应设计。 +4.1.22 +计算和算法设计缺陷 +计算和算法设计缺陷- +~殷包括: +计算和算法逡计不能满足功能需求; +算法设计未考虑异常'数据的处理。 +4.1.2.3 +流程设计缺陷 +流程设计缺陷 +~殷包括: +对毪序逻辑器径考虑不全面; +功能分支设计不完善; +逻辑判断不正确; +不正确循环; +虿复逻辑; +不必婴的功能。 +4.1.2.4 +操怍性和理性缺陷 +操作。利理解。方面缺陷 +~殷包括: +界面逡计不科学。不合理。操作性差。界面不友好; +揄入数据未作有效性检查; +参数设置不易于选择 ,未作缺省值设计; +界面敏少有效捉示能力; +缺少运行状态监控的能力。 +4.1.3 +程序缺陷 +程序缺陷指软件实现与相应的文档不- +~致。而文裆是正确的 +4.1.3.1 +接口实观缺陷 +接1实现缺陷 +~殷包括: +接口不正确: +1〉 发送的报文格式与协议不一致; +2) 瘘收正确/异常'输入 (报文。参数等) 处理不正确, 或不处理; +3) 菝收不同频率报交处理不正确。 +中断处理不正确: +未对必婴的数据或寄存器进行保护; +2) PUSH 利 POP 缫作不匹配; +3) 牛断嵌套考感不全面; +牛断处理不够精简,导致中断时间过长。 +4.1.3.2 +数据处理缺陷 +数据处理缺陷一 +~殷包括: +数据初始化不正确 +堆栈初始化不正确; +数组初始化不正确; +指针初始化不正确; +局部娈量初始化不正确; +全局娈量初始化不正确; +循环娈量初始化不正确= +数据访问或存储不正确 +标忐或索引设置不正确; +2) 压缩或解压缩数掂不正确; +引用了错误的数据娈量; +数据引用越界; +〉 共卓资源冲突; +内存分配与使用不正确= +数据单位不正确: +1) 计算后的数据单位不正确; +2) 晁示的计算结果单位不正确 +数据的维数不正确: +维数定义的类型不正确; +2) 数组下标使用不正确 +数据范围不正确。 +数据定义及结构不正确。 +输入/输出数据不正确或遗漏 +操作数据不正确或遗潺。 +4.1.3.3 +计算实现缺陷 +计算实现缺陷一 +~殷包括: +计算不正确: +等式牛操作符不正确; +等式中操作数不正确; +括号使用不正确; +除数为篓; +对负数求平方裉。 +精度缺隋: +舍入进位或截断进位缺陷; +泯合运算缺陷; +符号约定故障; +常'数有效位不够; +定点比例尺选择不当。 +4.1.3.4 +时序时限缺陷 +时序或时限与正确的文裆婴求不一致。缺陷- +~殷包括: +消息处理顺序不正确/不合理; +软件实现的运行时不正确; +传输频率与规定的文档不一致; +I/O 定时故障或不正确。 +4.1.3.5 +边界或端点运行状态缺陷 +软件处在边界或端点惰况下运行状态缺陷一般包括: +软件的输入域或输出域酌边界或端点运行状态鳅陷; +状态转换的边界或端点运行状态缺陷; +功能界限的边界或端点运行状态缺陷; +性能界隗的边界或端点运行状态缺陷; +容量界限的边界或端点运行状态缺陷。 +4.1.3.6 +UI 界面操作显示缺陷 +UI界面实现的正确性 +~致性缺陷一 +~般包括: +操作利显示界面与爻档婴求的不一致/不符合; +界面文宁。字符不正确; +界面显示风袼不一致; +界面的莱单或功能按钮失效。 +4.1.3.7 +绢码缺陷 +编码缺陷 +殷包捂: +编稚和程序输入错误; +违反飨程风格或标准; +翟序结构不正确: +控制沉和顺序不正确; +翟序处理不正确。 +4.1.4 +文档缺陷 +文裆缺陷指软件实琬与相应的文裆不一致。而程序是正确的,或文档本身存在缺陷,但不影啊软件 +功能。能。 +4.1.4.1 +文档一致性缺陷 +文档的不一致性包含文交不一致及文实不一致,其中文文不一致是指提交文档内容描述不一致,文 +实不一致是揖软件实现与相应的文裆不一致。而程序是正确的。 +一致。缺陷 +殷包捂: +文档肉容。绡略语及术语的含义前后不一致; +交档与翟序实现不一致; +书面文档与联机帮助文档不-致; +文档之间描述不一致。 +4.1.4.2 +文档完整性缺陷 +交裆完整性包含了交裆章书内容的完整。及软件需求描述的完备性。 +完整。缺陷- +殷包捂: +文档章节完整性主婴考察文档条甘 +内容是否桉麒文档编制所依据的标准描逑 (岩有裁剪 +剪是否满足相关婴求); +文档封面内容甚否完整。正确,甚否包括了文档名称。版本。密级。绢号。单位。绢写时间; +文档签署是否完整 +包括拟制。'审莜 +批准等信息。 +4.1.4.3 +文档准确性缺陷 +交裆准确。指文裆肉容是正确的;且在技术匕和祛袢匕是可行的。 +文裆稚确。缺陷一 +殷包捂: +存在有二义性的定义。术语或肉容; +描逑文档内容不正确 +不准确(例如需求描逑是不可实现的/不可测试的); +存在错别字 +影响对文档理解。 +42 +质量屈性类 +42. +功能实现缺陷 +功能实现与正确的文裆婴求不一致 +缺陷 +殷包捂: +功能缺失: 需求中明确翌求的功能未在系统中实现; +逻辨错误: 功能流程或业务规则实现错误,导致揄出结果异常; +接1不一 +致: 棋块i接川定义与实现不一致,导致数据传递失败; +边界条件处理缺陷: 未正确处理输入值的边界情祝 (如极值 +空位。非法宁符) +异常处理: 异常条件未处理或处理不正确; +状态管理缺陷: 系统状态 (如登录状态。事务状态) 圳换错误或末同步。 +422 +性能实现铗陷 +软件性能实珧不满足捎标婴求。缺陷一 +殷包捂: +处理精度: 处理精度不满足指标; +负载能力: 负载能力不满足指标; +高延迟缺陷: 用户操作或诮求响应时间过长,超卅可瘘受范围; +资源泄漏缺陷: 未正确释放肉存 +连接或文件句柄。导致资源耗尽; +并发处理缺陷: 高并发场景下系统吞吐量下降或出现错误; +扩展性缺陷: 系统无法通过增加资源 (如服务器节点) 线性提升性能; +配置优化缺陷: 代码或环境配置未针对性能优化,如缓存策酪。索引缺失。 +4.2.3 +安全铗陷 +安全缺陷 +殷包捂: +认证与授权缺陷: 用户身份验证或权限筐理机制的漏洞; +输入验证缺陷: 未对用户输入进行有效过滤或验证_ +导致注入攻本; +加密缺陷: 数据加密或传输过程中的安全潺洞; +访问控制缺陷: 权限管理不当 +导致未授权访问敏感功能或数据; +耳忐与监控缺陷: 缺乏安全事件记录或实时监控。无法及时发现攻击行为 +4.2.4 +莱容性缺陷 +蒹容。缺陷- +殷包捂: +浏览器兼容性缺陷: 页面或功能在不同浏览器内核 (如 Chrome, Firefox, Safori) 中表现异常; +操作系统兼容性缺陷: 系统行为困操作系统版本 (如 Windows, +Iuc05 +Linl ) +不同两产生差 +h; +设备适配缺陷: 界面或功能在不同设备类型 (PC。 平板。手机) 或分辨率下适配不良; +第三方依赖缺陷: 因外部库。框架或服务版本更新导致的兼容性问题; + +区域化缺陷: 本地化配置 (如语言 +时区。货币格式) 引发的问题。 +4.2.5 +可靠性缺陷 +可靠。缺陷- +~殷包括: +容错性缺陷: 系统对异常输入或环境娈化的处理能力不足; +恢复性缺陷: 故障后无法自动恢复或恢复流翟不完整; +稳定性缺陷: 长时间运行后出现性能下降或内存泄潺; +并发性缺陷: 多用户 /线程同时操作时出现竞态条件或死锁。 +4.2.6 +易用性缺陷 +易用。缺陷- +~殷包括: +导航缺陷: 用户难以找到关键功能或返回器径; +反馈缺陷: 操作后无明确状态捉示或锖误信息模糊; +一致性缺陷: 同一功能在不同页面的设计或术语不-致; +无障碍缺陷: 不符合 ICAG 标准 +影响残障用户使用。 +4.2.7 +可维护性缺陷 +可维护。缺陷 +~殷包括: +代码可读性缺陷: 代码命名讹乱。缺乏注释或模块化不足; +耦合性缺陷: 模块间过度侬赖 +修改 +-处引发多处错误; +配置缺陷: 硬编码参数或配置分散。难以调整; +测试覆盖缺陷: 关键逻辑缺乏单元测试或测试用例过时。 +4.2.8 +可移植性缺陷 +可移植。缺陷 +~殷包括: +平台农赖缺陷: 代码或组件绑定特定操作系统或硬件; +环境酡置缺陷: 系统对运行时环境 (如 JDK 版本。库赖)敏感; +数据迂移缺陷: 数据格式或存储方式导致跨平台迂移失败; +本地化缺陷: 语言 +时区或区域设置未适配自标市场。 +软件测试缺陷严重等级 +软件缺陷按其影响严重程度分为: 致命 (P0) +严虿 (P1) `一般 (P2) +轻微 (P3) 凹个笋级。 +5.1 +致命 (P0) +妨碍运行或任务的主婴功能的完成; 妨碍葆作员完成运行或任务的主婴功能。 +~殷包括: +软件系统崩溃。主婴功能完全丧失等; +软件主爨任务没有实现; +软件无法通信,导致主叟任务数据无法传输; +软件主娑任务数据丢失; +逡计架构存在致命缺陷。导致主婴任务失败。 +5.2 +严重 (P1) +对运行或任务的主婴功能的完成造成不利的影响,以致降低效能,且设有娈通的解决办法; 给操作 +员完成由基线婴求所规定的运行或任务的主婴功能造成不利的影响。以致降低效能 +且没有变通的 +解诀办法。 +殷包捂: +影响软件甚本能力的实现。且没有已匆的变通解诀方案; +软件性能指标不满足婴求; +软件主婴功能部分丧失 +次婴功能全部丧失; +设计架构存在严虿缺陷 +导致主娑功能无法实现; +软件主婴功能在文档中描述不正确。 +5.3 +一般 (P2) +对运行或任务的主婴功能的完成造成不利的影响。以致降低效能,但已知有娈通的解袂方祛; 给操 +作员完成由基线婴求所规定的运行或任务的主婴功能造成不利的影啊,以致降低效能,但已匆有变通的 +解诀办法。 +殷包括: +软件次娑功能实现不完整或不正确 +或影响软件甚本能力实现。但已知变通方案; +软件接口实现与协议不一致; +软件界面显示不正确 (包括页面刷新有残#等) +文档存在文文不一致。文实不一致等错误; +存在控制流。数据流等代码方面错误; +软件边界数据或状态未处理或处理不正:; +软件对异常条件 (包括操作。数据。命令。通信频率等) 未处理或处理不正确; +除致命。严五 +轻微外的其他缺陷。 +5.4 +轻微 (尸3) +给操作员带来不方便或麻烦,但不影响所婴求的运行或任务的芏婴功能; 所有的其他错误。即对功 +能几乎没有影响的缺陷。 +殷包括: +文档存在交宁。排版等小缺陷; +界面存在锖别字。显示位置不友好; +错误提示信息不合理/友好。 diff --git a/assets/images/classification/截屏2025-04-30 16.57.50.png b/assets/images/classification/截屏2025-04-30 16.57.50.png new file mode 100644 index 0000000..86d62f1 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.57.50.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.57.57.png b/assets/images/classification/截屏2025-04-30 16.57.57.png new file mode 100644 index 0000000..bb0a711 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.57.57.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.58.10.png b/assets/images/classification/截屏2025-04-30 16.58.10.png new file mode 100644 index 0000000..4b2a314 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.58.10.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.58.19.png b/assets/images/classification/截屏2025-04-30 16.58.19.png new file mode 100644 index 0000000..7eb9c97 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.58.19.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.58.30.png b/assets/images/classification/截屏2025-04-30 16.58.30.png new file mode 100644 index 0000000..7fbb87a Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.58.30.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.58.39.png b/assets/images/classification/截屏2025-04-30 16.58.39.png new file mode 100644 index 0000000..e33ab15 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.58.39.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.58.48.png b/assets/images/classification/截屏2025-04-30 16.58.48.png new file mode 100644 index 0000000..479ad4e Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.58.48.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.58.56.png b/assets/images/classification/截屏2025-04-30 16.58.56.png new file mode 100644 index 0000000..a290534 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.58.56.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.59.05.png b/assets/images/classification/截屏2025-04-30 16.59.05.png new file mode 100644 index 0000000..d4e40b0 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.59.05.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.59.20.png b/assets/images/classification/截屏2025-04-30 16.59.20.png new file mode 100644 index 0000000..268bbe6 Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.59.20.png differ diff --git a/assets/images/classification/截屏2025-04-30 16.59.27.png b/assets/images/classification/截屏2025-04-30 16.59.27.png new file mode 100644 index 0000000..fc8e83a Binary files /dev/null and b/assets/images/classification/截屏2025-04-30 16.59.27.png differ diff --git a/assets/images/demand/demand.txt b/assets/images/demand/demand.txt new file mode 100644 index 0000000..c9f84fd --- /dev/null +++ b/assets/images/demand/demand.txt @@ -0,0 +1,384 @@ +Q/SY KLD +昆仑数智科技有限责任公司企业标准 +Q/SY KLD +软件需求文档编写要求 +RequirementsforWritingSoftwareRequirement +Documents +20XX-XX-XX发布 +20XX-XX-XX实施 +昆仑数智科技有限责任公司 +发布 +目 +前 +言 +1范围. +2规范性引用文件. +3术语和定义. +4缩略语. +5需求文档编写基本原则. +6编写文档结构与内容规范 +6.1文档头部信息.. +6.2业务需求主体. +2 +6.2.1需求背景/来源. +6.2.2业务价值. +6.2.3需求描述. +6.2.4影响分析... +6.2.5验收条件 +6 +6.2.6其它.. +6.3研发需求主体. +6.3.1需求来源.. +6.3.2优先级.. +6.3.3功能架构.. +6.3.4功能描述.. +6.3.5非功能性需求描述. +8 +6.3.6验收标准.. +8 +附录A +（规范性） +标题名称 +10 +A.1 +10 +附录 +B +（资料性） +标题名称 +11 +B.1 +11 +参考文献. +12 +前 +言 +本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定 +起草。 +本文件由××××（一层组织全称）提出。 +本文件由昆仑数智科技有限责任公司科技与产品发展部归口。 +本文件起草单位：（一层组织全称） +本文件主要起草人： +本文件审查人： +需求文档编写要求 +1范围 +本文件规定了软件开发过程中业务需求和研发需求文档编写的要求 +本文件适用于昆仑数智企业软件开发过程中业务需求和研发需求文档的编写。 +2规范性引用文件 +下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， +仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 +文件。 +GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》 +3术语和定义 +下列术语和定义适用于本文件。 +3.1 +业务需求BusinessRequirements +客户/用户提出的核心目标 +3.2 +研发需求DevelopmentRequirements +系统需实现的具体功能 +4缩略语 +无。 +5需求文档编写基本原则 +清晰明确：使用简洁的技术术语，避免模翻描述；每条需求须独立成段，不可混杂多个功能点 +可验证性：每条需求需附带验收条件（如"用户登陆响应时间<2秒”）。 +唯一性标识：为每条需求分配唯一编号（格式：REQ-项目缩写-模块-序号，如REQ-ERP-AUTH-001)。 +可追溯性：需求需关联到来源（如用户反馈、会议记录、竞品分析文档编号）。 +6编写文档结构与内容规范 +6.1文档头部信息 +Q/SY KLD +文档头部固定包含以下信息： +·项目名称 +●文档版本号（格式：v1.0.0，遵循语义化版本控制） +●编写/修订日期 +·编写人/审核人 +·适用范围（如核心系统、移动端模块） +6.2业务需求主体 +6.2.1需求背景/来源 +详细描述业务场景，包括当前的市场环境、竞争对手分析、用户需求变化等，以便更好地理解需求 +的背景和重要性。为了更好的描述需求背景，可以考虑从业务驱动因素、问题场景描述等方面入手对需 +求的背景进行描述。 +·业务驱动因素 +■核心问题：当前业务遇到的痛点或机会是什么 +■示例：“现有订单系统无法支持秒级库存同步，导致超卖问题频发，近3个月用户投诉量增加 +35%。” +■关键点：当前业务现状（数据化描述）；未满足的目标或问题后果（如效率损失、成本增加、 +用户流失等）。 +●问题场景描述 +■具体场景：需求针对哪些用户或业务场景 +■示例：“商家在促销活动期间需手动调整库存，操作繁琐且容易出错，平均耗时30分钟/次。” +■关键点：用户角色（如商家、运营人员）；具体操作流程或场景痛点。 +●市场/行业背景 +■外部因素：市场需求、竞争压力或行业趋势是否驱动了该需求？ +■示例：“竞品已上线AI客服系统，用户满意度提升20%，我方需跟进以保持竞争力。” +■关键点：竞品分析、用户调研结果；行业标准或技术演进（如AI、自动化趋势）。 +●利益相关者（Stakeholders） +■相关方诉求：哪些部门或角色需要该功能 +■示例：“客服部门反馈现有工单系统无法自动分类问题，导致响应效率低下。” +■关键点：提出需求的部门或角色（如业务方、技术团队、管理层）；他们的核心诉求和目标。 +●数据支持 +■量化依据：用数据证明需求的必要性。 +■示例：“调研显示，80%的用户因支付流程复杂放弃下单，导致转化率损失15%。” +■关键点：用户调研数据、业务指标（如转化率、错误率）；历史问题发生的频率或影响范围。 +●政策/合规要求 +■法规驱动：是否因法律法规、安全标准等必须实现 +■示例：“根据《个人信息保护法》要求，用户数据导出功能需增加权限审批流程。” +■关键点：法规名称及具体要求；不合规的风险（如罚款、停业整改）。 +·关联需求/系统 +■土下文依赖：需求与其他功能或系统的关联性。 +■示例：“本需求为供应链系统升级的一部分，需与ERP系统库存模块对接。” +■关键点：上游/下游依赖的系统或功能；整体项目规划中的定位。 +完整示例： +当前会员系统的积分兑换功能仅支持实物商品，但用户调研显示：65%的用户希望积分可兑换视频平 +台会员等虚拟权益；因无法满足需求，近6个月积分闲置率高达45%，导致用户活跃度下降。此外， +竞品（如A平台）已上线虚拟权益兑换功能，其会员续费率提升20%。为提升用户粘性并跟进市场趋 +势，需扩展积分兑换场景，支持虚拟权益发放。 +6.2.1.1千系人 +列出业务相关千系人（客户、业务部门、用户代表等），针对每一类干系人的痛点进行分析。 +6.2.1.2收集方法 +描述如何收集业务需求（如访谈、问卷等）。 +6.2.2业务价值 +应明确需求的具体价值，包括对业务增长、用户体验提升、成本控制等方面的具体影响，帮助相关 +方理解实施该需求的必要性。 +需求价值的表达要避免模糊，尽量量化表达不要夸大，不要假设，区分短期和长期价值并且把用户 +视角和业务视角结合。 +可从以下几个角度入手： +●业务指标提升 +■明确需求对关键业务指标（如收入、转化率、效率）的直接影响。 +5万元。” +·用户体验优化 +■描述功能对用户操作效率、满意度或留存率的提升。 +存率提升10%。” +·成本降低或效率提升 +■说明需求如何减少资源浪费、缩短流程耗时或降低运维复杂度 +■示例：“引1入自动化部署工具后，版本发布耗时从2小时降至10分钟，团队产能提升30%。” +·风险控制或合规性 +■说明需求如何规避法律风险或系统稳定性问题。 +■示例：“实现数据加密存储后，可满足GDPR合规要求，避免潜在罚款（最高年营收4%）。 +●战略或市场竞争优势 +■关联企业长期战略目标或市场竞争需求。 +■示例：“支持多语言功能后，可拓展东南亚市场，支撑公司年度海外营收增长20%的目标。” +·技术债缓解或可扩展性 +■说明技术架构优化对未来需求的支撑作用。 +■示例：“重构订单模块后，系统可支持未来3年日均百万级订单量的增长需求。” +6.2.2.1优先级 +为每个需求分配优先级（高、中、低）。 +6.2.2.2需求分类 +需求属于功能需求、非功能需求还是接口需求。 +6.2.3需求描述 +6.2.3.1整体描述 +整体描述聚焦于它所在的模块或者系统，从更高层级或者整体的角度描述需求的功能。根据需求的 +特点可以描述他在业务架构中的坐标位置，或者明确业务上下游的交互关系，或者其它能够帮助开发人 +员理解业务特点的方式。 +6.2.3.2干系人业务流程 +从干系人视角描述该需求的业务流程 +6.2.3.3界面需求 +该章节可选。 +此处填入界面原型图 +6.2.3.3.1界面字段说明 +针对原型的界面展示字段和输入字段进行说明，格式如下： +字段名称 +数据类型 +长度 +说明 +6.2.3.3.2界面操作 +针对界面原型的操作进行说明。格式如下： +序号 +业务操作 +说明 +6.2.3.4处理逻辑详细说明 +对于复杂的处理逻辑在此具体说明，比如涉及到后台处理逻辑，处理步骤。可以通过时序图辅助说 +明。 +6.2.3.5数据描述 +数据项 +数据类型 +数据含义 +触发条件 +可选条件 +姓名 +字符型 +必填 +年龄 +整型 +必填 +6.2.3.6非功能性需求 +6.2.3.6.1性能需求 +描述系统响应时间，最大并发访问等需求， +6.2.3.6.2隔离需求 +描述项目采用的隔离策略，是逻辑隔离，还是物理隔离 +6.2.3.6.3安全需求 +描述用户认证、授权管理、链路传输、数据备份和归档等安全需求 +6.2.3.6.4运行坏境需求 +描述软件、硬件配套的要求，链路要求，以及系统可移植性的需求 +6.2.3.6.5可靠性需求 +描述系统运行的可靠性、可用性需求，是否需要HA、STANDBY、负载均衡等高可用余设计 +6.2.3.7接口需求 +与外部模块/系统的交互需求（如“与第三方支付平台对接”）。 +6.2.4影响分析 +该章节可选。 +应对需求实施可能带来的风险和影响进行全面分析，包括对现有系统、业务、用户、技术风险与挑 +战、资源投入和法律合规的影响。描述的时候可选择其中一个或者多个受到影响的因素进行描述。下面 +对这些因素进行详细说明。 +·系统影响 +■模块/功能影响：需求涉及哪些现有模块或功能需要修改 +支持角色分级。” +■接口影响：是否新增或修改接口 +示例：“支付系统需提供新版退款API（v3），旧接口逐步废弃。” +■数据影响：数据结构、存储或流程是否变化 +示例：“商品表新增预售开始时间字段，历史数据需批量初始化。” +●业务影响 +■流程变更：业务流程是否需要调整 +●示例：“财务结算流程需增加预售订单的结算周期（从T+1改为T+7）。” +■部门协作：哪些部门需要配合流程或规则变化 +示例：“客服团队需培训预售订单的售后处理规则。” +■KPI关联：对业务指标（如转化率、客单价）的预期影响。 +●示例：“预计预售功能上线后，客单价提升15%，但订单取消率可能增加5%。” +·用户影响 +■用户体验变化：用户操作流程是否简化或复杂化 +示例：“用户需在结算页手动选择“现货"或"预售"商品，操作步骤增加1步。” +■用户教育成本：是否需要引导用户适应新功能？ +示例：“需在APP首页增加预售功能引导弹窗，持续推送3天。” +·技术风险与挑战 +技术复杂度：是否存在技术难点或未知风险 +·示例：“预售库存与现货库存的实时隔离需解决高并发下的数据一致性问题。” +依赖风险：是否依赖未经验证的技术或第三方服务 +示例：“依赖第三方物流API的实时回调接口，需评估其稳定性（SLA99.9%）。” +·资源影响 +■ +人力投入：开发、测试、运维的预计工时。 +示例：“后端开发：10人日，前端开发：5人日，联调测试：3人日。” +环境依赖：是否需要特殊测试环境或数据准备 +示例：“需在测试环境模拟百万级预售订单压力测试。” +·法律与合规影响 +政策合规性：是否涉及数据隐私、消费者权益等法规 +示例： +“预售规则需明确标注发货时间，避免违反《电子商务法》第35条。” +完整示例： +影响维度 +具体内容 +风险/应对措施 +系统性能 +预售订单峰值预计达10万/分钟，需优化数据库 +风险：数据库压力过大； +分库策略。 +应对：分库+读写分离。 +用户体验 +部分用户可能因等待发货时间较长选择取消订 +应对：提供预售订单取消补偿券 +单。 +（满100减10） +合规性 +预售规则需在商品页显著位置展示发货时间。 +风险：法律纠纷； +应对：法务团队审核文案。 +6.2.5验收条件 +该章节可选。 +编写验收条件要明确输入与输出，避免模糊词汇，使用量化指标，采用“前置条件+触发动作+预期 +结果"的框架进行描述，并且要对条件进行分类，比如：功能验收、性能验收、兼容性验收等，例如： +功能验收 +描述系统在特定场景下的预期行为 +■ +例如：“当用户点击‘提交'按钮时，系统应保存表单数据并跳转到确认页面。” +性能验收 +■ +定义响应时间、吞吐量、资源占用等指标 +例如：“系统在1000并发用户下，页面加载时间应小于2秒。” +兼容性验收 +■ +明确支持的平台、设备或者版本 +例如：“功能需兼容Chrome100+、Safari15+及Firefox90+浏览器。” +安全性验收 +■ +涉及权限、数据保护等 +例如：“用户密码加密存储，且连续3次登陆失败后锁定账户30分钟。” +用户界面（UI）要求 +描述交互或视觉 +例如：“错误提示应显示为红色文本框，并自动聚集到错误字段。” +? +用户验收测试场景 +描述用户实际操作流程的验证 +■例如：“用户从商品搜索到支付完成的端到端流程需成功执行。” +验收的分类不局限于这些情况，根据实际需求可自定义。 +6.2.6其它 +该章节可选。 +可以增加其他相关信息，如实施的时间框架、预算、资源需求等。 +6.3研发需求主体 +6.3.1需求来源 +指定研发需求是从哪个业务需要分解而来，要指定需求名称、需求编号和文档版本号。 +6.3.2优先级 +根据研发需求的重要性和紧迫性，按高中低三档分配优先级。 +6.3.3功能架构 +功能架构编写要求 +●命名规范： +■一级模块：业务领域中心（如客户中心、订单中心） +■二级模块：[主体对象管理（如个人客户管理、集团客户管理） +■三级模块：[核心操作管理（如基础信息管理、权限配置） +●示例： +客户中心（一级） +一个人客户管理（二级） +一基础信息管理（三级） +一服务记录管理(三级) +一集团客户管理(二级) +一集团信息管理（三级） +一成员单位管理（三级） +6.3.4功能描述 +6.3.4.1总体描述 +功能性需求是一个总体的描述，遵循”作为<用户角色》我想要<结果>以便于<目的>”的书 +写结构，是对功能的整体描述，细节放在子章节，每一个子章节是一个功能单元（功能点）。 +6.3.4.2功能单元描述 +功能单元的编写方法采用以下两种方式： +·建议以主状谓宾或主谓宾补的固定句式进行描述。 +如：系统用户（主语）通过（介词）人员管理界面（名词）查询（谓语）用户信息（宾语），并且 +可以修改（谓语）用户的基本信息（宾语）。 +■主状谓宾：主语_状语+谓语_宾语或名词_名词+介词_动词_名词 +■主谓宾补：主语_谓语_宾语_补语或名词_动词_名词_介词+名词 +·应尽量避免将拆分表“子过程描述”内容堆叠于此。 +配图：可使用UM红流程图描述关键功能流程，每个流程对应一张图。或通过图片来直观呈现页面 +布局，展示清晰、准确即可。 +6.3.5非功能性需求描述 +该章节可选。 +非功能性需求可以按如下类型进行描述： +·非功能性需求模板 +■模板：系统应[性能描述]，以确保[业务目标或用户体验]。 +■示例：系统应能够在5秒内响应用户请求，以确保用户不会感到等待时间过长。 +业务规则需求模板 +■模板：当触发条件]时，系统应[业务规则描述]，以便[业务目标]。 +■示例：当订单金额超过1000元时，系统应自动应用10%的折扣，以便鼓励高价值订单。 +安全性需求模板 +■模板：为了[安全目标]，系统应[安全措施]，以便[保护措施描述]。 +■ +示例：为了保护用户数据，系统应要求用户在30分钟后未活动时自动注销，以便防止未授权 +访问。 +性能优化需求模板 +■模板：为了[性能目标]，系统应[优化措施]，以便性能提升描述]。 +■示例：为了提高页面加载速度，系统应优化数据库查询，以便将页面加载时间从10秒减少到 +3秒。 +月 +用户界面需求模板 +■模板：用户应能够[界面操作]，以便[用户目标]。 +■示例：用户应能够通过点击“提交"按钮来提交表单，以便快速完成注册流程。 +报告和监控需求模板 +■模板：系统应提供报告类型]，以便[监控目标]。 +■示例：系统应提供每日销售报告，以便管理层监控销售趋势。 +集成需求模板 +■模板：系统应与[外部系统集成，以便[集成目标]。 +■ +示例：系统应与财务系统集成，以便自动同步交易数据。 +维护和升级需求模板 +■模板：系统应[维护措施]，以便[维护目标]。 +■示例：系统应定期进行安全更新，以便保持系统的安全性。 +6.3.6验收标准 +验收标准的编写原则是：可量化、可验证、完整覆盖（功能，性能，安全，文档四维度） +完整示例： +1.功能实现 +（1）输入正确账号密码可跳转到首页（测试用例覆盖5种浏览器） +(2密码错误3次后锁定账户1小时（需模拟10次错误请求验证） +2.性能要求 +（1）单接口响应时间≤200ms（压测500并发通过） +（2）登录成功率≥99.9%（持续24小时监控） +3.安全要求 +(1）通过OWASPTop10漏洞扫描（报告无高危漏洞） +(2）密码传输加密（HTTPS+BCrypt算法验证） +4.交付文档 +（1）提供API接口文档（含错误码说明） +（2）提交部署配置脚本（已通过Jenkins流水线验证） diff --git a/assets/images/demand/demand_easy.txt b/assets/images/demand/demand_easy.txt new file mode 100644 index 0000000..fdd947f --- /dev/null +++ b/assets/images/demand/demand_easy.txt @@ -0,0 +1,523 @@ +Q/SY KLD +昆仑数智科技有限责任公司企业标准 +Q/SY KLD +软件需求文档编写要求 +Requirements for Writing Software Requirement +Documents +2OXX-XX-XX 发布 +2OXX-XX-XX 实施 +昆仑数智科技有限责任公司 +发 布 +次 +言。 +艳围_ +2 规范性引用文件 +3 术语利定义_ +4 缩略语_ +需求文档编写基本廪则。 +编写文档结构与肉容规范 +文档头部信息 +6.2 业务需求主体. +6.2.1 需求~景/来源_ +6.2.2 业务价#_ +6.2.3 需求描述 +6.2.4 影响分析_ +6.2.5 验收条件 +6.2.6其它. +6.3 研岌需求主体. +6.3. +需求来源_ +6.3.2 优光级_ +6.3.3 功能架构 +6.3.4 功能描述 +6.3.5 非功能性需求描述: +6.3.6 验收标璀_ +附 录 A +(规池性) +标题名称 +A.1 +附 录 +(资料。) +标题名称_ +8.1 +参 考 交 +献 +前 +言 +本文件按照 GB /T 1.1-2020 <标谁化工作导则 +部分: 标准化文件的结构和起草规则》的规定 +起草。 +本文件由 X XX +(一层组织全称) 提出。 +本交件由昆仑数智科技有限责任公司科技与产品发展部归八。 +本交件起草单位: +(一层组织全称) +本文件主婴起草人: +本文件审查人: + +需求文档编写要求 +范围 +本交件规定了软件开发过程中业务需求和砥发需求交裆编写的婴求 +本文件适用于昆仑数智企业软件开发过程中业务需求和研发箫求文裆的编写 +规范性引用文件 +下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中 ,社日期的引用交件, +仅该日期对应的版本适用于本文件; 不注日期的引用文件,其最新版本 (包括所有的修改单) 适用于本 +文件。 +GB/T1.12020 《标准化工作导则 笫 +部分: 标准化文件的绪构和起草规则》 +术语和定义 +下列术语和定义适用于本文件。 +业务需求 +Business Requirements +客户/用户捉出的核心目标 +3.2 +研发需求 +Development Requirements +系统需实现的具体功能 +缩略语 +需求文档编写基本原则 +消晰明确: 使用简洁的技术术语。避免棋糊描述; 每条需求须独立成段 +不可批杂多个功能点 +可验证性: 每条需求需附带验收条件 (如" 用户登陆响应时间<2秒" +|一。标识:为每条需求分配帷一编号(格式:REQ- 项目缩写-模坎-序号,如 REQERP-AUTH-0OI )。 +可追溯。: 需求需关联到来源 (如用户反馈。会议记录。竞品分析文裆编号) +编写文档结构与内容规范 +6.1 +文档头部信息 +Q/SYKLD +交裆头部固定包含以下信息: +项自名称 +文裆版本号 (袼式: vl00, 遵循语义化版本控制) +编写/修订日期 +编写人7审核人 +适用范围 (如核心系统。移动端祺块) +6.2 +业务需求主体 +6.2.1 +需求背景 /来源 +详细描述业务场景。包括当前的市场环境。竞争对手分柝。用户需求变化等。以便更好地理解需求 +的背景和重婴性。为了更好的描述需求背景,可以考虑从业务驱动因素。问题场景描述等方面入手对需 +求的背景进行描述。 +业务驱动困素 +核心问题: 当前业务遇到的痛点或机会是什么 +示列: +'现有订单系统无法支持砂级库存同步 +导致超卖问题频发,近3个月用户投诉量增加 +35 +关键点: +当前业务现状 (数据化描逑) +未满足的目标或问题后果 (如效宰损失。成本增加 +用户流失等) +问题场景描述 +具体场景: 需求针对那些用户或业务场景 +示列: +#商家在促销活动期间需手动调整库存 +操作繁琐且容易出锴。平均耗时30 分钟/次。 +关键点: +用户角色 (如商家。运菅人员) +具体操作流程或场景痛点。 +市场/行业背景 +外部困素: 市场需求。竞争压力或行业趋棼是否驱动了该需求? +示列: +"竞品已上线 AI 客服系统,用户满意度提升 20% +我方需跟进以保持竞争力。 +关键点: +竞品分析。用户调砥结果; +行业标准或技术潢进 (如 AI +自动化趋棼) +利益相关者 +{Stokeholdcrs) +相关方诉求: 哪些部门或角色需要该功能 +示列: +#客服部门反馈现有工单系统无法自动分类问题。导致响应效率低下 +关键点: 提卅箫求的部门或角色 (如业务方。技术团队。筐理层) ; 他们的核心诉求和目标= +数据支持 +量化侬据: 用数据证明需求的必婴性。 +示列: +#调研显示 +80%的用户因支付流穆复杂放弃下单 +导致转化荤损失15%。 +关键点: 用户调研数据。业务指标 (如转化率。锴误宰) +历史问题发生的频率或影响范围 +政策1合规婴求 +法规驱动: 是否困法袢法规。安全标准等必须实珧 +示列: +"根据 《个人信息保护法》婴求。用户数据导出功能需增加权熨审批流程。 +关键点: +法规名称及具体婴求; +不合规的风险 (如罚款。停I整改) +关联需求/系统 +匕下文依赖: 需求与其他功能或系统的关联性。 +示列: +"本需求为供应链系统升级的 +~部分 +需与 ERP 系统库存祺块对接。 +关键点: +匕游/下游侬赖的系统或功能: +整体项目规划中的定位。 +完整示列: +当前会员系统的积分兑换功能仅支持实物商品。但用户调研显示: +65%酌用户希望积分可兑换视频平 +台会员等虚拟权益; +'无法满足 隶 +近6个月积分闲置单高达 45% +导致用户活跃度下降。 +此外 +竞品 (如^平台) 己匕线虚拟权益兑换功能。其会员续费率提开 20%。 +为提升角户粘性并踉迸市场趋 +势。 扩屣积分兑换场昃。支持虚拟权益发放。 +6.2.1.1 +干系人 +列出业务相关干系人 (客户。业务部仃。用户代表等) +针对每一类干系人的痛点进行分析。 +6.2.1.2 +收集方法 +描述如何收巢业务需求 (如访谈。问卷等) +6.22 +业务价值 +应明确需求的具体价值。包括对业务增长。用户体验提升。成本控制等方面的其体影响。荪助相关 +方理解实施该需求的必婴。。 +需求价值的表达要避免棋矧,尽量量化表达不要夺人,不要假设, 区分短期和长期价值并且把用户 +视角和业务视角结合。 +可从以下几个角度入手: +业务捎标提升 +明确需求对关键业务指标 (如收入。转化宰。效率) 的直接影响 +示列: +"上线自动退颛功能后。预计客服人工处理退款工单量馘少70% +每月书省人力成本约 +5万元。 +用户体验忧化 +描述功能对用户操作效宰。满意度或留存率的提升。 +示列: +"优化搜索算法后,用户平均找到目标商品的肘间从 +分钟缩短至 15秒。预计用户氍 +存率提升10%。 +成本降低或效率提升 +说明需求如何碱少资源浪费 +缩短沉程耗时或降低运维复杂度。 +示列: +#引入自动化部署工其后 +版本发布耗时从2小时降至 t0 分钟。团卧产能捉升30%。 +风险控制或合规。 +说明需求如何规避法律风险或系统稳定。问题 +示列: +"实现数据加密存储后。可满足 GDPR 合规婴求,避免潸在罚款 (最商年菅收 4%) +战略或市场竞争忧棼 +关联企业长期战略目标或市场竞争需求C +示列: +"支持多语言功能盾。可拓展东甫亚市场 +支撑公司年度海外菅收增长 20%的甘标。 +技术偾缓解或可扩展。 +说明技术架构优化对未来需求的支撑作用。 +示列: +"虿构订单模块后。系统可支持未来 +牛日均百万级订单量的增长需求。 +6.2.2. +优先级 +为每个需求分配优先级 (高。中。低) +6.222 +需求分类 +需求属于功能需求。非功能需求还是接1需求= + +6.2.3 +需求描述 +6.2.3. +整体描述 +整体描述聚焦于它所在的棋块或者系统,从更高层级或者整体的角度描述需求的功能。裉据需求的 +特点可以描述他在业务架构中的坐标位置。或者明确业务匕下游的交互关系 +或者其它能够崭助开发人 +员理解业务特点的方式。 +6.2.3.2 +干系人业务流裎 +从干系人视角描述该需求的业务流程 +6.2.3.3 +界面需求 +该章书可选c +此处填入界齑原型囹 +6.23.3. +界面字段说明 +针对原型的界面展示宁段和输入宁段进行说明 +袼式如下= +字段名称 +数据类型 +长度 +说明 +6.23.3.2 +界面操作 +针对界面原型的操作进行说明。 +袼式如下: +序号 +业务#作 +说明 +6.23.4 +处理逻辑详细说明 +对于复杂的处理逻辑在此具体说明。比如涉及到后台处理逻辑。处理步骤。可以通过时序倒辅助说 +6.2.3.5 +数据描述 +数握项 +数据类型 +数抿含义 +触发条仵 +可选条件 +姓多 +字符型 +必填 +中龄 +整型 +必填 +6.2.3.6 +非功能性需求 +6.2.3.6.1 +性能:求 +描述系统响应时间 +最大并岌访问等需求 +6.23.6.2 +隔离需求 +描述项目采用的隔商策略 +是逻辑隔离,还是物理隔商 +6.2.3.6.3 +安全需求 +描述用户认证。授权筐理。链路传输。数据备份和归裆竽安全需求 +6.2.3.6.4 +运行环境需求 +描述软件。硬件配食的婴求。链路婴求。以及系统可移植。的需求 +6.2.3.6.5 +可靠性:求 +描述系统运行的可靠性。可用性需求。是否需婴 HA, STANDBY , 负载均衡等高可用冗余设计 +6.2.3.7 +接口需求 +与外部棋块/系统的交互需求 (如"与第三方支付平台对接") +6.2.4 +影响分析 +该章书可选。 +应对需求实施可能带来的风险和影响进行全齑分析,包括对现有系统。业务。用户。技术风险与挑 +战。资源投入和法律合规的影响。描述的时候可选择其中一 +个或者名个受到影响的困素进行措述。 +下面 +对这些困素进行详细说明 +系统影啊 +棋块/功能影啊: 需求涉及那些琬有棋块或功能需婴修改 +示列: +"订单创建模块需新增预售订单类型处理逻辑。 +"用户牛心需扩展杈限管理功能= +支持角色分级。 +接1影响: 是否新增或修改接八 +示列: +"支付系统需捉供新版退弑 API +〈31 +|接口逐步废弃。 +数据影啊: 数据结构。存储或流程是否娈化 +示列: +"商品表新增预臂开始时间宁段。历史数据需批量初始化。 +业务影啊 +流程娈更: 业务流程是否需婴调整 +示列: +"财务结算流程需增加预臂订单的结算周期 (从 TtI 改为T+7) +部门协作: 哪些部门需婴配合流程或规则娈化 +示列: +"客服困卧需培训预臂订单的售后处理规则。 +KPI 关联: 对业务指标 (如转化宰。客单价) 的预期影响。 +示列: +*预计预臂功能匕线后。客单价提升 15% +但计单取消率可能增加 5% +用户影啊 +用户体验娈化: 用户缫作流程是否简化或复杂化 +示列: +"用户需在结算页于动选择'现货'或'预臂'商品,操作步骤增加 +步。 +用户教爷成本: 是否需婴引导用户适应新功能? +示列: +*需在 APP 首页增加顸售功能引导弹窗,持续推送 +天。 +技术风险与祧战 + +技术复杂度: 是否存在技术难点或未知风险 +示列: +"预臂库存与现货库存的实时隔离需解诀高并发下的数据一致性问题。 +依赖风险: 是否依歉未经验证的技术或第三方服务 +示列: +"依赖笫三方彻流 API 的实时回调接口,需评估其稳定性 (SLA 99.9% ) +资源影啊 +人力投入: 开发 +测试。运维的预计工时。 +示列: +"后端开发: 10人日,前端开发: 5人日。联调浏试: 3人月。 +环境依歉: 是否需婴特殊浏试环堍或数据稚备 +示列: +"需在测试环垸模拟百万级预臂订单压力测试。 +法律与合规影啊 +政策合规性: 是否涉及数据隐私。消费者权益等法规 +示列: +"预臂规则需明确标注发货时间。避免违反《电子商务法》第35条。 +整示列: +影响雏度 +具体肉容 +风险/应对措施 +系统。能 +琐售计单峰预计达 10 万1分钟 +需优化数据库 +El 险: +数据库压力过犬; +分库策略 +应对: 分库+读写分离 +用户体验 +部分用户可能困等待发货时间较长选择取消计 +应对: 挺供预售订单取消补偿券 +(满 IO0 馘10) +合规。 +预售规则需在商品页显著位置展示发货时间 +风险: 法律纠纷; +应-: +法务团队审核交案 +6.2.5 +验收条仵 +该章书可选。 +编写验收条件婴明确输入与输出。避免棋矧词汇,使用量化指标_ +采用"前置条件+触发动作+预期 +结果"的框架进行描述 +并且翌对条件进行分类 +比如: 功能验收 +性能验收 +兼容性验收等, +例如: +功能验收 + +描逑系统在特定场景下的预期行为 +例如: *当用户点击 `提交'按钮时,系统应保存表单数据并跳转到确认页面。 +。能验收 +定义响应时间。吞吐量。资源占用等指标 +列如: *系统在 I0O0 并发用户下。页面加载时间应小于2秒。 +蒹容性验收 +明确支持的平台 设备或者版本 +列如: *功能需兼容 Chrome 100+ +Safori 15+ 及 Fitefox 90+浏览器。 +安全。验收 +涉及杈限。数据保护等 +例如: *用户密码加密存储 +且连续 +次登陆失败斥锁定账户30 分钟。 +用户界面 (UI〉 要求 +描述交互或视觉 +例如: *错误提示应显示为红色文本框 +并自动聚集到错溟宁段。 +用户验收测试场景 +描述用户实际#作流程的验证 +列如: +'用户从商品搜索到支付完成的端到端流毪需成功执行。 +验收的分类不局限于这些情祝。根据实际需求可自定义。 +6.2.6 +其它 +该章书可选。 +可以增加其他相关信息。如实施的时间框架。预算。资源需求等。 +6.3 +研发需求主体 +6.3.1 +需求来源 +指定研发需求是从聊个业务需婴分解而来,婴指定需求名称。需求编号和文裆版本号。 +6.3.2 +优先级 +根据砥发需求的虿婴性和紧迫性。按高中低三档分配优先级。 +6.3.3 +功能架构 +功能架构编写要求 +采用三级分层结构,需包含功能树图 +(Tisio +UNL 图) 辅助说明 +命名规范: +~级棋块: [业务领域牛心 (如客户牛心 订单4心) +二级棋块: [主体对象]管理 (如个入客户管理。集团客户管理) +三级棋块: [核心操佾管理 (如基础信息管理。衩限酡置) +示列: +客户中心(一级) +个人客户管理〈二级) +基础信息管理 +〈二级〉 +服务记录管理〈三级) +巢团客户管理(二级) +卜巢团信息管理 (三级) +成员单位管理〈三级) +6.3.4 +功能描述 +6.3.41 +总体描述 +功能性需求是一个总体的描述。谥循" 作为 <用户角色> 我想婴<结果〉 以便于 <甘的> +的书 +写结构,是对功能的整体描述。细节放在子章节 +每一个子章节是一个功能单元(功能点) +6.3.42 +功能单元描述 +功能单元的编写方法采用以下两种方式: +建议以主状诮宾或主诮宾补的固定句式进行描述。 +如: 系统用户〈主语)通过〈介词〉人员管理界面〈名词〉查询〈谓语〉用户僖息〈宾语) +并且 +可以修改〈诮语)用户的基本信息〈宾语) +主状诮宾 +主语_状语+诮语_宾语 或 名词_名词-介词_动词_名词 + + +主诮宾补: 主语_诮语 _宾语_补语 或 名词_动词_名词_介词+名词 +应尽量避免将拆分表"子过程描述"内容堆叠于此。 +配图: 可使用 UNL 流毪图描述关键功能流毪 +每个流程对应一 +~张图。或通过图片来直观呈现页面 +布局。展示消晰 谁确即可。 +6.3.5 +非功能性需求描述 +该章节可选。 +非功能。需求可以按如下类型进行描述: +非功能。需求棋板 +棋板: 系统应[性能描进],以确保[业务目标或用户体验]。 +示列: 系统应能够在 5秒内响应用户请求, +以确保用户不会感到竿待时间过长。 +业务规则需求模板 +棋板: 当[触发条件]时。系统应[必务规则描逝 +以便[业务目柄。 +示列: 当计单金额超过 IOO0 元时 +系统应自动应用 10%的折扣,以便鼓励高价值计单。 +安全。需求棋板 +棋板: 为了[安全目柄],系统应[安全措硇] +以便[保护措施描d。 +示例: 为了保护用户数据。系统应婴求用户在 +分钟后未活动肘自动注销,以便防止未授权 +访问。 +。能优化需求模板 +棋板: 为了[性能目柄,系统应[优化措硇] +以便[。能捉升描逝= +示列: 为了捉商页面加载逑度 +系统应优化数据库查询。以便将贞面加载时间从 +秒诚少到 +用户界面需求棋板 +棋板: 用户应能够[界面操佾,以便[用户目柄。 +示列: 用户应能够通过点击"捉交"按钮来捉交表单,以便快递完成注册流翟。 +报告和监控需求棋板 +棋板: 系统应提供[报告类型,以便[监控目柄。 +示列: 系统应捉供每日销售报告 +以便筐理层监控销售趋棼。 +巢成需求棋板 +棋板: 系统应与外部系统]集成。以便[集成目柄。 +示例: 系统应与务系统粜成。以便自动同步交易数据。 +维护和升级需求棋板 +棋板: 系统应[维护措施],以便[雏护目柄。 +示例: 系统应定期进行安全更新。以便保持系统的安全。。 +5.3.6 +验收标准 +验收标准的编写原则是: 可量化。可验证。完整覆盖 (功能 +性能 +安全 +交裆吗维度) +完整示列: +1.功能实现 +输入正确账号密码可跳转到苜页 (潮试用例羧盖 +种浏览器) +密码错误 +次后锁定账户 +小时 (箫模拟 10 次错误黹求验证) +性能要求 +单接口啊应时间^ 20Oms ( 压测 500 并发逦过) +登录成功宰>99.9% (持续24小肘监控) +3。安全要求 +逦过 OWASP Top 10 漏洞扫描 (报告无高危漏洞) +密码传输加密 (HTTPStBCtpt 算法验证) +交付文档 +提供 APT 接]文档 (含错误码说明) +提交部署配置龇本 (巳逦过 Jenkins 流水线验证) diff --git a/assets/images/demand/截屏2025-04-30 17.07.06.png b/assets/images/demand/截屏2025-04-30 17.07.06.png new file mode 100644 index 0000000..a0da692 Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.07.06.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.07.13.png b/assets/images/demand/截屏2025-04-30 17.07.13.png new file mode 100644 index 0000000..f4ba8d3 Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.07.13.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.07.19.png b/assets/images/demand/截屏2025-04-30 17.07.19.png new file mode 100644 index 0000000..446b1b7 Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.07.19.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.07.27.png b/assets/images/demand/截屏2025-04-30 17.07.27.png new file mode 100644 index 0000000..287622c Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.07.27.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.07.36.png b/assets/images/demand/截屏2025-04-30 17.07.36.png new file mode 100644 index 0000000..37fe12f Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.07.36.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.07.44.png b/assets/images/demand/截屏2025-04-30 17.07.44.png new file mode 100644 index 0000000..d51733c Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.07.44.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.07.52.png b/assets/images/demand/截屏2025-04-30 17.07.52.png new file mode 100644 index 0000000..9e20d4a Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.07.52.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.08.00.png b/assets/images/demand/截屏2025-04-30 17.08.00.png new file mode 100644 index 0000000..78a9ba8 Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.08.00.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.08.13.png b/assets/images/demand/截屏2025-04-30 17.08.13.png new file mode 100644 index 0000000..6904fcf Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.08.13.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.08.19.png b/assets/images/demand/截屏2025-04-30 17.08.19.png new file mode 100644 index 0000000..eb1a96a Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.08.19.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.08.29.png b/assets/images/demand/截屏2025-04-30 17.08.29.png new file mode 100644 index 0000000..8436168 Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.08.29.png differ diff --git a/assets/images/demand/截屏2025-04-30 17.08.34.png b/assets/images/demand/截屏2025-04-30 17.08.34.png new file mode 100644 index 0000000..1525544 Binary files /dev/null and b/assets/images/demand/截屏2025-04-30 17.08.34.png differ diff --git a/assets/images/dms1/.DS_Store b/assets/images/dms1/.DS_Store new file mode 100644 index 0000000..816c1f8 Binary files /dev/null and b/assets/images/dms1/.DS_Store differ diff --git a/assets/images/dms1/dms/dms.txt b/assets/images/dms1/dms/dms.txt new file mode 100644 index 0000000..c53d9c9 --- /dev/null +++ b/assets/images/dms1/dms/dms.txt @@ -0,0 +1,409 @@ +DMS合规性认证 +中李莹 +2024年7月10日创建 +1.背景 +对标OSDU技术体系，攻关多软件数据高效共享技术，研发油气行业工业软件所需的数据共享标准、数据工作流、开 +放领域数据服务、数据安全工具和成果知识库，打破各工业软件之间的数据孤岛，为各工业软件提供一体化数据支 +撑。 +油田开发 +非常规工 +数 +数据引入 +工作流 +作流 +据 +公 +消 +费 +数据源 +数据治理 +数据引入 +数据发现 +数据充实 +数据交付 +数据安全 +依据策略、 +所属等对数 +对数据源的 +对元数据进 +加工、改进 +根据数据消 +通过认证、 +数据提取元 +行索引，支持 +和丰富数据 +费需要提供 +授权、数 +据添加标签， +地震处理软件 +管理。元数 +数据，并且绑 +对属性和语 +生产出高质 +文件、数据 +据授权云 +地震解释软件 +据、体数据 +定正确的使 +义检索 +量或新概念 +集下载服务， +原生安全 +匹配检查； +用标签 +的衍生物 +各领域数据 +边界提供 +地质建模软件 +CRS检查； +服务 +全面的安 +测井解释软件 +可视化扫描 +全机制 +管网仿真软件 +健层改造软件 +领域数据 +发现/细化/充实 +提供基于井筒、地震、地面管网、油气藏等专业共享交换模型的领域数据服务（DDMS），结合平台数据集及文件服 +务，实现工业软件领域数据共享。 +共享微件 +大类1 +目录1 +管理树 +子类1 +对象树 +节点1 +子类2 +节点2 +大类2 +目录2 +工作空间 +节点类型 +对象树模板 +（类别名称。DMS服务类别 +数据索引组织 +lcon，网性1，属性2. +编目结构 +节点信息 +寻址信息 +权限管控、标签 +（定义信息、DMS获取信息） +(DMS源，服务URL，参数KV) +主数据 +DMS +DMS +DMS +DMS +DMS +DMS +DMS +DMS +地质 +物探 +井筒 +油气藏 +油气生产 +地面工程 +外源 +空间数据 +虚拟/物理数据入湖 +数据湖！ +总部湖 +企业区域湖 +数据引入 +梦想云主湖 +工程技术 +大庆 +长庆 +塔里木 +川庆 +EISC +基于DdDMS的数据架构图 +2.DDMS合规性测试需求 +2.1用户操作流程 +1.各供应商按照统一交换标准所实现的DDMS需注册到DMS服务控制台，所注册的服务需通过质量认证测试后才能 +发布。 +DDMS控制台注册界面 +2.DDMS注册实例后，在服务审核中提交审核申请，并在申请附件中添加关于DMS业务逻辑调用流程的说明以及api +说明文档。 +DMS控制台服务审核-我的审核界面 +合规性测试服务 +基于场景的服务调用流程进行测试， +返回测试结果和外理意见 +平台需提供领域数据服务的验证功能，允许第三方实现的MX-OSDU服务接入数据生态。确保领域数据服务能够按照 +既定标准和要求自动执行数据交换和通信。自动化验证DMS服务可能包括以下几个方面： +数据模型验证：数据对象的定义和组织。 +API接口测试：验证DMS服务的应用程序接口（API）是否能够正确地执行数据读取、存储、更新和删除操作。 +数据质量检查：自动检查数据的质量，包括数据的准确性、完整性和一致性 +性能测试：评估DMS服务的性能，如响应时间和数据处理速度。 +互操作性测试：确保DMS服务能够与其他符合DMS标准的系统和应用程序无缝集成。 +安全测试：验证DMS服务的数据传输安全性，包括数据加密和访问控制。 + +DMS服务审核申请通过后完成发布 +2.2技术流程设计 +整体DMS服务的验证测试流程参考如下： +某业务实体创 +mock数据准备 +建API +某业务实体查 +业务场景流程 +自动化接口测 +按流程调用 +询API +结果断言 +认证通过 +生态接入 +梳理 +试模块 +DMS +数据比较 +DMS发布 +某业务实体修 +改API +DMSAPI准备 +某业务实体相 +关API +某业务实体删 +除API +与断言结果不一致，返回修改 +初始化时，各领域工作室需提供一套针对本专业场景的DMS合规性验证流程，根据场景的业务逻辑调用DMS，场景 +需充分覆盖DMS范围。此后若有其他供应商按照统一数据共享标准实现了一套DMS，则可复用此合规性测试流程。 +北航目前的自动化测试工具测试任务流程配置界面如下： +测试任务创建 +000 +测试工具添加 +编排测试流程 +配置数据传递规！ +测试用例生成 +运行测试任务 +查看测试结果 +自动化接口测试工具界面 +2.3示例：基于井筒共享模型的数据服务 +基于井筒共享模型的井筒中心数据服务是以对象（自然实体对象&业务成果类对象）为核心的多组领域数据服务AP的 +集合，包括对象的基础增删改查服务以及围绕对象发布的多种带条件的查询服务等。 +A +B +C +1对象 +描述 +状态 +Well +井对象分组，”井“为自然实体对象，表示一组井筒的位于地面以上的源头 +●已发布 +3 +Wellbore +井筒对象分组，”井筒”为自然实体对象，表示从地球表面的一点延伸到最大穿透点的轨迹 +●已发布 +4 +TubularAssembly +对象描述 +●未开始 +5TubularComponeni对象描述 +●未开始 +6TubularUmbilical +对象描述 +●未开始 +WellboreMarkerSe1井筒层位对象分组，描述与该井筒相交的岩石岩性变化 +●未开始 +8WellboreTrajectory井筒轨迹对象分组，用于计算二维和三维空间中计划或实际井筒的位置和空间不确定性的数据 +●正在进行 +9WellLogt +●正在进行 +Well分组已发布的API列表： +A +API +说明 +2创建井筒 +创建新井筒对象，需要用户角色是users.datalake.editors”或者‘users.datalake.admins'才有权限创建 +3获取井筒 +查询指定井筒对象，需要用户角色是users.datalake.viewers’或users.datalake.editors”或'users.datalake.admins”.并且有对应的数据权限才能 +查询到井筒对象信息 +4获取给定井筒的层位 +查询指定井筒对象的层位信息 +5获取给定井筒的轨迹 +查询指定井筒对象的井筒轨迹信息 +查询指定井筒对象的所有数据版本信息，需要用户角色是users.datalake.viewers’或‘users.datalake.editors'或‘users.datalake.admins'.并且 +6获取井筒的所有版本 +有对应的数据权限才能查询到井筒对象版本信息 +7 +获取指定版本的井筒 +查询指定数据版本的井筒对象信息，需要用户角色是users.datalake.viewers”或users.datalake.editors’或users.datalake.admins'.并且有对应 +的数据权限才能查询到井筒对象信息 +8获取给定井筒的测井信息查询指定井筒对象的测井信息 +9 +逻辑删除井筒 +逻辑删除指定数据版本的井筒对象，主要用户角色是users.datalake.editors'或users.datalake.admins'才有权限操作 +创建井筒后，在查询井筒api中能够查看新创建的井筒，获取指定版本的井筒能够查看到初始版本的井筒信息，最后 +逻辑删除井筒能够将新增井筒删除 +well-manage-controller井简中心数据服务 +GET +/dde/vell/activity查询项目 +GET +/dde/vell/activity-type查问项目类型 +GET +/dde/vell/cache/init刷新缓存 +GET +/dde/vell/changdata获取变更记录 +GET +/dde/vel1/findvel1根据井号模糊查询井信息 +GET +/findvellbyvellconnonnane +根据井号模糊查询井筒信息 +GET +/dde/ve11/findvellidandnane +根据井号模糊查询井信息（只返回井id和井 +号 +GET +/dde/vell/findvelllocation查问井坐标信息 +GET +/dde/vell/generategroupplvalue批量获取主数据id +GET +/dde/vell/getattributemap获取所有属性对应中文名 +GET +/dde/vell/getbatchinfo获取批次详细信息 +GET +/dde/vell/getchangdata获取变更记录 +2.4验证报告实例参考 +平台提供可下载的测试报告详情，供用户在附件中可供查看或者在处理意见中提供可下载的测试报告链接。 +报告编码： +报告名称：Xxx领域数据服务测试分析报告 +申请日期： +申请人： +服务供应商名称： +摘要： +测试内容包括： +序号 +服务名称 +服务功能描述 +服务参数描述 +服务返回值描述 +井信息查询服务 +提供通过井名检索等 +方式的井信息查询服 +务 +分层信息表查询服 +分层数据表新增、删 +务 +除、修改、查询服务 +3 +测井曲线解析服务 +将测井数据体，包含 +wis、las解析 +测试情况说明： +本次测试是对xxx领域数据管理服务Vx.0版本下的xx个API进行验证测试。第一轮测试：累计发现缺陷0个。 +测试结论： +本套领域数据服务已通过环境验证，系统可以正常运行。验收测试通过标准关于用例执行、DMS业务流相关文档等两 +个方面分析，该项目通过验收测试。 +检测依据： +集成开发应用支撑系统开放数据生态数据共享要求和评价第xxx部分：关于xxx领域数据服务的接口要求和测试细则。 +2.5dms调用流示例模版参考 +平台提供可下载的dms调用流模版，用户按照模版章节填写场景使用内容。 +此部分内容非必填，如果用户选择不填，则默认使用平台配置好的场景验证测试流程，若因部分DMS为实现而造成的 +测试不能通过，需要给用户提示。 +一、场景描述（示例） +场景画像： +结合专业软件直连，地震解释A模块，地震解释工作流和微件，形成一套地震智能解释应用场景 +地震解释 +专业软件 +GeoEast +其它软件 +地震智能解 +梦想云 +释微件 +体化共享数据模型&接口实现 +地震中心 +治理 +GeoEast项目库 +油田区域湖 +二、业务流/工作流描述（示例） +2.1业务流 +基础地质研究 +地震构造解释（替换部分pcg组件，升级） +地震储层预测（替换部分pcg组件，升级） +地震烃类检测（替换部分pcg组件，升级） +地震沉积解释（替换部分pcg组件，升级） +2.2模块 +由微件组合业务功能模块，完成地震和地质业务分析工作。 +2.2.1地震构造解释成果分析 +井震标定，地层对比，地震二维可视化，三维可视化， +2.2.2地震储层有利区圈定 +地震剖面叠合井曲线，工区底图，断层平面polygon，. +2.2.3储层含油气性分析 +地震属性水平切片，平剖联动，地震组合剖面， +2.2.4地层沉积微相分析 +地震剖面对比，多水平切片对比， +2.3工作流 +2.3.1地震构造解释工作流 +地震数据优选，频谱分析，层位标定，并震统层，断层解释，层位解释，速度建场，时深转换，构造成图 +员信分 +三堆可成化 +GecEast +一%一% +二幢可视化 +三维可化 +福一%一%%一%一%% +以上内容均可通过调用PBC接口获取 +三、DMS描述（示例） +3.1调用顺序及输入输出数据说明 +建议：若用户已上传openapi或swagger文档或领域数据说明书，表中的部分信息可通过文档解析获取到，用户通过 +上移下移或拖动行调整调用顺序，减轻重复录入工作量。 +建议：若用户已上传openapi或swagger文档或领域数据说明书，表中的部分信息可通过文档解析获取到，用户通过 +上移下移或拖动行调整调用顺序，减轻重复录入工作量。 +序号 +名称 +功能描述 +输入数据 +产出数据 +二维地 +地震剖面、 +地震数据体 +震剖面可 +平面显示 +视化 +三维地 +地震数据体 +地震数据体 +震可视化 +三维展示 +地层对 +过多口井地 +地震数据体，时深 +层对比，井 +关系，井分层，任 +分层，任意 +意线拐点 +线位置底图 +显示 +断层平 +断层平面 +断层多边形组合文 +面 +polygon组合 +件 +polygon +图 +* +构造成 +to图，构造 +工区网格，层位 +图 +图可视化 +3.2DMS结果断言 +序号 +名称 +结果描述 +二维地震剖面可视化 +地震剖面、平面显示 +2 +三维地震可视化 +地震数据体三维展示 +3 +地层对比 +过多口井地层对比，井分层，任意线位置底图显 +示 +断层平面polygon +断层平面polygon组合图 +n +构造成图 +tO图，构造图可视化 diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.08.05.png b/assets/images/dms1/dms/截屏2025-05-07 18.08.05.png new file mode 100644 index 0000000..5853e09 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.08.05.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.08.15.png b/assets/images/dms1/dms/截屏2025-05-07 18.08.15.png new file mode 100644 index 0000000..ea44bbf Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.08.15.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.08.23.png b/assets/images/dms1/dms/截屏2025-05-07 18.08.23.png new file mode 100644 index 0000000..7e3df18 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.08.23.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.08.36.png b/assets/images/dms1/dms/截屏2025-05-07 18.08.36.png new file mode 100644 index 0000000..95fdaab Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.08.36.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.08.43.png b/assets/images/dms1/dms/截屏2025-05-07 18.08.43.png new file mode 100644 index 0000000..fc43d20 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.08.43.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.08.50.png b/assets/images/dms1/dms/截屏2025-05-07 18.08.50.png new file mode 100644 index 0000000..fc0f468 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.08.50.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.09.00.png b/assets/images/dms1/dms/截屏2025-05-07 18.09.00.png new file mode 100644 index 0000000..448cf81 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.09.00.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.09.09.png b/assets/images/dms1/dms/截屏2025-05-07 18.09.09.png new file mode 100644 index 0000000..f372056 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.09.09.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.09.16.png b/assets/images/dms1/dms/截屏2025-05-07 18.09.16.png new file mode 100644 index 0000000..4951866 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.09.16.png differ diff --git a/assets/images/dms1/dms/截屏2025-05-07 18.09.23.png b/assets/images/dms1/dms/截屏2025-05-07 18.09.23.png new file mode 100644 index 0000000..40cdc45 Binary files /dev/null and b/assets/images/dms1/dms/截屏2025-05-07 18.09.23.png differ diff --git a/assets/images/dms1/zsy/.DS_Store b/assets/images/dms1/zsy/.DS_Store new file mode 100644 index 0000000..5008ddf Binary files /dev/null and b/assets/images/dms1/zsy/.DS_Store differ diff --git a/assets/images/dms1/zsy/2地震 (1).png b/assets/images/dms1/zsy/2地震 (1).png new file mode 100644 index 0000000..0f91681 Binary files /dev/null and b/assets/images/dms1/zsy/2地震 (1).png differ diff --git a/assets/images/dms1/zsy/2地震 (1).txt b/assets/images/dms1/zsy/2地震 (1).txt new file mode 100644 index 0000000..20f7746 --- /dev/null +++ b/assets/images/dms1/zsy/2地震 (1).txt @@ -0,0 +1,398 @@ +《开放油气数据服务规范第2部分：地震》草案_加批 +注 +CCS +中华人民共和国石油天然气行业标准XX/TXXXXX-20XX +开放油气数据服务规范 +第2部分：地震 +A A AA Specification for open data service in petroleum exploration and developmen +Part2: + Seismic exploration +202X-XX-XX发布 +202X-XX-XX实施国家能源局 +前言 +1范围1 +2 规范性引用文件1 +3术语和定义1 +3.1地震数据 seismic data1 +4 缩略语1 +5 地震数据服务体系架构1 +6地震数据交换模型2 +6.1地震数据交换模型分类规则2 +6.2 地震数据交换模型命名规则2 +6.3地震数据交换模型3 +7地震数据服务接口5 +7.1地震数据封装5 +7.2 地震数据服务接口命名规范6 +7.3地震数据服务接口功能分类6 +7.4地震数据服务接口安全要求6 +7.5 地震数据服务设计规则6 +7.6 开放地震数据服务扩展规则8 +1.前言 +油气行业作为稳定型的传统工业和典型的数字化深度应用行业，基于其复杂、多样的专业特质，具有不断创新与 +深厚的科学技术积淀。在业务数智化、能源低碳化发展的时代背景下，石油工业软件面临着新型工业业态、数据生 +态、技术与安全环境的全面变革。面对工业软件多样性和开发与运行环境迥异、数据孤岛、数据异构等复杂性，导到 +了数据交互难、成果共享难、业务协同难等问题，严重制约了全产业链的协同效率与智能化发展。通过规范并统一 +据服务接口技术，实现跨学科、跨专业数据共享与系统互操作，降低软件集成难度，推动新型工业软件的转型升级 +提升油气行业数字化转型效能，编制本系列规范。共六个部分： +一第1部分总则； +一第2部分地震； +-一第3部分 测井; +一第4部分油气藏； +-一第5部分钻井； +-一第6部分 油气生产。 +本文件是上述第2部分。 +本文件按照GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。 +请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 +本文件由提出并归口。 +本文件起草单位： +本文件主要起草人： +开放油气数据服务规范第2部分：地震 +2.范围 +本文件规定了油气行业工业软件地震勘探领域数据服务接口的体系结构、数据交换模型定义、数据封装方法和 +据服务接口清单。 +本文件适用于油气行业开放数据生态中地震数据的规范化交换、使用和互操作。 +3.规范性引用文件 +下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期 +应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 +SYT--5314-2004-地震资料采集技术规程 +SYT--5332-2005-陆上地震勘探数据处理技术规程 +SYT--5481-2003-地震勘探资料解释技术规程 +SYT-5454-2003-垂直地震剖面法勘探技术规程 +GB/T 20988 信息安全技术 信息系统灾难恢复规范 +GB/T22239 信息安全技术 网络安全等级保护基本要求 +SY/T 5232-2012石油工业软件工程规范 +GB/T 35273 个人信息安全规范 +GB/T 43697-2024数据安全技术数据分类分级规则 +开放油气数据服务规范第1部分：总则 +4.术语和定义 +下列术语和定义适用于本文件。 +地震数据 seismic data +地震数据是对地震勘探相关数据的统称，泛指在地震勘探规划、设计、采集、处理、解释与石油地质研究等活 +中所产生的所有数据，包括地震勘探工程与项目设计、野外地表调查与施工作业记录、现场采集与处理记录、室内 +理与解释过程中的文档、图件以及时间域、空间域、频率域的多维度地震数据体。 +5.缩略语 +地震数据服务应遵循SY/TXXXXX.1-202X《开放油气数据服务规范第1部分：总则》的相关要求。 +地震数据服务体系架构分为数据接口服务层和数据源端，通过数据接口服务层，整合各数据源端，将数据封装 +标准、高效、安全、可扩展的数据服务接口，通过交换模型在各应用间实现数据共享、交换与交互操作 +地震数据服务由数据交换模型与数据服务接口组成，地震数据服务体系如图1所示 +地震数据应用调用 +报报务核务接级报务核 +地震数据服务 +本系架构图 +7.地震数据交换模型 +地震数据交换模型分类规则 +地震数据服务交换模型分类可按照《GB/T43697-2024数据安全技术数据分类分级规则》中的数据分类规则 +求，可分为基础数据、采集数据、处理数据、解释数据，根据实际应用中需求，用户可自定义扩展数据类别。 +地震数据及交换模型分类如图2所示 +基础数据 +地震采集数据地震处理数据 +地震解释数据 +2.地震数据及交换模型分类 +地震数据交换模型命名规则 +地震数据服务交换模型命名规则宜采用不固定长度的分段层次码，每个段层之间用下划线字符“_"进行连接， +码总长度不宜超过30个字符。 +地震数据交换模型的命名代码结构如图3所示 +x xx +第一段（分类码） +3．地震数据交换模型命名规则 +第一段（分类码)，应使用地震数据专业英文简写“SE"作为命名分类码。 +第二段(子类限定词)，用于说明交换模型分类，推荐使用模型分类的英文简写作为子类限定词。 +第三段（实体名称码)，用于说明数据对象，宜使用数据对象首拼字母或关键英文单词作为实体名称码。若采月 +关键英文单词，最多不超过两个单词。 +地震数据交换模型 +7.1基础数据交换模型 +基础数据交换模型为用于交换地震作业活动的基本信息数据，包括地震项目、 +地震工区、工区测线等， +基础数据交换模型特征见表1。 +基础数据交换模型特征 +交换模型名称 +模型定义 +主要参数 +地震项目 +SE_BASE_Project_info +描述地震项目基本信息， +项目标识、项目名称、项 +包括采集、处理、解释以 +及采集处理解释组合项目 +系统标识、坐标系统蒋 +描述地震工区基本信息， +地震工区 +包括采集、处理、解释以 +及采集处理解释组合工区 +测线 +工区测线 +veyLine_inf描述工区测线基本信息 +测线名称、桩号、CMP +SE_BAS +No、大地坐标×值、大地 +坐标Y值 +7.2地震采集数据交换模型 +地震采集数据交换模型为用于交换原始观测数据、施工参数及配套文档，包括地震采集参数、地震观测系统等 +地震采集数据交换模型特征见表2。 +2.地震采集数据交换模型特征 +交换模型名称 +模型定义 +主要参数 +仪器检测数据 +SE_AC_Equipment_detec +记录采集设备的校准与性 +仪器类型、采样率、动态 +能参数 +ting +地表调查数据 +SE_AC_Surfce +近地表地质与地形信息， +、小折射结 +investigation +用于静校正 +果、露头参数、近地表速 +度模型 +地震施工参数 +采集作业的施工计划与执 +震源类型、接收器间距、 +Ctor +行参数 +全合规记录 +观测系统 +SE_AC_S +测线与检波器排列的空间 +测线编号、炮点坐标、检 +tion +配置 +波点坐标、最大偏移距、 +面元网格标识 +原始炮数据 +SE_AC_Shot_gather +原始地震记录数据 +数据集标识、记录格式、 +道头信息、数据安全分级 +标识 +7.3地震处理数据交换模型 +地震处理数据交换模型为用于交换地震数据处理阶段的中间成果及处理参数，包括处理流程、算法参数等。 +地震处理数据交换模型特征见表3。 +3.地震处理数据交换模型特征 +交换模型名称 +模型定义 +主要参数 +道集数据 +SE_PR_Gathers +预处理后的地震道集 +道集类型、面元网格标 +速度模型 +SE_PR_Vel +用于叠加与偏移的速度场 +速度模型版本、垂向速度 +度、横向平滑参数、关 +数据 +叠加剖面 +SE_PR_Stack +初步处理成果的二维/三维 +剖面类型、分辨率、数据 +剖面 +恰式 +/输出数据集标 +7.4 地震解释数据交换模型 +地震解释数据交换模型为用于交换地震资料解释成果的构造、地层 +地震处理数据交换模型特征见表4。 +d.地震解释数据交换模型特征 +交换模型名称 +模型定义 +主要参数 +层位 +SE_INT_Horizon +描述层位基本信息 +项目标识、工区标识、对 +型名称 +断层 +描述断层基本信息 +项目标识、工区标识、段 +层ld、断层名称 +平面属性 + SE_INT_SurfacePro +描述地震平面属性基本信 +项目标识、工区标识、平 +总求 +属性数据体 + SE INT_Attritute +提取的地震属性 +任意线 + SE_INT_Traverse +描述任意线基本信息 +项目标识、工区标识、任 +意线标识、任意线名称、 +任意线类型 +子波 +描述子波基本信息 +上区标识、于 +数、开始线号、结束线 +号、开始道号、结束道 +号、开始时间、 +结束时间 +合成记录 +描述合成记录基本信息 +项目标识、工区标识、记 +数、采样间隔 +反演成果 +岩性与物性反演结果 +反演方法、数据体范围、 +井震标定参数 +7.5扩展数据交换模型 +当6.3.1-6.3.4规定的地震数据交换模型不能满足实院 +应用需求时，可 +震数据交换模型的命名应符合6.2的规定。 +8.地震数据服务接口 +地震数据封装 +地震数据封装应遵循《开放油气数据服务规范第1部分：总则》中规定的结构化数据封装方法。 +地震数据服务接口命名规范 +地震服务接口应包含通用和专业领域两部分。 +-通用部分应按照SY/TXXXXX.1-202X《开放油气数据服务规范第1部分：总则》要求命名。 +专业领域部分接口名称宜采用驼峰命名法，命名格式为：/seismic(版本号)(交换模型名称)(接口功能}。 +地震数据服务接口功能分类 +数据安全防护措施应遵循SYTXXXX.1-202X《开放油气数据服务规范第1部分：总则》中数据服务接口分类 +求进行接口设计，地震数据服务接口功能清单见表5。 +表5地震数据服务接口功能清单 +功能 +功能代码 +含义 +查询列表数据 +abed +查询指定的交换模型的 +持分页查询 +查询数据内容 +get +查询交换模型对应的数据内容。 +新增 +ad +对指定的交换模型新增数据。 +修改 +mod +对指定的交换模型修改数据。 +删除 +del +对指定的交换模型删除数据。 +用台 +对指定交换模型导出数据。 +地震数据服务接口安全要求 +地震数据安全防护措施应遵循SYTXXXXX.1-202X《开放油气数据服务规范第1部分：总则》中数据服务接口 +全要求的相关规定，控制地震数据服务接口访问权限，并对敏感字段和数据传输进行加密。 +地震数据服务设计规则 +地震数据服务应通过7.3中数据服务接口功能分类对地震数据交换模型进行相应操作。其中，数据交换模型内容 +及数据服务接口功能应由用户根据业务实际需求确定。数据交换模型应包含6.3中给出的地震数据交换基础模型。实 +际地震数据服务见表6。 +表6 地震数据服务接口清单 +交换模型分类 +交换模型名称 +服务接口功能 +基础数据 +地震项目信息 +查询列表数据 +新增 +修改 +删除 +地震工区信息 +查询列表数据 +新增 +修改 +删除 +工区测线信息 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +地震采集数据 +仪器检测数据 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +地表调查数据 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +地震施工参数 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +观测系统 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +原始炮数据 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +地震处理数据 +道集数据 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +速度模型 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +叠加剖面 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +地震解释数据 +查询列表数据 +查询数据内容 +新增 +修改 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +平面属性 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +属性数据体 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +导出 +任意线 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +子波 +查询列表数据 +查询数据内容 +新增 +修改 +删除 +用 +扩展数据 +开放地震数据服务扩展规则 +当地震数据服务交换模型扩展时，应为其补充相应的数据服务接口。 diff --git a/assets/images/dms1/zsy/3 测井.png b/assets/images/dms1/zsy/3 测井.png new file mode 100644 index 0000000..9593bff Binary files /dev/null and b/assets/images/dms1/zsy/3 测井.png differ diff --git a/assets/images/dms1/zsy/3 测井.txt b/assets/images/dms1/zsy/3 测井.txt new file mode 100644 index 0000000..98bae5c --- /dev/null +++ b/assets/images/dms1/zsy/3 测井.txt @@ -0,0 +1,315 @@ +《开放油气数据服务规范第3部分：测井》草 +案-0507 +ICS +CCS +中华人民共和国石油天然气行业标准XX/TXXXXX一20XX +开放油气数据服务规范 +第3部分：测井 +Specification for open data service in petroleum exploration and development +Part 3: Well logging +202X- XX- XX发布 +202X-XX-XX实施 +发布 +目次 +前言I +1范围1 +2 规范性引用文件1 +3 术语和定义1 +3.1测井数据1 +4 缩略语1 +5 测井数据服务接口体系架构1 +6测井数据服务交换模型2 +6.1交换模型分类规则2 +6.2 交换模型命名规则2 +6.3 测井数据交换模型3 +6.4交换模型扩展原则4 +7测井数据服务接口4 +7.1 测井数据封装4 +7.2 测井数据服务接口命名规范4 +7.3 测井数据服务接口功能分类5 +7.4 测井数据服务接口安全要求5 +7.5 测井数据服务设计规则5 +7.6开放测井数据服务扩展规则6 +1.前言 +油气行业作为稳定型的传统工业和典型的数字化深度应用行业，基于其复杂、多样的专业特质，具有不断创新与 +深厚的科学技术积淀。在业务数智化、能源低碳化发展的时代背景下，石油工业软件面临着新型工业业态、数据生 +态、技术与安全环境的全面变革。面对油气行业工业软件多样性和开发与运行环境迥异、数据孤岛、数据异构等复杂 +性，导致了数据交互难、成果共享难、业务协同难等问题，严重制约了全产业链的协同效率与智能化发展。通过规范 +并统 +型升级，提升油气行业数字化转型效能，编制本系列规范。首批共六个部分： +－—第1部分 总则; +-一第2部分地震； +-一第3部分 测井； +一一第4部分 油气藏； +一一第5部分钻井； +-一第6部分 油气生产。 +本部分是上述的第3部分。 +请注意本部分的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 +本部分由提出并归口。 +本部分起草单位： +本部分主要起草人： +开放油气数据服务规范第3部分：测井 +2.范围 +本文件规定了油气行业测井专业的开放数据服务的体系架构、数据服务交换模型以及数据服务接口。 +本文件适用于油气行业开放数据生态中测井数据的规范化交换、使用和互操作。 +3.规范性引用文件 +GB/T38667-2020信息技术大数据数据分类指南 +SY/T XXXXX.1-202X开放油气数据服务规范第1部分：总则 +4.术语和定义 +测井数据 +测井数据是地球物理测井技术在油气勘探与开发活动中产生的综合性数据集合，泛指在测井设计、现场实施、数 +据处理、解释及储层研究等环节中生成的所有数据。其内容涵盖测井工程规划、井下仪器测量记录、动态监测数据、 +室内解释成果以及时间域、空间域、工程域的多维度测井数据体。 +5.缩略语 +JSON：JavaScript对象表示法（JavaScript Object Notation）。 +API：应用程序编程接口（Application Programming Interface）。 +HTTP：超文本传输协议(Hypertext Transfer Protocol)。 +HTTPS：超文本传输安全协议(Hypertext Transfer Protocol Secure)。 +RESTful：表述性状态传递(Representational State Transfer)。 +URL：统一资源定位符（Uniform Resource Locator）。 +6.测井数据服务接口体系架构 +测井数据服务应遵循SY/TXXXXX.1-202X《开放油气数据服务规范 第1部分：总则》的相关要求。 +为标准、高效、安全、可扩展的数据服务接口，通过交换模型在各应用间实现数据共享、交换与交互操作。 +测井数据服务由数据交换模型与数据服务接口实现。测井数据服务体系如图1所示。 +测井数据应用调用 +数据请求、鉴权、解封装等代理服务 +数据接口服务 +收据服务注册 +数据服务货口 +数报服封接 +数握服务接口 +1．测井数据服务体系架构图 +7.测井数据服务交换模型 +交换模型分类规则 +测井数据服务交换模型分类遵循《GB/T38667-2020信息技术大数据数据分类指南》中分类方法，结合测井业 +务实际，分为测井采集数据、测井处理数据、测井解释数据。 +测井数据及交换模型分类如图2所示。 +测井数据 +测井采集数据 +测井处理数据 +测井解释数据 +2．测井数据及交换模型分类 +交换模型命名规则 +测井数据交换模型命名规则宜采用不固定长度的分段层次码，每个段层之间用下划线字符“_”进行连接，代码总 +长度不宜超过30个字符。 +测井数据交换模型命名代码结构见图3。 +xx-.xxx-xxxx_xxxx +第三段(实体名称码） +第二段（子类限定词） +第一段（分类码） +3．测井数据交换模型命名规则 +第一段（分类码），应使用测井专业英文简写“WL"作为分类码。 +第二段(子类限定词)，用于说明交换模型分类，宜使用模型分类的英文简写作为子类限定词。 +第三段 (实体名称码)，用于指明数据对象名称，应使用数据对象英文名称关键词作为实体名称代码，其中关键 +词不宜多于两个英文单词。 +测井数据交换模型 +6.3.1测井采集数据交换模型 +测井采集数据交换模型用于交换测井采集作业活动的数据，包括测井采集基础信息、测量环境信息、测井遇阻/ +遇卡情况、采集资料质量评价等。测井采集数据交换模型见表1。 +表1测井采集数据交换模型 +交换模型名称 +模型定义 +主要参数 +测井采集基础信息 +WL_OPS_BASE_INFO +描述测井采集的基础信息 +井名、测井井次、测井通 +知单时间、起始时间、结 +束时间、任务类型、测井 +监督、测井公司名称等 +测量环境信息 +WL_OPS_MEA_ENVIRON」描述裸眼井测量环境信息 +测量井段顶深、测量井段 +MENT +底深、钻头程序、套管程 +序、钻井液类型、钻井液 +温度、钻井液密度、钻井 +液粘度等 +测井遇阻/遇卡情况 +WL_OPS_LOG_INTERVA +描述测井遇阻/遇卡情况 +遇阻/遇卡时间、遇阻/遇卡 +L_HUD +深度、原因及事件描述、 +处理时间等 +采集资料质量评价 +WL_OPS_QUALITY_EVA +描述测井采集资料资料质 +测井项目数、优等项目 +量 +数、合格项目数、不合格 +项目数、不合格项目等 +6.3.2测井处理数据交换模型 +测井处理数据交换模型用于交换测井处理作业活动的数据，包括测井处理基本信息、处理质量评价等。测井处理 +数据交换模型见表2。 +表2测井处理数据交换模型 +交换模型名称 +模型定义 +主要参数 +测井处理基本信息 +WL_WAP_BASE_INFO +描述测井处理基本信息 +处理类型、处理井段顶 +深、处理井段底深、处理 +软件、处理模块、处理参 +数文件名称、处理参数文 +件路径等 +处理质量评价 +WL_WAP_QUALITY_EVA + 描述测井处理质量评价结 +评价的处理项目、评价项 +果 +目的处理成果数据文件名 +称、处理内容是否齐全、 +处理结果是否达标等 +6.3.3测井解释数据交换模型 +测井解释数据交换模型用于交换测井解释活动的数据，包括测井解释基本信息、解释质量评价、测井成果表、测 +井成果图、测井解释成果文件等。测井解释数据交换模型见表3。 +表3测井解释数据交换模型 +交换模型名称 +模型定义 +主要参数 +测井解释基本信息 +WL_ACH_BASE_INFO +描述测井解释基本信息 +解释项目、解释成果图文 +件名称、解释成果图文件 +路径、解释成果数据文件 +名称、解释成果数据文件 +路径、解释报告文件名 +称、解释报告文件路径等 +解释质量评价 +WL_ACH_INTER_QUALIT +描述测井解释质量评价结 +评价的解释项目、评价项 +Y_EVA +果 +目的解释成果数据文件名 +称、评价项目的解释成果 +数据文件路径、解释内容 +是否齐全、缺失的解释内 +容等 +测井解释成果表 +WL_ACH_INTERP_RESU +描述测井解释成果表 +井号、层号、层位、顶 +LT +深、底深、有效孔隙度、 +渗透率、含油饱和度、含 +油饱和度、测井解释结论 +等 +测井解释成果图 +WL_ACH_INTERP_MAP +描述测井解释成果图 +井名、图件名称、图件大 +小、文件路径、图件格 +式、 +、下载链接等 +测井解释成果文件 + WL_ACH_INTERP_FILE +描述测井解释成果文件 +井名、文件名称、文件格 +式、文件大小、解释软 +件、顶界深度、底界深 +度、测井系列等 +6.3.4测井扩展数据交换模型 +当6.3.1-6.3.3规定的测井数据交换模型不能满足实际应用需求时，可定义并扩展其他测井数据交换模型，此类测 +井数据交换模型的命名应符合6.2的规定。 +8.测井数据服务接口 +测井数据封装 +非结构化数据封装方法如下： +图件、报告类非结构化数据封装，遵循《开放油气数据服务规范第1部分：总则》。 +对于测井数据体文件应采用“非结构化存储+结构化索引"的方式进行封装。通过该封装方式将测井数据体文件与 +相关的元数据及访问接口相结合，形成一个独立的数据对象。保持原始数据的完整性和可追溯性，并通过结构化的索 +引实现高效的数据检索和管理。 +其中，非结构化存储是指对测井原始数据文件进行原样存储，确保数据的完整性和可追溯性，不改变其格式或内 +容。结构化索引是指通过数据库或索引系统，将测井文件的元数据进行结构化存储。 +测井数据服务接口命名规范 +服务接口应由通用和专业领域两部分组成。 +-一通用部分应按照《开放油气数据服务规范 第1部分：总则》要求命名为api/dms。 +-一专业领域部分接口名称宜采用驼峰命名法，命名格式为：将/well-logging/{版本号}/{交换模型名称}/{接口功 +能}。 +测井数据服务接口功能分类 +测井服务接口按照功能可分为查询功能和操作功能两类，测井服务接口功能清单见表4。 +表4 测井数据服务接口功能清单 +接口分类 +接口功能 +功能代码 +含义 +查询功能 +查询 +page +根据指定的交换模型查询 +数据，支持分页查询 +操作功能 +新增 +ppe +使用指定的交换模型新增 +数据 +修改 +mod +使用指定的交换模型修改 +数据 +删除 +del +使用指定的交换模型删除 +数据 +下载 +download +使用指定的交换模型下载 +数据 +测井数据服务接口安全要求 +数据安全防护措施应遵循总则中数据服务接口安全要求，控制测井数据服务接口访问权限，并对敏感字段和数据 +传输进行加密。 +测井数据服务设计规则 +测井数据服务应通过7.3中数据服务接口功能对测井数据交换模型进行相应操作。其中，数据交换模型内容及数 +据服务接口功能应由用片 +井数据服务示例见表5。 +表5测井数据服务示例 +交换模型分类 +交换模型名称 +服务接口功能 +测井采集数据 +测井采集基础信息 +新增信息 +修改信息 +查询信息 +删除信息 +测量环境信息 +新增信息 +修改信息 +查询信息 +删除信息 +测井遇阻/遇卡情况 +新增信息 +修改信息 +查询信息 +删除信息 +采集资料质量评价 +查询信息 +新增信息 +测井处理数据 +测井处理基本信息 +查询信息 +新增信息 +处理质量评价 +查询信息 +新增信息 +测井解释数据 +测井解释基本信息 +新增信息 +修改信息 +查询信息 +删除信息 +解释质量评价 +查询信息 +新增信息 +测井解释成果表 +新增信息 +修改信息 +查询信息 +删除信息 +删除测井解释成果文件 +扩展数据 +开放测井数据服务扩展规则 +当测井数据服务交换模型扩展时，应为其补充相应的数据服务接口。 diff --git a/assets/images/dms1/zsy/总则草案 (1).png b/assets/images/dms1/zsy/总则草案 (1).png new file mode 100644 index 0000000..ef28f03 Binary files /dev/null and b/assets/images/dms1/zsy/总则草案 (1).png differ diff --git a/assets/images/dms1/zsy/总则草案 (1).txt b/assets/images/dms1/zsy/总则草案 (1).txt new file mode 100644 index 0000000..23c4284 --- /dev/null +++ b/assets/images/dms1/zsy/总则草案 (1).txt @@ -0,0 +1,477 @@ +《开放油气数据服务规范第1部分：总则》草案-0507 +ICS +中华人民共和国石油天然气行业标准SY/TXXXX-20XX +开放油气数据服务规范 +第1部分：总则 +Specificationfor open data service in petroleum exploration and development +Part 1: General principles +202X-XX-XX发布202X-XX-XX实施 +国家能源局 +目次 +前言 +1范围1 +2规范性引用文件1 +3术语和定义1 +4 缩略语3 +5 总体要求4 +5.1总体架构4 +5.2 数据服务架构设计要求5 +5.3业务域扩展要求5 +5.4 功能与扩展要求5 +6数据交换模型要求5 +6.1数据交换模型要求5 +6.2验证机制7 +6.3版本管理7 +7数据服务接口要求8 +7.1通用技术要求8 +7.2 数据服务接口分类8 +7.3数据服务接口开发设计9 +7.4 数据服务接口管理与运维要求9 +8数据服务接口安全要求10 +8.1传输安全10 +8.2访问控制10 +附录A11 +附录B18 +参考文献19 +前言 +油气行业作为稳定型的传统工业和典型的数字化深度应用行业，基于其复杂、多样的专业特质，具有不断创新与 +深厚的科学技术积淀。在业务数智化、能源低碳化发展的时代背景下，石油工业软件面临着新型工业业态、数据生 +态、技术与安全环境的全面变革。面对工业软件多样性和开发与运行环境迥异、数据孤岛、数据异构等复杂性，导致 +了数据交互难、成果共享难、业务协同难等问题，严重制约了全产业链的协同效率与智能化发展。通过规范并统一数 +据服务接口技术，实现跨学科、跨专业数据共享与系统互操作，降低软件集成难度，推动新型工业软件的转型升级， +提升油气行业数字化转型效能，编制本系列规范。首批共6个部分： +--第1部分总则：规定了开放油气数据服务的总体原则和通用技术要求-。 +-一第2部分地震：规范了地震数据服务要求； +—一第3部分测井：规范了测井数据服务要求； +-一第4部分油气藏：规范了油气藏地质建模和数值模拟数据服务要求 +-一第5部分钻井：规范了钻井工程设计和实钻数据管理数据服务要求 +-一第6部分 油气生产：规范了油气生产数据管理与动态分析数据服务要求。 +本文件是其中的第1部分，即“总则”部分。 +本文件按照GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。 +请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 +本文件由石油工业标准化技术委员会石油信息与计算机应用专业标准化委员会提出并归口。 +本文件起草单位： +本文件主要起草人 +开放油气数据服务规范第1部分：总则 +1.范围 +本文件规定了油气行业工业软件数据服务接口开发的总体框架、技术要素、设计原则及通用要求。 +本文件适用于油气行业地震、测井、油气藏、钻井、油气生产等专业数据交换的数据服务设计与开发。 +2.规范性引用文件 +下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对 +应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 +GB/T 5271.1-2000信息技术 词汇第1部分：基本术语 +GB/T18391.3-2009信息技术元数据注册系统（MDR）第3部分：注册系统元模型与基本属性 +GB/T 527117-2010信息技术词汇第17部分：数据库 +GB/T 36344-2018信息技术 数据质量 +GA/T 911-2019信息安全技术日志分析产品安全技术要求 +GB/T 32907-2016 信息安全技术 SM4分组密码算法 +3.术语和定义 +下列术语和定义适用于本文件。 +数据元（素）data element +数据元（素）是数据结构中的基本单位，也被称为数据项、元素或节点。它是描述客观事物的最小逻辑单元，可 +以包含一个或多个具体的数据项，通常作为一个整体进行存储、处理和分析。 +数据元（素）是由一组属性规定其定义、标识、表示和允许值的数据单元。数据元通常用于构建一个语义正确、 +独立且无歧义的特定概念语义的信息单元。数据元由对象类、特性和表示三部分组成。 +[来源：GB/T18391.3-2009，3.3.36，有修改] +数据结构 data structure +数据结构是计算机系统中存储、组织和管理数据的一种方式，旨在实现一组相关数据元素之间的逻辑关系，并支 +持高效的数据访问、修改和操作。 +结构化数据 structured data +数据具有固定格式和明确的关系，通常存储在二维表格中，并遵循预定义的模型（如关系型数据库）。 +非结构化数据 unstructured data +数据无固定格式，无法直接按规则解析，通常包含自然语言或二进制内容。 +半结构化数据 semi-structured data +数据部分结构化，通过标签、标记或层级关系隐含一定逻辑，但无严格模式。 +元数据metadata +元数据是描述数据的数据(或关于数据元素的数据)，用于解释数据的结构、含义、来源、规则、权属、易变性 +等属性，是理解和管理数据的基础工具。 +[来源：GB/T5271.17-2010,1706.05，有修改] +蒋亮亮 +主数据master data +主数据是对企业核心业务实体标准化的关键数据，是跨系统、跨流程共享的关键信息（如油田、工区、并/井 +筒、油藏、地层等业务类实体，客户、供应商、项目等管理类实体，以及设备、产品等资产类实体等），具有权威 +性、稳定性和一致性。 +参考数据 reference data +参考数据是指用于分类或分组其他数据的静态数据集，通常为预定义的标准化值，限定数据取值范围（如国家代 +码、订单状态)，支撑数据一致性。 +本文件中是指基于业务活动所产生的重要数据，与主数据构成“父-子”关系，并被主数据或业务数据引用。 +数据服务data service +数据服务是指提供数据采集、数据传输、数据存储、数据处理（包括计算、分析、可视化等）、数据交换、数据 +销毁等数据生存形态而演变的一种信息技术驱动的服务或例程(程序)。 +数据服务接口 data service interface +数据服务接口是指计算机系统中为开放的特定业务数据而开发并发布的可供其他系统或应用调用的访问模式。 +数据交换 data exchange +数据交换是指在应用软件与应用软件、应用软件与其他数据源之间建立数据通道，以实现数据的查询、获取与保 +存。 +数据交换模型 data exchange model +数据交换模型是指实现应用软件与应用软件之间、应用软件与其他数据源之间数据交换及其配套功能调用的通信 +协议、交互模式或范式，包含接口协议、数据格式、传输机制等技术要素。 +数据对象data object +数据对象在计算机科学和信息技术领域中是指能够被计算机程序处理的数据单元。数据对象是一个抽象的概念， +它并不直接对应于计算机内存中的具体位置，而是表示程序中可以操作的数据单元。数据对象是计算机系统中可以存 +储和处理的数据实体，该实体可以是一个单一的数据元素或一组相关的数据元素的集合。数据对象通常有相应的数据 +类型，用于定义数据对象可能包含的数值的种类，以及对这些数值进行的操作。 +数据封装 data encapsulation +数据封装是指将待交换的数据对象包装成适合网络传输和交换主体之间便于快速有效识别的格式，而对原数据对 +象添加标准化的描述性信息的过程。 +数据解封装data decapsulation +数据解封装是数据封装的反过程，是指去掉已封装的数据对象中添加的描述性信息的过程。 +领域数据管理服务 domain data management services +面向油气行业特定专业业务领域（如地震、测井等），基于领域知识体系构建的专业化数据服务，通过标准化接 +口提供领域专属的数据处理、业务逻辑执行以及专业分析能力，满足专业领域内垂直方向上业务场景中的工业软件协 +同和跨专业领域水平方向上业务场景中的数据共享与数据交换的需求。 +租户 tenant +在云计算环境中的多租户架构中独立使用系统资源的业务实体，例如：油气企业下属子公司、合作单位或独立项 +目组，其数据存储、计算资源及访问权限通过逻辑或物理隔离机制实现安全边界划分，确保不同租户间的数据与操作 +互不影响。 +数据域data domain +按油气行业业务属性或技术特征划分的数据逻辑分类单元，用于规范数据的存储策略、处理流程及服务边界，确 +保地震、测井、油气藏等专业领域数据的标准化管理与跨系统协同。 +4.缩略语 +下列缩略语适用于本文件。 +API: 应用程序编程接口 (Application ProgramminglInerface)。 +gRPC：是由谷歌（Google）开源的一1 +一个现代高性能远程过程调用(RPC)框架（Google Remote Procedure +状况检查和身份验证。 +HTTP：超文本传输协议（Hypertext rnsfer Protocl) +HTTPS：超文本传输安全协议（HypertextTrnsferProtocol ecure 。 +JSON： JavaScript对象表示法（JavaScript Object Notation)。 +OpenAPI:开放API规范（OpenAPI Specification）。 +RESTful: 表述性状态传递 (Representational State Transfer)。 +TLS：传输层安全性协议（Transport Layer Security) +URL：统一资源定位符（Uniform Resource Locator) +5.总体要求 +总体架构 +数据服务接口设计和实现的总体架构如图1所示。 +空制等代理服务 +伤领层 +集成层：效据集成与数据发布等代理服务 +图1数据服务接口总体架构 +-应用层为分布于云/非云环境中的业务管理、研究与决策场景或单个应用，例如：地震解释、钻井优化、综合 +地质研究、资源评价等。 +服务，支持业务数据的单个或组合调用及数据请求、鉴权、解封装等服务。 +--传输层为基于工业物联网或互联网络，支持数据的可靠、安全和高效传输，兼容跨系统平台 +(Windows/Liux/国产OS等）应用的数据传输需求。 +一协议层为定义数据交换模型、安全协议及服务契约，确保数据交互接口的规范性、可靠性与安全性 +一-数据接口服务为提供统一的数据存取访问、计算服务调用等核心功能。 通过服务中心的服务治理、安全控制 +等保障标准化与安全性，支持多租户隔离与弹性扩展，满足数据协同需求。 +一数据存储层集中管理油气各领域的核心业务数据资源，通过对数据的封装，为上层提供规范化的数据访问。 +数据服务架构设计要求 +数据服务架构设计应遵循以下要求： +一一模块化设计：应采用分层架构实现接口核心功能解耦，同时支持在云环境下运行； +一跨平台兼容：应支持国际以及国内常用操作系统运行环境； +－一协议中立性：应兼容HTTP及gRPC等主流协议； +一一数据标准化：应兼容行业已发布的其它数据标准。 +业务域扩展要求 +应通过模块化架构设计，支持专业业务领域（如：各种新能源业务）新增和快速接入，各领域通过插件化的数据 +连接于适配器与各层实现便捷扩展。 +功能与扩展要求 +5.1 核心功能应满足 +一一数据存取服务：应提供标准化的数据查询、读取、写入接口，服务的输出满足数据交换格式; +-一计算服务调用：应支持算法模型远程调用与计算资源调度 +一一状态监控接口：应实时反馈系统运行状态与接口健康度。 +5.2 业务领域数据服务扩展 +各专业领域数据服务接口扩展，应基于本文件中的各项要求进行 +-一专业领域数据交换模型，应按照各专业领域应用要求设置； +-一安全策略，应参考第8节安全要求设置。 +6.数据交换模型要求 +数据交换模型要求 +数据交换模型模式应满足： +一一应使用JSON Schemar作为数据封装的描述语言（见参考文献2和参考文献3）;； +-一数据对象的结构定义应符合油气行业数据结构的相关规范要求； +-一一应标明数据交换模式版本，例如：schema":"htp:/son-schema.org/drft-7/schema"。 +6.1 交换模型命名要求 +数据服务交换模型命名宜采用不定长分段层次码作为命名规则，每个段层之间用字符“”进行连接，代码总长度 +不宜超过30个字符。数据交换模型命名代码结构见图2 +xxxxxxx +第三段(实体名称码) +第二段（子关胰定词)）., +第一放（分类排） +图2 交换模型命名规则 +a.第一段(分类码),，应使用专业分类作为命名分类码。 +b．第二段（子类限定词)，用于说明交换模型分类，宜使用分类首拼字母或英文简写作为子类限定词。 +C、第三段（实体名称码），用于说明数据对象，宜使用数据对象首拼字母或关键英文单词作为实体名称码。若采 +用关键英文单词，最多不超过两个单词。 +6.2 数据交换模型设计 +数据交换主体之间进行数据交换时，应使用约定的数据交换模式对待交换的数据对象进行封装，交换后再进行解 +封装。交换过程中应基于数据交换主体之间的请求（数据使用端）和响应（数据服务端）机制进行，内容包括请求信 +息与响应信息。响应信息主要包括两种类型，一是正确地返回所请求的结果，即封装在数据交换模式中的数据对象 +(体)；二是不能正确地返回所需要的结果时，则返回错误信息。 +其中，待交换的数据对象（体）使用JSON格式报文形式（样例见附录A.1），错误返回信息采用自定义的JSON错 +误代码描述格式（定义见附录B），具体要求如下 +_一交换数据对象 (体)：应包括消息头及业务数据对象（体); +一一返回错误信息：应包括错误码、错误描述、错误原因分析及运行日志等信息。日志符合《GA/T911-2019信 +息安全技术 日志分析产品安全技术要求》。 +6.3 数据交换模型设计要求 +数据交换模型应满足： +一一类型约束：应明确定义基础数据类及数据元素类等类型，油气专业数据类还应包括数据约束及量纲，安全设 +计应符合《GB/T3634-2018信息技术数据质量》中的数据一致性要求； +一一元数据描述：每个数据模型应包含标准元数据属性； +二-组合结构：复杂数据对象应采用组合结构实现扩展。 +6.4 数据分类交换模型结构及数据封装设计与方法 +数据分类交换模型应按照以下四种数据对象大类进行设计，其中，数据交换模型根据数据结构分类对待交换的数 +据对象进行封装和传输操作，其他分类以及分级信息作为数据对象的属性或标识性信息进行描述与封装。 +一元数据类：除用于明确定义元数据所描述的数据对象外，还应包括数据结构分类类型，数据管理分级、数据 +敏感性（或安全性）分级、业务分级以及业务关联信息等，对元数据的封装方法参见附录A.2。 +(1数据对象元数据：宜包含数据对象名称、结构组成、元素及类型、元素约束条件、元素量纲等； +(2） 数据结构分类：宜包含结构化、非结构化、半结构化以及对象存储类等； +（3）数据管理分类：宜包含元数据、主数据、参考数据： +(4）数据敏感性（或安全性）分级：宜按照各企业相关的数据敏感性或安全性管理规定进行定义，例如：敏感/ +非敏感数据，或保密(国家/企业/项目/个人秘密）/非保密数据（企业外部/企业内部等公开范围)，或公开共享/私有数 +据 (企业/项目/个人) +（5）业务分级：应以油气数据业务逻辑为核心架构，主数据定义为关键业务实体（例如：油田、并筒、油藏等 +核心对象），参考数据包含业务属性（例如：物性参数、测井曲线、地震解释成果等）及数据关联关系（例如：并区- +工区空间拓扑、油藏-生产动态逻辑映射)。 +_一结构化数据类：是指按照二维表格方式存储的数据对象。对结构化数据的封装方法见附录A.3 +-非结构化数据类：是指按照“非结构化数据描述信息头+非结构化或二进制数据体”存储的数据对象。对结构 +化数据的封装方法见附录A.4。 +一一半结构化数据类：是指按照“结构化信息头+非结构化或二进制数据体”存储的数据对象。对半结构化数据的 +封装方法见附录A.5。 +验证机制 +数据交换模型应提供规范性验证机制，包括： +一一接口提供方：应公开JSON Schema定义端点，例如:：/schema/(model-type); +_一数据交换时：执行Schema验证，出错时返回标准的错误代码，见附录B。 +版本管理 +数据交换模型应支持版本管理，版本定义格式为“主版本号.次版本号.修订号”，变更要求如下： +一修订号变更仅涉及非功能性修改。 +7.数据服务接口要求 +通用技术要求 +构成数据服务接口的技术实现应遵循以下要求： +一一接口描述语言：应使用OpenAPIi语法，用于定义接口契约; +三一数据序列化：应使用JSON格式，便于校验数据。 +数据服务接口分类 +7.1数据服务接口 +数据服务接口应满足如下要求： +一-功能：应实现专业数据的可靠性存取，支持分页查询、条件过滤、版本回溯等数据操作； +实现模式：应遵循RESTful API设计原则，主要操作见表1。 +一一接口组成：应包括接口名称、接口参数、返回码以及返回数据交换模型结构。 +数据服务接口的核心组成要素、命名规则与设计要求见表1。 +表1接口组成与命名 +组成要素 +命名规则与设计要求 +示例 +接口名称 +义，例如：“GetV +'SubmitSeismic.ob. +HTTP方法 +遵循RESTful规范： +GET /wells/{well_id) +GET：数据检索 +POST：创建资源 +PUT：更新资源 +DELETE：删除资源 +路径结构 +格式： +：“专业)v版本号)资源类 +/logging/v1.2/wells +型 +-—专业：seismicprospecting, +-版本号：语义化版本，例如 v1.2 +公共 +必含字段 +请求头 +X-Tenant-ID：租户标识 +"buu-oduo.al-ueua-x. +"bubbol. .ujewoa-ejea-X. +：Bearer令牌 +路径参数 +使用全小写+下划线命名，反映资源 +/wells/{well_id) +唯一标识 +支持过滤/分页/排序 +查询参数 +min_depth=1500&max_depth=200 +一复数形式表示资源集合 +("/wells ) +一使用行业标准术语 +`trajectory"而非`path’) +错误响应 +结构化错误码（见附录B），包含 +code、message +"code": 4001, +unit" +7.2计算服务接口 +应提供计算服务接口的功能和接口协议： +一一功能：应提供专业的和高性能计算等种类的远程调用，支持异步任务管理与结果回调。 +一一协议：应兼容高性能计算应用与通用应用，定义SubmitJob、GetJobStatus等方法。 +7.3模型管理接口 +应提供元数据管理接口，设计和安全原则包括： +一一功能：应包含管理数据字典、权限策略、接口版本等元信息，支持动态配置与审计追踪。 +一一安全：应提供对敏感数据的访问限制。 +数据服务接口开发设计 +7.4 模式化设计 +数据服务接口的开发，应按照6.1、6.2、6.3等技术与非技术要求进行设计，其中数据对象（体）的封装应按照 +6.1.4中的相关要求进行。 +7.5兼容性要求 +数据服务接口设计应考虑版本和可扩展性的兼容性要求，即： +一一版本：数据服务接口调用的URL中嵌入版本号，例如：M1/datasets，且支持多版本共存与平滑升级； +-一扩展性：增加optional属性标记字段用于扩展，以提升与现有客户端的兼容性。 +7.6服务质量要求 +服务质量主要包括用户应用体验和服务性能等方面，其中服务性能主要是提高数据访问体验，可采取的技术措施 +有 +一分页：支持数据服务响应的分页控制； +-传输压缩：数据服务请求时，可根据数据体及类型选择是否压缩，以降低数据传输对网络带宽的占用; +一缓存策略：通过设置返回信息头中的数据缓存周期，定义数据在数据缓存中的存放周期，以提升数据服务效 +数据服务接口管理与运维要求 +数据所有权单位，应结合数据应用需求，在数据源端对数据服务接口设计、开发与应用等过程进行全生命周期管 +理，对数据服务接口的应用质量进行跟踪和持续改进，对数据应用安全进行审计和应急处置。 +8.数据服务接口安全要求 +传输安全 +数据服务接口应使用安全的传输协议和认证鉴权方法。 +数据服务接口应提供对敏感数据的安全防护： +—-敏感字段加密：应采用字段级加密，宜使用符合《GB/T 32907-2016 信息安全技术 SM4分组密码算法》的 +国密算法保障端到端安全。 +一传输加密：宜配合认证鉴权对传输内容强制启用加密。 +访问控制 +数据服务接口应提供安全访问控制，提供包括但不限于数据增加、删除、修改和查询等权限的 +附录A +(资料性) +数据交换JSON格式示例 +A.1 JSON格式报文模式 +JSON是一种常用的开放标准的文件格式和数据交换格式，是基于ECMAScript的一个子集设计的，它易于人阅读 +和编写，同时也易于机器解析和生成。它在电子数据交换中有多种用途，包括与服务器之间的Web应用程序的数据交 +换。其简洁和清晰的层次结构有效地提升了网络传输效率，使其成为理想的数据交换语言。 +JSON独立于编程语言设计，很多编程语言都支持JSON格式的数据交换。其文件通常使用扩展名json。通过使 +用JSON格式对待交换信息进行封装，以实现对信息的完整、快速、可靠传输，其中，对信息本体的描述采用“信息头 ++信息体”的报文形式，举例如下。 +请求报文 +请求报文： +/响应报文 +响应报文： +A.2元数据类JSON格式封装 +"$schema": "https://ison-schema.org/draft-07/schema", +"title": "SeismicMetadata", +type" "objet", +'properties": +"id": ( +'type": "string". +"format": "uid". +"description"："数据唯一标识符 +_version": +'tye". "strin" +"patern":"\llld+$" +"example": "1.2.0" +"_acl": ( +"properties": +buus madA}:swalm'Aeue mad:saumo, +'viewers": ("type": "array", "items": "type": "string"} +"required": ["owners"] +"Jlegal"r: +"type": "object" +"properties": +"clasication": "enum": [PUBLIC","CONFIDENTIAL", RESTRICTED),. +'retention_days": ("type": "integer", "minimum": 30} +"business_metadata": { +'type": "object", +"properties": +usssuouepe +(busadAweuAauns +"aep,ewoyu,us dAa aepuosnbom +"coordinate_system": ("type":"string","example": "EPSG:32650") +'required": ["survey_name"] +required":["_id","_version","business_metadata"] +元数据类JSON格式封装样例如下; +说明： +一系统元数据（前缀字段）：包含数据标识、版本控制、权限管理（ACL）及合规性标签； +一一业务元数据：定义地震工区名称、采集日期等业务属性，严格绑定seismic数据域; +-一符合核心元数据模型，支持多租户隔离（通过_acl.owners关联租户ID）。 +A.3结构化数据类JSON格式封装 +"$schma* :/schmas/wllog-data-2.0.son", +"header": +"bu!u-oqen.pueua, +'data": +"well_i" "W-2023" +'dept_unit": "m",. +'reference_point": +"": 432150.3, +"y": 356780.1, +"crs": "EPSG:32650" +"log_curves": [ +"curve_name": "GR", +"unit": "API", +values": [65.3, 671, 70.5], +"depth_index":[1500.0 1500.1,1002]. +"qultyflas": [0,1,0/0=正常，1-可疑 +).,.eiepeiaur. +"tol,type": *x"" +"Z::-p +结构化数据类JSON格式封装样例如下; +数据结构说明： +亚三wellore： 定义井筒基础信息及坐标;； +--og_curves：测井曲线数据，包含采样间隔、深度索引及质量标签。 +A.4 非结构化数据类JSON格式封装 +"file_reference": +"file_id"r"segy-8a3d" +"file_name"r"abc_3D.segy" +"file type": "SEGY", +"protocol": "s3"," +'endpoint": "https://os.example.com", +"bucket": "seismic-raw" +"key": "2023/SS-2023-PB01.sgy" +"technical_metadata": ( +fl_size_GB": 245.7, +'md5_hash": "a3d5e8f102.". +'trace_count":100000, +'sample_interval_ms": 4 +'_security": +'encryption": +'algorithm": "SM4-CTR", +"key_id": "Kkms-001" +非结构化数据类JSON格式封装样例如下; +说明： +一一—采用引用式存储（非结构化数据本体存于对象存储，JSON仅封装元数据）; +一包含文件校验信息（MD5哈希）及加密状态声明。 +A.5 半结构化数据类JSON格式封装 +interpretation_report": { +"report_id":"IR-2023-001", +"bueuzsibojoa.".Joune, +"z00:0:801--opuoeo +"sections" +'ssieue anej. .aduooas, +'content": ( +"fault id": "F-102" +'confidence": 0.85, +"annotations": +"text":"逆断层，断距约200m", +'position": ("rinline": 150, "xline": 320) +"attachments": [ +半结构化数据类JSON格式封装样例如下； +兑明 +一一自由格式内容与结构化字段混合存储； +一支持动态扩展字段，兼容未来新增业务属性 +附录B +(资料性) +JSON关键字与错误代码描述 +JSON关键字与错误代码描述见表B-1 +表B-1JSON关键字与错误代码描述 +JSON关键字 +错误码 +描述 +type +4001 +类型校验失败 +required +4003 +必填字段缺失 +minimum/maximum +4002 +数值越界 +format +4004 +自定义格式校验失败 +uniqueltems +4005 +数组元素重复 +enum +4006 +非法枚举值 +参考文献 +[1]国家发展改革委，中央网信办.关于推进“上云用数赋智”行动培育新经济发展实施方案》的通知（发改高技 +（2020]552号） +https://www.ndrc.gov.cn/xwdt/ztzl/fkyqfgwzxdzt/fkgjdt/fgfc/202004/t20200410_1225542.html? +code=&state=123,(2020-04-07) +[2]JSON组织.JSON核心元模式定义Draft-O7（JSONSchemaDraft-O7）.https://jison-schema.org/draft- +07/schema. +[3]OSDU组织.OSDU数据定义（OSDUDATADEFINITIONS）.https://osduforum.org/osdu-data-definition- +documentation/. +[4]中华人民共和国数据安全法，2021. diff --git a/assets/images/dms1/zsy/梦想云地震中心统一共享服务接口文档@2024722.pdf b/assets/images/dms1/zsy/梦想云地震中心统一共享服务接口文档@2024722.pdf new file mode 100644 index 0000000..6209abb Binary files /dev/null and b/assets/images/dms1/zsy/梦想云地震中心统一共享服务接口文档@2024722.pdf differ diff --git a/assets/images/image2doc.py b/assets/images/image2doc.py new file mode 100644 index 0000000..6be84bb --- /dev/null +++ b/assets/images/image2doc.py @@ -0,0 +1,113 @@ +import easyocr +import os +import time + +# --- 配置项 --- +BASE_IMAGE_DIR = '/Users/zpc01/workspace/zzlh/compliance/assets/images/' +LANGUAGES = ['ch_sim', 'en'] # 需要识别的语言 +USE_GPU = True # 是否尝试使用 GPU (如果可用) +OUTPUT_DETAIL = 0 # 0: 只输出文本列表, 1: 输出详细信息 (坐标, 文本, 置信度) + +# --- 初始化 EasyOCR Reader --- +print("正在加载 EasyOCR 模型... 这可能需要一些时间。") +try: + reader = easyocr.Reader(LANGUAGES, gpu=USE_GPU) + print("EasyOCR 模型加载成功。") +except Exception as e: + print(f"加载 EasyOCR 模型时出错: {e}") + print("请确保已正确安装 EasyOCR 及其依赖项，并且模型文件可下载或已存在于 ~/.EasyOCR/model 目录下。") + exit() + +# --- 遍历基础目录下的所有子文件夹 --- +print(f"开始处理目录: {BASE_IMAGE_DIR}") + +if not os.path.isdir(BASE_IMAGE_DIR): + print(f"错误：基础目录 '{BASE_IMAGE_DIR}' 不存在或不是一个有效的目录。") + exit() + +try: + subfolders = [f for f in os.listdir(BASE_IMAGE_DIR) if os.path.isdir(os.path.join(BASE_IMAGE_DIR, f))] +except OSError as e: + print(f"错误：无法访问目录 '{BASE_IMAGE_DIR}'。请检查权限。 {e}") + exit() + +if not subfolders: + print(f"在 '{BASE_IMAGE_DIR}' 下没有找到任何子文件夹。") + exit() + +print(f"找到 {len(subfolders)} 个子文件夹，将逐一处理...") + +# --- 逐个处理子文件夹 --- +for folder_name in subfolders: + subdir_path = os.path.join(BASE_IMAGE_DIR, folder_name) + print(f"\n--- 正在处理文件夹: {folder_name} ---") + + all_texts_in_folder = [] # 用于存储当前文件夹所有图片的识别结果 + png_filenames_sorted = [] # 用于存储排序后的 PNG 文件名 + + # --- 获取并排序当前子文件夹下的所有 png 文件 --- + try: + all_items_in_subdir = os.listdir(subdir_path) + # 筛选出所有 png 文件名 + png_filenames = [ + f for f in all_items_in_subdir + if f.lower().endswith('.png') and os.path.isfile(os.path.join(subdir_path, f)) + ] + # 按字典序（字母顺序）排序 + png_filenames.sort() # sort() 方法直接在原列表上排序 + png_filenames_sorted = png_filenames # 赋值给新变量（或者直接使用 png_filenames） + + if not png_filenames_sorted: + print(f" 在文件夹 '{folder_name}' 中未找到 PNG 图片。") + continue # 跳到下一个文件夹 + + except OSError as e: + print(f" 错误：无法访问子文件夹 '{subdir_path}' 或读取其内容。跳过此文件夹。 {e}") + continue # 跳到下一个文件夹 + + print(f" 找到 {len(png_filenames_sorted)} 个 PNG 文件，将按字典序处理...") + + # --- 按排序后的顺序处理 PNG 文件 --- + for filename in png_filenames_sorted: + image_path = os.path.join(subdir_path, filename) + # 在打印信息中可以体现出是按顺序处理的 + print(f" 正在识别图片 (顺序: {png_filenames_sorted.index(filename) + 1}/{len(png_filenames_sorted)}): {filename} ...") + + try: + start_time = time.time() + result = reader.readtext(image_path, detail=OUTPUT_DETAIL) + end_time = time.time() + + if result: + if OUTPUT_DETAIL == 0: + all_texts_in_folder.extend(result) + print(f" 识别到 {len(result)} 段文本，耗时: {end_time - start_time:.2f} 秒") + else: + texts_only = [text for _, text, _ in result] + all_texts_in_folder.extend(texts_only) + print(f" 识别到 {len(texts_only)} 段文本 (详细模式)，耗时: {end_time - start_time:.2f} 秒") + else: + print(" 未识别到文本。") + + except Exception as e: + print(f" 处理图片 '{filename}' 时发生错误: {e}") + continue # 继续处理下一个文件 + + # --- 将当前文件夹所有识别结果写入文本文件 --- + if all_texts_in_folder: # 只有在确实识别到了文本时才写入 + output_txt_filename = f"{folder_name}_easy.txt" + output_txt_path = os.path.join(subdir_path, output_txt_filename) + + try: + with open(output_txt_path, 'w', encoding='utf-8') as f: + for text in all_texts_in_folder: + f.write(text + '\n') + print(f" 已将所有识别结果写入文件: {output_txt_path}") + except IOError as e: + print(f" 错误：无法写入输出文件 '{output_txt_path}'. {e}") + # 如果 png_filenames_sorted 不为空，但 all_texts_in_folder 为空，说明找到了图片但没识别出内容 + elif png_filenames_sorted: + print(f" 文件夹 '{folder_name}' 中的 PNG 图片均未识别到文本，不创建 .txt 文件。") + # (如果 png_filenames_sorted 为空，前面已经打印过 "未找到 PNG 图片" 的信息) + +print("\n--- 所有文件夹处理完毕 ---") \ No newline at end of file diff --git a/assets/images/image2doc_paddle.py b/assets/images/image2doc_paddle.py new file mode 100644 index 0000000..6b1763e --- /dev/null +++ b/assets/images/image2doc_paddle.py @@ -0,0 +1,137 @@ +# -*- coding: utf-8 -*- +# Required libraries: paddleocr, paddlepaddle (or paddlepaddle-gpu) +# Install using: pip install paddlepaddle paddleocr +import os +import time +from paddleocr import PaddleOCR # Import PaddleOCR class +import logging + +# Suppress excessive PaddleOCR logging if desired +logging.disable(logging.INFO) # Disables INFO level logs, keeps WARNING and ERROR +# logging.disable(logging.WARNING) # To disable WARNING level logs as well + +# --- Configuration --- +BASE_IMAGE_DIR = '/Users/zpc01/workspace/zzlh/compliance/assets/images/dms1' +# Language configuration: 'ch' supports Chinese and English by default. +# Other options include 'en', 'korean', 'japan', 'french', 'german', etc. +LANG = 'ch' +USE_ANGLE_CLS = True # Use angle classification to help with rotated text +# PaddleOCR attempts to use GPU automatically if paddlepaddle-gpu is installed +# and CUDA is available. You can force CPU with use_gpu=False. +# USE_GPU = False # Uncomment to force CPU usage + +# --- Initialize PaddleOCR Engine --- +# This needs to run only once to download and load models into memory. +print(f"正在初始化 PaddleOCR (语言: {LANG})... 这可能需要一些时间，特别是首次运行时。") +try: + # Initialize PaddleOCR + # If you want to explicitly control GPU usage, add use_gpu=USE_GPU parameter + ocr_engine = PaddleOCR(use_angle_cls=USE_ANGLE_CLS, lang=LANG) # Default: use_gpu=True (auto-detect) + print("PaddleOCR 初始化成功。") +except Exception as e: + print(f"初始化 PaddleOCR 时出错: {e}") + print("请确保已正确安装 paddleocr 和 paddlepaddle (或 paddlepaddle-gpu)。") + print("GPU 用户请确保 CUDA/cuDNN 环境配置正确。") + exit() # Exit if initialization fails + +# --- Iterate through base directory's subfolders --- +print(f"开始处理目录: {BASE_IMAGE_DIR}") + +if not os.path.isdir(BASE_IMAGE_DIR): + print(f"错误：基础目录 '{BASE_IMAGE_DIR}' 不存在或不是一个有效的目录。") + exit() + +try: + subfolders = [f for f in os.listdir(BASE_IMAGE_DIR) if os.path.isdir(os.path.join(BASE_IMAGE_DIR, f))] +except OSError as e: + print(f"错误：无法访问目录 '{BASE_IMAGE_DIR}'。请检查权限。 {e}") + exit() + +if not subfolders: + print(f"在 '{BASE_IMAGE_DIR}' 下没有找到任何子文件夹。") + exit() + +print(f"找到 {len(subfolders)} 个子文件夹，将逐一处理...") + +# --- Process each subfolder --- +for folder_name in subfolders: + subdir_path = os.path.join(BASE_IMAGE_DIR, folder_name) + print(f"\n--- 正在处理文件夹: {folder_name} ---") + + all_texts_in_folder = [] # Store all recognized text from this folder + png_filenames_sorted = [] # Store sorted PNG filenames + + # --- Find and sort PNG files in the current subdirectory --- + try: + all_items_in_subdir = os.listdir(subdir_path) + # Filter for PNG files only and sort them + png_filenames = [ + f for f in all_items_in_subdir + if f.lower().endswith('.png') and os.path.isfile(os.path.join(subdir_path, f)) + ] + png_filenames.sort() # Sort alphabetically (dictionary order) + png_filenames_sorted = png_filenames + + if not png_filenames_sorted: + print(f" 在文件夹 '{folder_name}' 中未找到 PNG 图片。") + continue # Skip to the next folder + + except OSError as e: + print(f" 错误：无法访问子文件夹 '{subdir_path}' 或读取其内容。跳过此文件夹。 {e}") + continue # Skip to the next folder + + print(f" 找到 {len(png_filenames_sorted)} 个 PNG 文件，将按字典序处理...") + + # --- Process PNG files in sorted order --- + for filename in png_filenames_sorted: + image_path = os.path.join(subdir_path, filename) + print(f" 正在识别图片 (顺序: {png_filenames_sorted.index(filename) + 1}/{len(png_filenames_sorted)}): {filename} ...") + + try: + start_time = time.time() + # Perform OCR using PaddleOCR + # The result is typically a list where each item corresponds to a detected text line. + # Format: [[[box], (text, confidence)], [[box], (text, confidence)], ...] + # Sometimes it might be nested further, e.g., [page_result] + # We usually need result[0] for a single image. + result = ocr_engine.ocr(image_path, cls=USE_ANGLE_CLS) + end_time = time.time() + + # Extract text from the result structure + extracted_texts = [] + if result and result[0]: # Check if result is not None and the first element (page/image result) exists + for line in result[0]: # Iterate through detected lines in the first (and likely only) page/image + # line format is usually [[box_coords], (text, confidence)] + if line and len(line) == 2 and isinstance(line[1], tuple) and len(line[1]) >= 1: + extracted_texts.append(line[1][0]) # Get the text part + + if extracted_texts: + all_texts_in_folder.extend(extracted_texts) + print(f" 识别到 {len(extracted_texts)} 段文本，耗时: {end_time - start_time:.2f} 秒") + else: + print(" 未识别到文本。") + + except Exception as e: + # Catch potential errors during OCR processing for a single file + print(f" 处理图片 '{filename}' 时发生错误: {e}") + # Decide whether to stop or continue; here we continue + continue + + # --- Write aggregated text to a file --- + if all_texts_in_folder: + output_txt_filename = f"{folder_name}.txt" + output_txt_path = os.path.join(subdir_path, output_txt_filename) + + try: + with open(output_txt_path, 'w', encoding='utf-8') as f: + for text in all_texts_in_folder: + f.write(text + '\n') # Write each text segment on a new line + print(f" 已将所有识别结果写入文件: {output_txt_path}") + except IOError as e: + print(f" 错误：无法写入输出文件 '{output_txt_path}'. {e}") + elif png_filenames_sorted: # Found PNGs but extracted no text + print(f" 文件夹 '{folder_name}' 中的 PNG 图片均未识别到文本，不创建 .txt 文件。") + # If png_filenames_sorted is empty, the message was printed earlier. + +print("\n--- 所有文件夹处理完毕 ---") + diff --git a/assets/images/image2doc_paddle_single.py b/assets/images/image2doc_paddle_single.py new file mode 100644 index 0000000..e89384e --- /dev/null +++ b/assets/images/image2doc_paddle_single.py @@ -0,0 +1,205 @@ +# -*- coding: utf-8 -*- +# Required libraries: paddleocr, paddlepaddle (or paddlepaddle-gpu), Pillow, opencv-python +# Install using: pip install paddlepaddle paddleocr Pillow opencv-python numpy +import os +import time +from paddleocr import PaddleOCR # Import PaddleOCR class +import logging +from PIL import Image # Added +import numpy as np # Added +import cv2 # Added + +# Suppress excessive PaddleOCR logging if desired +logging.disable(logging.INFO) # Disables INFO level logs, keeps WARNING and ERROR +# logging.disable(logging.WARNING) # To disable WARNING level logs as well + +# --- Configuration --- +BASE_IMAGE_DIR = '/Users/zpc01/workspace/zzlh/compliance/assets/images/dms1/zsy' +# Language configuration: 'ch' supports Chinese and English by default. +# Other options include 'en', 'korean', 'japan', 'french', 'german', etc. +LANG = 'ch' +USE_ANGLE_CLS = True # Use angle classification to help with rotated text +MAX_CHUNK_HEIGHT = 3000 # Added: Maximum height for each image chunk in pixels. Adjust if needed. +# PaddleOCR attempts to use GPU automatically if paddlepaddle-gpu is installed +# and CUDA is available. You can force CPU with use_gpu=False. +# USE_GPU = False # Uncomment to force CPU usage + +# --- Initialize PaddleOCR Engine --- +# This needs to run only once to download and load models into memory. +print(f"正在初始化 PaddleOCR (语言: {LANG})... 这可能需要一些时间，特别是首次运行时。") +try: + # Initialize PaddleOCR + # If you want to explicitly control GPU usage, add use_gpu=USE_GPU parameter + ocr_engine = PaddleOCR(use_angle_cls=USE_ANGLE_CLS, lang=LANG) # Default: use_gpu=True (auto-detect) + print("PaddleOCR 初始化成功。") +except Exception as e: + print(f"初始化 PaddleOCR 时出错: {e}") + print("请确保已正确安装 paddleocr 和 paddlepaddle (或 paddlepaddle-gpu)。") + print("GPU 用户请确保 CUDA/cuDNN 环境配置正确。") + exit() # Exit if initialization fails + +# --- Iterate through base directory's subfolders --- +print(f"开始处理目录: {BASE_IMAGE_DIR}") + +if not os.path.isdir(BASE_IMAGE_DIR): + print(f"错误：基础目录 '{BASE_IMAGE_DIR}' 不存在或不是一个有效的目录。") + exit() + +# --- Determine processing targets --- +paths_to_process_with_display_names = [] +subfolders = [] +try: + # Attempt to find subfolders + subfolders = [f for f in os.listdir(BASE_IMAGE_DIR) if os.path.isdir(os.path.join(BASE_IMAGE_DIR, f))] +except OSError as e: + print(f"错误：无法访问目录 '{BASE_IMAGE_DIR}' 来查找子文件夹。请检查权限。 {e}") + exit() + +if subfolders: + print(f"找到 {len(subfolders)} 个子文件夹，将逐一处理...") + for sf_name in subfolders: + paths_to_process_with_display_names.append( + (os.path.join(BASE_IMAGE_DIR, sf_name), sf_name) + ) +else: + # No subfolders, check BASE_IMAGE_DIR itself for PNGs + print(f"在 '{BASE_IMAGE_DIR}' 下没有找到任何子文件夹。正在检查该目录下是否直接包含 PNG 文件...") + try: + items_in_base_dir = os.listdir(BASE_IMAGE_DIR) + png_files_in_base_dir = [ + f for f in items_in_base_dir + if f.lower().endswith('.png') and os.path.isfile(os.path.join(BASE_IMAGE_DIR, f)) + ] + if png_files_in_base_dir: + print(f"在 '{BASE_IMAGE_DIR}' 目录下直接找到 {len(png_files_in_base_dir)} 个 PNG 文件。将进行处理。") + display_name = os.path.basename(BASE_IMAGE_DIR.rstrip(os.sep)) + if not display_name: # Handle case where BASE_IMAGE_DIR might be root "/" + display_name = "根目录中的图片" + paths_to_process_with_display_names.append((BASE_IMAGE_DIR, display_name)) + else: + print(f"在 '{BASE_IMAGE_DIR}' 下既没有找到子文件夹，也没有直接找到 PNG 文件。脚本将退出。") + exit() + except OSError as e: + print(f"错误：无法访问或读取 '{BASE_IMAGE_DIR}' 的内容以查找PNG文件。 {e}") + exit() + +if not paths_to_process_with_display_names: + print("没有找到可处理的目录或PNG文件。脚本将退出。") + exit() + +# --- Process each identified path --- +for current_scan_path, name_for_display in paths_to_process_with_display_names: + print(f"\n--- 正在处理目标: {name_for_display} (路径: {current_scan_path}) ---") + + png_filenames_sorted = [] # Store sorted PNG filenames + + # --- Find and sort PNG files in the current path --- + try: + all_items_in_path = os.listdir(current_scan_path) + # Filter for PNG files only and sort them + png_filenames = [ + f for f in all_items_in_path + if f.lower().endswith('.png') and os.path.isfile(os.path.join(current_scan_path, f)) + ] + png_filenames.sort() # Sort alphabetically (dictionary order) + png_filenames_sorted = png_filenames + + if not png_filenames_sorted: + print(f" 在 '{name_for_display}' (路径: {current_scan_path}) 中未找到 PNG 图片。") + continue # Skip to the next target + + except OSError as e: + print(f" 错误：无法访问 '{name_for_display}' (路径: {current_scan_path}) 或读取其内容。跳过此目标。 {e}") + continue # Skip to the next target + + print(f" 找到 {len(png_filenames_sorted)} 个 PNG 文件，将按字典序处理...") + + # --- Process PNG files in sorted order --- + for filename in png_filenames_sorted: + image_path = os.path.join(current_scan_path, filename) + print(f" 正在识别图片 (顺序: {png_filenames_sorted.index(filename) + 1}/{len(png_filenames_sorted)}): {filename} ...") + + try: + start_time = time.time() + current_image_texts = [] # To store all texts from this image (chunks or whole) + + # Load image with Pillow + pil_image = Image.open(image_path) + img_width, img_height = pil_image.size + + if img_height > MAX_CHUNK_HEIGHT: + print(f" 图片高度 {img_height}px 超过限制 {MAX_CHUNK_HEIGHT}px，将进行分块处理...") + num_chunks = (img_height + MAX_CHUNK_HEIGHT - 1) // MAX_CHUNK_HEIGHT # Ceiling division + + for i in range(num_chunks): + top = i * MAX_CHUNK_HEIGHT + bottom = min((i + 1) * MAX_CHUNK_HEIGHT, img_height) + chunk_box = (0, top, img_width, bottom) + + pil_chunk = pil_image.crop(chunk_box) + + # Convert PIL chunk to BGR NumPy array for PaddleOCR + # PaddleOCR expects BGR format if a numpy array is provided. + if pil_chunk.mode != 'RGB': + pil_chunk = pil_chunk.convert('RGB') + img_rgb_np = np.array(pil_chunk) + img_bgr_np = cv2.cvtColor(img_rgb_np, cv2.COLOR_RGB2BGR) + + print(f" 正在识别分块 {i+1}/{num_chunks} (像素 {top}-{bottom})...") + # Result structure: [[line_info_1], [line_info_2], ...] + # line_info: [[[box_coords], (text, confidence)]] + # We need the first element of the result for a single image/chunk. + ocr_output_for_chunk_list = ocr_engine.ocr(img_bgr_np, cls=USE_ANGLE_CLS) + + if ocr_output_for_chunk_list and ocr_output_for_chunk_list[0]: # Check if list is not empty and first element (page result) exists + ocr_output_for_chunk = ocr_output_for_chunk_list[0] + for line_info in ocr_output_for_chunk: # Iterate through detected lines in the chunk + # line_info format is [[box_coords], (text, confidence)] + if line_info and len(line_info) == 2 and isinstance(line_info[1], tuple) and len(line_info[1]) >= 1: + current_image_texts.append(line_info[1][0]) # Append text + if num_chunks > 0: # only print if chunking actually happened + print(f" 所有分块识别完毕。") + else: # Process the image as a whole (height <= MAX_CHUNK_HEIGHT) + # Convert PIL image to BGR NumPy array for PaddleOCR + pil_to_ocr = pil_image + if pil_to_ocr.mode != 'RGB': + pil_to_ocr = pil_to_ocr.convert('RGB') + img_rgb_np = np.array(pil_to_ocr) + img_bgr_np = cv2.cvtColor(img_rgb_np, cv2.COLOR_RGB2BGR) + + # Result structure: [[line_info_1], [line_info_2], ...] + ocr_output_whole_image_list = ocr_engine.ocr(img_bgr_np, cls=USE_ANGLE_CLS) + + if ocr_output_whole_image_list and ocr_output_whole_image_list[0]: # Check if list is not empty and first element (page result) exists + ocr_output_whole_image = ocr_output_whole_image_list[0] + for line_info in ocr_output_whole_image: # Iterate through detected lines + if line_info and len(line_info) == 2 and isinstance(line_info[1], tuple) and len(line_info[1]) >= 1: + current_image_texts.append(line_info[1][0]) + + end_time = time.time() + + # Extracted text from all chunks (or whole image) is in current_image_texts + if current_image_texts: + print(f" 识别到 {len(current_image_texts)} 段文本，总耗时: {end_time - start_time:.2f} 秒") + + # --- 为当前图片写入 .txt 文件 --- + base_img_filename, _ = os.path.splitext(filename) + output_txt_filename_for_image = f"{base_img_filename}.txt" + output_txt_path_for_image = os.path.join(current_scan_path, output_txt_filename_for_image) + + try: + with open(output_txt_path_for_image, 'w', encoding='utf-8') as f_img: + for text_segment in current_image_texts: + f_img.write(text_segment + '\n') + print(f" 已将识别结果写入文件: {output_txt_path_for_image}") + except IOError as e: + print(f" 错误：无法写入输出文件 '{output_txt_path_for_image}'. {e}") + else: + print(" 未识别到文本。") + + except Exception as e: + print(f" 处理图片 '{filename}' 时发生错误: {e}") + continue + +print("\n--- 所有目标处理完毕 ---") + diff --git a/assets/images/log/log.txt b/assets/images/log/log.txt new file mode 100644 index 0000000..68dd7df --- /dev/null +++ b/assets/images/log/log.txt @@ -0,0 +1,391 @@ +应用日志规范（Java) +1.技术要求 +1.1记录原则 +1.【强制】隔离性：日志输出不应影响系统正常运行； +2.【强制】安全性：日志打印本身不应存在逻辑异常或漏洞，导致产生安全问题； +3.【强制】数据安全：不应输出机密、敏感信息，如用户联系方式、身份证号码、token等，应保证日志的完整性、 +可审计性； +4.【强制】可监控分析：日志应提供给监控进行监控，分析系统进行分析； +5．【强制】可定位排查：日志信息输出应有意义，应具有可读性，可供开发人员排查线上问题。 +1.2日志级别 +在我们日常开发中有四种比较常见的日志打印等级，不同的等级适合在不同的时机下打印日志。 +主要使用的有以下四个等级： +1.DEBUG +DEUBG级别应主要输出调试性质的内容，该级别日志应用于并发、测试阶段输出。该级别的日志应尽可能地详尽 +开发人员可以将各类详细信息记录到DEBUG里，起到调试的作用，包括参数信息，调试细节信息，返回值信息等 +等，便于在开发、测试阶段出现问题或者异常时，对其进行分析。 +2. INFO +INFO级别的主要记录系统关键信息，旨在保留系统正常工作期间关键运行指标，开发人员可以将初始化系统配置， +业务状态变化信息，或者用户业务流程中的核心处理记录到INFO日志中，方便日常运维工作以及错误回溯时上下文 +场景复现。应在项目完成后，在测试环境将日志级别调成INFO，然后通过INFO级别的信息看看是否能了解这个应用 +的运用情况，如果出现问题后是否这些日志能否提供有用的排查问题的信息。 +3.WARN +WARN级别的主要输出警告性质的内容，这些内容是可预知且是有规划的，比如，某个方法入参为空或者该参数的值 +不满足运行该方法的条件时。在WARN级别的时应输出较为详尽的信息，以便于事后对日志进行分析。 +注：常见的WARN级别异常 +·用户输入参数错误 +·非核心组件初始化失败 +·后端任务处理最终失败（如果有重试且重试成功，就不需要WARN） +·数据插入幂等 +4.ERROR +ERROR级别主要针对于一些不可预知的信息，诸如：错误、异常等，比如，在catch块中抓获的网络通信、数据库连 +接等异常，若异常对系统的整个流程影响不大，可使用WARN级别日志输出。在输出ERROR级别的日志时，应尽量多 +地输出方法入参数、方法执行过程中产生的对象等数据，在带有错误、异常对象的数据时，应将该对象一并输出。 +注：常见的ERROR级别异常 +·程序启动失败 +·核心组件初始化失败 +·连不上数据库 +·核心业务访问依赖的外部系统持续失败 +Woo· +不应滥用ERROR级别日志。一般来说在配置了告警的系统中，WARN级别一般不会告警，ERROR级别则会设置监控 +告警甚至电话报警，ERROR级别日志的出现意味着系统中发生了非常严重的问题，应有人立即处理。 +错误的使用ERROR级别日志，不区分问题的重要程度，只要是问题就采用ERROR级别日志，这是极其不负责任的表 +现，因为大部分系统中的告警配置都是根据单位时间内ERROR级别日志出现的数量来定的，随意打ERROR日志会造 +成极大的告警噪音，造成重要问题遗漏。 +1.3日志格式 +1.3.1后端日志格式 +后端日志可以保存或输出到文件，远程服务器，控制台及数据库等，日志输出包含以下要素： +·时间戳：2024-01-29T15：30：45，789 +·日志链路id(traceld、rpcld）（可选）0b26053315407142451016402xxxxx0.3－///- +·日志级别：DEBUG，INFO，WARN，ERROR，FATAL +·线程名：SofaBizProcessor-4-thread-333，main +·类名或Logger名称：com.example.MyClass +·方法名与行号（可选）：·myMethod（L45） +·调用耗时（可选）1ms +·调用是否成功(Y/N）(可选) +·状态码（可选）SUCCESS +·系统上下文信息（调用系统名、调用系统ip、调用时间戳、是否压测（Y/N)）（可选）appName，ip地址，时间戳，Y +·请求入参（可选）参数1 +·请求出参（可选）参数1 +·日志消息内容："Thisis alog message"，"No URLs will be polled as dynamic +configurationsources" +日志自定义输出格式如下： +[SofaBizProcessor-4-thread-333] {com.example.MyClass}-L22-[(1ms,Y,SUCCESS)(appName,ip +地址，时间戳，Y)（参数1,参数2)]-NoURLswillbe polled asdynamicconfiguration sources +[ob26053315407142451016402xXXxx0.3-///-]是traceld；[INF0]是日志级别； +[SofaBizProcessor-4-thread-333]是线程名；{com.example.MyClass}是类名；L22是行号；No +URLswillbepolledasdynamicconfigurationsources是实际的日志消息，具体的业务相关日志打 +印形式可以根据业务实际情况自定义。 +日志标准输出格式如下： +1 2024-01-29 15:30:45,789 [INF0] [main]{com.example.MyClass} ]-No URLs will be polled +as dynamicconfigurationsources +注：移动端日志遵循后端日志格式。 +1.3.2前端日志格式 +因素： +1.时间戳：在日志条目的开头添加一个时间戳，以便跟踪事件发生的时间。 +2.日志级别：指定日志条目的级别（例如，错误、警告、信息、调试等），以便根据需要进行筛选和过滤。 +3.源代码位置：在日志条目中包含源代码的位置信息（例如，文件名、行号等），以便快速定位问题。 +4.消息内容：提供有关事件或错误的详细信息，包括任何相关的上下文或错误消息。 +5.自定义字段：根据需要添加具他自定义字段，例如用户ID、会话ID、浏览器信息等。 +以下是一个简单的前端日志格式示例： +1[2023-03-15 14:32:01] INF0: main.js:123 -User logged in successfully. +[2023-03-15 14:32:15] ERR0R: user.js:45-Failed to fetch user data. Error: Network +Error.码 +在这个示例中，每条日志条目都包含时间戳、日志级别、源代码位置以及消息内容。此外，还可以根据需要添加其他 +自定义字段，例如用户ID、会话ID等。 +需要注意的是，前端日志格式应该根据项目的具体需求和规范进行定制，以便更好地满足项目的需求。同时，还需要 +考虑日志的存储、传输和展示等方面的问题，以确保日志的可用性和可维护性。 +1.4日志存储 +应及时清理和管理日志，以避免过大的日志文件或存储空间的浪费。及时地分析日志，以便发现潜在的问题或改进系 +统性能。 +志文件的重要程度、文件大小以及磁盘空间自行调整，6个月内至少清理一次过期的或无用的日志数据，此外，还可 +以对日志进行监控，收到磁盘报警时，对1个月之前的数据可以进行删除或者转储。 +1.5日志安全 +1.5.1保护范围 +日志记录中包含的某些内容出于隐私保护、数据安全和法规遵从的要求，不应直接以原始形式显示。以下是一些需要 +进行处理的内容类型： +1.法律法规不充许的信息 +·《个人信息保护法》涉及的敏感信息：《个保法》第二十八条敏感个人信息是一旦泄露或者非法使用，容易导致 +自然人的人格尊严受到侵害或者人身、财产安全受到危害的个人信息，包括生物识别、宗教信仰、特定身份、医 +疗健康、金融账户、行踪轨迹等信息，以及不满十四周岁未成年人的个人信息。根据法规，个人可识别信息如身 +份证号码、电话号码、住址、电子邮件地址等必须严格保护，未经同意不得非法收集、使用或披露。同时，个人 +敏感数据如健康状况、医疗记录、生物识别信息等高度私密，处理时需特别谨慎，确保合法合规。 +2.石油集团保密要求 +·包括但不限于涉密技术资料、勘探数据、生产数据、商业合作细节等信息，信息系统日志中应避免直接记录这些 +内容，并对所有操作进行严格的审计和安全控制，确保日志的安全存储、访问权限控制以及必要时的数据脱敏。 +3.涉及的商业秘密信息 +·在日志中，商业秘密信息可能以各种形式体现，例如研发数据、客户名单、内部策略、未公开的产品设计和技术 +方案等。 +4.业务定义敏感信息 +·金融交易信息：银行卡号、支付卡数据（CVV码、有效期等）是金融行业严控的信息，必须采取加密或具他安全 +措施妥善处理和存储。 +致企业竞争优势受损或违反合同约定的信息。 +5.可能有助于攻击者利用的敏感数据 +·用户的会话lD（如果需要跟踪会话相关的事件，可以考虑用Hash值代替） +·会话ID与Hash值：为了防止会话劫持，原始会话ID不应在日志中明文记录，可以考虑采用哈希值代替，但要确保 +该哈希不能被反向解析为原始会话标识。 +此建议不在日志中详细记录或仅记录到主版本级别。 +·散列值：如果散列为敏感数据的散列，例如密码散列，在记录日志时应当谨慎，避免将过于详细的散列值存入日 +志，特别是对于易破解的弱散列算法。 +式去标识化。 +·数据库连接字符串与密钥：包含数据库凭据的连接字符串、加密密钥和其他主密钥绝对不能出现在日志中，这些 +信息一旦泄露可能导致数据大规模泄露或系统完全失控。 +1.5.2脱敏方法 +不应在日志中明文记录敏感信息数据，必要时对这些数据进行脱敏处理。对敏感的日志信息进行加密，以保护数据安 +全。确保在存储和传输过程中对敏感信息进行加密，以防止未授权的访问和泄露。 +需要脱敏的信息见”保护范围“部分。 +注：在进行日志脱敏时，会根据不同的敏感级别采用不同的脱敏策略，包括替换、遮盖、截断、哈希加密等方法，以 +保护这些信息不被泄露，同时确保日志能够满足必要的业务分析和故障排查要求 +具体方式包括但不限于： +·移除（Remove）：直接从日志条目中删除敏感字段。 +·分类与分级处理：根据数据的敏感程度进行分类，并针对不同类别实施不同的脱敏策略，例如部分脱敏或完全替 +换。 +·脱敏（Masking)：替换敏感字段为星号、占位符或其他非敏感字符，如将电话号部分数字脱敏为“****** +1234”。 +·净化（Sanitizing)：对敏感数据进行格式化或规范化，确保不泄露实际意义，例如使用哈希函数处理用户身份信 +息。 +·Hash化：对于需要保持唯一性的数据，比如用户名或电子邮件地址，可以采用不可逆的哈希算法进行处理，用于 +审计目的但不能反向还原出原始数据。 +实施上述措施有助于企业在满足日志分析和故障排查需求的同时，最大限度地降低数据泄露风险，并符合《网络安全 +注：在使用日志框架如logback、Log4j等时，可以配置相应的插件或者自定义拦截器来实现自动化脱敏功能。 +1.5.3安全措施 +日志数据安全是确保系统在生成、传输、存储日志时，保护敏感信息不被未经授权的访问、泄露、篡改或丢失的重要 +环节。以下是维护日志数据安全的一些关键措施： +1.日志数据传输加密： +·在传输过程中，可使用SSL/TLS等安全协议加密SYSLOG或具他形式的日志数据流。 +2.访问控制： +·实施严格的访问控制策略，只有授权人员才能查看和操作日志数据， +3.敏感信息处理： +·对于包含敏感信息的日志条目，执行脱敏处理，如替换或模糊化密码、个人识别信息（PII)、信用卡号等敏感内 +容。 +4.标准化与合规： +·确保日志格式和实践符合行业标准和法规要求，比如《网络安全法》和《网络安全等级保护基本要求》对于数据 +处理的规定。 +5.备份与恢复： +·定期备份日志，并保证备份数据的安全性，同时设计有效的灾难恢复方案。 +通过上述措施，可从多个维度保障日志数据的安全性，同时也为数据分析、故障排查、安全审计及合规性检查提供了 +有力支持。 +1.6Java最佳实践 +1.【推荐】日志语言应使用英文 +注：应在打印日志时输出英文，防止中文编码与终端不一致导致打印出现乱码的情况，对故障定位和排查存在一定的 +干扰。如果日志中的错误信息用英文描述不清楚可使用中文描述，否则容易产生歧义。国际化团队或海外部署的服务 +器由于字符集问题，uing用英文来注释和描述日志错误信息。 +2.【推荐】日志打印时不宜直接用JSON工具将对象转换成String +反例： +1 public void doSth(){ +2 +log.info("do sth and print log，data={}"，JsoN.toJsoNstring(data)); +3 +//业务逻辑 +4 +51 +注： +·fastison等序列化组件是通过调用对象的get方法将对象进行序列化，如果对象里某些get方法被覆写，存在抛出异 +常的情况，则可能会因为打印日志而影响正常业务流程的执行。 +打日志过程中对一些对象的序列化过程也是比较耗性能的。首先序列化过程本身时一个计算密集型过程，浪费 +cpu。其次这个过程会产生很多中间对象，对内存也不友好。 +正例： +可以使用对象的toString(（）方法打印对象信息，如果代码中没有对toString（有定制化逻辑的话，可以使用apache的 +ToStringBulider工具。 +1public void doSth(){ +2 +log.info("do sth and print log, data={}", data.toString()); +3 +log.info("do sth and print log， data=[}"， ToStringBuilder.reflectionToString(data，T +4 +3. +【强制】不应打印无意义（无业务上下文、无关联日志链路id）的日志 +反例： +不带任何业务信息的日志，对排查故障毫无意义。 +1public void doSth(）{ +2 +log.info("do sth and print log"); +3 +//业务逻辑 +4 +5} +对于无异常分支的代码打印日志，一般流程下，异常分支都会打日志，如果没有出现异常，那就正常执行了。 +1public void doSth(）{ +2 +doIt1(); +3 +log.info("do sth 1l1"); +4 +doIt2(); +5 +log.info("do sth 222"); +6} +正例： +·日志应带相关的业务信息，有利于排查问题快速定位到原因。 +1public void doSth(）{ +2 +log.info("do sth and print log， id=[}"，id); +3 +//业务逻辑 +4 ++ +【强制】不应在循环中打印非DEBUG级别的日志 +反例： +1 public void doSth(){ +2 +for(String s:strList){ +3 +log.info("do sth and print log: {}"，s); +4 +//业务逻辑 +5 +6 +7 +5.【推荐】在核心业务逻辑中遇到if..else等条件，每个分支首行都应打印日志 +在编写核心业务逻辑代码时，如遇到if..else...或者switch这样的条件，可以在分支的首行就打印日志，这样排查问题 +时，就可以通过日志，确定进入了哪个分支，代码逻辑更清晰，也更方便排查问题。 +正例： +1 public void doSth(){ +2 +if(user.isVip()){ +3 +log.info（"该用户是会员，Id：[}，开始处理会员逻辑",user，getUserId（））； +4 +//会员逻辑 +5 +}else{ +6 +log.info（"该用户是非会员，Id：[}，开始处理非会员逻辑",user，getUserId（）） +//非会员逻辑 +9} +6.【推荐】宜打印必要的参数，不宜整个对象打印 +反例： +1 public void doSth(）{ +2 +log.info("print log，data={}"，data.toString(）); +3 +//业务逻辑 +4 +5} +注：首先分析下自己是否必须把所有对象里的字段打印出来？如果对象中有50个字段，但只需其中两个参数就可以定 +位具体的原因，那么全量打印字段将浪费内容空间且因为字段过多，影响根因排查。 +正例： +1 public void doSth(){ +2 +log.info("print log，id={}，type={}"，data.getId()，data.getType()); +3 +//业务逻辑 +4 +5} +注：使用这个种方法需及时防止npe，并考虑是否核心场景，核心场景建议还是打全，避免漏打、少打影响线上问题 +定位&排查。 +7.【强制】在接口/方法的入口/出口处，打印请求及响应参数日志。 +8 +【推荐】日志内容中不应仅打印特殊字符或数字。 +9. +【推荐】日志内容中应包含关键特征类信息，例如：用户标识或流水号。 +10. +【强制】日志单行大小应不超过200K +11．【强制】打印日志的代码不应失败，阻断流程！ +一定要确保不会因为日志打印语句抛出异常造成业务流程中断，如下所示，shop为null的会导致抛出NPE。 +1public void doSth(){ +2 +log.info("do sth and print log: [}"，shop.getId()); +3 +//业务逻辑 +4 +5} +12.【强制】不应使用System.out.println(输出日志 +反例： +1public void doSth(){ +2 +System.out.println("doSth..."); +3 +//业务逻辑 +4 +5} +注：通过分析System.out.println源码可知，System.out.println是一个同步方法，在高并发的情况下，大量执行 +println方法会严重影响性能。 +1 public void println(String x){ +2 +synchronized （this）[ +3 +print(x) ; +4 +newLine(); +5 +6 +不能实现日志按等级输出。具体来说就是不能和日志框架一样，有debug，info，error等级别的控制。 +System.out、System.error打印的日志并没有打印在日志文件中，而是直接打印在终端，无法对日志进行收集。 +正例： +在日常开发或者调试的过程中，应使用标准日志记录系统log4j2或者logback（但不应直接使用其中的APl)，异步的进 +行日志统一收集。 +1 public void doSth(){ +2 +log.info("doSth...") ; +3 +//业务逻辑 +13.【强制】对于debug/info级别的日志输出，应进行日志级别的开关判断 +反例： +1 public void doSth(){ +2 +String name = "xxx"; +3 +logger.debug("print debug log"+ name); +4 +logger.info("print infolog"+ name); +5 +//业务逻辑 +6 +7} +注： +如果配置的日志级别是warn的话，上述日志不会打印，但是会执行字符串拼接操作，如果name是对象，还会执行 +toString（方法，浪费了系统资源，执行了上述操作，最终日志却没有打印，因此建议加日志开关判断。 +正例： +在debug、info级别日志打印前加上对应级别的日志开关判断，通常可以将开关判断逻辑包装在日志工具类中，统一 +实现。 +1 public void doSth(){ +2 +if(logger.isDebugEnabled()）{ +3 +logger.debug("print debug log {}"，name); +4 +5 +if(logger.isInfoEnabled()）{ +6 +logger.info("print info log [}"，name; +7 +} +8 +//业务逻辑 +9 +10} +14. +【强制】打印异常日志应要输出全部错误信息 +反例： +没有打印异常e，无法定位出现什么类型的异常 +1 public void doSth(){ +2 +tryf +3 +//业务逻辑 +4 +5 +}catch（Exception e）{ +6 +log.error("execute failed"); +7 +8} +没有记录详细的堆栈异常信息，只记录错误基本描述信息，不利于排查问题。 +1 public void doSth(){ +2 +tryf +3 +//业务逻辑 +4 +5 +}catch (Exception e){ +6 +log.error("execute failed",e.getMessage()); +7 +8 +正例： +一般日志框架中的warn、error级别均有存在传递Throwable异常类型的APl，可以直接将抛出的异常传入日志APl中。 +1void error(String varl， Throwable var2); +2 public void doSth(){ +3 +tryf +4 +//业务逻辑 +5 +6 +}catch （Exception e){ +7 +log.error("executefailed"，e); +8 +9} diff --git a/assets/images/log/log_easy.txt b/assets/images/log/log_easy.txt new file mode 100644 index 0000000..7fe973a --- /dev/null +++ b/assets/images/log/log_easy.txt @@ -0,0 +1,633 @@ +应用日志规范 +(Java) +1. +技术要求 +1.1 记录原则 +[强制] 隔离性: 日志输出不应影响系统正常运行; +[强制] 安全性: 日志打印本身不应存在逻辑异常或漏洞。导致产生安全问题; +[强制] 数据安全: 不应输出机密 +敏感信息。如用户联系方式。身份证号码。 token等。应保证日志的完整性 +可审计性; +[强制] 可监控分析: 日志应提供给监控迸行监控; +分析系统迸行分析; +[强制] 可定位排查: 日志信息输出应有意义。应具有可读性。可供开发人员排查线上问题。 +1.2 +日志级别 +在我们日常开发中有四种比较常见的日志打印等级。不同的等级适合在不同的时机下打印日志。 + +主要使用的有以下四个等级: +1. DEBUG +DEUBG级别应主要输出调试性质的内容 +该级别日志应用于开发。测试阶段输出。该级别的日志应尽可能地详尽, +开发人员可以将各类详细信息记录到DEBU6里。起到调试的作用。包括参数信息。调试细节信息。返回值信息等 +等。便于在开发 +测试阶段出现问题或者异常时, +对其迸行分析。 +2. INFO +INFO级别的主要记录系统关键信息。旨在保留系统正常工作期间关键运行指标。开发人员可以将初始化系统配置 _ +业务状态变化信息。 或者用户业务流程中的核心处理记录到INF0日志中 +方便日常运维工作以及错误回溯时上下文 +场景复现。应在项目完成后 +在测试环境将日志级别调成INFO, 然后通过INF0级别的信息看看是否能了解这个应用 +的运用情况。如果出现问题后是否这些日志能否提供有用的排查问题的信息。 +WARN +WARN 级别的主要输出警告性质的内容。这些内容是可预知且是有规划的。比如。某个方法入参为空或者该参数的值 +不满足运行该方法的条件时。在WARN级别的时应输出较为详尽的信息 +以便于事后对日志进行分析。 +注: 常见的WARN级别异常 +用户输入参数错误 +非核心组件初始化失败 +后端任务处理最终失败 {如果有重试且重试成功。就不需要WARN) +数据插入幂等 +ERROR +ERROR级别主要针对于 +些不可预知的信息。诸如: 错误 +异常等。比如。茌catch块中抓获的网络通信_ +数据库连 +接等异常 +若异常对系统的整个流程影响不大。可使用WARN级别日志输出。在输出ERROR级别的日志时。应尽量多 +地输出方法入参数。方法执行过程中产生的对象等数据 +在带有错误 +异常对象的数据时, +应将该对象一井输出。 +注: +常见的ERROR级别异常 +程序启动失败 +核心组件初始化失败 +连不上数据库 +核心业务访问依赖的外部系统持续失败 +OOM +不应滥用ERROR级别日志。 +般来说在配置了告警的系统中 +WARN级别一般不会告警 +ERROR级别则会设置监控 +告警甚至电话报警 +ERROR级别日志的出现意味着系统中发生了非常严重的问题。应有人立即处理。 +错误的使用ERROR级别日志; +不区分问题的重要程度 +只要是问题就采用ERROR级别日志。这是极其不负责任的表 +现 +因为大部分系统中的告警配置都是根据单位时间内ERROR级别日志出现的数量来定的。随意打ERRORO志会造 +成极大的告警噪音。造成重要问题遗漏。 +1.3 日志格式 +1.3.1 +后端日志格式 +后端日志可以保存或输出到文件 +远程服务器。控制台及数据库等, +日志输出包含以下要素: +时间戳: +2024-01-29T15:30:45 +789 +日志链路id(traceld, rpcld) (可选) +0b26053315407142451016402XXXXX +日志级别: DEBUG +INFO, +WARN +ERROR。 FATAL +线程名: SofaBizprocessor-4-thread-333 +main +类名或Lo99er名称: +COm.example +MyClass +方法名与行号 (可选) : +myMethod (L45) +调用耗时 (可选) +Ims +调用是否成功(YIN) (可选) +状态码 (可选) +SUCCESS +系统上下文信息(调用系统名。调用系统ip。调用时间戳。是否压测(YIN)) (可选) +appName , 1p地址 ,时间戳 +请求入参 (可选) +参数1 +请求出参 (可选) +参数1 +日志消息内容: +IThis +15 +log +message +TNo +URLs +4i1 +be +polled +as dynamic +configuration +SOUrCeS +日志自定义输出格式如下: +2024-01-29 +15;30:45 +789 +[0b26053315407142451016402XXXXX +0.3 +1i - ] +[INFO] +[SofaBizprocessor-4-thread-333] +{com +example.MyCLass } +122 +[(Ims +丫,SUCCESS ) (appName +地址 ,时间戳,丫) (参数1 ,参数2) ] - +川o +URLs +V111 +polled +Jynamic +Confi +guration +SOUTCes +0b25053315407142451016402XXXX +0.3 +是 traceld; +[INFO] +是日志级别; +[SofaBizProcessor-4-thread-3331 +是线程名; +{com.example .MyCLass } +是类名; +122是行号; +No +URLS +Wi11 +be +polled +35 +dynamic +configuration +SOUTCeS +是实际的日志消息。具体的业务相关日志打 +印形式可以根据业务实际情况自定义 +日志标准输出格式如下: +2024-01-29 +15:30:45,789 +[INFO] +[main] +{COm +example .MyClass} +No URLS wi2l +polled +dynamic +configuration +SOUTCes +移动端日志遵循后端日志格式。 +1.3.2 前端日志格式 +前端日志格式并没有固定的标准。但通常会遵循一些常见的约定和最佳实践。以下是 +些常见的前端日志格式和考虑 +因素: +1。时间戳: 在日志条目的开头添加一个时间戳, +以便跟踪事件发生的时间。 +日志级别: 指定日志条目的级别 (例如。错误。警告。信息。调试等) +以便根据需要迸行筛选和过滤。 +3。源代码位置: 在日志条目中包含源代码的位置信息 (例如。文件名 +行号等) ,以便快速定位问题。 +4。消息内容: 提供有关事件或错误的详细信息。包括任何相关的上下文或错误消息。 +5。自定义字段: 根据需要添加其他自定义字段。例如用户I0。会话I。浏览器信息等 +以下是一个简单的前端日志格式示例: +[2023-03-15 +14:32:01] +INFO: +main.j5:123 +User +LOBged +SUCCessfulIy +[2023-03-1514:32:15] +ERROR: +User.js :45 +Failed +fetch +USer +Jata +Error: +Network +Error. 码 +在这个示例中 +每条日志条目都包含时间戳。日志级别。源代码位置以及消息内容。此外,还可以根据需要添加其他 +自定义字段。例如用户I。会话I0等 +需要注意的是 +前端日志格式应该根据项目的具体需求和规范迸行定制, +以便更好地满足项目的需求 +同时。还需要 +考虑日志的存储。传输和展示等方面的问题。以确保日志的可用性和可维护性。 +1.4日志存储 +应及时清理和管理日志, +以避免过大的日志文件或存储空间的浪费。及时地分析日志, +以便发现潜在的问题或改迸系 +统性能。 +[推荐1 对于信息系统 +日志的保存时间至少为6个月。每个月必须备份一次日志文件。在实际应用中, +可以根据日 +志文件的重要程度。文件大小以及磁盘空间自行调整 +6个月内至少清理 +~次过期的或无用的日志数据 +此外。还可 +以对日志迸行监控_ +收到磁盘报警时, +对1个月之前的数据可以迸行删除或者转储 +1.5 日志安全 +1.5.1 保护范围 +日志记录中包含的某些内容出于隐私保护 +数据安全和法规遵从的要求。不应直接以原始形式显示。以下是一些需要 +迸行处理的肉容类型: +法律法规不允许的信息 +《今人信息保护法》涉及的敏感信息:《个保法》第二十八条 敏感个人信息是 +旦泄露或者非法使用。容易导致 +自然人的人格尊严受到侵害或者人身 +财产安全受到危害的个人信息。包括生物识别。宗教信仰。特定身份。医 +疗健康 +金融账户 +行踪轨迹等信息, +以及不满十四周岁未成年人的个人信息。根据法规。个^可识别信息如身 +份证号码。电话号码。住址 +电子邮件地址等必须严格保护, +未经同意不得非法收集 +使用或披露。同时。个人 +敏感数据如健康状况。医疗记录 +生物识别信息等高度私密。处理时需特别谨慎。确保合法合规。 +,澳集团保密要求 +包括但不限于涉密技术资料。勘探数据 _ +生产数据 +商业合作细节等信息。信息系统日志中应避免直接记录这些 +内容 +井对所有操作迸行严格的审计和安全控制。确保日志的安全存储。访问权限控制以及必要时的数据脱敏 +涉及的商业秘密信息 +在日志中 +商业秘密信息可能以各种形式体现。例如研发数据。客户名单。内部策略 +未公开的产品设计和技术 +方案等。 +业务定义敏感信息 +金融交易信息: 银行卡号 +支付卡数据 {CVV码。有效期等〉 是金融行业严控的信息。必须采取加密或其他安全 +措施妥善处理和存储。 +业务敏感信息: 还包括未公开的战略规划。客户名单 +定价策略。市场研究结果_ +内部财务数据等。任何可能导 +致企业竞争优势受损或违反合同约定的信息 +可能有助于攻击者利用的敏感数据 +用户的会话I0(如果需要跟踪会话相关的事件 可以考虑用Hash值代替) +会话10与Hash值: 为了防止会话劫n。原始会话1不应在日志中明爻记录。可以考虑采用哈希值代替 +但要确保 +该哈希不能被反向解析为原始会话标识= +软件版本及框架版本: 虽然不直接构成安全风险 +但在某些情况下暴露版本信息可能让攻击者了解潜在漏洞, +此建议不在日志中详细记录或仅记录到主版本级别。 +散列值: 如果散列为敏感数据的散列。例如密码散列。在记录日志时应当谨慎。避免将过于详细的散列值存入日 +志 +特别是对于易破解的弱散列算法。 +访问TokenlAPIToken: 应采取措施避免在日志中完整记录访问令牌或AP!令牌; +以防止泄露后被恶意使用= +认证密码: 绝对不应该在任何日志中明爻记录用户密码。即使是对服务器端的操作日志也应该加密或通过其他方 +式去标识化。 +数据库连接字符串与密钥: 包含数据库凭据的连接字符串_ +加密密钥和其他主密钥绝对不能出现在日志中 +这些 +信息一旦泄露可能导致数据大规模泄露或系统完全失控。 +1.5.2 脱敏方法 +不应在日志中明爻记录敏感信息数据, +必要时对这些数据迸行脱敏处理。对敏感的日志信息迸行加密。以保护数据安 +全。确保在存储和传输过程中对敏感信息迸行加密。以防止未授权的访问和泄露 +需要脱敏的信息见"保护范围"部分。 +注: 在迸行日志脱敏时,会根据不同的敏感级别采用不同的脱敏策略。包括替换 +遮盖_ +截断。哈希加密等方法。以 +保护这些信息不被泄露。同时确保日志能够满足必要的业务分析和故障排查要求 +具体方式包括但不限于: +移除 {Remove) +直接从日志条目中删除敏感字段。 +分类与分级处理 +根据数据的敏感程度迸行分类。并针对不同类别实施不同的脱敏策略。例如部分脱敏或完全替 +换 +脱敏 {Masking) +替换敏感字段为星号_ +占位符或其他非敏感字符。如将电话号部分数字脱敏为 +UUr」| +{量k +1234 +净化 (Sanitizing) +对敏感数据进行格式化或规范化。确保不泄露实际意义。例如使用哈希函数处理用户身份信 +Hash化: 对于需要保持唯 +-性的数据。比如用户名或电子邮件地址 +可以采用不可逆的哈希算法迸行处理。用于 +审计目的但不能反向还原出原始数据。 +实施上述措施有助于企业在满足日志分析和故障排查需求的同时,最大限度地降低数据泄露风险;井符合《网络安全 +法》和 《网络安全等级保护基本要求》等法律法规中有关个人信息保护的要求。 +注: 在使用日志框架如logback。 1o94j等时, +可以配置相应的插件或者自定义拦截器来实现自动化脱敏功能 +1.5.3 安全措施 +日志数据安全是确保系统在生成。传输 +存储日志时。保护敏感信息不被未经授权的访问。泄露 +篡改或丢失的重要 +环节。以下是维护日志数据安全的- +些关键措施: +日志数据传输加密 +在传输过程中 +可使用SSL/TLS等安全协议加密5YSL06或其他形式的日志数据流 +2。访问控制: +实施严格的访问控制策略。只有授权人员才能查看和操作日志数据 +敏感信息处理: +对于包含敏感信息的日志条目。执行脱敏处理。如替换或模糊化密码。个人识别信息 (P)。信用卡号等敏感内 +容 +标准化与合规: +确保日志格式和实践符合行业标准和法规要求。比如《网络安全法》和 《网络安全等级保护基本要求》对于数据 +处理的规定。 +备份与恢复: +定期备份日志。井保证备份数据的安全性。同时设计有效的农难恢复方案。 +通过上述措施。可从多个维度保障日志数据的安全性。同时也为数据分柝。故障排查 +安全寅计及合规性检查提供了 +有力支持 +1.6 Java最佳实践 +[推荐」 日志语言应使用英文 +注: 应在打印日志时输出英文。防止中文缩码与终端不 +致导致打印出现乱码的情况。对故障定位和排查存在一定的 +干扰。如果日志中的错误信息用英文描述不清楚可使用中文描述。否则容易产生歧义。 +国际化团队或海外部署的服务 +器由于字符集问题; uing用英文来注释和描述日志错误信息。 +[推荐) 日志打印时不宜直接用 JSON工 具将对象转换成String +反例 +public void dosth(){ +info(wdo +Sth +ahd +print +data={}" +JSON .LoJSONString (data) ) +业务逻辑 +注二 +fastjson等序列化组件是通过调用对象的get方法将对象迸行序列化。如果对象里某些get方法被覆写。存在抛出异 +常的情况。则可能会因为打印日志而影响正常业务流程的执行。 +打日志过程中对一 +些对象的序列化过程也是比较耗性能的。首先序列化过程本身时 +个计算密集型过程。浪费 +Cpu。 其次这个过程会产生很多中间对象。对内存也不友好。 +正例 +可以使用对象的toStringl) 方法打印对象信息。如果代码中没有对toString() 有定制化逻辑的话。可以使用apache的 +ToStringBulider工 具 +Dublic +Void dosth(){ +info(wdo +Sth +ahd +print +LOE; +data{}" +data +CoStrine()); +Log +info(wdo +Sth +ahd +print +data{}" +TostringBuilder.reflectionTostring (data, +(强制] 不应打印无意义(无业务上下文 +无关联日志链路id)的日志 +反例 +不带任何业务信息的日志。对排查故障毫无意义。 +public +V01d +dosth() { +info("do +Sth +ahd +print 1oB ) +业务逻辑 +1Og +1o, +1Og +1o, +10B +对于无异常分支的代码打印日志, +般流程下 +异常分支都会打日志,如果没有出现异常。那就正常执行了 _ +public void +dosth() { +doItI(); +info(wdo sth _11" ) +doIt2() +info +Oo sth 222") +正例 +日志应带相关的业务信息。有利于排查问题快速定位到原因。 +public +Void +dosth() { +info(wdo sth +ahd +print +14{]" +id ) +业务逻辑 +[强制] 不应在循环中打印非DEBUG级别的日志 +反例 +public void +dosth() { +for (Strine +strlist ) +info("do +Sth +anc +print log: +{}I +5) ; +业务逻辑 +[推荐] 在核心业务逻辑中遇到i..else等条件。每个分支首行都应打印日志 +在缩写核心业务逻辑代码时。如遇到i..else. . 或者switch这样的条件_ +可以在分支的首行就打印日志。这样排查问题 +时 +就可以通过日志。确定迸入了哪个分支。代码逻辑更清晰。也更方便排查问题 +正例: +public void +dosth() { +af(user.isVip()) { +log.info ("该用户足会员 , Id : {} ,开始处理会员逻辑" _ +User, getUserId ()); +1/会员逻辑 +}else{ +info +该用户是非会员 , Id : {} ,开始处理非会员逻辑" _ +User +getUserId () ) +/1非会员逻辑 +108 +108 +108 +10B, +loB +10e +[推荐] 宜打印必要的参数。不宜整个对象打印 +反例 +public +Void +dosth() { +info("print +data={}I +data.tostring()); +业务逻辑 +注 +首先分析下自己是否必须把所有对象里的字段打印出来? 如果对象中有50个字段。但只需其中两个参数就可以定 +位具体的原因 +那么全量打印字段将浪费内容空间且因为字段过多。影响根因排查。 +正例 +public +Void +dosth() { +info("print +-d={}, +type={}" +data +geCId (), +data. getType()); +业务逻辑 +注: 使用这个种方法需及时防Lnpe, 井考虑是否核心场景;核心场景建议还是打全; +避免漏打。少打影响线上问题 +定位&排查。 +[强制] 在接口/方法的入口|口处。打印请求及响应参数日志。 +[推荐] 日志内容中不应仅打印特殊字符或数字 +[推荐] 日志内容中应包含关键特征类信息, +例如: 用户标识或流水号 +10. +(强制] 日志单行大小应不超过200K +11 +[强制] 打印日志的代码不应失败; +阻断流程! +一定要确保不会因为日志打印语句抛出异常造成业务流程中断。如下所示, shop为null的会导致抛出NPE。 +public +Void +dosth() { +info +Wdo sth +ahd +print +{}" +shop. getId ()); +业务逻辑 +108 +108 +108 +108 +108 +108: +12. +[强制] 不应使用System.out.println()输出日志 +反例= +public +V01d +dosth() { +System +OUt.println ( +doSth。" ) +业务逻辑 +注: 通过分析System.out.println源码可知, System.out println是- +个同步方法。在高井发的情况下。大量执行 +println方法会严重影响性能 +public +V01d +println (String +synchronized (this) +print (x) +newLine() +不能实现日志按等级输出。具体来说就是不能和日志框架 +-样。有 debug, info, error等级别的控制 +System.out。 System.error打印的日志井没有打印在日志文件中。而是直接打印在终端。无法对日志迸行收集 +正例= +在日常开发或者调试的过程中 +应使用标准日志记录系统1094j2或者logback(但不应直接使用其中的API), 异步的进 +行日志统 +收集。 +public +V01d +dosth() { +lOB.info("dosth...") +业务逻辑 +13. +(强制] 对于debuglinfo 级别的日志输出,应迸行日志级别的开关判断 +反例 +public +V01d +dosth() { +String +Hame +XXXI +logger +(Iprint +l0g" +hame ) +logger +info ("print info +LOE" +name) +业务逻辑 +注 +如果配置的日志级别是warn的话, +上述日志不会打印。但是会执行字符串拼接操作。如果name是对象; +还会执行 +toString()方法。浪费了系统资源 +执行了上述操作。最终日志却没有打印; +因此建议加日志开关判断 +正例: +在debug info 级别日志打印前加上对应级别的日志开关判断。通常可以将开关判断逻辑包装在日志工具类中,统 +实现 +public +Void dosth() { +1 +(logger. +sDebugEnabled () ) +Zogger. debug +Iprin +name / +1 +(logger.isInfoEnabled()) +logger +info ("print +Tnfo +{}" +name +业务逻辑 +14. +[强制] 打印异常日志应要输出全部错误信息 +反例: +没有打印异常e。无法定位出现什么类型的异常 +debug +gebug +Jebug +10B +ZOB +public +Void dosth() { +Cry { +业务逻辑 +catch +(Exception e){ +error +execute failed") +没有记录详细的堆栈异常信息。只记录错误基本描述信息。不利于排查问题 +public +Void dosth() { +Cry { +业务逻辑 +catch +(Exception e){ +eFror +execuTe ++a1eqI +e. BetMessage()); +正例 +般日志框架中的warn, error级别均有存在传递Throwable异常类型的API, +可以直接将抛出的异常传入日志API中 +Void +error(String VarI, +Throwable Varz) +public +V01d +dosth() { +Cry { +业务逻辑 +catch +(Exception e){ +error +execUe +failedw +loB +lOB +loB diff --git a/assets/images/log/截屏2025-04-30 17.12.09.png b/assets/images/log/截屏2025-04-30 17.12.09.png new file mode 100644 index 0000000..40c3bf7 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.12.09.png differ diff --git a/assets/images/log/截屏2025-04-30 17.12.28.png b/assets/images/log/截屏2025-04-30 17.12.28.png new file mode 100644 index 0000000..7976813 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.12.28.png differ diff --git a/assets/images/log/截屏2025-04-30 17.12.47.png b/assets/images/log/截屏2025-04-30 17.12.47.png new file mode 100644 index 0000000..e5253a8 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.12.47.png differ diff --git a/assets/images/log/截屏2025-04-30 17.12.59.png b/assets/images/log/截屏2025-04-30 17.12.59.png new file mode 100644 index 0000000..e81bc81 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.12.59.png differ diff --git a/assets/images/log/截屏2025-04-30 17.13.10.png b/assets/images/log/截屏2025-04-30 17.13.10.png new file mode 100644 index 0000000..182fad6 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.13.10.png differ diff --git a/assets/images/log/截屏2025-04-30 17.13.26.png b/assets/images/log/截屏2025-04-30 17.13.26.png new file mode 100644 index 0000000..ff5ff55 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.13.26.png differ diff --git a/assets/images/log/截屏2025-04-30 17.13.39.png b/assets/images/log/截屏2025-04-30 17.13.39.png new file mode 100644 index 0000000..7b1bc15 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.13.39.png differ diff --git a/assets/images/log/截屏2025-04-30 17.13.49.png b/assets/images/log/截屏2025-04-30 17.13.49.png new file mode 100644 index 0000000..0a2acb6 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.13.49.png differ diff --git a/assets/images/log/截屏2025-04-30 17.13.59.png b/assets/images/log/截屏2025-04-30 17.13.59.png new file mode 100644 index 0000000..84bf516 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.13.59.png differ diff --git a/assets/images/log/截屏2025-04-30 17.14.13.png b/assets/images/log/截屏2025-04-30 17.14.13.png new file mode 100644 index 0000000..b14034a Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.14.13.png differ diff --git a/assets/images/log/截屏2025-04-30 17.14.21.png b/assets/images/log/截屏2025-04-30 17.14.21.png new file mode 100644 index 0000000..148a1e2 Binary files /dev/null and b/assets/images/log/截屏2025-04-30 17.14.21.png differ diff --git a/assets/images/test/test.txt b/assets/images/test/test.txt new file mode 100644 index 0000000..ac98cbf --- /dev/null +++ b/assets/images/test/test.txt @@ -0,0 +1,747 @@ +Q/SY KLD +昆仑数智科技有限责任公司企业标准 +Q/SY KLD +软件测试设计编制规范 +Specificationforsoftwaretestdesigndocumentation +(草案) +20XX-XX-XX发布 +20XX-XX-XX实施 +昆仑数智科技有限责任公司 +发布 +目 +蒋次 +前言 +1范围.. +2规范性引用文件 +1 +3术语和定义.. +1 +3.1基准测试BenchmarkTesting +1 +3.2MCDC测试ModifiedCondition/DecisionCoverage. +1 +3.3通过准则passcriteria... +1 +3.4软件特征softwarefeature... +1 +3.5测试覆盖testcoverage.. +1 +3.6测试设计testdesign. +2 +3.7测试项testitem.. +2 +3.8测试目标testobjective. +2 +3.9WCAG标准WebContentAccessibilityGuidelines. +2 +4测试设计的结构.. +.2 +5测试设计要求. +2 +5.1测试设计说明标识符 +2 +5.2识别测试项. +.2 +5.3测试技术选择. +3 +5.4测试覆盖要求. +.5 +5.5测试项标识... +7 +5.6测试通过准则 +.8 +6风险评估.. +.8 +6.1风险识别.. +.8 +6.2风险缓解策略 +6 +附录A（资料性） +测试技术分类 +附录B（资料性） +常见测试工具 +.13 +附录C（资料性）软件测试设计示例 +.14 +C.1测试设计规格标识符 +..14 +C.2测试设计方法细化 +.14 +C.3测试项标识... +.17 +C.4测试通过准则. +17 +参考文献.. +.18 +前 +蓝言 +本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定 +起草。 +本文件是Q/SYXXXXX《XXXXXXXX》的第1部分。Q/SYXXXXX已经发布了以下部分： +第1部分：XXXXXXXXXXXXXXXX； +第2部分：XXXXXXXXXXXXX。 +（分部分标准应有此段描述，只写出已经发布的，没有发布的可在引言中描述。） +本文件由数字和信息化管理部提出。 +（信息标准提出单位只可以是”数字和信息化管理部”或中国石油天然气集团有限公司标准化委 +员会信息技术专业标准化技术委员会”） +本文件由中国石油天然气集团有限公司标准化委员会信息技术专业标准化技术委员会归口。 +本文件起草单位：数字和信息化管理部、共享运营公司、勘探开发研究院、昆仑数智。 +（起草单位写到局级单位且为简称【在每年标准制修订计划中有简称，可查询】，应与编制说明中 +的单位对应一致，集团公司企业标准至少应由3个局级单位共同起草） +本文件主要起草人：XXX、XXX +（专家审查会之前，起草人应确定，排名顺序应按照编写标准的责献程度排名。） +本文件主要审查人：XXX、XXX。 +1范围 +本文件规定了基本的软件测试设计文档的格式和内容要求， +本文件适用于软件测试过程中软件设计的编写工作。 +2规范性引用文件 +下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， +仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 +文件。 +GB/T15532-2008计算机软件测试规范 +GB/T9386-2008计算机软件测试文档编制规范 +GB/T38634.4-2020系统与软件工程软件测试第4部分：测试技术 +马品 +3术语和定义 +GB/T11457中确立的以及下列术语和定义适用本标准。 +3.1 +基准测试BenchmarkTesting +通过运行标准化测试程序或场景，评估系统、组件或软件的性能、效率及稳定性，为后续优化或比 +较提供数据依据。 +3.2 +MCDC测试ModifiedCondition/DecisionCoverage +MCDC测试ModifiedCondition/DecisionCoverage（修改条件/决策覆盖测试）是一种基于结构的 +白盒测试技术，旨在验证代码中每个逻辑条件对整体决策结果的独立影响能力。 +3.3 +通过准则passcriteria +判断一个软件项或软件特征的测试是否通过的判别依据。 +3.4 +软件特征softwarefeature +软件项的显著特性（如功能、性能或可移植性）。 +3.5 +测试覆盖testcoverage +给定的测试或测试集，对于给定的系统和部件实现所有规定的需求的程度。 +3.6 +测试设计testdesign +一种文档，它规定对软件特性或软件特性与标识相关测试的组合的详细测试方法。解决测什么、怎 +么测的问题。 +3.7 +测试项testitem +测试点 +是测试目标的软件项。 +3.8 +测试目标testobjective +在规定的条件下要量度的软件特性的标识集，它由把时间行为与在软件文档中描述的所要求的行为 +进行比较来量度。 +3.9 +WCAG标准WebContentAccessibilityGuidelines +WCAG（WebContentAccessibilityGuidelines，Web内容无障碍指南）是由方维网联盟（W3C）制 +定的国际标准，旨在确保残障人士能够平等访问和使用网络内容。其核心目标是消除数字环境中的障碍， +帮助视觉、听觉、运动或认知障碍用户通过辅助技术（如屏幕阅读器）与网页交互。 +4测试设计的结构 +测试设计应有如下内容和结构： +a）测试设计说明标识符； +b）识别测试项； +c）测试设计方法细化（技术选择、覆盖要求）； +d）测试项标识； +e）软件特征测试通过准则。 +5测试设计要求 +5.1测试设计说明标识符 +为该测试设计说明规定唯一的标识符。如果在相关的测试计划中有规定，则应引用。 +5.2识别测试项 +5.2.1测试项来源与范围定义 +测试项是测试目标的软件项。测试项需基于需求文档、设计文档及风险分析报告等文件进行提取和 +识别。具体包括：功能需求、性能指标、安全约束、兼容性要求、可靠性要求、易用性要求、可维护性 +要求、可移植性要求等。 +在测试过程中，应明确测试项的层级与类型：层级分为模块级、系统级和接口级；类型包括功能测 +试、性能测试、安全性测试及兼容性测试等。同时，应明确定义排除项并说明排除理由，以确保测试范 +围的透明性。 +5.2.2测试项识别方法 +测试项的识别需结合系统需求、设计文档及风险分析，提取软件特性中可测试属性。以下是具体方 +法： +a）基于需求的分解法 +1）功能特征识别：通过逐条分析需求文档（如用户故事、需求规格说明书），提取功能点并 +分解成测试项； +示例：通过需求描述”系统应支持用户密码修改”→提取特征”密码修改功能”，包括输 +入校验、加密存储等子特征，最终形成测试项。 +2）非功能特征识别：从性能、安全性等非功能性需求中提取可量化指标。 +示例：响应时间≤2秒、并发用户数≥1000人。 +b）基于设计的结构分解法 +1）架构与模块分解：根据系统设计文档（如架构图、模块说明书），识别各组件接口、数据 +流及依赖关系，确定需测试的测试项； +示例1：根据系统的功能特性，将其拆分为不同的功能模块，如登录模块、搜索模块、购物车 +模块等，每个功能模块可独立进行测试； +示例2：版本拆分：根据项目规划的版本进行拆分，同一个版本的功能可独立进行测试。 +2）代码分析：通过代码走查或工具识别关键逻辑分支、异常处理路径等结构测试项； +3）对于图形用户界面系统，可以将界面元素拆分为不同的组件，如按钮、文本框、下拉框等。 +每个界面元素可单独进行测试： +4）根据数据在系统中的流动路径进行拆分，从输入到处理再到输出。可以针对数据的输入、 +处理和输出进行测试 +c）用户场景分解法 +1）流程图：通过活动图或业务流程图，识别端到端场景中的关键测试项。 +示例：按照业务流程的顺序将系统拆分为一系列步骤或阶段，如订单处理流程、客户注册流 +程等，每个业务流程可以独立进行测试。 +2）角色-功能矩阵：按不同用户角色（如管理员、普通用户）划分权限，根据权限进行测试。 +d）基于风险的优先级划分 +1）风险矩阵评估：结合历史缺陷数据、用户场景重要性，对软件特征进行风险评级，优先识 +别高风险的软件特征进行测试； +2）失效模式分析：针对关键模块，分析潜在失效点（如数据库连接失败），转化为需验证的 +测试项。 +e）行业标准与法规符合性检查 +1）根据国家法规或行业标准识别强制测试项。 +全等级保护基本要求》，识别强制测试项：”用户个人敏感信息数据应加密存储”。 +5.3测试技术选择 +测试技术选择应基于被测对象的特性、需求明确性、测试阶段目标、资源约束及风险等级等因素综 +合评估，主要测试技术见附录A。 +5.3.1技术选择原则 +a)需求明确性 +1）需求清晰时应优先使用基于规格说明的技术，如：等价划分、决策表； +2)）需求模糊时宜使用基于经验的技术和探索性测试。 +b）系统复杂度 +1）逻辑复杂或条件组合多时，采用组合测试或因果图法； +2）状态依赖型系统优先选择状态转换测试。 +c）资源与风险 +1）资源充足时，采用组合测试或MC/DC提高覆盖率； +2）高风险模块需综合多种技术，如：边界值+错误猜测+决策表的测试组合。 +5.3.2测试技术分类及核心自标 +a）基于规格说明的测试技术（黑盒测试） +目标：验证系统行为是否符合需求规格说明，关注输入与输出的正确性。 +适用场景：需求文档明确、功能逻辑复杂或需覆盖用户场景的测试阶段。 +典型技术： +1）等价划分：输入域存在明确分组规则时（如合法/非法值）； +2）边界值分析：输入输出存在数值范围或边界条件时； +3）决策表测试：多条件组合触发不同业务规则时； +4）状态转换测试：系统行为依赖状态迁移； +5）场景测试：模拟用户端到端业务流程。 +b）基于结构的测试技术（白盒测试） +目标：验证代码逻辑的完整性和健壮性，提升代码覆盖率。 +适用场景：单元测试、集成测试或需深度验证代码逻辑的场景。 +典型技术：亮 +1）语句/分支测试：需覆盖代码基本执行路径时； +2）MC/DC测试：高安全性系统需满足严格覆盖准则时； +3）数据流测试：检测变量定义与使用异常时。 +c）基于经验的测试技术 +目标：利用测试人员经验补充系统化设计的盲区。 +适用场景：需求模糊、时间紧迫或需探索潜在缺陷的场景。 +典型技术： +1）错误猜测：依赖历史缺陷模式或领域知识推测易错点； +2）检查表：使用预定义的检查项指导测试设计，确保覆盖关键点。 +5.3.3技术组合策略 +a）分层覆盖：在单元测试中采用白盒技术确保代码质量，在系统测试中通过黑盒技术验证功能完 +整性。 +b）互补增强 +1）针对关键功能应使用边界值分析和错误猜测的组合测试； +2）针对多条件交互功能应使用决策表和分支条件组合等进行组合测试。 +c）选代优化：根据测试结果动态调整技术，当发现分支覆盖不足时应补充分支条件组合测试。 +5.4测试覆盖要求 +测试覆盖要求的制定应与软件质量特性紧密结合，并明确覆盖的度量方法与实施要求。 +5.4.1结合质量特性的覆盖要求 +测试覆盖邀请需结合测试技术分类（基于规格说明、结构、经验）进行设计，具体覆盖类型如下： +5.4.1.1功能测试覆盖要求 +a）需求覆盖 +1）应建立需求道踪矩阵（RTM），确保每个需求对应的功能至少被一个测试用例覆盖，测试 +用例应涵盖所有预期功能和边界条件； +2）应标识需求的优先级，高优先级需求对应的功能应实现100%覆盖。 +b）业务流程覆盖要求 +1）应覆盖所有主流程和分支流程； +2）应测试覆盖异常流程的处理； +3）应验证端到端的业务流程。 +c）UI交互覆盖 +1）应覆盖所有页面元素（按钮、表单、弹窗、导航）的交互行为； +2）应测试覆盖响应式设计的适配性，包括屏幕尺寸、分辨率、横竖屏方向等。 +d）接口覆盖要求：应覆盖验证系统内外接口（API、协议、数据格式）的输入/输出及异常处理。 +e）权限覆盖要求 +1）覆盖所有用户角色的功能权限（如管理员增删改查，普通用户仅查询）； +2）应验证权限变更的实时性。 +）基于结构的测试覆盖 +1）语句/分支测试：应覆盖代码基本执行路径； +2）MC/DC测试：高安全性系统应满足严格覆盖准则； +3）数据流测试：应检测变量定义与使用异常。 +9）基于规格说明的测试技术覆盖要求 +此类覆盖关注需求或功能规格说明的覆盖程度，适用于黑盒测试： +1）等价划分：测试用例需覆盖所有有效和无效等价类，确保每个类至少有一个用例； +2)边界值分析：应覆盖输入域的边界值，如：最小值、最大值、略超出边界的值： +3）决策表测试：应覆盖决策表中所有条件组合对应的动作； +4）状态转换测试：应覆盖所有状态转移路径，包括合法转移和非法触发； +5）场景测试：应覆盖用户场景中的所有关键路径和异常分支。 +5.4.1.2性能测试覆盖要求 +a）负载范围覆盖 +1）宜根据基准测试结果，设计50%、80%、100%、120%四种不同级别的负载测试； +2）宜对每种负载级别持续运行足够时间以观察系统稳定性； +3）宜模拟突发流量场景，测试系统对流量突增的应对能力。 +b）网络环境覆盖 +1）宜覆盖3G/4G/5G/Wi-Fi等多种网络环境，保证高延迟下功能正常； +2）应测试网络切换时的系统表现。 +5.4.1.3安全测试覆盖要求 +a）漏洞扫描覆盖 +1）所有代码应进行静态安全扫描； +2）系统上线前，宜对系统进行动态安全扫描； +3）系统上线前，宜对系统执行渗透测试，覆盖所有对外暴露的接口。 +b）数据安全覆盖 +1）应验证敏感数据（如密码、身份证号）加密存储和传输的情况。 +c)权限覆盖 +1）应测试覆盖所有角色的权限分配情况； +2）应测试权限变更后的即时生效情况。 +d）合规覆盖 +1）应审计所有安全日志的记录和存储情况； +2）应验证系统是否符合相关法律、法规的要求。 +5.4.1.4兼容性测试覆盖要求 +a）浏览器覆盖 +1）应选择Chrome/Firefox/Safari/Edge中至少2个最新版本进行覆盖测试； +2）宜测试浏览器插件和扩展的影响。 +b）移动端覆盖：应选择主流移动设备厂商的不同型号进行覆盖测试； +c）分辨率覆盖 +1）应覆盖720p/1080p/2K/4K及全面屏； +2）应测试不同DPI设置下的显示效果； +3）宜测试覆盖全面屏、刘海屏等特殊屏幕形态。 +d）操作系统覆盖：宜对操作系统的不同版本进行覆盖。 +e）安装卸载测试 +1）应验证模拟常见的安装错误，如空间不足、权限不足、网络中断等。 +2）应检查软件卸载是否彻底； +3）应确认软件安装后是否正常。 +5.4.1.5可靠性测试覆盖要求 +a）压力边界覆盖 +1）应测试超过设计容量50%的负载情况； +2）应测试资源耗尽情况下的系统行为。 +b）容错覆盖 +1）应模拟测试网络中断、服务崩溃、磁盘满等异常场景； +2）应验证降级策略的有效性。 +c）恢复覆盖 +1）应测试数据库崩溃后的恢复流程； +2）应验证备份数据的完整性和可用性。 +5.4.1.6易用性测试覆盖要求 +a）核心路径覆盖 +1）应测试新手用户的首次使用体验情况； +2）宜验证操作步骤的最简化程度。 +b）多语言覆盖 +1）应测试日期、时间、货币等本地化内容； +2）应测试系统所有支持语言的显示效果。 +5.4.1.7可维护性测试覆盖要求 +a）日志覆盖 +1）应确保所有关键操作都有日志记录； +2）应验证日志信息的完整性和可读性。 +b）文档覆盖 +1）应验证系统API文档的完备性； +2）应验证系统部署手册的完备性； +3）应验证系统故障处理指南的完备性。 +5.4.1.8可移植性测试覆盖要求 +a）宜确保系统能在不同环境（云、容器、物理机）中部署和运行； +b）宜覆盖依赖项、配置、数据迁移的兼容性。 +5.4.2覆盖的实施要求 +a)分层覆盖管理： +1）单元测试：代码结构覆盖为主，语句覆盖率≥90%，分支覆盖率>80%； +2）集成测试：接口测试验证所有输入/输出接口及交互协议，应覆盖正常与异常场景； +3）系统测试：需求功能覆盖应达到100%，场景覆盖核心业务流程。 +b）高风险模块增强覆盖：对高优先级需求或复杂模块，应采用多技术组合测试，提高覆盖率。 +c）自动化支持：宜使用自动化工具实现覆盖率动态监控，如：代码覆盖率工具、需求跟踪工具。 +对未覆盖项生成告警并触发测试用例补充机制。 +5.4.3覆盖的合规性要求 +测试覆盖的合规性应满足以下要求： +a）可道溯性：测试用例与需求、代码或风险的关联关系应通过需求跟踪矩阵（RTM）记录； +b）可重复性：覆盖率度量方法应标准化，确保不同测试周期或团队的结果一致性； +c）透明度：测试报告中应明确说明覆盖目标、实际结果及未覆盖项的潜在影响； +d）适应性：覆盖标准应根据项目变更动态调整。 +5.5测试项标识 +列出与该设计有关的每一个测试项的标识并简要描述。测试项列表示例见表1。 +表1测试项示例表 +序号 +测试项描述 +测试项代码 +1. +有效的小数点，含4个小数位的前导点 +NNE.TC.040 +2. +有效的小数点，含1个小数位的嵌人式点 +NNE.TC.041 +3. +有效的小数点，含0个整数的尾部点 +NNE.TC.042 +4. +无效的小数点，5个小数位 +NNE.TC.050 +5. +无效的小数点，2个点 +NNE.TC.051 +6. +无效的小数点，没有数字的点 +NNE.TC.052 +5.6测试通过准则 +给出用于判定软件特征或软件特征组合是否通过或失败的准则。 +a）明确判定依据，定义通过或失败的具体条件，包括但不限于： +1）功能正确性：功能模块的输入与输出必须与需求文档定义的预期结果一致； +2）性能指标：响应时间、吞吐量、资源占用率等需满足预设阈值； +3）兼容性要求：功能需在指定的操作系统、浏览器、设备或版本范围内正常运行； +4）容错能力：对异常输入、非法操作或极端场景需具备合理处理机制。 +b）量化或定性标准 +1）量化标准：提供可测量的指标，例如数值阈值（响应时间≤1秒）； +2）定性标准：描述可观察的行为或状态，例如界面交互流畅无卡顿、业务流程完整无中断。 +c）覆盖范围定义 +1）覆盖率要求：在软件测试阶段，应执行全部设计的测试用例，并提供执行记录； +2通过率要求：关键功能（如核心业务流程、安全模块）的测试用例应100%通过；非关键 +功能的测试用例通过率不低于95%，未通过用例应评估影响范围并在测试报告中明确标注。 +d通过准则豁免 +1）任何偏离上述准则的情况需经上级审批，并在发布说明中明确标注。 +6风险评估 +6.1风险识别 +风险识别是系统化发现可能影响测试目标实现的内外部因素的过程，需覆盖技术、管理、资源及环 +境等多维度风险。 +在软件测试过程中，风险评估是识别潜在威胁、分析其影响并制定应对策略的核心环节，旨在降低 +测试活动的不确定性，确保测试目标的达成。应覆盖技术、管理、资源及环境等多维度进行风险识别。 +风险来源分类见表1。 +表2风险来源分类表 +风险类型 +典型风险示例 +需求风险 +需求不清晰或频繁变更 +风险类型 +典型风险示例 +关键需求遗漏或优先级误判 +技术风险 +复杂算法实现缺陷 +第三方组件兼容性问题 +代码质量风险 +数据风险 +性能瓶颈或安全漏洞 +资源风险 +测试环境不足（如硬件、工具缺失） +成本风险 +人力短缺 +人员能力风险 +人员技能不足 +测试人员对业务不熟悉造成的风险 +测试人员可能对产品的功能不熟悉，导致测试不充分 +进度风险 +开发延期导致测试时间压缩 +缺陷修复周期不可控 +环境风险 +依赖外部系统接口不稳定 +生产环境与测试环境配置差异 +流程风险 +测试用例设计遗漏关键场景 +缺陷管理流程不规范 +风险应通过风险登记册进行记录，包含以下信息： +风险ID、描述、类别、概率（高/中/低）、影响（高/中/低）、优先级、责任人、状态（开放/ +关闭）。 +示例： +ID +风险描述 +类别 +概率 +影响 +优先级 +责任人 +状态 +R01 +第三方支付 +技术风险 +中 +高 +高 +张某某 +开放 +接口响应超 +时 +6.2风险缓解策略 +针对已识别的风险，应制定优先级排序的应对措施，确保风险可控或影响最小化。宜采用风险矩阵 +对风险进行量化评估。风险评估方法见表2。 +表3风险评估矩阵表 +影响/概率 +高 +中 +低 +高 +紧急处理（PO) +高优先级（P1） +中优先级(P2） +中 +高优先级(P1) +中优先级（P2) +低优先级(P4) +影响/概率 +高 +中 +低 +低 +中优先级(P2) +低优先级（P3） +观察（P4) +根据风险评估结果使用风险应对策略对风险进行处理，风险应对措施见表3。 +表4风险应对措施表 +策略类型 +定义与实施方法 +适用场景 +风险规避 +通过调整计划或方案避免风险发生。 +替换不稳定的第三方组件。 +风险减轻 +采取措施降低风险发生概率或影响。 +增加性能测试覆盖关键接口。 +风险转移 +将风险转移至第三方（如外包、保险）。 +外包高复杂度模块的开发与测试。 +风险接受 +明确接受风险后果，并制定应急计划。 +低影响且处理成本过高的风险。 +附录A +（资料性） +测试技术分类 +测试技术分类见表A.1。 +表A.1测试技术分类表 +测试技术分类 +测试技术名称 +简要说明 +基于规格说明的 +等价划分 +将输入数据划分为等价类，每个类选取代表性值进行测试，减少 +测试设计技术 +冗余用例。 +（黑盒测试) +边界值分析 +针对输入或输出的边界值设计测试用例，验证系统在边界条件下 +的行为。 +分类树法 +通过树状结构对输入条件进行分类组合，生成系统化的测试用例。 +决策表测试 +基于条件与动作的组合关系，覆盖所有逻辑组合的测试用例。 +场景测试 +模拟用户实际业务流程，验证系统在端到端流程中的表现。 +状态转换测试 +测试系统在不同状态间的转换逻辑，覆盖状态迁移路径和触发条 +件。 +因果图法 +分析输入条件与输出结果的因果关系，生成覆盖因果逻辑的测试 +用例。 +随机测试 +随机选择输入数据进行测试，常用于探索性测试或大规模数据验 +证。 +需求基测试 +根据需求文档直接设计测试用例，确保需求与实现的一致性。 +变异测试 +通过人为注入代码缺陷验证测试用例能否发现这些缺陷。 +基于结构的测试 +语句测试 +确保代码中每条语句至少执行一次。 +设计技术(白盒 +分支测试 +覆盖代码中所有分支的真假路径。 +测试) +决策测试 +覆盖代码中所有决策条件的真假组合。 +路径测试 +覆盖代码中所有可能的执行路径。 +数据流测试 +通过追踪程序中变量的定义、使用和销毁过程，验证数据在程序 +执行路径中的传递逻辑，并检测未初始化使用、冗余定义或资源 +泄漏等数据流异常。 +分支条件组合测 +覆盖分支中所有条件的可能组合。 +试 +修改条件/决策 +确保每个条件能独立影响决策结果，满足高安全性系统的覆盖要 +覆盖（MCDC) +求。 +错误猜测 +依赖测试人员的经验，猜测系统中可能存在的缺陷并针对性设计 +经验导向的测试 +用例。 +测试技术分类 +测试技术名称 +简要说明 +检查表 +使用预定义的检查项（如常见错误列表）指导测试设计，确保覆 +盖关键点。 +设计技术 +历史数据分析 +基于历史缺陷数据或用户反馈，识别高风险模块并针对性设计测 +试。 +附录B +(资料性） +常见测试工具 +常见测试工具及用途见表B.1。 +表B.1 +测试工具 +测试工具 +途径分类 +备注 +编写测试大纲编写需 +Excel +求对比编写测试用例 +使用Excel本地编写，使用SVN进行测试设计保存 +Xmind +编写脑图 +使用Xmind本地编写，使用SVN进行测试设计保存 +昆仑智联 +编写测试用例及管理 +使用统一开发平台编写用例及管理 +Selenium、Appium +功能测试工具 +这些工具用于验证系统或应用程序的功能是否正确实现。可以模拟 +用户操作来测试Web应用程序和移动应用程序的功能 +Selenium、Appium +自动化测试工具 +这些工具可以自动执行测试用例，模拟用户操作来验证软件的功能， +可以用于自动化Web应用程序和移动应用程序的测试 +JMeter、LoadRunner +性能测试工具 +这些工具用于评估软件的性能，如响应时间、吞吐量、资源利用率 +等。可以用于执行负载测试和压力测试 +这些工具用于检测软件中的安全漏洞和风险。可以用于执行漏洞扫 +OWASP ZAP、Nessus +安全测试工具 +描和渗透测试 +SonarQube、FindBugs +这些工具通过分析代码来检测潜在的错误、漏洞和质量问题。可以 +静态代码分析工具 +用于检测代码中的缺陷和违反编码规范的问题 +JIRA、TestRail +测试管理工具 +这些工具用于管理测试活动，包括测试计划、测试用例、测试执行 +和缺陷跟踪等。可以用于管理测试过程和团队协作 +Cobertura、Jacoco +这些工具用于测量代码的测试覆盖率，帮助确定哪些部分的代码没 +覆盖率分析工具 +有被测试覆盖到。可以用于生成代码覆盖率报告 +Mockito、WireMock和 +环境模拟工具 +适用于接口测试、依赖隔离、数据驱动测试。模拟外部依赖（如Mo +Faker +ckito、WireMock）或生成测试数据（如Faker）。 +附录C +（资料性） +软件测试设计示例 +下面的示例来自于软件测试设计的一种文档形式。这个示例并不意味着本文件对其他种类的软件适 +用性有任何的限制。 +C.1测试设计规格标识符 +XSGW.TD.001 +20XX年4月14日 +C.2测试设计方法细化 +借助思维导图可以进行启发式测试设计并可视化承载设计过程。思维导图的编写不是只在测试设计 +阶段完成的，而是一个逐级细分的过程，思维导图的设计从测试的特性入手，一层一层地分解，直至最 +终输出测试用例，这体现了从整体到局部逐渐细化、具体的思维方式。 +C.2.1填写说明 +a）思维导图绘制说明 +1）定义：思维导图是一种以图形化的方式展示信息和思维结构的工具； +2）目的：帮助用户整理、理解和记忆信息，促进创造性思维和问题解决； +3）内容：思维导图通常包含一个中心主题，以及与之相关的子主题和分支； +4）结构：以中心主题为起点，子主题通过线条和连接词与中心主题相连，形成一个树状或网 +状结构。 +5）绘制步骤： +确定中心主题：选择一个核心概念或问题作为思维导图的中心； +· +添加分支：从中心主题开始，添加与之相关的子主题和分支； +●细化内容：在每个分支下添加更具体的细节和相关信息； +·使用关键词：使用简短的关键词来描述每个子主题和分支，避免过长的句子； +·利用颜色和图像：使用不同的颜色和图像来区分不同的主题和分支，增强视觉效果和 +记忆； +·连接关联：通过连接词或箭头来表示主题之间的关系和逻辑。 +b）思维导图绘制要求： +1）简洁明了：保持思维导图的简洁性和清晰度，避免过多的细节和文字； +2）结构合理：确保分支和子主题的层次结构合理，便于理解和阅读； +3）突出重点：使用颜色、字体大小或符号来突出重要的子主题和关键信息； +4）逻辑连贯：保持主题之间的逻辑连贯性，确保分支之间的关系清晰； +5）个性化：根据个人的思维方式和需求进行绘制，体现个人风格和特色。 +C.2.2思维导图模板 +思维导图模板见图C.1。 +功能测试 +业务场景 +分支场景 +功能点 +测试点1 +测试点2 +性能测试 +测试点 +安全测试 +测试点 +易用性测试 +测试点1 +测试设计思维导图模板 +测试点2 +兼容性测试 +测试点 +可靠性测试 +测试点 +可移植性测试 +测试点 +可维护性测试 +测试点 +图C.1 +测试设计思维导图 +C.2.3大纲笔记模板 +思维导图模板见图C.2。 +测试设计大纲笔记模板 +功能测试 +·业务场景 +·分支场景 +·功能点 +·测试点1 +·测试点2 +性能测试 +测试点 +安全测试 +测试点 +易用性测试 +测试点1 +测试点2 +兼容性测试 +·测试点 +可靠性测试 +·测试点 +可移植性测试 +测试点 +可维护性测试 +测试点 +图C.2测试设计大纲笔记图 +测试设计大纲笔记分级填写说明见表C.1。 +表C.1 +测试设计分级填写说明表 +层级 +填写说明 +要求 +中心主 +填写测试对象，应填写项目名称、模块名称或版本名称，以明确 +明确脑图的主题和中心思想 +题 +测试的具体范围。 +测试类 +选择适当的测试类型，如功能测试、性能测试、安全测试、兼容 +根据主题和中心思想，划分出主要的分支 +型（第- +性测试、可靠性测试、用户体验测试等。 +和子分支，形成清晰的层次结构。 +层级 +填写说明 +要求 +级） +业务场 +来自于产品设计报告，主要设计的是功能测试类型的业务场景 +按照产品设计报告的业务场景设计 +景（第二 +级） +分支场 +来自于产品设计报告，主要设计的是功能测试类型的分支场景 +按照产品设计报告的分支场景设计，测试 +景（第三 +人员要充分考虑分支场景，如产品设计报 +级） +告的分支场景考虑不全面需要与产品人 +员讨论决定 +功能点 +来自于研发需求 +功能点要覆盖所有研发需求 +（第四 +级） +测试点 +测试人员应考虑用户需求、系统规格和行业标准。测试点应明确、 +测试点要覆盖所有的需求 +（第五 +可重复和可度量，以便进行有效的测试和结果评估。通过识别测 +级） +试点，测试人员可以创建一个全面的测试计划，确保系统的质量 +满足预期的要求。 +C.3 +测试项标识 +分支场发] +8100件商 +上角址 +C.4测试通过准则 +为了通过这种测试，每种测试项（测试点）必须通过所有的测试用例。 diff --git a/assets/images/test/test_easy.txt b/assets/images/test/test_easy.txt new file mode 100644 index 0000000..e2dab1e --- /dev/null +++ b/assets/images/test/test_easy.txt @@ -0,0 +1,857 @@ +Q/SY KLD +昆仑数智科技有限责任公司企业标准 +QISY KLD +软 件 测 试 设 计 编 制 规 范 +Specification for software test design documentation +2OXX-XX-XX 发布 +2OXX-XX-XX 实施 +昆仑数智科技有限责任公司 +发 布 +目 ^次 +范圊. +2 规范饪引用文忤_ +3 木语和定义 +3.1 基崔,试 Benchmark Testing +3.2 MCDC 涸试 Modified ConditionlDecision Coverage。 +3.3 逼过准则 pass criteria。 +3.4 软件特征 software feature +3.5 趔试'盏 testcoverage +3.6 痧试设计 test design +3.7 趔试项 testitem +3.8 痧试目标 testobjective +3.9 WCAG 沅崔 Web Content Accessibility Guidelines。 +测试设计的结构: +测试设计耍求 +5.1 +测试设计说`标识符 +5.2 识别渺试颈 +5.3 涸试技术选择 +5.4 趣试'盏耍求_ +5.5 涸试项标识_ +5.6 趣试通过崔则 +风险浮估 +6.1 风险识别..一 +6.2 风险绥解策。 +(资料性) +测试技术分类 +(资料性) +常见测试工具 +(资料性) +较件测试设计示例 +C.1 P试设计规格标识符_ +C.2 +测试设计方法细化 +C.3 〈试项标识_ +C.4 涸试通过准则. +参考文献 +前 +言 +本文件按照 GB/T 1.1-2020 《标难化工作导则 +笫1部分: 标准化交件的结构和起草靓则》的规定 +起草。 +本文件是 Q/SY XXXXX +(〈 +笫 +部分。Q/sr XXXX 已经发布了以下部分: +部分: +K; +第2部分: +XXXXXXXXXXXXX。 +(分部分标谁应有此段描述 +只写出己经岌布的 +没有发布的可在引言中描述。) +本交件由数宁和信息化管理部提出。 +(信息标睢提出单位兴可以是 +数字和信息化管理部" 或 中囤石油天然集团有限公司标准化委 +员会信息技术专业标谁化技术委员会 +本文件由中囤石油天然巢团有限公司标准化委员会信息技术专业标准化技术委员会归川。 +本交件起草单位: 数宁和信息化筐理部 +共亨运菅公司 +勘探开发研究院。昆仑数智 +(起草单位写到局级单位且为简称 (在每牟标稚制修订计划中有简称, +可查询1 +应与绢制说明中 +的单位对应 +~致 +巢团公司企业标稚至少应由3个局级单位共同起草) +本文件主婴起草人: +XXX +XXX +(专蒙申查会之前 +起草人应确定。排名顺序应按照编写标稚的贡献程度排名。) +本文件主婴审查人: +XXX +XXX。 +范围 +本文件规定了基本的软件浏试设计交裆的袼式和肉容婴求 +本文件适用于软件测试过程中软件设计的编写工作。 +规范性引用文件 +下列文件中的肉容通过文中的规范。引用而构成本交件必不可少的条款。其中 ,注日期的引用文件 +仅该月期对应的版本适用于本文件; 不注日期的引用文件 +其最新版本 (包括所有的修改单)适用于本 +文件。 +GBIT 15532-2008 计算机软件测试靓范 +GB T 9386-2008 计算机软件测试文档编制规范 +GBIT 38634.4-2020 系统与软件工程 软件测试 笫4部分: 测试技术 +术语和定义 +GBIT 11457 中确立的以及下列术语和定义适用本标准。 +基准测试 Benchmark Testing +通过运行标谁化浏试程序或场景 +评估系统。组件或软件的性能;效率及稳定性。为后续优化或比 +较提供数据依据。 +32 +MCDC 测试 Modified Condition /Decision Coverage +MCDC 测试 +Modited +Condition/Decision Coveroge (修改条件 /袂策覆盖浏试) 是一种甚于结构的 +白盒浏试技术 +旨在验证代码中每个逻辑条件对整体袂策结果的独立影响能力。 +3.3 +逋过准则 +pass criteria +判瓯 +`软件项或软件特征的测试是否通过的判别依据。 +3.4 +软件特征 software feature +软件项的品著特。 (如功能。。能或可移植性) +35 +测试覆盖 test coverage +给定的测试或浏试巢。对于给定的系统和部件实琬所有规定的需求的程度 +3.6 +测试设计 test design +种交裆。它靓定对软件特性或软件特性与标识相关测试的组合的详细测试方法。解袂测什么怠 +么测的问题。 +3.7 +测试项 test item +测试点 +是浏试目标的软件项。 +3.8 +测试曰标 test objective +在规定的条件下婴量度的软件特。的标识巢,它由把时间行为与在软件文档牛描逑的所婴求的行为 +进行比较来量度。 +39 +WCAG 标准 +Neb Content Accessibility Guidelines +ICAG +(Web Content Accessibility Guidelines +Web内容无障碍指南) 是由厅维网联盟 +〈IC〉 制 +定的国际标准,旨在确保残障人士能够平等访问利使用网络肉容。其核心目标是消除数字环境中的障碍 +帮助视觉。听觉。运动或认知障碍用户通过辅助技术 (如屏:阅读器) 与网页交互。 +测试设计的结构 +浏试设计应有如下肉容和结构: +测试逡计说明标识符; +识别测试项; +测试设计方祛细化 (技术选择。覆盖婴求) +浏试顷标识:; +软件特征测试通过璀则。 +测试设计要求 +5.1 +测试设计说明标识符 +为该测试设计说明规定唯一的标识符。如果在相关的测试计划中有规定。则应引用。 +52 +识别测试项 +5.2.1 +测试项来源与范围定义 +浏试项是浏试目标的软件项。测试项需基于需求文档。设计文档及风险分析报告等文件进行挺取和 +识别。其体包括: 功能需求。性能指标 +安全约束。兼容性婴求。可靠性婴求。易用性婴求。可维护性 +婴求。可移植性婴求等。 +在浏试过程中 +应明确测试顼的层级与类型: 层级分为楔块级。系统级和接口级; 类型包括功能测 +试。性能测试 +安全性测试及兼容性测试等。同时 +应明确定义排除项并说明排除理由,以确保测试范 +围的透明。。 +5.2.2 +测试项识别方法 +浏试项的识别需结合系统需求。设计文档及风险分析,提取软件特性牛可测试属性。以下是其体方 +法: +甚于需求的分解法 +功能特征识别: 通过逐条分析需求交裆 (如用户故事。需求靓格说明书) +挺取功能点并 +分解成测试项; +示列: 通过需求描述 +系统应支持用户密码修改" +提取特征 +密码修改功能 +包括输 +入苡验 +加密存储等子待征 +最终形成测试项。 +非功能特征识别: 从性能。安全性等非功能性需求牛提取可量化指标。 +示例: 啊应时间<2秒。并发用户数 = 1000 人。 +基于设计的结构分解法 +1) 架构与模块分解: 根据系统设计交档 (如架构倒。模块说明书) +识别各组件接八。 数据 +沉及依赖关系 +确定需浏试的浏试项; +示例1: 根据系统的功能特性。将其拆分为不同的功能模块,如登录棋块。搜索槟块。购物车 +模块等 +每个功能模块可独立进行测试; +示例2: 版本拆分: 裉据项目规划的版本进行拆分 +个版本的功能可独立进行测试。 +代码分祈: 通过代码走查或工具识别关键逻犋分支。异常处理路径等结构测试项; +对于8形用户界面系统,可以将界面元素拆分为不同的组件,如按钮。文本框。下拉框等。 +每个界面元紊可单独进行浏试; +裉据数据在系统牛的沉动路径进行拆分, 从输入到处理再到输卅。可以针对数据的输入 +处理和输出进行浏试。 +用户场景分解法 +沉程倒: 通过活动8或业务沉程图= +识别端到端场景牛的关键测试项。 +示例: 按麒业务流程的顺序将系统拆分为 +系列步骤或阶段 +如订单处理流程。客户f册流 +程等。每个业务流程可以独立进行测试。 +角色-功能矩阵: 按不同用户角色 (如管理员。普通用户) 划分权限,根据权限进行测试。 +甚于风险的优先级划分 +风险矩阵评估: 结合历史缺陷数据。用户场景虿婴性。对软件特征进行风险评级。优先识 +别高风险的软仵特征进行浏试; +失效模式分析: 针对关键棋块。分析潸在失效点 (如数据库连瘘失败) +转化为需验证的 +测试项。 +行业标雄与法规符合性检查 +裉据罔家法规或行业标准识别强制测试项。 +示例: 根据 《中华入民共和国个人信息侃护法》和 《GB/T 22239-2019 信息安全技术 网络安 +全等级保护基本婴求》 +识别强制测试项: +用户个入敏感信息数据应加密存储 +5.3 +测试技术选择 +浏试技术选择应基于被浏对象的特性。需求明确性。测试阶段目标。资源约束及风险等级等因素综 +合评估 +主婴浏试技术见附录A2 +5.3.1 +技术选择原则 +需求明确性 +箫求消晰时应优先使用毖于规格说明的放术,如: 等价划分。袂策表; +需求模猢时宜使用基于经验的技术和探索性测试。 +系统复杂度 +逻犋复杂或条件组合多时,采用组合测试或困果8法; +状态依赖型系统优先选择状态转换测试。 +资源与风险 +资源充足时。采用组合测试或 MC/DC 提高爵盖宰; +高风险模块需综合多种技术,如: 边界值+错误猜测+诀策表的测试组合。 +5.3.2 +测试技术分类及核心目标 +基于规格说明的测试技术 (黑盒测试) +甘标: 验证系统行为是否符合需求规袼说明 +关注输入与输出[正确。。 +适用场景: 需求交裆明确。功能逻辑复杂或需覆盖用户场景的浏试阶段。 +典型技术: +等价划分: 输入域存在明确分组规则时 (如合祛/非法值) +边界值分析: 输入输出存在数值 围或边界条件时; +决策表测试: 多条件组合触发不同业务靓则时; +状态转换测试: 系统行为依赖状态迂移; +场景测试: 馍拟用户端到端业务沉翟。 +基于结构的测试技术 (白盒测试) +目标: 验证代码逻辑的完整性和健壮。。提升代码爵盖率。 +适用场景: 单元测试。粜成测试或需深度验证代码逻辑的场景。 +典型技术: +语句/分支测试: 需覆盖代码基本执行路径肘; +MCIDC 测试: 高安全性系统需满足严格覆盖谁则时; +数掂沉测试: 检测娈量定义与使用异常'时 +基于经验的测试孜术 +目标: 利用浏试人员经验补充系统化设计的自区。 +适用场景: 需求棋糊。时间紧迫或需探索潸在缺陷的场景。 +典型技术: +错误猜测: 依赖历史缺陷棋式或领域知识推测易错点; +检查表: 使用预定义的检查项指导测试设计 +确侏覆盖关键点 +5.3.3 +技术组合策略 +分层覆盖: 在单元测试中采用白盒技术确保代码质量。在系统测试中通过黜盒技术验证功能完 +整。。 +互补增强 +针对关键功能应使用边界值分析和锴误猜测的组合测试; +2)针对多条件交互功能应使用诀策裘和分支条件组合等进行组合测试。 +迭代优化: 裉据测试结果动态调整放术,当发现分支覆盖不足肘应补充分支条件组合测试。 +5.4 +测试覆盖要求 +浏试'盖婴求的制定应与软件质量特性紧盥结合 +并明确颞盖的度量方法与实施婴求。 +5.4. +结合质量特性的覆盖要求 +浏试覆盖邀诮需结合浏试技术分类 (基于规袼说明。结构。经验) 进行设计 +具体爵盖类型如下: +5.4.1.1 +功能测试覆盖要求 +需求覆盖 +应建立需求追踪矩阵 (RTN) +确保每个需求对应的功能孕少被 +个测试用例'盖 +测试 +用6应涵盖所有预期功能和边界条件: +应标识需求的优先级,高优先级需求对应的功能应实现 100%覆盖。 +业务流程覆盖婴求 +应覆盖所有主流程和分支流程; +应测试覆盖异常沉程的处理; +应验证端到端的业务沉翟 +交互覆盖 +应覆盖所有页面元紊 (按钮。表单。弹窗。导航) 的交互行为; +应测试覆盖响应式设计的适配性,包括屏幕尺寸。分辨率。横竖屏方向等。 +接口覆盖翌求: 应覆盖验证系统肉外接十 +(API, 协议。数据格式)的输入/输出及异常处理。 +权限覆盖婴求 +覆盖所有用户角色的功能权限 (如管理员增删改查, +普通用户仪查询) +应验证杈限娈更的实时性。 +甚于结构的测试覆盖 +语句/分支测试: 应覆盖代码基本执行路径; +MCIDC 测试: 高安全性系统应满足严格覆盖谁则; +数据沉测试: 应检测娈量定义与使用异常。 +基于规格说明的测试技术覆盖费求 +此类覆盖关注需求或功能规格说明的覆盖程度。适用于黑盒测试: +竽价划分: 测试用例需覆盖所有有效和无效等价类,确保每个类孕少有一个用例; +边界值分析: 应覆盖输入域的边界值,如: 最小值。最人值。骼超卅边界的值; +袂策表测试: 应覆盖袂策表牛所有条件组合对应的动作; +状态转换测试: 应覆盖所有状态转移路径,包括合祛转移和非法触发; +场景测试: 应覆盖用户场景牛的所有关键路径和异常分支。 +5.4.1.2 +性能测试覆盖要求 +负载范围覆盖 +宜裉据毖准测试结果,设计 50。80%。 100%。120%凹种不同级别的负载浏试; +宜对每种负载级别持续运行足够时间以观察系统稳定性; +宜模拟突发沉量场景。测试系统对沉量突增的应对能力。 +网络环境覆盖 +宜覆盖.36/46/56 /Wi Fi 等多种网络环境,保证高延迟下功能正常; +应测试网络圳换时的系统表现= +5.4.1.3 +安全测试覆盖要求 +漏洞扫描'盖 +所有代码应进行鹳态安全扫描; +系统卜线前 +宜对系统进行动态安全扫措; +系统卜线前。宜对系统执行渗透测试。覆盖所有对外暴露的瘘1。 +数据安全覆盖 +应验证敏寇数据 (如密码。身份证号) 加密存储和传输的情况。 +杈限覆盖 +应测试覆盖所有角色的权限分配情沉; +应测试杈限娈更后的郎时生效情况。 +合规覆盖 +应审计所有安全日忐的记录和存储情沉; +应验证系统是否符合相关祛律。法规的婴求。 +5.4.1.4 +兼容性测试覆盖雯求 +浏览器覆盖 +应选择 Chrome / Firefox /Safori / Edge 中牵少2 个最新版本进行覆盖浏试; +宜测试浏览器插件和扩展的影响。 +移动端覆盖: 应选择主流移动设备厂商的不同型号进行覆盖测试; +分辨率覆盖 +应覆盖 +108Op/2K/4K 及全面屏; +应测试不同 DPI 设置下的显示效果; +宜测试覆盖全面屏。刘海屏等特殊屏幕形态。 +操作系统覆盖: 苴对操作系统的不同版本进行覆盖。 +安装卸载测试 +应验证模拟常见的安装错误,如空间不足。权限不足。网络牛断等 +应检查软件卸载是否彻底; +应确认软件安装后是否正常。 +5.4.1.5 +可靠性测试覆盖要求 +压力边界覆盖 +应测试超过设计容量50%的负载情况; +应测试资源耗尽情况下的系统行为。 +容错覆盖 +应模拟测试网络牛断。服务崩溃。醯盘满等异常场景; +应验证降级策骼的有效性。 +恢复覆盖 +72Opi' +应测试数据库崩溃后的恢复沉程; +应验证备份数据的完整性和可用性。 +5.4.1.6 +易用性测试覆盖要求 +核心,径覆盖 +应测试新手用广的首次使用悴验情况; +宜验证操作步骤的最简化程度。 +多语言覆盖 +应测试日期 +时间。货币等本地化内容; +应测试系统所有支持语言的显示效果。 +5.4.1.7 +可维护性测试覆盖要求 +月志覆盖 +应确保所有关键操作都有日忐记录; +应验证日忐信急的完整性和可读性。 +文档覆盖 +应验证系统 API 交裆的完备性; +应验证系统部署手册的完备性; +应验证系统故障处理指南的完备性。 +5.4.1.8 +可移植性测试覆盖雯求 +宜酶保系统能在不同环境 (云。容器。物理机) 中部署利运行; +宜覆盖依赖琐。配置。数据迂移的兼容性。 +5.4.2 +覆盖的实施要求 +分层覆盖管理: +单元测试: 代码结构覆盖为主,语句覆盖萃 = 90% +分支覆盖率 =80% +贷成测试: 瘘川测试验证所有输入/输出瘘川及交互协议 +应覆盖正常与异常场景; +系统测试: 需求功能覆盖应达到 IO0% +场景覆盖核心业务流程。 +高风险模块增强覆盖: 对高优先级需求或复杂模块。应采用多技术组合测试,挺高覆盖率。 +自动化支持: 宜使用自动化工具实现覆盖率动态监控,如: 代码覆盖率工具。需求跟踪工具。 +对未覆盖项生成告瞥并触发测试用列补充机制 +5.4.3 +覆盖的合规性要求 +浏试'盖的合规性应潢足以下婴求: +可逍渊性: 测试用例与需求。代码或风险的关联关系应通过需求跟踪矩阵 +(RTM〉 记录; +可虿复性: 覆盖率度量方法应标准化。确保不同测试周期或团队的结果 +~致性; +透明度: 测试报告中应明确说明」盖目标。实际结果及未覆盖项的潸在影响; +适应性: 覆盖标难应根据琐甘变更动态调整。 +5.5 +测试项标识 +列出与该设计有关的每一个浏试项的标识并简婴描述。浏试项列表示列见表 + +表1 +浏试项示例表 +序号 +测试项描述 +测试项代码 +有效的小数点。舍4个小数位的前导点 +NNETC.040 +有效的小数点。含 +个小数位的嵌人式点 +NNETC.041 +有效的小数点。舍0个整数的尾部点 +NNE TC.042 +无效的小小数点, +个小数位 +NNE TC 050 +无效的小小数点, +个点 +NNETC 051 +无效的小数点。没有数字的点 +NNETC 052 +5.6 +测试逋过准则 +给出用于判定软件特征或软件特征组合是否通过或失败的谁则。 +明确判定依据 +定义通过或失败酌具体条件。包括但不熨于: +功能正确性: 功能模块的输入与输出必须与需求文档定义的预期结果一 +~致; +性能指标: 响应时间。吞吐量。资源占用率等需满足预设阈值; +兼容性要求: 功能需在指定的操作系统。浏览器。设备或版本范围内正常运行; +容错能力: 对异常'输入,非法撰作或极端场景需具备合理处理机制 +量化或定性标准 +量化标准: 提供可测量的指标,例如数值阈值 (响应时间=1秒) +定性标准: 描述可观察的行为或状态 +例如界面交互沉畅无卡顿。业务沉程完整无牛断。 +覆盖范围定义 +覆盖率费求: 在软件测试阶段, 应执行全部设计的测试用例,并提供执行记录; +通过率婴求: 关键功能 (如核心业务流程。安全模块) 的测试用列应 100通过; 非关键 +功能的测试用例通过率不低于 95% ,未通过用例应评估影响范围并在测试报告中明确标注。 +通过谁则豁免 +任何倌离卜述准则的情况需经|级审批,并在发布说明中明确标社。 +风险评估 +风险识别 +风险识别是系统化发现可能影响浏试自标实现的内外部困素的过程,需覆盖妆术。管理。资源及环 +境等名维度风险。 +在软件浏试过程中 +风险评估是识别潸在威胁。分析其影响并制定应对策骼的核心环节,旨在降低 +浏试活动的不确定。。确保测试目标的达成。应颞盖技术。筐理。资源及环境等名维度进行风险识别 +风险来源分类见表1 +表2 +风险来源分类表 +风险类型 +典型风险示列 +氚冰氐险 +氚求不狩晰或颓綮变更 +风险类型 +典型风险示匆 +关键氚求透滴或优先级误判 +技术凤陀 +负茱箅祛实现缺陷 +笫三方纽件燕容性问酗 +代码质曷氐险 +数据氐险 +性能瓶颈或安全滴洞 +资源风险 +测试环境不足 +{如殃件 +工具缺兴1 +成本氐险 +人力短缺 +人员能力氐险 +人员技能不足 +测试人员对业务不熟悉造成的风险 +汕试人员可能对产品的功能不熟悉 +导致汕试不充分 +进度氐险 +开发延期导致汕试时间压缩 +缺陷修负周堋不可控 +环境氐险 +侬赖外部系练接[不总定 +生产环境与汕试环境配1差异 +浼镬风险 +汕试用例设计遗漏关键场景 +缺陷笞理浼[不规范 +风险应通过风险登记册进行记录 +包含以下信息: +风险 ID。 描述。类别 +概率 (高/中/低) +影响(高/中/低) +优先级。责任人,状态〈开放1 +关闲) +示列: +风险描还 +类别 +概率 +影响 +优先级 +责任人 +怅态 +RO +第三方支付 +技术凤险 +张某其 +开放 +接口向应趱 +6.2 +风险缓解策略 +针对己识别的风险,应制定优先级排序的应对措施,确保风险可控或影响最小化。宜采用风险矩阵 +对风险进行量化评估。风险评估方法见表2 +表3 +风险评估矩阵表 +影响 /概率 +案急处理 +{P) +高代先级 (P) +中代先级 {P) +高代先级 +{P) +中代先级 +(P) +低优先级{04) +影响/概率 +中代先级 {P2) +低代先级 +{P3) +观察 +{4) +根据风险评估结果使用风险应对策略对风险进行处理 +风险应对措施见表3。 +表4 +风险应对措施表 +策略类型 +定义与实施方法 +适用场景 +氐险C避 +逋过调整计划或方案避免凤险发生。 +咎换不总定的笫三方组件。 +氐险减轻 +采-褙^降低凤险发生概率或影呐 +增加性能浏试焱盖关键接口。 +风险转移 +将氐险转移至笫三方 {如外包。保险) +外包高复"度愤珙的开发与训试 +风险接受 +明硇接受险后果。并制定应急计划 +低影啊且处理成本过高的}险 +录 ^ +(资料性) +测试技术分类 +浏试技术分类见表4.1 +表A.1 +测试技术分类表 +测试技术分类 +测试技术名称 +简耍说明 +基于规袼说明的 +等价划分 +将输入数据划分为等价类。每个类选取代表。值进行浏试, +喊少 +浏试设计技术 +冗佘用列。 +(黛盒浏试) +边界值分析 +针对输入或输出的边界值设计测试用列 +验证系统在边界条件下 +的行为。 +分类耐法 +通过树状结构对输入条件进行分类组合,生成系统化的测试用例c +袂策表测试 +基于条件与动作的组合关系 +歌盖所有逻辑组合的浏试用列 +场景测试 +棋拟用户实际业务流程。验证系统在端到端流程中的表现C +状态转换测试 +试系统在不同状态间的转换逻辑。歌盖状态迂移路径和触发条 +园果图法 +分析输入条件与输出结果的困果关系 +生成颞盖困果逡辑的测试 +用列。 +随杌测试 +随机选择输入数据进行浏试 +常用于探索。浏试或人规棋数据验 +需求毖测试 +根据需求交裆直接设计浏试用列 +确保需求与实现的- +~致。 +娈荞试 +通过人为茌入代码缺陷验证浏试用例能否发现这些缺陷。 +毖于结构的浏试 +语句浏试 +确保代码中每条语句至少 行一 +'次。 +设计技术(白盒 +分支浏试 +覆盖代码中所有分支的真假路径。 +浏试) +袂策测试 +颞盖代码中所有袂策条件的真假组合 +路径测试 +覆盖代码中所有可能的执行路径。 +数据流浏试 +通过追踪程序中娈量的定义。使用和销毁过程 +验证数据在程序 + 行路径牛的传递逻辑。并检测未初始化使用。冗余定义或资源 +泄漏等数据沉h常 +分支条件组合浏 +覆盖分支中所有条件的可能组合 +修改条件/袂策 +确保每个条件能独立影啊袂策结果。满足高安全。系统的歌盖叟 +爱盖 (ICDC) +依款浏试人员的经验 +猜浏系统中可能存在的缺陷并针对。设计 +经验导向的测试 +错误猜浏 +用列2 +测试技术分类 +测试技术名称 +简要说明 +使用预定义的裣查项 (如常见错误列表) 指导浏试设计。确保' +硷查表 +盖关键点。 +设计技术 +基于历史缺陷数据或用户反馈。识别高风险棋块并针对性设计测 +历史数据分析 +录 +(资料性) +常见测试工具 +常见浏试工具及用途见表B.1c +表B1 +测试工具 +测试工具 +途径分类 +备注 +编写汕试犬纲编写需 +Pce] +使用 Fxccl 本地编写 +使# SVN 进行浏试设计保存 +求对比编写泄试用例 +Amind +绢写腑图 +使用 Xmind 术地编写 +馍川 sI +进行刘试没计垛存 +昆仑智联 +编写测试月例及管理 +使用统一开发平台编写用例及管理 +这些工具用于验证系练或应用毽序的功能定否正硇实现。可以榄拟 +Selenum; +Appium +功能测试工具 +用户操作来泄试 Wch 应用程序和咨动应用程序的功能 +这些工其可以自动执行训试用例。榄拟用户操作来验证软件的功能_ +Selenum, Appium +自动化训试工具 +可以用于自动化 Wcb 应用程序和移动应用程序的测试 +这些工具用于评估软件的性能 +如帕应时阃 +吞吐量。资源利用率 +INter +LTIInn +性能浏试工其 +可以用于执行负载汕试压力汕试 +这些工具用于检训软件中的安全漏洞和瓦险。可以用于执行漏洞扫 +OWAsp 7AP +Lessus +安全洲试工其 +描和$透洲试 +这些工具通过分析代码来检汕潜在的错误。漏洞和质量问鼬。 +可以 +Sonarcuh +PindBugs +萨态代码分斫工具 +用检测代码中的缺陷和违反编码规范的问鼬 +这些工具于管理泄试活动。包括测试计划。泄试用例 +测试执行 +JTRA, TestRal +汕试莒理工具 +和缺陷踉踪等 +可以用于管理测试过篷和困队协作 +这些工其用于洲量代码的训试炭盖率 +帮助硇定哪些部分的代码^ +Cohrturo。 +Ioco +f盖率分析工具 +有被泄试褴盖到。可以用于生成代码褴盖率报告 +Mrkito +Tire Wlock: 秆 +适用于接日泄试。依赖隔离。数据驱动浏试 +惯拟外部依赖 (如 Mo +环境愤拟工其 +Fakc +CKITO。 +KrcMock) 或生成汕试数据 {如 Raker) +录 +(资料性) +软件测试设计示例 +下面的示列来自于软件浏试设计的一种文档形式。这个示例并不意味眷本文件对其他种类的软件适 +用性有任何的限制。 +C1 +测试设计规格标识符 +XsGITDOol +208牛44148 +C2 +测试设计方法细化 +借助思维导囹可以进行启发式测试设计并可视化承载设计过程。思维导倒的绢写不是只在测试设计 +阶段完成的,而是 +-个逐级细分的过程 +思维导8的设计从测试的特性入手, 一层一层地分解。苴孕最 +终输出测试用列。这体珧了从整体到局部逐渐细化。具体的思维方式。 +C2。 +填写说明 +思维导图绘制说明 +定义: 思维导8是一种以8形化的方式展示信息和思维结构的工具; +目的: 帮助用户整理。理解和记忆信息,促进创造性思维和问题解决; +内容: 思维导图通常包含一 +个牛心主题 +以及与之相关的子主题和分支; +结构: 以中心主题为起点,子主题通过线条和连接词与中心主题相连。形成 +个树忧或网 +状结构。 +绘制步骤: +确定牛心主题: 选择一个核心慨念或问题作为思维导图的4心; +添加分支: 从中主题开始,添加与之相关的子主题和分支; +细化内容: 在每个分支下添加更具体的细书和相关信息; +使用关键词: 使用简短的关键词来描逑每个子士题和分支 +避免过长的句子; +利用颜色和图像: 使用不同的颜色和囹像来区分不同的芏题和分支,增强视觉效果和 +记忆; +连接关联: 通过连接词或箭头来表示主题之间的关系和透辑。 +思维导倒绘制婴求: +简洁明了: 保持思维导8的简洁性和潸蜥度,避免过多的细节和交字; +结构合理: 确保分支和子芏题的层次结构合理,便于理解和阅读; +突出巫点: 使用颜色。字人小或符号来突4垂要的子主题和关键信息; +逻犋连贯: 保持芏题之间的逻辑连贯性,确保分支之间的关系消晰; +个性化: 裉据个人的思维方式和需求进行绘制,体现个人风格和特色。 +C22 +思维导图模板 +思维导图祺板见图C.1 +`士点' +功;试 +业寻坯髻 +分支髻 +功#豆 +T|57 +性e剥试 +厕试 +安全 +叫讧 +Tutsl +S用au +测试设计思维导罔楔扳 +饔武总2 +菲弃什呙1 +&试- +可靠性 +D讨- +可移咱性Q试 +蹰芷点 +可堆垆饪西试 +图C。 +测试设计思维导图 +C2.3 +大纲笔记模板 +思维导囹棋板见囹C.2。 +测试设计大纲笔记模板 +功能测试 +业场| +分支场景 + +功能点 +测试点1 +测试点2 +性能测试 + +测试点 +安全测试 +测试点 +易用性测试 +测试点1 +测试点2 + +兼容性测试 +测试点 +可靠性测试 +测试点 +可移植性测试 + +测试点 +可维扩性测试 +测试点 +图C2 +测试设计大纲笔记图 +浏试设计人纲笔记分级填写说明见表C.1。 +表C1 +测试设计分级填写说明表 +层级 +填写说明 +要求 +4 +填写洲试对象 +应填写琐目名称。榄块名称或版耷名称。以明砌 +明硇脑倒的辛鼬和中思想 +浏试的其体范围 +测试类 +选择适当的测试炎型 +如功能浏试。性能浏试。安全测试。[容 +根据宅鼬和中心思想。划分出扌婴的分支 +型 (笫 +性汕试。可靠性汕试。用户体验汕试等 +和了分支。形成`晰的县次结沟。 + + + + + + +层级 +填写说明 +要求 +业务场 +来自干产品设计报告 +壬婴设计的是功能泄试炎型的业务场景 +按麒产品设计报告的业务场景设计 +昙 (笫 +分支场 +来自于产品设计报告。a婴设计的定功能浏试炎型的分支场景 +按麒产品设计报告的分支场景设计。浏试 +昙 (笫三 +人员婴充分考毖分支场景。如产品设计报 +告的分支场景考毖不全面氚婴与产品人 +员讨论洪定 +功能点 +来自于砑发氚求 +功能点婴C盖斫有研发氚求 +[笫四 +洲试点 +测试人员应考毖用户嵛求。系统规格和行业标摧。汕试点应明确 +试点婴褴盖所有的箭水 +笫五 +可虿反和可度量。以便进行有效的测试和结柴评估。逋过识别测 +试点 +测试人员可以创建 +全面的浏试计划。砌保系统的质量 + 足预期的婴求 +C3 +测试项标识 +C.4 +测试逋过准则 +为了通过这种浏试。每种浏试项(浏试点) 必须通过所有的浏试用匆 +o』「] diff --git a/assets/images/test/截屏2025-04-30 17.02.52.png b/assets/images/test/截屏2025-04-30 17.02.52.png new file mode 100644 index 0000000..087a61c Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.02.52.png differ diff --git a/assets/images/test/截屏2025-04-30 17.02.57.png b/assets/images/test/截屏2025-04-30 17.02.57.png new file mode 100644 index 0000000..147110b Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.02.57.png differ diff --git a/assets/images/test/截屏2025-04-30 17.03.03.png b/assets/images/test/截屏2025-04-30 17.03.03.png new file mode 100644 index 0000000..f29d953 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.03.03.png differ diff --git a/assets/images/test/截屏2025-04-30 17.03.13.png b/assets/images/test/截屏2025-04-30 17.03.13.png new file mode 100644 index 0000000..7a42519 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.03.13.png differ diff --git a/assets/images/test/截屏2025-04-30 17.03.22.png b/assets/images/test/截屏2025-04-30 17.03.22.png new file mode 100644 index 0000000..1f86a28 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.03.22.png differ diff --git a/assets/images/test/截屏2025-04-30 17.03.30.png b/assets/images/test/截屏2025-04-30 17.03.30.png new file mode 100644 index 0000000..a8a211e Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.03.30.png differ diff --git a/assets/images/test/截屏2025-04-30 17.03.38.png b/assets/images/test/截屏2025-04-30 17.03.38.png new file mode 100644 index 0000000..7563351 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.03.38.png differ diff --git a/assets/images/test/截屏2025-04-30 17.03.47.png b/assets/images/test/截屏2025-04-30 17.03.47.png new file mode 100644 index 0000000..2da8356 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.03.47.png differ diff --git a/assets/images/test/截屏2025-04-30 17.03.55.png b/assets/images/test/截屏2025-04-30 17.03.55.png new file mode 100644 index 0000000..1ee55bc Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.03.55.png differ diff --git a/assets/images/test/截屏2025-04-30 17.04.05.png b/assets/images/test/截屏2025-04-30 17.04.05.png new file mode 100644 index 0000000..fbde37c Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.04.05.png differ diff --git a/assets/images/test/截屏2025-04-30 17.04.14.png b/assets/images/test/截屏2025-04-30 17.04.14.png new file mode 100644 index 0000000..d48ed32 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.04.14.png differ diff --git a/assets/images/test/截屏2025-04-30 17.04.22.png b/assets/images/test/截屏2025-04-30 17.04.22.png new file mode 100644 index 0000000..b535e95 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.04.22.png differ diff --git a/assets/images/test/截屏2025-04-30 17.04.30.png b/assets/images/test/截屏2025-04-30 17.04.30.png new file mode 100644 index 0000000..6ceac6d Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.04.30.png differ diff --git a/assets/images/test/截屏2025-04-30 17.04.46.png b/assets/images/test/截屏2025-04-30 17.04.46.png new file mode 100644 index 0000000..0d24240 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.04.46.png differ diff --git a/assets/images/test/截屏2025-04-30 17.04.51.png b/assets/images/test/截屏2025-04-30 17.04.51.png new file mode 100644 index 0000000..39639b8 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.04.51.png differ diff --git a/assets/images/test/截屏2025-04-30 17.05.02.png b/assets/images/test/截屏2025-04-30 17.05.02.png new file mode 100644 index 0000000..bd838e3 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.05.02.png differ diff --git a/assets/images/test/截屏2025-04-30 17.05.15.png b/assets/images/test/截屏2025-04-30 17.05.15.png new file mode 100644 index 0000000..bfa3faa Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.05.15.png differ diff --git a/assets/images/test/截屏2025-04-30 17.05.22.png b/assets/images/test/截屏2025-04-30 17.05.22.png new file mode 100644 index 0000000..2c3ace4 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.05.22.png differ diff --git a/assets/images/test/截屏2025-04-30 17.05.31.png b/assets/images/test/截屏2025-04-30 17.05.31.png new file mode 100644 index 0000000..0ffbed6 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.05.31.png differ diff --git a/assets/images/test/截屏2025-04-30 17.05.39.png b/assets/images/test/截屏2025-04-30 17.05.39.png new file mode 100644 index 0000000..6310804 Binary files /dev/null and b/assets/images/test/截屏2025-04-30 17.05.39.png differ diff --git a/readne.md b/readne.md new file mode 100644 index 0000000..e69de29