1. 软件测试的六大模块
1.1 功能性测试
示例：
- ATM机上取钱上不扣款
- 输入不正确的日期格式也可以成功提交
- WEB页面的一个超链接打不开
- 手机上正在听音乐时来电不提示
- 地铁公交卡刷卡后扣款不成功
- 手机APP无法正常启动
- 手机拨号后无法接通对方手机
- 2012年广州出租车计价器无法识别2月29日
1.2 可用性测试
示例：
- 手机上应用程序运行太慢
- 删除一条数据时无二次确认
- 页面布局很难看
- 页面字体颜色太刺眼，字体太小
- 网站经常出现弹窗广告
- 手机上按钮设置在左上角
- 网页上的超链接显示不明显
- 苹果早期手机一直坚持屏幕小于4英寸
1.3 性能测试
示例：
- 网页半天打不开，反应很慢
- 应用程序运行太久占用内存很大
- 2008年北京奥运会门票系统崩溃
- 2012年伦敦奥运会门票系统崩溃
- 12306网站春运期间购票难
- Android手机运行不流畅
1.4 安全性测试
示例：
- 我们经常接到骚扰电话
- WIFI万能钥匙
- 某支付宝账户的余额被恶意转走
- CSDN网站用户600万数据泄漏
- 手机上的联系人信息被窃取
- 某网站首页被恶意篡改
- 某网站被大量非法用户攻击
1.5 兼容性测试
示例：
- 中国的插座无法在欧美使用
- 某网页IE和Firefox中显示效果不一样
- 某App应用程序在某手机上无法安装
- 针对手机，平板和电脑要单独开发三套界面
- 在IE中可使用回车键，但是在Firefox上无法使用
- 某游戏无法运行在IOS系统上
- 某应用程序在Windows 10上经常卡
1.6 可靠性测试
示例：
- 手机使用时间太长容易死机
- Android，IOS上的闪退
- Windows上的蓝屏
- 手机通话时失去信号后无法马上挂断
- 手机恢复信号后通话无法继续
- QQ文件传输不支持断点续传
- 阿里巴巴杭州电缆被挖断时无法立即恢复
2. 自动化测试的价值
2.1 自动化测试的优势
- 提高测试执行效率，节约时间成本
- 解放人力去做更加重要的工作
- 可重复利用，减少对人的依赖
- 提升客户满意度
- 提升软件测试团队整体水平
- 可大幅减少兼容性测试的工作量
- 有些测试工作必须依靠自动化来完成
2.2 自动化测试的不足
- 开发自动化测试脚本需要花费较长周期
- 随着产品的不断迭代，自动化测试脚本也将不断迭代，时间成本高
- 不同的项目之间自动化测试脚本的重用度低
- 对短期项目型产品实施自动化测试价值不高
- 自动化测试无法代替手工测试找到产品的BUG
- 自动化测试更多适用于回归测试
- 自动化测试开发过程对软件测试团队的技术有较高要求
2.3 手工测试 VS 自动化测试
| 比较 | |||
|---|---|---|---|
| 寻找产品缺陷 | 手工测试 | 优于 | 自动化测试 |
| 纯技术性要求 | 手工测试 | 低于 | 自动化测试 |
| 产品的稳定性要求 | 手工测试 | 低于 | 自动化测试 |
| 测试用例的高效性 | 手工测试 | 优于 | 自动化测试 |
| 对测试人才的需求 | 手工测试 | 同于 | 自动化测试 |
| 相互之间的可替代性 | 手工测试 | 同于 | 自动化测试 |
| 对测试项目的价值 | 手工测试 | 同于 | 自动化测试 |
特别提醒：测试的核心 价值在于测试的分析与设计；手工，自动只是执行手段。
3. 自动化测试能力要求
3.1 对软件测试的能力要求
- 掌握软件测试的流程和方法
- 掌握软件测试用例设计思路
- 有1年以上的软件测试项目经验
3.2 对程序设计的能力要求
- 有Java程序设计基础或相关经验
- 有Python等脚本语言基础经验
- 有数据库和SQL语句使用经验
- 对软件系统三层结构及协议有所理解
3.3 对软件架构的能力要求
- 理解软件系统前端和后端交互过程
- 理解操作系统（手机和电脑）基本原理
- 对软件系统三层结构及协议有所理解
- 理解项目的核心技术架构
- 理解对被测试产品的需求和业务逻辑
4. 自动化测试可行性
4.1 产品架构与业务可行性
- 单机应用程序，重点考虑界面级自动化测试
- 分布式应用系统，重点考虑接口级与界面级结合的自动化测试
- 手机APP应用，重点考虑接口级与界面级自动化测试，并重点关注兼容性
- 复杂业务场景，重点考虑接口级或代码级自动化测试，界面级测试可不作重 点关注。且摘取使用频率最高的模块进行测试
- 简单业务场景，可考虑不进行或只进行界面级自动化测试
4.2 测试技术实现可行性
- 自动化测试可应用于代码级，接口级，协议级和界面级
- 不同的被测产品应根据不同的情况进行有针对性的技术选择
- 自动化测试技术并不难理解，重点是测试方案的制定
- 通用优先技术选择顺序：接口级 > 协议级 > 界面级 > 代码级
- 自动化测试工具选择面太广，却没有一款工具可以完全满足企业要求，所以对自动化测试技术底层实现原理的理解和应用应该优先于对工具的考察和选型
- 自动化测试实施是一个长期完善的过程，并不是一锤子买卖
4.3 团队成员能力可行性
- 测试过程分为：分析，设计，实现，执行，而很多测试团队关注在实现和执行层面，而忽略测试最本质的环节：分析，设计
- 自动化测试仅属于测试的执行环节，所以并非懂自动化测试技术或工具就可以成功实施自动化测试
- 团队成员具备的能力：对产品业务的理解，对产品架构的理解，对被测模块功能的理解，对用户使用场景的理解，对软件开发及程序设计的理解，具备程序设计能力，有专人负责自动化测试
- 建设好测试团队和软件研发管理，远比实施自动化测试重要
4.4 自动化测试实施可行性
- 自动化测试方案应该与产品的架构设计工作一起，在研发早期进行统一规划，确保自动化测试的可实施性，减少为测试而重构代码
- 自动化测试更多用于回归测试或兼容性测试，不能以寻找BUG为目的
- 自动化测试属于的执行阶段，测试工作应该重点关注分析与设计
- 经验表明，80%的企业自动化测试实施工作无法坚持，效果并不理想
- 自动化测试是为软件质量服务的，并非用于自我满足或邀功
- 软件研发永远以人为本，寄希望于通过各种工具和技术解决问题的想法是不切实际的，而人永远会犯错误，预防比修补更重要
- 学会放下，大智慧也！
5. 自动化测试常用工具
5.1 代码级自动化常用测试工具
- XUnit: JUnit, CppUnit, GoogleTest, NUnit, PyUnit……
- XMock: JMock, GoogleMock, NMock……
Coverage: PureCoverage, Purify, EclEmma, DevPartner……
功能：
断言，参数化，测试用例管理，快速Mock，TDD
5.2 协议级自动化常用测试工具
- LoadRunner：支持全协议，重点支持HTTP等
- SoapUI：支持WebService协议SOAP
- WebLoad：支持HTTP协议
- RPT：重点支持HTTP和TCP/UDP协议
- SilkPerformance：重点支持HTTP和TCP/UDP协议
- HTTPClient，JSoup：HTTP协议和HTML元素处理
- JMeter：支持HTTP，JMS协议等
5.3 界面级自动化常用测试工具
- QTP/UFT：支持Windows，Web，Java，.NET应用程序等
- RFT：支持Windows，Web，Java，.NET应用程序等
- TestComplete：支持各类应用程序及第三方组件，对象识别能力超强
- Selenium/Watir：支持Web应用，Safar，IE，Chrome，Firefox
- Sikuli IDE：基于图像识别的自动化测试工具，支持所有应用
- Appium/MonkeyRunner：Android，iOS移动应用