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

* * * * * * * * * * * * * Page * 跟踪 余量图（燃尽图）：每一周过后，还有多少点数需要在下一个主要里程碑或者发布中完成。 Page * 测试驱动开发 测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。 Kent Beck最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，还专门撰写了《测试驱动开发》一书，详细说明如何实现。经过几年的迅猛发展，测试驱动开发已经成长为一门独立的软件开发技术，其名气甚至盖过了极限编程。 Page * 为什么要进行测试驱动开发 常见场景： 当有一个新的开发任务时，往往第一个念头就是如何去实现 它呢？ “应该是这么做的吧，嗯，差不多就是这样的” 。 抓起任务就开始编码，一边写，一边修改和设计。 时间这么紧！我还是先实现任务吧，然后再好好测试。 还是不工作，时间不多了。不管了，还是先做个实现，以后再来整理代码吧。 我已经单步调试了好几次了，遍历了所有可能的分支，应该不会有问题了，提交，今天可以好好休息一下了。 要不要写单元测试把我刚才单步调试的步骤写下来啊？那样是很好，但工作量很大哦。 Page * 为什么要进行测试驱动开发 常见场景： 这样的情况要作自动测试太复杂了。还是手工测试一下吧。 程序员应该做些有创意的东西，这样才有趣啊。 测试是QA的事，我为什么要做啊，我做了他们干什么啊。 奇怪了，怎么代码跟开发文档上有这么大的差别啊。 这段代码究竟想表达什么意思？ 代码现在越来越乱了，我都不敢修改代码了，修改了这个地方，天晓得会引起多少别的地方出错啊! 这个地方的代码怎么好象在那个地方看到过啊？这个程序里怎么会有这么多的重复代码呢？ Page * 为什么要进行测试驱动开发 常见场景： 开发部在干什么啊，BUG怎么这么多，他们有没有自己先测试一下啊。 这下好了，让他们修改了一个BUG，现在一下子来了这么多的BUG。 他们到底在搞什么啊，有没有从用户的角度考虑啊，我新增一个采购订单，订单项竟然可以输入负数。 为了消除上面的各种抱怨，可以考虑使用TDD。因为测试驱动所追求的目标就是代码整洁可用，其实现目标为： 1.只有测试失败时，我们才写代码 2.消除重复设计，优化设计结构 Page * 测试驱动开发方法 TDD简单来讲就是每当需要添加一个新功能，或修改现有功能时，首先思考这部分代码期望达到的输入与输出，先把验证该业务的单元测试用例写出来，再去写最简单的实现代码来通过该测试；不断重复此过程直到完成整个功能。 例如：下面程序中testMove方法描述一个测试，连接在4号房间的东边是5号房间，向东移动应该断言玩家在5号房间中。 代码： Public void testMove（）{ WumpusGame g=new WumpusGame （）; g.connect(4,5,”E”); g.setPlayerRoom(4); g.east(); assertEqual（5，g. getPlayerRoom()); } Page * 测试驱动开发步骤 典型的TDD开发步骤： Step 1：分析并确定一个目标测试场景 Step 2：添加一个单元测试来验证该测试场景的输入输出 Step 3：运行该测试，得到失败的测试结果 Step 4：写最简单的功能代码来通过该测试 Step 5：再次运行该测试，看到测试通过 Step 6： 进行代码重构，包括功能代码和单元测试代码 Step 7：重复以上步骤，直至开发完成 Page * 测试驱动开发步骤 Page * 测试促进模块之间的隔离 耦合在一起的薪水支付系统模型 Page * 测试促进模块之间的隔离 单元测试在解耦方面提供了很多推动和指导。例如：使用了Mock Object后，就可以对被Mock的对象进行解耦，而不依赖于某个特定的对象。下面是使用访对象Mock Object设计模式引入Payroll类的测试类test Payroll： Page * 测试促进模块之间的隔离 解除了耦合的薪水支付系统的应用模型 Page * 测试促进模块之间的隔离 解除了耦合的薪水支付系统的应用模型 Page * 验收测试 作为验证工具，单元测试是必不可少的，但还不够。单元测试用于验证系统小的组成单元的功能，但