应该知道的自动化测试陷阱2

陷阱6：所有测试都可以被自动化

　　并非所有的测试都可以被自动化。

　　自动化测试是手工测试的增强。乞求项目中的测试百分百实现自动化是不合理的。在首次引入自动化测试时，最好先验证一下，工具是否能识别出所有对象和第三方的控件。这对于基于GUI的测试工具来说非常重要，因为这类工具往往在识别一些个性化控件方面有困难，例如一些calendar、spin、grid控件，而这些控件被广泛应用在程序界面中，并且这些控件往往由第三方编写，大部分测试工具厂商未能跟上他们的发展速度。

　　测试工程师在碰到这种情况时要么放弃这部分应用了难以识别的控件的测试自动化，要么找出一些解决的办法。

　　另外，还有一些测试是基本上不可能被自动化实现的，例如，测试工程师可以实现自动化地把文档发送到打印机的过程，但是检查打印的效果（是否被正确地打印出来，有没有越过纸张打印线）这部分则必须人工进行。

　　至于哪些测试用例应该被自动化实现，可以参考下表决定：

    YES NO 测试执行的次数 测试会被执行多次吗？     测试会有规律地运行吗？例如经常被重用，作为回归测试的一部分或每日构建测试？     测试的关键程度 测试覆盖了软件功能的最关键部分的路径吗？     测试覆盖了最复杂的部分吗？（通常是最容易出错的部分）     测试的代价 如果手工进行测试的话，是否不可能、非常难以执行，例如并发测试、持久性测试、性能测试、内存泄漏测试等。     测试非常耗时吗？例如需要检查成百上千个测试结果输出。     测试的类型 测试需要组合很多输入，但是共用一个测试步骤吗？例如同一个功能，用很多不同的输入来验证。     测试需要在多种软硬件配置环境下执行吗？     被测试应用或系统 测试是在一个稳定的应用程序上执行的吗？例如功能特性已经基本完成。     使用兼容的技术和开放的架构    

　　陷阱7：自动化能提供百分百的测试覆盖率

　　并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。

　　自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。

　　例如一个简单的登录界面的测试，假设我们需要测试它的密码验证函数的正确性，密码长度在6到8个字符之间，每个字符可以大写或小写，至少包含一个数字，那么输入的可能组合将达到2,684,483,063,360个。

　　即使我们可以每分钟创建一个测试，也需要155年来完成全面的测试。因此，不可能穷尽所有可能的输入的测试。

　　陷阱8：测试自动化就是录制和回放

　　仅仅录制得到的不是有效的自动化脚本。

　　很多项目经理仍然把测试自动化等同于使用录制回放工具。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

　　陷阱9：自动化的软件测试与手工的软件测试过程一样

　　自动化测试所需要的技巧与手工测试所需要的技巧是不一样的。

　　通常，你的项目经理会被那些测试工具销售们迷惑，认为自动化的软件测试就是简单地按一个录制的按钮，产生测试脚本。而事实上并没有那么简单。

　　区分自动化测试所需要的技巧与手工测试所需要的技巧是非常重要的。最重要的是，自动化测试工程师需要掌握软件开发技巧，没有接受任何培训的手工测试人员，或者没有编程背景的手工测试人员，在实施自动化测试时会碰到很多困难。

　　陷阱10：忘记了测试的最终目标：找到BUG

　　在自动化测试中，同样要注意把边界值分析、等价类分析、基于风险的测试方法、挑选最合适的测试用例等技术应用起来。

　　通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但是我们往往忘记了测试的本来目的：找bug。

　　项目经理可能雇佣了最好的自动化开发人员来搭建框架，使用了最新最好的自动化开发技术，创建了成千上万的自动化测试脚本。但是如果BUG仍然被遗漏了，那些本该被自动化测试脚本捕捉到的BUG，结果没有被捕捉到，那么你的自动化测试仍然会被认为是失败的。

　　小结

　　正在你忧心重重，担心项目经理一步步迈向自动化测试的陷阱的时候，你看到了这篇文章，你决定拿给项目经理看看，希望他在看完这篇文章之后，对自动化测试有一个新的认识，从而把那只即将踏入陷阱的脚抽回来！