测试策略模式

1、第18章记录测试（也称为记录与回放测试、机器人用户测试、捕获/回放测试）如何准备软件的自动化测试?通过记录与应用程序的交互并使用测试工具回放它们来自动化测试。18-1 记录测试示意图自动化测试有几个目的。 在回归测试软件更改之后， 它们可以用于这些软件。它们有助于归档软件的行为。在写软件之前，它们可以指定其行为。如何准备自动化测试脚本，对可以将它们用于什么目的、它们对SUT中的变更有多健壮以及准备它们需要多少技能与努力等产生影响。记录测试使得能够在构建SUM后、改变它之前迅速创建回归测试。运行原理我们使用一种工具，它会监控我们与 SUT勺交互。这种工具记录大多数SUT 对我们的通信以及我们对

2、SUT勺响应。录音会话完成之后，可以将它保存在文件 里以便稍后回放。准备运行测试时，可以从工具的“回放”部分开始，并让它指向录音会话。它启动SUT并给它提供响应SUT俞出的记录输入。在录音会话内，它也可以比较SUT的输出及其响应。错误匹配可能导致测试失败。有些记录测试工具允许调整录音会话内 SUT表现与回放过程中SUM现之间比较的敏感性。大多数记录测试工具通过用户界面与SU校互。使用时机如果应用程序正在运行， 但不希望对它进行太多变更， 就可以使用记录测试进行回归测试。 现有应用程序需要重构（ 预计修改功能性） 而没有可用的脚本测试用作回归测试时，也可以使用记录测试。通常，生成一组记录测试比准

3、备具有相同功能性的脚本测试更快。在理论上，任何知道如何运行应用程序的人都可以完成测试记录，几乎不需要专业技术。实际上，许多商业工具都值得深入学习。同时，需要一些专业技术来添加“检查点” ，以便调整回放工具的敏感性，或者调整测试脚本（ 如果记录工具记录了错误信息 ） 。大多数记录测试工具通过用户界面与SU校互。如果SUT勺用户界面不断发展，这种方法特别容易让它们变得脆弱 （ 接口敏感性，参见“脆弱测试” ） 。甚至是小的变更（ 例如改变按钮或字段的内部名称） 也足以让回放工具产生错误。 这些工具也倾向于在低级别详细记录信息，这样会让测试难以理解（ 参见“模糊测试”）。因此，如果对SUT的变更中止

4、了这些工具，也很难手动修复它们。所以， 如果SUT断发展，就要准备有规律地再记录测试。如果要使用作为文档的测试或者要使用这些测试驱动新的开发， 就应该考虑使用脚本测试。 使用商业记录测试工具难以实现这些目标， 因为大多数工具不允许定义用于测试记录的高级语言。 将记录测试性能构建到应用程序本身之中或者使用重构的记录测试可以解决这个问题。变体：重构的记录测试这两种策略的混合是，使用”记录、重构、回放”1顺序从最新记录测试中提取一组“动作组件”或“动词”，然后通过测试用例来调用这些“动作组件”（而 不是使用详细的内联代码）。大多数商业捕获/回放工具提供将字面值转换为参数 的方法，主要的测试用例可以将

5、这些参数传递到“动作组件”。屏幕改变时，只需再记录“动作组件”，所有测试用例自动使用新的“动作组件”定义继续运行。这种策略在效能上与使用测试实用程序方法与单元测试中的SUT交互相同。它允许使用重构的记录测试组件作为脚本测试中的高级语言。像Mercury Interactive 的BPT这样的工具以自顶向下的方法将这一范式用于脚本测试。开发完高级脚本并指定了测试步骤所需的组件之后，更多的技术人员就可以记录或 手动编码单个组件。实现方式说明使用记录测试策略时，有两种基本选择：可以获得第三方工具，它记录与应 用程序交互时发生的通信；可以将“记录与回放”机制内置于应用程序。1 .变体：外部测试记录的缩

6、写。在商业上有许多测试记录工具可用， 每种工具都有自身的优缺点。最好的选 1名称“记录、重构、回放”是 Adam Geras提出来的。 BPT 是“业务进程测试(Business Process Testing)择取决于应用程序用户接口的性质、 预算、 要验证的功能性的复杂性以及其他可能的因素。如果要使用测试来驱动开发， 就需要挑选使用测试记录文件格式的工具， 这种格式可以手动编辑且易于理解。需要手动编写内容，如果使用“记录与回放”工具来执行测试，这种情况也还是脚本测试的示例。2 . 变体：内置测试记录也可以将记录测试性能内置于SUT在那种情况下，可以用相当高的级别定义测试脚本“语言” ，级别

