《Google軟件測試之道》摘錄

如下是最近看的一本書《Google軟件測試之道》裏的一些摘錄，收穫不少。

一、討論測試開發比並無什麼意義，若是你是一名開發人員，同時也是一名測試人員，若是你的職位頭銜上有測試的字樣，你的任務就是使那些頭銜上沒有測試的人能夠更好的去作測試。

二、只有在軟件產品變得重要的時候質量才顯得重要。

三、假如你被要求去實現一個函數account（void *）返回一個字符串中大寫字母A出現的次數。若是候選人上來就直接開始寫代碼，這無非在傳遞一個強烈的信息，只有一件事情須要去作而我正在作這個事情，這個事情就是寫代碼。SET不會遵循這樣的世界觀，他們會先把問題搞清楚。

      這個函數是用來作什麼的?咱們爲何要構建它？這個函數的原型看起來正確嗎？咱們指望候選人能夠關心函數的正確性以及如何驗證指望的行爲。一個問題值得更多的關注!候選人若是沒頭沒腦地就跳進來編碼，試圖解決問題，在對待測試問題上他一樣會沒頭沒腦。若是咱們提出一個問題是給模塊增長測試場景，咱們不但願候選人上就直接開始羅列全部可能的測試用例，直到咱們強迫他停下來。其實咱們只是但願他先執行最佳的測試用例。

      SET的時間是有限的。咱們但願候選人可以回過頭來尋找最有效的解決問題的方法，爲先前的函數定義能夠作一些改進。優秀的SET在面對拙劣的API定義的狀況下，在測試的過程當中也能夠把這個API定義變得更漂亮些。

普通的候選人會花幾分鐘經過提問題和陳述的方式來理解需求文檔，例如如下幾點。

• 傳入的字符串編碼是什麼:ASCII,  UTF-8或其餘的編碼方式?

• 函數名字比較槽糕，應該是駝峯式(CamelCased)的?須要更多說明描述，仍是這裏應該遵循其餘的什麼命名規範?

• 返回值類型是什麼(或許面試官忘記了，因此我會增長一個int類型的返回值在函數原型以前)?

• void*是危險的。咱們應該考慮更合適的類型，如char*。在一些編譯時刻類型檢查能夠爲咱們提供一些幫助。

• 若是隻有一個A的狀況，計數結果是多少?它對小寫字母a也計數嗎?

• 在標準庫中不是已經有這樣的函數了嗎(爲了面試的目的，僞裝你是第一個實現這個函數功能的人)?

更好的候選人則會考慮的更多一些。

• 考慮下擴展性：或許返回值的類型應該是1個64位的整形，由於Google常常涉及海量數據。

• 考慮下複用性：爲何這個函數是針對大寫字母A進行計數的?一個好的辦法是參數化，使得任意的字符均可以被計數，而不是使用不一樣的函數來實現。

• 考慮下安全性：這此指針都是來自於可信任的地址嗎?

最佳的候選人會這樣考慮。

