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

举报
SUNSKY 发表于 2020/02/15 20:40:11 2020/02/15
【摘要】 2017年2月28日周二晚8点30分,高级程序员、系统分析员、执行总监敏捷教练张克强老师,带来了主题为“敏捷用例:一种适合敏捷开发的改进用例方法”的交流。以下是主持人小媛子整理的问题精华,记录了张老师和读者间问答的精彩片段。问:在需求变更导致用例需要演进的过程中,用例切片是如何帮助团队更快地更改用例的,以及一般需要单独维护用例切片吗?答: 敏捷用例的维护是比照系统生命周期的,简单说就是长期维...

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


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200