☆測試

    一個好的測試人員會在着手測試之前，先準確瞭解自己要測試的是什麼。

 

測試問題一般分爲以下四類：

（1）測試現實生活中的事物（比如一支筆）；

（2）測試一套軟件；

（3）編寫代碼測試一個函數；

（4）調試解決已知問題。針對每一類題型，我們都會給出相應的解法。

請記住，處理這四類問題時，切勿假設使用者會好好地正常操作。請做好應對用戶誤用亂用軟件的準備。

1.      面試官想考擦什麼

表面上看，測試問題主要考察你能否想到周全完備的測試用例。這在某種程度上也是對的，求職者確實需要想出一系列合理的測試用例。

但除此之外，面試官還想考察以下幾個方面。

• 全局觀：你是否真的瞭解軟件是怎麼回事？你能否正確區分測試用例的優先順序？比如說，假設你被問到該如何測試像亞馬遜這樣的電子商務系統。若能確保產品圖片顯示位置正確，當然也不錯，但最重要的還是確保支付流程萬無一失，貨品能順利地進入發貨流程，並且顧客絕對不能被重複扣款。

• 懂整合：你是否瞭解軟件的工作原理？該如何將它們整合成更大的軟件生態系統？假設要測試谷歌電子表格，你自然會想到測試文檔的打開儲存及編輯功能。但是，實際上，谷歌電子表格也是大型軟件生態系統的重要組成部分之一。所以，你還需將它與Gmail、各種插件和其它模塊整合在一起進行測試。

• 會組織：你能否有條理地處理問題？還是處理問題時毫無條理？被要求提出照相機的測試用例時，有些求職者只會一股腦兒倒出一些雜亂無章的想法。而優秀的求職者卻能將測試功能分爲幾類，比如拍照、照片管理、設置，等等。在創建測試用例是，這種結構化處理方法還有助於你將公司操作落實。

• 可操作：你制定的測試計劃是否合理，行之有效？比如，如有用戶報告，軟件會在打開某種圖片時崩潰，而你卻只是要求他們他們重新安裝軟件，這顯然太不實際了。你的測試計劃必須切實可行，便於公司操作落實。

倘若能在面試中充分展現這些方面，那麼，你無疑就是任何測試團隊所夢寐以求的重要

一員。

2.      測試現實生活中的事物

問及該如何測試一支筆時，有些求職者會感到莫名驚詫。畢竟，你要測試的不是軟件嗎？

沒錯，但這些關於“現實生活”的問題其實很常見。我們先來看看下面這個例子吧！

比如有這麼一個問題：如何測試一枚回形針？

l 步驟1：使用者是哪些人？做什麼用？

你需要跟面試官討論一下，誰會使用這個產品，做什麼用。回答可能出乎你的意料，比

如，回答可能是“老師，把紙張夾在一起”或“藝術家，爲了彎成動物造型”。又或者，兩者皆要考慮。這個問題的答案，將影響你怎麼處理後續問題。

l 步驟2：有哪些用例？

列出回形針的一系列用例，這對解決問題很有幫助。在這個例子中，用例可能是，將紙

張固定在一起，且不得破壞紙張。

若是其它問題，可能會有多個用例。比如，某產品要能夠發送和接收內容，或擦寫和刪

除功能，等等。

l 步驟3：有哪些使用限制？

使用限制可能是，回形針一次可以夾最多30張紙，且不會造成永久性損害（比如彎掉），

另外，可以夾30到50張紙時，只不過會發生輕微變形。

同時，使用限制也要考慮環境因素。比如，回形針可否非常溫暖的環境下（33~43攝氏

度）使用？在極寒環境下呢？

l 步驟4：壓力與失效情況下的狀態如何？

沒有產品是萬無一失的，所以，在測試中，還必須分析失效情況。跟面試官探討時，最

好問一下在什麼情況下產品失效是可接受的（甚至是必要的），以及什麼樣纔算是失效的。

        舉個例子，要你測試一臺洗衣機，你可能會認爲洗衣機至少要能洗30件T恤衫或褲子。一次放進30到45件衣服，可能會導致輕微失效，因爲衣物洗得不夠乾淨。若超過45件衣物，出現極端失效或許可以接受。不過，這裏所謂的極端失效，應該是指洗衣機根本不該進水，絕對不應該讓水溢出來或引發火災。

l 步驟5：如何執行測試？

有些情況下，討論執行測試的細節可能很重要。比如，若要確保一把椅子能正常使用5

