本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 接口自动化项目落地系列 找个开源网站或开源项目，用tep实现整套pytest接口自动化项目落地，归档到电子书，作为tep完整教程的项目篇一部分。自从tep完整教程发布以后，tep被越来越多小伙伴了解。教程只是纯理论，是骡子是马，拉出来遛遛才知道。做接口自动化项目落地，一方面是为了让自己脑海中的构想实实在在的呈现出来，现实和理想存在多少差距，不断尝试去弥补和修缮；另一方面也是方便读者朋友们学习使用，借助实际项目来练习，才能在赛道中弯道超车。 HTTPBin网站 httpbin.org是一个简单的在线提供HTTP服务的网站： 它能够用来对HTTP进行在线测试。 测试报告 HTTPBin网站的接口自动化项目包含11个用例集： 67条测试用例： 自动化执行正确率98.5%，其中有1条错误结果，是我故意为之的，因为想展示下断言失败的效果。 环境配置 包含http和https两套环境，因为HTTPBin支持HTTP&HTTPS： fixtures/fixture_env_vars.py #!/usr/bin/python ## encoding=utf-8 from tep.fixture import * @pytest.fixture(scope="session") def env_vars(config): class Clazz(TepVars): env = config["env"] """变量定义开始""" # 环境变量 mapping = { "http": { # http环境 "domain": "http://httpbin.org", }, "https": { # https环境 "domain": "https://httpbin.org", } # 继续添加 } # 定义类属性，敲代码时会自动补全 domain = mapping[env]["domain"] """变量定义结束""" return Clazz() 配置默认为http环境： conf.yaml env: http 用例集 http-methods import allure from tep.client import request @allure.title("get请求") def test(env_vars): # 描述 # 数据 # 请求 response = request( "get", url=env_vars.domain + "/get", headers={'Host': 'httpbin.org', 'Proxy-Connection': 'keep-alive', 'accept': 'application/json', 'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.109 Safari/537.36', 'Referer': 'http://httpbin.org/', 'Accept-Encoding': 'gzip, deflate', 'Accept-Language': 'en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7'}, params={} ) # 提取 # 断言 assert response.status_code < 400 auth ...

序列赋值是Python默认操作，如果使用不当，有可能会掉入语法陷阱。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 8.1 AI可观测 8.1.1 什么是AI可观测 AI应用具有非确定性，即便是相同的提示，在不同次的运行中也可能产生不同的输出。如果没有可观测，在发生幻觉虚假错误等严重问题时根本无从查起。相反，一个好用的可观测工具会记录每一次的提示与响应、追踪使用模式，并标记异常。AI可观测是确保AI应用高效稳定安全运行的基础能力。 8.1.2 可观测 vs 监控：从“是什么”到“为什么” 监控关注“什么”：比如API响应时间、错误率、请求吞吐量和Token使用量等指标。 可观测性探究“为什么”：比如一个聊天机器人的回答不正确且耗时过长，监控可能只会显示错误率上升或延迟过高，但可观测能揭示为什么：可能是一次长时间的RAG请求最终得到了错误的召回，导致模型给出不准确的答案。 AI应用的每一次请求，都可以被弯针的追溯，包括调用工具的出入参、发送给大模型的具体提示词、任何中间步骤（如调用数据库或其他API），以及最终收到的输出。可观测工具就可以提供极其丰富的排查数据和上下文，帮助定位问题的根因。 8.1.3 AI可观测应对的核心挑战 性能与可靠性问题：大模型是资源密集型的，延迟峰值和瓶颈时有发生。 成本问题：许多大模型服务按Token使用量收费，若无控制，成本可能意外飙升。 质量问题：大模型的可能输出从训练数据中继承偏见或有害内容，也很可能产生幻觉。 8.1.4 AI可观测解决方案的关键能力 端到端全链路追踪：提供端到端的日志采集和链路追踪，可视化请求在整个AI应用中的执行路径。 全栈可观测：包含应用、AI网关、推理引擎可观测3个维度。 自动化评估功能：通过引入评估Agent，对应用和模型的输入输出进行自动化的评估，检测幻觉、不一致或答案质量下降等问题。 8.2 端到端全链路追踪 一个典型的LLM应用架构可能包含用户终端、认证模块、会话管理、对话服务、大模型路由、流程编排等。需要具备3项可观测能力：标准化的数据语义规范、低成本高质量的数据采集、端到端全链路追踪。 8.2.1 端到端全链路追踪的实现方式 面向AI应用的领域化Trace语义 基于OpenTelemetry的高质量数据采集 标准化协议 8.2.2 核心技术路径 1、链路插桩技术 Python探针，Monkey Patch Java探针，字节码增强技术。 Go探针，编译时插桩技术。 多语言兼容，其他语言通过OpenTelemetry开源框架支持。 2、链路采集与加工 数据采集策略 流式场景优化 3、LLM Trace查询与分析 全链路透视 高级过滤 智能诊断 8.3 全栈可观测：应用可观测 8.3.1 AI原生应用开发的痛点 工具选择盲区、错误排除困难、Token消耗黑洞、循环调用陷阱。 8.3.2 AI原生应用可观测需要具备哪些能力 零代码接入、可视化工具选择过程、精准故障定位、Token成本分析、端到端链路追踪。 8.3.3 演示场景架构 使用LangChain框架构建一个Agent，大模型使用Qwen Turbo。SLS MCP服务器通过SLS HTTP OpenAPI访问日志的接口，完成日志分析请求。LangChain Agent与MCP服务器产生的观测数据会自动采集到可观测平台中。 ...

