自动化测试的盲区

 
转帖加笔记，因为最近要写一份可行性分析报告~阅读了不少此方面资料，抛砖引玉~

————————————————————————————————————————————————

这里有几个原因导致GUI自动化测试比预期的要困难：

第一个原因是需要手工完成部分脚本。(~文中大概意思指的是业务逻辑及其复杂的，不适合做自动化测试~)

“录制回放”虽然可以生成部分测试脚本，但是有很多问题导致“录制回放”不能应用到整个测试执行过程中。

第二个原因把GUI自动化测试工具和被测试的产品有机的结合在一起需要面临技术上的挑战。(~工具不能识别控件的问题~)

非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。另外，还需要分析测试工具中的BUG，并且给工具打补丁。也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。

第三个原因GUI设计方案的变动会直接带来GUI自动化测试复杂度的提高。（~频繁的GUI变动~）

在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。花费大量的时间修改测试脚本，

~在此我再补充两点：

第四个原因就是功能不稳定，未经过手工测试，缺陷多、中断错误多的功能点，不合适实施自动化测试。

第五个原因就是功能变更频繁对于经常需要做需求变更的功能点，实施自动化会带来大量的脚本维护成本，不适合做自动化。

第六个原因就是涉及物理交互，工具很难完成与物理设备的交互，比如刷卡的测试、打印数据（检查打印格式是否正确）等。

第七个原因就是涉及人的感观方面，因为工具不具备想象力界面的美观、声音的体验、易用性的测试，工具无能为力。

 

~

 

 

工具本身并没有想象力和灵活性，而人对界面美观性、逻辑合理性，容易作出判断。所以功能测试自动化主要的应用在回归测试中，而且产品的界面(UI)和功能变化较大，自动化的脚本（scrīpt）维护成本较大

 

自动化测试前期投入大，对被测对象要求高以及存在其它的局限性。
软件测试自动化绝不能代替手工测试，它们两者有相应的测试对象和范围：
1) 工具本身并没有想象力和灵活性，根据业界统计结果，自动测试只能发现15-30%的缺陷，而手工测试可以发现70-85%的缺陷；所以自动化测试有其局限性，不适合软件的新功能测试，而特别适合回归测试，可以保证对已经测试过部分进行测试的准确性和客观性。

（~手工测试发现新的缺陷，自动化测试发现的是旧的缺陷；手工测试是探测的过程，自动化测试就是验证的过程~）
2) 在系统功能的逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，也很难通过自动化测试来实现，多采用黑盒测试的手工测试方法；
3) 单元测试、集成测试、系统负载或性能测试、稳定性测试、可靠性测试等比较适合采用自动化测试；
4) 当界面、需求变化比较频繁时、开发周期很短的软件、或做一次性软件开发项目（而不是做软件产品）时，自动化测试吃力不讨好，投入大而产出小。
5) 有些测试工具只能运行在Windows平台上，不能运行在Mac/Unix等平台上。
多数情况下，手工测试和自动化测试相结合，以最有效的方法来完成测试任务。(~这个是必须的，目前估计没有哪家公司可以说自己产品完全自动化测试，不用手工测试的吧~)

                 

3．软件测试误区：期望用测试自动化代替大部分人工劳动
　　目前，很多的企业首先是从节约成本的角度考虑去引入测试自动化工具的。是的，自动化测试工具的确能用于完成部分重复、枯燥的手工作业，但不要指望他来代替人工测试。一般来讲，产品化的软件更适于功能测试的自动化，由标准模块组装的系统更好，因为其功能稳定，界面变化不大。性能测试似乎更加依赖于自动化测试工具（如模拟多个虚拟用户和收集性能指标等），但考虑购买时也要注意，假设一个软件不支持DotNet Remoting，也许她就不一定适用于贵公司。