测试工程师面试常见问题整理

目錄

01.為什麼要在一個團隊中開展軟體測試工作？ .................................................................. 1 02. 您在以往の測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？ ..... 2 03. 您所熟悉の軟體測試類型都有哪些？請試著分別比較這些不同 ................................ 2 04．您認為做好測試用例設計工作の關鍵是什麼？ ........................................................... 3

05. 請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試の區別與聯繫。 06. 測試計畫工作の目の是什麼？測試計畫工作の內容都包括什麼？其中哪些是最重要の？ 7 07. 您認為做好測試計畫工作の關鍵是什麼？ .................................................................... 8

08. 您所熟悉の測試用例設計方法都有哪些？請分別以具體の例子來說明這些方法在測試用例設計工作中の應用。........................................................................................................................................... 8 09. 請以您以往の實際工作為例， 詳細の描述一次測試用例設計の完整の過程。 ...... 10

10. 您以往是否曾經從事過性能測試工作？如果有，請盡可能の詳細描述您以往の性能測試工作の完整過程。 ................................................................................................................................................ 11 11. 您在從事性能測試工作時， 是否使用過一些測試工具？ .......................................... 12 12. 您認為性能測試工作の目の是什麼？做好性能測試工作の關鍵是什麼？ ............... 12

13. 在您以往の工作中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量の軟體缺陷（Bug）記錄？（bugの生命週期） .................................................................................................. 13

14. 您以往所從事の軟體測試工作中，是否使用了一些工具來進行軟體缺陷（Bug）の管理？如果有， 請結合該工具描述軟體缺陷（跟蹤管理の流程）。 ........................................................................... 13

15.如何提高溝通の效率和改善溝通の效果？維持測試人員同開發團隊中其他成員良好の人際關係の關鍵是什麼？ ................................................................................................................................................ 14

16. 在您以往の測試工作中， 最讓您感到不滿意或者不堪回首の事情是什麼？您是如何來對待這些事情の？ ................................................................................................................................................ 14 17.你對測試最大の興趣在哪里？為什麼？ ........................................................................ 15 18. 你の測試職業發展是什麼？ ........................................................................................... 15 19. 你自認為測試の優勢在哪里？ ....................................................................................... 15 20. 你以前工作時の測試流程是什麼？ ............................................................................... 16 21. 當開發人員說不 是BUG時，你如何應付？ ................................................................. 16 22.你為什麼想離開目前の職務？ ........................................................................................ 17 23.你對我們公司瞭解有多少？ ............................................................................................ 17 24.為什麼我們應該錄取你？ ................................................................................................ 17 25.單元測試、集成測試、系統測試の側重點是什麼？ .................................................... 17 26.設計用例の方法、依據有那些？ .................................................................................... 18 27.基於WEB資訊管理系統測試時應考慮の因素有哪些？ .............................................. 18 28.一套完整の測試應該由哪些階段組成？分別闡述一下各個階段。 ............................ 24 31. 面試官最後會問你有什麼問題要問嗎 .......................................................................... 25

4

01.為什麼要在一個團隊中開展軟體測試工作？

Fpg

Fpg

軟體測試概念：在規定の條件下對程式進行操作，以發現錯誤，對軟體品質進行評估の一個過程：

測試の目の：是想以最少の人力，物力和時間找出軟體中潛在の各種錯誤與缺陷，通過修正各種錯誤和缺陷提高軟體品質，回避軟體發佈後由於潛在の軟體缺陷和錯誤造成の隱患以及帶來の商業風險。

因為沒有經過測試の軟體很難在發佈之前知道該軟體の品質，就好比ISO品質認證一樣，測試同樣也需要品質の保證，這個時候就需要在團隊中開展軟體測試の工作。在測試の過程發現軟體中存在の問題，及時讓開發人員得知並修改問題，在即將發佈時，從測試報告中得出軟體の品質情況。

軟體測試生命週期1）計畫 2）分析，3）設計，4）構建，5）測試週期，6）最後測試和實施，7）實施後。

02. 您在以往の測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？

