敏捷软件开发第二讲-计划与测试

1、广州大学华软软件学院软件工程系主讲教师：谭翔纬答疑时间：周三 10:30-12:00 周四 9:00-12:00Tel：660028Email：第二讲：计划与测试目录目录nXP的计划制定的计划制定n测试驱动的开发方法测试驱动的开发方法n验收测试验收测试Page 3初始探索l不需要试图记录细节不需要试图记录细节-只需记录故事的名字即可（只需记录故事的名字即可（如如Login，Add user，Delete user，Change Password），），无需记录其他任何内容。无需记录其他任何内容。l在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户故事。然而，在项目开始时，开发人员和客户

2、会尽量确定出所有真正重要的用户故事。然而，他们不会试图去确定所有的用户故事。随着项目的进展，客户会不断编写新的用户故他们不会试图去确定所有的用户故事。随着项目的进展，客户会不断编写新的用户故事。故事的编写会一直持续到项目完成。事。故事的编写会一直持续到项目完成。Page 4如何编写用户故事 用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点：p开发人员共同对这些用户故事进行估算。估算是相对的，不是绝对的。我们在记录故事的卡片上写上一些“点数”表示实现这个故事的相对时间，我们无法确定每个点数代表的时

3、间，但是我们应该知道8个点的故事所需要的时间应该是4个点的两倍。Page 5估算用户故事时间p任何过大的故事都应该被分解成小一点的部分，任何过小的故事都应该和其他小的故事进行合并。 如：如：“用户能够安全地进行存款、取款、转帐活动。用户能够安全地进行存款、取款、转帐活动。”必须进行分必须进行分解。解。p分割或合并一个故事时，应该对其重新进行估算，其值可能会增大或缩小。p为知道用户故事的绝对大小，需要一个称为速度（velocity）的因子。p 伴随项目的进展，由于可以度量每次迭代中已经产正的用户故事点数，所以速度的度量会越来越准确。Page 6一些关于用户故事的注意事项Page 7发布计划发布计

4、划的制定要考虑以下因素：包括客户选择的项目大小、程序功能包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期的优先级、各个版本的合成和发布日期。l用户故事实现顺序的选择不是单纯依据优先级进行的，一些重要的但是实现起来代价高昂的故事可能会被推迟实现，而会先去实现一些不那么重要的，但是代价要低廉得多的故事。此类选择属于商务（business）决策范畴。让业务人员来选定那些会给他们带来最大利益的故事。l 开发速度开始时并不准确，选择也是粗略的，当开发速度变得准确的时候，可以对发布计划进行相应的调整。Page 8迭代计划（迭代规模：1-2周）迭代计划的定制要注意事项：l在选择用户故事的时

5、候，绝不允许客户选择与当前开发速度不符的更多绝不允许客户选择与当前开发速度不符的更多的故事。的故事。l迭代期间用户故事的实现顺序属于技术决策范畴，开发人员采用最具技术意义的顺序来实现这些故事。l一旦迭代开始，客户就不能再改变该迭代期内需要实现的故事，但可以客户就不能再改变该迭代期内需要实现的故事，但可以更改其他故事。更改其他故事。l 即使没有完成所有的故事，迭代也要在先前指定的日期结束。即使没有完成所有的故事，迭代也要在先前指定的日期结束。开发人员会合计所有已经完成的故事的估算值，然后计算本次迭代的开发速度，这个速度会被用于下次迭代。Page 9任务计划 在每次迭代计划的执行过程中，需要对本次

6、迭代所要完成的任务制定任务计划要点如下：l在新的迭代开始时，开发人员和客户共同制定计划开发人员和客户共同制定计划。开发人员把故事分解成开发任务-一个任务就是一个开发人员能够在416个小时内实现的一些功能。l开发人员可以签订任意任务,不一定是他所精通的业务，这样可以促进知促进知识在团队的传播识在团队的传播。l每个开发人员都知道在最近一次迭代中完成的任务点数，这个数字可以作为下一次迭代中的个人预算。Page 10任务计划 （续上）：l“任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；任务要落实到具体的责任人；l任务粒度要小，工作量大于两天的任务要进一步分解；用

7、小时做为任务剩余工作量的估计单位，并每日重估计和刷新。l任务的选择一直到所有的任务都被分配出去，或者所有的开发人员都已经用完了他们的预算时为止。l在迭代进行到一半（迭代中点）的时候，团队必须召开会议查看所完成的故事数量，应该是一半的故事都被完成，如果没有，那么团队应该设法重新分配没有完成的任务和职责，以保证在迭代结束时能够完成所有的素材。Page 11迭代l每次（每2周）迭代结束时，会给客户演示客户演示当前可运行的程序。客户将会根据他们看到的反馈新的用户素材。l客户可以经常看到项目的进展，度量开发速度，按照他们自己的意愿去管理项目。Page 12跟踪l对于XP项目来说，跟踪和管理就是纪录每次迭

8、代的结果，然后使用这些结果预测后面几次迭代的内容。l速度图：每周结束时，一共完成了多少故事点。Page 13跟踪l余量图（燃尽图）：每一周过后，还有多少点数需要在下一个主要里程碑或者发布中完成。Page 14测试驱动开发l测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。lKent Beck最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，

