46、敏捷开发中的测试与缺陷处理

敏捷开发中的测试与缺陷处理

1. 迭代中的关键要点

1.1 迭代审查与客户参与

迭代审查会议是展示团队成果并获取下一迭代反馈的好机会，但不要等到会议时才收集客户意见，应在整个迭代过程中让客户参与进来。这样可以在迭代中进行小调整，客户也能清楚预期结果。

1.2 理解业务需求

尽管迭代节奏快，但仍需花时间更好地理解业务。与业务人员交流，了解他们的工作以及新软件功能可改进之处。例如，团队成员与退休计划管理团队成员一起工作，能更好地理解工作并识别应用程序中的小改进，如添加额外数据、增加搜索过滤器或更改显示顺序等。还可以用流程图和维基页面记录所学内容，让其他团队成员受益。

1.3 测试任务的完成

敏捷测试人员应积极主动，不等工作上门。与程序员合作，让他们尽早产出可测试代码。例如，运输成本算法可独立测试，无需访问数据库或用户界面；也可在访问真实数据的服务完成前，用硬编码数据模拟用户界面，单独测试表示层的行为。

1.4 团队测试分工

程序员除了进行单元和集成测试外，还会定期自动化 GUI 背后的测试，编写功能测试用例。有时编写初始的“快乐路径”可执行测试，然后由测试人员添加更多用例；偶尔会编写所有功能测试用例。团队成员都要愿意承担手动测试任务。对于刚开始且未解决自动化需求的团队，应安排时间执行手动回归测试脚本和测试新功能，这有助于学习如何设计便于测试自动化的应用程序。

2. 应对测试危机与缺陷处理

2.1 测试危机的应对

即使是经验丰富的敏捷团队，在迭代结束时也常遇到测试危机。如故事耗时超预期或生产问题影响开发进度。当迭代即将结束而任务板上仍有大量测试卡片时，要将其视为问题信号，与团队一起找出问题所在，如程序员与测试人员合作是否紧密、是否有过多干扰等。解决办法是让整个团队参与，任何人都可参与测试任务。在每日站会中评估团队是否能完成所有故事，若多个故事可能无法完成，可选择放弃一个故事或减少部分故事的范围，专注于逐个完成故事。临近迭代结束时，程序员可能要停止开发新功能，转而进行测试任务。

2.2 缺陷处理方式

不同团队处理缺陷的方式不同：
- 一些团队发现缺陷后立即修复，编写单元测试重现问题，修复代码使测试通过，然后提交测试和修复内容。若后续有人破坏代码，测试会捕获回归问题。
- 一些团队认为在缺陷跟踪系统（DTS）中记录问题和修复情况有价值，尤其是代码发布后才发现的问题。他们还会分析生产中的缺陷模式，进行根因分析以防止类似问题再次出现，但缺陷系统不利于面对面交流如何提高代码质量。
- Lisa 和她的测试团队发现问题后，若程序员能立即修复，则无需记录；若程序员无法立即处理且可能遗忘问题，则写卡片或录入 DTS。

2.3 缺陷还是特性

在软件开发中，“什么是缺陷”是个古老问题。一些答案是偏离需求或行为不符合预期，明显的缺陷如输出错误或错误消息不正确。但关键在于用户对产品质量的感知，若客户认为是缺陷，那就是缺陷。在敏捷开发中，可与客户合作解决问题，客户看到产品后改变想法也没关系。最终，若问题需要修复，是缺陷还是特性并不重要，客户会确定优先级和价值主张。若客户更看重软件质量而非新功能，应尽量发现并修复所有缺陷。

2.4 技术债务与零缺陷目标

可将缺陷视为技术债务，缺陷在系统中未被发现的时间越长，影响越大。遗留缺陷会对代码质量、系统直观性、灵活性、团队士气和开发速度产生负面影响，修复有缺陷代码中的一个问题可能会暴露更多问题，导致维护任务耗时更长。一些人鼓励团队追求“零缺陷容忍度”，如新团队起初可能难以相信能实现，但有组织通过挑战各项目团队在迭代结束和发布时接近零缺陷，取得了一定效果。

2.5 零缺陷迭代案例

