测试模式列表

一  AbstractTest /AbstractTestCases（抽象测试和抽象测试用例）

问题

        如何写一个能用来测试接口所有实现的针对接口或抽象类的测试包。

方案

        为每一个接口或抽象类写一个抽象测试类（AbstractTest），这个抽象测试应有一个创建对应接口类型的对象的抽象工厂方法FactoryMethod。

        为接口的每个实现写一个抽象测试的具体实现类ConcreteTest。这ConcreteTest是抽象测试AbstractTest的派生类，并覆盖抽象测试的FactoryMethod来实例化接口的实现类。

        抽象测试AbstractTest是一个包含所有实际测试的测试包，但它不知道如何实例化可测对象（采用了工厂方法FactoryMethod的缘故）。

          ConcreteTest包括工厂方法FactoryMethod的具体实现以及一个运行待测测试的机制，也可能包括与接口实现相关的特定测试。

          AbstractTestCases是一个针对抽象类的测试用例，用来确保抽象类的具体实现类具有期待的行为。

          抽象测试用例包含各种抽象方法，通过这些抽象方法用来获得待测抽象类的具体子类以及得到测试的适当的参数和期待的结果。

二 Broken Test 不完整测试

         该模式是来自KentBeck的《测试驱动开发》一书中的测试模式之一。

         在一天的结束，留下你正工作的未完成的最后的事情。在你第二天早上（或一周或一月后），重新工作时，不完整的测试经能够很快唤醒你正做什么的记忆。

              KentBeck认为这个模式仅对个人有效，对团队开发是无用的。

三 Clean Check In 提交前保证所有测试运行通过

           该模式也是KentBeck的《测试驱动开发》一书中的测试模式之一。

          在每个测试100%运行通过前不要chenk in代码。无一例外。

          该模式在团队开发时必须遵守。

四   Cover The Graph覆盖你能描绘的图形

          这个模式是许多测试方法的基础：代码覆盖测试、事务测试、数据流测试、状态机测试等等。

五  Code Unit Test First  单元测试优先

          模式遵从的规则：绝不写没有失败测试的一行代码。

          对象的接口和输出比它的实现更重要，所以首先写前者，依照代码设法使用它。

          如下是开发新的功能的确实好的方式：

            1 找出你要干的事情。

            2 挑选你想到的新功能的最小的添加。为期望的新功能写一个单元测试。

            3 运行单元测试，如果成功就返回第一步或者完成工作回家。

            4 修改问题：也许是你还没有写新的实现方法。也许方法工作不正确，无论哪种情况修改它，然后返回第三步。

          该过程的关键是：不要试图同时实现两件事情，不要同时试图修改两个问题，只是做一件事情。

六 Crash Test Dummy 清扫测试死角

          该模式也是来自KentBeck的《测试驱动开发》一书中的测试模式之一。

          用Crash Test Dummy对象（抛出一个例外代替做实际工作）来调用和测试错误代码。

七 Defect Seeding 缺陷播种也称为添错

八 Encapsulate New For Testability  为可测试性封装 NEW

九 Expected Result 确保调用函数返回期待的结果

十  Exploratory Testing探究性测试

          相当于集成和系统测试。测试设计和测试执行同步操作。

十一 Fake It  伪实现

       该模式也是来自KentBeck的《测试驱动开发》一书中的测试模式之一。

十二 Guru Writes Automated Test 专家写自动化测试

十三  Journalling Pattern 日志测试

            该模式 在DesignPatternsForDistributedObjects进行了描述。

            记录一序列事件，确保：

              1 出现期待的事件

              2 期待的事件以有效的序列出现。

十四 Log String 日志字符串

          该模式也是来自KentBeck的《测试驱动开发》一书中的测试模式之一。

          为了检查消息调用序列，当消息调用时使用一个logging对象附加到一个字符串。

十五 Mock Object 模拟对象     

        与stub思想相似,Mock Object极度地采用stub,使用规范代码来设置和校验预期.我们发现该方法对单元测试尤其有效,使你的代码更加符合得墨忒耳法则。

        一个Mock Object具有如下优点

          1 容易创建

          2 容易设置

          3 快速

          4 确定性

          5 容易产生行为

          6 没有直接的用户接口

           7 直接可查询

十六 Mutation Testing 变异测试

           Mutation Testing通过测试包运行目标程序的些微冲突版本来看是否测试用例能够识别版本的变化。

           Mutation Testing颠倒了测试问题：代替问我们如何对某个程序测试足够，我们问一个更有用的问题：测试是否充分检测某个程序中的BUG？

          所以，我们通过在代码中引入BUG和运行所有的测试。如果改变的程序通过所有的测试，就像没有改变之前的程序，你必须问“为什么改变的一小部分没有造成程序不同”？？？最可能的，它在还没有测试到的代码区域。

十七 Optimization Unit Test 优化单元测试

         一个优化也是系统的一个特征，好比其它特征，但比大多数特征更可能在进一步增加特征时引起BUG。

            一个优化反映了你的正运行系统的硬件方面的性能特性；这些特性随着时间流逝会变化。它也反映了系统架构方面的特性，这些特性也可能随着时间改变。

         最后，一个优化也是一种权衡。它存在成本；优化带来的成本降低要能够补偿带来的成本的增加，否则优化就变得无意义。成本和节余，不仅随着时间会改变，而且在优化使用的不同的场景也会变化。

