一、举步维艰
1、敏捷转型：测试眼中的研发
传统：
- 需求是清晰的
- 流程是固化的
- 开发是有序的
- 系统是可测的
- 测试时间是充足的
- 用户是讲道理的
敏捷：
- 需求频繁更改
- 交付问题多
- 测试时间紧
- 用户抱怨多
- 开发延迟，压缩测试时间，已成常态
那么问题来了：
- 还能随心所欲设计大量用例吗？
- 还有大段的系统测试时间和集成测试时间吗？
- 还能要求充足的回归测试吗？
- 还能期望研发提供各种测试建议吗？
- 还能不能愉快的进行了。。。
2、回归的痛苦
两个场景：
场景一：
开发：刚修复了一个紧急用户反馈，安排下测试吧。
测试：改了哪些？影响了哪些功能？
开发：改了好些地方，为了保险，把所有功能都测一遍吧。
场景二：
开发：昨天的修改测试完成了吗？
测试：测试中，要跑500个用例呢？
开发：我只修改了一行代码，怎么要测这么多呢？
两种意见：
1）缩减回归测试的范围
2）依靠自动化测试
3、自动化测试的价值
传统：
传统ROI（成本与收益）公式：自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
很大的前提：测试做的越多越好
这个理解对全新的项目是正确的，对后续的迭代和增量版本合理吗？回归测试中，因为“不放心”进行测试，冗余比例很高，因此公式中的收益很大一部分来自于这里。
自动化测试定义：
传统：
通常指测试过程被自动化，即把手工测试的用例让机器去做
广义包括：
- 测试环境的搭建和管理
- 测试环境的检查、监控和报警
- 测试代码的静态检查、编译和构建
- 测试场景的构造，测试数据的自动化准备
- 测试用例的分发和执行
- 测试结果的保存和管理
- 测试报告的生成
- 测试优先级的建议
自动化测试类型：
- 单元测试
- 代码静态检查，文件检查，签名校验，证书检查
- 接口自动化测试（本地native接口测试和服务service接口测试）
- UI自动化测试
- 性能测试（本地和服务）
可能的价值：
- 帮助回归，节省人力
- 构建人工测试无法构建的场景、数据准备，或执行一些人工测试做不到的测试用例，有效提升测试覆盖率
- 前置测试，让测试和开发可能并行，提升项目敏捷度，降低测试独占周期（提测到待发布的时长）
测试员路在何方：重要的不是我做了多少年，而是我的工作是否可被轻易取代
核心竞争在哪里？
- 精通业务：最精通的不是产品，市场研究员吗？
- 比其他岗位更懂业务技术：不应该建立在其他岗位的不足上
- 思想上：很多开发技术强的测试都转开发了