你是否曾试图在毫无计划的情况下测试一款网页应用？这就好比蒙着眼睛搭建乐高城堡 —— 虽然并非完全不可能，但你很可能会遗漏一些部件。 这个项目记录了我手动软件测试的实践之旅：设计测试用例、记录缺陷，并将每个需求与真实证据相连接，而我的 “练兵场” 则是 Sauce Labs 演示站点。

👉 你可以在 GitHub 上查看完整项目、所有模板以及测试用例。

剧透一下：我甚至在结账流程中发现了一个真实存在的缺陷！

​​

图示展示了 QA 测试策略框架的流程：模板生成测试用例，测试用例产出证据，这些证据又反哺追溯矩阵与缺陷管理。 一步一个脚印构建软件质量 —— 在我的实战测试框架中，将模板、测试用例、证据以及追溯性有机连接在一起。

我的 QA 测试策略框架包含哪些内容

• 用于文档编写的 Markdown ：所有模板、测试用例以及缺陷报告均采用 Markdown 编写，以确保内容清晰且便于版本管理。
• Git 与 GitHub ：所有更改均在 GitHub 上进行跟踪与发布，使项目保持透明度，便于追踪。
• Sauce Labs 演示站点 ：所有真实世界的测试均在 Sauce Labs 演示站点上开展，这是一个高度仿真的 QA 实践 “游乐场”。
• 作为证据的截图 ：每一次测试结果 —— 无论是成功、错误还是缺陷，均配有存储于 /tests/evidence/ 路径下的截图作为支撑。
• VS Code ：作为我信赖的文本编辑器，用于对 Markdown 文件进行整理与编辑。

我开展此项目的原因（以及我期望学到的内容）

我期望突破理论层面的桎梏，真正从零开始打造一个手动 QA 项目 —— 不借助自动化手段，不走捷径，仅仅把基础工作做到极致。

我的目标十分明确：

• 利用 ISTQB 技巧实践测试用例的设计与记录工作。
• 学习如何以清晰且可追溯的方式将需求、测试以及证据紧密相连。
• 在一个类真实世界的背景下，熟悉缺陷管理与报告流程。

在我着手开始之前，我便意识到：拥有一个清晰的计划与结构能使整个测试流程变得不再那么令人畏惧，甚至增添几分乐趣。

1. 奠定基础：模板、追溯性以及证据

起初，我仅仅将模板视为繁琐的文书工作。然而，在使用 Markdown 编写首个测试用例之后，我瞬间领悟到模板在保持条理性以及避免遗漏关键细节方面所发挥的巨大作用。模板成为了我的 “乐高积木” —— 可重复使用、可靠且能轻松适配于各种场景。

• 模板 ：涵盖测试用例、缺陷报告以及缺陷生命周期等方面，所有模板均基于 ISTQB 最佳实践（你可以在 GitHub 上的模板文件夹中查看示例）。
• 追溯矩阵 ：我的 “操作手册” —— 将每个需求映射到至少一个测试用例（在 traceability-matrix.md 文件中可查看完整的映射关系）。
• 作为证据的截图 ：这就好比为你完成的乐高作品拍照留念 —— 直观地证明每个步骤均已落实完成。

我所收获的感悟：一份优质的模板能够节省时间、降低困惑风险，并且便于我们及时发现测试流程中的漏洞。

​​

QA 测试策略框架的项目文件夹结构，以树形图的形式呈现。

2. 设计与执行真实测试用例

• 等价划分：对部件进行分类

“等价划分是一种将软件单元的输入数据划分为若干等价数据类别的技术，测试用例即可从这些类别中衍生而出。”——Myers，《软件测试的艺术》

在针对登录功能的测试中，我将有效与无效输入归类至等价类别中，仅从每个分组中选取一个示例进行测试。这就好比按照颜色对乐高积木进行分类：你无需测试每一块积木，仅需从每堆中挑选一块进行验证即可。

我所收获的感悟：对相似案例进行归类能够节省时间，确保不会遗漏那些显而易见的缺陷（你可以在 equivalence-partitioning-login.md 文件中查看完整的登录测试用例）。

​​

展示 QA 测试策略框架中等价划分登录测试用例的 Markdown 文件。 采用等价划分法的登录测试用例：涵盖一名有效用户与一名无效用户，所有步骤均在 Markdown 文件中详尽记录。

​​

