一、舉步維艱

1、敏捷轉型：測試眼中的研發

傳統：

• 需求是清晰的
• 流程是固化的
• 開發是有序的
• 系統是可測的
• 測試時間是充足的
• 使用者是講道理的

敏捷：

• 需求頻繁更改
• 交付問題多
• 測試時間緊
• 使用者抱怨多
• 開發延遲，壓縮測試時間，已成常態

那麼問題來了：

• 還能隨心所欲設計大量用例嗎？
• 還有大段的系統測試時間和整合測試時間嗎？
• 還能要求充足的迴歸測試嗎？
• 還能期望研發提供各種測試建議嗎？
• 還能不能愉快的進行了。。。

2、迴歸的痛苦

兩個場景：

場景一：

開發：剛修復了一個緊急使用者反饋，安排下測試吧。
測試：改了哪些？影響了哪些功能？
開發：改了好些地方，為了保險，把所有功能都測一遍吧。

場景二：

開發：昨天的修改測試完成了嗎？
測試：測試中，要跑500個用例呢？
開發：我只修改了一行程式碼，怎麼要測這麼多呢？

 兩種意見：

1）縮減迴歸測試的範圍--沒有好的方案

2）依靠自動化測試

3、自動化測試的價值

傳統：

傳統ROI（成本與收益）公式：自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本
很大的前提：測試做的越多越好
這個理解對全新的專案是正確的，對後續的迭代和增量版本合理嗎？迴歸測試中，因為“不放心”進行測試，冗餘比例很高，因此公式中的收益很大一部分來自於這裡。

自動化測試定義：

傳統：

通常指測試過程被自動化，即把手工測試的用例讓機器去做

廣義包括：

• 測試環境的搭建和管理
• 測試環境的檢查、監控和報警
• 測試程式碼的靜態檢查、編譯和構建
• 測試場景的構造，測試資料的自動化準備
• 測試用例的分發和執行
• 測試結果的儲存和管理
• 測試報告的生成
• 測試優先順序的建議

自動化測試型別：

• 單元測試
• 程式碼靜態檢查，檔案檢查，簽名校驗，證書檢查
• 介面自動化測試（本地native介面測試和服務service介面測試）
• UI自動化測試
• 效能測試（本地和服務）

可能的價值：

• 幫助迴歸，節省人力
• 構建人工測試無法構建的場景、資料準備，或執行一些人工測試做不到的測試用例，有效提升測試覆蓋率
• 前置測試，讓測試和開發可能並行，提升專案敏捷度，降低測試獨佔週期（提測到待發布的時長）

測試員路在何方：重要的不是我做了多少年，而是我的工作是否可被輕易取代

核心競爭在哪裡？

• 精通業務：最精通的不是產品，市場研究員嗎？
• 比其他崗位更懂業務技術：不應該建立在其他崗位的不足上
• 思想上：很多開發技術強的測試都轉開發了