一、舉步維艱
1、敏捷轉型：測試眼中的研發
傳統：
- 需求是清晰的
- 流程是固化的
- 開發是有序的
- 系統是可測的
- 測試時間是充足的
- 用戶是講道理的
敏捷：
- 需求頻繁更改
- 交付問題多
- 測試時間緊
- 用戶抱怨多
- 開發延遲，壓縮測試時間，已成常態
那么問題來了：
- 還能隨心所欲設計大量用例嗎？
- 還有大段的系統測試時間和集成測試時間嗎？
- 還能要求充足的回歸測試嗎？
- 還能期望研發提供各種測試建議嗎？
- 還能不能愉快的進行了。。。
2、回歸的痛苦
兩個場景：
場景一：
開發：剛修復了一個緊急用戶反饋，安排下測試吧。
測試：改了哪些？影響了哪些功能？
開發：改了好些地方，為了保險，把所有功能都測一遍吧。
場景二：
開發：昨天的修改測試完成了嗎？
測試：測試中，要跑500個用例呢？
開發：我只修改了一行代碼，怎么要測這么多呢？
兩種意見：
1）縮減回歸測試的范圍
2）依靠自動化測試
3、自動化測試的價值
傳統：
傳統ROI（成本與收益）公式：自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本
很大的前提：測試做的越多越好
這個理解對全新的項目是正確的，對后續的迭代和增量版本合理嗎？回歸測試中，因為“不放心”進行測試，冗余比例很高，因此公式中的收益很大一部分來自於這里。
自動化測試定義：
傳統：
通常指測試過程被自動化，即把手工測試的用例讓機器去做
廣義包括：
- 測試環境的搭建和管理
- 測試環境的檢查、監控和報警
- 測試代碼的靜態檢查、編譯和構建
- 測試場景的構造，測試數據的自動化准備
- 測試用例的分發和執行
- 測試結果的保存和管理
- 測試報告的生成
- 測試優先級的建議
自動化測試類型：
- 單元測試
- 代碼靜態檢查，文件檢查，簽名校驗，證書檢查
- 接口自動化測試（本地native接口測試和服務service接口測試）
- UI自動化測試
- 性能測試（本地和服務）
可能的價值：
- 幫助回歸，節省人力
- 構建人工測試無法構建的場景、數據准備，或執行一些人工測試做不到的測試用例，有效提升測試覆蓋率
- 前置測試，讓測試和開發可能並行，提升項目敏捷度，降低測試獨占周期（提測到待發布的時長）
測試員路在何方：重要的不是我做了多少年，而是我的工作是否可被輕易取代
核心競爭在哪里？
- 精通業務：最精通的不是產品，市場研究員嗎？
- 比其他崗位更懂業務技術：不應該建立在其他崗位的不足上
- 思想上：很多開發技術強的測試都轉開發了