张克强：敏捷用例实战解析

2017年2月28日周二晚8点30分，高级程序员、系统分析员、执行总监敏捷教练张克强老师，带来了主题为“敏捷用例：一种适合敏捷开发的改进用例方法”的交流。以下是主持人小媛子整理的问题精华，记录了张老师和读者间问答的精彩片段。

问：在需求变更导致用例需要演进的过程中，用例切片是如何帮助团队更快地更改用例的，以及一般需要单独维护用例切片吗？

答： 敏捷用例的维护是比照系统生命周期的，简单说就是长期维护的。

以ATM转账为例，如下是现有情况：

• 起始

• 储户已经登录并选择转账

• 基本步骤

• 储户输入对方帐号和转账金额

• ATM显示掩盖对方姓的名字以及金额，请储户确认

• 储户确认转账

• ATM机提交转账请求到后台系统

• 后台系统进行转账处理，返回成功结果

• ATM机显示转账成功结果，询问储户是否打印凭条

• 储户选择打印，进行下一步，否则跳到第9步

• ATM打印凭条

• ATM机返回的储户主界面

变化带来的切片就发生在上下文当中，最新转账的要求是：非同名账户要等待24小时转账才实质成功。

大家看，如果采用用户故事的写法，该如何写？作为储户，我给非同名账户转账，需要等待24小时后才能成功，这样能防范欺诈。这是用户故事的优点，一句话把事情说了。但其缺点是没有上下文，对以往的故事，要另外关联。而在敏捷用例当中，就是找到相应位置，进行修改，保留上下文。

ATM转账加非同名账户24小时延时的例子如下：

• 起始

• 储户已经登录并选择转账

• 基本步骤

• 储户输入对方帐号和转账金额

• ATM显示掩盖对方姓的名字以及金额，请储户确认

• 储户确认转账

• ATM机提交转账请求到后台系统

• 后台系统进行转账处理，

  • 5.1 如果是同名账户，马上转账，跳到第6步

  • 5.2 如果是非同名账户，显示需等待24小时转账，跳到第9步

• ATM机显示转账成功结果，询问储户是否打印凭条

• 储户选择打印，进行下一步，否则跳到第9步

• ATM打印凭条,ATM机返回的储户主界面

• ATM机返回的储户主界面

• 异常步骤

  • 2a-对方帐号不存在

  • 2b-转账金额超过限额

  • 3a-储户否认转账

  • 5a-后台转账不成功

对比老用例，修改了第5步，加入了5.1和5.2。修改幅度不大，与书写一句话的用户故事，工作量相当。但能够很好的保留上下文，背景等等，在版本控制工具的帮助下，能追查所有版本历史。切片就是通过标注在 5.2 上就可以了。

所以持续维护用例，是这个方法的关键，保证能够被找到，然后切片内容是绝不单独维护，一定是放在上下文当中。

刚开始想到了好多点子，但一个迭代内无法实现。如果采用 传统用户故事方法，需要书写多个用户故事，需要切分用户故事。而敏捷用例方法，不需要切分，而是在上下文中把以后实现的标注为比如@In。In代表第n个迭代，意味着未来做。或者当前迭代假设是I5，标注为I7，那就是意味着计划在下下个迭代里做。

比如下面的例子：

• 起始

• 储户已经登录并选择转账

• 基本步骤

• 储户输入对方帐号和转账金额

• ATM显示掩盖对方姓的名字以及金额，请储户确认

• 储户确认转账

• ATM机提交转账请求到后台系统

• 后台系统进行转账处理，

  • 5.1 如果是同名账户，马上转账，跳到第6步

  • 5.2 如果是非同名账户，显示需等待24小时转账，跳到第9步

  • 5.3 如果是同名账户，但身份证号不一样也需要等待24小时 @I7

• ATM机显示转账成功结果，询问储户是否打印凭条

• 储户选择打印，进行下一步，否则跳到第9步

• ATM打印凭条,ATM机返回的储户主界面

• ATM机返回的储户主界面

• 异常步骤

  • 2a-对方帐号不存在

  • 2b-转账金额超过限额

  • 3a-储户否认转账

  • 5a-后台转账不成功

注意其中5.3。关于开发计划调整，采用敏捷多级计划，迭代所选择的用例和用例切片进入到迭代backlog当中。对于调整，需要的是改变 标注。关于用户故事和用例，我并不是主张不用故事。而是建议融合故事和用例。本身两者从文字表达而言，差异并不大。

用户故事的经典句型，as a role, I want to , so that , 与 用例的角色小人+椭圆， 本质上表达的内容是一样的。“敏捷用例”可以与“故事”划上相似号。

趁着这个问题，把敏捷用例的核心再说明了下，补充一个关键信息， 用例/切片的行为管理仍然提炼到类似JIRA的条目化工具中。所谓用例/切片的行为 是指 其状态（开发中，测试中，等等），用例点（故事点），谁来做，等等。而用例本身专注于表达内容，说明用户与系统、系统与系统之间的交互。

问：所以这里的用例切片是指每一个步骤都是一个用例切片吗?

答： 对于新的用例，不需要切分切片。 所以并不是每个步骤都对应一个切片。而对于用例的变更升级，就要看变化在哪里？多数情况下，一个变化或者新增的步骤是一个切片。

问：切片切的是变化点？

