1. 项目概述为什么选择 Midscene.js 来搭建 UI 自动化测试系统最近几年前端技术栈的复杂度和迭代速度肉眼可见地增长一个稍微像样点的应用动辄就是 React/Vue 各种状态管理 组件库页面交互逻辑也越来越重。随之而来的就是 UI 自动化测试的难度和成本直线上升。传统的基于 Selenium 或 Puppeteer 的测试脚本写起来费劲维护起来更费劲页面结构一变选择器就失效测试用例就得跟着改团队里负责测试的同学经常为此头疼。正是在这种背景下我注意到了 Midscene.js。它不是一个全新的轮子而是在 Puppeteer 和 Playwright 这类现代浏览器自动化工具之上构建的一套声明式、场景驱动的测试框架。它的核心思想很有意思把测试用例看作是一系列用户操作场景Scene的集合然后用一种接近自然语言的 JSON 或 YAML 来描述这些场景。比如“点击登录按钮”、“在搜索框输入关键词并回车”、“验证搜索结果列表的第一项包含某个文本”。你不需要关心底层是用的哪个 CSS 选择器也不需要写一堆await page.click(‘#submit-btn’)这样的命令式代码。我第一次接触 Midscene.js 时最打动我的就是它的“智能”定位能力。它内置了多种定位策略会智能地尝试通过文本内容、组件角色ARIA、甚至是视觉特征来定位元素这大大降低了因前端 DOM 结构微调而导致的测试用例“脆断”。对于需要快速响应业务变化、追求测试稳定性的团队来说这无疑是个福音。所以这次实战的目标很明确从零开始搭建一套基于 Midscene.js 的智能 UI 自动化测试系统。这套系统不仅要能跑通基础的测试用例还要融入持续集成CI流程实现测试报告的自动生成与通知最终形成一个稳定、可维护的自动化测试闭环。无论你是前端开发者想为自己的项目加一道质量保障还是测试工程师在寻找更高效的自动化方案这篇文章都能给你提供一条清晰的路径。2. 核心设计思路构建一个健壮且易维护的测试架构在动手写第一行配置之前我们先得把架构想清楚。一个随意的、脚本堆砌式的自动化项目最终必然会陷入维护地狱。我们的目标是构建一个系统而不仅仅是几个脚本。2.1 分层设计让关注点分离我借鉴了经典的测试金字塔和页面对象模型Page Object Model, POM思想并结合 Midscene.js 的特点设计了四层结构场景层Scene Layer这是 Midscene.js 的核心。每个.scene.json或.scene.yml文件定义了一个完整的用户操作流程比如“用户登录并创建一条待办事项”。这一层只关心“做什么”不关心“怎么做”和“在哪里做”。它的可读性极高产品经理或非技术同学也能看懂大概逻辑。页面对象层Page Object Layer这一层封装了具体页面的元素定位和基础操作。虽然 Midscene.js 的智能定位减少了对精确选择器的依赖但对于复杂页面或高频使用的元素集中管理定位信息依然是最佳实践。我们可以创建一个pages目录里面存放各个页面的类例如LoginPage、HomePage。这些类里提供诸如getUsernameInputSelector()的方法返回一个 Midscene.js 兼容的定位描述符比如{ text: ‘用户名’ }。测试用例层TestCase Layer这一层使用 Jest、Mocha 或 Vitest 等测试运行器组织和管理场景。一个测试用例文件如login.spec.js会引入相关的页面对象和场景文件并可能包含一些前置条件如准备测试数据、后置清理以及断言。Midscene.js 提供了与这些测试运行器无缝集成的运行器。系统与CI层System CI Layer这是最顶层负责运行整个测试套件、生成报告、处理环境变量、与 CI/CD 平台如 GitHub Actions, Jenkins集成。我们会配置不同的运行配置文件来区分本地开发测试和 CI 环境下的无头浏览器测试。注意不要试图把所有逻辑都塞进场景文件。场景文件应保持简洁描述用户意图。复杂的业务逻辑、数据准备和清理应该放在测试用例层或专门的工具函数中。2.2 目录结构规划清晰的目录结构是项目可维护的基石。以下是我推荐的结构smart-ui-test-system/ ├── package.json ├── midscene.config.js # Midscene.js 主配置文件 ├── jest.config.js (或其他测试框架配置) ├── .github/workflows/ # GitHub Actions CI 配置 │ └── ui-test.yml ├── src/ │ ├── scenes/ # 场景层 │ │ ├── login.scene.json │ │ ├── search.scene.yml │ │ └── checkout.scene.json │ ├── pages/ # 页面对象层 │ │ ├── LoginPage.js │ │ ├── HomePage.js │ │ └── CheckoutPage.js │ ├── tests/ # 测试用例层 │ │ ├── login.spec.js │ │ ├── search.spec.js │ │ └── checkout.spec.js │ ├── fixtures/ # 测试夹具如静态数据、Mock 响应 │ │ └── test-data.json │ ├── utils/ # 工具函数 │ │ ├── test-helper.js │ │ └── report-generator.js │ └── runners/ # 自定义运行器如果需要 │ └── custom-runner.js ├── reports/ # 测试报告输出目录 │ ├── html/ │ └── junit/ └── screenshots/ # 失败用例截图可选这个结构将不同职责的代码清晰地分开无论是新增场景、修改页面元素还是调整 CI 流程都能快速定位到相关文件。2.3 技术选型考量测试运行器选择 Jest我选择 Jest因为它开箱即用内置断言库、Mock 功能和代码覆盖率报告生态丰富。Midscene.js 对其有很好的支持。当然你也可以用 Mocha Chai 的组合看团队习惯。场景描述语言用 JSON 还是 YAMLJSON 更通用无需额外解析器YAML 在书写多步骤场景时凭借其缩进格式可读性可能更好。我个人偏好 JSON因为它在 JS 项目中更自然且不易因缩进错误导致解析失败。但团队如果更熟悉 YAML也完全没问题Midscene.js 都支持。报告系统除了 Jest 自带的终端输出我们还需要更直观的 HTML 报告用于归档和分享。jest-html-reporter或jest-stare是不错的选择。同时为了 CI 平台如 Jenkins能解析测试结果生成 JUnit 格式的 XML 报告也很有必要可以使用jest-junitreporter。3. 从零开始的环境配置与核心依赖安装理论说完我们开始动手。第一步就是初始化项目并安装核心依赖。3.1 初始化项目与安装依赖打开终端创建一个新目录并初始化 npm 项目mkdir smart-ui-test-system cd smart-ui-test-system npm init -y接下来安装 Midscene.js 及其 CLI 工具、测试运行器 Jest以及浏览器自动化引擎。Midscene.js 底层默认使用 Playwright因为它对现代浏览器支持更好且自带浏览器内核无需单独安装 Chrome/Chromium。npm install --save-dev midscene midscene/cli jestPlaywright 浏览器安装比较特殊需要通过其自带的命令来安装npx playwright install chromium --with-deps这个命令会下载 Chromium 浏览器及其所有依赖项确保在不同环境下都能运行。如果你还需要测试 Firefox 或 WebKit可以把chromium替换为firefoxwebkit或直接使用all。3.2 配置 Midscene.js在项目根目录创建midscene.config.js文件。这是 Midscene.js 的核心配置文件。// midscene.config.js module.exports { // 指定浏览器类型这里我们使用已安装的 chromium browserType: chromium, // 浏览器启动选项 launchOptions: { headless: true, // CI 环境下通常为无头模式本地调试可设为 false slowMo: 50, // 操作间隔慢速方便观察生产环境可设为 0 或移除 args: [--no-sandbox, --disable-setuid-sandbox], // 适用于 Docker/CI 环境 }, // 视口大小 viewport: { width: 1920, height: 1080 }, // 全局超时设置毫秒 timeout: 30000, // 默认 30 秒 // 场景文件默认存放路径 scenesDir: ./src/scenes, // 自定义步骤或断言后面会详细讲 // extensions: ./src/extensions, // 基础 URL你的被测应用地址 baseURL: process.env.APP_BASE_URL || http://localhost:3000, // 报告输出配置 reporters: [ [html, { outputDir: ./reports/html }], [junit, { outputDir: ./reports/junit }] ] };这里有几个关键点headless: true表示在无图形界面的模式下运行浏览器节省资源适合 CI。本地调试时可以设为false看着浏览器自动操作非常直观。slowMo在调试时非常有用它让每个操作都有个微小延迟你能看清发生了什么。args中的--no-sandbox参数在 Linux 服务器如 Docker 容器中通常是必须的否则可能无法启动浏览器。baseURL通过环境变量APP_BASE_URL动态获取这让我们能轻松切换测试环境开发、测试、预生产。3.3 配置 Jest创建jest.config.js文件// jest.config.js module.exports { // 测试文件匹配模式 testMatch: [**/src/tests/**/*.spec.js], // 测试环境我们使用 Midscene.js 提供的环境 testEnvironment: midscene/jest-environment, // 在每个测试文件执行前运行用于全局设置 setupFilesAfterEnv: [rootDir/src/tests/setup.js], // 收集测试覆盖率 collectCoverage: false, // UI 测试通常不收集代码覆盖率可按需开启 coverageDirectory: ./coverage, // 报告生成器 reporters: [ default, [jest-html-reporter, { pageTitle: UI自动化测试报告, outputPath: ./reports/test-report.html, includeFailureMsg: true, includeConsoleLog: true, }], [jest-junit, { outputDirectory: ./reports/junit, outputName: junit.xml, }] ], // 全局超时 testTimeout: 120000, // 单个测试用例超时时间2分钟 };这里我们指定了测试文件的位置使用了midscene/jest-environment这个专门的环境它负责在测试前后启动和关闭浏览器。setupFilesAfterEnv指向一个设置文件我们接下来创建它。3.4 编写全局测试设置文件创建src/tests/setup.js文件。这个文件会在每个测试套件运行前执行是初始化的好地方。// src/tests/setup.js const { setupGlobalContext } require(midscene/jest-environment); // 你可以在这里进行一些全局的初始化操作 // 例如读取环境变量初始化全局状态或者注册自定义的 Midscene 扩展 beforeAll(async () { // 如果 Midscene 环境没有自动设置全局 context你可以在这里手动初始化 // 但通常 midscene/jest-environment 已经处理好了 console.log(测试基础URL: ${process.env.APP_BASE_URL || http://localhost:3000}); }); afterAll(async () { // 所有测试结束后执行可以用于清理全局资源 });至此最基础的环境和框架配置就完成了。接下来我们将进入核心部分编写页面对象和场景。4. 编写页面对象与智能场景描述这一部分是整个系统的血肉直接决定了测试用例的稳定性和可读性。4.1 创建页面对象Page Object我们先以一个简单的登录页面为例。创建src/pages/LoginPage.js。// src/pages/LoginPage.js class LoginPage { // 元素定位描述符使用 Midscene 支持的格式 // 它不一定是严格的 CSS 选择器可以是文本、角色等 selectors { usernameInput: { placeholder: 请输入用户名/邮箱 }, // 通过 placeholder 定位 passwordInput: { placeholder: 请输入密码 }, loginButton: { text: 登录 }, // 通过按钮文本定位 errorMessage: { css: .ant-alert-error }, // 必要时仍可使用 CSS 选择器 }; // 页面 URL 片段 get path() { return /login; } // 封装页面操作 async goto(page) { // page 对象由 Midscene 注入 const baseURL process.env.APP_BASE_URL || http://localhost:3000; await page.goto(${baseURL}${this.path}); } async fillUsername(page, username) { // 使用 Midscene 提供的智能定位和操作 // 这里演示的是直接使用 Playwright 的 page 对象实际 Midscene 场景中会更简洁 const locator page.locator(this.selectors.usernameInput); await locator.fill(username); } // ... 其他方法如 fillPassword, clickLogin 等 } module.exports new LoginPage();页面对象的核心价值在于将元素定位信息从测试用例中剥离并集中管理。如果前端的登录按钮文本从“登录”改成了“Sign In”你只需要在这个文件里修改loginButton的定位符所有用到这个按钮的测试用例都无需改动。实操心得不要过度封装。对于简单的输入、点击操作在场景文件中直接描述可能更清晰。页面对象更适合封装复杂的、重复的操作序列或者那些定位策略需要特别处理的元素。4.2 编写第一个智能场景Scene现在我们来创建一个登录场景。创建src/scenes/user-login.scene.json。{ name: 用户登录成功场景, steps: [ { action: goto, url: /login, description: 导航到登录页面 }, { action: fill, target: { placeholder: 请输入用户名/邮箱 }, value: testuserexample.com, description: 输入用户名 }, { action: fill, target: { placeholder: 请输入密码 }, value: Password123, description: 输入密码, options: { secret: true } // 标记为敏感信息报告中会隐藏 }, { action: click, target: { text: 登录 }, description: 点击登录按钮 }, { action: waitForNavigation, description: 等待页面跳转, options: { waitUntil: networkidle } }, { action: assert, assertion: urlContains, expected: /dashboard, description: 验证跳转到了仪表盘页面 }, { action: assert, assertion: textContent, target: { css: .welcome-message }, expected: 欢迎回来testuser, description: 验证欢迎语显示正确 } ] }这个 JSON 文件描述了一个完整的用户登录流程。它的可读性非常高即使不懂代码的人也能理解。Midscene.js 的执行引擎会解析这个文件并按照步骤顺序执行。Midscene.js 的“智能”体现在哪里灵活的定位器target字段可以使用{ text: ‘登录’ }、{ placeholder: ‘…’ }、{ role: ‘button’ }等多种方式而不局限于脆弱的 CSS 路径。引擎会尝试最合理的方式去找到元素。内置等待与重试像click、fill这样的操作Midscene.js 内部会等待元素变得可交互可见、可点击并包含自动重试机制这极大地增强了测试的稳定性避免了因页面加载或渲染稍慢而导致的失败。丰富的断言除了例子中的urlContains、textContent还支持toBeVisible、toHaveCount、toHaveValue等语法直观。4.3 创建对应的测试用例文件场景写好了我们需要一个 Jest 测试用例来驱动它。创建src/tests/login.spec.js。// src/tests/login.spec.js const { runScene } require(midscene); const LoginPage require(../pages/LoginPage); describe(用户登录功能, () { // 每个测试用例开始前可以跳转到登录页 beforeEach(async () { // 这里演示了如何使用页面对象实际 Midscene 场景中 goto 步骤已包含 // await LoginPage.goto(page); // 如果 page 对象可全局访问 }); it(应该使用正确凭据登录成功, async () { // 运行我们定义好的场景 const result await runScene(user-login.scene.json); // runScene 会返回一个结果对象包含步骤执行详情和最终状态 expect(result.status).toBe(passed); // 你也可以在这里添加额外的 Jest 断言 // 例如检查页面上的某个特定元素 // const welcomeText await page.textContent(.welcome-message); // expect(welcomeText).toContain(testuser); }); it(应该在使用错误密码时登录失败, async () { // 我们可以通过覆盖场景步骤中某个字段的值来复用场景 const result await runScene(user-login.scene.json, { overrides: { steps: [ {}, // 第一步 goto 保持不变 {}, // 第二步 用户名保持不变 { value: WrongPassword }, // 只覆盖第三步的密码 {}, // 后续步骤... { expected: /login }, // 覆盖断言期望仍在登录页 { expected: 用户名或密码错误 } // 覆盖断言期望看到错误信息 ] } }); expect(result.status).toBe(passed); }); });在这个测试用例中我们使用runScene函数来执行场景。第二个测试用例展示了如何通过overrides参数动态修改场景中的某些步骤比如输入错误的密码从而实现场景的复用避免为每个边界情况都写一个完整的场景文件。5. 运行测试与结果解析配置和代码都写好了是时候让测试跑起来了。5.1 本地运行与调试首先确保你的被测应用比如一个本地开发服务器已经在运行假设在http://localhost:3000。在package.json中添加 scripts 命令{ scripts: { test: jest, test:ui: jest --watchAll, // 监听模式文件变化自动运行测试 test:debug: jest --runInBand --no-coverage, // 串行运行方便调试 scene:run: midscene run ./src/scenes/user-login.scene.json // 单独运行某个场景 } }现在运行npm test或npm run test:uiJest 会启动浏览器执行我们写的测试用例。本地调试技巧无头模式在midscene.config.js中设置headless: false你可以亲眼看到浏览器的每一步操作非常直观。慢动作设置slowMo: 10001秒让操作慢下来方便观察细节。开发者工具即使在无头模式下你也可以通过配置launchOptions中的devtools: true来打开开发者工具。失败截图Midscene.js 通常会在步骤失败时自动截图。你可以在配置中指定截图保存路径方便事后分析。5.2 解读测试报告测试运行完毕后报告会输出在终端和我们在配置中指定的目录。终端输出Jest 会给出清晰的通过/失败总结以及失败用例的错误堆栈。HTML 报告打开./reports/test-report.html你会看到一个更详细的网页报告。它通常包含测试套件概览、每个测试用例的通过状态、执行时间以及详细的步骤日志。对于失败的步骤通常会附上截图和错误信息这是排查问题的利器。JUnit 报告./reports/junit/junit.xml是一个标准格式的 XML 文件可以被 Jenkins、GitLab CI 等 CI/CD 平台读取用于展示测试趋势和结果。一个高效的排查流程是先在终端看哪个用例失败了然后立刻打开 HTML 报告查看失败步骤的截图和前后操作日志能快速定位到是前端元素变了还是网络请求超时或是断言逻辑有问题。6. 集成到持续集成CI流水线自动化测试只有集成到 CI/CD 流程中才能真正发挥价值实现“质量门禁”。这里以 GitHub Actions 为例。6.1 配置 GitHub Actions Workflow创建.github/workflows/ui-test.yml文件name: UI Automation Tests on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest container: image: mcr.microsoft.com/playwright:v1.40.0-focal # 使用包含 Playwright 的官方镜像 steps: - name: Checkout repository uses: actions/checkoutv3 - name: Setup Node.js uses: actions/setup-nodev3 with: node-version: 18 cache: npm - name: Install dependencies run: npm ci # 使用 ci 命令确保依赖锁一致 - name: Install Playwright Browsers run: npx playwright install chromium --with-deps - name: Run UI Tests run: npm test env: APP_BASE_URL: ${{ secrets.APP_BASE_URL }} # 从 GitHub Secrets 读取测试环境地址 # 可以设置其他环境变量如测试用户账号密码务必使用 Secrets TEST_USERNAME: ${{ secrets.TEST_USERNAME }} TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }} - name: Upload test reports if: always() # 无论测试成功与否都上传报告 uses: actions/upload-artifactv3 with: name: ui-test-reports path: | reports/ screenshots/ # 如果有截图也上传 retention-days: 7这个工作流做了以下几件事在代码推送到主分支或发起 Pull Request 时触发。在一个包含 Playwright 的 Docker 容器中运行确保环境一致性。安装项目依赖和浏览器。运行npm test并通过环境变量APP_BASE_URL指定被测应用的地址例如测试环境的 URL。无论测试结果如何都将生成的报告HTML、JUnit和截图打包上传为工件Artifact供后续下载查看。6.2 关键 CI 配置要点环境变量管理绝对不要将测试环境的真实 URL、用户名、密码等硬编码在代码或配置文件中。务必使用 GitHub Secrets、GitLab CI Variables 或类似机制进行管理。上面的secrets.APP_BASE_URL就是在仓库的 Settings - Secrets and variables - Actions 中设置的。使用特定 Docker 镜像直接使用mcr.microsoft.com/playwright官方镜像它已经预装了所有必要的系统依赖和浏览器避免了在 CI 机器上安装浏览器时的各种兼容性问题。报告归档通过actions/upload-artifact保存测试报告至关重要。当测试失败时你可以下载这些工件查看 HTML 报告和失败截图这是远程调试的主要依据。失败通知可以进一步扩展工作流在测试失败时通过 Slack、钉钉、企业微信或邮件发送通知并附上报告链接。7. 高级技巧与常见问题排查系统搭建起来并能稳定运行后我们可以关注一些高级特性和常见坑点让系统更强大、更可靠。7.1 使用自定义步骤与扩展Midscene.js 允许你注册自定义的步骤Actions和断言Assertions以满足特定业务需求。例如你的应用有一个复杂的富文本编辑器需要上传图片。你可以创建一个自定义的uploadImage步骤。首先创建一个扩展文件src/extensions/custom-actions.js// src/extensions/custom-actions.js const { registerAction } require(midscene); registerAction(uploadImage, async (page, context, { target, filePath }) { // page 是 Playwright 的 Page 对象 // context 包含当前场景运行上下文 // target 是定位器 // filePath 是从场景步骤中传递过来的参数 const locator page.locator(target); // 假设这是一个通过 input[typefile] 上传的组件 // 可能需要先点击某个按钮触发文件选择对话框但 Playwright 可以直接设置文件 await locator.setInputFiles(filePath); // 等待上传完成可能是等待某个提示元素出现或消失 await page.waitForSelector(.upload-success-toast, { state: visible, timeout: 10000 }); });然后在midscene.config.js中引入这个扩展// midscene.config.js module.exports { // ... 其他配置 extensions: ./src/extensions, // 指向扩展文件所在目录 };现在你就可以在场景文件中使用这个自定义步骤了{ action: uploadImage, target: { css: .editor-upload-input }, filePath: ./fixtures/test-image.png, description: 上传文章封面图 }7.2 处理动态数据与等待策略UI 自动化测试最大的挑战之一就是处理异步加载和动态内容。智能等待Midscene.js 的内置步骤如click,fill已经包含了等待元素可用的逻辑。但对于自定义步骤或复杂场景你可能需要手动等待。waitForSelector: 等待某个元素出现或消失。waitForLoadState: 等待页面达到某个加载状态load,domcontentloaded,networkidle。waitForFunction: 等待页面中某个 JavaScript 条件成立。处理网络请求有时需要等待某个特定 API 调用完成。可以使用 Playwright 的page.waitForResponse(urlOrPredicate)方法。动态数据断言如果页面上显示的数据是动态生成的如订单号、时间戳断言不能写死。可以使用正则表达式或函数断言。{ action: assert, assertion: textContent, target: { css: .order-id }, expected: /^订单号\\d{10}$/, // 使用正则匹配 description: 验证订单号格式正确 }7.3 常见问题排查实录以下是我在实战中遇到的一些典型问题及解决方案问题1测试在 CI 上失败但在本地成功。可能原因1环境差异。CI 环境的应用版本、数据状态可能与本地不同。解决方案确保 CI 测试环境是独立、稳定且数据可预测的。使用数据库快照或每次测试前重置数据。可能原因2资源不足或超时。CI 机器的性能可能较弱。解决方案增加全局timeout和testTimeout。在launchOptions中尝试禁用 GPU 加速args: [--disable-gpu]。可能原因3浏览器启动失败。常见于 Docker 环境。解决方案确保在launchOptions中加入了args: [--no-sandbox, --disable-setuid-sandbox]并且使用的是包含必要依赖的 Docker 镜像如官方 Playwright 镜像。问题2元素定位失败控制台报错 “TimeoutError: Locator not found”。可能原因1页面尚未加载完成或元素被动态渲染。解决方案在操作前增加一个明确的等待步骤等待某个标志性元素出现。检查 Midscene 步骤的target定位器是否过于严格尝试使用更宽松的定位方式如{ text: ‘提交’ }而不是复杂的 CSS 路径。可能原因2iframe 或 Shadow DOM。解决方案如果目标元素在 iframe 或 Shadow DOM 内部需要先定位到 iframe 或 Shadow Root。Midscene.js 可能需要对这类场景进行特殊处理查阅其文档或考虑使用 Playwright 的原生 API 在自定义步骤中处理。问题3测试执行速度慢。可能原因每个测试用例都重新启动浏览器、登录步骤间等待时间过长。解决方案复用浏览器上下文配置 Midscene/Jest 环境尝试复用同一个浏览器上下文Context而不是为每个测试打开新窗口。注意测试之间的状态隔离。并行执行Jest 默认是并行执行测试的。确保你的测试用例是独立的没有全局状态依赖以充分利用并行优势。优化等待检查slowMo配置在 CI 上设为 0。将不必要的waitForTimeout替换为更精确的waitForSelector。问题4测试报告中没有截图或截图不清晰。解决方案在 Midscene 配置或自定义步骤中确保在失败时调用了截图 API如await page.screenshot({ path: ‘screenshot.png’, fullPage: true })。对于 CI 环境截图路径应是绝对路径或相对于工作目录的确定路径并确保在upload-artifact步骤中包含了该路径。搭建这样一套系统并非一蹴而就从第一个简单的登录场景开始逐步覆盖核心业务流程再接入 CI每一步都会遇到不同的问题。但一旦这套系统稳定运行起来它所带来的质量信心和效率提升是巨大的。它不仅能捕捉到视觉和交互层面的回归问题更能作为一个活的、可执行的产品需求文档驱动开发者和测试者从用户视角去思考。