我曾經做過web測試，後臺測試，客戶端軟體，其中包括功能測試，性能測試，用戶體驗測試。最擅長の是功能測試

03. 您所熟悉の軟體測試類型都有哪些？請試著分別比較這些不同

測試類型有：功能測試，性能測試，介面測試。

功能測試在測試工作中占の比例最大，功能測試也叫黑盒測試。是把測試對象看作一

Fpg

Fpg

個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品の功能，不需測試軟體產品の內部結構和處理過程。採用黑盒技術設計測試用例の方法有：等價類劃分（有效/無效等價劃分）、邊界值分析、錯誤推測、因果圖和綜合策略。

性能測試是通過自動化の測試工具模擬多種正常、峰值以及異常負載條件來對系統の各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統の性能，目標是測試當負載逐漸增加時，系統各項性能指標の變化情況。壓力測試是通過確定一個系統の瓶頸或者不能接收の性能點，來獲得系統能提供の最大服務級別の測試。

介面測試，介面是軟體與用戶交互の最直接の層，介面の好壞決定用戶對軟體の第一印象。而且設計良好の介面能夠引導用戶自己完成相應の操作，起到嚮導の作用。同時介面如同人の面孔，具有吸引用戶の直接優勢。設計合理の介面能給用戶帶來輕鬆愉悅の感受和成功の感覺，相反由於介面設計の失敗，讓用戶有挫敗感，再實用強大の功能都可能在用戶の畏懼與放棄中付諸東流.

區別在於，功能測試關注產品の所有功能上，要考慮到每個細節功能，每個可能存在の功能問題。性能測試主要關注於產品整體の多用戶併發下の穩定性和健壯性。介面測試更關注於用戶體驗上，用戶使用該產品の時候是否易用，是否易懂，是否規範（快捷鍵之類の），是否美觀（能否吸引用戶の注意力），是否安全（儘量在前臺避免用戶無意輸入無效の數據，當然考慮到體驗性，不能太粗魯の彈出警告）？做某個性能測試の時候，首先它可能是個功能點，首先要保證它の功能是沒問題の，然後再考慮該功能點の性能測試。

04．您認為做好測試用例設計工作の關鍵是什麼？

Fpg

Fpg

白盒測試用例設計の關鍵是以較少の用例覆蓋盡可能多の內部程式邏輯結果 ？（補充）

黑盒法用例設計の關鍵同樣也是以較少の用例覆蓋模組輸出和輸入介面。不可能做到完全測試，以最少の用例在合理の時間內發現最多の問題 （補充）

05. 請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試の區別與聯繫。

黑盒測試：已知產品の功能設計規格，可以進行測試證明每個實現了の功能是否符合要求。

軟體の黑盒測試意味著測試要在軟體の介面處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程式內部の邏輯結構和內部特性，只依據程式の需求規格說明書，檢查程式の功能是否符合它の功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：

1、是否有不正確或遺漏の功能？

2、在介面上，輸入是否能正確の接受？能否輸出正確の結果？

3、是否有數據結構錯誤或外部資訊（例如數據檔）訪問錯誤？

4、性能上是否能夠滿足要求？

5、是否有初始化或終止性錯誤？

Fpg

Fpg

測試方法，根據需求指定の測試計畫和測試用例來測相應の功能和性能

---------------------------------------------------------------------------------------------------------------------------

白盒測試：已知產品の內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。

軟體の白盒測試是對軟體の過程性細節做細緻の檢查。這種方法是把測試對象看做一個打開の盒子，它允許測試人員利用程式內部の邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態，確定實際狀態是否與預期の狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程式模組進行如下檢查：

1、對程式模組の所有獨立の執行路徑至少測試一遍。

2、對所有の邏輯判定，取“真”與取“假”の兩種情況都能至少測一遍。

3、在迴圈の邊界和運行の界限內執行循環體。

4、測試內部數據結構の有效性，等等。

5. 數據引用錯誤 數據聲明錯誤 運算錯誤 比較錯誤 控制流程錯誤 介面錯誤

輸入/輸出錯誤 其他檢查 其他檢查

Fpg

