属性测试（PBT）是 Kiro Specs 中验证实现是否符合规格说明的核心机制。与只检验具体示例的传统单元测试不同，PBT 将自然语言需求（EARS 格式）转化为通用属性，自动生成数百乃至数千个测试用例，覆盖整个输入空间，通过"收缩"找出反例。Kiro 在设计阶段提取属性，在任务执行阶段运行测试，失败时自动定位具体场景并给出修复建议。

什么是 Spec 正确性验证？

"Spec 正确性"回答一个根本性问题：你的实现真的做到了你规格说明所要求的吗？当 AI 生成代码时，如何确认它符合你的意图？

核心概念

属性测试（Property-Based Testing）

属性测试（PBT）是向 AI 时代正确性验证方式转变的重要一步——从检验单个具体示例，转向在整个输入空间内验证通用属性。

传统单元测试只检验特定示例，无论人类还是 AI 来写，都受限于编写者自身的思维盲区。通过将自然语言规格说明自动转化为可执行属性并生成大量测试用例，Kiro 构建了一个强力反馈循环，帮助 AI 智能体和人类开发者共同构建更可靠的软件。

这种方法不仅能发现传统测试遗漏的 Bug，还在需求与验证测试之间保持清晰可追溯的关联。

PBT 无法保证彻底消灭所有 Bug，但它提供了比基于示例的测试强得多的正确性证据，是规格说明驱动开发的重要工具。

什么是属性（Property）？

属性是关于系统行为的通用陈述，表达系统中应当始终成立的不变量和契约，与具体数据无关。

对于满足特定前置条件的任意一组输入，某种预期行为总是成立。

在 Kiro 的规格说明体系中，这与 EARS 格式的需求完美对应：

"对于任意已认证用户和任意有效房源，该用户可以查看该房源。"

这捕捉了一条关于系统行为的通用规则，必须在所有有效场景中成立。

属性测试的工作方式

以一个二手车销售应用为例：

• 传统测试：用户将 5 号车收藏，5 号车出现在收藏列表
• 属性测试：对于任意用户和任意车辆，当用户将该车加入收藏时，系统应在其收藏列表中展示该车辆

PBT 会自动测试：用户 A 收藏 1 号车、用户 B 收藏 500 号车、姓名含特殊字符的用户、各种状态的车辆……数百种组合——发现边界情况，验证实现是否符合意图。

在此过程中，PBT 通过"收缩（shrinking）"不断寻找反例——类似于一支红队尝试攻破你的代码。当发现违例时，Kiro 可以自动更新实现，或提供选项让你决定是修复 spec、实现还是测试本身。

虽然不是形式化验证，但 PBT 为你永远不会手写的场景提供了正确性证据，展示你的实现是否真正符合你定义的行为。

属性测试与 Specs 集成

Kiro 将属性测试贯穿整个 Spec 工作流，从需求一直到实现验证。

工作流程

Kiro 从 EARS 格式的需求中提取属性（如"系统应允许已认证用户查看有效的二手车房源"），判断哪些属性可以进行逻辑测试，然后在你选择运行时生成数百乃至数千个随机测试用例。

设计阶段

在设计阶段，Kiro 从需求中提取属性并生成测试用例。这是工作流的第一步，Kiro 分析需求并识别可测试的属性。

将鼠标悬停在属性上可以看到它与原始需求的关联以及对应的任务链接。

任务执行阶段

在执行阶段，Kiro 对你的实现运行生成的 PBT 测试用例。注意：PBT 默认是可选的，你可以先专注于核心实现。属性测试运行后，可以看到指向生成代码的引用。

当属性测试失败时，Kiro 会识别具体的失败场景并提交审查。

你可以与 Kiro 对话，了解失败原因，并决定合适的修复方式——更新实现、调整测试，或完善需求本身。

常见问题

Q：属性测试（PBT）和普通单元测试有什么根本区别？

单元测试检验特定的示例（"当输入 X 时，输出应为 Y"），PBT 验证通用属性（"对于任意符合条件的输入，某种行为总是成立"）。PBT 的测试用例由框架自动生成，覆盖你可能想不到的边界情况，提供比人工编写测试用例更强的正确性保证。

Q：PBT 是否会显著增加测试运行时间？

PBT 会生成大量测试用例，通常比单元测试耗时更长。在 Kiro 的 Specs 中，PBT 默认是可选的，你可以先完成核心实现，再选择运行属性测试进行深度验证。对于关键路径和复杂业务逻辑，多花些时间在 PBT 上是值得的。

Q：属性测试失败时我应该怎么做？

Kiro 会显示具体失败场景（哪些输入触发了违例）。你有三种选择：（1）修复实现以满足属性；（2）如果测试本身有问题则调整测试；（3）如果需求与预期不符则重新审视规格说明。Kiro 可以帮助你分析失败原因并提供针对性建议。