博客

2026-07-28 | LangChain 学习 Day 1

前言

一直想系统学习 LangChain，今天终于动手写了第一个 Demo。目标很简单：让本地运行的 AI 模型能查询真实天气数据并回答用户问题。

最终效果：我问”合肥明天天气怎么样？”，Agent 自动调用和风天气 API 获取实时数据，然后用自然语言回答我——和我手机天气 App 显示的数据完全一致。

技术选型

架构原理

整个流程只有 4 步：

用户提问 → 模型决策（要不要调工具？调哪个？传什么参数？）→ 执行工具 → 模型整合回答

用 LangChain 的话说，这就是一个 ReAct Agent：Reasoning + Acting 循环。

┌─────────────┐
│  用户提问    │  "合肥明天天气怎么样？"
└──────┬──────┘
       ▼
┌─────────────────────────────────┐
│  LLM (qwen2.5:7b)              │
│  思考：需要调用 get_weather 工具  │
│  决策：city = "合肥"             │
└────────────────────────────────┘
       ▼
┌─────────────────────────────────┐
│  工具执行：get_weather("合肥")    │
│  → 请求和风天气 API              │
│  → 返回：晴 25~33°C 南风3-4级    │
└──────┬──────────────────────────┘
       ▼
┌─────────────────────────────────┐
│  LLM 整合数据，生成自然语言回答   │
│  "明天合肥晴天，25到33度..."      │
└─────────────────────────────────┘

完整代码

# pip install -qU langchain langchain-ollama requests python-dotenv
import os
import requests
from dotenv import load_dotenv
from langchain.agents import create_agent

load_dotenv()  # 从 .env 文件加载环境变量

# ===== 和风天气配置（从 .env 读取） =====
QWEATHER_HOST = os.getenv("QWEATHER_HOST", "")
QWEATHER_KEY = os.getenv("QWEATHER_KEY", "")

# 城市经纬度映射（常用城市）
CITY_COORDS = {
    "合肥": "117.27,31.86",
    "北京": "116.41,39.92",
    "上海": "121.47,31.23",
    "广州": "113.26,23.13",
    "深圳": "114.06,22.54",
    "杭州": "120.15,30.28",
    "南京": "118.78,32.06",
    "武汉": "114.31,30.52",
    "成都": "104.07,30.67",
    "重庆": "106.55,29.56",
}


def get_weather(city: str) -> str:
    """查询指定城市的真实天气预报，包括明天天气。city参数传入中文城市名，如 合肥、北京、上海"""
    try:
        coords = CITY_COORDS.get(city)
        if not coords:
            geo_url = f"{QWEATHER_HOST}/v2/city/lookup?location={city}&key={QWEATHER_KEY}"
            geo_resp = requests.get(geo_url, timeout=10)
            geo_data = geo_resp.json()
            if geo_data.get("code") != "200" or not geo_data.get("location"):
                return f"未找到城市: {city}"
            loc = geo_data["location"][0]
            coords = f"{loc['lon']},{loc['lat']}"
            city = loc.get("name", city)

        url = f"{QWEATHER_HOST}/v7/weather/3d?location={coords}&key={QWEATHER_KEY}"
        resp = requests.get(url, timeout=10)
        data = resp.json()

        if data.get("code") != "200":
            return f"查询失败，错误码: {data.get('code')}"

        today = data["daily"][0]
        today_info = (f"今天({today['fxDate']}): "
                      f"{today['textDay']} {today['tempMin']}~{today['tempMax']}°C, "
                      f"{today['windDirDay']}{today['windScaleDay']}级, "
                      f"湿度{today['humidity']}%")

        tomorrow = data["daily"][1]
        tomorrow_info = (f"明天({tomorrow['fxDate']}): "
                         f"{tomorrow['textDay']} {tomorrow['tempMin']}~{tomorrow['tempMax']}°C, "
                         f"{tomorrow['windDirDay']}{tomorrow['windScaleDay']}级, "
                         f"湿度{tomorrow['humidity']}%, "
                         f"日出{tomorrow['sunrise']} 日落{tomorrow['sunset']}")

        return f"{city}天气:\n{today_info}\n{tomorrow_info}"
    except Exception as e:
        return f"查询失败: {e}"


agent = create_agent(
    model="ollama:qwen2.5:7b",
    tools=[get_weather],
    system_prompt="你是一个天气助手，请用中文回答。调用工具时city参数使用中文城市名(如合肥、北京、上海)。",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "合肥明天天气怎么样？"}]}
)
print(result["messages"][-1].content_blocks)

运行结果

合肥明天的天气预计是晴天，气温在25到33摄氏度之间。
南风等级为3-4级，湿度为83%。
日出时间是早上5点25分，日落时间是晚上19点11分。
请注意防晒和补水哦！

对比手机天气 App：明天 25~33°C 晴 —— 完全一致。

踩坑记录

坑 1：项目文件夹不能叫 langchain

一开始我把项目放在 d:\code\ai-code\langchain\ 目录下，结果 from langchain.agents import create_agent 直接报 ModuleNotFoundError。

