如何构建结构良好的测试框架
1个回答
展开全部
这段时间一直在为公司内部开发
自动化测试框架
,简称GTF,因为这个框架现在还属于开发阶段,很多事都是言之过早。我会持续将我在架构过程中的想法写下来。供自己和大家一起分享。
这些想法,并不属于我一个人,我工作中的同事们给了我很大的帮助。
今天这一篇主要说明架构方面的考虑。
在现有的提供自动化测试解决方案的产品很多,包括:Robot,TestComplete,WinRunner等等。我只接触过这些,公司里也进行过很大的尝试,但是结果往往总是不竟如人意。
这中间,排除那些人员方面的原因,也总结这些自动化工具
,在使用过程中的不方便的地方:
1. 定位控件不方便。标准控件还好,非标准控件就只能靠很多非正常方法去获取。而且,控件的识别往往和界面布局相关。
3. 代码维护不方便。由于在编写过程中,大量的和界面相关的代码,导致最后在需求变更的时候,代码的维护,成为软件测试人员的负担。
针对这些情况,我们经过讨论,何不自己做一个软件测试框架。当然了,这是基于我们的丰富的知识积累的决策。大家不需要关心这个决策的情况。不过,可以多关注一些我们在做的过程中的分析结果。
通过分析流行的软件测试框架,有多种方式:
第一、最典型的就是消息驱动,自动化工具通过脚本录制和编写,保存为测试脚本。在回放的过程中,将这些脚本转换成为Windows消息,发送给我们应用程序的窗体和各种控件。
这种方式的好处在于,自动化工具和应用程序之间能够做到完全的隔离。但是,由于使用了Windows消息,它也拥有了一个非常致命的缺点。那就是消息队列的异步性与程序的顺序性之间的矛盾。很多消息发送给了应用程序,但是应用程序的处理可能已经和消息队列错位了。有一些关于代码的时间片等待,就是因为这个问题。
另外,就是由于完全的隔离,对于操纵控件数据的能力大大降低。毕竟,拥有大量数据的控件都不是标准控件。
自动化测试框架
,简称GTF,因为这个框架现在还属于开发阶段,很多事都是言之过早。我会持续将我在架构过程中的想法写下来。供自己和大家一起分享。
这些想法,并不属于我一个人,我工作中的同事们给了我很大的帮助。
今天这一篇主要说明架构方面的考虑。
在现有的提供自动化测试解决方案的产品很多,包括:Robot,TestComplete,WinRunner等等。我只接触过这些,公司里也进行过很大的尝试,但是结果往往总是不竟如人意。
这中间,排除那些人员方面的原因,也总结这些自动化工具
,在使用过程中的不方便的地方:
1. 定位控件不方便。标准控件还好,非标准控件就只能靠很多非正常方法去获取。而且,控件的识别往往和界面布局相关。
3. 代码维护不方便。由于在编写过程中,大量的和界面相关的代码,导致最后在需求变更的时候,代码的维护,成为软件测试人员的负担。
针对这些情况,我们经过讨论,何不自己做一个软件测试框架。当然了,这是基于我们的丰富的知识积累的决策。大家不需要关心这个决策的情况。不过,可以多关注一些我们在做的过程中的分析结果。
通过分析流行的软件测试框架,有多种方式:
第一、最典型的就是消息驱动,自动化工具通过脚本录制和编写,保存为测试脚本。在回放的过程中,将这些脚本转换成为Windows消息,发送给我们应用程序的窗体和各种控件。
这种方式的好处在于,自动化工具和应用程序之间能够做到完全的隔离。但是,由于使用了Windows消息,它也拥有了一个非常致命的缺点。那就是消息队列的异步性与程序的顺序性之间的矛盾。很多消息发送给了应用程序,但是应用程序的处理可能已经和消息队列错位了。有一些关于代码的时间片等待,就是因为这个问题。
另外,就是由于完全的隔离,对于操纵控件数据的能力大大降低。毕竟,拥有大量数据的控件都不是标准控件。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询