軟件質量控制實踐 - Microsoft 篇（2）
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, Test case 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.
7. invest on test engineer’s career
無論產品使用何種方式保障質量，人總是最核心最關鍵的因素。提高軟件質量有無數種方式和無數個因素，如果非要說一個最最重要的方式，那就是激發測試工程師的工作熱情。You can only achieve average by working hard, but passion is the one driving to excellence. 為了最大化激發測試工程師的潛能，微軟為測試工程師設計一整套完善的職業發展計劃。測試工程師主要有兩個職業發展路線。一個是 Individual Contributor (IC): 不管人，管技術。另外一個是 Manager: 偏重于管人和項目。這兩個路線沒有好壞之分，因人而異。兩個路線都是以技術能力為核心，也是加薪升職的最主要考慮因素。經理未必比個人掙錢更多，“Become a manager is not a promotion”。You are paid for what you cover。”what you cover”就像長方形的面積，面積大小有長和寬同時決定。VP 管的很多（長），但是深度有限（寬）。而技術大牛管的很少（長），但是很深（寬），所以兩個長方形的面積大小差不多。這也就是為什么有些技術大牛一個人不管但是掙錢和 VP 一樣多。下面是幾個測試工程師常見的職位：
SDET － 初級測試工程師 ，要求是：executor，如果有個問題需要解決，而且告訴你如何解決，你能夠很好地把問題解決了。
SDET 2 － 中級測試工程師 ，要求是：designer，如果有個問題需要解決，你自己找出辦法去解決。
Senior SDET － 資深測試工程師，要求是：planner，你自己去發現問題，然后找出解決辦法。
Principal SDET － 首席測試工程師， 要求是：thinker，能發現問題并且發現問題的共性，不僅解決問題而且避免問題出現。
對經理的要求也大致如此，除了技術上也要過硬外，還要求經理為手下的人盡可能創造機會以幫助他們成功。
另外微軟鼓勵測試工程師創造性思維，鼓勵員工創建好的測試工具用來提高測試效率，好的想法也可以可以申請測試專利或發表論文，并且被邀請到國際性測試會議上做演講。微軟內部有一個測試工具庫，有將近 1 萬個測試工具。本人就有一個測試，具在微軟內部 50 多個產品組廣泛使用，我也多次做演講，現在正 open source。
最后，我總結的測試工程師必須具備的硬技術能力：
1、至少一門編程語言，比如 C++/C#/Java，最好也了解設計模式的基本概念，比如：open-close principle, design to interfaces, favor aggregation over inheritance, encapsulate
by policy and reveal by need, etc…
2、至少一個腳本語言， 比如 DOS batch, powershell, perl
3、熟悉測試基礎，比如功能測試，性能壓力測試，安全測試，本地化測試。
4、基本測試技能，比如等價類劃分，邊界值分析，黑白盒測試，組合測試，基于模型測試，探索性測試等
5、Xml
6、P/invoke
7、Reflection
8、Threading
9、Code coverage analysis
10、Network knowledge, such as TCP/IP, HTTP, HTTPS,WCF
11、Fault injection/dependency injection and mocking
還有微軟鼓勵測試工程師 take responsibility， make a difference。鼓勵員工在做好本職工作同時在某一項技術領域專的更深。比如前面提到的一些測試基礎 (test fundamentals) 包含功能測試，性能壓力測試，安全性測試，本地化測試，容錯測試， TiP 等等。可以鼓勵測試團隊的每一個人選一個領域去專研，把他培養成不僅是產品組里的 go-to person, 而且成為公司內乃至更大范圍的領域專家。這不僅對產品的質量有幫助，更是對員工本身職業發展的極大激勵。工程師是一群特殊的人類，如果一直重復做一件事（比如本職工作），很容易厭倦失去興趣；相反越是有難度，有挑戰，有影響力的工作，越是激發工程師一定要搞定，做好的斗志和恒心，哪怕是沒有任何報酬，不為別人，為的是自我價值的實現。英語里有句話：it’s not what you have to do make you success, it’s what else you do . that will make a difference. 所以不僅僅把本職工作做好（這是最低要求了），更進一步將會使你脫穎而出。“更進一步”不是指你的本職工作，也不是讓你加班加點，而是指那些自己喜歡的可以實現自我價值，同時對產品質量有深刻影響的東西。沒有人逼你做這些東西，你完全可以選擇按部就班或平平庸庸。最后引用功夫熊貓里的一句話立志：It’s not about where you came from or what you were, it’s about what you choose to be。所以，what you choose to be?
好了，關于微軟的話題就此打住。感覺好像在寫長篇小說，沒完沒了，越聊話題越多。:)
小結，英語里面有句話“little steps lead to big change”。我覺得這句話用來描述微軟走過的測試路最恰當不過了。微軟有幾百個產品組，發布過幾千個產品。很難有一個或幾個因素決定產品的質量。但是上面幾個是我個人認為是諸多因素中的幾個至關重要的。微軟是世界上最偉大的軟件公司…..（沒有之一）。尤其是在測試方面，微軟的投資比其它任何公司都多，在軟件測試理論和實踐上絕對是首屈一指的領先者。微軟就像一個健壯的中年人，而 google 像一個 20 歲的青年，非死book 可能只是 teenager。 但是 google,非死book 這些公司起源于互聯網應用服務，在互聯網應用服務質量管理方面的確有很多出色的實踐。所以下一次和大家探討：提高軟件質量實踐――Google 篇。