原因：Python 导入时优先查找当前目录，文件夹名 langchain 遮蔽了已安装的 langchain 包。

解决：改名为 langchain-demo。

坑 2：pip 和 python 版本不一致

系统装了 Python 3.13 和 3.14 两个版本。pip install 装到了 3.14，但 python 命令指向 3.13。

解决：永远用 python -m pip install 确保装到正确版本。

坑 3：wttr.in 国内天气不准

最初用免费的 wttr.in，合肥明天预报 24~27°C 多云/雨，实际是 25~33°C 晴，差了 6 度。

原因：wttr.in 数据源是国外气象服务，对中国城市精度很差。

解决：换和风天气 API，数据来自中国气象局，完全准确。

坑 4：和风天气需要填 API Host

注册后只填了 Key 没填 Host，导致请求发到占位符地址当然失败。

教训：和风天气有两个必填项 —— API Host（每个用户不同）和 API Key。

项目结构

langchain-demo/
├── .env                  # 密钥配置（不提交 Git）
├── .env.example          # 配置模板
├── .gitignore
├── langchaindemo1.py     # 主程序
├── LEARNING_ROADMAP.md   # 学习路线 TODO
└── 我的第一个LangChain项目.md  # 本文

核心收获

1. LangChain 的 create_agent 极简：10 行代码就能创建一个能调用工具的 Agent
2. 工具函数的 docstring 很重要：模型靠它理解何时调用、传什么参数
3. system_prompt 引导模型行为：比如指定”用中文城市名”避免编码问题
4. 数据源选择影响结果质量：国外 API 查国内天气不靠谱，选对数据源很关键
5. .env 管理密钥是基本规范：永远不要把 Key 硬编码在代码里

下一步

按照学习路线，接下来进入阶段 2：
– 学习 Prompt Templates 和 Output Parsers
– 构建第一个 RAG 知识库问答系统
– 尝试 LangSmith 追踪调试

路还很长，但第一步已经迈出去了。

  凯格尔运动（提肛）有多重要？

  对男性来说，它是最被低估的「核心力量训练」。盆底肌是支撑膀胱、直肠的「底盘」，强化它可以改善排尿控制、提升性功能、预防

  中年以后的前列腺问题。

  对女性来说就更刚需了——产后漏尿、盆腔器官脱垂、核心稳定性，都和这块肌肉密切相关。产科医生、康复师反复强调要做，但从来没

  人教你怎么做。

  问题来了：绝大多数人的凯格尔运动，根本做错了。

  你可能正在用腹部代偿、憋气、用臀部发力，甚至不知道自己到底收紧的是哪块肉。

  所以我写了这个工具——提肛助手（tgang-helper）。一句话介绍：傻子也能练对。

  它会做什么？

  – 男女分离，科学分级：男性和女性的盆底肌发力感受完全不同，课程分开设计，分入门/进阶/强化三个等级，从感知定位到极限耐力

  ，循序渐进。

  – 看着就能做：训练时有一个会呼吸的大圆环——收紧时缩小变红，放松时扩大变绿。旁边还有一个动画小人，用高亮告诉你该用哪里发

  力，收缩方向有箭头指示。你一看就知道该怎么做。

  – 闭眼也能跟练：全程中文语音播报，「收紧」「放松」「休息一下」自动提醒，不用盯着屏幕。

  – 开摄像头纠正姿势：如果你打开姿势检测，浏览器会用 AI（MediaPipe Pose）实时检测你站着还是坐着、有没有驼背、耸肩、身体

  歪斜。全程纯本地运行，摄像头画面不上传到任何服务器。当检测到你持续姿势不对，系统会把姿势数据（不是图像）发给 DeepSeek

  获取纠正建议，然后用语音告诉你：「肩膀有点紧张，放松下沉」。

  – 打卡和统计：训练记录保存在本地浏览器，热力图日历 + 周统计图，直观看到自己的坚持。

  技术上说几句

  纯前端应用，Next.js + TypeScript，姿势检测用 MediaPipe Pose，动画用 Framer Motion + SVG，AI 建议通过 API Route 代理调

  DeepSeek。没有后端数据库，所有数据本地存储，隐私友好。

  最后说句真心话

  盆底肌训练是最被低估的「隐形健身」，它不像练腹肌那样肉眼可见，但对生活质量的影响远超你的想象。每天 8

  分钟，坚持两周，你就能感受到变化。

  来试试吧：https://tgang.dimeng.icu  如果觉得有用，分享给需要的朋友。有些话题虽然不好意思聊，但值得被认真对待。

在前端开发中，自动化测试是保障项目质量、提升开发效率的关键环节。而 Cypress 作为一款现代化的端到端（E2E）测试框架，凭借其简洁的 API、实时重载、时间旅行调试等优势，成为越来越多前端开发者的首选工具。不同于传统测试框架的繁琐配置，Cypress 开箱即用，既能满足新手快速上手的需求，也能支撑复杂项目的测试场景。本文将从入门认知、环境安装、基础使用，到进阶精通，一步步带你吃透 Cypress，结合具体示例帮你快速落地实践。

