软件测试六大模块:
- 功能测试(Functionality Testing): 是否满足了客户的需求
- 可靠性测试(Reliability)：是否能够一直在一个稳定的状态上满足可用性
- 易用性（Usability）：衡量用户使用软件要付出多大努力的质量属性
- 效率（Efficiency)：衡量软件正常运行要耗费多少时间和物理资源，是性能测试的重点内容
- 可维护性（maintainability):衡量对已完成的软件进行调整需要多大努力
- 可移植性（Portability) : 能否方便的部署到不同的环境中
自动化测试的价值
1. 自动化测试的优势
提高测试执行效率，节约时间成本
解放人力去做更加重要的工作
可重复利用，减少对人的依赖
提升客户满意度
提升软件测试团队整体水平
可大幅减少兼容性测试的工作量
有些测试工作必须依靠自动化来完成
2. 自动化测试的不足
开发自动化测试脚本需要花费较长周期
随着产品的不断迭代，自动化测试脚本也将不断迭代，时间成本高
不同的项目之间自动化测试脚本重用性低
对短期项目型产品实施自动化测试价值不高
自动化测试无法代替手工测试找到产品的bug
3. 手动测试VS自动化测试
寻找产品缺陷： 手工测试 优于 自动化测试
纯技术性要求： 自动化测试 高于 手工测试
产品的稳定性要求： 手工测试 低于 自动化测试
测试用例的高效性： 手工测试 优于 自动化测试
对测试人才的需求 手工测试 同于 自动话测试（高手难求）
相互之间的可替代性：手工测试 同于 自动化测试 (互相不可替代）
对测试项目的价值 手工测试 同于 自动化测试 （均非核心价值）
PS: 测试的核心价值在于测试的分析与设计；手工、自动只是执行手段
4. 自动化测试常用工具
1) 代码级自动化常用工具
XUnit：JUnit, CppUnit, GoogleTest, NUnit, PyUnit
XMock: JMock, GoogleMock, NMock... (仅能适用于纯粹的面向对象的语言，使用多态来实现细节的模拟）
Coverage: PureCoverage, Purify, EclEmma, DevParter, Threading Testing ...
FindBugs
功能：
断言，参数化，测试用例管理，快速Mock, TDD
PS: 代码级自动化测试框架并不能为自动化测试实施带来多大实质性价值，而更多是对研发人员的一种意识的灌输
2) 接口/协议级自动化常用测试工具
LoadRunner: 支持安全协议，重点支持HTTP等 (性能，协议，安全性测试）
SoapUI: 支持WebService协议SOAP
WebLoad: 支持HTTP协议
接口目前没有很成熟的工具，因为接口是不规范的，接口（暴露出来的方法）每家都不一样
3). 界面级自动化常用测试工具
QTP/UFT: 支持Windows, Web, Java
RFT:
TestComplete
Selenium/Watir: 支持Web应用，Safar, IE, Chrome, Firefox
Sikuli IDE：基于图像识别的自动化测试工具，支持所有应用
Appiump/MonkeyRunner：Android, ISO移动应用
思考： 界面元素无法识别时如何解决
如基于图形识别(Sikuli IDE）
基于鼠标/键盘操作
5. 自动化测试可行性分析：
1) 产品架构与业务可行性
单机应用程序：界面级
分布式应用系统：接口与界面结合
手机app应用：接口，界面，重点关注兼容性
复杂业务场景：接口，代码，界面可不关注。且摘取使用频率最高的模块进行测试
简单业务场景：可不进行或只进行界面级自动化测试
2) 测试技术实现可行性
自动化技术并不难理解，重点是测试方案的制定
通用优先技术选择顺序：接口级>协议级>界面级>代码级
对自动化测试技术底层实现原理的理解和应用应优先于对工具的考察和选型
3) 团队成员能力可行性
测试过程分为： 分析、设计、实现、执行
测试最本质的环节：分析、设计
自动化测试仅属于测试的执行环节，所以并非懂自动化测试技术或工具就可以成功实施自动化测试
建设好测试团队和软件研发管理，远比实施自动化测试重要
4) 自动化测试实施可行性
自动化测试方案应与产品的架构和设计工作一起，在研发早期进行统一规划，确保自动化测试的可实施性，减少为测试而重构代码
自动化测试更多用于回归测试或兼容性测试，稳定性测试，不能以寻找bug为目的
自动化属于执行阶段，测试工作应重点关注分析与设计
自动化测试是为软件质量服务的，并非用于自我满足或邀功
5. 自动化测试原理
1.基于代码的自动化测试（Code-Based)
1）白盒测试VS灰盒测试
白盒测试深入被测代码的逻辑细节
白盒测试关注代码覆盖率和运行路径
(Stub，Mock)实现代码隔离
白盒测试通过测试驱动（Test fixture)执行测试用例
灰盒测试关注接口与参数，不关注代码实现
灰盒测试适用黑盒测试用例设计方法
灰盒测试只关注测试驱动程序开发，不关注测试桩
2）白盒测试基本流程
定义期望结果
- 运行被测对象
- 对比期望结果与实际结果
- 得出测试结果
- 迭代运行，保证测试质量
3）白盒测试驱动程序开发
4）测试驱动开发TDD介绍
先开发测试代码，实现被测代码，一旦所有测试代码都pass了之后，被测代码开发结束
step1: 规划接口规范（接口名称及参数）
step2: 开发测试驱动程序
step3: 运行测试驱动程序
step4: 查看测试结果（成功或失败）
2. 基于界面的自动化测试（GUI-Based)
不同于代码级自动化，界面级更符合黑盒测试习惯
利用代码或工具模拟鼠标和键盘操作
界面级自动化测试的核心是：对象识别和操作
所有的测试原理和方法均适用于界面级自动化
3. 基于协议的自动化测试（Protocol-Based)
对于典型的分布式三层架构应用系统来说：
代码级自动化更多用于服务端
界面级自动化更多用于客户端
在客户端与服务器端之间的数据传输，基于协议的测试便会发挥作用
基于协议的自动化测试可以弥补代码级和界面级的不足
基于协议的自动化测试更易于进行可靠性，安全性，性能等的测试
6.三类自动化测试技术的优劣
界面：
优点：测试工具多，有成熟解决方案，易于学习使用，短期效果明显
缺点：
依赖界面，容易出现无法识别和操作界面上的元素从而让该技术失败。维护成本高
适用于产品稳定后的自动化，不以找bug为目的，主要用于验收测试和兼容性测试
代码：
优点：易于实施和控制，更容易快速看到效果，结合TDD将代码质量提升一个质量级
缺点：
要求较强的编码能力和对被测代码的理解，同时需要流程和团队的配合
大量的测试驱动和测试桩程序将让研发团队望而却步
解决方案：多从灰盒测试角度来实施（基于接口测试）而非纯白盒测试角度（基于代码逻辑）
协议：
优点：适用于进行功能，性能，安全性，可靠性，可用性等测试类型
介于白盒与黑盒测试之间，非常适合于黑白盒测试进行补充和增强
缺点：
必须非常熟悉协议规则，特别是开放式的自定义协议规则或加密协议
解决方案： 根据测试类型和测试目的来决定是否选用此技术，定能找到解决方案
Android自动化测试及其框架简介
Android各种UI测试框架介绍
1. MonkeyRunner
编写语言：Python
运行环境：Python环境，adb连接PC运行
测试对象：UI测试
测试限制：主要使用坐标，逻辑判断较差
2. Instrumentation
编写语言：java
运行环境：adb命令启动或手机中直接启动测试
测试限制：单个activity测试，需要与测试应用相同的签名
测试对象：主要用于白盒测试和UI测试
3.Robotium
编写语言：java基于Instrumentation的封装
运行环境：与instrumentation相同
测试限制：与instrumentation相同
测试对象：
4.UIAutomator
Google在Android 4.1推出UIAutomator测试框架
主要用于UI自动化测试
功能：模拟人对手机进行操作，模拟各种动作如点击、长按、滑动、按键等操作
优点：
编写快速
运行简单
API简单易学
无activity限制
无需签名
几乎可以模拟所有的人为操作
缺点：
对权限控制不足
无法像Instrumentation一样高权限操作应用
很多Android API无法利用
为什么选择UiAutomator
1). 编写灵活，使用方便
2). 可快速学习
3)限制少， 无activity/Root/签名 的限制
4). 模拟目前90%以上的手工操作
5) 扩展性好
6) 可调用很大一部分Android API
