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

1、第二讲：计划与测试,目录,XP的计划制定测试驱动的开发方法验收测试,Page3,初始探索,不需要试图记录细节-只需记录故事的名字即可（如Login，Adduser，Deleteuser，ChangePassword），无需记录其他任何内容。,在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户故事。然而，他们不会试图去确定所有的用户故事。随着项目的进展，客户会不断编写新的用户故事。故事的编写会一直持续到项目完成。,Page4,如何编写用户故事,用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特

2、点：,开发人员共同对这些用户故事进行估算。估算是相对的，不是绝对的。我们在记录故事的卡片上写上一些“点数”表示实现这个故事的相对时间，我们无法确定每个点数代表的时间，但是我们应该知道8个点的故事所需要的时间应该是4个点的两倍。,Page5,估算用户故事时间,任何过大的故事都应该被分解成小一点的部分，任何过小的故事都应该和其他小的故事进行合并。如：“用户能够安全地进行存款、取款、转帐活动。”必须进行分解。分割或合并一个故事时，应该对其重新进行估算，其值可能会增大或缩小。为知道用户故事的绝对大小，需要一个称为速度（velocity）的因子。伴随项目的进展，由于可以度量每次迭代中已经产正的用户故事点

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

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

5、员能够在416个小时内实现的一些功能。开发人员可以签订任意任务,不一定是他所精通的业务，这样可以促进知识在团队的传播。每个开发人员都知道在最近一次迭代中完成的任务点数，这个数字可以作为下一次迭代中的个人预算。,Page10,任务计划（续上）：,“任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；任务要落实到具体的责任人；任务粒度要小，工作量大于两天的任务要进一步分解；用小时做为任务剩余工作量的估计单位，并每日重估计和刷新。任务的选择一直到所有的任务都被分配出去，或者所有的开发人员都已经用完了他们的预算时为止。,在迭代进行到一半（迭代中点）的时候，团队必须召开

6、会议查看所完成的故事数量，应该是一半的故事都被完成，如果没有，那么团队应该设法重新分配没有完成的任务和职责，以保证在迭代结束时能够完成所有的素材。,Page11,迭代,每次（每2周）迭代结束时，会给客户演示客户演示当前可运行的程序。客户将会根据他们看到的反馈新的用户素材。客户可以经常看到项目的进展，度量开发速度，按照他们自己的意愿去管理项目。,Page12,跟踪,对于XP项目来说，跟踪和管理就是纪录每次迭代的结果，然后使用这些结果预测后面几次迭代的内容。速度图：每周结束时，一共完成了多少故事点。,Page13,跟踪,余量图（燃尽图）：每一周过后，还有多少点数需要在下一个主要里程碑或者发布中完成

7、。,Page14,测试驱动开发,测试驱动开发，英文全称Test-DrivenDevelopment，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。,KentBeck最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，还专门撰写了测试驱动开发一书，详细说明如何实现。经过几年的迅猛发展，测试驱动开发已经成长为一门独立的软件开发技术，其名气甚至盖过了极限编程。,Page15,为什么要进行测试驱动开发,常见场景：当

8、有一个新的开发任务时，往往第一个念头就是如何去实现它呢？“应该是这么做的吧，嗯，差不多就是这样的”。抓起任务就开始编码，一边写，一边修改和设计。时间这么紧！我还是先实现任务吧，然后再好好测试。还是不工作，时间不多了。不管了，还是先做个实现，以后再来整理代码吧。我已经单步调试了好几次了，遍历了所有可能的分支，应该不会有问题了，提交，今天可以好好休息一下了。要不要写单元测试把我刚才单步调试的步骤写下来啊？那样是很好，但工作量很大哦。,Page16,为什么要进行测试驱动开发,常见场景：这样的情况要作自动测试太复杂了。还是手工测试一下吧。程序员应该做些有创意的东西，这样才有趣啊。测试是QA的事，我为什

9、么要做啊，我做了他们干什么啊。奇怪了，怎么代码跟开发文档上有这么大的差别啊。这段代码究竟想表达什么意思？代码现在越来越乱了，我都不敢修改代码了，修改了这个地方，天晓得会引起多少别的地方出错啊!这个地方的代码怎么好象在那个地方看到过啊？这个程序里怎么会有这么多的重复代码呢？,Page17,为什么要进行测试驱动开发,常见场景：开发部在干什么啊，BUG怎么这么多，他们有没有自己先测试一下啊。这下好了，让他们修改了一个BUG，现在一下子来了这么多的BUG。他们到底在搞什么啊，有没有从用户的角度考虑啊，我新增一个采购订单，订单项竟然可以输入负数。为了消除上面的各种抱怨，可以考虑使用TDD。因为测试驱动所

10、追求的目标就是代码整洁可用，其实现目标为：1.只有测试失败时，我们才写代码2.消除重复设计，优化设计结构,Page18,测试驱动开发方法,TDD简单来讲就是每当需要添加一个新功能，或修改现有功能时，首先思考这部分代码期望达到的输入与输出，先把验证该业务的单元测试用例写出来，再去写最简单的实现代码来通过该测试；不断重复此过程直到完成整个功能。,例如：下面程序中testMove方法描述一个测试，连接在4号房间的东边是5号房间，向东移动应该断言玩家在5号房间中。代码：PublicvoidtestMove（）WumpusGameg=newWumpusGame（）;g.connect(4,5,”E”);

11、g.setPlayerRoom(4);g.east();assertEqual（5，g.getPlayerRoom();,Page19,测试驱动开发步骤,典型的TDD开发步骤：Step1：分析并确定一个目标测试场景Step2：添加一个单元测试来验证该测试场景的输入输出Step3：运行该测试，得到失败的测试结果Step4：写最简单的功能代码来通过该测试Step5：再次运行该测试，看到测试通过Step6：进行代码重构，包括功能代码和单元测试代码Step7：重复以上步骤，直至开发完成,Page20,测试驱动开发步骤,Page21,测试促进模块之间的隔离,耦合在一起的薪水支付系统模型,Page22,测

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

13、te-boxtests)。验证测试是用来验证系统满足客户需求的黑盒测试(black-boxtests)。,Page26,验收测试,验收测试由不了解系统个内部机制的人编写。验收测试是程序可以运行，一般使用脚本语言编写。,Page27,测试驱动开发TTD的局限性,1.TDD产生的代码质量取决于测试的质量，即不恰当，不正确的测试会产生错误的代码；业务场景覆盖不充分的测试会产生功能不完整的代码；2.TDD只适用于输入输出明确的开发项目，不适用于某些探索性的，输出不确定的开发，比如密码系统，人工智能，安全等领域的研发；3.TDD在某些环境下实施会有一些困难，比如关系型数据库，异步通信等，需要一些额外的辅助工具。,Page28,常用测试工具Junit,JUnit是一款由ErichGamma（设计模式的作者）和KentBeck（极限编程的提出者）编写的开源的回归测试框架，供Java编码人员做单元测试之