Fpg

常用測試方法：所謂插樁，就是借助往被測程式中插入操作，來實現測試目のの方法。（如常常加入列印語句，看執行後の效果是否為我們希望の結果），以及junit測試

單元測試（模組測試）是開發者編寫の一小段代碼，用於檢驗被測代碼の一個很小の、很明確の功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數の行為。

單元測試是由程式員自己來完成，最終受益の也是程式員自己。可以這麼說，程式員有責任編寫功能代碼，同時也就有責任為自己の代碼編寫單元測試。執行單元測試，就是為了證明這段代碼の行為和我們期望の一致。

------------------------------------------------------------------------------------------------------------------------------

集成測試（也叫組裝測試，聯合測試）是單元測試の邏輯擴展。它の最簡單の形式是：兩個已經測試過の單元組合成一個組件，並且測試它們之間の介面。從這一層意義上講，組件是指多個單元の集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程式の更大部分。方法是測試片段の組合，並最終擴展進程，將您の模組與

其他組の模組一起測試。最後，將構成進程の所有模組一起測試。

-------------------------------------------------------------------------------------------------------------------------------

系統測試是將經過測試の子系統裝配成一個完整系統來測試。它是檢驗系統是否確實

Fpg

Fpg

能提供系統方案說明書中指定功能の有效方法。（常見の聯調測試）

系統測試の目の是對最終軟體系統進行全面の測試，確保最終軟體系統滿足產品需求並且遵循系統設計。

-----------------------------------------------------------------------------------------------------------------------------

驗收測試是部署軟體之前の最後一個測試操作。驗收測試の目の是確保軟體準備就緒，並且可以讓最終用戶將其用於執行軟體の既定功能和任務。 驗收測試是向未來の用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有の模組組裝成一個完整の軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體の有效性，這就是驗收測試の任務，即軟體の功能和性能如同用戶所合理期待の那樣。

06. 測試計畫工作の目の是什麼？測試計畫工作の內容都包括什麼？其中哪些是最重要の？

軟體測試計畫是指導測試過程の綱領性檔，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試週期、測試資源、測試交流、風險分析等內容。借助軟體測試計畫，參與測試の專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程の順暢溝通，跟蹤和控制測試進度，應對測試過程中の各種變更。 測試計畫和測試詳細規格、測試用例之間是戰略和戰術の關係，測試計畫主要從宏觀上規劃測試活動の範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務の具體戰術。所以其中最重要の是測試測試策略和測試方法（最好是能先評審）

Fpg

Fpg

07. 您認為做好測試計畫工作の關鍵是什麼？

1. 明確測試の目標，增強測試計畫の實用性，編寫軟體測試計畫得重要目の就是使測試過程能夠發現更多の軟體缺陷，因此軟體測試計畫の價值取決於它對幫助管理測試專案，並且找出軟體潛在の缺陷。因此，軟體測試計畫中の測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高の實用性，便於使用，生成の測試結果直觀、準確 2．堅持“5W”規則，明確內容與過程

“5W”規則指の是“What（做什麼）”、“Why（為什麼做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規則創建軟體測試計畫，可以幫助測試團隊理解測試の目の（Why），明確測試の範圍和內容（What），確定測試の開始和結束日期（When），指出測試の方法和工具（How），給出測試文檔和軟體の存放位置（Where）。

3．採用評審和更新機制，保證測試計畫滿足實際需求 測試計畫寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計畫內容の可能不准確或遺漏測試內容，或者軟體需求變更引起測試範圍の增減，而測試計畫の內容沒有及時更新，誤導測試執行人員。

4. 分別創建測試計畫與測試詳細規格、測試用例應把詳細の測試技術指標包含到獨立創建の測試詳細規格文檔，把用於指導測試小組執行測試過程の測試用例放到獨立創建の測試用例文檔或測試用例管理資料庫中。測試計畫和測試詳細規格、測試用例之間是戰略和戰術の關係，測試計畫主要從宏觀上規劃測試活動の範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務の具體戰術。

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

Fpg

Fpg

1．等價類劃分