一、入门认知：什么是 Cypress？

Cypress 是一个专为现代 Web 应用设计的端到端测试框架，它不仅是一个测试工具，更是一套完整的测试解决方案，涵盖了测试编写、运行、调试的全流程。与 Selenium 等传统框架相比，Cypress 具有以下核心优势，也是它能快速出圈的原因：

• 浏览器原生运行：测试代码与应用代码在同一浏览器环境中执行，无需额外的驱动程序，避免了跨环境兼容问题，能更真实地模拟用户操作体验。
• 实时重载 + 时间旅行：修改测试代码后，测试会自动重新运行；同时支持回放测试的每个步骤，可查看每个操作对应的 DOM 状态、网络请求，快速定位问题。
• 自动等待：智能等待元素加载、网络请求完成，无需手动编写 sleep 等待语句，大幅减少测试用例的不稳定性（默认等待4秒，可自定义配置）。
• 丰富的 API 与断言：内置强大的选择器、操作命令和断言方法，支持 DOM 元素、网络请求、Cookie 等多种场景的验证，语法简洁易懂。
• AI 辅助能力：提供 AI 驱动的测试生成、自愈能力，可通过 Cypress Studio 录制用户操作生成测试代码，减少手动编写成本。

适用场景：前端项目的端到端测试（模拟用户真实操作流程）、组件测试、接口测试，尤其适合 React、Vue、Angular 等现代前端框架开发的项目。

二、环境安装：3步搞定，开箱即用

Cypress 的安装非常简单，核心依赖 Node.js（建议版本 ≥14.17.0），无论是新建项目还是已有项目，都能快速集成。以下是详细安装步骤，覆盖 Windows、Mac、Linux 全系统。

2.1 前置条件

确保本地已安装 Node.js 和 npm/yarn/pnpm（任意一种包管理器），可通过以下命令验证：

# 验证 Node.js 版本
node -v
# 验证 npm 版本
npm -v

若未安装 Node.js，可前往 Node.js 官网 下载安装（建议选择 LTS 长期支持版）。

2.2 安装 Cypress

有两种安装方式，根据项目场景选择即可：

方式1：新建测试项目（从零开始）

# 1. 新建项目文件夹并进入
mkdir cypress-demo && cd cypress-demo
# 2. 初始化 package.json（一路回车即可）
npm init -y
# 3. 安装 Cypress（开发依赖）
npm install cypress --save-dev
# 或使用 yarn/pnpm
yarn add cypress --dev
pnpm add cypress --dev

方式2：集成到已有前端项目

直接在已有项目根目录执行安装命令即可：

npm install cypress --save-dev

2.3 启动 Cypress

安装完成后，通过以下命令启动 Cypress 可视化界面：

npx cypress open

首次启动时，Cypress 会自动初始化项目结构，生成默认的配置文件和测试示例，同时会下载 Cypress 核心应用程序（若下载失败，可参考下方常见问题解决）。启动成功后，会弹出 Cypress 可视化控制台，选择「E2E Testing」即可开始编写测试用例。

2.4 常见安装问题解决

若出现「The Cypress App could not be downloaded」错误，通常是网络或镜像问题，可通过以下方法解决：

# 1. 配置国内镜像（临时生效，仅当前命令行）
# Windows（cmd/PowerShell）
set CYPRESS_DOWNLOAD_MIRROR=https://npmmirror.com/mirrors/cypress/
# Mac/Linux（终端）
export CYPRESS_DOWNLOAD_MIRROR=https://npmmirror.com/mirrors/cypress/
# 2. 清除缓存并重新安装
npx cypress cache clear
rm -rf node_modules package-lock.json
npm install

三、基础使用：编写第一个测试用例

启动 Cypress 后，我们先熟悉其项目结构，再编写第一个测试用例，快速感受 Cypress 的便捷性。

3.1 Cypress 项目结构（核心目录）

初始化后，项目根目录会生成 cypress 文件夹，核心目录结构如下：

cypress/
├── e2e/          # 端到端测试用例存放目录（核心）
│   └── example.cy.js  # 默认示例用例
├── fixtures/     # 测试数据文件（如 JSON 格式，用于模拟接口数据）
├── support/      # 支持文件
│   ├── commands.js  # 自定义命令（封装重复操作）
│   └── e2e.js     # 全局配置（如导入依赖、设置全局变量）
├── screenshots/  # 测试失败时自动生成的截图
└── videos/       # 测试运行时自动生成的录屏（无头模式下生效）

核心配置文件：cypress.config.js（项目根目录），用于配置基础路径、浏览器、等待时间等，默认无需修改，后续可根据需求自定义。

3.2 编写第一个测试用例（实战示例）

我们以「访问百度首页，搜索 Cypress 并验证结果」为例，编写第一个测试用例，步骤如下：

步骤1：新建测试文件