9、还专门撰写了测试驱动开发一书，详细说明如何实现。经过几年的迅猛发展，测试驱动开发已经成长为一门独立的软件开发技术，其名气甚至盖过了极限编程。Page 15为什么要进行测试驱动开发常见场景：常见场景：l当有一个新的开发任务时，往往第一个念头就是如何去实现 它呢？l“应该是这么做的吧，嗯，差不多就是这样的” 。l 抓起任务就开始编码，一边写，一边修改和设计。l 时间这么紧！我还是先实现任务吧，然后再好好测试。l 还是不工作，时间不多了。不管了，还是先做个实现，以后再来整理代码吧。l 我已经单步调试了好几次了，遍历了所有可能的分支，应该不会有问题了，提交，今天可以好好休息一下了。l 要不要写单元测试

10、把我刚才单步调试的步骤写下来啊？那样是很好，但工作量很大哦。Page 16为什么要进行测试驱动开发常见场景：常见场景：l这样的情况要作自动测试太复杂了。还是手工测试一下吧。l 程序员应该做些有创意的东西，这样才有趣啊。l 测试是QA的事，我为什么要做啊，我做了他们干什么啊。奇怪了，怎么代码跟开发文档上有这么大的差别啊。 这段代码究竟想表达什么意思？ 代码现在越来越乱了，我都不敢修改代码了，修改了这个地方，天晓得会引起多少别的地方出错啊! 这个地方的代码怎么好象在那个地方看到过啊？这个程序里怎么会有这么多的重复代码呢？ Page 17为什么要进行测试驱动开发常见场景：常见场景：l开发部在干什么啊

11、，BUG怎么这么多，他们有没有自己先测试一下啊。l 这下好了，让他们修改了一个BUG，现在一下子来了这么多的BUG。l他们到底在搞什么啊，有没有从用户的角度考虑啊，我新增一个采购订单，订单项竟然可以输入负数。 为了消除上面的各种抱怨，可以考虑使用TDD。因为测试驱动所追求的目标就是代码整洁可用，其实现目标为：1.只有测试失败时，我们才写代码只有测试失败时，我们才写代码2.消除重复设计，优化设计结构消除重复设计，优化设计结构Page 18测试驱动开发方法lTDD简单来讲就是每当需要添加一个新功能，或修改现有功能时，首先思考这部分代码期望达到的输入与输出，先把验证该业务的单元测试用例写出来，再去写

12、最简单的实现代码来通过该测试；不断重复此过程直到完成整个功能。l例如：下面程序中testMove方法描述一个测试，连接在4号房间的东边是5号房间，向东移动应该断言玩家在5号房间中。代码：Public void testMovePublic void testMove（）（） WumpusGame g=new WumpusGame WumpusGame g=new WumpusGame （）（）; ; g.connect(4,5,”E”); g.connect(4,5,”E”); g.setPlayerRoom(4); g.setPlayerRoom(4); g.east(); g.east()

13、; assertEqual assertEqual（5 5，g. getPlayerRoom();g. getPlayerRoom(); Page 19测试驱动开发步骤l典型的TDD开发步骤：Step 1：分析并确定一个目标测试场景Step 2：添加一个单元测试来验证该测试场景的输入输出Step 3：运行该测试，得到失败的测试结果Step 4：写最简单的功能代码来通过该测试Step 5：再次运行该测试，看到测试通过Step 6： 进行代码重构，包括功能代码和单元测试代码Step 7：重复以上步骤，直至开发完成Page 20测试驱动开发步骤Page 21测试促进模块之间的隔离耦合在一起的薪水支付

14、系统模型Page 22测试促进模块之间的隔离l单元测试在解耦方面提供了很多推动和指导。例如：使用了Mock Object后，就可以对被Mock的对象进行解耦，而不依赖于某个特定的对象。下面是使用访对象Mock Object设计模式引入Payroll类的测试类test Payroll：Page 23测试促进模块之间的隔离l解除了耦合的薪水支付系统的应用模型Page 24测试促进模块之间的隔离l解除了耦合的薪水支付系统的应用模型Page 25验收测试l作为验证工具，单元测试是必不可少的，但还不够。单元测试用于验证系统小的组成单元的功能，但没有验证系统做为一个整体时工作的正确性。l单元测试验证系统中

15、个别机制的白盒测试(white-box tests)。l验证测试是用来验证系统满足客户需求的黑盒测试(black-box tests)。Page 26验收测试l验收测试由不了解系统个内部机制的人编写。l验收测试是程序可以运行，一般使用脚本语言编写。Page 27测试驱动开发TTD的局限性l 1. TDD产生的代码质量取决于测试的质量，即不恰当，不正确的测试会产生错误的代码；业务场景覆盖不充分的测试会产生功能不完整的代码；l 2. TDD只适用于输入输出明确的开发项目，不适用于某些探索性的，输出不确定的开发，比如密码系统，人工智能，安全等领域的研发；l 3. TDD在某些环境下实施会有一些困难，

16、比如关系型数据库，异步通信等，需要一些额外的辅助工具。Page 28常用测试工具JunitlJUnit是一款由Erich Gamma（设计模式的作者）和Kent Beck（极限编程的提出者）编写的开源的回归测试框架，供Java编码人员做单元测试之用，可以从网站上免费获得。总结l通过一次次迭代和发布，项目进入了一种可以预测的、舒适的开发节通过一次次迭代和发布，项目进入了一种可以预测的、舒适的开发节奏。奏。l使用敏捷方法并不意味着只要涉众是（与要建设的业务系统相关的一使用敏捷方法并不意味着只要涉众是（与要建设的业务系统相关的一切人和事）可以完全得到客户想要的。它不过意味着能够控制着团队切人和事）可以完全得到客户想要的。它不过意味着能够控制着团队以最小的代价获得最大的商业价