• 考慮擴展

          這個函數會在Shared data(譯註:數據分區，是數據庫存儲分害J( partition)的一種方式。水平分割是一個數據庫的設計一準則，數據以記錄行的方式存儲在不一樣的物理位置，而不是經過不一樣列的方式存儲。或許這纔是調用這個函數最有用的形式。在這個場景須要考慮一些什麼問題嗎?針對整個互聯網的全部文檔運行這個函數，該如何考慮性能和正確性?

          若是這個子程序被每個Google查詢所調用，並且因爲外部的封裝層面已經對參數作了驗證，傳遞的指針是安全的，或許減小1個空指針的檢查會天天節省上億次的cpu調用週期，井縮短用戶的響應時間。最少要理解所有參數驗證所帶來的潛在影響。

•     考慮基於常量的優化

        咱們能夠假設輸入的數據是已經排好順序的嗎？若是是那樣，咱們或許能夠在找到第個大寫字母B以後就快速退出。輸入的數據是什麼結構?多數狀況下都是A嗎?多數是字符的混合，仍是隻包含字毋A和空格？若是那樣，在咱們比較指令的地方或許能夠作些優化。當在處理大數據，甚至小數據的時候，在代碼執行的時候對於真實的計算延遲也會有比較顯著的亞線性變化。

• 考慮安全性

  在許多系統上，若是這是一段對於安全敏感的代碼，能夠考慮更多的非空的指針作測試，在某些系統上，1是一個非法指針。

  增長一個字符長度的參數，用以保證代碼不會運行到指定字符串以外的部分。檢查字符串長度，這個參數的值是否正常。那些不是以null結尾的字符串是黑客們的最愛。

       若是指針指向的數據能被其餘的線程修改，這裏就有潛在的線程安全問題。

       咱們是否應該使用try/catch來捕獲異常的發生？或者若是未能如預期那樣正常的調用代碼，咱們或許應該返回錯誤代碼給調用者。若是有錯誤代碼的話，這些代碼通過良好的定義並有文檔嗎？這意味着候選人在思考大型代碼庫和運行時刻的上下文環境方面的問題，這樣的思索能夠避免錯誤代碼的重複和遺漏。

四、在Google，若是測試運行失敗須要清除的知道測試代碼在作什麼，不然這個測試就應該被禁止掉，或者被標記爲怪異的測試，或是忽略這個測試的運行失敗，這個問題若是發生了，這是編寫出壞代碼的SWE的責任，或是代碼審查時給予經過的投票的SWE或SET的責任。

五、使用白盒測試知道哪些用例是無效的：

一般狀況下，普通的候選人會這樣作。

• 他們會比較有條理地或體系化地提供特定的字符串(如不一樣的字符串大小)而不是隨機的字符串。

• 專一於產生有意義的測試數據。考慮如何去運行大型測試和使用真實環境的數據作測試。

更優秀的候選人會這樣作的更多一些。

• 在併發線程中調用這個函數，去查看在串擾(cross talk )、死鎖和內存泄露方面是否存在問題。

• 構建長時間持續運行的測試場景。例如在一個while(true)循環中調用函數，並確保他們在不間斷地長時間運行過程當中保持功能正常。

• 在構建測試用例、測試數據的產生方法、驗證和執行上保持濃厚的興趣。

六、Selenium在瀏覽器內部使用JavaScript實現，而WebDriver使用瀏覽器自己的API集成到瀏覽器內部。兩種方法各有優劣。例如，Selenium能夠在瞬間打開一個新的Chrome瀏覽器，但卻不能上傳文件或者很好地處理用戶交互，由於它是JavaScript實現，必須限定在JS沙箱以內。因爲WebDriver構建在瀏覽器裏面，它能夠突破這些限制，但打開個新的瀏覽器卻比較痛苦。在咱們都開始爲Google工做的時候，咱們決定把這兩個集成到一塊兒。

七、風險分析

• 哪些事件須要擔憂

• 這些事件發生的可能性有多大?

• 一旦發生，對公司產生多大影響?

• 一旦發生，對客戶產生多大影響?

• 產品具有什麼緩解措施?

• 這些緩解措施有多大可能會失敗?

• 處理這些失敗的成本有哪些？

• 恢復過程有多困難?

• 事件是一次性問題，仍是會再次發生?

八、對於一個web測試頁面，一個文本輸入框，一個計數按鈕，用於計算一個字符串中大寫字母A出現的個數。請設計出一系列字符串來測試這個web頁面。

      一些候選人頭扎進去開始羅列測試用例，這每每是一個危險的信號，說明他們尚未充分思考這個問題。根據咱們的經驗，追求數量而非質量的傾向，是一種低效的工做方式，所以會給負面評價。經過觀察候選人在找到答案以前思考和解決問題的方式，能瞭解他們不少東西。

        更好的是那些會提出一些問題，來作進一步澄清的候選人：大寫仍是小寫？只是英語嗎？計算完成後文本會被清除嗎？屢次按下按鈕會發生什麼事情？諸如此類。在問題被澄清以後，候選人開始列舉測試用例。重點觀察他們是否使用一些瘋狂的作法。他們只是在試圖破壞軟件，仍是同時在驗證它能正常工做？他們知道這二者的區別嗎？他們是否能從最顯而易見的簡單的輸入開始，儘快地發現大bug?他們能清晰地列出測試計劃或數據嗎?在白板上隨機擺放字符串不能反映出思路的清晰性，他們極可能毫無測試計劃，或者只有很粗糙很隨意的測試計劃。

        一個典型的列表以下：

不管丟失上述測試和總結哪幾個都是一個很差的徵兆。

更好的候選人會超越輸入選擇，討論更加高級的測試問題。他們可能會作如下的事情。

• 質疑界面的外觀、調色板和對比度。如「這些與相關應用風格一致嗎?」，「視力困難的人能使用麼？「等

• 擔憂文本框過小了，建議加長以便顯示更長的輸入字符串。

• 考慮這個應用可否在同一臺服務器運行多個實例。會發生多個用戶的串擾嗎？

• 提出疑問「數據會被記錄嗎」，輸入串可能包含地址或其餘身份信息。

• 建議使用真實數據進行自動化測試，如從詞典或書本里選擇。

• 提出疑問，「計算足夠快嗎?在大負載下呢?」

• 提出疑問，「該頁是可發現的嗎？用戶怎麼能找到該頁面呢？」

• 輸入HTML和JavaScript，看是否會破壞頁面渲染。

• 詢問是對大寫仍是小寫的A計數，仍是都包括。

• 嘗試複製和粘貼字符串。

還有一些想法更加高級，反映了富有經驗的、寶貴的測試思惟，可以比問題走的更遠。他們可能會這樣作。

• 意識到計算會經過URL-encoded HTTP GET請求傳遞到服務器，字符串可能會在穿越網絡時被截斷。所以，沒法保證支持多長的URL 

• 建議將此應用參數化。爲什麼只對字母A一計數呢?

• 考慮計算其餘語臺中的A(如埃A或變音符號)。

• 考慮該應用是否能夠被國際化。

• 考慮編寫腳本或者手工採樣來探知字符串長度的上限(例如，經過2的指數遞進算法)，而後確保在此區間內功能正常。

• 考慮背後的實現和代碼。也許有一個計數器遍歷該字符串，另一個跟蹤已經遇到了多少個A累加器)。所以，能夠在邊界值附近變化A的個數和字符串的長度來進行測試。

