軟件測試介紹

少則清晰，測試人員的稀缺導致測試資源很昂貴。（不要招聘太多的測試人員）

質量不等于測試

開發對質量負責（預防行為，不是檢測）

衛生間張貼著最佳測試實踐

角色介紹

• SWE（Software Engineer）

• SET（Software Test Engineer)

• TE(Test Enginee)

SET也是開發角色，100%時間（不可能吧，嚴）在編寫代碼，SET和SWT是合作伙伴

工作重心在可測試性和通用測試基礎框架

參與設計評審

為了增加可測試性，甚至會對代碼重構

關注質量提升和測試覆蓋率增加

SET和SWT是合作伙伴

TE是產品專家，質量顧問和風險分析師

大量時間在模擬用戶的使用場景的代碼上。

組織結構

測試是獨立的部門（工程生產力團隊），以租借的方式進入產品

不同項目組的借調，時刻保持新鮮感，也方便好的測試想法快速蔓延。

推廣創新技術，直接借調創新的發明者是一個很好的辦法

爬走跑

金絲雀版本（每日構建）

開發版本（每周）

測試版本（每月最佳）

發布版本（穩定的測試版本）

測試類型

Google用小型，中型，大型測試（對應我們的單元，集成，系統測試）

小型測試

函數或模塊，需要使用mock、fake

中型測試

模塊之間的交互

大型測試

真實用戶場景和數據

軟件測試開發工程師

理想的軟件世界，有test harness， test infrastructure，mock and fake任你使用（如，模擬的數據庫）

測試代碼的主要思路是去破壞，怎樣寫測試代碼以擾亂分離用戶及其數據

SET的工作

公共庫，共享代碼。可復用性大于功能復雜性和設計巧妙性

公共模塊必須經過審核

開發人員有編寫出干凈代碼的記錄，會被授予“良好可讀性”證書

每種語言都有統一的編譯器（類似我們的統一開發服務器）

構建系統使用統一的打包規范（和語言無關，linux rpm）

一個產品有多個服務組成，服務之間并行開發，項目早期定下服務之間的接口。早期測試，接口都是虛假的實現

SET非常難招聘（又懂開發又懂測試）

“只有軟件產品變的重要的時候質量才顯得重要”

產品早期一般不投入測試（可能重新設計），正式批準后，才會尋求測試資源。

項目初期，設計文檔(動態更新)

SET有一個巨大的優勢，就是產品方面最寬廣的視野

SET審核初期階段的設計文檔

接口、協議，采用protocol buffer

可測試性如何，是否需要新增testing hook（為了測試增加接口，顯示系統內部狀態）

協議與接口

protocol buffer定義的接口和協議由SET實現（SET第一個實現所有的接口和協議），集成測試的運行依賴這些接口，因此SET針對各個模塊的依賴提供了mock和fake

自動化計劃

試圖自動化所有端到端的測試用例，是一個常見的錯誤（SWE也不會感興趣）
自動化投入越多，維護成本越大。自動化計劃，應該規模更小，目的性更強

端到端的自動化測試投入過度，會把產品特定功能綁定在一起，產品穩定之前都不會特別有用。SET應該投入到提高質量，而不是維護不穩定的測試套件上。

可測試性

