OTHERS.md · ywtnhm/auto-Api

## 杂谈
#### API 基本模型
##### API 的分类
1. 获取信息API： 这类API不会对服务器上的任何数据进行修改，仅用于获取数据，是比较方便测试的一种
2. 修改信息API： 这类API会对服务器上的数据产生修改，可能也会获取些数据，比较难于确认的测试

##### url 路由
url 里面可能带有参数等信息，本项目目前并不考虑这个情况。

所以本项目目前仅支持简单url(仅作路由用)的api的自动化测试

但对于复杂url路由的情况，也支持简单的回放测试

##### header 请求头
其中包含安全和环境有关的信息

请求头内的信息由标准确定，主要测试权限，围绕cookie(角色)的切换

##### data 参数
请求附带的请求参数，比如form表单

其抽象格式为：(key:value)对

api的参数可以有一下的分类(本项目可以自动化的构建一下分类的相关信息)

1. 必选参数，可选参数，n个可选参数必选一个
2. int,float,str,bool 这些基本类型 list,dict 列表，字典类型
3. 用户来源，api中间沟通，校验
    1. 用户来源 ： 这个参数的具体内容由用户决定，其具体又有 有限 和无限之分。有限 指参数的值是有限的。无限 指 这个参数完全由用户提供的内容，比如 评论的内容 等
    2. api中间沟通 ： 比如 文章的id ，这由 文章列表 这个api 提供文章id列表，之后文章详情通过列表内的id访问完整的内容
    3. 校验 : 参数用于安全校验或者由系统决定

##### 返回值(json)
本项目目前仅支持 json 格式的api校验

返回值有以下分类:
1. 元数据(返回码) ，消耗数据(用户界面展示，并不作为参数发回)，通道数据(将发回给服务器) 
2. int,float,str,bool 基础类型，list,dict 列表和字典类型
3. 校验参数，用于客户端验证服务器

#### 构建黑盒api模型的方法
1. 将相同的url请求认为是一个api,通过对参数出现的情况初步判断是否为必要参数
2. 将所有的api请求中相同的返回结果路由(比如状态码)保存，需要人工设定有效请求和无效请求和逻辑(正则表达式)
3. 程序摸索式测试请求参数的额外信息(必要参数是否真实有必要，可选参数是否是几种可选参数里面必须选择一个)

## 黑板模式
对API模型的理解并不能完全通过历史记录来确定，可能需要一切其他辅助信息或者是试验。
系统将一些需要额外解答的问题自动生成出来，并记录在`黑板` 上，这个黑板可以给任何实体查看。包括第三方系统和人类。
系统可以通过`计算流`自动化解答问题（`计算流`参考下一节内容）。
当任何实体(第三方系统或者人类)对问题进行解答，那么API模型将会自动的根据问题进行更新，以达到不断准确的目的。

第三方系统可以是原始文档的解析器，将原始文档进行解析，然后获取答案，快速自动解答新文档中的问题。

## 计算元构建理解算法
#### 概述
对某个问题进行自动解答的小脚本，而回答这些问题具有一些相似的内容。在系统中，将这些相似的内容总结为一块块计算元。
将计算元组装起来就可以快速实现自动解答的计算方法。
其中，一个问题可以拥有多个不同的计算流，每个计算流有自己的条件，当满足条件之后，对这个模型调用计算流，对问题进行解答。

#### 基本思路
通过不断的装饰起点函数，让数据在流动过程中经历自定义的过程，实现动态构建算法函数

#### 基本说明
0. 条件：model需要满足某个要求才能调用这个计算流进行理解
1. 起源：所有自定义算法的起源，也就是 `Source()`类，为生产请求记录的起源迭代器
2. 计算流： 在`Source`类下面定义的各种函数，这些函数实现：
    1. 包装起源函数
    2. 调用自定义的小函数实现一些自定义的处理方法
3. 小函数： 一般是处理一个请求记录，也有处理model，具体的参数和返回值需要根据要使用的场景编写

#### 算法构建方法
参考默认算法的实现

ywtnhm/auto-Api

简介

发行版

贡献者

近期动态

ywtnhm/auto-Api .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

ywtnhm/auto-Api