在 cypress/e2e 目录下，新建 baidu-search.cy.js 文件（测试文件后缀必须为 .cy.js，Cypress 会自动识别）。

步骤2：编写测试代码

测试代码的核心结构是 describe（测试套件）和 it（测试用例），结合 Cypress 内置命令完成操作和断言，代码如下（含详细注释）：

// 告诉 Cypress 这是它的测试文件（可选，用于语法提示）
/// <reference types="cypress" />

// 测试套件：描述一个功能模块（如「百度搜索功能」）
describe('百度搜索功能测试', () => {
  // 测试用例：描述一个具体的测试场景（如「搜索 Cypress 并验证结果」）
  it('访问百度首页，搜索 Cypress，验证搜索结果', () => {
    // 1. 访问百度首页（cy.visit() 用于导航到指定 URL）
    cy.visit('https://www.baidu.com')
    
    // 2. 定位搜索输入框，输入「Cypress」（cy.get() 用于定位元素，type() 用于输入内容）
    // 这里通过 ID 定位搜索框（#kw 是百度搜索框的 ID）
    cy.get('#kw').type('Cypress')
    
    // 3. 定位搜索按钮，点击搜索（click() 用于点击元素）
    cy.get('#su').click()
    
    // 4. 断言：验证搜索结果中包含「Cypress 官方网站」（should() 用于断言）
    cy.contains('Cypress 官方网站').should('be.visible')
    
    // 额外断言：验证当前 URL 包含「wd=Cypress」（确认跳转到搜索结果页）
    cy.url().should('include', 'wd=Cypress')
  })
})

步骤3：运行测试用例

重新启动 Cypress（npx cypress open），在可视化控制台中找到 baidu-search.cy.js，点击即可运行测试。运行过程中，你会看到：

• 浏览器自动打开，逐步执行测试步骤（访问百度、输入内容、点击按钮）；
• Cypress 控制台左侧显示每个步骤的执行状态（绿色表示成功，红色表示失败）；
• 测试完成后，若所有断言都通过，测试用例会显示「PASSED」。

小贴士：测试过程中，可点击控制台左侧的步骤，查看该步骤对应的 DOM 状态（时间旅行功能），快速调试问题。

3.3 基础命令速查（高频使用）

Cypress 的命令简洁直观，以下是基础使用中最常用的命令，结合示例记忆更高效：

四、进阶精通：解锁 Cypress 高级用法

掌握基础使用后，我们需要学习 Cypress 的高级用法，解决复杂测试场景（如接口模拟、代码复用、跨环境测试、CI/CD 集成），真正实现“精通”并落地到实际项目中。

4.1 接口测试与网络请求模拟

Cypress 不仅能测试页面交互，还能直接测试接口，或模拟接口返回数据（避免依赖真实后端环境），核心命令是 cy.intercept()（拦截网络请求）和 cy.request()（发送请求）。

示例1：直接测试接口（GET 请求）

describe('接口测试示例', () => {
  it('测试获取用户列表接口', () => {
    // 发送 GET 请求
    cy.request('GET', 'https://api.example.com/users')
      .then((response) => {
        // 断言接口状态码为 200
        expect(response.status).to.eq(200)
        // 断言返回数据是数组
        expect(response.body).to.be.an('array')
        // 断言返回数据长度大于 0
        expect(response.body.length).to.gt(0)
      })
  })
})

示例2：模拟接口返回（拦截请求，无需依赖真实后端）

先在 cypress/fixtures 目录下新建 users.json（模拟接口返回数据）：

[
  { "id": 1, "name": "张三", "age": 25 },
  { "id": 2, "name": "李四", "age": 28 }
]

然后编写测试用例，拦截接口并返回模拟数据：

describe('接口模拟示例', () => {
  it('模拟获取用户列表接口', () => {
    // 1. 拦截 GET 请求，指定返回 fixtures 中的数据
    cy.intercept('GET', 'https://api.example.com/users', { fixture: 'users.json' }).as('getUsers')
    
    // 2. 访问需要调用该接口的页面（假设页面加载时会请求用户列表）
    cy.visit('/user-list')
    
    // 3. 等待接口请求完成（as 定义的别名，用于关联拦截的请求）
    cy.wait('@getUsers')
    
    // 4. 断言页面中显示模拟的用户数据
    cy.contains('张三').should('be.visible')
    cy.contains('李四').should('be.visible')
  })
})

4.2 代码复用：自定义命令与测试钩子

实际项目中，很多测试步骤会重复（如登录、退出、导航到指定页面），通过自定义命令和测试钩子，可大幅减少重复代码，提升测试用例的可维护性。

4.2.1 自定义命令（封装重复操作）

在 cypress/support/commands.js 中定义自定义命令，全局可用。示例：封装登录命令：

// cypress/support/commands.js
// 定义登录命令，接收用户名和密码参数
Cypress.Commands.add('login', (username, password) => {
  cy.visit('/login') // 访问登录页
  cy.get('input[name="username"]').type(username) // 输入用户名
  cy.get('input[name="password"]').type(password) // 输入密码
  cy.get('button[type="submit"]').click() // 点击登录按钮
  cy.url().should('include', '/home') // 断言登录成功，跳转到首页
})

