<th id="v9g6b"><track id="v9g6b"></track></th>

  • <em id="v9g6b"><acronym id="v9g6b"></acronym></em>
    <progress id="v9g6b"><pre id="v9g6b"></pre></progress>
    <tbody id="v9g6b"></tbody>
    <button id="v9g6b"><acronym id="v9g6b"></acronym></button>
    <rp id="v9g6b"><ruby id="v9g6b"></ruby></rp>

        <dd id="v9g6b"></dd>

        <em id="v9g6b"></em>

          B/S开发框架测试驱动开发(TDD)指导书(一)

          本指导书详细介绍了敏捷实践——TDD的各个方面。TDD是提升单元测试有效性的工程方法,Web开发框架中遵循测试先行、小步快跑和及时重构的原则,能有效减少过度设计,促进降低开发成本、以及提高软件质量和设计效率。另外,本指导书还对遗留系统的TDD,以及TDD工具的选择给予参考性建议,B/S开发框架并通过大量的实践案例引导你充分体验TDD的魅力。

          TDD概述


          TDD——测试驱动开发(Test Driven Development)的基本思想就是在B/S开发框架开发功能代码之前,先编写测试代码。也就是说在明确要开发某个功能后,首先思考如何对这个功能进行测试,并完成测试代码的编写,然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能,直到完成全部功能的开发。代码整洁可用(clean code that works)是测试驱动开发所追求的目标。

          业界有一句流行的口号:TDD即设计!这里的设计不是指具体某个测试用例、测试代码、功能代码,更不是以前那种详细设计文档,而是整个TDD过程,以及测试用例、测试代码和功能代码的一致交付。

          TDD的步骤:

          B/S开发框架TDD概述


                                                                                                                      图1TDD的步骤

          1、  快速新增一个测试用例;

          2、  运行所有的测试,发现最新的测试不能通过;

          3、  做一些小小的改动;

          4、  运行所有的测试用例,并且全部通过;

          5、  重构代码,以消除冗余设计,优化设计结构。

          为什么要做TDD


                2009年挪威开发者大会(NDC),大会主要发言人Robert C. Martin(Bob大叔)谈到了B/S开发框架单元测试和测试驱动开发是一个专业软件开发人员的基本功。作为开发人员有没有思考过为什么我们需要做TDD呢?我们先来看看TDD能够给我们带来的好处有哪些:

          1.1 TDD可以降低开发成本

          首先我们来看一组业界问题发现时间数据:

          l  下面这个图摘自《实用软件度量》(Capers Jones,McGraw-Hill 1991),它列出了准备测试,执行测试,和修改缺陷所花费的时间(以一个功能点为基准),这些数据显示单元测试的成本效率大约是集成测试的两倍 系统测试的三倍(参见下图)。

          l  这个图也从侧面说明了单元测试的重要性,问题越在软件开发框架单元测试阶段被发现,需要的成本越低。

          SHAPE\* MERGEFORMAT

          Web开发框架测试成本效率比

                                                                                                           图1 各种测试的成本效率对比

          1.2 TDD可以提高软件质量

          “我们相信公司应该一直努力去发布最高质量的产品,给客户带来真正的价值,而单元测试就是让这一切变成现实的最有效的方法。” 《单元测试的艺术》作者——Typemock高级工程师Roy Osherove总结道。

          业界研究实例表明,TDD确实可以提高软件质量。

          在Empirical Software Engineering杂志的第13卷第3期发表的一篇研究报告声称:“看来TDD可以应用在多个领域中,并显著降低web开发框架软件的缺陷密度,同时也不会明显降低开发团队的工作效率。”研究对比了4个在微软和IBM执行的项目,这些项目使用了TDD方式开发,并与没有使用TDD开发的类似项目进行了对比。

          研究报告的作者来自:微软的Nachi Nagappan和Thirumalesh Bhat、IBM的E. Michael Maximilien,以及北卡罗来纳大学的Laurie Williams。

          报告中研究的4个案例,1个来自IBM,3个来自微软。B/S开发框架每个案例研究都对比了开发同一个产品的两个团队,他们使用同样的开发语言和技术,处于同一级别的管理之下,唯一不同之处在于:一个团队使用TDD,另一个不用。在开发过程中,这些团队都不知道自己处于研究之下。IBM案例中的团队在开发设备驱动程序,微软的团队在开发Windows、MSN和Visual Studio的相关应用。

          相较于不使用TDD的项目而言,这四个产品在发布前的缺陷密度降低了40%到90%。从团队管理层的主观报告看来,B/S开发框架开发在开发的初始阶段,使用TDD的团队要多花15%到35%的时间;不过团队都同意一点:这个时间被减少的产品维护时间抵消掉了。

          1.3 TDD可以提升设计效率

          相比起传统的软件开发框架单元测试代码来,web开发框架TDD中的测试代码不但能发现代码的低级错误,而且还可以简化设计流程、提高设计效率,等同于一份详细的设计文档,而且只要功能代码发生了改变就不得不更新,不用任何制度约束。

          l  大幅度的改善了设计和实现

          ü  简单设计避免了过度设计

          ü  高内聚,低耦合(由于测试工具的隔离性,要求必须能识别相应的依赖关系)

          ü  圈复杂度:因为构造用例时要求尽量简单,所以圈复杂度就自然降低了

          l  为维护和重构编织了单元级的“保护网”

          l  项目可以与详尽的测试集一起发布,从而对程序的将来版本的修改和扩展提供方便,全面(全路径覆盖)验证了功能代码的逻辑是否正确

          l  设计工作,人人有责。对于一个执行TDD的开发小组,每个人都在做设计。

          l  大部分时间代码处在高质量状态,100%的时间里成果是可见的

          l  由于可以保证编写测试和编写代码的是相同的程序员,降低了理解代码所花费的成本

          l  减少了文档和代码之间同步工作和由同步不及时所引入的BUG

          l  完工时完工

          1.4 TDD的趋势

          B/S开发框架的软件研发TDD的趋势是越来越流行!

          2008年10月,Scott Ambler在Extreme Programming和Test-Driven Development两个组内进行了有关TDD的调查,参与者共121人,其人员基本背景如下:

          l 74% 开发人员/建模人员, 15%管理层

          l 52%  10年以上IT工作经验

          l 22%  在超过1000人的组织工作

          l 96%  工作在商业组织

          l 50%  来自北美,26%来自欧洲

          调查结果如下:

          B/S开发框架TDD流行度

                                                                                                            图2TDD流行程度调查结果

          调查显示,TDD的流行程度将近冒烟测试的2倍,在北美和欧洲等研发领域已经是非常流行的一个敏捷实践。

          TDD能够给我们带来的好处远比不止上述描述的内容,在B/S开发框架开发过程中实施TDD是非常必要的。更有甚者还有人提出充分的单元测试能够避免法律纠纷,如:Typemock于2009年在挪威开发者大会(NDC)上举办的Unit Testing Open Microphone的活动。在活动中,超过一半的开发人员相信,如果欧盟软件责任提案(EU software liability bill)获得通过的话,单元测试能帮助公司避免法律诉讼。

          既然TDD能够给我们带来这么多好处,那是否所有的项目都适合做TDD呢?项目中的所有模块我们都应该做TDD吗?

          B/S开发框架搭建一个模块的TDD环境需要模拟模块的周边接口,可以根据投入产出比来决定是否适合做TDD。

          l  如果一个模块已经有TDD环境,在这个基础上增加TDD用例非常容易,毫无疑问,我们应该做TDD。

          l  如果一个模块没有TDD环境,是否应该做TDD,需要考虑投入产出比。

          ü  如果这个模块问题比较多,或者预期后续还有比较多的改动,我们应该做TDD。

          ü  如果这个模块已经很稳定,后续也没什么大的改动,只是小修小补,可以选择不做TDD。

          类似于用户交互的外围处理代码,逻辑流程比较简单,但输入输出特别多。这种情况可能不适合做TDD,可以选择不做。但用户交互的内核代码一般比较内聚,可以做TDD。



          标签: B/S开发框架测试驱动开发(TDD)

          网站&系统开发技术学习交流群:463167176

          本站文章除注明转载外,均为本站原创或翻译,欢迎任何形式的转载,但请务必注明出处,尊重他人劳动,共创和谐网络环境。
          转载请注明:文章转载自:华晨软件-云微开发平台 ? B/S开发框架测试驱动开发(TDD)指导书(一)
          本文标题:B/S开发框架测试驱动开发(TDD)指导书(一)
          本文地址:http://www.sajuice.com/OrgTec/Agile/0007.html

          相关文章: B/S开发框架瀑布式软件开发过程

          电话
          电话 18718672256

          扫一扫
          二维码
          本港台开奖 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>