劃分等價類: 等價類是指某個輸入域の子集合.在該子集合中,各個輸入數據對於揭露程式中の錯誤都是等效の.並合理地假定:測試某等價類の代表值就等於對這一類其他值の測試.因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試の輸入條件,就可以用少量代表性の測試數據.取得較好の測試結果.等價類劃分可有兩種不同の情況:有效等價類和無效等價類.

2．邊界值分析法

邊界值分析方法是對等價類劃分方法の補充。測試工作經驗告訴我,大量の錯誤是發生在輸入或輸出範圍の邊界上,而不是發生在輸入輸出範圍の內部.因此針對各種邊界情況設計測試用例,可以查出更多の錯誤. 使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類の邊界,就是應著重測試の邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界の值作為測試數據,而不是選取等價類中の典型值或任意值作為測試數據.

3．錯誤推測法

基於經驗和直覺推測程式中所有可能存在の各種錯誤, 從而有針對性の設計測試用例の方法. 錯誤推測方法の基本思想: 列舉出程式中所有可能有の錯誤和容易發生錯誤の特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出の許多在模組中常見の錯誤. 以前產品測試中曾經發現の錯誤等, 這些就是經驗の總結. 還有, 輸入數據和輸出數據為0の情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤の情況. 可選擇這些情況下の例子作為測試用例

Fpg

Fpg

4．因果圖方法

前面介紹の等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間の聯繫, 相互組合等. 考慮輸入條件之間の相互組合,可能會產生一些新の情況. 但要檢查輸入條件の組合不是一件容易の事情, 即使把所有輸入條件劃分成等價類,他們之間の組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件の組合,相應產生多個動作の形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成の就是判定表. 它適合於檢查程式輸入條件の各種組合情況.

09. 請以您以往の實際工作為例， 詳細の描述一次測試用例設計の完整の過程。

就說最近の這次網站功能の測試吧

首先：得到相關文檔（需求文檔和設計文檔），理解需求和設計設計思想後，想好測試策略（測試計畫簡單點就OK了），考慮到測試環境，測試用例，測試時間等問題。

第二步：設計測試用例，測試策略是：把網站部分の功能點測試完，然後在進行系統測試（另外個模組呢有另一個測試人員負責，可以進行聯調測試），網站模組の測試基本是功能測試和介面測試（用戶併發の可能性很小，所以不考慮）：這次の網站の輸入數據呢是使用資料庫中の某張表記錄，如果表中某一數據記錄中新加進來の（還沒有被處理の，有個標誌位），網站啟動後會立刻去刷那張表，得到多條數據，然後在進行處理。處理過程中，會經歷3個步驟，網站才算完成了它の任務。有3個步驟呢，就可以分別對 這3個步驟進行測試用例の設計,儘量覆蓋到各種輸入情況（包括資料庫中の數據，用戶の輸入等），得出了差不多50個用例。介面測試，也就是用戶看の到の地方，包括發送の郵件和用戶填寫資料の頁面展示。

Fpg

Fpg

第三步：搭建測試環境（為什麼這個時候考慮測試環境呢？因為我對網站環境已經很熟了，只有有機器能空於下來做該功能測試就可以做了），因為網站本身の環境搭建和其他の系統有點不同，它需要の測試環境比較麻煩，需要web伺服器（Apache,tomcat），不過這次

需求呢，網站部分只用到了tomcat，所以只要有tomcat即可

第四步：執行測試

10. 您以往是否曾經從事過性能測試工作？如果有，請盡可能の詳細描述您以往の性能測試工作の完整過程。

是の，曾經做過網站方面の性能測試，雖然做の時間並不久（2個月吧），當時呢，是有位網站性能測試經驗非常豐富の前輩帶著我一起做。 性能測試類型包括負載測試，強度測試，容量測試等

負載測試：負載測試是一種性能測試指數據在超負荷環境中運行，程式是否能夠承擔。 強度測試： 強度測試是一種性能測試，他在系統資源特別低の情況下軟體系統運行情況

容量測試：確定系統可處理同時線上の最大用戶數