在测试用例中直接调用自定义命令：

describe('首页功能测试', () => {
  // 调用自定义登录命令，无需重复编写登录步骤
  beforeEach(() => {
    cy.login('admin', '123456') // 每个测试用例执行前先登录
  })
  
  it('验证首页显示用户名', () => {
    cy.contains('欢迎您，admin').should('be.visible')
  })
  
  it('验证首页菜单显示', () => {
    cy.get('#menu-home').should('be.visible')
    cy.get('#menu-user').should('be.visible')
  })
})

4.2.2 测试钩子（控制测试流程）

Cypress 提供 4 个常用测试钩子，用于控制测试用例的执行顺序，减少重复操作：

• before()：所有测试用例执行前，只执行一次（如初始化测试数据）；
• beforeEach()：每个测试用例执行前，都执行一次（如登录、访问页面）；
• afterEach()：每个测试用例执行后，都执行一次（如清除缓存、退出登录）；
• after()：所有测试用例执行后，只执行一次（如关闭浏览器、清理测试环境）。

示例：结合钩子和自定义命令，优化测试流程：

describe('用户管理功能测试', () => {
  // 所有用例执行前，初始化测试数据
  before(() => {
    cy.request('POST', 'https://api.example.com/init-test-data')
  })
  
  // 每个用例执行前，先登录
  beforeEach(() => {
    cy.login('admin', '123456')
  })
  
  // 每个用例执行后，清除当前页面缓存
  afterEach(() => {
    cy.reload()
  })
  
  // 所有用例执行后，清理测试数据
  after(() => {
    cy.request('POST', 'https://api.example.com/clear-test-data')
  })
  
  it('新增用户', () => {
    // 编写新增用户的测试步骤（无需重复登录）
  })
  
  it('编辑用户', () => {
    // 编写编辑用户的测试步骤（无需重复登录）
  })
})

4.3 数据驱动测试（多场景批量测试）

当测试场景相同、仅输入/输出数据不同时（如登录失败的多种场景：账号为空、密码为空、账号密码错误），可使用数据驱动测试，通过循环批量执行测试用例，避免重复编写代码。

示例：测试登录失败的多种场景：

describe('登录失败场景测试', () => {
  // 测试数据：数组形式，每个元素是一组输入和预期结果
  const testData = [
    { username: '', password: '123456', expectMsg: '请输入用户名' },
    { username: 'admin', password: '', expectMsg: '请输入密码' },
    { username: 'admin', password: 'wrong', expectMsg: '账号或密码错误' }
  ]
  
  // 循环测试数据，生成测试用例
  testData.forEach((data) => {
    it(`输入${data.username}/${data.password}，提示${data.expectMsg}`, () => {
      cy.visit('/login')
      cy.get('input[name="username"]').type(data.username)
      cy.get('input[name="password"]').type(data.password)
      cy.get('button[type="submit"]').click()
      // 断言错误提示
      cy.contains(data.expectMsg).should('be.visible')
    })
  })
})

4.4 跨环境测试与配置优化

实际项目中，会有开发、测试、生产等多个环境，通过 Cypress 配置文件，可快速切换测试环境，无需修改测试代码。

示例：修改 cypress.config.js，配置多环境基础路径：

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    // 基础配置
    setupNodeEvents(on, config) {},
    // 不同环境的基础路径（可通过命令行参数切换）
    baseUrl: config.env.environment === 'test' 
      ? 'https://test.example.com' 
      : 'https://dev.example.com'
  },
  // 全局等待时间（默认4秒，可自定义）
  defaultCommandTimeout: 5000
})

通过命令行切换环境：

# 测试环境运行测试
npx cypress run --env environment=test
# 开发环境运行测试
npx cypress run --env environment=dev

4.5 CI/CD 集成（自动化测试流水线）

将 Cypress 测试集成到 CI/CD 流水线（如 GitHub Actions、Jenkins、CircleCI），可实现“代码提交后自动运行测试”，提前发现问题，保障代码质量。以下是 GitHub Actions 和 Jenkins 的简单示例。

示例1：GitHub Actions 集成

在项目根目录创建 .github/workflows/test.yml 文件，配置如下：

on: [push] # 代码推送时触发测试
jobs:
  cypress:
    runs-on: ubuntu-latest
    steps:
      - name: 拉取代码
        uses: actions/checkout@v4
      - name: 安装 Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '16'
      - name: 安装依赖
        run: npm install
      - name: 运行 Cypress 测试（无头模式）
        uses: cypress-io/github-action@v6
        with:
          build: npm run build
          start: npm start

示例2：Jenkins 集成

1. 安装必要插件：NodeJS Plugin、HTML Publisher Plugin；

2. 新建 Jenkins 任务，配置源码管理（关联 GitHub/GitLab 仓库）；

