可维护性： 在工作中，我原来使用过一个测试套，他把所有的程式输出保留到文件中。然后，通过对照输出文件内容和一个已有的输出文件内容的差异，能称已有的输出文件为 “ 规范文件 ” ( “gold file” )。在回归测试中，用这个方法查找 BUG 是不是亮智之举。这种方法太过于迟钝了，他会产生非常多搭档的正告。跟着时间的推移，软件研发人员会根据需要修改产品的非常多输出信息，这会导致非常多自动化测试失败。非常显明，为了确保自动化测试的顺利进行，应该在对 “ 标准文件 ” 细心分析的基本上，依据研发人员修改的产品输出信息对之做相应的修改。比较好的可保护性方法是，每次只反省选定的产品的某些特定输出，而不是比照所有的结果输出。产品的接口变动也会导致原来的测试无法执行或执行失败。对于 GUI 测试，这是个更大的应战。钻研由于产品接口变化惹起的相关测试修改，并钻研使测试修改量最小的方法，测试中采用库是解决问题的方法。当产品发作变化的时候，只需要建改相关的库，确保测试和产品的变动同步修正便可。

　　完整性： 当自动化测试执行后，报告测试执行通过，能判断这是真的吗?这就是我称之为测试套的完全性。在前面的故事中，当没有对自动化测试完整性索取应有的关注的时候，产生了富有笑剧性的情况。我们应该在多大水平上置信自动化化测试执行结果?自动化测试执行中的误演讲警是非常大的问题。测试人员特殊厌恶由于测试足本本身的问题或是测试环境的问题导致测试执行失败，不过，关于自动化测试误呈文警的情况，自己往往无计可施。你希冀本人设计的测试对 BUG 非常迟钝、有效，当测试发现非常的时候，能够报告测试执行失利。有的测试框架支持对特地测试结果的分类方法，分类包含 PASS ， FAIL 和第三种测试结果 NOTRUN 或 UNRESOLVED 。不管你怎么称谓第三种测试结果，他非常好的阐明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到准确的测试结果是自动化测试完整性定义的一部分，另一部门是能够确认执行成过的测试确确切实已执行过了。我原来在一个测试队列中发现一个 BUG ，这个 BUG 惹起测试队列中部分测试用例被跳过，没有执行。当测试队列运行完毕后，没有上报所有差错，我不得不通过行读代码的方式发觉了这个 BUG 。如果，我没有关注到这个 BUG ，那么可能在认识到自动化测试已涌现问题之前，还在长时间运转局部测试用例。

　　独立性： 采用自动化方法不可能达到和手工测试同样的成效。当写手工测试执行的规程时候，通常假定测试执即将会由一个有脑筋、擅长念考、具有察看力的测试人员完成的。如果采用自动化，测试执行是由一台不会说话的计算机完成的，你必须告知计算机什么样的情况下测试执行是失败的，并且需要奉告计算机怎么复原测试场景才能确保测试套能顺利执行。自动化测试能作为测试套的一部分或作为独立的测试执行。测试都需要建立自己所需要的测试执行环境，因此，确保测试执行的独立性是独一的好方法。手工回归测试通常都相关的指示文件，以便一个接着一个有序地完成测试执行，每个测试执行能利用前一个测试执行创立的对象或数据记录。手工测试人员能明晰地掌握整个测试过程。在自动化测试中采用上述方法是经常犯的错误，这个错误流于 “ 多米诺骨牌 ” 测试套，当一个测试执行失败，会导致后续一系列测试失败。更糟糕的是，所有的测试联系关系紧稀，无法独立的运行。并且，这使得在自动化测试中分析正当的执行失败结果也困难重重。当出现这种情况后，人们首先开始疑惑自动化测试的价值。自动化测试的独立性需求在自动化测试中增长重复和冗余设计。具有独立性的测试对发现的缺陷的分析有非常好的支持。以这种方式设计自动化测试好像是一种低效率的方式，不过，首要的是在不牺牲测试的可靠性的条件下确保测试的独立性，如果测试能在无需人看管情况下运行，那么测试的执行效率就不是大问题了。

　　可沉复性： 自动化测试有时能够发现问题，有时候又无法发现问题，对这种情况其实没有什么好的的处置办法。因此，需要确保每次测试执行的时候，测试是以同样的方式工作。这意味着不要采用随机数据，在通用言语库中结构的随机数据常常暗藏始始化过程，使用这些数据会导致测试每次都以不同的方式执行，这样，对测试执行的失败结果分析是非常让人懊丧的。这里有两个使用随机数据发生器的的方法能躲免上述情况。一种方法是使用常量始始化随机数据发生器。如果你盘算天生不同品种的测试，需要在可猜测，并且可节制的情况下修立不同类型的随机数据发作器。另外一个措施是提早在文件中或数据库中树立天生随机测试数据，然后在测试过程中使用这些数据。这样做看止来好像非常好，不过我却原来看到过太多违背规则的做法。下面我来说明到顶看到了什么。当手动执行测试的时候，往往匆急忙忙收拾文件名和测试数据记录。当对这些测试采用自动化测试方法，该做哪些工作呢?方法之一是，能为测试中使用的数据记录给流动的命名。如果这些数据记录在测试完成后还要继承使用，那么就需要制订命实规矩，避任在不同的测试中命名冲突，采用命名规则是一种非常好的方法。但是，我原来瞅到有些测试只是随机的命名数据记录，非常倒霉，现实证明采用这种随机命实的方式不可防止的导致命名冲突，并且影响测试的可反复性。非常显然，自动化工程师低估了命名冲突的可能性。下面的情况我逢见过两次，测试数据记录的名字中包括四个随机发生的数字，经由简略的推算如果我们采用这种命实方式的时候，如果测试使用了 46 条记录，会存在 10% 冲突的可能性，如果使用 118 条记录，冲突的几率会达到 50% 。我以为测试当中使用这种随机命名是出于偷勤的设法主意 ?? 避免再次测试之前写代码肃清老的数据忘录，这样引进了问题，侵害了测试的可靠性和测试的完整性。

