4、Drive quality upstream
我們都知道bug越是滯后發現，修復的成本越高。據微軟統計，如果產品發布以后需要發布一個熱修復，它的直接成本是150萬美元（間接成本在200萬美元），而在發布之前的一個月發現的話，修復成本是5萬，設計階段修復成本是1千，需求階段修復成本是1百。在需求分析階段，測試人員主要職責就是驗證需求分析的可行性和可靠性。PM和DEV的共性是易于樂觀，傾向于把實際情況簡單化，所以會作出很多假設。比如用戶肯定不會這么使用，用戶肯定知道如何用，所有用戶的環境肯定都有該配置。但是實際情況下總會有用戶不知道如何用，總會有用戶會不按“預先設計”的方式使用，總會有用戶環境沒有該項配置。所以測試人員的主要職責就是找出這些假設并提出疑問并加以驗證。
在dev設計階段，測試人員需要驗證設計，同樣找出dev的假設然后疑問這些假設是否合理，看看該設計是否處理很多沒有預料的但是有可能會發生的情況，比如用戶輸入特殊字符，非常規操作，非常規流程，機器重啟，死機，數據庫連接中斷，網絡中斷，內存耗盡等等。除了驗證設計是否處理非正常情況外，測試人員的另外一個更為重要的職責是驗證設計的可測試性。可測試性是指測試軟件容易的程度。軟件的可測性對于提高軟件的質量至關重要。道理很簡單，如果你的軟件很難測試，無從下手，測試一個用例需要幾個小時甚至幾天的話，你的軟件質量也就無從保證。提高軟件可測試性通常的做法是把軟件模塊化，松耦合，模塊內部運行狀態可見，模塊內部運行分支可控制。在評審一個設計時通常問的問題是該如何測試該模塊，是否容易測試它，能不能單獨測試它。如果不可以的話，需要重新考慮設計。因為一個設計的很容易測試的模塊和產品可以使得后期的測試代價大大降低。微軟大部分復雜系統都會有一個“one-box”版本，該版本是個假的模擬系統但是擁有真正系統的幾乎所有功能，它可以運行在任何機器上。系統的絕大部分功能都可以在該模擬系統上快速方便驗證。我在培訓的時候很多學生問？？他們在后期測試的時候遇到許多無法測試或者很難測試的困境，問我該如何解決。在具體了解困難和困境之后，我發現他們的測試策略非常單調，只能把產品部署到有限的測試環境下從用戶界面上做端到端的測試。如果想測試某個特定模塊或功能需要好幾個其它模塊配合起來才可以。我就坦率的說如果你的軟件是這么架構設計的話而且已經到了這一步，世界上沒有人可以解決你現在面臨的困難。因為看起來好像你是卡在現在這一步了，但實際上根本問題是在前期，在需求或設計。就像解決河流的水質污染問題，你在下游無論多大的代價也只能稍微改善，解決問題的根本方法是在解決上游的污染源。或者像隔靴撓癢，隔著厚厚的靴子無法撓到關鍵地方，必須能夠把靴子脫掉直接撓。
5、Getting better every day
軟件測試的目的一個是找出bug，另外一個是衡量軟件的質量。通過測試來了解產品哪些地方薄弱，哪些地方不穩定. 通過監控測試的結果，包括功能測試，性能壓力測試，安全測試，本地化測試，容錯測試等等來反映當前軟件的質量。這也是持續集成的一個重要原因，它一方面短期迭代，另一方面可以在最短的時間內知道軟件的質量，同時跟蹤軟件質量重開始到發布，軟件質量的變化曲線。衡量軟件質量的通常指標有：測試用例通過率/趨勢，bug數量，種類/趨勢，代碼覆蓋率等等。另外測試在開發周期中通常做的其它工作還有：bug root cause analysis，Bug analysis，Testcase failure analysis， test gap analysis，Bug talk，bug share，CCS data analysis等等。這一方面促使產品質量逐漸變好，而且是看得見的好。另外也促使自己放下繁忙的工作靜心思考一下，如何更有效率更進一步提高質量。
6、Engineering agility
隨著軟件即服務和云計算的興起，它們給開發管理，質量管理，運營管理等提出了很多新的挑戰。以前那種保密開發測試2－3年再突然發布的策略無法適應互聯網應用服務的要求，而是逐漸演變成快速開發出產品基本原型，然后就發布，根據用戶反饋不斷加以改進的方式。質量管理方面，基于服務的產品除了關注功能性能，還有其它特別重要的方面，比如scalability， high availability， fault tolerance， disaster recovery， etc.. 這些都是桌面型產品所沒有的或不重視的。微軟從2010年開始在很多組開始實踐如何提高服務型產品的質量，比如Azure， Bing， etc…。其中最為根本的一點就是提高整個團隊的敏捷度，團隊能夠跟的上快速迭代交付的節奏。這需要從產品設計上到測試自動化，工具，基礎設施上得以保障。另外一個非常重要的實踐就是TiP （test in production） 或 crowd-sourced testing. 我們在前面談到“drive quality upstream”，也即是提前測試。test in production正好相反是“drive quality downstream”，也即是在產品環境中測試。傳統的桌面產品發布之后就不再測試了。服務型產品，產品發布后繼續測試。它的基本出發點是：無論投資多少建立測試環境用以模擬產品運行環境，測試環境和真正產品環境總會有不同。無論花費多大的代價做前期測試，都不可能找出所有的bug。所以無論在發布之前花費多大的代價做測試，在產品上線后總會發現新的bug。現在既然發布產品更新非常快和容易，為什么不干脆在真正產品環境中來測試，或者利用真正的用戶使用真正的產品來測試（當然用戶意識不到）。一旦發現bug，馬上修復，馬上更新。這不僅減輕了前期測試的投入，而且提高的測試效率。看看我們在測試環境中發現的bug有多少沒有被認為是“真正”的bug就明白了。當然要做到test in production， 需要很多具體的流程、技術，工具作為保障。不能影響用戶的關鍵業務，不能讓用戶發現過于簡單的bug。 除了基本的測試自動化基礎設施和測試用例外，常用的一些TiP技術有：A/B testing，expose control/slicing model，on/off features，chaos-monkey，measuring/monitoring.
最后一篇將和大家討論一下測試工程師的技能提高和職業發展，to be continued .....
相關鏈接：