年，你恐怕不會把它放在家裏，等上5年來看結果。相反，你需要定義何謂“正常”使用情況（每年會在椅子上坐多少次？扶手呢？）。然後，除了做一些手動測試，你可能還會想到找臺機器，自動執行某些功能測試。

3.      測試一套軟件

測試軟件與測試現實生活中的事物非常相似。主要差異在於，軟件測試往往更強調執行

測試的細節。

        請注意，軟件測試主要有如下兩個方面。

• • 手動測試與自動化測試：理想情況下，我們當然希望能夠自動化所有的測試工作，不過這不太現實。有效東西還是手動測試來的更好，因爲某些功能對計算機而言過於定性，計算機很難有效地檢查（比如，內容帶有淫穢色情成分）。此外，計算機只能機械地識別明確告知的情況，而人類就不一樣了，通過觀察可能發現亟待驗證的新問題。因此，在測試過程中，無論是人工還是計算機，兩者都不可或缺。

  • 黑盒測試與白盒測試：兩者的區別反映了我們對軟件內部機制的掌控程度。在黑盒測試中，我們只關心軟件的表象，並且僅測試其功能。而在白盒測試中，我們會了解程序的內部機制，還可以分別對每一個函數單獨進行測試。我們也可以自動執行部分黑盒測試，只不過難度要大得多。

        下面介紹一種測試方法，並從頭到尾細述一遍。

l 步驟1：要做黑盒測試還是白盒測試？

儘管通常我們會拖到測試後期才考慮這個問題，但我喜歡早點做出選擇。不妨根面試官

確認一下，要做黑盒測試還是白盒測試——或是兩者都要。

l 步驟2：使用者是哪些人？做什麼用？

一般來說，軟件都會有一個或多個目標用戶，設計各個功能時，就會考慮用戶需求。比

如，若要你測試一款家長用來監控網頁瀏覽器的軟件，那麼，你的目標用戶既包括家長（實施監控過濾哪些網站），又包括孩子（有些網站被過濾了）。用戶也可能包括“訪客”（也就是既不實施也不受監控的使用者）。

l 步驟3：有哪些用例？

在監控過濾軟件中，家長的用例包括安裝軟件、更新過濾網站清單、移除過濾網站，以

及供他們自己的不受限制的網站。對孩子而言，用例包括訪問合法內容積“非法”內容。

切記，不可憑空想象來決定各種用例，應該與面試官交流討論後確定。

l 步驟4：有哪些使用限制？

大致定義好用例後，我們還需要找出確切的意思。“網絡被過濾屏蔽”具體指什麼？只

過慮屏蔽“非法”網頁還是屏蔽整個網站？是否要求該軟件具備“學習”能力，從容識別不良內容，異或只是根據白名單或黑名單進行過濾？若要求具備學習能力並自動識別不良內容，允許多大的誤報漏報率？

l 步驟5：壓力條件和失效條件爲何？

軟件的失效是不可避免的，那麼，軟件失效應該是什麼樣的？顯然，就算軟件失效了，也不能導致計算機宕機。在本例中，失效可能是軟件未能屏蔽本該屏蔽的網站，或是屏蔽本來允許訪問的網站。對於後一種情況，你或許應該與面試官討論一下，是不是讓家長輸入密碼，允許訪問該網站。

l 步驟6：有哪些測試用例？如何執行測試？

這纔是手動測試和自動測試以及黑盒測試和白盒測試真正顯示出差異的地方。

在步驟3和步驟4中，我們初步擬定了軟件的用例，這裏會進一步加以定義，並討論該

如何執行測試。具體需要測試哪些情況？其中哪些步驟可以自動化？哪些又需要人工介入？

請記住，在有些測試中，雖然自動化可以助你一臂之力，但它也有着重大缺陷。一般來

說，在測試過程中，手動測試還是少不了的。、

對着上面的清單一步步解決問題時，請不要想到什麼就草率吐露。這會顯得很沒有條理，

而且你肯定會遺漏重要環節。相反，你應該組織好自己的思路，先將測試工作分割爲幾個主要模塊，然後逐一展開分析。這樣，不僅可以給出一份更完整的測試用例清單，而且也顯得你做事有層次、有條理。

4.      測試一個函數

基本上，測試函數是測試中最簡單的一種，與面試官的交流相對也會比較簡短、清晰，

因爲，測試一個函數通常不外乎就是驗證輸入與輸出。

話說回來，千萬不要忽視與面試官交流的重要性。對於任意可能，特別是如何處理特定

情況，你都應該深究到底。

        假設要你編寫代碼測試對整數數組排序的函數sort(int [] array),可參考下面的解決步驟。