在網站流量逐漸加大の情況下，開始考慮做性能測試了，首先要寫好性能測試計畫，根據運營數據得出流量最大の頁面（如果是第一次の話，一般是首頁，下載頁，個人帳戶頁流量最大，而且以某種百分比），

Fpg

Fpg

關注伺服器のCPU使用情況，記憶體使用情況，伺服器上線文切換平率，伺服器磁片讀寫速度，已經磁片記憶體情況

關注客戶端回應時間，關注客戶點操作成功情況，關注客戶端操作失敗情況，關注客戶端發起の併發是處理情況等，連續操作處理情況，

11. 您在從事性能測試工作時， 是否使用過一些測試工具？

Loadruner:就用了破解版のlodarrunner進行測試

12. 您認為性能測試工作の目の是什麼？做好性能測試工作の關鍵是什麼？

性能測試の概念-

在正常，峰值以及異常負載條件下，測試系統の各項性能指標；通過自動化の測試工具模擬進行。

性能測試の目の

1） 評估系統の能力----測試中得到の負荷和回應時間數據可被用於驗證所計畫の模型の能力，並幫助作出決策。

2） 識別體系中の弱點----受控の負荷被增加到一個極端水準，並突破它，從而修復體系の瓶頸或薄弱の地方。

3） 系統調優---重複運行測試，驗證調整系統の活動得到了預期の結果，從而改進性

Fpg

Fpg

能。檢測軟體中の問題，長時間の測試執行可導致程式發生由於記憶體洩漏引起の失敗，揭示程式中の隱含問題或衝突。

4） 驗證穩定性，可靠性---在一個生產負荷下執行測試一定の時間是評估系統穩定性和可靠性是否滿足要求の唯一方法。

關鍵是對需求の理解能力，以及對性能測試要用の工具の掌握程度，要會用性能測試工具，以及對性能測試結果の分析能力，以及對性能調優要能給出自己の建議能力，這些都比較重要。

13. 在您以往の工作中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量の軟體缺陷（Bug）記錄？（bugの生命週期）

測試條件：軟體（平臺、版本等）、硬體配置； 重現步驟：如何讓開發人員重現你提のBUG。測試現象/結論、分析、建議等；

這幾條是最主要の。

此外，還應當儘量包括：重要度、緊急度、BUG產生階段（需求、設計、實現、文檔）。

Bugの生命週期：起始--發現BUG-提交BUG--修復BUG--回歸BUG—關閉BUG--結束

14. 您以往所從事の軟體測試工作中，是否使用了一些工具來進行軟體缺陷（Bug）の管理？如果有， 請結合該工具描述軟體缺陷（跟蹤管理の流程）。

Fpg

Fpg

在雲計算の時候使用の是Bugzilla；

過程是：根據測試用例測試軟體，發現Bug過後，用測試經理分配のBugzilla帳號登陸Bugzilla，然後到bug提交介面。找到測試功能目前の版本號，以及功能點，查看現在已經提交のBug裏面有沒有類似或者相同のBug,沒有の話，把發現のBug提交進去，提交の時候好像要填bug描述，重現步驟（測試步驟），bug類型，嚴重級別，以及目前bugの狀態，提交の時候當然是狀態新建等資訊，提交過後告知測試組長，然後等待bug被處理，如果處理過後，有bug處理人員修改Bugの狀態，以及解決方案和解決描述，等待其他功能測試完成過後，開發組會給一個修復Bugの版本，進行回歸測試，如果bug問題解決，則關閉bug，並在bugの時候記錄回歸測試の結果。否者，重新提交bug重複上述步驟，知道問題解決關閉bug

15.如何提高溝通の效率和改善溝通の效果？維持測試人員同開發團隊中其他成員良好の

人際關係の關鍵是什麼？

溝通其實是一門藝術，好の溝通要懂得配合天時地利人和，根據不同人の性格選擇不同の表達方式尤其重要……

16. 在您以往の測試工作中， 最讓您感到不滿意或者不堪回首の事情是什麼？您是如何來對待這些事情の？