3. 构建步骤添加“执行 shell”（Linux）或“执行 Windows 批处理命令”，输入如下命令：

# 安装依赖
npm install
# 运行 Cypress 测试，生成测试报告
npx cypress run --reporter junit --reporter-options mochaFile=results/test-results-(hash).xml

4. 构建后操作：配置测试报告展示，方便查看测试结果。

4.6 调试技巧与最佳实践

4.6.1 调试技巧

• 时间旅行：测试运行时，点击控制台左侧的步骤，可回放该步骤的 DOM 状态，查看元素属性和网络请求；
• 调试语句：在测试代码中添加 debugger，测试运行到该语句时会暂停，可在浏览器开发者工具中调试；
• 日志输出：使用 cy.log('日志内容')，在控制台输出自定义日志，方便定位问题；
• 截图/录屏：测试失败时，Cypress 会自动截图；无头模式运行时，会自动录屏，可在 screenshots 和 videos 目录查看。

4.6.2 最佳实践

• 使用 data-testid定位元素，避免依赖 ID、类名（避免因样式修改导致测试失败）；
• 一个测试用例只测一个功能点，避免“大而全”的用例（失败时可精准定位问题）；
• 避免手动添加 cy.wait(1000)等待语句，依赖 Cypress 的自动等待机制；
• 使用 fixture 管理测试数据，避免硬编码在测试代码中；
• 定期清理测试用例，删除过期、冗余的用例，保持测试套件的简洁性。

五、总结与进阶方向

到这里，你已经掌握了 Cypress 的核心用法：从环境安装、基础测试用例编写，到接口模拟、代码复用、CI/CD 集成，足以应对大部分前端项目的自动化测试需求。Cypress 的优势在于“简单、高效、易调试”，无需复杂的配置，新手也能快速上手，同时其强大的高级功能，也能支撑复杂项目的测试场景。

进阶方向建议：

• 深入学习 Cypress 组件测试（测试 React/Vue 组件）；
• 探索 Cypress Cloud 功能，实现测试结果可视化、并行测试、AI 辅助调试；
• 结合实际项目，搭建完整的自动化测试体系（接口测试 + 端到端测试 + CI/CD 集成）；
• 学习 Cypress 插件开发，扩展其功能（如集成测试报告、自定义断言）。

自动化测试的核心是“提升效率、保障质量”，Cypress 只是工具，关键在于结合项目场景，编写高效、稳定、可维护的测试用例。多动手实践，多踩坑调试，才能真正精通 Cypress，让它成为你前端开发中的“质量守护者”。

真正的强大是重新爱上自己

1.你开始为自己的选择负责，而不是依赖他人

2.你能坦然说出“我不知道”或者“我需要帮助”

3.你越来越懂得欣赏自己的特质，并发挥他们积极的一面

4.你不再美化没有走过的路，欣然接纳自己的局限

5.你允许自己有消极情绪，不再责备自己

6.你学会了为“小小的胜利”庆祝，大大方方地骄傲

7.你不再靠别人的评价确认自我价值，拥有了清晰的“自我坐标”

立项管理

项目可行性研究内容：

1、技术可行性分析；

2、经济可行性分析；

3、社会效益可行性分析；

4、运行环境可行性分析；

5、其他方面的可行性分析；

项目可行性研究阶段：

1、初步可行性研究；

2、详细可行性研究；

项目建议书的内容：项目的必要性、项目的市场预测、项目预期成果（如产品方案或服务）的市场预测、项目建设必需的条件

整合管理

整合管理常见的问题？

1、没有制定项目管理计划；

2、没有制定有效的范围和需求管理子计划；

3、没有制定合理的整体变更流程及需求变更控制流程；

4、对客户的需求获取不充分；

5、需求分析工作不充分，缺乏需求定义环节，没有定义出需求规则说明书；

6、缺乏需求验证环节，没有请客户代表一起进行需求评审；

7、没有求得干系人对需求的承诺；

8、没有求得干系人对需求的一致理解；

9、没有有效的管理变更控制；

10、未能做好进度管理，范围变更时没有充分评估对进度等其他方面的影响，导致进度延误；

11、范围没有管好，导致不断的范围蔓延

项目整合变更控制流程？

1、变更申请；

2、对变更的初审；

3、变更方案的论证；

4、变更审查；

5、发出通知并实施；

6、变更监控；

7、效果评估；

8、变更收尾；

项目整合变更控制流程常见的问题？

1、没有制定项目变更控制流程，或者没有遵循项目变更控制流程；

2、没有成立变更控制委员会，或类似的组织形式来控制项目的变更；

3、未做好变更相关的配置管理工作，导致版本混乱；

4、变更口头提出，未进行书面记录；

项目章程主要内容：

项目目的；高层次需求、高层级项目描述、边界定义以及主要可交付成果；可测量的项目目标和相关的成功标准；整体项目风险；总体里程碑进度计划；预先批准的财务资源；关键干系人名单；项目审批要求；项目推出标准；委派的项目经理及其职责和职权；发起人或其他批准项目章程的人员的姓名和职权