　　测试库： 自动化测试的一个通用战略是研发能在不同测试中运用的测试函数库。我原来看到过非常多测试函数库，自人也写了一些。当需求测试不蒙被测试产品接口变动影响的时候，采用测试库方法是非常有效的。不过，根据我的察看测试库已使用的太多了，已被滥用了，并且测试库往往设计的不好，没有相关的文件支持，因此，使用测试库的测试往往非常难开展。当发现问题的时候，往往不知道是测试库自身的问题，仍是测试库的使用问题。由于测试库往往非常繁杂，即使在发现测试库存在问题，相关的维护人员也非常不愿意去修改问题。通过前文中的阐述，能得出结论，在一开始就应该确保测试库设计良好。不过，实际情况是测试自动化往往没有花省更多的精神去确保一个精良设计的测试库。我原来看到有些测试库中的功能基本不再使用了或仅仅使用一次。这和极限编程准绳维持一致，即 " 你将不必他 " 。这会导致在测试用例之间的代码出现一些重复，我发现渺小的变化可能仍旧存在，非常难和测试库功能和谐。你可能企图对测试用例作修改，采用原始码的方式比采用库的方式更容易修改。如果有几个测试，他们有某些一同的操作，我使用剪切和粘揭的方式去复制代码，有的人以为我采用的方法不可理喻。这容许我根据需要修改通用代码，我不必一开始尝试和预测怎么重用代码。我觉得我的测试是非常容易读懂的，因为浏览者不必关怀所有测试库的语法。这种方法的劣势是非常容易理解测试，并且非常便利扩大测试套。在研发软件测试项目的时候，大少数程式员找到和他们计划实现功能相似的原始码，并对原始码做修改，而不是从头开始写代码。同样，在写测试套的过程中能采用上述方法，这也是代码研发方式所激励的方法,龙富足浴器。我比较喜欢写一些范围比较小的测试库，这些库能被重复的使用。测试库的研发需要在概念阶段充沛定义，并且文件化，从始至末都应该维持。我会对测试库作充沛的测试后，才在测试中使用这些测试库。采用测试库是对所有面临的情况作衡量的。千万不要企图写一个大而全的测试库，不要希望有晨一日测试人员会利用你的测试库完成大量的测试，这一天生怕永久不会到来。

　　数据驱动测试： 把测试数据写入到简单表格中，这种测试技术得到了越来越普遍的运用，这种方法被称为表驱动( table-driven )，数据驱动 (data-driven) 或 “ 第三代 ” 自动化测试( "third generation" automation )。这需要写一个解析器，用来注释表格中的数据，并执行测试。该测试架构的最主要的利益是，他容许把测试内容写在具有必定格局的表格中，这样便利数据设计和数据的检视。如果测试组中有缺乏编程经验的业务专家参和测试，采用数据驱动测试方法是非常合适的。数据驱动测试的解析器主要是由测试库和上层的少量研发言语写成的代码组成的，所以，上面关于测试库的阐明放在这里是同样合适的。在针对上面提到的少量代码的设计、研发、测试的工作，还存在各种困难。代码所采用的编程语行是不时开展的。或许，测试人员认为他们需要把第一部分测试的输出作为第两部分测试的输入，这样，参加了新的变量。接下来，或许有人需要让测试中的某个环节运行一百次，这样参加一个轮回。你能采用其他语行，不过，如果你意料到会见临上述情况的时候，那么做好采用一些能够通过公然的渠道获取的编程言语，好比 Perl,Python 或 TCL ，这样比设计你自己的语言要快的多。

　　启示式确认： 我原来望到非常多测试自动化没有实正意义上的结果校验，其原因有两个，一个原因是做完整意义上的自动化测试解果确认从技术上道是非常困难的，另外一个原因是通过测试设计规格非常难找出自动化测试的预期结果。这非常倒霉。不过，采用手工校验测试结果的方法是真正意义上的测试校验。本准文件( Gold file )是另外一中校验测试结果的方法。首先，捕获被测试程式的输出，并检视程式的输出，然后，把输出疑作文件化，并回档，作为尺度文件。以后，自动化测试结果和规范文件作对比，从而达到成果校验的目标。采用本准文件的法子，也有弊病。当产品发作变化，自动化测试的环境设放产生变化，产品的输动身生变化的时候，采用规范文方法，会上报大批的误讲演警。做好的测试结果校验方法是，对输出结果的特定内容作剖析，并作公道的比拟。有时候，非常难知讲准确的输出结果是什么样的，不过你应该知道差错的输出结果是什么样的。启铺启迪式的结果校验是非常有辅助的。我料想一些人在自动化测试中设计了大而齐的测试结果校验方法，是由于担忧假如结果校验遗漏了所有疑作，可能导致自动化测试本身呈现搭档。不过，我们在测试历程中往往采用调和的做法，没有采用大而全的测试结果校验方法，这样就不得不面对少质漏测情况的出隐的威严险。自动化测试不能篡改这种情况的涌现。假如自动化工程师不习性采用这种合衷的方法，那么他必需觅相关人员征询，寻觅一种适合的测试结因校验战略，这需要有非常大的发明性。目前有非常多技术能确保在不发生误呈文警的情况下，找到被测试产品的缺点。