l 步驟1：定義測試用例？

一般來說，你應該考慮以下幾種測試用例。

正常情況：輸入正常數組時，該函數是否能生成正確的輸出？務必記得考慮其中的潛在問題。比如，排序通常涉及某種分割處理，應該要合理的想一想，數組元素個數爲奇數時，由於無法均分數組，算法可能無法處理。所以，測試用例必須涵蓋元素個數爲偶數與奇數的兩種數組。

極端情況：傳入空數組會出現什麼問題？或傳入一個很小的數組（只有一個元素）？此外，傳入非常大數組又會如何呢？

空指針和“非法”輸入：值得花時間好好考慮一番，若函數接收到非法輸入，該怎麼處理。比較，你在測試生成第n項菲波那切數的函數，那麼，在測試用例中，自然要考慮n爲負數的情況。

奇怪的輸入：第四種有可能出現的情況：奇怪的輸入。傳入一個有序數組會怎麼樣？或者，傳入一個反向排序的數組呢？

        只有充分了解函數功能，才能想到這些測試用例。如果你對各種限制條件不是很清楚，最好先向面試官問個清楚。

l 步驟2：定義預期結果？

通常，預期結果非常明顯：正確的輸出。然而，在某些情況下，你可能還需要驗證其它

情況。比如，如果sort函數返回的是一個已排序的新數組，那麼，你可能還有驗證一下原先的數組是否保持原樣。

l 步驟3：編寫測試代碼？

有了測試用例，並定義好預期結果後，編寫代碼實現這些測試用例，也就水到渠成了。

代碼大致如下：

   

   

5.      調試與故障排除

測試問題的最後一種是，說明你會如何調試或排除已知故障。碰到這種問題，很多求職

者都會支支吾吾，處理不當，給出諸如“重裝軟件”等不切實際的答案。其實，就像其它問題一樣，還是有章可循的，也可以有條不紊地處理。

        下面通過一個例子輔助說明，假設你是谷歌Chrome瀏覽器團隊的一員，收到一份bug報告：Chrome啓動時會崩潰。你會怎麼處理。

        重新安裝瀏覽器或許就能解決該用戶的問題，但是，若其他用戶碰到同樣問題，怎麼辦？你的目標是搞清楚究竟出了什麼問題，以便開發人員修復缺陷。

l 步驟1：理清狀況？

首先，你應該多體問題，儘量瞭解當時的情況：

• 用戶碰到這個問題有多久了？

• 該瀏覽器的版本號？在什麼操作系統下運行？

• 該問題經常發生嗎？或者，出問題的頻率有多高？什麼時候會發生？

• 有無提交錯誤報告？

l 步驟2：分解問題？

瞭解了問題發生時的具體狀況，接下來，着手將問題分解爲可測模塊。在這個例子中，

可以設想出以下操作步驟。

1. 轉到Windows的“開始”菜單。

2. 點擊Chrome圖標。

3. 瀏覽器啓動。

4. 瀏覽器載入參數設置。

5. 瀏覽器發送HTTP請求載入首頁。

6. 瀏覽器收到HTTP迴應。

7. 瀏覽器解析網頁。

8. 瀏覽器顯示網頁內容。

        在上述過程中的某一點，有地方出錯致使瀏覽器崩潰。優秀的測試人員會逐一排查每個步驟，診斷定位問題所在。

l 步驟3：創建特定的、可控的測試？

以上各個測試模塊都應該有實際的指令動作——也就是你要求用戶執行的、或是你自己

可以做的操作步驟（從而在你自己的機器上予以）。在真實世界中，你面對是一般客戶，不可能給他們做不到或不願做的操作指令。

 

附：隨機崩潰常見原因

1. 隨機變量：該應用程序可能用到某個隨機變量或可變分量，程序每次執行時取值不定。具體的例子包括用戶輸入、程序生成的隨機數，或當前時間等。

2. 未初始化變量：該應用程序可能包含一個未初始化變量，在某些語言中，該變量可能含有任意值。這個變量取不同值可能導致代碼每次執行路徑有所不同。

3. 內存泄漏：該程序可能存在內存溢出。每次運行時引發問題的可疑進程隨機不定，這與當時運行的進程數量有關。另外還包括堆溢出或棧內數據被破壞。

4. 外部依賴：該程序可能依賴別的應用程序、機器或資源。要是存在多處依賴，程序就有可能在任意位置崩潰。

                                    ——摘自《程序員面試金典(第5版)》