光遇自动弹琴脚本代码_软件自动化测试浅析

软件测试(Software Testing)：
描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。
软件测试并不只是一个发现软件BUG的过程，通过找出错误，分析其产生的原因和错误的发生趋势，可以帮助项目管理者或开发人员发现当前软件开发过程中存在的缺陷，以便及时改进，节省成本。
这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。
在我看来，它其实是预期输出与实际输出的一个审核、对比、分析的过程。个人认为，分析显得十分重要，这不只是培养了我们的测试思维，并且让我们养成了良好的学习、生活习惯。
软件测试的方法很多，比如常见的黑白盒测试、冒烟测试、边界值测试等等。
在这里，我们只简单地将软件测试方法区分为手动测试与自动化测试两类，并着重介绍自动化测试。
手工测试：
手工测试就是由人去一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。
(手工测试同样需要业务熟悉、基本测试方法的理解。看似简单的工作却能够发现别人不能发现的软件问题。在目前的测试领域，手工测试仍然是无法替代的一种测试方法)
手动测试是由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果进行比较的过程。为了节省人力、时间或硬件资源，提高测试效率，便把以人为驱动的测试行为转化为机器执行，由此引入了自动化测试的概念。
自动化测试：界面自动化、接口自动化、性能自动化。
我们一般所说的自动化测试就是指功能自动化测试，通过相关的测试技术，通过编码的方式用一段程序来测试一个软件的功能，这样就可以重复执行程序来进行重复的测试。如果一个软件一小部分发生改变，我们只要修改一部分代码，就可以重复的对整个软件进行功能测试。这样就大大的提高了测试效率。
　　性能自动化测试，当然，除了早期阶段，现在的性能测试工作都是通过性能测试工具辅助完成的。通过工具可以模拟成千上万的用户向系统发送请求，用来验证系统的处理能力。
我们在这里主要介绍的还是功能测试。

测试策略的分层：金字塔模型
UI界面层(用户界面测试)：功能性验证测试、兼容性与用户测试
业务逻辑层(API层面)：客户端模拟测试、内外接口测试、SDK接口测试
数据处理层：单元测试
越是底层的测试，运行速度越快，时间开销越少，金钱开销越少
越是顶层的测试，运行速度越慢，时间开销越多，金钱开销越多
测试金字塔由敏捷开发专家Mike Cohn提出，是希望解决传统UI自动化测试中的一些雷区，比如：执行速度慢，稳定性差，受测试环境影响较大，测试框架复杂，开发及维护成本高等。
如图所示，单元测试相当于整个金字塔的基石，单元测试脚本执行速度快，在这个环节更容易发现并定位缺陷，使之不会影响上层测试，效率更高。
但是单元测试也存在：测试数据都是假的(全靠mock)，涉及的测试用例太多，很难完全覆盖，不是单靠测试团队能搞定等不足。(mock测试，简单举例：一个闹钟根据时间来进行提醒服务，如果过了下午5点钟就播放音频文件提醒大家下班了，如果我们要利用真实的对象来测试的话就只能苦苦等到下午五点。这时我们利用mock对象 来进行测试，模拟控制时间，不用苦苦等待)
集成测试可以很大程度上避免上面两种测试的问题，但测试数据依然是假的(call/stub(与mock类似))
而软件最终呈现给用户的是UI层，所以即便UI自动化问题很多，测试人员也无法放弃UI自动化测试。
在这座金字塔中三种测试的比例如何划分被称为分层自动化测试。
《google 测试之道》中介绍，对于google产品，70%的投入为单元测试，20%为集成及接口测试，10% 为UI层的自动化测试
备注问题：mock与call/stub 的区别是什么？
测试工程上的分层：代码重用
在自动化测试的工程中，测试脚本中的代码(关键字,keyword等，下同)一般包括3部分：
1、测试业务逻辑代码
2、支撑代码
3、测试数据
测试工程的分层，主要是解决以下问题：
1、当测试逻辑与一大堆支撑代码混在一起时，测试逻辑隐藏在支撑代码中，难以理解及修改。要添加新测试步骤/用例，通常需要重读这些支撑代码才能找到需要修改的代码，效率低。
2、业务逻辑间通常会有耦合关系，某个业务或模块功能的轻微变化，会影响到相关所有测试脚本都要修改。
3、维护开销大。一个测试工程会对系统的某个部分进行多组测试，每组测试间可能存在重复的代码。这些重复代码被不同工程师在不同的脚本中完成和维护，工程师能力的差异就会导致测试代码的质量参差不齐，稳定性差。
解决以上问题的方法是采用软件工程中重用的思想，针对支撑代码进行分层，比如分为高中低3层：
高层：公司级可重用代码,这些代码一般与具体业务无关，但工具本身并不提供，比如：特殊字符串处理，JSON处理，控件操作封装等；
中层：项目级可重用代码，这些代码在本项目各个模块中可以重用，一般是对各个模块主要功能或流程的封装，比如登陆功能，订单功能等。其他模块的自动化测试用例可以使用这些代码简单的解决脚本中模块间相互依赖的问题；
低层：模块级可重用代码，这些代码在某一个模块中可以重用。
自动化测试的应用场景：
1、任务明确，不会出现频繁的改动；
2、回归测试比