NT 服务的 QA 经理 Jakub Oleszkiewicz 讲述了团队如何在每次迭代结束时不遗留缺陷。关键在于测试人员、开发人员和业务分析师之间的出色沟通和纪律性。他们避免陷入瀑布式开发陷阱，保持代码和测试活动的一致性，在编写功能代码的同时设计和自动化测试用例，实际上在实践一种测试驱动开发方式。每天早上的 Scrum 会议通过简单对话确保团队内各职能组的一致性，发现缺陷时能迅速解决。

2.6 缺陷处理的选择

2.6.1 决定记录哪些缺陷

• 单元测试失败 ：对于采用测试驱动开发（TDD）且单元测试覆盖率高的团队，构建过程中的单元测试失败无需记录，这是程序员立即解决问题的信号，记录会造成冗余和时间浪费。
• 高级别回归测试失败 ：许多团队有运行高于单元级别的回归测试的构建。如“全量构建”运行 GUI 前后的功能测试，若开发人员立即解决问题，通常不记录缺陷；若问题不简单，测试人员会调查并记录缺陷，提供失败测试的名称或手动重现步骤。无论哪种情况，都会编写重现缺陷的测试，修复代码使测试通过，测试会成为构建的一部分。
• 当前迭代中的故事缺陷 ：能立即修复的缺陷，尤其是原本要记录在电子 DTS 中的，若团队与程序员紧密合作且完成故事后进行配对测试，只要程序员立即处理，就无需记录。可与程序员讨论问题是否真实存在，必要时与客户沟通，并做笔记以便调整测试。若使用索引卡记录缺陷，可在任务板上放一张卡片作为提醒。
• 迭代后或无法立即修复的缺陷 ：无法立即修复的缺陷应记录。强调尽早测试以在程序员处理故事时发现更多缺陷，因为早期修复成本更低。若程序员已开始处理其他故事而无法立即修复，这类缺陷适合记录。有时“缺陷”可能是遗漏的需求，需作为故事进行评估和优先级排序，安排到未来迭代中。
• 遗留系统中的缺陷 ：产品存在时间长，遗留系统中可能有潜伏的缺陷。若产品负责人认为值得修复，应记录并纳入产品待办事项列表进行优先级排序；若缺陷长期存在且无影响，产品负责人可能决定不修复，此时无需记录，避免浪费时间。
• 生产环境中发现的缺陷 ：应用程序在生产环境中，客户发现的所有缺陷都应记录。根据严重程度，这些缺陷可能立即修复、在下一次发布时修复，或进行评估、优先级排序后放入产品待办事项列表。

2.6.2 选择修复缺陷的时机

所有发现的缺陷都需进行分类，确定是立即修复、稍后修复还是不修复。分类方式可以是与程序员讨论确定是否为当前故事中的缺陷，与产品负责人讨论是否为下一次迭代的新故事，或与客户进行正式流程以确定修复优先级。
- 立即修复 ：能立即修复的缺陷越多，应用程序产生的技术债务越少，“缺陷”库存也越少。越早发现的缺陷修复成本越低，如 IBM 报告显示，产品发布后发现的错误修复成本是设计阶段的四到五倍，是维护阶段的 100 倍。若在开发新功能时发现缺陷或因修复其他缺陷产生的副作用，应自动修复，但要谨慎处理。例如，若程序员认为某个缺陷难以修复且可能影响产品稳定性，应提交给客户进行优先级排序。

以下是修复软件缺陷的成本对比表格：
| 软件开发生命周期阶段 | 修复成本相对倍数 |
| — | — |
| 实现阶段 | 1x |
| 设计阶段 | 6.5x |
| 测试阶段 | 15x |
| 维护阶段 | 100x |

下面是一个简单的缺陷处理流程图：

