关于公司的自动化测试（二）！

自动化测试的回归——测试用例（功能测试）。

研究了很长时间的GUI测试，却发现纯粹的GUI测试根本无法满足自动化测试的需要，而自己思考问题的范围却被局限在GUI测试上。似乎离开了GUI测试都不算是自动化测试，可是GUI测试在项目的测试中的作用并不明显，并且花费的时间很多，脚本比较独立，很难被调用，很难维护。并且自动化测试成了一个与我们实际测试工作中毫无关系的多余的一部分，成为了附属的多余工作，于是我们总是觉得时间不够用，甚至很疑惑难道这就是我们需要的自动化测试么？

这段时间的思考让我发现我们理解的自动化范围太窄，似乎功能的自动化测试就等于GUI的自动化测试，除此之外都与自动化测试无关。

现在我发现GUI测试只是自动化测试的一部分，并且是很小的一部分，甚至同时我们还需要很多后台的处理来保证GUI测试的成功执行。比如对GUI测试环境的恢复需要对数据库的操作和处理。（没有这部分的工作，GUI的测试几乎是不可能地。）而还有很大一部分的工作是与GUI测试无关的。如果这些大部分的工作不能自动执行，或者不能通过简单的操作就能执行那自动化只是纸上谈兵，离自动化还差的很远。

我觉得自动化的目的是降低我们的工作量，是对工作有利的，是项目相关的（我们实现自动化必须是与具体项目有关的，因为每一个项目都有它自己的特点），而违背了这个原则的自动化对我们来说是不是需要是个值得思考的问题。有一个简单的标准来衡量项目自动化的程度：能够多大程度上减少工作中花在重复工作中的时间。从这个意义上说，这不仅包括GUI的测试，还包括数据的准备，以及各种与GUI没有关系的后台数据的校验，和其它一些可以被取代的重复性工作。这些也应该是我们自动化测试的目标，成为我们自动化测试的一部分。因为它们是我们项目工作的一部分

为了实现这个目标，我们应该回归到我们项目的测试用例。我们需要做的所有的工作都会在用例上包括。（如果测试用例上没有，证明我们的测试用例不是完善的了，呵呵)。用例中主要包括2个主要的部分，测试数据和测试用例。测试数据准备我们所需要的所有的测试相关的数据记录。而测试用例则包括测试的Pre－condition和after condition，以及测试的步骤，测试涉及数据的编号，测试的每一步执行的期望结果。看看这包括了所有GUI测试所需要的元素，当然也包括了所有其它自动化测试所需要的要素。

现在我们可以来设想一下如果我们能够把我们的用例做的足够完善，以满足我们自动化测试的需要。其实自动化的过程就是把测试用例翻译成自动化脚本的过程。用程序来实现和替代我们手动需要完成的工作。这样自动的目的就达到了。

而自动化的实现的步骤和路径就是不断地完善我们的测试用例，自动的完成测试数据的准备，自动的完成测试的用例。而这需要我们能够让自动化的测试工具和我们的测试用例很好的融合起来。可以一步步去实现，相信每一步的成功都能给我们的工作带来很大的便利。

如果能够放开去思考问题，真正为了改善我们的工作去学习和工作，这些才是最重要的，才是我们真正需要地！