自动化测试是如何实现的？

qyangxjtu

自动化测试工具在测试中扮演了什么角色？

自动化测试是如何实现的？（为什么可以实现自动化测试？）

如果我要实现通过web页面配置router并进行测试，用测试脚本如何实现和router的交互？

只是通过命令行实现对router的配置和测试，自己实现全部自动化测试功能，只是实现能模拟手工测试，需要解决哪些问题？是不是不可行？还是得靠自动化测试工具，如CDRouter等？

自己写一个测试框架是不是就不用其他的测试工具了？

刚接触自动化测试，很多基本概念都很迷糊，谢谢各位了！

[ 本帖最后由 qyangxjtu 于 2008-12-11 16:24 编辑 ]

qyangxjtu

找到一片文章，似乎有点关系。查看了文中最后介绍的两个软件，介绍如下：
AutoRunner是黑盒测试工具，可以用来完成功能测试、回归测试、每日构建测试与自动回归测试等工作。是具有脚本语言的、提供针对脚本完善的跟踪和调试功能的、支持IE测试和Windows native测试的自动化测试工具。

产品可以进行：
Web测试——对B/S系统进行功能测试，支持各种B/S应用和网站。
.NET测试——对.NET类型的应用软件进行功能测试,支持标准Windows应用程序测试和.NET应用程序测试。

（后来发现，最后两句话是生产该软件的公司加的，原文不是这样，呵呵）

和我需要的功能相差较远。因为我需要的功能还包括与router交互，不是一个纯软件的测试
TestComplete的实现还是不明白，如果我的程序里没有控件，纯字符界面操作，那怎么办？



在现有的提供自动化测试解决方案的产品很多，包括:Robot，TestComplete，WinRunner等等。我只接触过这些，公司里也进行过很大的尝试，但是结果往往总是不竟如人意。
这中间，排除那些人员方面的原因，也总结这些自动化工具，在使用过程中的不方便的地方:
1. 定位控件不方便。标准控件还好，非标准控件就只能靠很多非正常方法去获取。而且，控件的识别往往和界面布局相关。
2. 验证数据不方便。这点更是针对非标准控件(什么?你不用非标准控件?)，数据的检测，甚至夸张到使用图片检测。
3. 代码维护不方便。由于在编写过程中，大量的和界面相关的代码，导致最后在需求变更的时候，代码的维护，成为软件测试人员的负担。
针对这些情况，我们经过讨论，何不自己做一个软件测试框架。当然了，这是基于我们的丰富的知识积累的决策。大家不需要关心这个决策的情况。不过，可以多关注一些我们在做的过程中的分析结果。
通过分析流行的软件测试框架，有多种方式:
第一、最典型的就是消息驱动，自动化工具通过脚本录制和编写，保存为测试脚本。在回放的过程中，将这些脚本转换成为Windows消息，发送给我们应用程序的窗体和各种控件。
这种方式的好处在于，自动化工具和应用程序之间能够做到完全的隔离。但是，由于使用了Windows消息，它也拥有了一个非常致命的缺点。那就是消息队列的异步性与程序的顺序性之间的矛盾。很多消息发送给了应用程序，但是应用程序的处理可能已经和消息队列错位了。有一些关于代码的时间片等待，就是因为这个问题。
另外，就是由于完全的隔离，对于操纵控件数据的能力大大降低。毕竟，拥有大量数据的控件都不是标准控件。
第二、嵌入式。TestComplete就是这类工具。它有支持不同语言的版本。大概思路，就是在程序编译的时候，注入自己的控件代理。脚本的回放，直接可以通过代理，操纵到应用程序。
可惜的是，这类软件开发的时候，更多的是考虑平台的兼容性。对于特有平台上的支持不是十分完美。特别是对自定义控件(比如Delphi中，除了VCL的标准控件)支持也没有做到最好。不过，我这里必须承认，TC的内部实现机制可能十分强大，我不能窥探所有。如果有人清晰，可以指点一二。
针对上面的两种，我们想到的第三种方式:一体式。这种方式中，通过给程序在打包的过程中，添加额外的框架代码，使得程序自动提供控件的访问方式。自动化的模块也会作为软件测试程序的一部分运行。
应用程序在执行脚本的时候，自动通过脚本，控制各控件界面的显示和关闭。它应该是第二种方式的变种。但是由于是自己实现的，所以在对各类自定义控件支持的都非常好。
针对一开始提出的几个自动化测试的难题，我们提出了，自动封装窗体上所有控件的概念(这些概念后面会详细介绍)，对于软件测试人员，只要关心真正的业务操作流程。而业务流程中涉及到的控件，已经为他们自动提供好。这样，脚本也自然只成了业务流程的脚本。其复杂度也就大大降下来了。
按照这个思路，最主要的是可以充分发挥“程序是我们自己的”的优势，对于测试人员，开发人员是他们的最好的访问控件的工具。有什么控件找不到，开发人员可以快速地给他们适配一个访问方式。这也大大降低了软件测试人员对软件系统内部的了解程度。
如果要推荐2个工具的话，我就推荐泽众软件公司的自动化测试工具AutoRunner和测试管理工具Testcenter，用这2个软件合作可以很好的进行自动化测试与对测试用例进行管理。

