QTP的局限性以及我们的新尝试。

以下观点仅是作者工作经验，可能有较大的偏见。

用QTP的经验：
1. 在2009的时候，我用QTP做一个自动化工具，其中主要是用于自动化测试安装和卸载工具，其中某窗体的一个tree控件，在QTP上经常识别不出来。期间请教我们公司最牛的QTP同事，他也无法。而且，问题是时而出现，时而不出现。搞得很没有自信（包括对QTP和自己） 。

2. 在我们以前的团队中遗留下大量的QTP案例，大概400个左右。每次在RC时，这些案例只有15%左右跑不过，为了提高5%的通过率，通常我们团队三人经常加班（^--^），一直很痛苦，其中我们做了很多努力，但效果还是不好。很少在案例的回归测试中能发现bug.
3. 领导觉得85%的通过率与90%的都不能说明的问题。且我们发现QTP用的是类VB的语言，以后的市场潜力太小，市场竞争力不够。
4. 在经历了我们的以上两次的痛苦后，领导让我们放弃以前的QTP的UI案例。放弃QTP（这些QTP框架和案例是以前的团队做的大主要工作之一）。（这是个英明的决定哈）


新的尝试：
1. “一扇门关上了，会有一扇窗为你打开”，我们在放弃QTP后，领导要求我们将bug库中的bug进行案例化，要求做一个通用的自动化测试工具框架。
2. 我们一开始制订的框架目标是：只做以api可以案例化的bug，不做与界面有关的bug.
3. 在前2个季度中，我们严格控制bug案例的风险，将不稳定的案例都控制在2%以内。
4. 随着需求的变更，我们加入了autoit3来测试界面（delphi或windows原生态的界面）, uiautomation来测试界面(qt+qtaccessible)。当然，在加入这些之后，又变的稳定性差了一些。主要原因是：4.1 写案例的人存在粗心的情况， 4.2工具的的库需要不断的维护和修改，以适应新的需求
5. 目前这个测试工具框架，一直都在生产环境中使用。

我们的自动化测试工具框架（没有界面的QTP），名叫CCAT。

1. 数据库           管理案例的名称与组别、结果等信息。（ms sql）
        2. 工具调度外壳     根据不同参数，运行不同的案例，案例分布到不同的虚拟测试机上。(C#)
        3. 脚本公共库   根据不同的需求，加入不同的功能，就像积木一样，公共库中的东西越多可以测试的东西就越多哈。（其中主要包括：与winapi交互，与产品交互，autoite3包装的与界面的交互，uiautomation包装的与界面的交互，生成案例的结果文件，等等）(Python + C#[dll])
        4. 脚本文件     通用的结构，根据不同的案例，做不同的处理 。（main.py + run.py）
        5. 运行结果入数据库 网页展示（MVC）
        6. 其中参与者已超30人，案例数超4600，每天分布在不同的虚拟测试机上运行。

        其中还有附属：1. 公共库帮助文档（类msdn）。2. 案例入库、管理工具。(C#、VBA)
       

在投入使用了1年后，我们也发现了不少问题。
我们希望在做二期或重构的时候再去完善。
欢迎有相关的经验者给我们提出建议。