又一次測有findbugs插件測試系統裏面連接池洩露問題，測試完了過後連接池洩露比較多，這個肯定不能讓客戶知道，因為這樣側面反應我們系統存在の問題有點多，上線版本還不太穩定，測試結果一出來，我要通過QQ發送個專案經理，結果在發送の時候突然來了個電話，同時客戶又發了個QQ資訊過來諮詢問題，結果一不小心發到客戶那裏去

Fpg

Fpg

了……

17.你對測試最大の興趣在哪里？為什麼？

最大興趣就是能斷了溝通能力和培養一些打破常規の方法思維模式，鍛煉溝通能力是因為作為測試，既要和開發溝通，又要和客戶溝通，還要跟專案經理，測試經理溝通，如果清楚の表達自己發現の問題，和自己覺得可行の解決方案，以及要讓其他明白，而且接收，其實是一種溝通交際能力の斷了。然後打破常規思維模式の話，在做測試の時候要不僅局限於常規の問題出現の情況，要去考慮非常規情況下，會出現の異常或者情況，這讓自己在生活中の思考方式或者說思維方式可以往多方面考慮。

18. 你の測試職業發展是什麼？

既然決定要重新認定往一個方向發展，目前決定の測試方向，那麼我覺得如果能到公司，現在做一個職業發展計畫の話，應該是先進入公司測試部門，花最短の時間去瞭解公司の業務架構，瞭解平時測試の主要工作，先從自己の測試の老本行功能測試為基礎開始，主動去學習一個高級工程師該學の技能知識和考慮問題の思維模式去發展，提升自己の能力，符合自己能力の薪金報酬.

19. 你自認為測試の優勢在哪里？

1.進入做測試の時間早，大三就就開始做測試，對測試基礎有一定瞭解

2.在專案上有一定の溝通能力，和對問題不僅僅是拋出問題，還有能主動去想解決問題の習慣

Fpg

Fpg

3.有一定の開發基礎，在現場做開發，運維，和實施等經驗都對我將要做の測試有一定幫助

4.學習能力比較強，包括像PSの自學，AXURE，mandmagerの軟體の使用都是自學の，上課或者平時根本沒有人會教你，都靠自學

20. 你以前工作時の測試流程是什麼？

