（一）您認為做好測試用例設計工作的關鍵是什麼？

（二）您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。

（三）我現在有個程式，發現在Windows上執行得很慢，怎麼判別是程式存在問題還是軟硬體系統存在問題？

參考答案：1、檢查系統是否有中毒的特徵；2、檢查軟體/硬體的配置是否符合軟體的推薦標準；3、確認當前的系統是否是獨立，即沒有對外提供什麼消耗CPU資源的服務；4、如果是C/S或者B/S結構的軟體，需要檢查是不是因為與伺服器的連線有問題，或者訪問有問題造成的；5、在系統沒有任何負載的情況下，檢視效能監視器，確認應用程式對CPU/記憶體的訪問情況。

（四）什麼是併發？在lordrunner中，如何進行併發的測試？集合點失敗了會怎麼樣？

（五）寫出bug報告當中一些必備的內容。

（六）簡述一下缺陷的生命週期？

（七）、判斷題（每題2分,正確的“√”，錯誤的“╳”） 

（1）發現錯誤是軟體測試的目的（） 

（2）白盒測試可以找出軟體遺漏功能和程式碼錯誤功能。（）

（3）在設計測試用例時，應包括合理的應用條件和不合理的應用條件。 （）

（4）軟體缺陷一定是由編碼引起的錯誤。 （） 

（5）文件測試是對系統提交給使用者的文件進行驗證，並不是一般性的審查活動。（）

（八）如何編寫提交給使用者的測試報告？

（九）你最擅長什麼？

（十）測試產品與測試專案的區別是什麼？

參考答案：習慣上把開發完成後進行商業化、幾乎不進行程式碼修改就可以售給使用者使用的軟體成為軟體產品，也就是可以買“賣拷貝”的軟體，例如Windows2000。而通常把針對一個或者幾個特定的使用者而開發的軟體成為軟體專案，軟體專案是一種個性化的產品，可以是按照使用者要求全部重新開發，也可以修改已有的軟體產品來滿足特定的使用者需求。專案和產品的不同特點，決定我們測試產品和測試專案仍然會有很多不同的地方：-質量要求不同。通常產品的質量要高一些，修復釋出後產品的缺陷成本較高，甚至會帶來很多負面的影響。而做專案通常面向某一使用者，雖然質量越高越好，但是一般只要滿足使用者要求就可以了。-測試資源投入多少不同。做軟體產品通常是研發中心來開發，進度壓力要小些。同時由於質量要求高，因此會投入較多的人力、物力資源。-專案最後要和使用者共同驗收測試，這是產品測試不具有的特點。此外，測試產品與測試專案在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作。

（十一）沒有產品說明書和需求文件地情況下能夠進行黑盒測試嗎？

參考答案：這個問題是國內測試工程師經常遇到的問題，根源就是國內軟體開發文件管理不規範，對變更的管理方法就更不合理了。實際上沒有任何文件的時候，測試人員是能夠進行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據自己的專業技能、領域知識等不斷的深入瞭解測試物件、理解軟體功能，進而發現缺陷。在這種做法基本上把軟體當成了產品說明書，測試過程中要和開發人員不斷的進行交流。尤其在作專案的時候，進度壓力比較大，可以作為加急測試方案。最大的風險是不知道有些特性是否被遺漏。

（十二）在測試一個web頁面時，頁面顯示為空白頁，如何定位問題所在？可能是哪些原因引起的？

（十三）軟體的評審一般由哪些人蔘加？其目的是什麼？

（十四）描述測試用例設計的完整過程？