• 提出疑問，"HTTP POST方法和參數會被黑掉嗎?也許有安全漏洞?」

• 用腳本建立各類有趣的排列組合和字符串特性如長度、A的個數等的組合，自動生成測試輸入和驗證。

     瞭解候選人使用多長的字符串作爲測試用例，這一般能暗示他們工做時的表現。若是候選人只是通常性的知道使用「長字符串」(最多見的答案)，但卻沒法就特定場景進行技術性的分析，這是一種糟糕的跡象。更懂技術的候選人，會詢問字符串的規格說明，進而圍繞極限點進行邊界值測試。例如，當極限點是1000的時候，他們會嘗試999. 1000和10010最好的候選人還會嘗試2^32，以及許多其餘有趣的值，例如2和10的次方。重點在於候選人表現出對真正重要的數字值的理解，而不僅是使用隨機數值——他們須要對底層的算法、語言、運行時和硬件都有所瞭解，由於這些正是錯誤最常常出現的地方。他們還應當基於可能的實現細節嘗試不一樣的長度，並考慮到計數器、指針及抓環的邊界錯誤。最優秀的候選人還會意識到系統多是有狀態的，測試必須將先前的輸入考慮在內。所以，屢次輸入同一字符串，或者在長度爲1000的字符串以後輸入一個長度爲0的，這些就屬於重要的使用情形。

      在Google，鑑於快節奏的發佈週期，規格說明常常變來變去，能夠有不一樣的理解和修改。若是候選人能指出「5個字符的最大長度」這種描述是有點奇怪的，有可能會使用戶感到疑惑，這正反映了他們能從用戶角度思考。若是候選人不假思索地接受了這個描述並匆忙動手，那他們在實際工做中也頗有可能如此，結果是自費力氣驗證了錯誤的行爲。那些能反駁或者質疑規格說明的候選人，每每在工做中有優異的表現。固然，也要注意反駁或者質疑的方式。

