增强UML符号的提案

增强UML符号的提案2013-10-04 infoq Raul Rugiero需求与测试用例，特别是验收测试，是密切相关的。敏捷方法本身基于测试驱动方法，尤其强调这一点。可以增强UML用例的符号以使增强后的UML工具可以正确地处理用例与测试之间连接。

验收测试是设计的一部分

"测试驱动开发"或Dan North观点里的"行为驱动开发"是敏捷范式里最好的实践之一。当我第一次读到BDD的介绍时，对文字模板的"可执行规格"概念的印象特别深刻：

（T1） Given <context> {and <context>}, when <event>, then <outcome> {and <outcome>}

"可执行规格"，多好的想法！不管在所有环境中这一概念的可用性情况，比如很难想象如何按字面意义将它应用到一个合同文档中，但是它作为隐含信息却改变了我看待测试的方式：

验收测试是设计的一部分！

为什么仅仅是验收测试？单元测试、集成测试、系统测试又怎样呢？

单元测试通常用于检测低层构件，如类方法，它们受很多实现决策的限制，以至于需要认真地考虑：我没见过将单元测试作为设计组件，但可作为辅助从源代码中用工具自动生成。

系统（或子系统）测试用于检测高层组件交付时的准备状态，所以我将系统测试看作验收测试。

集成测试提出了问题：我的简单回答是它应该被看作验收测试。或者"应该"这个词需要更深的认识，它牵涉到"黑盒测试"和"白盒测试"。"黑盒测试"聚焦于系统做什么，"白盒测试"则聚焦于系统如何做。"白盒测试"类别中多一个测试失败，则离"验收"的类别更远。换句话说"黑盒测试"类别中多一个集成测试失败，离"验收"类别就更近了。

一些敏捷方法，包括XP（eXtreme Programming）和Scrum在内，建议将用户故事作为需求的产出。一些作者，例如Mike Cohn或Scott Ambler，认为用户故事如果简洁，则特别高效。并且，笼统地提议采用以下模板5：

（T2） As a <role>, I want to <goal/desire>, so that <benefit>

第一印象是"so that"子句是可选的6，但 Chris Matts7 觉得它是提出以下模板的基础：

（T3） In order to <receive benefit> as a <role>, I want to <goal/desire>

我的观点是接受Chris 的论点且认为"in order to"子句或相同的"so that"是关键。事实上，我认为任何需求都需要至少一个验收测试和这样一些子句，它们应该用于沟通验收测试的期望： <goal/desire>表明测试的产出应该符合 <benefit>。

在一个同时管理用户故事和验收测试的假想的工具中，每个验收测试应该链接到一个特定用户故事的"so that"子句，而不是直接链接到用户故事。

正好说到点子上，我的用户故事模板的愿景是：

（T4） As a <role>, I want to <goal/desire>, so that <benefit> {and <benefit>}

每个"benefit"，而非完整的 "so that"子句，都应该有至少一个相关的验收测试。