阿里巴巴测试面试题
春节刚刚过去，也是各大公司开始抢人的时刻。最近帮忙准备几个自动化相关的题目，以前参加面试的时候总被问到些奇怪的问题，所以我出题本着开放的原则，题目本身没有什么答案，要的是你能说服我，或者让我知道你比较关注于技术圈子的事情。知识面我觉得很重要，呵呵…1. 如何理解自动化测试，用测试工具进行测试等于自动化测试这句话对不对?
关注点:测试工具的使用是自动化测试的一部分工作，但“用测试工具进行测试”不等于“自动化测试”。自动化测试，模拟手工测试步骤，通过执行程序语言编制的 测试脚本自动地测试软件。 自动化测试，强调借助工具(不仅仅是工具，有时包括策略和工件)来完成测试的执行，也就是用工具来帮助或辅助测试。但是用测试工具进行测试有可能是自动化，半自动化，或者手工测试。
2. 介绍下比较了解的自动化框架，watir，selenium，QTP…..任选一个说说，这个框架的工作原理是什么?
随便选取一个，重要的是原理，而不是使用。大家在用这些框架的时候，一定要关注背后的执行原理.看源码是一个比较简单的途径。
3. 介绍下SoapUI，如果你用着的话。这个框架需要注意什么?
soapUI是一款桌面应用程序，能够监测、触发、模仿以及测试(功能和负载)基于SOAP/WSDL和REST/EADL的HTTP网络服务。
和大多数的工具一样，都是使用HTTPREQUEST对相应的资源进行请求很提取。再得到response之后进行相应的处理，对XML进行XPATH定位。注意的是SOAP方法中包含GET，POST的方法，POST的方法主要使用Application/xml的MIME形式发送相应的POST数据。
4. 对webservice层面的自动化测试，你认为比较重要的是什么?
对webservice的测试主要分为两个阶段，首先是对WEB Ui层面的数据XML Response与webservice的schema进行对比测试，其次是web Ui层面的数据与数据库服务器中相应的数据进行验证。
5. 对持续集成工具有了解过吗?类似于Jenkins(hudsoon)/Bamboo/Teamcity这些持续集成的工具,有了解过这些吗?
目前比较这几个还算比较流行，阿里主要集中在用hudson。Teamcity在以前的公司了解过。
6. 桌面自动化测试和WEB 自动化测试的区别?
驱动方式不同，C/S架构(或者桌面类型)界面自动化测试，采取的方式可以调用操作系统本身的API(windows桌面软件)来构建自动化测试或者可以采用虚拟机内(java swing程序)的事件处理机制来完成了。
WEB 自动化测试 B/S架构，原理就是依靠JS来进行客户端的操作，然后寻找对象是采用了DOM解析技术，将web方面的节点进行解析定位
7. 自动化测试碰到比较难解决的问题是什么?如果出现这些问题给出你的解决方案?
重点引导到测试结果定位准确这个角度上来, 在自动化程度比较高，case很多，就会存在排查失败的case过程。
解决方案; case错误分类，有效的log日志，异常信息的抓取
8. IOS支持UI自动化，主要有2种方式，介绍下这2种方式?
1.苹果官方提供的技术， UI Automation。
2. 就是在应用中注入测试代码。
Instrument uiautomation 是苹果官方提供的iPhone手机应用的自动化测试工具。控件元素的识别准确，属性获取，元素操作的API丰富。可以很方便的录制测试脚本、回放和查看运行结果。
果然是互联网公司，主要web，， 谢谢分享！刚入门还没接触到自动化测试，看起来好深奥:o 有点复杂 问题不错，我随便挑一个第七题来回答一下。另外本文收录在我的博客里http://www.cnblogs.com/sdet/p/5492030.html
问题：自动化测试碰到比较难解决的问题是什么?如果出现这些问题给出你的解决方案?
回答：
比较难以解决的问题是：
1，自动化测试没有达到预期目标，既没有节约人力，也没有提高产品质量。
自动化测试脚本会频繁报错，但错误原因多半是脚本问题而不是产品质量问题。
现在程序员们用测试开发的身份进入测试界，在测试界搞了很多自动化测试，然而并没有什么用。
测试人员/测试开发人员并没有在做测试，而是一直在分析脚本误报的错误，一直在修改失效的脚本。
然而却没有意识到，这些测试假如从测试角度看，实在很弱。
举个例子吧，
我们做了一组冒烟测试用例，期望以此找到系统上最高级的A级bug，当我们找到A级bug时，测试暂停，开发人员需要先行修复A级bug。
事实上，我们的冒烟测试用例三个月内失败过十五次。但其中A级bug只有3次。而且，其中2次不是冒烟测试用例找到的bug，而是装包时找到的（此处装包可以理解为安装待测软件）。
剩下1次的A级bug是导致系统提供的网络服务直接不能用的问题，这也是唯一一次我们真正用这组冒烟测试用例找到的bug。
其余12次，都是系统功能更新了，而脚本没更新，导致的误报错误。这导致了我们12次中有8次我们或其他相关人员加班修改测试用例。因为这个测试如果失败，后续自动化测试流程不会执行。
这问题说明了什么呢？
从经理们的角度来看，问题异常简单。测试人员晚上不上班，那么设备就空了，等于浪费了资源。搞个自动化测试吧，这样晚上也能测了，多好呀。反正测试这玩意儿都是重复劳动，根本不需要人工干预。
让电脑自己去测试另一台电脑不就好了吗，就像两个角斗士在竞技场里PK，我们看看就好。
从测试人员的角度来看，问题异常复杂。ok，经理说了算，我们就按照他的想法来实现了。或者说不是经理，有些挂着测试架构师头衔的人也这么幼稚地看问题。ok，我们按照这些老大们的要求，写了很多测试脚本。
我们假装这些测试脚本可以代替人工测试。
当然，其实并不能代替。这些测试有多傻，上面的例子已经说明了问题。更别说测试脚本本身还有一大堆的自己的bug，比如语法错误。特别是隐含着的语法错误。一般你如果是一个测试人员，要你测某个场景。
即使你是新手，你也想到，哦，pass的流程是怎样的，fail的流程是怎样的。对吧。
但是写测试脚本的人想不到。他写的测试脚本在系统上执行了，pass了，万岁。过了一个月，系统上跟这个测试有关的模块更新了，开发人员没通知测试人员或测试开发人员。那么问题来了，这个时候测试pass了，到底是真的pass呢，还是
凑巧pass了呢。这个时候测试fail了，不用说，99%都不是待测产品质量问题导致的，而是测试脚本没跟着系统更新导致的。
再举一个例子，充分说明一下为什么测试脚本非常弱智。
我们有好几个测试用例，是在 系统安装/系统重启/系统锁定和解锁 完成之后，检查其中各个虚拟机启动时间的。
测试脚本编写人员写了，做了上述操作后，如果超过1000秒，没启动好，那么就使测试失败。
就这么简单一个测试脚本。假设语法都对，脚本也是最新的，和系统版本相匹配。其中有什么问题？
这里的问题是，测试脚本只检查了启动超时的异常。对啊，这是很合乎那些测试脚本开发人员的逻辑的，需求说系统要在1000秒内启动好。那么就写个脚本，让他在超过1000秒还没启动好时报个错啊。
到此为止，都是程序员思维。
测试员思维是这样的：系统启动慢了，固然要报错。如果系统启动太快了呢。
我一个本来启动都要600秒的软件系统。今天他突然只花了200秒就启动好了。说明了什么？肯定有问题啊！！！！怎么可能凭空缩短了400秒？？？而且这是什么问题？这是严重问题，十有八九非常的严重。
这么严重的问题，人工测的时候，正常的测试员百分百能发现，而测试脚本，百分百不能发现。这就是写脚本的思维啊，有问题。而且呢，这是写不完的，这种人工能发现，脚本不能发现的不可预知的问题，无穷尽，
自动化脚本里写不完。自动化测试只能死板地根据脚本开发人员的定义去有限地发现问题，而不能根据实际情况，判断无限的实际情况中到底是有问题还是没问题。
那么我的解决方案呢？
呵呵了， 把测试架构师换掉，给测试经理重新培训什么叫自动化测试。
毕竟，在错误的测试策略下，无法改进这个问题。我们300人的部门里几十个测试人员整天都不做测试在那边分析脚本上误报的问题，和更新过时的脚本，或者写一些新的浪费时间的脚本，这是部门的测试策略决定的。
假如测试策略由我来定，假如我是测试决策人，我请大家不要假装在干活，不要假装在做测试，不要去写一些试图代替人做测试的东西，始终坚持以人为本，测试的主体是人，也只能是人。
一直在依赖不可靠的测试脚本。
举一个例子吧,我们
问题有深度哇
页:
[1]
