自动化测试实例,自动化测试项目案例
如何使用UIAutomation进行iOS自动化测试
使用iOS模拟器
1. 下载示例应用程序TestAutomation.xcodeproj，并打开它。这个项目是一个很简单的包含2个tab的tabbar应用程序。
2. 确保选中如下图所示的“TestAutomation iPhone 5.0
Simulator”模式（或许已经切换成5.1了，因此它可能是iPhone5.1模拟器）。
3. 启动Instruments(Product Profile)，或者通过?I。
4. 选择左边的iOS Simulator，然后再选择Automation模板，然后点击“Profile”。
5. Instruments就已经启动好后，然后直接开始录制了。这里先停止录制，（红包按钮或者?R）。
6. 在左边的Scripts窗口，点击“Add Create”创建新的脚本。
7. 在脚本编辑器里，输入下面的代码
var target = UIATarget.localTarget();
var app = target.frontMostApp();
var window = app.mainWindow();
target.logElementTree();
8. 重新运行这段脚本?R（不需要保存）。脚本跑起来后，可以在日志打完后停止它。
赞一个！就这样完成了第一个UIAutomation测试用例。
使用iOS设备
除了将测试用例运行模拟器上，也可以将它运行在一个真实的设备上。不过，自动化测试用例只能运行在支持多任务的：iPhone 3GS，iPad，iOS
4.0等设备上。遗憾的是不管iPhone 3G的系统版本是什么，都不支持。
下面是如何操作：
1. 通过USB接口连接上iPhone。
2. 选择 “TestAutomation iOS Device”模式。
3. 确保Developper profile设置成Release模式（而不是Ad-Hoc Distribution
profile）。默认情况下，profiling是设置成Release模式的（因为没有必要将profile设置成Debug模式）。
4. 启动测试 (?I)
5. 后面的步骤请参考前面模拟器部分
自动化测试实例二：脚本开发(上)
完成测试用例后就可以开发测试脚本，一般包括自动化测试框架的开发和功能脚本的开发。在本节中不介绍如何开发自动化测试框架，有兴趣的读者可以参考《 QTP 自动化测试与框架模型设计 》一书中第 19 章和第 20 章的自动化测试框架的内容。本章介绍该实例中需要调用到的函数。
(1)公用函数封装。
在本实例中需要封装的函数主要包括： 读取测试用例、输入每个测试用例的测试结果。
通过获取单元格中数据的行数，可以确定测试用例文档中有多少条测试用例， 代码如下：
读取单元格中的数据，即获得测试用例值， 代码如下：
在该实例中还需要记录每个测试用例执行的结果， 封装的代码如下：
由于在本实例中需要连接数据库，检查数据库中的数据是否正确，所以将连接数据库的代码进行封装， 代码如下：
(2)单一模式脚本开发。
自动化测试脚本开发完成后，开始录制脚本，这个阶段主要是将自动化测试的需求转换为一个简单的脚本。
1)录制登录过程的脚本如下：
2)录制订票流程的脚本如下：
3)录制航班信息的脚本如下：
4)录制查询订票信息的脚本如下：
(3)脚本增强。
录制好的单一模式脚本的功能很弱，只完成了一个简单的功能，不具备可扩展性，无法兼容不同的测试数据，所以需要对上面的脚本进行增强。在录制单一模式的脚本时，其实有一个功能是通用的，就是登录功能，每个操作的功能都需要先登录系统，所以可将一个正确登录的脚本封装成一个过程，这样可以节约脚本量，也便于维护脚本。在封装登录过程时，需要使用到描述性编程， 封装的代码如下：
接着对登录的脚本进行增强操作，增强的原因是脚本需要能正确处理当输入用户名或密码出错的情况。 主要需要处理的情况有： 输入的用户名为空、输入的用户名少于 4 个字符、输入的密码为空、输入的密码少于 4 个字符。 登录功能增强后的脚本如下：
订票流程脚本的增强主要需要处理订票日期未输入和输入错误的情况， 订票流程功能增强后的脚本如下：
航班信息查询脚本的增强主要是需要检查当选择出发城市和到达城市后，显示出来的航班信息是否正确，脚本增强时需要获取所有航班信息。 增强后的脚本如下：
查询订票信息脚本增强主要是需要检查该航班号是否存在，如果航班号不存在，会弹出相应的对应信息;如果查询的订单号存在，就会显示出该订单的相关信息。 增强后的脚本如下：
Robotframe work之web自动化测试小例子
????????原来一直是做Python+selenium的web自动化测试的，最近换了一家新公司，需要做app自动化测试，所以appium如何使用都得现学。框架也不是用的原来的，现在公司再用Robotframe work在做，一切都是从头开始。自己也开始记录一下学习的过程，学习遇到不懂的也都会在网上搜索，但有时候很痛苦，搜索的很费事。所以自己也就想起来将从头开始学的一些东西都记录一下。
? ??????Robotframe work的环境搭建网上都有很多，这里就不一一说明了，直接上干货，一个小小的例子。
? ??????
上图是测试51自学网，过程是这样的，sleep就不说了。
1.使用chrome浏览器打开51自学网的浏览器
2.然后鼠标悬浮在程序开发的菜单上，mouse over鼠标悬停+xpath定位
3.然后点击appium自动化测试教程子菜单， click element+xpath定位，若点击按钮，则用click button
4.然后进行断言验证，得到跳转页的title， get text方法获取文本，然后赋值给变量
5.进行断言，should match方法
6.输出测试完成，log方法
7.关闭浏览器
运行完成后，显示如下页面：
robotframerwork的关键字与selenium有很大差别，有时候不知道找什么关键字，那么可以按F5，在search keyword中搜索你要做的操作，比如打开浏览器，可以输入open，出现如下图：
今天就写到这里，以后我慢慢在更新，一起努力学习
手工测试和自动化测试如何进行有效的结合，试举出适当的例子阐述
手工测试和自动化测试的有效结合：
自动化脚本首先在重复执行操作和固定流程操作方面占优，而有经验的测试人员在灵光乍现的时候发现的一些稀奇古怪但是却影响很大的bug，是无法用自动化脚本来发现的。最好的方案是自动化测试与人工测试结合，自动化脚本来干脏活累活，测试人员来做有创造性的充满乐趣的测试工作。
举例论证：
在一个实时的项目监控的系统中，客户通过手机或固定电话拨号完成数据的输入，当接收到的号码一旦与已知设定不符合的时候，触发报警系统，在打印该输入号码同时还要将它转存到磁带上。
测试分析：在该项目中，需要对客户号码、报警器、还有输出设备（打印机和磁带机）这三个方面进行测试。
对于电话号码而言可能有好多的形式，但是无论如何，它们的值一定是数字组成的，对接收方来说，只有两种情况，收到了合法的数据和收到和非法的数据。所以它适合使用程序来模拟输入数据和根据输入判断预期的输出结果。可以使用自动化的方式来实现。
对报警器而言，它只有两种状态报警或不报警。所以同样可以用合法的数据来触发报警和使用非法数据来测试来判断其是不是不报警。所以同样可以实现自动化。
再看第三个测试对象，输出设备的测试，对于这种物理设备的测试只能使用手工测试。
手工测试特点：?
1、测试人员要负责大量文档、报表的制订和整理工作，会变得力不从心。
2、受软件分发日期、开发成本及人员、资源等诸多方面因素的限制，难以进行全面的测试。
3、如果修正缺陷所需时间稍长，那么想将手工测试应用于回归测试将变得异常困难。这是因为需要测试的测试用例太多。
4、对测试过程中发现的大量缺陷缺乏科学、有效的管理手段，责任变得含混不清，没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率。这样往往会导致最后的汇总报表数据不准确。
5、反复测试带来的倦怠情绪及其它人为因素使得测试标准前后不一，测试花费的时间越长，测试的严格性也就越低。
6、难以对不可视对象或对象的不可视属性进行测试。
自动化测试的特点：
1、可以运行更多更频繁的测试。
2、可以执行一些手工测试困难或者不可能做的测试。如对不可视对象的测试，利用面向对象的自动化测试脚本就很容易实现。
3、可以更好地利用资源。在夜间执行自动测试。
4、测试具有移植性和可重复性。好的测试脚本往往具有较好的平台移植性。
5、可以更快地将软件推向市场。因为自动测试节省了大量的时间。? 但是自动化测试要求的前期投入比较大，而且要求人员必须经过严格的培训。
扩展资料：
手工测试和自动化测试各自适用的场合如下：
1、测试很少执行的项目中。当测试用例执行频度太小时（一年一次），我们可以直接使用手工测试就可以了。
2、软件运行仍然不稳定时，适合使用手工测试。
3、测试结果很容易通过人验证的测试项目适合手工测试。
4、测试项目中涉及物理交互比较多的时候适合手工测试。如需要经常查看打印机，绘图仪的输出时。
5、软件维护时使用的回归测试适合自动化测试。
6、执行压力测试时适合自动化测试。例如测试服务器的最大访问上限等。
7、配置和兼容性测试等项目适合自动化测试。
参考资料来源：百度百科-手工测试
? ? ? ? ? ? ? ? ? ??百度百科-自动化测试