4.5 基于协作的测试方法
4.5.1 协作用户故事编写
用户故事代表对系统或软件的用户或购买者有价值的特征。用户故事包括三个关键方面，统称为“3C”：
• 卡片（Card）– 述用户故事的媒介（例如索引卡、电子板中的条目）。
• 对话（Conversation）– 解释软件的使用方式（可以是文档化或口头形式）。
• 确认（Confirmation）– 验收准则。
用户故事最常见的格式是“作为一个【角色】，我希望【要实现的目标】，以便于我可以【为角色创造商业价值】”，其次是验收准则。
协作编写用户故事可以使用头脑风暴和思维导图等技术。通过协作，同时兼顾到业务、开发和测试三个视角，团队可以共同理解应该交付的内容和共享愿景。
好的用户故事应该是：独立的（Independent）、可协商的（Negotiable）、有价值的（Valuable）、可评估的（Estimable）、小巧的（Small）和可测试的（Testable）（INVEST）。如果利益相关方不知道如何对用户故事进行测试，可能说明用户故事不够清晰，或者没有反映出有价值的内容，或者利益相关方需要在测试方面得到帮助。
4.5.2 验收准则
用户故事的验收准则是实现用户故事必须满足的条件，以便被利益相关方接受。从这个角度来看，验收准则可以被视为测试应该覆盖的测试条件。验收准则通常是对话的结果。
验收准则用于：
• 定义用户故事的范围。
• 利益相关方之间达成共识。
• 述正向和反向场景。
• 作为用户故事验收测试的依据。
• 实现准确规划和估算。
编写用户故事的验收准则有几种方式。最常见的两种格式是：
• 面向场景（例如，BDD 中使用的 Given/When/Then 格式）
• 面向规则（例如，要点验证列表，或输入–输出（I/O）映射的表格形式）
大多数验收准则可以在两种格式中任选一种进行记录。然而，团队也可以使用自定义格式，只要验收准则明确定义且无歧义。
4.5.3 验收测试驱动开发(ATDD)
ATDD 是测试先行（test-first）的一种方法。测试用例在实现用户故事之前创建。测试用例由具有不同视角的团队成员创建，例如客户、开发人员和测试人员。测试用例可以人工或自动化执行。
第一步是进行规格说明讨论会，团队成员分析、讨论和编写用户故事及其验收准则（如果尚未定义）。在此过程中解决了用户故事中的不完整、模糊或缺陷。下一步是创建测试用例，可以由整个团队或测试人员单独完成。测试用例基于验收准则，并且视为软件运行方式的实例。这将有助于团队正确实现用户故事。
由于实例和测试是相同的，因此这些术语常常可以互换使用。
通常，第一批测试用例是正向测试，确认在没有异常或错误条件下的正确行为，并包括按照预期执行的活动序列。在完成正向测试用例后，团队应进行反向测试。最后，团队还应涵盖非功能质量特性（例如性能效率、易用性）。测试用例应以利益相关方可以理解的方式进行描述。通常，测试用例包含自然语言形式的句子，包括必要的前提条件（如果有），输入和后置条件。
测试用例必须覆盖用户故事的所有特性，并且不应超出故事范围。不过，验收准则可能详细 述用户故事中描述的一些问题。此外，任何两个测试用例都不应该 述用户故事的相同特性。
当以测试自动化框架支持的格式进行捕获时，开发人员可以在实现用户故事描述的特征时编写支持代码，从而自动化测试用例。验收测试就成为可执行的需求。
原创文章，作者：iTestCat，保留所有权利，禁止转载，如若转载，请联系作者！
微信扫一扫 
支付宝扫一扫 