(十五 ）有個產品相當於大家下載軟體的應用商店這樣，做了一個策略，要求省內省外下載的軟體包不是一個渠道包。渠道包大家應該知道吧。就是後臺有兩個下載地址，一個是省外下載地址，一個是省內下載地址。當用戶是省內IP，則使用省內地址，當用戶是省外IP時，使用省外地址。如果是這個功能大家會怎麼測試呢，首先你就要搭建測試環境，編寫測試用例等等，留言告訴小編你如何搭建測試環境，功能點需要怎麼考慮那些。

（十六）面試官問用安卓系統和ios系統進行軟體測試，會有哪些不同？

（十七）LoadRunner分哪三部分？

（十八）資料庫內聯接和外連線，自聯接有什麼區別？

（十八）測試計劃工作的目的是什麼？測試計劃工作的內容都包括什麼？其中哪些是最重要的？

測試計劃一般是由有經驗的公司老人，組長經理來寫，也稱工作計劃，主要是根據測試範圍列表劃分功能優先順序，分配測試人員的工作量，對於風險的評估其中像需求的變更，人員的變動，技術業務的成熟度，測試的總體週期，測試的標準是什麼樣的。最重要的就是測試的標準，週期，每人每責

（十九）當開發人員說不是BUG時，你如何應付？

參考答案：開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先儘可能的說出是BUG的依據是什麼？如果被使用者發現或出了問題，會有什麼不良結果？程式設計師可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最後的確認。

（二十）如果一個bug只出現一次，該怎麼處理？

參考答案：（1）bug出現的同時立即截圖留下異常的畫面（2）使用相同的環境、裝置、測試步驟、方法，使用相同的輸入資料，看能否重 （3）不能重現，則告訴專案經理髮現bug的過程，分析優先順序，討論解決方案

（二十一）軟體測試的缺陷等級如何劃分？

參考答案：

A類—嚴重錯誤，包括以下各種錯誤：

1． 由於程式所引起的宕機,非法退出
2． 死迴圈
3． 資料庫發生死鎖
4． 因錯誤操作導致的程式中斷
5． 與資料庫連線錯誤
6． 資料通訊錯誤

B類—較嚴重錯誤，包括以下各種錯誤：

1.程式介面錯誤

2.系統可被執行，但操作功能無法執行（含指令）

3.單項操作功能可被執行，但在此功能中某些小功能（含指令引數的使用）無法被執行（對系統非致命的）

4.在小功能項的某些專案（選項）使用無效（對系統非致命的）

5.業務流程不正確

6.功能實現不完整，如刪除時沒有考慮資料關聯

7.功能的實現不正確，如在系統實現的介面上，一些可接受輸入的控制元件點選後無作用；對資料庫的操作不能正確實現；

8.報表格式以及列印內容錯誤（行列不完整，資料顯示不在所對應的行列等導致資料顯示結果不正確的錯誤）

C類—一般性錯誤，包括以下各種錯誤：

1.操作介面錯誤（包括資料視窗內列名定義、含義是否一致）

2.列印內容、格式錯誤（隻影響報表的格式或外觀，不影響資料顯示結果的錯誤）

3.簡單的輸入限制未放在前臺進行控制

4.刪除操作未給出提示

5.已被捕捉的系統崩潰，不影響繼續操作

6.雖然正確性不受影響，但系統性能和響應時間受到影響

7.不能定位焦點或定位有誤，影響功能實現

8.顯示不正確但輸出正確

9.增刪改功能，在本介面不能實現，但在另一介面可以補充實現。

D類—較小錯誤，包括以下各種錯誤：

1.介面不規範

2.輔助說明描述不清楚

3.輸入輸出不規範

4.長時間操作未給使用者提示

5.提示視窗文字未採用行業術語

6.可輸入區域和只讀區域沒有明顯的區分標誌

7.必填項與非必填項應加以區別

8.滾動條無效

9.鍵盤支援不好，如在可輸入多行的欄位中，不支援回車換行；或對相同欄位，在不同介面支援不同的快捷方式

10.介面不能及時重新整理，影響功能實現

 E類—其他錯誤

1.游標跳轉設定不好，滑鼠（游標）定位錯誤

2.一些建議性問題

（二十二）軟體的安全性應從哪幾個方面去測試？

（二十三）http有哪些請求方式，get和post請求有什麼區別

參看答案：

    get傳輸資料是通過URL請求，以field（欄位）= value的形式，置於URL後，並用"?"連線，多個請求資料間用"&"連線，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程使用者是可見的；post傳輸資料通過Http的post機制，將欄位與對應值封存在請求實體中傳送給伺服器，這個過程對使用者是不可見的；

    Get傳輸的資料量小，因為受URL長度限制，但效率較高，Post可以傳輸大量資料，所以上傳檔案時只能用Post方式；

 post較get安全性較高，get是不安全的，因為URL是可見的，可能會洩露私密資訊，如密碼等.

    get方式只能支援ASCII字元，向伺服器傳的中文字元可能會亂碼，post支援標準字符集，可以正確傳遞中文字元。

（二十四）http請求和http響應包含哪些內容

參考答案：

    請求報文包含三部分：
    a、請求行：包含請求方法、URI、HTTP版本資訊

    b、請求首部欄位

    c、請求內容實體
    響應報文包含三部分：

    a、狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語

    b、響應首部欄位

    c、響應內容實體

（二十五）α測試，β測試定義?

　　α測試是軟體開發公司組織內部人員，模擬各類使用者，對即將上市的軟體產品進行測試，試圖發現錯誤並修復的過程。

　　β測試是由軟體的多個使用者在實際使用環境中進行的測試，這些使用者返回有關錯誤資訊給開發者。

（二十六）Socket程式設計瞭解麼，應用在哪些地方

參考答案：

    可以把 WebSocket 看成是 HTTP 協議為了支援長連線所打的一個大補丁。WebSocket是HTML5下一種新的協議。它實現了瀏覽器與伺服器全雙工通訊。最大不同是：
    WebSocket是一種雙向通訊協議。在建立連線後，WebSocket伺服器端和客戶端都能主動向對方傳送或接收資料，就像Socket一樣；
    WebSocket需要像TCP一樣，先建立連線，連線成功後才能相互通訊
一個使用WebSocket應用於視訊的業務思路如下：
    使用心跳維護websocket鏈路，探測客戶端端的網紅/主播是否線上
    設定負載均衡7層的proxy_read_timeout預設為60s
    設定心跳為50s，即可長期保持Websocket不斷開

（二十七）Tcp與udp區別？

    TCP面向連線（如打電話要先撥號建立連線）;UDP是無連線的，即傳送資料之前不需要建立連線TCP提供可靠的服務。
    TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付
    TCP面向位元組流，實際上是TCP把資料看成一連串無結構的位元組流;UDP是面向報文的，UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如IP電話，實時視訊會議等）
    每一條TCP連線只能是點到點的;UDP支援一對一，一對多，多對一和多對多的互動通訊
    TCP首部開銷20位元組;UDP的首部開銷小，只有8個位元組
    TCP的邏輯通訊通道是全雙工的可靠通道，UDP則是不可靠通道

（二十八）、介面測試用例的編寫要點有哪些？

1、測試每個引數型別不合法的情況(型別不合法容易遺漏null型)

2、測試每個引數取值範圍不合法的情況

3、測試引數為空的情況

4、測試引數前後臺定義的一致性

5、 測試每個引數的上下限(這裡容易出現致命的BUG，如果程式處理不當，可能會程式導致崩潰)

6、如果兩個請求有嚴格的先後順序，需要測試調轉順序的情況

（二十九）你所熟悉的軟體測試型別有哪些?

參考答案：

測試型別有：功能測試、效能測試、介面測試

　　功能測試在測試工作中佔有比例最大，功能測試也叫黑盒測試。

　　效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。

　　介面測試，介面是軟體與使用者互動的最直接的層，介面的好壞決定使用者對軟體的第一印象。

　　區別在於，功能測試關注產品的所有功能，要考慮到每個細節功能，每個可能存在的功能問題。效能測試主要關注產品整體的多使用者併發下的穩定性和健壯性。介面測試則關注與使用者體驗相關內容，使用者使用該產品的時候是否已用，是否易懂，是否規範(使用者無意輸入無效的資料，當然考慮到體驗性，不能太粗魯的彈出警告)。做某個效能測試的時候，首先它可能是個功能點，首先要保證她的功能是沒有問題的，然後再考慮效能的問題。

   （三十）說說你對整合測試中自頂向下整合和自底向上整合兩個策略的理解，要談出它們各自的優缺點和主要適應於哪種型別測試？參考答案：

1、自頂向下整合
    優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟體功
能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支援故障隔離。
    缺點：柱的開發量大；底層驗證被推遲；底層元件測試不充分。

適應於產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要儘早被驗證；希望儘早能看到產品的系統功能行為。
2、自底向上整合
    優點：對底層元件行為較早驗證；工作最初可以並行整合，比自頂向下效率高；減少了樁的工作量；支援故障隔離。
    缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。適應於底層介面比較穩定；高層介面變化比較頻繁；底層元件較早被完成。

（三十一）開發人員修復缺陷後，如何保證不影響其他功能 
參考答案：

    Bug的修復以及新功能的新增都有可能對版本造成一些影響，為了避免，在新版本釋出以後，首先會對新版本做一個基礎的流程測試也叫做冒煙測試，如果測試基本流程都順利通過沒有任何問題，那麼測試人員可以繼續進行詳細的測試，否則就將冒煙測試中出現 的問題以及問題有可能出現的原因反饋給開發人員，由開發人員修正後再次發版，進行測試。這是一個迭代的過程。

（三十二）介面測試持續整合是如何進行的呢？

參考答案：

    對介面測試而言，持續整合自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實現了介面自動化，主要應用於迴歸階段，後續還需要加強自動化的程度，包括但不限於下面的內容：

    1) 流程方面：在迴歸階段加強介面異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。

    2) 結果展示：更加豐富的結果展示、趨勢分析等

    3) 問題定位：報錯資訊、日誌更精準，方便問題復現與定位。

    4) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。

    5) 程式碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高程式碼覆蓋率。

    6) 效能需求：完善效能測試體系，通過自動化的手段監控介面效能指標是否正常。

（三十三）介面響應的結果有那些？

    1）對異常請求的處理

    2）請求頭的處理

    3）存在業務關聯的介面

    4）涉及資料庫互動的介面

    5）結構不同

    6）節點值有效性

    7）列表結構排序

（三十四）正交表測試用例設計方法的特點是什麼？

參考答案：

用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很複雜;

對於基本的驗證功能，以及二次整合引起的缺陷，一般都能找出來;但是更深的缺陷，更復雜的缺陷，還是無能為力的;

具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。

（三十五）說說你對軟體配置管理的理解

參考答案：

相關推薦