第一章 前言
1.1 文档总体介绍
该文档针对媒资4.1相关接口的两轮测试结果进行了抽象汇总，针对于研发自测相关项提供了具体的自测依据。
1.2 使用范围
目前只有研发自测相关的规范
1.3 作用
1.研发在进行自测的时候有依据可以遵循
2.能够让研发开发的接口更加健壮
第二章 研发自测项(接口类型)
1.所有请求对应返回值的精确性(尤其是返回错误之后相关的错误提示的准确性)，每个产品或者项目需要有明确的定义
2.1 insert接口
1.必填参数的验证以及相关提示问题
2.入参，当前不做限制的需要在说明中明确
2.2 update接口
1.入参的格式限制(例如：文档中为String，就必须限制输入String)
2.绑定相关接口中，需要验证id是否为有效的id再进行绑定
2.3 delete接口
1.批量删除需要对每一个id进行验证(格式验证、是否为数据库中的有效id的验证)
2.假删除中入参的验证限制问题(例如：限制只能输入0、1、2)
2.4 query接口(公共问题)
1. 查询返回的参数严格与接口文档中的返回参数保持一致
2.5 queryById接口
1.mongodb中先判断id是否为24位，否则直接去查询会抛出异常(或者也可以直接捕捉对应的异常进行相关明确的提示处理)
2.id后面输入特殊符号问题，#需要在文档中进行说明(例如：#为url地址中特有的占位符，所以后面加入#是解析不到controller中的，所以id后面加入#进行调用依然可以调用成功的问题)
2.6 queryPage接口
1.入参，是否必填，必须在接口文档中介绍清楚(特指具有层级嵌套的入参)
2.入参的边界值、最大限制问题(例如：分页查询页数和每页条数的限制)
3.是否包含字段的测试与限制问题(例如：用户输入不包含isDel则返回的字段中不应该有isDel字段)
4.入参的时间值验证是否为正确的入参时间格式(验证格式要与文档中保持一致)
第三章 研发自测项(文档说明)
3.1 common问题
1.请求url拼接的格式说明必须明确
2.每个接口的请求方式必须明确(插入post、更新put、删除delete/get、根据id查询get、分页查询post)
3.每个接口的请求地址必须明确(地址中相关的空格、改接口是否已经提供的说明)
4.请求参数是否为必填项必须明确，如果有层级嵌套，也必须说明
例如：分页查询中的queryMap中的字段对应的是否为必填项、queryMap该字段是否为必填项
5.必填项的定义：该字段的key值必填，value并没有明确标注
6.请求结果中的参数必须与文档中的返回参数严格一致
7.边界值相关问题的考虑(需要在入参对应的说明中写清楚)
3.2 专属问题
暂无
第四章 总结
一直渴望并且在每一次经历的过程中针对于自己的经历很铭感的进行总结抽象的过程，争取能够让自己的下次再做类似的事情的时候效果更好、做的更到位。
所谓团队，如果都能够奖自己的长处发挥共享，互补成长，相信这个团队的成长一定是空前的，如果没有这样的环境，可以创造环境，如果没有这样的团队，自己可以当那个带头人，如果环境真的不允许，至少可以做的还有渐渐的影响身边的人向更好的方向发展下去。
一个人的成功不在于做了多少事情，而在于帮助了多少人，小编抽象这样的文档，共享给团队，相当于间接的在影响团队在帮助团队每个人意识到善于思考、提高效率的重要性~