测试证据 ：当你尝试使用被锁定用户进行登录时，系统会给出怎样的反馈呢 —— 这是来自 Sauce Labs 演示站点的真实反馈。

• 边界值分析：对边缘情况进行测试

“边界值分析聚焦于各分区之间的边界。测试用例旨在针对边界值进行验证。”——Myers，《软件测试的艺术》

在结账表单中，我对邮政编码字段的上下限值进行了测试。

令人意外的是：当我输入 “12345678901”（超出规定长度一个字符）时，系统居然允许我继续后续操作！即便是演示站点，也可能潜藏着真实缺陷。

以下是揭示 Sauce Labs 演示站点中一个真实缺陷的完整流程：

​​

步骤 1 ：起始状态 —— 结账表单，尚未输入任何邮政编码。 在 Sauce Labs 演示站点的结账表单中输入无效的 11 位邮政编码（“12345678901”）。

​​

步骤 2 ：在结账表单中输入无效的 11 位邮政编码（“12345678901”）。 在 Sauce Labs 演示站点上，系统允许用户携带无效邮政编码进入结账概览页面。

​​

步骤 3 ：尽管邮政编码无效，系统仍允许用户进入结账概览页面 —— 一个真实缺陷就此浮出水面！

我所收获的感悟：永远不要低估边缘情况的影响力。并且一定要对你的发现进行记录 —— 在未来的某个时刻，其他人（或者你自己）将会因此而心怀感激（你可以在 boundary-value-analysis-postalcode.md 文件中查看边界值测试用例）。

​​

展示 QA 测试策略框架中邮政编码字段边界值分析测试用例的 Markdown 文件。 针对邮政编码字段的边界值分析测试用例，覆盖边缘情况与限制条件，所有内容均以 Markdown 格式呈现。

为了直观展示边界值分析的实际应用，我对邮政编码字段进行了测试，输入了一个 11 位的值（“12345678901”）—— 这一数值比预期的最大长度多出一个字符。

• 决策表测试：映射规则

对于结账流程，我借助决策表罗列出所有必填字段的组合情况。这就好比遵循一份食谱：如果你遗漏了一种食材（字段），最终结果将与预期大相径庭。

我所收获的感悟：决策表能够帮助我们直观地呈现复杂的规则，并且及时发现缺失的场景（你可以在 decision-table-testing-checkout.md 文件中查看决策表）。

​​

展示 QA 测试策略框架中结账流程决策表的 Markdown 文件。 结账流程的决策表测试用例，罗列出所有必填字段的组合情况以及对应的预期结果。

• 状态转换测试：遵循用户旅程

我针对购物车的不同状态（空置、已填充、结账）之间的转换进行了测试，模拟真实用户在应用中的操作流程。你可以将其想象为搭建乐高套装的步骤：每个阶段均依赖于前一个阶段的成果。

我所收获的感悟：状态转换能够揭示那些仅在步骤转换过程中才会显现的缺陷，而非孤立操作下所能发现的问题。

​​

展示从购物车空置状态到结账完成流程的状态转换图。 购物车以及结账流程的状态转换图，直观地展示了用户在整个购买旅程中的状态变迁。

3. 缺陷管理：一次简单测试发现一个真实缺陷

在边界值分析过程中，我发现了一个真实的缺陷：结账流程居然允许我使用无效的邮政编码继续后续操作。

• 地点 ：Sauce Labs 演示结账页面
• 方式 ：输入一个 11 位的邮政编码（本应失败）
• 我的应对措施 ：依据我所制定的模板记录下该缺陷，对其生命周期进行跟踪，并附上相关证据。

清晰且有条理的缺陷管理对于任何 QA 流程而言都至关重要。每份缺陷报告都应包含摘要、复现步骤、预期结果与实际结果，以及相关的证据内容。在报告提交后，缺陷将遵循一个生命周期流程：经过验证、优先级排序、指派、修复、重新测试，最终得以关闭 —— 或者如果问题仍然存在，则重新打开。

我所收获的感悟：清晰的缺陷报告能够使开发人员（以及未来的我）更加轻松地理解、复现并修复问题（你可以在 defect-life-cycle-example.md 文件中查看缺陷报告以及缺陷生命周期的相关内容）。

以下是基于我为该项目所构建的模板生成的示例记录，以此来具体阐释缺陷记录与跟踪在实际操作中的运作方式。