项目管理计划的主要内容：

范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、资源管理计划、沟通管理计划、风险管理计划、采购管理计划、干系人参与计划、范围基准、进度基准、成本基准、变更管理计划、配置管理计划、绩效测量基准、项目生命周期、开发方法、管理审查

在变更中的配置管理活动？

项目收尾？

范围管理常见问题

1、没有编制范围管理计划和需求管理计划/独自一人编制不妥；

2、没有全面收集干系人需求/未对需求进行跟踪；

3、没有编制范围说明说/独自一人编制不妥；

4、制订范围说明书的依据不充分；

5、没有创建WBS；

6、创建WBS工作没有相关关系人的参与/独自一人创建WBS不妥；

7、WBS的创建没有遵循相关原则/多人负债同一工作包/工作包时间过长或过短；

8、没有形成范围基准/范围基准未经确认；

9、没有形成范围确认工作/范围确认未贯穿于项目始终；

10、没有进行范围控制工作导致问题频发/范围控制没有走变更控制流程；

11、项目经理管理经验不足，可见未提前进行好相关的培训工作；

规划范围管理的输出：范围管理计划+需求管理计划

范围基准：批准的范围说明书、WBS、WBS词典

WBS分解原则：

1、WBS必须是面向可交付成果的；

2、WBS必须符合项目范围；

3、WBS的底层工作应该支持计划和控制；

4、WBS中的元素必须有人负责，而且只由一个人负责；

5、WBS应控制在4-6层；

6、WBS应该包括项目管理工作，也要包括分包出去的工作；

7、WBS的编制需要所有（主要）项目干系人的参与；

8、WBS并非是一成不变的

范围说明书的内容：

产品范围描述、可交付成果、验收标准、项目的除外责任、项目需求、假设条件、制约因素

WBS分解步骤：

1、识别和分析可交付成果及相关工作；

2、确定WBS的结构和编排方法；

3、自上而下逐层细化分解；

4、为WBS组件制定和分配标识编码；

5、核实可交付成果分解的程度是否恰当

范围确认和质量控制的区别与联系？

需求文件的主要内容包括？

1、业务需求

（1）、可跟踪的业务目标和项目目标；

（2）、执行组织的业务规则；

（3）、组织的指导原则

2、干系人需求

对组织其他领域的影响；对执行组织内部或外部团体的影响；干系人对沟通和报告的需求

3、解决方案需求

功能和非功能需求；技术和标准合规性需求;支持和培训的需求；质量需求；报告需求；

4、项目需求

服务水平、绩效、安全和合规性等；验收标准

5、过度需求

6、与需求相关的假设条件、依赖关系和制约因素

需求跟踪矩阵的主要内容：

1、业务需要、机会、目的和目标；

2、项目目标；

3、项目范围/WBS可交付成果；

4、产品设计；

5、产品开发；

6、测试策略和测试场景；

7、高层级需求到详细需求。

缩短工期的方法：

赶工；快速跟进；使用高素质的资源或经验丰富的人员；缩小活动范围或降低活动要求；改进方法或技术；加强质量管理，减少返工。

赶工和快速跟进的区别？

资源平衡和资源平滑的区别？

总时差和自由时差的区别？

三点估算公式：

te期望时间；to乐观时间；tm是最可能时间，tp是悲观时间

贝塔分布（最乐观时间+4*最可能时间+最悲观时间）/6

三角分布：（最乐观时间+最可能时间+最悲观时间）/3

标准差公式：σ=（tp-to）/6

挣值分析：pv计划价值 ev是挣值 ac实际成本

etc 完工尚需估算 bac完工预算 eac 完工估算

成本偏差 cv=ev-ac

进度偏差=sv=ev-pv

成本绩效指数cpi=ev/ac

进度绩效指数spi=ev/pv

非典型偏差etc=bac-ev

典型偏差：etc=（bac-ev）/cpi

完工估算：eac=ac+etc

完工偏差：vac=bac-eac

为了按计划（bac）完成，必须维持的效率：

完工尚需绩效指数：tcpi=（bac-ev）/（bac-ac）

为了按当前完工估算（eac）完成，必须维持的效率：

完工尚需绩效指数tcpi=（bac-ev）/(eac-ac)

质量管理常见问题：

项目经理质量管理经验和能力不足；

项目的软件研发人员不应该兼任项目质量管理人员；

没有依据本项目的相关资料制订质量管理计划/不能依据个人经验制订；

没有生成质量测量标准；

质量控制应该贯穿全过程，不应该在X月才开始检查；

没有进行质量审计；

没有对项目成员开展质量培训；

项目经理没有对质量检查中发现的问题进行记录；

针对发现的不符合项，没有采取正式的纠正及改进措施，也没有跟踪纠正及改进措施的落实情况

资源管理常见问题

没有制定资源管理计划；

没有制定团队章程；

资源管理计划没有明确团队的角色职责导致后期出现纠纷/问题；