[ 本帖最后由 qyangxjtu 于 2008-12-11 18:40 编辑 ]

qyangxjtu

看了一些资料，似乎可以把我的问题定义为：如何实现嵌入式产品自动化测试？

当然，还是不明白自动化测试是如何实现的！
消息驱动，自动化工具通过脚本录制和编写，保存为测试脚本。在回放的过程中，将这些脚本转换成为Windows消息，发送给我们应用程序的窗体和各种控件。
如何实现将脚本转换成Windows消息？

有篇文章《基于MMI的嵌入式软件自动化测试平台设计与实现》，可惜没找到下载地址

qyangxjtu

下面的例子是转载。我个人理解，自动化测试工具做了比高级程序员更多的事情，使得我们可以通过简单的脚本来实现自动化测试。
也没有哪位开发过自动测试工具的前辈来答疑，:-)

用一个小例子来说明手工测试，自动化测试，系统命令，编程语言，API的关系用一个小例子来说明手工测试，自动化测试，系统命令，编程语言，API的关系
很多人理解的自动化就是把手工测试case用脚本和工具转变成自动化测试。也就是说把手工测试的每一个步骤用脚本来模拟，从而执行test case。那么自动化的所有问题就归结于，如何用工具和脚本 来转化手工操作步骤了。还有很多非常senior的，但是不会coding的手工测试工程师强调case的design能力是如何如何重要，自动化相对来说不是那么重要。我这里可以肯定的说，没有好的编程功底，你也不可能涉及出非常好的test case, 自动化的开 发也不应该是仅仅把手工操作用脚本来模拟，而是应该大幅度的改变test case，使得能够用最好的方式来进行自动化。那些手工测试人员所谓的设计case的重要性，和他们设计case的高水平，实际上只是在他们的知识范围之内产生的观点。下边我用一个小例子来说明，编程能力在自动化过程中起的作用到底有多大。基本上来讲，有多强的开发水平，就有多强的自动化设计，实现水平。自动化开发和产品的开发实际上都是一样的，都是有需求，你来实现。当然，不同水平的人，实现起来的效果是千差万别的。这也就是为什么开发有高手，有低手，自动化测试的开发也同样有低手，有高手。自动化测试水平没有上限，你要学会发挥自己的无穷潜力。
不多说了，现在说一下我们要自动化什么问题。我们有两个计算机帐号，A和B。我们需要用B帐号进行系统的设置，也就是测试的准备工作，然后用A帐号来进行测试。下边来说一下不同水平的人是如何进行自动化的。
1. 手工测试人员
Log on BConfigureLog outLog on ATest2. 初级自动化人员（直接把手工case转成自动化）
Set autologon BSet autorunRecord test status: 0LogoutCheck statusif(status==0){    Configure    Set autologon A    Record test status:1    Logout}
if(status==1){    Test}
这个级别的人，需要懂得脚本编程，需要懂得系统设置，autologon and autorun。
3. 有一定经验的自动化人员（改变手工测试case以利于自动化的更简单，可靠的实现） 
不需要log out and log on利用Windows命令Runas用高级语言调用Runas利用重定向来输入Password这个级别的人，需要懂得高级语言，重定向，Windows系统命令Runas
4. 中级自动化人员（具有更丰富的开发经验，可以用程序代替UI和系统命令）
不需要Runas命令利用.NET的Process对象用B的身份生成一个Process来进行配置工作这个级别的人，要比较熟悉高级语言，比较熟悉高级语言的类库，懂得操作系统的内核基本概念
5. 高级自动化人员（精通高级语言，精通操作系统内核）
不需要多生成一个进程用本线程impersonate用户B利用.NET WindowsIdentity 对象必须要调用Windows API，LogonUser这个级别的人，要精通C/C++和Java，C#等高级语言，精通Windows内核的知识和Windows API