杂谈

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，具体的参数和返回值需要根据要使用的场景编写

算法构建方法

参考默认算法的实现