没有为核心岗位设置AB岗，导致项目进度滞后；

估算活动资源不到位/没有产出项目的资源需求；

没有及时组织有效的团队建设情况；

缺乏培训，或培训占用太多精力；

没有及时发现冲突，或没有进行良好的冲突管理；

没有控制资源，设备未按时归还；

团队阶段：形成、震荡、规范、发挥、解散

冲突发展的阶段：潜伏、感知、感受、呈现、结束

冲突解决办法：合作/解决问题；强迫/命令；妥协/调解；缓和/包容；撤退/回避

团队章程的内容：团队价值观、沟通指南、决策标准和过程、冲突处理过程、会议指南、团队共识

沟通和干系人管理常见问题

1、识别干系人不全面；未识别干系人；

2、未编制沟通管理计划/干系人参与计划；

3、独自编制干系人清单不妥，应全体人员共同制定；

4、干系人沟通方式单一，只采用电子邮件/会议方式；

5、与各个干系人之间的沟通方法和频率不合理；

6、监督干系人参与不到位，项目经理发现干系人参与项目不积极后，未采取有效行动；

干系人等级册没有持续更新；

与高层沟通不力；

沟通渠道数：M=n*(n-1)/2

沟通方法：互动沟通、推式沟通、拉式沟通

权力/利益方格：

高 令其满意 重点管理

权力

低 监督（花最小精力） 随时告知

低 利益 高

风险管理常见问题

未制定风险管理计划/独自编制风险管理计划不妥；

根据自己经验制定风险管理计划不妥；

风险识别未贯穿项目始终；

风险登记册不应该由一人编制/不应该靠经验来编制；

没有进行风险定性分析/未进行风险排序；

没有进行风险定量分析；

风险应对措施不够全面；

风险监控不到位/出现了新的风险未及时更新风险登记册；

依据自己经验制定应对计划不妥，应依据定性风险分析的风险值开展定量风险分析排序后，制定风险应对计划；

没有进行风险审计/风险再评估。

风险管理计划的内容：风险管理策略、方法论、角色与职责、资金、时间安排、风险类别、干系人风险偏好、风险概率和影响、概率和影响矩阵、报告格式、跟踪

SWOT分析：优势、劣势、机会、威胁

风险登记册的内容：已识别风险的清单、潜在风险责任人、潜在风险应对措施清单

消极风险应对策略：规避、转移、减轻、接受

积极风险应对策略：开拓、提高、分享、接受

合同的内容：标的内容和范围；项目的质量要求；项目的计划、进度、地点、地域和方式；项目建设过程中的各种期限；技术情报和资料的保密；风险责任的承担；技术成果的归属；验收的标准和方法；价款、报酬及其支付方式；违约金或者损失赔偿的计算方法；解决争议的方法；名词术语解释

配置管理常见问题

没有编制配置管理计划；不应独自一人制定配置管理计划；

项目经理不应兼职配置管理员，应该配备专职的配置管理员；

配置库权限设置存在问题，不能给所有项目组成员开放全部操作权限；

没有建立配置库；

没有给所有的配置项进行配置标识；

配置控制没有做好/配置的变更没有走配置管理流程；

配置项在开发库修改后未经评审就放入受控库中；

版本管理存在问题，配置项更新后版本号并未更新；

没有做好配置审计工作；

没有及时进行配置管理回顾与改进；

没有对成员进行配置管理培训；

配置管理员/项目经理经验不足；

配置项状态分为：草稿、正式、修改

配置库分为：开发库、受控库、产品库

配置审计分为：功能和物理

配置管理活动包括：制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、配置管理回顾与改进

配置控制流程：变更申请、变更评估、通告评估结果、变更实施、变更验证与确认、变更的发布、基于配置库的变更控制

ITTO

输入：

项目章程、项目管理计划、项目文件（风险登记册、干系人登记册、问题日志、变更日志）、工作绩效数据、事业环境因素、组织过程资产

工具与技术：

数据收集、数据分析、数据表现、检查、会议、专家判断、审计、决策、项目管理信息系统、人际关系与团队技能

输出：

变更请求、工作绩效信息、项目管理计划更新、项目文件更新（风险登记册、干系人登记册、问题日志、变更日志）、组织过程资产更新

智能制造能力成熟度等级：一级（规划级）、二级（规范级）、三级（集成级）、四级（优化级）、五级（引领级）、

开始规划，核心业务；单一业务数据共享；跨业务数据共享；核心业务精准预测和优化；持续优化和创新。

现代化服务：1、基础服务2、生产和市场服务3、个人消费服务4、公共服务

先进制造业与现代服务业的融合表现出结合型、绑定型和延申型。

消费互联网以个人为用户，以日常生活为应用场景

本质是个人虚拟化，增强个人生活消费体验

智慧城市发展成熟度等级：一级（规划级）、二级（管理级）、三级（协同级）、四级（优化级）、五级（引领级）、

欢迎使用 WordPress。这是您的第一篇文章。编辑或删除它，然后开始写作吧！