談談軟體測試的開發化趨勢

現在招人， 不問幾個開發的問題， 都不好意思。 《Google軟體測試之道》裡說到：未來是軟體測試開發工程師（SET）的天下。 軟體測試的開發化似乎是一個不可避免的趨勢了。

再談軟體測試的目的

測試的目的， 還是發現需求， 開發過程中的問題， 避免流入到生產環境。 所以， 用什麼手段不重要， 達到上線的要求才是根本。

自動化測試真的有用嗎？

自動化測試不見得能直接發現bug， 那還要來幹啥？還有用嗎？

以前， 我們做了很多基於UI的自動化測試。 上頭給的解釋是1.增加上線的信心。 2.回歸測試節省時間。 撇開UI自動化的實現成本， 執行中我們確實沒發現什麼被測系統的bug(發現更多的是測試代碼的bug)。 由於測試資料準備， 網路， UI改變等等原因， 調試又花了不少功夫， 回頭想想， 根本沒有節省時間。 那麼， 自動化測試到底在哪些方面有用呢？我覺得， 最能突出反映自動化價值的， 就是性能測試。 因為， 手動完全做不了大併發或者長時間大容量的壓力， 使得性能測試完全無法替代。 其次， 做一些主流程的介面測試或者複雜專案部分方法的單元測試， 也是一個有比較高ROI的嘗試。 尤其是對於多系統的集成， 或關鍵代碼的覆蓋測試， 非常有價值。 有些黑盒測試很難構造的測試資料， 必須通過介面測試或者單元測試保障， 做到分支覆蓋或者語錄覆蓋。 最近測試談的都是分層測試， UI被放在了最頂端， 做得也最少。 這種理念似乎被廣為接受了， 說辭是UI變化太大， 不值得做。 但是， 至少從我經歷項目來看， UI的變化並沒有傳說得那麼誇張， 往往半年甚至一年才經歷一次大改版， 大部分後臺系統很少改動， 大家的精力還是放在增加新功能上。 所以， 個人覺得還是應該提高一些UI自動化的比例。 加上Web Driver的日漸成熟， 以及Page Object框架維護被測物件， 使得UI腳本可維護性也大大提升。 即使改版， 也只需要更新一些物件的id， name和xpath就可以運行， 不妨一試。 另外， 還有一部分自動化測試開發， 會研發一些平臺工具類的東西。 我個人以為， 這些是錦上添花的東西。 作為測試開發工程師， 儘量還是自己去寫代碼完成測試， 少依賴這些別人搭建的平臺。 否則， 等到丟開拐杖之後， 無法獨立行走， 那就慘了。 。 。

懂開發有啥用， 到底有啥用啊？測試懂開發， 最直觀的感受， 就是可以看懂代碼邏輯， 並且做code review。 一些不明白的東西也不用老是纏著人家問了， 自己看看反而比人家講得更清楚。 其次， 可以提升自己的編碼水準。 反正我學一個新的方法， 總是從抄開始的。 看不同人的代碼， 學到不同的實現方式， 也是一種樂趣。 再次， 擴展知識面， 有些未必對你寫介面測試有説明， 但是一些設計思想， 設計模式會對你有説明。 學一些前端知識， 資料庫緩存的使用， 也可以幫助你去開發測試工具， 測試平臺等。 瞭解打包和發部腳本， 也能幫助你維護好測試環境等。 甚至後期轉行做開發或者運維，

都是不錯的。

說了這麼多， 再用摘抄的文章， 提醒一下自己。 自動化測試知識手段， 不是目的。 學習開發知識雖然很重要， 但也不應本末倒置。 我們應該花更多時間理解業務的實質， 設計好測試策略！！！

測試策略是所有測試活動的靈魂和核心， 對於待測系統， 其價值類似於隆中對之于劉備， 農村包圍城市之於中國革命。 遺憾的是儘管有很多業內人士在不斷呐喊， 但對於測試策略的重視程度仍然遠遠不足。 測試策略需要很強的專業領域知識與測試經驗， 是測試工程師的重要價值所在。

http://www.jianshu.com/p/0cde18be00ed