要想得到你以前没有的，就必须做你以前没有做过的事情！
学习后台开发绕不开前端的知道，那从今天开始学习前端知识，扫一下盲，内容不多，会慢慢添加到文章里。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<!--这里显示网页标题-->
<title>网页标题</title>
</head>
<body>
<!--body里显示页面内容-->
<p>起因是在看完 Django Book 之后觉得有点过时，随后看了官方文档，<br />还是觉得官方文档写的比较通俗易懂。为了方便更多想要学习 Django 的人（顺便翻译一遍也能更深入的理解文档），就有了这个项目。
<hr />
这一项目离不开辛勤帮助翻译的小伙伴们，没有他们这个项目也无法完成。
特别感谢 @Zoctan，将翻译版本从 1.8 升级到了 1.11（pr），跟上了 Django 的发展。
</p>
<hr /><!--分隔线-->
<br /> <!--换行-->
<!--div ,span表示块，没有实际意义-->
<div>这一项目离不开辛勤帮助翻译的小伙伴们，没有他们这个项目也无法完成。
特别感谢 @Zoctan，将翻译版本从 1.8 升级到了 1.11（pr），跟上了 Django 的发展。这一项目离不开辛勤帮助翻译的小伙伴们，没有他们这个项目也无法完成。
特别感谢 @Zoctan，将翻译版本从 1.8 升级到了 1.11（pr），跟上了 Django 的发展。这一项目离不开辛勤帮助翻译的小伙伴们，没有他们这个项目也无法完成。
</div>
<span>
这一项目离不开辛勤帮助翻译的小伙伴们，没有他们这个项目也无法完成。
特别感谢 @Zoctan，将翻译版本从 1.8 升级到了 1.11（pr），跟上了 Django 的发展。这一项目离不开辛勤帮助翻译的小伙伴们，没有他们这个项目也无法完成。
特别感谢 @Zoctan，将翻译版本从 1.8 升级到了 1.11（pr），跟上了 Django 的发展。这一项目离不开辛勤帮助翻译的小伙伴们，没有他们这个项目也无法完成。
特别感谢 @Zoctan，将翻译版本从 1.8 升级到了 1.11（pr），跟上了 Django 的发展
</span>
<!--空格-->
<em>今天天气很好！</em> <!--表示强调语气-->
<i>明天天气不知道会不也这么大风！</i> <!--表示关键词-->
<b>这里的文字被加粗</b>
<br />
<strong>强调一段话，将翻译版本从 1.8 升级到了 1.11（pr），跟上了 Django 的发展
<h1>一号标题</h1>
<h2>二号标题</h2>
<h3>三号标题</h3>
<h4>四号标题</h4>
<h5>五号标题</h5>
<h6>六号标题</h6>
<!--显示标题大小>
<!--图片显示-->
<img src="/home/python/Pictures/girl01.jpg" alt="屏幕截图">
<br />
<!--网址链接-->
<a href="http://www.baidu.com" title="显示弹出提示信息">百度网址</a>
<br/>
<!--图片做超链接-->
<a href="http://www.baidu.com" title="我好看吗？">
<img src="/home/python/Pictures/girl01.jpg"></a>
<br>
<!--设置缺省值，#号可以点击跳转页面顶部-->
<a href="#">新闻标题</a>
<br>
<!--设置缺省值，没有跳转动作-->
<a href="javascript:;">缺省值</a>
<!--设置页面内部跳转-->
<h2 id = page1>page1</h2>
<a href="#page1">page1</a>
<a href="#page2">page2</a>
<a href="#page3">page3</a>
<a href="#page4">page4</a>
<p>小型企业，会选用成熟的API测试框架。
中大型企业，一般会自己开发更适合自身业务的API测试框架。
这种根据公司业务上下文开发实现的 API 测试框架，在使用上有很多优点，而且灵活性也很好，主要体现在以下几个方面：
可以灵活支持多个 API 的顺序调用，方便数据在多个 API 之间传递，即上一个 API 调用返回结果中的某个字段值可以作为后续 API 调用的输入参数；
方便在 API 调用之前或者之后执行额外的任意操作，可以在调用前执行数据准备操作，可以在调用后执行现场清理工作等；
可以很方便地支持数据驱动测试，这里的数据驱动测试概念和 GUI 测试中的数据驱动测试完全相同，也就是可以将测试数据和测试代码分离解耦；
由于直接采用了代码实现，所以可以更灵活地处理测试验证的断言（Assert）；
原生支持命令行的测试执行方式，可以方便地和 CI/CD 工具做集成。
然后作者提供了一个伪代码示例来说明，可以去看原文。
自动生成API测试代码
Postman 工具本身已经支持将 Collection 转化成测试代码，但如果直接使用这个功能的话，还有两个问题需要解决：
测试中的断言（assert）部分不会生成代码，也就是说测试代码的生成只支持发起 request 的部分，而不会自动生成测试验证点的代码；
很多中大型互联网企业都是使用自己开发的 API 测试框架，那么测试代码的实现就会和自研 API 测试框架绑定在一起，显然 Postman 并不支持这类代码的自动生成。
鉴于以上两点，理想的做法是自己实现一个代码生成工具，这个工具的输入是 Postman 中 Collection 的 JSON 文件，输出是基于自研 API 框架的测试代码，而且同时会把测试的断言一并转化为代码。
作者也提供了相应的例子，不再赘述。
Response结果发生变化时的自动识别
问题：到底应该验证API返回结果中的哪些字段？
不可能对返回结果中的每一个字段都写assert。
而API测试中，有一个很重要的概念是向后兼容。是指，发布的新API版本应该能够兼容老版本的API。
因此，需要找到一个方法，既可以不对所有的response字段都去写assert，又可以监测到response的结构以及没有写assert的字段值的变化。
于是，诞生了“Response结果变化时的自动识别”技术。也就是说，即使没有针对每个Response字段都去写assert，仍然可以识别出哪些Response字段发生了变化。
思路：在API测试框架中引入一个内建数据库，推荐非关系型数据库（比如MongoDB），然后用这个数据库记录每次调用的request和Response的组合，当下次发送想通的request时，API测试框架就会自动和上次的Response做差异检测，对于有变化的字段给出告警。
那么对于每次API调用都不同的字段，比如token、session ID、时间戳等，可以通过规则配置设立一个“白名单列表”，把动态值的字段排除在外。
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<h2 id ='page2'>page2</h2>
<a href="#page1">page1</a>
<a href="#page2">page2</a>
<a href="#page3">page3</a>
<a href="#page4">page4</a>
<br>
【心得】
最有用的是Response结果发生变化时的自动识别这块啊！自己在项目中遇到过类似的问题，虽然采取了一定的措施，但是没有想到作者这个解决方案。准备顺着作者的思路捋一捋，看看如何具体实现。
作者：cynthia猫
链接：https://www.jianshu.com/p/18e26c81811d
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
</p>
</body>
</html>
页面跳转效果图：
image.png
image.png
点击page1,page2,page3,page4,可跳转指定段落，由于文字过多，截取一部分展示！
网友评论