九、加入一個新項目的頭幾個星期，我主要用來傾聽而不是發表意見，深刻理解團隊很是重要，要學習產品的架構，瞭解團隊的最新動態。我不能接受一位醫生在觀察我不到五分鐘的時間就給我開乓抗生素類的藥詩之:。一樣地，我也不指望個測試團隊能夠接受，我一開始就提出的什麼解決方案。在進行診斷以前你必須先要學習。

      我感受人們有時候作事只是由於看到別人這麼作，或者他們測試某個特性的時候只是作那些他們知道怎麼作的東西。若是你不問他們爲何，他們本身也不會費心思考這事兒，由於他們已經把那些做爲了一種習慣。

十、咱們作的每件事都有明確的目的。咱們質疑全部的事情：測試用例、每項自動化測試。其實咱們正在作的不少事情就通不過這種審視。若是自動化不能帶來明確的價值，咱們就廢棄它。全部的事情都是價值驅動的，這才能成就團隊。若是要我給新晉測試經理什麼建議，我會告訴他們：大家作的每一件事都要創造價值，可以持續地創造價值。

 十一、個人測試人員個個都是通才。具體來講，每一個人都能作手工測試，真的是每一個人都能。探索式測試足深刻學習理解一個產品的最佳途徑。我永遠不會讓  一個測試開發工程師成爲一個框架開發者。我但願他們深刻產品並瞭解如何使用它。每一個測試人員都必須強調用戶。他們必須是專家級的用戶，通曉整個產品的每一個細節。在個人團隊，咱們把如穩定性測試、電源管理、性能測試、壓力測試和第三方應用程序的快速檢查都留給自動化測試完成。舉個例子，沒有人可以手動發現相機的內存泄露或在各個平臺下驗證一個單一特性的功能——這絲都須要自動化。大量重複性的工做不適合手工測試，或者一些須要機器才能達到的高精度測試就必須經過自動化測試來完成。

十二、Google的測試流程能夠很是簡練地歸納爲：讓每一個工程師都注重質量。只要你們誠實認真地這麼作，質量就會提升。代碼質量從一開始就能更好，早期構建版本的質量會更高，集成也再也不是必須的，系統測試能夠關注於真正面向用戶的問題。全部的工程師和項目都能從堆積如山的bug中解脫出來。

1三、Google在測試方面的祕方：（James）那就是測試人員所擁有的技術能力(包括計算機科學的專業文憑)、測試資源的稀缺從而得到開發人員幫助和不斷進行測試優化、優先考慮自動化(這樣才能讓人去作那些計算機作很差的事情)，以及快速迭代、集成和得到用戶反饋的能力。其餘公司要想效仿Google的作法，應該從這四個方面作起：技能、稀缺性、自動化和迭代集成。這就是Google測試的「祕方」，照方抓藥吧！

1四、任何角色都不該被過度強調。團隊的每一個人都是在爲產品工做，而不是爲了開發過程當中的某個部分。開發過程自己就是爲產品服務的。除了作出更好的產品，流程的存在還有其餘的目的嗎？用戶愛上的是產品，而不是開發產品流程。

1五、測試的價值是在於測試的動做，而不是測試產物。

        ​相對於被測代碼來講，測試工程師生成的測試產物都是次要的：測試用例是次要的：測試計劃是次要的：bug報告是次要的。這些產物都須要經過測試活動才能體現價值。不幸的是，咱們過度稱讚這此產物(好比在年度評估時，統計測試上程師提交的bug數量) ,而忘記了被測的軟件。全部測試產物的價值，在於它們對代碼的影響，進而經過產品來體現。

    ​    ​獨立的測試團隊，傾向於把重點放在建設和維護測試產物上。若是把測試的目標定位在產品的源碼上，整個產品都將受益。所以，測試人員必須把產品放在第一位。