1. 場景一: 假設你所在的團隊負責研發一款手機計算器程式，你是這款產品的測試負責人，你準備如何開展工作？
【Key. 測試設計類】我問他這次測試任務的範圍是什麼？開發為什麼要做這些改動？這些改動是開發自己提出來的還是客戶要求的？如果客戶要求的客戶的關注點在哪裡？這次改動具體改了什麼內容？怎麼改的？你覺得這樣的改動合理嗎？改動以前是什麼樣子的？【改動原因？改動內容？改動方法？】【保證測試工作的有效性和測試工作的覆蓋率】
(1) 明確測試任務：
? 如明確產品執行平臺？（對平臺的支援需求不同，測試的設計的差異性也很大）
? 如明確產品的研發週期？（瞭解專案的進度安排，才能制定有效的測試策略，在按測試的深度和專案的開發時間上取得較好的平衡。）對於時間驅動的(Date-Driven)專案，這類專案的特點是預先制定釋出時間，要求到了那天，產品就一定要釋出。針對這類專案，我們在設計測試計劃時，就應該更多的考慮解決和專案釋出相關的質量問題；另外對於質量驅動的(Quality-Driven)的專案，這類專案的特點是對釋出時間沒有強行的規定，但要求產品的質量必須達到一定的指標，並且需要在釋出以後，實時監控產品質量。
? 那麼，在測試中，我們不僅要做好專案當下版本的測試工作，還需要考慮構建長期、高效地測試系統和平臺，保障產品質量能夠實時度量。
? 另外，明確產品的功能設計、產品的核心競爭力、可用的測試資源等資訊，對於接下來做產品測試都是至關重要的。
(2) 分析測試範圍制定（開發溝通確定測試範圍）
測試人員每天的例行工作之一就是與開發溝通程式碼改動，並對改動進行功能迴歸，我們稱之為測試範圍確認。對於每個測試人員來說，可能都會遇到以下問題：
1、拿到一個程式碼改動後我首先做什麼？
2、跟開發溝通時問些什麼？
3、我該如何溝通才能問到自己想問的問題？才能更精確的得到迴歸範圍？
4、擔心自己問的問題太不搭調，被對方嘲笑怎麼辦？
5、跟開發溝通結束後，接下來該怎麼做？直接按照開發說的去做嗎？
栗子： 對話背景1：一天，武爺對瀏覽器的程式碼作了幾筆改動。小強匆匆忙忙地看了一下程式碼變更之後，就跑去問武爺了…
Good case（小明版）
小明：在SVN上看到一筆改動，把一個auto_ptr 換成了unique_ptr, 我瞭解到的這兩個指標，都能自動地釋放記憶體，為什麼要做這樣的轉換呢？
（評語：開題就把對方帶到了自己想要談的主題上，讓對方知道我是來找你瞭解程式碼改動。接著，說了下自己提前瞭解到的情況並提出準備好的問題，這樣能引導對方跟你思考同一個問題，有利於確認到較準確的迴歸範圍。）
武爺：原來的auto是我們自己做的，unique_ptr 是VC11的，VC11已經有自動釋放的指標了，我們就就沒必要再自己做，直接使用系統提供的就好了。
小明：那這樣改動會影響哪些範圍呢？
（評語：與對方確認改動的影響範圍，這種開放式的提問方式，能夠讓對方展開來談論，有利於我們瞭解到更多內容。）
武爺：應該沒有什麼影響，要是出問題就崩潰了，看下主路徑就行。
小明：那些指標是控制哪些物件的？
（評語：如果提前瞭解到更多的技術細節，也可以提前準備好疑問，溝通時提出來一起討論來解答疑惑）
武爺：DC(裝置繪圖的)
小明：我們對瀏覽器介面主路徑做測試，沒有出現大的問題，比如崩潰，就沒問題是吧？
（評語：好了，迴歸範圍拿到了，最後就溝通得出的結論總結下，讓雙方達成一致。）
武爺：是的。
對話背景2：一天，開發新增了一個函式，在SVN上的changelog內容註釋的是”新增了一段牛掰程式碼“，對於看不懂程式碼的測試童鞋要去找開發確認迴歸範圍了。。。
Good case1（NaNa版）
nana：想跟你確認下程式碼改動，你現在有時間嗎？
開發：有時間，你說。
nana：剛才發到你QQ上的截圖，就是那筆改動，你的註釋是”加了一段牛掰程式碼“。我看了一下，不太瞭解你這段程式碼的邏輯，你能跟我講一下嗎？
（評語：說明來意，直奔主題）
開發：哦，這個呀，這個你不用迴歸。這個沒什麼影響，功能上沒什麼大問題就行，不用迴歸。
nana：那個程式碼本身的邏輯你能簡單給我講一下嗎？我想了解一下
（評語：深入瞭解程式碼邏輯，因為了解到邏輯後，對後面的迴歸有幫助）
開發：函式本身是計算去一個最佳的距離
nana：什麼距離呢？
開發：所有字型佈局之間的距離
nana：我們瀏覽器的主框架？
開發：可以這麼理解，所有的佈局和字型之間的距離
nana：所有的佈局？我們瀏覽器的UI包括很多，主框架區、對話方塊，還有氣泡等等，是指這些嗎？
開發：主框架
nana：是指主框架的收藏欄、位址列、側邊欄等嗎？
（評語：對待每個模糊的回答，能夠細化問題，精準的確認影響範圍）
開發：是的
nana：這個函式計算的UI距離是指哪些具體的UI呢？
開發：行間距和字型的間距，圖片與字型之間的間距
nana：這段程式碼的邏輯調研過嗎？能給我交接下嗎？
（評語：明白自己的目的，以學習的心態再次要求開發講解程式碼邏輯。這在完全不瞭解程式碼邏輯但又必須得了解的情況下是可取的，能避免漏掉細節）
開發：你一定要了解嗎？那給你講講吧。
Good case2（小明版）
小明：請問有時間嗎？跟你溝通下程式碼改動，確認下回歸範圍。改動內容已經截圖發給你了。
開發：好的
小明：我看你註釋的內容是”加了一段牛掰程式碼“，這段程式碼是做什麼用的？
開發：哦，這個呀，這個你不用迴歸。這個沒什麼影響，佈局上沒什麼大問題就行，不用迴歸。
小明：它會讓佈局不一樣是吧？那它是做什麼用的呢？
開發：它主要用於計算距離，一些佈局的間距
小明：什麼時候會使用呢？
（評語：瞭解具體的函式使用細節，包括作用、使用時機、使用範圍等，有助於確認最後的迴歸範圍，這些都建議提前做準備，有備無患）
開發：展示UI的時候，需要排版時就會呼叫它來計算間距
小明：是所有UI都要用到嗎？
開發：可以這麼理解
小明：這個跟DPI有關嗎
開發：有，就是在高DPI下用來重新計算距離的
小明：哦，那就是在125%、150%DPI下用到是吧？
開發：是的
小明：那這個如果出問題的話，可能出什麼問題呢？
開發：如果出問題，佈局就錯亂了
小明：那這段函式是我們們自己寫的嗎？
開發：是
小明：那是否需要我們做內部的調研，去針對性的做一些單測呢？
（評語：引導開發思考修改存在的隱患問題，並提出做單測的想法，提出瞭如果出問題會如何如何，這樣開發會更加謹慎的去回答你提出的問題。）
開發：想做也行
小明：不會出問題吧？要是出問題我就找你哈~~哈哈哈
開發：那做一下吧
小明：那要做的話，請講一下具體實現吧。
（評語：通過單測的要求，讓開發講解程式碼實現順理成章）
開發：balabalabala。。。（講實現）
小明：我再確認下，這個功能就是在瀏覽器高DPI下，UI佈局展現時計算距離的，我們驗證UI時，應該看一下所有的UI佈局展現的正確性，包括在移動、重新整理時候的UI展示都沒問題就行吧？如果出現問題可能是錯亂等問題，這個函式如果需要深入測試的話到時候會找你瞭解具體的程式碼實現。
（評語：最後，總結下雙方的溝通結論，達成一致）
以下是測試範圍確認流程的整體框架，以及每個階段的實施建議，供大家參考。
(3) 測試計劃和測試用例：
【同類問題. 一支筆，一部電梯，一塊表，一臺銀行ATM機】
2. 場景二：假設你是QQ這個產品的測試負責人，你怎麼去測試QQ傳檔案這個功能？說一下測試點，你可以發揮自己的想象力，不必侷限於它現有的功能。
【Key】面試官想聽到的測試思路：
(1) 思路一：
按照傳檔案的流程（客戶端A-網路-伺服器-網路-客戶端B）
(2) 思路二：
按照測試框架回答（比如系統的說明從UI、功能、效能、相容性、安裝部署、伺服器端、網路、安全）
3. 經典測試用例設計題：
(3) QQ傳檔案
1、功能測試
傳送成功：
1） 檔案直接拖到對話方塊，傳送----開始傳送
2） 點選傳送檔案按鈕，傳送—開始傳送
3） 傳送中顯示傳送進度條
4） 傳送中檔名稱正確顯示，並顯示檔案大小
5） 給同一使用者傳送1個檔案、多個檔案—--能同時傳送多個檔案
6） 同時給不同使用者傳送檔案
7） 檔案開啟的時候傳送檔案---可以傳送
8） 檔案接收後，檢查檔案的完整性。
9） 檔案是否可以正常接收。
10） 接收時候預設路徑
11） 是否可以更改檔案接收路徑
12） 檔案傳送時，不影響聊天功能，不影響任何其他功能的使用。
13） 同一個檔案傳送給多個人
14） 同一個檔案傳送給同一個人多次
15）對方線上
16）對方不線上
17）傳送離線檔案
18）對方是好友
19）與對方是臨時會話
20）選擇下次接收檔案
檔案傳送失敗：
15） 點選取消可以取消檔案的傳送
16） 直接關閉對話方塊，可取消檔案的傳送—出提示
17） 斷電、斷網—傳送中斷
18） 對方拒絕接收—傳送中斷
2、 檔案大小測試
1） 空檔案
2） 資料夾巢狀1層
3） 資料夾巢狀多層
4） 資料夾巢狀很多層
5） 空資料夾
6） 10M的檔案
7） 10G的檔案---邊界值
8）
3、 檔名稱測試
2）普通檔案
3）含有特殊字元的檔案---傳送中，接收後，檔名稱都應該無誤
4）檔名為空的檔案
5）檔名為空格的檔案
6）檔名只有中文
7）檔名有中應為混合
8）檔名只有英文
9）檔名有標點符號
4、 檔案格式測試
1）.exe檔案------------安全性測試
1） Txt doc pdf
2） 圖片
3） 視訊
4） 音訊
5） 壓縮檔案
6） 資料夾
7） 病毒檔案---安全性測試
5、 安全性測試
1）.exe檔案------------安全性測試
2）病毒檔案
6、 效能測試
1） 上傳時網速很慢
2） 上傳時CPU使用率
3） 上傳時斷網
7、 介面測試
（1）介面美觀性、易用性（鍵盤和滑鼠的操作、tab跳轉的順序是否正確）----------顯示正常（根據需求）
（2）按鈕文字是否正確--------------正確
（3）正確/錯誤提示的文字是否正確---------------正確
（4）說明性文字是否正確-----------------------正確
8、 其他測試