十八 Random Testing  随机测试

        随机测试是功能测试的一种，当写和运行极端测试需要的时间太长（或者问题太复杂难以测试每个组合时）时是有用的。软件发布的标准也可能包括一个需要的随机测试量的陈述。例如，我们要求在发布前应当两个星期内没有随机测试失败的情况（即在50个工作站连续随机测试两周）。

          随机测试一个大的问题是如何知道什么时候测试失败。如同所有的测试，一个预期是需要的。你可以依赖代码里的断言作为唯一的预期（例如，你在代码中投掷随机输入，可能来自多个线程，如果两个礼拜没有GPF（一般性保护错误）发生，你能够假设软件是OK的）。在其它情景，通常见于硬件开发你有相同规范的两个不同的实现（一个是模型，另一个是实现），如果它们都允诺确定的精确性那么测试通过。

       当你必须做随机测试时，一定要确保你的测试是足够的随机和它们能够覆盖规范。重复相同的测试两周不发生任何意外。

        随机测试没有直接测试效率高是确定的。但你必须考虑写随机测试产生器的时间与写一组直接测试（或生成器）的时间对比。一旦你有一个随机测试生成器，你的计算机能够一天24小时的工作来产生新的测试。

 

十九 Shunt Pattern 回流模式

  

    别名 InMemoryImpostor, LoopBack

       动机: 为自动化测试准备复杂数据

       回流器是从一个插口出去的线,进入一个输入,所以机器被连接到本身.当机器运行时,它认为自己连接到世界,其实只是与自己对话。在软件上，伪造与外面世界的通讯的诡计，用来运行本地测试，因此测试能够进行分离测试。

        一些测试要确认数据库的底层存取能够按计划那样工作，因此基于这个假设写一个测试套件，它假设能够从真实数据库输入和输出数据，所以我不必有真实的数据库。而是在内存中为数据库创建一个内存顶替者以便能够运行高层的对象。

 

二十 Supporting Unit Test 支持单元测试 

     你在功能测试期间发现错误，不是修改它，你能：

     在代码中定位

     写单元测试

     使单元测试工作

      重新运行功能测试来确认错误已经解决。

      这比简单的修改功能测试的错误更好，因为，

      1 当修改缺陷时你能更加聚焦。你必须做一个关于错误源的特定的、具体的假设，而不是四处走动增加一处然后否定直到功能通过测试。

     2 你现在也有了一个功能测试代码（可能比一个功能测试运行更多次），当错误重新出现时将更有用。

二十一 Tactical Testing  策略测试        

          策略测试是测试代码合并入源代码，所以它是极端的白盒测试。我听说过为测试设计，我们也知道源代码是设计的观念，所以我们应该为测试编码。这显然是低水平的操作，我称它为策略测试。

         它将要成为一个针对测试的模式语言吗？

           它能够成为一个针对白盒测试的模式语言，但我不确信我相信白盒测试有多少，也不确信必须做它多久。

          策略测试要完成的事情：

          测试程序的所有路径

          测试没有使用的边界条件

          测试没有使用的数据集

         允许回归测试由除了开发人员的其他人来做，最好使用一个自动化测试框架。

二十二 Test Boundary Conditions 测试边界条件

二十三 Test Environments 测试环境

           测试环境除了某些东西外要象真实的环境。然后标示两者的不同（最好是数据），把不同参数化，并放入配置文件中。

二十四  Test Everything That Could Possibly Break测试所有出错的可能        

          极限编程的一个经常重复的格言是：“测试每一个可能的错误”

            测试每一个可能的错误意味着覆盖分析确保你测试到了每一个代码行，意味着测试每一个输入的不同组合确保你没有错过一个可以使类错误的条件。测试每一个可能的错误说起来好像是好的事情，但在实践上是不可能的事情。

           可以使用二/八原则。20%的努力可以获得80%的测试成果将进入神化的“完全测试”（如果有这样的事情）。“测试每一个可能的错误”，试图写一个完整的测试，对我来说是不可能的。如果那样做，你将浪费大量的时间而获得很少。

二十五 Test Every Refactoring   测试每个重构

             我认为公平的说，没有软件没有保护缺陷是真实的。可是我们作为软件工程师仍试图使缺陷尽可能的少，我们也总是寻找增强我们相信的质量的各种方式。

            问题：

                    如何避免在重构时引入可能使系统宕掉的错误？

            情景

                    你正开发软件和想在继续编码之前做一些重构。

            约束

                   如果你在重构时引入了一个错误，它可能难以返回除非扔掉所有的变化。

                   相信重构的正确性将会造成错误频繁。

          方案

                测试每个重构是绝对必须的。单元测试是极好的方式。记住“测试是你的安全网，在代码快速演变是预防破坏系统。

        效果

                重构时每次测试系统将对被修改的代码维护一个严格的围墙。在每次重构后，如果引入问题，测试将立即发现原因和冲突位置。

        原理阐述

             “在功能级别增强软件质量的方式之一是在合适的地方有好的测试”。另外，“产出物必须继续确认通过测试。Kent Beck和Erich Gamma揭示他们的开发方法是“编码一点，测试一点”。对于重构，可以改写Kent Beck和Erich Gamma的说法为“重构一点，测试一点”。

               重构在系统的源代码级引起变化，所以在重构后，你应当测试软件来验证功能的完整性。如果在重构后测试失败，你仅需要验证变化的代码。

二十六  Testing Error Handling测试差错处理

二十七 Test Null 测试 NULL情形

 二十八       Test Overrides Now 测试忽略现在的情形

二十九   Test Printed Output测试打印输出

三十      Test Transactions 测试事务

三十一  Tests As Scaffolding  作为脚手架的测试

三十二 To Do List  代办事项清单

三十三 Touchstone Build 检验构造

三十四 Unit Test As Tickler 作为备忘的单元测试

三十五 Unit Test Delegator  单元测试委托

三十六 Unit Testing Java Events 为Java Events提供单元测试

三十七       Virtual Clock 虚拟时钟