通过亲前面的文章我们了解了软件的一些新的变化之后，我们再来看看我们所用的自动化的测试技术存在哪些问题。
测试录制自动化程度低
首先测试录制的自动化程度是非常低的，我们传统的自动化测试技术，无论是Selenium这种开源自动化测试平台，还是一些商业测试工具产品，主要的自动化脚本开发的录制技术都是基于UI的，无论是基于浏览器的还是基于APP的，或者是基于CS、.NET、java的，它的录制都是和UI是紧密结合的，在通用性上就会带来很多问题。
再就是UI元素识别的不智能，我们传统的脚本录制的相关工具是非常依赖于UI元素的，对于UI元素的相应内容都有一套固定的转换规则，对于UI元素里面的一些变化，它的识别实际上很不智能。
再就是脚本和用例的转化，大部分的自动化测试工具的脚本和用例实际上是没有产生关联的，他们之间是脱钩的，没有产生相互转换的关系，用例就是用例，脚本就是脚本。这个也给自动化测试带来了很多问题，用例实际上和脚本应该是紧密关联的。
测试录制兼容性差
旧版本的终端，比如说像IE有很多老的版本，像在银行里，现在很多都还在用win7+IE10这种配置，对于IE旧版本，很多测试工具的录制都会出现问题，很多控件和元素的识别并不是非常理想。
智能终端，越来越多的智能终端是类CS架构的，它的客户端是完全定制化开发的，对这些定制化智能终端的录制兼容性也是会非常差的。很多定制化开发的软件内容，实际上是很难去录制下来。
多端协同，现有的测试工具的脚本一般都是跟UI的开发技术是紧密相关的，多端协同性就比较差，但是多端协同的场景却是非常多的，比如说有APP端，有BS、浏览器端，还有没有UI的后台服务端，像这种多端协同的场景，很难通过一个工具去进行通用性的解决。
通用方案，因为工具是依赖于具体的客户端的技术，很难有一个通用方案能把各个端的脚本覆盖到，这样的方案目前也非常的少，传统的自动化工具无法提供这种通用方案的解决方式。
测试脚本开发难度大
测试脚本的开发对开发能力的要求是非常高的，开发人员需要掌握很多相应的开发语言，了解很多API、函数...然后才能进行相应的开发。
再一个就是脚本是非常难以理解的，脚本是大量的代码，它的含义是非常难以理解的。
第三个方面是，脚本非常依赖于UI，每个脚本都要依赖于相应的UI的开发技术。最后一点是脚本是不通用的，你的脚本开发完以后，很有可能在UI发生变化之后，脚本就不再能够使用了，这个脚本的价值就没了，相应的成本就会提升很多。
测试脚本运行问题
运行任务的定制化和运行环境的定制化现在的测试工具都无法去提供，它更多是解决整个脚本的录制回放，然后做一些简单的任务的处理，定制化相对来说做的都是不够好。
再就是刚才说的旧版本终端不兼容的问题，而且运行的过程是很难去追溯的。很多时候你只知道最终的运行结果，但是不知道整个过程的执行过程。执行过程中有哪些问题，执行情况怎样，这个是非常难以去追溯的。
