收益：
- 能够在 CI/CD 背景下从创意到发布的端到端 QA 流程中设计人工智能和人工审批点的角色
- 在 CI/CD 中，不是授权 AI 自动“通过”测试，而是应用限制来保护机密数据和密钥
- 能够在授权范围内出于防御目的执行安全测试，并采用负责任的披露和道德透明度原则。
在之前的十个单元中，我们在各个任务中使用了人工智能：场景生成、自动化代码、错误报告、覆盖率分析、突变测试。最后一个单元将它们全部合并到一个负责任的工作流程中。现代 QA 不是一项在一个人的办公桌上完成的工作；而是一项工作。这是一个存在于 CI/CD（持续集成/持续交付——不断组合代码、自动测试并准备频繁且安全地发布的管道）中的过程。人工智能可以触及这个过程的每个阶段。但随着人工智能的力量不断增强，负责任地使用它的重要性也随之增强：隐私、安全测试权威、道德，最重要的是，将质量决策权留给人类。在本单元中，您将学习端到端流程和边界。
端到端人工智能驱动的 QA 流程
人工智能在功能从创意到发布的过程中的作用：
1.需求分析。 AI 会标记要求中的含糊之处和缺失的接受标准（“此规则没有说明密码最少有多少个字符”）。
2、测试设计。场景和案例草稿（单元 2）、边缘案例（单元 3）属于验收标准。
3.自动化。单元(6)、API(5)和UI(4)测试代码草案；每个都通过突变（10）得到证实。
4.CI/CD集成。每次代码合并时都会自动运行测试。 AI 起草管道配置 (YAML)、总结失败测试的日志、建议可能的根本原因。
5、发布决定。收集风险分析 (8) 和回归 (9) 结果，但由专家决定是否成功。
6、生产监控与反馈。直播中的错误成为未来的考验；人工智能提出了制造缺陷的回归案例。
提示：将 AI 设置为 CI/CD 中的一个层，“加速人工审核草稿”，而不是“编写测试并做出决策”。如果没有人工审查和批准，任何自动生成的测试都不应进入管道。
CI/CD 中的 AI：哪里是，哪里不是
舞台
人工智能适配
人是必不可少的
测试代码草案
是的
修改+突变
管道 YAML 草案
是的
身份验证+密钥检查
失败日志摘要
是的
根本原因确认
脆性测试诊断
是的
永久解决方案决定
“能有一个版本吗？”
不
专家判断和责任
自动“通过”测试
从不
—
注意：永远不要给人工智能一个像 CI/CD 中的“修复它以通过失败的测试”这样的命令。这违背了测试的目的并自动掩盖了错误。 AI可以解释错误，建议纠正；但“把测试涂成绿色”必须是一个人有意识的、理性的决定。
隐私、数据和安全：不可改变的边界
隐私。在测试环境中，实际客户数据、生产数据库副本、API 密钥和内部系统信息都是敏感的。不要将这些提供给公共人工智能工具。个人数据须遵守 KVKK 和类似法规；屏蔽日志和屏幕截图。尽可能使用合成（虚构）测试数据。
安全测试——防御性和授权性。本模块中学习的安全测试（授权/IDOR测试、文件上传限制、输入验证）仅用于在书面授权和定义的范围内测试您自己的产品。使用人工智能未经许可访问他人的系统、将真正的漏洞武器化或进行超出范围的测试既不道德又非法。当您发现安全漏洞时，请遵循负责任的披露原则——对漏洞保密并报告给相关方以便修复。
道德和透明度。请勿将人工智能产生的测试视为自己的作品；说明您正在团队内使用人工智能是透明的。你要对人工智能产生的输出的不准确性负责——“人工智能写的”不是借口。
弱提示/强提示
弱：“为 CI 设置测试管道。”
Strong：“为 GitHub Actions 起草 CI 工作流程 YAML：对每个 PR 运行单元 + API 测试，生成覆盖率报告，每周运行突变测试 (Stryker)。不要在代码中嵌入机密；仅使用机密引用。如果测试为红色，则阻止合并。这是一份草案；我将审查和编辑密钥管理和验证步骤。不要添加自动化测试“修复”或“迁移”步骤。”
强大的提示功能；它对保密性、人工审查和“禁止自动化测试”施加了限制。
四个可复制模板
1）端到端测试计划：
您的角色：高级 QA 领导。为以下功能起草从构思到发布的端到端测试计划：[功能 + 验收标准]。阶段：需求分析（不确定性）、测试设计、自动化层（单元/API/UI）、CI/CD 集成、发布决策标准、生产跟踪。分别指定人工智能和人类审批点在每个阶段的作用。
2）CI/CD管道概要：
[GitHub Actions/GitLab CI/Azure Pipelines] 的 CI YAML 草案：- PR 中的单元 + API 测试 + 范围 - 防止红色测试中的合并 - 仅包含机密的机密值；嵌入代码这是一个草案；我将审查关键管理和审批步骤。添加自动更正/通过测试步骤。
3）失败的测试日志分析：
在 CI 打印输出中，测试是红色的。检查日志；对故障进行分组，区分可能的根本原因，以及哪些可能是真正的故障，哪些可能是脆弱的测试/环境问题。如果存在个人数据，请将其屏蔽。决定和修正将由我决定。日志：[粘贴]
4) 安全/隐私预检查：
在将此测试数据/日志发送到 AI 工具之前，请检查：它是否包含个人数据、API 密钥、内部系统地址、生产数据？列出哪些区域（如果有）需要屏蔽/删除。按原样处理。内容：[粘贴]
三个迷你箱子
情况1——端到端流程的速度。一个团队通过人工智能驱动的端到端流程解决了新的“订阅续订”功能：预先标记需求不确定性，起草三层测试并进行突变验证，与 CI 相关。该功能将传统流程需要5天的测试周期缩短为2天；但每个阶段都保留了人工批准，并且需求不确定性（如果刷新失败会发生什么）在上线前就已关闭。
案例 2 — 从密钥泄漏中返回。一位开发人员让 AI 生成 CI YAML，AI 将一个真实的 API 密钥嵌入到 YAML 中作为示例。 “安全/隐私预检查”步骤抓住了这一点；密钥转换为秘密参考。如果没有审核步骤，密钥将泄漏到版本控制（git 历史记录）中。
案例 3——权限限制。一位团队成员出于“我很好奇”，想要将他学到的 IDOR 测试应用到业务合作伙伴的实时系统中。 QA 领导停下来：未经书面授权和定义范围，在另一个系统上进行安全测试是违法的。测试只在自己产品的测试环境中进行，具有权威性；公开责任方已通知相关团队。
常见错误
- 让人工智能做出发布决策。问“可以发布吗？”发送给人工智能并用答案代替签名。
- “通过”自动化测试。在 CI 中，让 AI 将测试涂成绿色；掩盖错误。
- 向车辆提供机密数据/钥匙。在无人监管的情况下共享生产数据、个人数据或 API 密钥。
- 未经授权的安全测试。攻击者在未经范围和许可的情况下在另一个系统上进行测试。
- 未经审查就将测试引入管道。自动运行AI sketch，无需人工批准。
- 把责任归咎于人工智能。通过说“人工智能写的”来捍卫不正确的输出。
总之
端到端 QA 是一个从需求延伸到生产跟踪并存在于 CI/CD 中的过程；在每个阶段，人工智能都会生成草稿、总结日志并提出根本原因建议。但界限是一成不变的：人类做出测试决定并发布批准； AI从来没有被赋予自动“通过”测试的权力；机密数据和钥匙不会进入车辆；出于防御目的，仅在书面授权和定义的范围内对您自己的产品进行安全测试，并以负责任的方式披露结果。使用人工智能时保持透明；您对输出的准确性负责。人工智能加速发展；您保证质量和道德。
应用任务
使用“端到端测试计划”模板为您自己项目的功能起草从想法到发布的计划；在每个阶段分别标记人工智能和人类认可点的作用。然后生成一个带有“CI/CD 管道大纲”的 YAML，并对这个 YAML 应用“安全/隐私预检查”以检查嵌入的密钥/秘密数据。最后，列出你的计划中所有的“人类决策”点，并用一句话解释为什么这些决策不能委托给人工智能。
清单
- [ ] 我将发布和测试决策归因于人类批准；我没有把它交给AI。
- [ ] 在 CI/CD 中我没有给予 AI 自动“通过/纠正”测试的权限。
- [ ] 在将机密数据、个人数据和密钥发送到车辆之前，我检查并屏蔽了它们。
- [ ] 我只考虑在书面授权和范围内对我自己的产品进行安全测试。
- [ ] 我本着负责任的披露原则解决了发现的漏洞。
- [ ] 我明确表示我使用了人工智能，并对输出的准确性负责。
模块考试
1. 在 QA 环境中如何最准确地定义“错误通过”？
- A) 虽然测试变绿，但实际上并没有确认任何行为； ✔ 即使代码损坏也不会变红
- B) 测试运行非常慢并且超时。
- C) 测试检测到真正的错误并变为红色
- D) 测试仅在生产环境中运行
解释：伪通过是指测试说“通过”，但实际上并未确认任何有意义的事情；测试是绿色的，但即使软件有故障，它也不会捕获它。这是人工智能在 QA 中的第一大风险，因为人工智能往往会产生看起来简洁但空洞的测试。
2、人工智能在测试和QA过程中最准确的定位是什么？
- A) 人工智能可以决定版本是否可以在未经人类批准的情况下发布
- B) 人工智能是产生草稿和想法的助手； “是否准备好发表”的决定和责任属于专家✔
- C) 人工智能只能编写文本，根本无法处理测试代码
- D）人工智能总是比人类写出正确的测试，因此不需要审查
描述：人工智能是测试助手、草稿生成器和创意倍增器；生成测试场景、自动化代码和报告草稿。然而，诸如“该软件是否已准备好发布”或“该测试是否已通过”之类的质量决策的责任和最终批准属于有能力的专家。
3. 基于错误大多发生在阈值处的事实，哪种测试设计技术是针对 18 岁年龄限制分别测试 17、18 和 19？
- A) 状态转换测试
- B) 决策表
- C) 边界值分析 ✔
- D）探索性测试
说明： 边界值分析基于对边界处错误最常发生的观察，并分别测试阈值（略低于、略高于和略高于极限）。它是一种强大的技术，可以补充等价类。
4. 在元素选择中应优先选择哪种方法来降低人工智能生成的 UI 测试自动化代码的脆弱性？
- A) 使用尽可能最长的 XPath 路径
- B）根据屏幕上的像素位置选择元素
- C) 使用基于 CSS 类名的选择器
- D) 使用添加的稳定属性（data-testid）进行测试✔
说明：长XPath路径和CSS类名极其依赖于页面结构和设计；只要界面发生最轻微的变化，它就会崩溃。专门为测试添加的稳定属性（例如 data-testid）不受设计更改的影响，并使测试更加稳健。
5. 为什么 API 测试仅仅检查 HTTP 状态码（例如 200）是不够的？
- A) 因为具有正确状态代码的正文数据可能已损坏，并且仅状态检查无法捕获此情况（伪信任）✔
- B) 因为状态码在 API 测试中根本不可靠
- C) 因为状态代码检查会大大减慢测试速度
- D) 因为 API 测试中永远不会返回状态代码
说明：虽然服务器返回正确的状态代码，但它可能会返回正文中损坏的数据（类型错误、字段缺失、计算值错误）。只看情况的测试看不到这一点并给出错误的信心。因此还应该添加模式/契约和业务规则验证。
6. 为什么在打印单元测试时告诉AI“根据接受规则手动计算期望值，不要引用函数的当前输出”很重要？
- A）因为手动计算运行测试速度更快
- B) 因为否则测试会将代码当前（可能有错误）的行为视为“正确”并确认该错误 ✔
- C) 因为人工智能根本无法计算小数
- D）因为测试中从未使用验收规则
解释：如果AI从被测函数的输出中得出期望值，那么即使该函数有故障，它也会使测试“通过”；也就是说，无论代码生成什么，测试都算为真。独立于接受规则计算期望值可确保测试是规则的看门人，而不是代码的镜子。
7. 以下哪一项是一份好的错误报告最显着的特征？
- A）尽可能长且技术性强
- B）由人工智能编写
- C) 包含开发人员可以独立遵循并产生错误的确定性再现步骤 ✔
- D）这只是一个屏幕截图
说明：错误报告的真正价值在于开发人员无需您的帮助即可重现错误。从头开始的确定性、可追溯的复制步骤确保了这一点；如果缺少这些步骤，报告通常会因“无法生成”而关闭。
8. 主页公司名称拼写错误错误的严重性和优先级关系最准确的表述是什么？
- A）强度和优先级应始终具有相同的值
- B）这个错误的严重性和优先级肯定很低
- C) 严重性和优先级是同一个概念，一个标签就足够了
- D) 技术强度可能较低，但业务优先级（声誉）可能较高；两者评价不同✔
说明：严重性是错误的技术影响（拼写错误在技术上较低），优先级是需要修复的紧急程度（较高，因为它是每个访问者都会看到的声誉元素）。两者并不总是朝着同一个方向发展；此示例是低严重性-高优先级情况。
9. 对 90% 线路覆盖率的测试套件最准确的解释是什么？
- A) 它表明这些行已被执行，但并不能证明它们的行为正确； ✔ 高覆盖率可能会产生虚假信心
- B) 最终证明 90% 的软件没有错误
- C) 它是优秀测试质量的明确衡量标准。
- D) 表示不再需要编写任何额外的测试
说明：行覆盖表示只执行了行；它并不能证明它会产生正确的结果。即使使用无断言测试，也可以实现 90% 的覆盖率。范围是一张“从未看过哪里”的地图，而不是“一切都经过测试”的保证；实际的保护是通过突变测试来衡量的。
10. 在基于风险的测试中，如何计算功能的风险以指导有限的测试工作？
- A）仅按代码行数
- B) 将故障概率与其故障时产生的影响相乘 ✔
- C) 仅按照功能开发的顺序
- D）仅优先考虑最容易为其编写测试的功能
说明：在基于风险的测试中，风险评估为概率=概率（损坏的可能性）×影响（损坏时的损坏）。高概率和高影响领域（支付、身份验证）值得最严格的测试，而低×低领域则接受轻度测试。
11. 即使代码没有改变，在有时通过有时失败（脆弱/片状）的测试中添加重试的主要风险是什么？
- A) 缩短测试的运行时间
- B) 降低覆盖率
- C) 掩盖真正的并发错误或根本原因并抑制症状 ✔
- D) 更改测试名称
说明：重试是一种诊断工具，而不是治疗方法。优柔寡断常常来自于实际的竞赛状况或成瘾；通过重试使测试“通过”会掩盖这个真正的错误，并可能在现场造成严重的问题。必须首先找到根本原因。
12. 突变测试是衡量测试套件是否真正具有保护作用的最诚实的方法，它是如何工作的？
- A）通过测量测试的运行速度
- B）通过计算编写了多少行代码
- C）通过以不同的顺序运行测试
- D) 通过故意在代码中创建小中断并测量测试是否捕获它们 ✔
描述：突变测试会在源代码中产生小的故意扭曲（突变）；一个好的测试套件应该捕获这些扭曲并变成红色。未捕获（幸存）的突变表明测试未保留该行为。突变分数是比覆盖率更诚实的质量衡量标准。
13. 执行安全测试（例如授权/IDOR测试）时要遵循的主要限制是什么？
- A) 只能在其自己的产品上、在书面授权和规定范围内、出于防御目的进行✔
- B）它可以自由地应用于任何感兴趣的系统
- C) 无需许可即可在商业伙伴的现网系统上试用
- D) 发现的任何漏洞应立即公开发布。
说明：本模块中学习的安全测试仅用于在书面授权和定义的范围内测试您自己的产品以用于防御目的。未经许可访问他人的系统或执行超出范围的测试既不道德又非法；发现的任何漏洞都会通过负责任的披露进行报告。
14. CI/CD 管道中不应该赋予 AI 哪些权限？
- A) 总结失败的测试日志
- B) 自动“通过”失败（红色）测试或将其涂成绿色的权力✔
- C) 建议测试代码草案
- D) 管道 YAML 文件起草
描述：AI可以在CI/CD中生成测试代码大纲、管道YAML和日志摘要；然而，永远不应该提供自动“通过/修复”失败测试的能力。这违背了测试的目的并自动掩盖了错误。将测试涂成绿色应该是一个人有意识且理性的决定。