自动化测试理论

首先，通常说来，受限于人力资源、产品规模和发布周期，任何大型产品都很难在发布之前对产品的各个方面进行全面的测试。我们只能根据新版本中的代码变更预测影响的功能和行为，并围绕这些影响区域进行重点测试，而对于其他区域测试完整性将大打折扣。这就为产品缺陷的滋生留下了隐患。另一方面，很多的测试都需要机械性的重复执行，比如冒烟测试、回归测试、性能测试、和长期运转测试（Long Run），这些测试的手工执行将占用大量的人力。由于缺乏充足测试的支持，开发者对产品结构性问题修正的风险将大大增加，从而使得开发者更倾向于针对问题的表象“打补丁”而不敢触及根本。

通过自动化测试，测试团队可以从这些繁冗的机械重复中解放出来，集中精力加强重点区域的测试力度，也有余力通过制定更完善的测试计划，设计合适的测试用例，改进自动化测试脚本来提高测试的整体覆盖率；从开发者的角度看，随着回归测试成本的降低，开发者也更有信心对产品进行结构性的调整。

呃，这是很奇怪的一个观点，对吧？在我们编写和调试自动化脚本的时候，或许能够发现一些产品的新问题，而一旦脚本投入使用之后，将不会帮助我们发现“新”的产品问题。因为，这些脚本只能不断的重复，来确保我们设计的测试用例在今后的日子里不会发现问题。自动测试脚本充当的更像是一个“守护者”而非“探索者”的角色，它将帮助我们更加确信产品没有问题。它们发现的问题通常都是回归性的，而不是新问题。

• 自动化测试需要成本

这又是一个显而易见的命题，不过自动化测试的成本经常会被忽略。和我们的产品一样，自动化测试脚本也是一堆代码。我们通过自动化测试来保证产品的正确性，而保证这些脚本的正确性却需要人工，这意味着我们需要开发、调试；产品是会不断演化的，昨天正确的脚本今天可能就是错误的，这意味着我们需要不断的维护。为了复用现有的脚本获得更大的价值，我们需要持续的改进自动化系统，甚至移植到新平台上。开发，维护，演进，请记住自动化测试需要长期的持续投资。

看过了上面这些内容，您是否会觉得自动化测试不再像想象中的那么美妙了？呵呵，请相信自动化测试并非万能，而现在的大型产品没有自动化测试的支持是万万不能的。作为我们的工具箱中的一个强力工具，我们需要用好它，发挥出它的威力。

自动化测试技术是保证产品质量的重要手段。随着敏捷开发方法的盛行和产品发布周期的缩短，产品对测试的要求也相应提高，因此自动化测试也变得比以前更加重要。冰冻三尺非一日之寒，和产品开发一样，产品的自动化测试系统也需要通过迭代开发不断强化，逐步解决效率瓶颈，更广泛、更灵活的支持产品开发的需求。那么，如何从无到有建立图形用户界面（GUI）产品的自动化测试系统？GUI 产品自动化测试每一阶段的目标是什么？在逐步演化的过程中，我们可能会面对哪些问题？这些又可以如何解决呢？本系列文章希望能够结合我们团队的经验，一一解答。在本文中，您将了解我们如何看待自动化测试，又是如何通过 RFT 来实现简单的测试目标。