7、足够高，就可以在构建系统之前手动编写测试。实际上，有报告说Microsoft Excel电子数据表的VBA性能是Excel自动化测试机制的开端。示例：内置测试记录从表面上看， 提供记录测试的代码样本没有意义， 因为这种模式处理生成测试的方法， 而不是表示它的方法。 回放测试时， 实际上就是数据驱动测试。 同样，通常不重构到记录测试， 因为它经常是项目尝试的第一种测试自动化策略。 而且，如果发现有过多遗漏的测试， 还可以在尝试脚本测试之后引入记录测试， 因为手动自动化的成本太高。 在那种情况下， 不应该试图将现有脚本测试转换为记录测 试，应该记录新测试。该测试用来回归测试安全关键的应用程序，并且

8、在它从 OS2上的C移植到Windows上的C+记后。请注意，记录的 信息如何形成用户易于理解的域专用高级语言。5566SOUTHSOUTHNORTHSOUTHNORTH该样本表示回放测试的输出。内置回放机制插入了 actual 元素。 status 属性表示这些元素是否匹配expected 值。 将样式表应用于这些文件来格式化它们，就像具有彩色编码结果的Fit 测试一样。 然后项目的商业用户可以进行记录、回放和结果分析。在软件的表示层插入挂钩可以记录用户和用户响应提供的选项列表。 其中一个挂钩的示例如下所示：if (playback_is_on() choice = get_choice_f

9、or_playback(dialog_id, choices_list); else choice = display_dialog(choices_list, row, col, title, key);if (recording_is_on() record_choice(dialog_id, choices_list, choice, key);方法 get_choice_for_playback 检索 used-value 元素的内容， 而不是要求用户从选项列表中选取。方法record_choice 生成 actual 元素并“断言”expected 元素，记录各元素 status 属

10、性的结果。注意，当处于回放模式时，recording_is_on() 返回 true 以便记录测试结果。示例：商业记录与回放测试工具几乎有所商业测试工具都使用“记录与回放”隐喻。每种工具都定义自己的记录测试文件格式，其中大多数都非常冗长。下面是使用 Mercury Interactive的 QuickTest Professional QTP 工具记录的测试的“简短”摘要。它显示于“专家视图”中，该视图表示真正记录的内容： VbScript 程序！该示例包括手动插入的注释( 前缀为来说明测试在做什么， )如果改变导致测试不再运行的应用程序之后记录测试，那么就会丢失这些注释。 GoToPageM

11、aintainTaxonomy()Browser(Inf).Page(Inf).WebButton(Login).ClickBrowser(Inf).Page(Inf_2).Check CheckPoint(Inf_2)Browser(Inf).Page(Inf_2).Link(TAXONOMY LINKING).ClickBrowser(Inf).Page(Inf_3).Check CheckPoint(Inf_3)Browser(Inf).Page(Inf_3).Link(MAINTAIN TAXONOMY).Click AddTerm(A,Top Level, Top Level Def

12、inition)Browser(Inf).Page(Inf_4).Link(Add).Clickwait 4Browser(Inf_2).Page(Inf).Check CheckPoint(Inf_5)Browser(Inf_2).Page(Inf).WebEdit(childCodeSuffi x).Set ABrowser(Inf_2).Page(Inf).WebEdit().Set Top LevelBrowser(Inf_2).Page(Inf).WebEdit().Set Top Level DefinitionBrowser(Inf_2).Page(Inf).WebButton(

13、Save).Clickwait 4Browser(Inf).Page(Inf_5).Check CheckPoint(Inf_5_2) SelectTerm(A-Top Level)Browser(Inf).Page(Inf_5).WebList(selectedTaxonomyCode).Select A-Top Level AddTerm(B,Second Top Level, Second Top Level Definition)Browser(Inf).Page(Inf_5).Link(Add).Clickwait 4Browser(Inf_2).Page(Inf_2).Check

14、CheckPoint(Inf_2_2)infofi le_;_hightlight id_;_Browser(Inf_2).Page(Inf_2)_;_ and it goes on, and on, and on 注意， 测试依据应用程序用户界面描述所有输入和输出的方法。 这样主要会产生两个问题：模糊测试 ( 由记录信息的具体性质所导致) 和接口敏感性 ( 导致脆弱测试 ) 。重构说明让该测试作为文档可以使之更有用， 能够降低或避免高测试维护成本， 支持使用一系列提取方法Fowler 重构组成使用高级语言的其他测试。示例：重构的商业记录测试下面的示例显示重构来交流意图的相同测试：GoToPa

15、ge_MaintainTaxonomy()AddTerm(A,Top Level, Top Level Defi nition)SelectTerm(A-Top Level)AddTerm(B,Second Top Level, Second Top Level Defi nition)注意，该测试的意图变得非常明显。提取的测试实用程序方法如下所示：Method GoToPage_MaintainTaxonomy()Browser(Inf).Page(Inf).WebButton(Login).ClickBrowser(Inf).Page(Inf_2).Check CheckPoint(Inf

16、_2)Browser(Inf).Page(Inf_2).Link(TAXONOMY LINKING).ClickBrowser(Inf).Page(Inf_3).Check CheckPoint(Inf_3)Browser(Inf).Page(Inf_3).Link(MAINTAIN TAXONOMY).ClickBrowser(Inf).Page(Inf_4).Check CheckPoint(Inf_4)EndMethod AddTerm( code, name, description)Browser(Inf).Page(Inf_4).Link(Add).Click wait 4Brow

17、ser(Inf_2).Page(Inf).Check CheckPoint(Inf_5)Browser(Inf_2).Page(Inf).WebEdit(childCodeSuffi x).Set codeBrowser(Inf_2).Page(Inf).WebEdit().Set nameBrowser(Inf_2).Page(Inf).WebEdit( niti).Set descriptionBrowser(Inf_2).Page(Inf).WebButton(Save).Clickwait 4Browser(Inf).Page(Inf_5).Check CheckPoint(Inf_5

18、_2) endMethod SelectTerm( path )Browser(Inf).Page(Inf_5).WebList(selectedTaxonomyCode).Select pathBrowser(Inf).Page(Inf_5).Link(Add).Click wait 4end我将这个示例编在一起是为了说明与xUnit中做法的类似之处。不要随便运行该示例，因为在语句构成上它可能不正确。高级阅读论文 “ Agile Regression Testing Using Record and PlayBack ” ARTRP 介绍了将记录测试机制内置于应用程序以利于将它导出到其他平台

19、的经验。脚恻成（也称为手写测试、手动编码测试、程序测试、自动化单元测试）如何准备软件的自动化测试？通过手动写测试程序来自动化测试。图18-2脚本测试示意图自动化测试有几个目的。在回归测试软件更改之后，它们可以用于这些软件。它们有助于归档软件的行为。在写软件之前，它们可以指定其行为。如何准备自动化测试脚本，这将影响可以将它们用于什么目的、 它们对SUT中的变更有多健 壮以及准备它们需要多少技能与努力。脚本测试允许在开发软件之前准备测试，以便它们有助于驱动设计。运行原理通过写测试程序来自动化测试，这些测试程序为了执行其功能性而与 SU校 互。和记录测试不一样，这些测试可以是客户测试或单元测试。这些

20、测试程序通常称为“测试脚本”,以便与它们测试的产品代码区分开来使用时机准备软件的单元测试时，通常使用脚本测试。因为它更容易从用相同编程语 言写的软件中直接访问单个单元。它也允许执行所有代码路径，包括“不合理的”。客户测试稍微有些复杂。当使用自动化故事测试来驱动软件开发时，应该使用脚本测试。记录测试不能很好满足这种需要，因为没有用来记录它们的应用程 时时它难以记录测试。准备脚本测试可以使用编程经验以及测试方法中的经验。项目上的大多数业务用户不可能对学习如何准备脚本测试感兴趣。在编程语言中进行脚本测试的方法之一是，定义测试SUT的高级语言，然后作为数据驱动测试解释程序GOF实现该语言。一种定义数据

21、驱动测试的开源架构是Fit及FitNesse。 Canoo WebTest是支持这种类型测试的另一种工具。在现有遗留应用程序3在测试驱动程序中，遗留应用程序是缺乏自动化测试安全网的系统。中，可以考虑使用记录测试作为快速创建一组回归测 试的方法，这些回归测试在重构代码引入易测性时可以起到保护作用。随后可以准备可测试应用程序的脚本测试。实现方式说明传统上脚本测试写作“测试程序”，通常使用特定的测试脚本语言。现在， 我们更喜欢使用测试自动化架构来写脚本测试，例如，用与SUT相同的语言写的xUnit 。在这种情况下，通常以测试用例类上测试方法的形式捕获各测试程序。要最小化手动干预，各测试方法应该实现自

22、检测试(也就是可重复的测试)示例：脚本测试下面是用JUnit写的脚本测试的示例：public void testAddLineItem_quantityOne()final BigDecimal BASE_PRICE = UNIT_PRICE;final BigDecimal EXTENDED_PRICE = BASE_PRICE;(Fit)使用数据驱动测试作为测试策略时，应该考虑使用预制数据驱动测试架构。WardCunninghamift初将Fit这种架构作为在自动化测试中包含业务用户的方法。虽然Fit通常用于自动化客户测试，但如果测试数量授权构建必需的夹具， 它也 可用于单元测试。Fit由

23、两部分组成：架构和用户创建的夹具。 Fit架构是通用 数据驱动测试解释程序，该解释程序读取输入文件并找出其中的所有表。 它在每 个表的左上单元查找夹具类名，然后搜索该类的可执行测试。当它找到类并读取 该表的行和列时，它会创建该类的实例并将控件传递给该实例。可以重写架构定 义的方法来指定表中各单元出现的情况。因此， Fit夹具是适配器，Fit调用它 来解释数据表并调用SUT上的方法。Fit表也可以包含SUT的预期2果。Fit将指定的值与SUT返回的实际值进 行比较。然而，与xUnit中的断言方法不一样，Fit在遇到第一个不匹配预期值 的值时不会终止测试。相反，它给表中的各个单元涂上颜色，绿色单元

24、表示与预 期值相匹配的实际值，红色单元表示错误的或意料之外的值。使用Fit有几个好处：与构建自己的测试解释程序GOF相比，要写的代码更少。输出对业务人员也有意义，而不只是对技术人员有意义。测试不会在遇到第一个失败的断言时停止。Fit可以用一种能够很容易看 出失败模式的方法传达多种失败/错误。照现在的样子，有大量夹具类型可以用来子类化或使用。那么，为什么不在所有单元测试中都使用 Fit取彳t xUnit呢？使用Fit的主 要不足如下所述：在构建Fit夹具之前，测试场景必须非常易于理解。因此需要将各种测试 逻辑转换为表格表示法，这不太合适，特别是对习惯于从过程思考的开发 人员而言尤其如此。它适合拥

25、有可以为客户测试写 Fit夹具的测试者的情 况，但这种方法不适合于真正的单元测试，除非测试者与开发人员的比例 为 1 ： 1。这些测试在每个测试中都要采用相同的 SUT交互逻辑5。要运行几种不同 类型的测试，很可能就必须为每种类型的测试构建一个或多个不同的火 具。构建新的夹具通常比写一些测试方法更复杂。虽然现在有许多不同 夹具类型可以用来子类化或使用， 但这种使用方法与要求开发人员学习以 便完成任务的方法不同。尽管这样，也不是所有单元测试都要使用Fit来进行自动化。Fit测试通常没有集成到开发人员通过 xUnit运行的回归测试中。相反，5表格数据必须在夹具建立或执行SUT阶段注入SUT或者在结

26、果验证阶段从SUT中检索这些测试必须单独运行，这样每次检入时它们有可能不运行。有些团队将Fit测试作为其持续集成构建过程的一部分，以部分解决这个问题。有的团队报告已经拥有辅助“客户”构建服务或运行所有客户测试的服务器。当然,这些问题都是可以克服的。总的来说，xUnit架构比Fit架构更适合于单元测试；Fit架构比xUnit架构更适合于客户测试。2 .变体：天真xUnit测试解释程序当需要作为基于xUnit的脚本测试策略的一部分运行的数据驱动测试的数量较小时，最简单的实现方式是写包含循环的测试方法，该循环从文件读取一组输入数据值以及预期结果。这与将单个参数化测试及其所有调用者转换为表格测试（参见

27、“参数化测试”）具有相同意义。和表格测试一样，这种构建数据驱动测 试解释程序的方法会产生具有许多断言的单个测试用例对象。它有以下几种结果：整组数据驱动测试将计算为单个测试。因此，将一组参数化测试转换为单 个数据驱动测试会减少执行的测试数量。当遇到第一个失败或错误时会停止执行数据驱动测试。因此，遗漏了许多 缺陷定位。有些xUnit变体允许指定失败的断言不中止测试方法的执行。需要确保出现失败时，断言失败能说出正在执行哪个子测试。在循环中包含try/catch 语句，同时包含测试逻辑然后继续代码执行， 这样 可以解决最后两个问题。然而，仍然需要能够以一种有意义的方法报告测试结果 （例如，“失败子测试

28、1、3和6以及”）。要更方便地扩充数据驱动测试解释程序来处理相同数据文件中几种不同类 型的测试，可以包含“动词”或“动作单词”作为数据文件中各条目的一部分。 解释程序可以依据动作单词分派给不同的参数化测试。3 .变体：测试套件对象生成器让测试套件工厂（参见“测试枚举”）上的suite方法伪造与测试发现内置机 制相同的测试套件对象结构，就可以避免与天真xUnit测试解释程序相关的“第 一次失败时就停止”这个问题。要这样做，可以为数据驱动测试文件中的每个条 目构建测试用例对象，然后用特定测试的测试数据初始化每个对象6这与xUnit的内置测试方法发现（参见“测11t发现”）机制的运行原理类似，但后者

29、接受的是测试数据和测试方法名称。构建测试套件时，该对象知道如何执行具有加载数据的参数化测试。这样即使第一个测 试用例对象遇到断言失败，也可以确保数据驱动测试能够继续执行。因此，可 以让测试运行器以正常方式计算测试、错误及失败。4 . 变体：测试套件对象模拟器构建测试套件对象的方法之一是创建像一个对象那样运行的测试用例对象。要求运行时该对象会阅读数据驱动测试文件并重新执行所有测试。 它必须捕获参数化测试抛出的所有异常，然后继续执行后面的测试。完成后，测试用例对象必须给测试运行器报告测试、 失败和错误的准确数量。 它也要实现测试运行器依赖的标准测试接口上的其他方法，例如返回“套件”中测试的数量、返

30、回套件中每个测试的名称和状态( 关于图形测试树探测器，参见“测试运行器” ) 。启发示例假设有一组测试如下所示：def test_extrefsourceXml = expectedHtml = abcgenerateAndVerifyHtml(sourceXml,expectedHtml,)enddef test_testterm_normalsourceXml = expectedHtml = abcgenerateAndVerifyHtml(sourceXml,expectedHtml,) enddef test_testterm_pluralsourceXml = expectedHt

31、ml = abcsgenerateAndVerifyHtml(sourceXml,expectedHtml,)end如下定义参数化测试可以简化这些测试：def generateAndVerifyHtml( sourceXml, expectedHtml,message, &block)mockFile =!(t)handler = setupHandler(sourceXml, mockFile ) unless block = = nil actual_html = assert_equal_html( expectedHtml,actual_html, message + html out

32、put)actual_htmlend这些测试存在的主要问题是， 这些测试还是用代码写的， 而实际上它们之间的唯一不同是用作输入的数据。重构说明当然，解决方案是将参数化测试的公共逻辑提取到数据驱动测试解释程序中，并将所有参数集合到任何人都可以编辑的单个数据文件中。需要写“主”测试，它知道从哪个文件阅读测试数据，知道阅读和分析测试文件的一些逻辑。该逻辑可以调用现有的参数化测试逻辑，并让xUnit记录测试执行统计。示例：使用XML据文件的xUnit数据驱动测试本示例中，使用*乂1式文件。每个测试都由test元素组成，它有三个主 要部分：告诉数据驱动测试解释程序要运行哪种测试逻辑的动作（例如， cro

33、ssref）。传递给SUT的输入，这里是sourceXml元素希望SUT expectedHtml元素中）生成的HTML这三个部分包装在testsuite 元素里：crossrefabccrossrefabccrossrefabcs所有拥有XM闾辑器的人都可以编辑这个 XM&C件，而不必担心引入测试逻辑错误。 数据驱动测试解释程序封装用来验证预期结果的所有逻辑， 使用的方法与参数化测试使用的方法相同。 出于查看的目的， 通过定义样式表对用户隐藏了XML的结构。另外，许多XM闾辑器会将XMLM换为基于表格的输入以简化编辑。为了避免处理操作XML勺复杂性，解释程序也可以使用 CSVC件作为输入示例

34、：使用CSV俞入文件的xUnit数据驱动测试使用CSVC件，前面示例中的测试则如下所示:ID, Action, SourceXml, ExpectedHtmlExtref,crossref,abcTTerm,crossref,abcTTerms,crossref,abcs它阅这个解释程序相对简单， 并且建立在为参数化测试而开发的逻辑之上。读CSVt件，并使用Ruby的split函数分析各行。def test_crossrefexecuteDataDrivenTest enddef executeDataDrivenTest filenamedataFile = (filename) do |

35、line |desc, action, part2 = (,)sourceXml, expectedHtml, leftOver = (,)if crossref= =generateAndVerifyHtml sourceXml, expectedHtml, descelse # new verbs go before here as elsifsreport_error( unknown action + )endendend除非将 generateAndVerifyHtml 的实现方式改变为捕获断言失败和增加失败计数器， 这种数据驱动测试才会在遇到第一个失败断言时停止执行。 而回归测试可

36、以接受这种行为，虽然它没有提供很好的缺陷定位。示例：使用Fit架构的数据驱动测试如果要进一步控制用户的行为，可以创建Fit “列夹具”，其中有id、action、source XML和expected Html() 各列，让用户编辑 HTML WeR面(如表18-1所示)。表18-1使用Fit架构构建的数据驱动测试Extrefcrossref?abc?TestTermcrossref?abc?TestTermPluralcrossref?abcs?使用Fit时，测试解释程序是测试专用的Fit夹具类扩充的Fit架构:public class CrossrefHandlerFixture exte

37、nds ColumnFixture extrefcrossextrefaTestTermcrosstesttermahref=TestTermcrosstestterm?abcs?预?abc? 实际测试自动化架构如何让编写和运行不同人写的测试更方便？可以使用架构，该架构提供运行测试逻辑所需的所有机制， 因此测试作者只 需要提供测试专用逻辑就行了。写和运行自动化测试包含几个步骤，但对于每个测试而言其中许多步骤都相 同。如果每个测试都必须包含这些步骤的实现方式， 写自动化测试就变得很单调、 很耗时间、容易出错并且成本很高。使用测试自动化架构是一种最小化写全自动化测试努力的方法。图18-4 测试自动

38、化架构示意图运行原理可以构建一种架构，它实现运行测试套件和记录结果所需的所有机制。这些机制能够找出单个测试、将它们组合为测试套件、依次执行每个测试、验证预期 结果、收集和报告测试失败或错误以及发生失败或错误时能够消除它们。这种架构提供了一种方法来插入并运行测试自动化人员写的测试专用行为。这样做的原因构建可重复且健壮的全自动化测试，该过程比写调用SUT的测试脚本更复杂。需要应付成功情况和错误情况，以及预期结果与意外结果。需要建立和拆卸 测试夹具，需要指定运行哪个（哪些）测试，运行一组测试后还要报告结果。构建全自动化测试需要的努力可能是测试自动化的严重阻碍。只提供实现最常见功能性的架构，可以大大降

39、低启动成本，学习使用架构时，才需要付出唯一的入门成本。同样，如果实现公共协议还可以降低成本，例如 xUnit ，在熟悉第一个架构之后，更容易学习第二或者第三个架构。使用架构也有助于将运行测试所需逻辑的实现方式与测试逻辑隔离开。 这种方法有助于减少测试码复制和最小化模糊测试发生的概率。它还可以确保不同测试自动化人员写的测试可以方便地在单个测试运行中运行，并可以提供测试结果的单独报告。实现方式说明有许多种测试自动化架构可用，既有商业厂商的，也有开源资源。它们可分为两大类： “机器人用户”测试工具和脚本测试。后面一类可进一步细分为测试自动化架构下的 xUnit 和数据驱动测试家族。1. 变体：机器人

40、用户测试架构许多第三方测试自动化工具可以通过用户界面测试应用程序。 其中大多数使用“记录与回放”测试隐喻。这种隐喻提供了一些非常诱人的营销材料，因为记录测试会话时， 它让测试自动化就像手动运行一些测试那样简单。 这种机器人用户测试工具由两个主要部分组成：“测试记录器”，它监控和记录用户与SUT之间的交互； “测试运行器” ，它执行记录的测试。大多数测试自动化工具也是架构， 这些架构支持许多“构件识别器”插件。大多数商业工具都有一批内置的构件识 别器。2. 变体：测试自动化架构的 xUnit 家族大多数单元测试工具属于自动化手写脚本测试（ 参见 “脚本测试” ） 的测试架构的 xUnit 家族。

41、 xUnit 已经移植到 （或者重新开发 ） 当前大多数编程语言。单元测试架构的 xUnit 家族由几个主要组件组成。 最显而易见的是测试运行器， 可以从命令行或者作为图形测试运行器（ 参见“测试运行器” ） 调用它。它构建测试用例对象，将它们集合到测试套件对象里，并调用各种测试方法。 xUnit 架构的其他主要组件是内置断言方法库， 这些断言方法在测试方法里使用， 用来指定各个测试的预期结果。3. 变体：数据驱动测试架构数据驱动测试架构可以插入解释程序， 这些解释程序知道如何执行特定类型的测试步骤。实际上，这种灵活性用“动词”和对象扩充输入文件的格式。这种架构还提供读入文件的测试运行器，遇到

42、相应数据格式时可以将控件传递给插件，并可以记录测试运行的统计数据。数据驱动测试架构家族最着名的成员是Fit ，它让测试自动化人员能够用表的形式写测试，而且能够“插入”夹具类，这些类知道如何解释特定格式的表。示例：测试自动化架构要理测试自动化架构在某种程度上似乎与各种可能的自动化测试方法不同。解这些变体，请参考记录测试、脚本测试和数据驱动测试，并查看各自测试自动 化架构的示例。高级阅读xUnit测试自动化架构一些最常见的示例有JUnit(Java) 、SUnit (Smalltalk) 、CppUnit (C+)、NUnit(所有.NET 语言)、runit (Ruby)、 PyUnit(Pyt

43、hon)和 VbUnit(Visual Basic) 。在上可以找到最新的完整列表，以 及可用扩展(如HttpUnit 、 Cactus)的列表。其他开源测试自动化架构包括 Fit、Canoo Web-Test和Watir。商业测试自 动化架构包括 QTP BPTffi eCATT等。在 Test-Driven Development -By Example TDD-BE中,Kent Beck 通过用 Python构建测试自动化架构来说明TDD在他比作“自己进行脑外科手术”的方 法中，他使用新兴测试自动化架构来运行自己为各种新性能所写的测试。这一 应用是TDCW步步为营法的最好示例。也称为最小

44、上卜义)应该使用哪种夹具策略？应该尽可能为每个测试使用最小、最简单的夹具图18-5最小夹具示意图每个测试都需要某种类型的测试夹具。 理解测试的关键是理解测试夹具， 并 认识到它如何影响测试的预期结果。如果夹具又小又简单，那么测试就更容易理 解。这样做的原因最小夹具对于实现作为文档测试和避免缓慢测试至关重要。使用最小夹具的测试总是比使用包含不必要或不相关信息的夹具的测试更容易理解。不管使用新鲜夹具还是共享夹具，结果总是这样，虽然使用共享夹具构建的最小夹具需要的 努力更高，因为它必须处理多个测试。 对于新鲜夹具而言，定义最小夹具更容易， 因为它只需要服务单个测试。实现方式说明设计的夹具只包含那些对

45、于表示测试验证的行为绝对必不可少的对象。换句话说，就是“如果对象对理解测试无关紧要，那么不要在夹具中包含它就至关重 要。”要构建最小夹具，就要“残酷地”从夹具中删除那些无助于测试传达SUT亍为的东西。可以考虑两种形式的“最小化”：可以删除整个对象。也就是说，不构建对象作为夹具的一部分。如果对象 对证明SUT的行为无关紧要，就根本不用包含它。如果对象的多余属性无助于理解预期行为，就可以将它们隐藏起来。要想知道作为夹具一部分的对象是否必不可少，一种简单方法就是删除它。 如果导致测试失败，那么对象在某种程序上可能是必需的。当然，如果作为我们 不感兴趣的某个方法的参数或者从未使用的属性 （虽然由于某种

46、原因需要该属性 所属的对象），它可能是必需的。包含这些类型的对象作为夹具建立的一部分肯 定会导致模糊测试。可以用下面两种方法之一删除这些不必要的对象：（1）隐藏它们；（2）接受哑元对象或使用实体链裁剪（参见“测试桩”）来删除这些对象。 然而，如果SUT执行测试中的逻辑时确实访问该对象， 那么就要求包含该对象作 为测试夹具的一部分。如果确定对象对于测试执行必不可少，那么现在就要看看该对象对于理解测 试是不是有用。如果将它初始化为“幕后”，理解测试会变得更难吗？如果作为 神秘访客（参见“模糊测试”），该对象会导致模糊测试吗？如果是，就要让该对 象保持可见。边界值就是这样一个很好的例子，在其中需要保

47、持具有边界值的对 象或属性可见。如果确定对象或属性对理解测试无关紧要，就应该从测试方法中删除它，但不需要从测试夹具中删除它。创建方法是实现这一目标的常见方法。 使用创建方 法用有意义的默认值填充所有“无关紧要”的属性，可以隐藏不影响测试结果但 构造对象时又必需的属性。也可以在创建方法内隐藏需要的依赖对象的创建，例如当写需要格式不良好的对象作为输入的测试时 （使用无效输入测试SUT）。在这 种情况下，为了弄清楚这个问题，可以显示传递给SUT的对象的所有有效属性，应该有许多这样的无关属性。不过，需要关注无效属性。要这样做，可以调用创 建方法来构造有效对象，然后用无效值 （想用这个值验证 SUT是否

48、会正确处理） 取代单个属性，这样用最少的代码通过一种坏属性模式 （参见“派生值”）来构建 格式不良好的对象。加比大具（也称为标准上卜义）应该使用哪种夹具策略?可以重复使用跨多个测试的测试夹具设计。要执行自动化测试，需要易于理解且完全确定的测试夹具。 为每个测试设计自定义测试夹具需要额外努力。标准夹具可以再利用多个测试中相同的夹具设计，且无需共享相同的夹具实例。图18-6标准夹具示意图运行原理标准夹具关乎态度胜过关乎技术。它要求在测试过程中尽早决定设计一些或 许多测试都可以使用的标准夹具， 而不是从单独设计的测试中提取公共夹具。从某种意义上说，标准夹具是整个测试套件的测试夹具“预先进行大量设计(

49、BigDesign Upfront) ”的结果。因此，可以使用这种公共测试夹具设计定义具体的 测试。标准夹具的选择与新鲜夹具和共享夹具之间的选择无关。在定义上，共享火 具就是标准夹具。然而，反过来却不正确，因为标准夹具注重夹具设计的再利用,而不是夹具构建的时间或其可见性。如果选择使用标准夹具，仍然需要确定每个测试是否构建了自己的标准夹具（ 新鲜夹具 ） 实例， 或者曾经作为共享夹具构建它接着在多个测试中再利用它。使用它的时机当我和丛书编辑Martin Fowler 一起检查本书的早期草稿时，他问我： “人们真的会这样做吗？”这个问题例证了夹具设计的观点划分。由于 Martin 具有敏捷背景，所

50、以他让每个测试都有夹具。如果几个测试刚好需要相同的夹具，那么就需要将它重构到 setUp 方法，并且将该类分解成每个夹具一个测试用例类。对于 Martin 来说甚至不会出现设计所有测试都可以使用的标准夹具。那么谁使用它们呢？在测试 （ 质量评估 ） 团体中， 标准夹具是惯例。 定义用作测试活动测试台的大型标准夹具很常见。 在手动执行许多客户测试上下文中这种方法很有意义， 因为它不需要每名测试者花大量时间为每个客户测试建立测试环境， 并且允许几名测试者同时在相同的测试环境中工作。 定义自动化客户测试时， 有些测试自动化人员也使用标准夹具。 当测试自动化人员因为明显原因使用共享夹具时， 这种策略尤其流行。在 xUnit 家族中， 使用标准夹具来避免为每个测试设计最小夹具， 这种用法不受欢迎，并且命名为一般夹具（ 参见“模糊测试” ） 。可接受的示例是使用与每 个夹具一个测试用例类结合的隐式建立，因为只有一些测试方法共享夹具的设计，他们这样做是因为需要相同的设计。在许多具有不同要求的测试间多次重复 使用标准夹具，会使它变得更庞大复杂。由于新测试需要引入中断标准夹具现有 客户的变更，这种趋势会导致脆弱夹具（参见“脆弱测试”）。依据构建标准夹具 的方法，如果因为测试隐藏夹具建立或者因为不知道标准夹具引用部分