在DRF官方教程的学习过程中，一个很明显的感受是框架在不断地进行封装，我们自己写框架/工具/脚本/平台也可以模仿模仿，先完成底层代码，再做多层封装，让使用者很容易就上手操作。本文是教程的最后一篇，介绍ViewSets和Routers。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 Lambda Expression 有了Lambda Expression，就不用再写anonymous classes。 写Lambda，首先要找到它的类型。 There is a restriction on the type of a lambda expression: it has to be a functional interface. 函数接口，只有1个抽象方法的接口： @FunctionalInterface public interface Runnable { public abstract void run(); } 默认方法do not count，所以下面这个也是函数接口： @FunctionalInterface public interface Consumer<T> { void accept(T t); default Consumer<T> andThen(Consumer<? super T> after) { // the body of this method has been removed } } 静态方法也do not count，所以下面这个还是函数接口： ...

JMeter断言用来对服务器的响应数据进行验证，其中的响应断言基本能完成大多数的验证工作，但是JMeter还是提供了适用于多个不同场景的断言元件，一共16个，如下图所示：

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 What We Mean by “Spring” The term “Spring” means different things in different contexts. It can be used to refer to the Spring Framework project itself, which is where it all started. Over time, other Spring projects have been built on top of the Spring Framework. Most often, when people say “Spring”, they mean the entire family of projects. This reference documentation focuses on the foundation: the Spring Framework itself. ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 这个版本质量好不好？ 每次遇到这种问题，都很难给出让人满意的答案。 本文梳理下当前我对版本质量的思考，未来会不断迭代更新我的认知。 软件产品质量模型，描述了8个特性：功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性、可移植性。这个模型可以从全局视角，对软件产品质量进行评估。 总不能每次发完版，就套用这个模型来给产品质量打个分吧。 更现实的做法是，定义量化指标多维度进行评估。 指标库是个庞大和复杂的体系，涵盖了项目、产品、需求、开发、测试、质量等多个方面的关键性能指标（Key Performance Indicators，简称KPIs）。 这里只罗列版本质量相关的指标： 线上问题数量及问题级别：系统发布触发用户问题。质量好不好，必然要看问题多不多，影响大不大。 需求缺陷密度：需求缺陷数 / 完成需求数。缺陷少，质量高。想必我们都体验过测出来一堆问题，上线后还是一堆问题的烂质量。 缺陷关闭率：已关闭缺陷数 / 有效缺陷总数。要想提高质量，就要解决问题。曾经历过遗留30个bug不处理就上线的，初创团队抢占市场可以理解，稳定产品的缺陷关闭率低就需要引起重视了。 缺陷关闭时长：所有缺陷(关闭时间 - 创建时间)求和 / 有效缺陷总数。长时间、跨版本都没有解决的问题，一拖再拖，说不定哪天就在线上暴雷了。所有问题都要及时关注，尽快修复。 缺陷逃逸率：上线后发现缺陷数 / 有效缺陷总数。测试同学注意了，灵魂三问，没有测过吗？为什么没测到？为什么不知道？遇到过测试马虎了事的，测试不给力，保不住质量下限。 除了怎么衡量版本质量以外，还有个问题是怎么交付出高质量产品，是让开发少写点bug，还是让测试多找点bug？ 有个很有意思的说法是，高质量产品是用出来的。这个认知没有局限于开发、测试谁背锅的责任归属，而是从产品迭代的角度出发，更多的功能，更多的缺陷，就会投入更多的努力去修复这些质量问题，从而提高产品质量。 让更多客户使用，发现更多问题，持续完善产品，才能打磨出高质量产品。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 创建上图的pytest项目结构，只需要一条命令即可： tep startproject demo 前提是安装tep0.9.8版本： pip install tep==0.9.8 示例代码单独放在了samples文件夹下，可以放心将整个目录删除。其中的db演示了连接MySQL数据库，http演示了requests常见用法和tep request的猴子补丁，login_pay演示了从登陆到下单该如何编写脚本，包括httprunner、mvc（不推荐）、tep（强烈推荐）三种写法。 fixtures从conftest.py文件中单独拎了出来。这个设计与Django不谋而合，Django也有个叫做fixtures的文件夹，用来存放测试数据。其实pytest的fixture的本意是可以用来做setup和teardown的，从这个意义来说，fixtures就是存放测试数据的，比如封装登录接口为用例提供token。 utils存放了一些工具。比如自带的fastapi项目，request猴子补丁，mitmproxy抓包自动生成用例。request猴子补丁可以自定义日志输出格式，在发送请求前后完成任何你想做的操作。 tep0.9.8版本正式发布，对项目脚手架进行了精简，是为接下来的**《tep完整教程帮你突破pytest》**做好准备。

切片，就像面包，给几刀，切成一片一片，可以做成吐司，也可以做成三明治，口味更佳：