SET第一要務是可測試性，提供程序結構和代碼風格建議給開發人員
代碼審查需要工具和文化的支持，google將代碼審查作為開發流程的中心，代碼審查比編寫代碼更值得炫耀。
只有被證明是值得信賴的開發者，才有往代碼庫提交代碼的資格。用“可讀性”區分有資格的提交者和新開發人員。
CL（change list），持續提交優秀的CL，獲得“可讀性”的代碼審查資格。（先要寫好代碼，才能當這方面的評委，嚴）。
自動化檢查代碼風格是否符合要求（這一塊，我們需要補上，嚴）
在與外部公共庫（或框架）有交互的地方需要依賴集成測試
項目成員輪流做“構建警察”(我們可以借鑒，每人輪流跟蹤jenkins的輸出）
TAP(Test Automation Program)

SET工作流程（實例）

詳見書籍
（google可以做到修改一個代碼，只跑這個模塊的單元測試？嚴）
基于googletest
樣例中，將_test后置
xxxx.cc（正式文件）
xxxx_test.cc（測試文件）

測試執行

只有能加速開發過程的自動化測試才有意義，測試不應拖慢開發的速度
新增測試程序，會創建一個構建說明文件（測試名稱，源碼文件，依賴庫及數據，規模大小）。工程師通過一條指令即可觸發構建、運行自動化和展示結果（我們有這樣的東西嗎？現在的方式是必須提交代碼，jenkins才會運行，嚴）

測試大小的定義

小型測試，外部服務（文件系統，數據庫，網絡）必須通過mock和fake里實現
中型測試，主要目標是驗證指定模塊之間的交互

測試規模在共享測試平臺的使用

測試規模的益處

google維護著不同測試類型之間的健康比例，全部使用大型的端到端自動化測試是錯誤；全部使用小型的單元測試也是錯誤的
不同類型的測試都有覆蓋率報告（命令行加一個選項即可在瀏覽器查看覆蓋率）（我們的中、大型測試還沒有覆蓋率報告）
經驗法則：70%是小型；20%是中型；10%是大型
如果面向用戶，集成度高，用戶接口復雜，增加中大型測試比例
基礎平臺或面向數據，增加小型測試比例
(google的Harvester是一個可視化工具）

測試運行要求

可以設置一個標記以隨機順序執行用例（任意順序也意味著可以并發）
google的持續集成做了優化，利用依賴分析技術，一個代碼變更只運行影響模塊的測試（我們能做到嗎？嚴）

測試認證

對開發人員做測試這個文化有巨大的幫助
測試認證是一個富有聲望的事情，從1級到5級（有徽章，可以炫耀）
（1-5級對應的內容在書的Page55,56）

與測試認證計劃創始人的訪談

級別1：基本操作，還有去除所有非確定性測試（結果不確定的測試），挑選冒煙測試；
級別2：提高增量覆蓋率
級別3：測試新增代碼
級別4：測試歷史遺留代碼（針對可測試性做重構）
級別5：更高的覆蓋率，每個缺陷對應增加測試用例
通過ToTT（Testing on the Toilet）和其他活動把測試搞得充滿激情、趣味和吸引力，包括fixit
針對沒有”測試時間”的狀況，尋找下面的團隊：有興趣；沒有太多冗余代碼；有測試戰神
試點項目，測試教練幫助團隊，各種宣傳，積分系統等
團隊的測試認證級別代表提高測試的重視程度，是工程生產團隊決定是否投入有限測試資源的重要參考指標
最困難的一步“所有的重要代碼變更，都需要測試”，遺留代碼缺少可測試性（長遠角度就是重構增加可測試性）0生巨大的影響
如何用acount(void *s)返回字符串中'A'的次數，有詳細的區分普通、更好、優秀的候選人的方法（Page63-67）（這個可以借鑒，嚴）

測試工程師

TE starting from middle（從頭介入不適用于google，因為早期功能不斷變化，TE沒有太多工作可做）
配備多少測試人員，取決于項目風險和投資回報率
Google只有少數團隊采用word文檔通過郵件來傳遞（很老派）
google的文化是分布式和自我管理（大政府理念會受到嘲弄）
ACC（Attribute Component Capability）是測試計劃的替代方法
Attribute是區別于競爭對手的關鍵。測試用例關聯到這些標簽，就知道哪些Attribute已經完成多少測試。
Attribute和Component要求簡潔，Capability描述完整的功能
能力最重要的一個特點就是可測試性
Attribute作為行，Component作為列，形成的表格，每個單元格里都是不同的能力（多條）。
用戶故事可以用一系列能力來描述
采用風險分析，將單元格附上顏色
風險分析需要不同人的意見。有個方法很給力，先完成一份，然后發給不同的人，他們發現偏差就會提出意見（樹個靶子）

bug的生命周期

google使用buganizer管理bug，分為P0到P5（P0最糟）
當bug到達的速度超過團隊修復的能力時，不進行新功能的開發（google強烈推薦這種實踐），有助于控制住bug

TE的招聘

尋找正面的價值觀：用不那么極端的輸入，一遍又一遍的測試用以模擬真實使用場景，保證通用情況下，軟件的運行不會出錯

google的測試領導和管理工作

海盜領導力：船員武裝到牙齒，才能卓著，不愁去處，船長怎么管理這些人？（無法通過強力和恐懼，船員的動力在于劫掠的生活方式和下一次收成的興奮感）
要靠技術洞察力，令人興奮的技術冒險，有趣的?？扛劭趤眍I導團隊
谷歌領導和管理：mentoring and guiding, not dictating

Google Test Analytics

是否有GTA類似的軟件供我們使用

與lindsay webster訪談

go-to tester（有困難就找她）
從頭到尾理解產品，包括各種文檔
代表客戶
坦誠某個組件或領域不由自己負責，開發反而尊敬你

測試工程經理

測試工程經理具備TE和SET技能，并具有足夠的管理技能
獨立貢獻者向測試經理（manager）匯報，資深工程師和技術負責人直接向總監（director）匯報

影響力

google特別強調影響力

ankit mehta的訪談

進入一個新項目，頭幾個興趣都是在傾聽（無法接受醫生觀察我不到5分鐘就開出抗生素的藥）
問為什么要做這個測試，很多開發不思考，只做他們知道怎么做的東西或看別人怎么做就怎么做。應該是能提高產品質量，提高工程師開發效率的東西
團隊的文化和氛圍很大程度來自團隊那個資深的人
管理的同時保持技術敏銳

• 留下一部分工作自己做
• 排除干擾（去了另外一個地方工作，干擾少，產能很高）
  只選用最好的人，絕不動搖
  經驗：
• 測試和開發采用相同的語言
• 關注測試基礎設施建設，讓測試更容易
• 20%的用例覆蓋了80%的使用場景（自動化這些）
  年輕的測試工程師可能一上來就干，沒有思考為什么要寫這些測試

Hung Dang的訪談

如果自動化不能帶來明確的價值，我們就廢棄它

測試總監

Shelton Mar

測試技術必須融入項目團隊，需要非常強的工程師

Brad Green

google聘用的都是極端自我驅動力的家伙，“按我說的做”用多了，這群聰明的家伙就會不理你而去做他們覺得最該做的事情（google style， 表面上答應你，后面干自己的事情）

James Whittaker

我發現沒有比開發工具更能激發測試人員的創造性和團隊士氣了（我們是否可以借用，嚴）
我對google最滿意的兩件事：測試人員向測試人員匯報；測試人員自己決定自己的發展
Google測試的秘方：技能（測試人員的技術能力）、稀缺性（獲得開發人員的幫助）、自動化、迭代集成

google軟件測試改進

google的測試流程概況：讓每個工程師都注重質量

google測試流程的致命缺陷

• 測試成了開發的拐杖（測試變得越簡單，開發越不會去做測試）
• 測試人員更關注自己的角色，而不是他們的產品
• 測試人員崇拜測試產物勝過軟件本身（所有測試產物的價值，在于他對代碼的影響，再通過產品來體現）、

SET的未來

SET的未來就是開發
測試代碼要成為一等公民，由PM管理，由SWE編寫
測試功能特性開發應有團隊的新成員負責（必須學習產品的所有東西，包括內部設計），是一個非常理想、最佳的熱身項目。

結論

軟件開發的問題已經徹底改變，繼續死守數十年之久的測試教條無異于刻舟求劍
集中測試部門逐漸下發到項目，讓他們更敏捷，更少關注測試流程，更多關注產品本身。
測試工程經理是最強的產品專家

糕）