軟件測試介紹

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

質(zhì)量不等于測試

開發(fā)對(duì)質(zhì)量負(fù)責(zé)（預(yù)防行為，不是檢測）

衛(wèi)生間張貼著最佳測試實(shí)踐

角色介紹

• SWE（Software Engineer）

• SET（Software Test Engineer)

• TE(Test Enginee)

SET也是開發(fā)角色，100%時(shí)間（不可能吧，嚴(yán)）在編寫代碼，SET和SWT是合作伙伴

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

參與設(shè)計(jì)評(píng)審

為了增加可測試性，甚至?xí)?duì)代碼重構(gòu)

關(guān)注質(zhì)量提升和測試覆蓋率增加

SET和SWT是合作伙伴

TE是產(chǎn)品專家，質(zhì)量顧問和風(fēng)險(xiǎn)分析師

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

組織結(jié)構(gòu)

測試是獨(dú)立的部門（工程生產(chǎn)力團(tuán)隊(duì)），以租借的方式進(jìn)入產(chǎn)品

不同項(xiàng)目組的借調(diào)，時(shí)刻保持新鮮感，也方便好的測試想法快速蔓延。

推廣創(chuàng)新技術(shù)，直接借調(diào)創(chuàng)新的發(fā)明者是一個(gè)很好的辦法

爬走跑

金絲雀版本（每日構(gòu)建）

開發(fā)版本（每周）

測試版本（每月最佳）

發(fā)布版本（穩(wěn)定的測試版本）

測試類型

Google用小型，中型，大型測試（對(duì)應(yīng)我們的單元，集成，系統(tǒng)測試）

小型測試

函數(shù)或模塊，需要使用mock、fake

中型測試

模塊之間的交互

大型測試

真實(shí)用戶場景和數(shù)據(jù)

軟件測試開發(fā)工程師

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

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

SET的工作

公共庫，共享代碼?？蓮?fù)用性大于功能復(fù)雜性和設(shè)計(jì)巧妙性

公共模塊必須經(jīng)過審核

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

每種語言都有統(tǒng)一的編譯器（類似我們的統(tǒng)一開發(fā)服務(wù)器）

構(gòu)建系統(tǒng)使用統(tǒng)一的打包規(guī)范（和語言無關(guān)，linux rpm）

一個(gè)產(chǎn)品有多個(gè)服務(wù)組成，服務(wù)之間并行開發(fā)，項(xiàng)目早期定下服務(wù)之間的接口。早期測試，接口都是虛假的實(shí)現(xiàn)

SET非常難招聘（又懂開發(fā)又懂測試）

“只有軟件產(chǎn)品變的重要的時(shí)候質(zhì)量才顯得重要”

產(chǎn)品早期一般不投入測試（可能重新設(shè)計(jì)），正式批準(zhǔn)后，才會(huì)尋求測試資源。

項(xiàng)目初期，設(shè)計(jì)文檔(動(dòng)態(tài)更新)

SET有一個(gè)巨大的優(yōu)勢，就是產(chǎn)品方面最寬廣的視野

SET審核初期階段的設(shè)計(jì)文檔

接口、協(xié)議，采用protocol buffer

可測試性如何，是否需要新增testing hook（為了測試增加接口，顯示系統(tǒng)內(nèi)部狀態(tài)）

協(xié)議與接口

protocol buffer定義的接口和協(xié)議由SET實(shí)現(xiàn)（SET第一個(gè)實(shí)現(xiàn)所有的接口和協(xié)議），集成測試的運(yùn)行依賴這些接口，因此SET針對(duì)各個(gè)模塊的依賴提供了mock和fake

自動(dòng)化計(jì)劃

試圖自動(dòng)化所有端到端的測試用例，是一個(gè)常見的錯(cuò)誤（SWE也不會(huì)感興趣）
自動(dòng)化投入越多，維護(hù)成本越大。自動(dòng)化計(jì)劃，應(yīng)該規(guī)模更小，目的性更強(qiáng)

端到端的自動(dòng)化測試投入過度，會(huì)把產(chǎn)品特定功能綁定在一起，產(chǎn)品穩(wěn)定之前都不會(huì)特別有用。SET應(yīng)該投入到提高質(zhì)量，而不是維護(hù)不穩(wěn)定的測試套件上。

可測試性

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

SET工作流程（實(shí)例）

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

測試執(zhí)行

只有能加速開發(fā)過程的自動(dòng)化測試才有意義，測試不應(yīng)拖慢開發(fā)的速度
新增測試程序，會(huì)創(chuàng)建一個(gè)構(gòu)建說明文件（測試名稱，源碼文件，依賴庫及數(shù)據(jù)，規(guī)模大?。９こ處熗ㄟ^一條指令即可觸發(fā)構(gòu)建、運(yùn)行自動(dòng)化和展示結(jié)果（我們有這樣的東西嗎？現(xiàn)在的方式是必須提交代碼，jenkins才會(huì)運(yùn)行，嚴(yán)）