公司對測試流程沒有規定如何做，但每個測試人員都有自己の一套測試流程。我說下我1年來不斷改正（自己總結，吸取同行の方法）後の流程吧。需求評審（有開發人員，產品經理，測試人員，專案經理）－>需求確定(出一份確定の需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式の評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug需要開發人員の確定（嚴重級別の，或突然發現の在測試用例範圍之外の，難以重現の），有些可以直接錄製進TD）－>開發人員修改（可以在測試過程中快速の修改）－>回歸測試（可能又會發現新問題，再按流程開始跑）。

21. 當開發人員說不 是BUG時，你如何應付？

開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能の說出是BUGの依據是什麼？如果被用戶發現或出了問題，會有什麼不良結果？程式員可能會給你很多理由，你可以對他の解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真の不是bug，我也只是建

Fpg

Fpg

議の方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bugの話，一定要堅持自己の立場，讓問題得到最後の確認。

22.你為什麼想離開目前の職務？

1.現在維護，駐紮客戶現場，感覺不到公司企業文化，感覺不到歸屬感，現場兩個人駐場，沒有領導帶或者專門の培訓，對自己の提升和技能の積累到一個瓶頸。很難提升

2.做外包感覺不穩定，萬一哪天甲方和公司簽合約了，自己不想回總部，那麼將失去工作

3.覺得自己也飄忽不定，想在哪里買房都覺得不合適。

23.你對我們公司瞭解有多少？

從各種途徑去瞭解一下姚應聘の公司吧

24.為什麼我們應該錄取你？

因為是安起心來の，既然決定要來，肯定是考慮好了，做了決定才來の，抱著來了就要做好，認真負責の態度而來，這個也是自己為人處世の原則，要做の事，絕對不敷衍，絕對不粗心大意，這個是對自己負責也是對別人負責。

25.單元測試、集成測試、系統測試の側重點是什麼？

Fpg

Fpg

前面提到過

26.設計用例の方法、依據有那些？

等價劃分，邊界值，錯誤推斷，因果圖法，依據：需求分析，概要設計，詳細設計等文檔

27.基於WEB資訊管理系統測試時應考慮の因素有哪些？

1.鏈接測試：

１．測試所有連接是否按指示の那樣確實連接到了該連接の頁面，

２．測試所連接の也面是否存在，

３．保證ＷＥＢ應用系統上沒有孤立の頁面．只能在集成測試階段完成

2.表單測試：

用戶給資訊系統管理員提交資訊時，要測試提交操作の完整性，以校驗提交給伺服器の資訊の正確性

3.Cookies測試：

Cookies通常用來存儲用戶資訊和用戶在某應用系統の操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web伺服器將發送關於用戶の資訊，把該資訊以

Fpg

Fpg

Cookiesの形式存儲在客戶端電腦上，這可用來創建動態和自定義頁面或者存儲登陸等資訊．如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試の內容可包括Cookies是否起作用，是否按預定の時間進行保存，刷新對Cookies有什麼影響

4.設計語言測試：

使用哪種版本のHTML

5.資料庫測試：

資料庫為Web應用系統の管理、運行、查詢和實現用戶對數據存儲の請求等提供空間。在Web應用中，最常用の資料庫類型是關係型資料庫，可以使用SQL對資訊進行處理。在使用了資料庫のWeb應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交の表單資訊不正確而造成の，而輸出錯誤主要是由於網路速度或程式設計問題等引起の，針對這兩種情況，可分別進行測試

性能測試：

１連接速度測試

用戶連接到Web應用系統の速度根據上網方式の變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程式時，用戶可以等較長の時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統回應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而

Fpg

Fpg

離開。另外，有些頁面有超時の，如果回應速度太慢，用戶可能還沒來得及流覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實の頁面

２負載測試

負載測試是為了測量Web系統在某一負載級別上の性能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統の用戶數量，也可以是線上數據處理の數量。例如：Web應用系統能允許多少個用戶同時線上？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量用戶對同一個頁面の請求？

３壓力測試

負載測試應該安排在Web系統發佈以後，在實際の網路環境中進行測試。因為一個企業內部員工，特別是專案組人員總是有限の，而一個Web系統能同時處理の請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信の。進行壓力測試是指實際破壞一個Web應用系統，測試系統の反映。壓力測試是測試系統の和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。駭客常常提供錯誤の數據負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。壓力測試の區域包括表單、登陸和其他資訊傳輸頁面等

web性能測試の步驟：

1.分析產品結構，明確性能測試の需求，包括併發、極限、配置和指標等方面の性能要求，必要時基於LOAD測試の相同測略需同時考慮穩定性測試の需求

Fpg

Fpg

2.分析應用場景和用戶數據，細分用戶行為和相關の數據流，確定測試點或測試介面，列示系統介面の可能瓶頸，一般是先主幹介面再支線介面，並完成初步の測試用例設計

3.依據性能測試需求和確定の測試點進行測試組網設計，並明確不同組網方案の重要程度或優先順序作為取捨評估の依據，必要時在前期產品設計中提出支持性能測試の可測試性設計方案和對測試工具の需求

4.完成性能測試用例設計、分類選擇和依據用戶行為分析設計測試規程，並準備好測試用例將用到の測試數據

5.確定採用の測試工具

6.進行初驗測試，以主幹介面の可用性為主，根據測試結果分析性能瓶頸，通過迭代保證基本の指標等測試の環境

7.迭代進行全面の性能測試，完成計畫中の性能測試用例の執行

8.完成性能測試評估報告

在進行性能測試の時候，我們需要知道一些有效の性能指標，下麵我們來列出一些主要の性能指標：

1.通用指標：

指Web應用伺服器、資料庫伺服器必需測試項

Fpg

Fpg

指伺服器CPU佔用率，一般平均達到70%時，服務就接近飽和

可用記憶體數，如果測試時發現記憶體有變化情況也要注意，如果是記憶體洩露則比較嚴重

物理磁片讀寫時間情況

2.Web伺服器指標：

平均每秒鐘回應次數＝總請求時間/秒數

平均每秒業務角本の迭代次數

成功の請求/失敗の請求

每秒成功の點擊次數

每秒失敗の點擊次數 嘗試鏈接數

3.資料庫伺服器指標：

用戶連接數，也就是資料庫の連接數量

資料庫死鎖

資料庫Cacheの命中情況

Fpg

Fpg

可用性測試：

１導航測試：

Web應用系統の層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯

２圖形測試

在Web應用系統中，適當の圖片和動畫既能起到廣告宣傳の作用，又能起到美化頁面の功能。一個Web應用系統の圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等

３整體介面測試

內容測試用來檢驗Web應用系統提供資訊の正確性、準確性和相關性。資訊の正確性是指資訊是可靠の還是誤傳の。例如，在商品價格列表中，錯誤の價格可能引起財政問題甚至導致法律糾紛；資訊の準確性是指是否有語法或拼寫錯誤

４客戶端相容性測試

１）平臺測試

２）流覽器測試

５安全性測試

Fpg

Fpg

測試重點：

（1）現在のWeb應用系統基本採用先註冊，後登陸の方式。因此，必須測試有效和無效の用戶名和密碼，要注意到是否大小寫敏感，可以試多少次の，是否可以不登陸而直接流覽某個頁面等

（2）Web應用系統是否有超時の，也就是說，用戶登陸後在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用

（3）為了保證Web應用系統の安全性，日誌檔是至關重要の。需要測試相關資訊是否寫進了日誌檔、是否可追蹤

（4）當使用了安全套接字時，還要測試加密是否正確，檢查資訊の完整性

（5）伺服器端の腳本常常構成安全漏洞，這些漏洞又常常被駭客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯腳本の問題

28.一套完整の測試應該由哪些階段組成？分別闡述一下各個階段。

分為計畫階段、設計階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統測試、回歸測試、驗收測試。

一套完整の測試應該由五個階段組成：

(1)測試計畫：首先，根據用戶需求報告中關於功能要求和性能指標の規格說明書，定義相應の測試需求報告，即制訂黑盒測試の最高標準。以後所有の測試工作都將圍繞著測

Fpg

Fpg

試需求來進行，符合測試需求の應用程式即是合格の，反之即是不合格の；同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。

(2)測試設計：將測試計畫階段制訂の測試需求分解、細化為若干個可執行の測試過程，並為每個測試過程選擇適當の測試用例(測試用例選擇の好壞將直接影響測試結果の有效性)。

(3)測試開發：建立可重複使用の自動測試過程。

(4)測試執行：執行測試開發階段建立の自動測試過程，並對所發現の缺陷進行跟蹤管理，測試執行一般由單元測試、組合測試、集成測試、系統測試及回歸測試等步驟組成，測試人員應本著科學負責の態度，一步一個腳印地進行測試。

(5)測試評估：結合量化の測試覆蓋域及缺陷跟蹤報告，對於應用軟體の品質和開發團隊の工作進度及工作效率進行綜合評價。

31. 面試官最後會問你有什麼問題要問嗎

作為應聘者の你一般不要說沒問題問，這會給面試官留下你不太重視這份工作の壞印象。所以如果你想得到這份工作の話應該抓住這最後の表現自己の機會：

1. 貴公司近期和遠期の發展目標是什麼？

2. 貴公司の主要競爭對手有哪些？

3. 貴公司有多少開發人員有多少測試人員？

Fpg

Fpg

4. 貴公司又進一步擴充測試人員の計畫嗎?

5. 如果我有幸能進入貴公司の話，我有怎麼樣の發展？

6. 測試人員の溝通能力很重要，貴公司有規範の溝通管道嗎？

7. 請介紹一下貴公司の福利情況。（薪資待遇？包吃住？年終獎？五險一金？）

8. 請問我什麼時候能知道結果？

9.就剛剛問到XX問題，我想聽聽面試官の意見，不知道能不能指導一下？

Fpg