graph LR
    A[发现缺陷] --> B{是否能立即修复}
    B -- 是 --> C[立即修复]
    B -- 否 --> D{是否为单元测试失败}
    D -- 是 --> E[不记录，程序员立即解决]
    D -- 否 --> F{是否为高级别回归测试失败}
    F -- 是 --> G{开发人员能否立即解决}
    G -- 是 --> H[修复，不记录缺陷]
    G -- 否 --> I[测试人员调查并记录缺陷]
    F -- 否 --> J{是否为当前迭代故事缺陷}
    J -- 是 --> K{程序员能否立即处理}
    K -- 是 --> L[不记录，讨论调整]
    K -- 否 --> M[记录缺陷]
    J -- 否 --> N{是否为遗留系统缺陷}
    N -- 是 --> O{产品负责人是否决定修复}
    O -- 是 --> P[记录并排序]
    O -- 否 --> Q[不记录]
    N -- 否 --> R{是否为生产环境缺陷}
    R -- 是 --> S[记录，确定修复时机]
    R -- 否 --> T[记录，后续处理]

综上所述，在敏捷开发中，团队需要根据自身情况和产品特点，灵活选择合适的测试方法和缺陷处理策略，以提高软件质量和开发效率。

3. 缺陷处理策略的总结与实践建议

3.1 缺陷处理策略总结

根据前面的讨论，我们可以将缺陷处理的策略总结如下表：

缺陷类型	是否记录	处理方式
单元测试失败	否	程序员立即解决
高级别回归测试失败	视情况	开发人员能立即解决则不记录，否则测试人员调查并记录
当前迭代中的故事缺陷	否（能立即修复）	与程序员讨论，必要时与客户沟通，做笔记调整测试
迭代后或无法立即修复的缺陷	是	记录，可能作为故事评估和排序到未来迭代
遗留系统中的缺陷	视情况	产品负责人决定修复则记录，否则不记录
生产环境中发现的缺陷	是	记录，根据严重程度确定修复时机

3.2 实践建议

• 建立良好的沟通机制 ：团队成员之间，包括程序员、测试人员和业务人员，要保持密切的沟通。如 NT 服务团队那样，通过每日的 Scrum 会议和日常的交流，及时发现和解决问题，避免缺陷积累。
• 强调测试的及时性 ：尽早进行测试，在程序员编写代码的过程中就参与进来，这样可以在早期发现更多的缺陷，降低修复成本。例如，采用测试驱动开发的方式，在编写代码的同时设计和自动化测试用例。
• 灵活运用缺陷记录方式 ：根据缺陷的类型和情况，选择合适的记录方式。对于能立即解决的缺陷，避免不必要的记录；对于需要后续处理的缺陷，要详细记录以便跟踪和修复。
• 全员参与测试 ：团队中的任何人都可以参与测试任务，当面临测试危机时，整个团队共同努力，确保迭代目标的实现。例如，在每日站会中评估测试进度，及时调整策略。

3.3 持续改进

敏捷开发强调持续改进，团队应该定期回顾缺陷处理的过程，总结经验教训，不断优化测试和缺陷处理策略。可以通过以下步骤进行持续改进：
1. 数据收集 ：收集每次迭代中的缺陷数据，包括缺陷的类型、发现时间、修复时间等。
2. 分析总结 ：分析缺陷数据，找出问题的根源和规律，如哪些类型的缺陷容易出现，是由于需求理解问题还是代码质量问题等。
3. 制定改进措施 ：根据分析结果，制定相应的改进措施，如加强需求沟通、提高代码审查标准等。
4. 实施与跟踪 ：实施改进措施，并跟踪效果，确保改进措施有效。

以下是持续改进的流程图：

graph LR
    A[数据收集] --> B[分析总结]
    B --> C[制定改进措施]
    C --> D[实施与跟踪]
    D --> A

4. 结论

在敏捷开发中，测试和缺陷处理是确保软件质量的关键环节。通过积极主动的测试、良好的沟通机制、灵活的缺陷处理策略和持续改进，团队可以有效地降低技术债务，提高开发效率和软件质量。

团队需要根据自身的实际情况，选择合适的测试方法和缺陷处理方式。例如，对于小型团队或处于敏捷开发初期的团队，可以先从简单的方式开始，如让团队成员共同参与手动测试，随着团队的成熟和经验的积累，再逐步引入自动化测试和更完善的缺陷管理系统。

同时，要始终关注客户的需求和反馈，将客户的意见纳入到开发过程中。因为最终产品的质量是由客户来评判的，满足客户的需求是软件开发的最终目标。

总之，敏捷开发中的测试和缺陷处理是一个复杂而又重要的过程，需要团队成员的共同努力和不断探索，才能实现软件开发的高效和高质量。