測試大小的定義

小型測試，外部服務(wù)（文件系統(tǒng)，數(shù)據(jù)庫，網(wǎng)絡(luò)）必須通過mock和fake里實(shí)現(xiàn)
中型測試，主要目標(biāo)是驗(yàn)證指定模塊之間的交互

測試規(guī)模在共享測試平臺(tái)的使用

測試規(guī)模的益處

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

測試運(yùn)行要求

可以設(shè)置一個(gè)標(biāo)記以隨機(jī)順序執(zhí)行用例（任意順序也意味著可以并發(fā)）
google的持續(xù)集成做了優(yōu)化，利用依賴分析技術(shù)，一個(gè)代碼變更只運(yùn)行影響模塊的測試（我們能做到嗎？嚴(yán)）

測試認(rèn)證

對(duì)開發(fā)人員做測試這個(gè)文化有巨大的幫助
測試認(rèn)證是一個(gè)富有聲望的事情，從1級(jí)到5級(jí)（有徽章，可以炫耀）
（1-5級(jí)對(duì)應(yīng)的內(nèi)容在書的Page55,56）

與測試認(rèn)證計(jì)劃創(chuàng)始人的訪談

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

測試工程師

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

bug的生命周期

google使用buganizer管理bug，分為P0到P5（P0最糟）
當(dāng)bug到達(dá)的速度超過團(tuán)隊(duì)修復(fù)的能力時(shí)，不進(jìn)行新功能的開發(fā)（google強(qiáng)烈推薦這種實(shí)踐），有助于控制住bug

TE的招聘

尋找正面的價(jià)值觀：用不那么極端的輸入，一遍又一遍的測試用以模擬真實(shí)使用場景，保證通用情況下，軟件的運(yùn)行不會(huì)出錯(cuò)

google的測試領(lǐng)導(dǎo)和管理工作

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

Google Test Analytics

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

與lindsay webster訪談

go-to tester（有困難就找她）
從頭到尾理解產(chǎn)品，包括各種文檔
代表客戶
坦誠某個(gè)組件或領(lǐng)域不由自己負(fù)責(zé)，開發(fā)反而尊敬你

測試工程經(jīng)理

測試工程經(jīng)理具備TE和SET技能，并具有足夠的管理技能
獨(dú)立貢獻(xiàn)者向測試經(jīng)理（manager）匯報(bào)，資深工程師和技術(shù)負(fù)責(zé)人直接向總監(jiān)（director）匯報(bào)

影響力

google特別強(qiáng)調(diào)影響力

ankit mehta的訪談

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

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

Hung Dang的訪談

如果自動(dòng)化不能帶來明確的價(jià)值，我們就廢棄它

測試總監(jiān)

Shelton Mar

測試技術(shù)必須融入項(xiàng)目團(tuán)隊(duì)，需要非常強(qiáng)的工程師

Brad Green

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

James Whittaker

我發(fā)現(xiàn)沒有比開發(fā)工具更能激發(fā)測試人員的創(chuàng)造性和團(tuán)隊(duì)士氣了（我們是否可以借用，嚴(yán)）
我對(duì)google最滿意的兩件事：測試人員向測試人員匯報(bào)；測試人員自己決定自己的發(fā)展
Google測試的秘方：技能（測試人員的技術(shù)能力）、稀缺性（獲得開發(fā)人員的幫助）、自動(dòng)化、迭代集成

google軟件測試改進(jìn)

google的測試流程概況：讓每個(gè)工程師都注重質(zhì)量

google測試流程的致命缺陷

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

SET的未來

SET的未來就是開發(fā)
測試代碼要成為一等公民，由PM管理，由SWE編寫
測試功能特性開發(fā)應(yīng)有團(tuán)隊(duì)的新成員負(fù)責(zé)（必須學(xué)習(xí)產(chǎn)品的所有東西，包括內(nèi)部設(shè)計(jì)），是一個(gè)非常理想、最佳的熱身項(xiàng)目。

結(jié)論

軟件開發(fā)的問題已經(jīng)徹底改變，繼續(xù)死守?cái)?shù)十年之久的測試教條無異于刻舟求劍
集中測試部門逐漸下發(fā)到項(xiàng)目，讓他們更敏捷，更少關(guān)注測試流程，更多關(guān)注產(chǎn)品本身。
測試工程經(jīng)理是最強(qiáng)的產(chǎn)品專家

糕）