答： 是的。切片是变化的地方。还有一种情况是：切片用于分批开发。

问：那么在JIRA的每个迭代中如何管理切片呢？比如说我在迭代5是实现了当前1-9用例。但是5.3加了进去，要迭代7做。在迭代7我需要把整个用例都拖进来，还是只是5.3？如果只是5.3，感觉这个切片不太完整。都拖进来，又感觉太冗余。

答： JIRA支持超级链接，我推荐的方案是 用例内容不要放在JIRA里面，通过超级链接。用例内容，推荐wiki工具来存放。JIRA只记录标题和链接，这样方便长期维护用例。形象地说，用例是要活的，与系统共同成长。如果只有JIRA的话，我推荐Re-Open原来用例。不推荐克隆。Re-Open原来用例，修改，加入到I7迭代。

问：我想问一下在您的项目中，这些需求用例如何转变成测试用例的。其中切片的又该如何转呢？

答： 需求用例转换到测试用例，这本身就是需求用例的强项，由于需求用例的位置不变，与测试用例的关联关系容易维护。当发生变化的时候，需求用例本身就能显示哪里发生了变化，与之关联的测试用例需要配套修改，也可能要新增测试用例。

测试用例分自动化和手工，对于普通应对变化（没有采用ATDD、BDD），首选一般先上手工测试用例。相关变化总是写在一起的敏捷用例，容易把测试用例考虑的全面。 而分散的用户故事，则要注意与原来关联故事的关系，也要注意原来的老测试用例是否需要配套修改。手工测试用例，按什么样的颗粒度书写，每家公司不尽相同，但针对切片来写，恐怕不经济。

问：我们用QC也是复用，但有些项目太复杂，导致复用后的用例更难看懂了，后来遇到复杂模块就不复用了。

答： QC功能足够强大，本身带需求管理功能。全套需求用例+测试用例在QC当中，应当也能采用我推荐的敏捷用例方法运作起来，不过我自己没有这样用过。我自己在JIRA+WIKI上， Git+Word+禅道，泛微OA上，用过敏捷用例方法。

对于用例新切片的测试，我的首选思路是在老测试用例上加上最新切片情况，如果这样导致老测试用例过于庞大，那么新写测试用例。

关于故事的经典句型写法，最新流传的故事模版，已经加入了故事叙述部分和验收条件部分。

问：感觉这个主要还是需要PO改变过去的As ... I want ... so that...的用户故事书写方式。

答： Agree！对于多年运行的大型系统，一句话用户故事的表现力是不够的。早年敏捷刚刚起来时，在XP里，安排有现场客户，可以每天来反馈，发现不对，马上告诉开发人员。而现在多数组织里，现场客户几乎不可能，现场客户代表都未必可以马上叫到。

而且大型系统多年运行，也需要考虑传承的问题，所以现在在用户故事方面，出现一个趋势是把验收条件写得越来越多。那么，用例的基本流+异常流的组合写法，对于表达功能上的验收条件 具有明显优势。

而GWT的写法，是特别方便得到测试用例，但整体理解不好。GWT是指Given-When-Then，起源本来就是测试。

问：之前看过您的关于扩展需求story的分类，用户故事，系统故事，赋能故事，请问您这次介绍的用例有没有结合故事的分类来做？

答： 首先，没有。 用例虽然没有用例规约的国际标准。但是用例本身是被UML定义的。所以用例本身不能扩充到像赋能故事那样。但用例本身定义是覆盖角色为系统的用例的。UML早就是OMG的国际标准。

用例的角色分为两大类，人类角色和非人类角色。其交互的主题一般都是待开发运维的系统。那么在敏捷当中如何使用了敏捷用例的话，那些非系统本身建设的事务（比如搭建CD Pipeline，重构某模块，补充某模块自动化测试等等）如何管理？

我的推荐是，最好同样放入到backlog中，JIRA能够方便支持多种类型放在一起。如果没有合适工具的话，按照固定或者一定工作量比例来安排非用例的事务。在文章中我说到 “方法汇集了来自于敏捷、极限编程和用例2.0的好处”，我特别想要提的一个好处是“用例图”。

用户故事方法早些没有给出图形表达，用户故事地图利用二维图来表现。用例图+泳道图（活动图） 在敏捷用例的情形仍然可用。用户故事地图在纵向上试图表现 功能优先级批次安排，在横向上试图表达功能流转先后关系。对于新产品新系统，用户故事地图有较好的适用性。而对于大型老系统，用户故事地图在纵向横向的表现力都不够。

而敏捷用例的用例图专注于表现“功能流转先后关系”。把“开发优先级的表现”放到“本身的迭代标注+条目化工具”当中。敏捷用例不赞成切分用例，所以与用户故事地图方法是不兼容的。用例图还有的好处，是与OOA面向对象分析可以对接，当然这个古老技术也许很少人用了。但至少 用例图（包括泳道图等）可以帮助形象的看到“全貌和相互关系”。

问： UML的用例图？

答： 是的，UML的用例图。或者换个方向，把故事绘制到图中。

补充说明，这个方法严重依赖工具，推荐的思路是内容工具记用例内容，最好要有版本控制。条目化工具管理用例活动行为，两者之间要有追溯关联。

（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文：《张克强：敏捷用例实战解析》）

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF92DF400001534F13E012A82EB0