• 缺陷报告示例：接受无效邮政编码

​​

展示 QA 测试策略框架中记录无效邮政编码问题的示例缺陷报告，呈现所采用的字段与结构。 此示例缺陷报告生动地展示了该框架是如何记录一个无效邮政编码缺陷的，涵盖摘要、复现步骤以及证据字段等关键要素。

• 缺陷生命周期示例：无效邮政编码问题

​​

展示 QA 测试策略框架中无效邮政编码缺陷的状态流转表。 此示例缺陷生命周期表格直观地演示了在一个 QA 框架中，一个缺陷从报告提交到最终关闭的完整流转过程。

4. 追溯性与敏捷协作

“敏捷团队中的测试人员并非质量把关者，而是指引者与协作者，助力团队交付高质量成果。”——Crispin & Gregory，《敏捷测试》

我的追溯矩阵成为了整个项目的 “粘合剂”。每个需求都被映射到至少一个测试用例，从而轻松地呈现出需求的覆盖情况以及未覆盖之处。在敏捷团队中，此类文档堪称 “救生员”，因为在敏捷环境下，事务繁杂且节奏飞快，清晰的沟通至关重要。

我所收获的感悟：追溯性不仅仅是为了审计而存在 —— 它关乎你自己保持理智，以及实现更高效的团队沟通（你可以在 traceability-matrix.md 文件中查看完整的映射关系）。

追溯矩阵示例

​​

展示 QA 测试策略框架中需求与测试用例映射关系的追溯矩阵示例。 追溯矩阵示例，直观地呈现出需求与测试用例之间的关联，确保全面覆盖并便于追踪。

5. 影响力与指标：衡量价值所在

一个结构化的 QA 流程不仅仅关乎缺陷的查找 —— 更重要的是节省时间、降低风险以及构建信任。

• QA 经济学公式

价值 \= （所预防缺陷数量 × 平均每个缺陷成本） —— QA 投入成本

• 所预防缺陷数量 ：8 个（预估）
• 平均每个缺陷成本 ：250 美元（行业平均值）
• QA 投入成本 ：500 美元（我的时间成本） 价值 \= （8×250） —— 500 \= 2000 —— 500 \= 1500 美元

快速收益：

• 93% 的测试覆盖率
• 减少了每月 35 小时不必要的会议时长（多亏了详尽的文档记录）
• 凭借清晰的缺陷跟踪流程，实现更快的版本发布节奏

我所收获的感悟：优秀的 QA 不仅仅体现在技术层面 —— 它更是业务价值的体现。

6. 该项目带给我的启示（以及后续规划）

这不仅仅是一次简单的 “打勾作业” 或者文档编写工作。我学会了如何剖析需求、设计针对性测试，并且清晰地传达缺陷信息。最为重要的是，我深刻领悟到 QA 的核心本质在于通过每一次测试、每一条证据，逐步建立起信任。

后续计划：

我迫不及待地期望在下一个项目中探索网页自动化测试（借助 Playwright）以及 CI/CD 流程。如果你有任何相关建议，或者也愿意分享你的自动化测试之旅，欢迎与我建立联系！

👉 在 LinkedIn 上与我建立联系 💻 查看我的 GitHub 仓库

7. 附录：QA 证据快速参考指南

以下是该项目所生成的关键成果物以及证据的直接链接：

• 登录测试证据：login-valid-success.png
• 购物车流程测试用例：state-transition-testing-cart-checkout.md
• 缺陷生命周期示例：defect-life-cycle-example.md
• 追溯矩阵：traceability-matrix.md
• 缺陷报告示例：bug-report-example.md

如需查看所有文档以及证据的完整内容，请访问项目仓库。

8. 参考文献

• Myers, G. J., Sandler, C., & Badgett, T. (2011).《软件测试的艺术》
• Black, R. (2009).《软件测试过程管理》
• Crispin, L., & Gregory, J. (2009).《敏捷测试：测试人员与敏捷团队的实用指南》
• Knorr, F., & Gonçalves, P. (2020).《敏捷测试精要 —— 葡萄牙语 - 巴西版》
• Kaner, C., Bach, J., & Pettichord, B. (2002).《软件测试经验谈》
• Capers Jones, C. (2023).《软件质量经济学》

感谢您的阅读！对于完善此框架，您认为还有哪些可以改进之处？欢迎与我建立联系，共同分享 QA 故事。

‍