<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的魅力。

          旁证博引(二)


          1.1  同其它敏捷实践及测试的关系

          1.1.1  与Story的关系

          B/S开发框架项目测试用例的来源是Story,测试驱动的根本是需求驱动。

          必须根据B/S开发框架项目Story从用户角度编写相应的测试用例和测试代码,测试用例表达用户希望系统能提供什么样的交互形式,并为其编写对应的测试代码。

          对整个Story很可能无法只通过一个测试用例来完成,那么可以从一个较小的测试用例开始,然后逐步新增用例完成整个Story的开发。

          尽量能够直接依照Story中的用户验收标准来细分,即垂直划分单元。如果必要时出现横向划分单元,则单元之间的接口要求作为TDD用例的依据。

          1.1.2  与重构的关系

          B/S开发框架开发项目重构是在TDD每个小步伐中进行:测试不通过->测试通过->重构。

          B/S开发框架项目TDD是从测试用例推导出可工作的代码,而重构使代码更加简洁,重构不仅使功能代码变得简洁,还能使测试代码变得简洁。无论是功能代码还是测试代码,提高可维护性都是必要的。在编写刚好够用的代码基础上,及时重构,避免代码日益腐化,在TDD小粒度开发中进行重构,减少或避免日后对整个系统大规模的重构。

          B/S开发框架开发项目尽管可以采用隔离、迁移、提取等重构方法,但是对代码的改变最好不要修改功能单元的外部特性。重构之后及时自动执行测试用例,检查测试是否通过,重构是否影响到功能的正常性。

          1.1.3 TDD跟传统测试的关系

          l 与TDD无关的项

          对于测试人员负责的SDV、SIT、SVT等测试,跟TDD无关。

          BBIT由开发人员负责,不过目前测试人员也广泛参与,这项活动也跟TDD无关。

          l 与TDD相关的项

          对于B/S开发框架项目ST,应该是测试本项目组所负责的模块,可以算TDD的范畴。但实际上,项目ST基本上都是把整个系统集成在一起测试,很少针对单个模块进行测试,如果这样的话,就不能算TDD的范畴。

          对于项目UT、IT,可以跟设计、编码融合在一起,采用TDD的方式开发。

          1.2  遗留系统的TDD

          如何实施遗留系统的TDD,准入条件是什么?

          在我们的B/S开发框架研发过程中,有很多时候必须忍受遗留代码。想编写一些新的优秀的代码,但是现在负责的是对我们来说全新的完全不熟悉的一段老代码。这份代码看起来相当复杂、陌生,但却不得不接受这项工作。

          在进行遗留系统的TDD之前,我们首先需要弄清楚几个概念:什么是遗留代码,什么是遗留系统;同时需要弄明白遗留系统所面临的困境和我们为什么要对遗留系统进行改造等。

          1.2.1  遗留系统的困境

          首先,什么是遗留系统?业内认识:无法理解的、难以修改的代码。《修改代码的艺术》一书中将其定义为:没有编写相应测试的代码。

          B/S开发框架遗留系统的困境:没有测试安全网,或者说没有完整的测试保障;代码腐烂,依赖关系复杂,架构糜烂,修改代码无从下手;没有同步的文档,系统难以理解;错误的注释,不准确的注释;在系统上实现新需求,修改bug异常困难,风险很高,牵一发而动全身;维护人员对遗留系统不熟悉。

          遗留系统上修改代码的起因:添加新需求、修正系统中的bug、改善现有设计或优化资源使用等。传统的做法是,在你竭尽全力避免破坏现有功能的情况下适当做些修改。不幸的是,因为对代码的不熟悉,当你改变一个数据结构或者更新一个变量时,你无法确信将要发生什么。与其在这种充满危险的境况里盲目地徘徊,还不如制定一个处理的策略和准入原则。

          处理遗留系统时我们可多管齐下,构建(Build),自动化(Automate)并且测试(Test),简称BAT。使用这个BAT,在各个环节设置准入条件,这种模式可有效地实施遗留系统的TDD。

          1.2.2  编译测试

          B/S开发框架开发项目要解决的第一个问题就是能够编译测试,除非你能可靠地构建它,不然测试一个产品很困难。

          遗留系统TDD的准入条件之一:构建环境要干净(构建不局限于单一机器或者一个特殊的环境),代码所有者间能相互传递并构建。

          当任何人都能构建时,任何人也就都能进行测试,于是也就会更加频繁地运行测试,产生出更小范围的缺陷报告。我们构建目的就是创建一个能够在任何开发机器上易于运行、易于维护的干净的构建。

          软件开发框架TDD测试工具和用例

          1.2.3  自动化测试工具及用例

          现在你已经可以在任何一台机器上自动构建你的产品了,那么让我们来使它自动化吧。

          B/S开发框架项目自动化的目标是自动化整个构建,在一台干净的机器上,在测试周期内,使人为干预最小化。

          使万事自动化并非都有可能。但是我们希望达到的目标是,把那些可以被合理的自动化执行的东西都写入脚本。

          遗留系统准入条件之二:有自动测试工具和测试用例支撑。

          冒烟测试是一个简短的测试集合,其目标是被频繁修改的代码区。

          冒烟测试不必设法运行整个产品。一套好的冒烟测试应该是可以轮换运行的,它们不是永久不变的。当你开始致力于不同的产品领域时,退出原来的冒烟测试,把新的测试添加进来。你可以从完整的测试套件中选择恰当的测试,使其在冒烟测试套件运行。通常都是把它们添加到一个Ant target(如命名为smoke-test的target)中,然后运行选定的测试。

          我们仍然需要一个干净的构建和周期性运行的完整测试。这就是我们如何验证是否有人忘记提交一个被修改的文件或者用一种非预期的方式来破坏产品。冒烟测试经常遗漏这几类破坏,为了保持产品处于最佳状态,我们需要相当频繁地运行整个测试套件。

          1.2.4  持续集成

          建立这类自动化的最佳方式是什么?最快捷、最容易的方法就是使用一个持续集成(CI)产品。

          B/S开发框架项目遗留系统准入条件之三:有一个完善的持续集成系统。

          BAT最后一部分就是指自动测试。现在CI系统正在构建产品,运行你的自动测试,我们需要确信我们的测试充分地覆盖了整个产品。毕竟,从客户的观点来看,如果一个测试不能检验客户所使用的功能,那它就是没用的。

          模拟客户测试(Mock Client Test)并不是一套特定的测试框架。它的目的是用来确保预期的功能不会被破坏。你要改变系统中的一部分,却不知道这个修改影响了产品的其他区域,这在遗 留产品中经常出现。

          一个优秀的测试策略是缺陷驱动测试(Defect Driven Testing)。每次你发现一个系统缺陷,就增加一个相应的测试。当你增加该测试时,你可以尝试增加一些与该测试相近而不同的测试。随着时间的推移,这个策略为产品最需要涵盖的范围,提供了相当可观的测试覆盖率。

          不管你如何选择增加测试,都要设置测试优先级。如果你计划对软件开发框架产品进行任何修改,有一个基本的测试套件是最关键的。

          最后一步就是将测试集成到持续集成系统。

          B/S开发框架TDD旁征博引

          1.2.5  测试集成到持续集成中

          B/S开发框架遗留系统准入条件之四:测试(模拟客户测试)能够加入到持续集成系统或者已经加入持续集成系统中。

          软件开发框架项目构建、自动化和测试(BAT)是所有开发人员都可以采纳的措施,它对于在遗留代码上做增量开发的开发人员更是如鱼得水。我们推荐使用BAT作为遗留系统TDD的解决之道,同时我们设置如下准入条件:

          l  构建环境需要干净,代码所有者间能相互传递并构建。

          l  有自动测试工具和测试用例支撑

          l  有一个完善的持续集成系统

          l  测试(模拟客户测试)能够加入到持续集成系统或者已经加入持续集成系统中

          1.2.6  与结对编程的关系

          l  专家经验的传播,与TDD专家结对编程的时候,技术及经验传播更方便,人员进步也会比较快

          l  充分讨论,设计更充分

          l  通过结对,写作和检视同时进行,提高质量



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

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

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

          相关文章: web开发缓存技术之B/S开发框架Redis分布式缓存管理

          电话
          电话 18718672256

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