背面試題是避免面試出現被問懵的現象最好的方式，昨天我們分享了第一期軟測經典面試題，今天我們繼續分享，還是老規矩建議收藏~~

      16、簡述一下缺陷的生命周期？

      提交->確認->分配->修復->驗證->關閉

      17、軟件的安全性應從哪幾個方面去測試？

      用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議

      加密機制

      安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描

      數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理

      防病毒系統

      18、一套完整的測試應該由哪些階段組成？

      測試計劃、測試設計與開發、測試實施、測試評審與測試結論

      19、軟件系統中除用戶文檔之外，文檔測試還應該關注哪些文檔？

      開發文檔

      軟件需求說明書

      　　　　數據庫設計說明書

      　　　　概要設計說明書

      　　　　詳細設計說明書

      　　　　可行性研究報告

      管理文檔

　      　　　項目開發計劃

      　　　　測試計劃

　　　      　測試報告

　      　　　開發進度月報

      　　　　開發總結報告

      20、簡述軟件系統中用戶文檔的測試要點？

      讀者群。文檔面向的讀者定位要明確。對于初級用戶、中級用戶以及高級用戶應該有不同的定位

      術語。文檔中用到的術語要適用與定位的讀者群，用法一致，標準定義與業界規范相吻合。

      正確性。測試中需檢查所有信息是否真實正確，查找由于過期產品說明書和銷售人員夸大事實而導致的錯誤。檢查所有的目錄、索引和章節引用是否已更新，嘗試鏈接是否準確，產品支持電話、地址和郵政編碼是否正確。

      完整性。對照軟件界面檢查是否有重要的分支沒有描述到，甚至是否有整個大模塊沒有描述到。

      一致性。按照文檔描述的操作執行后，檢查軟件返回的結果是否與文檔描述的相同。

      易用性。對關鍵步驟以粗體或背景色給用戶以提示，合理的頁面布局、適量的圖表都可以給用戶更高的易用性。需要注意的是文檔要有助于用戶排除錯誤。不但描述正確操作，也要描述錯誤處理辦法。文檔對于用戶看到的錯誤信息應當有更詳細的文檔解釋。

      圖表與界面截圖。檢查所有圖表與界面截圖是否與發行版本相同。

      樣例與示例。像用戶一樣載入和使用樣例。如果是一段程序，就輸入數據并執行它。以每一個模塊制作文件，確認它們的正確性。

      語言。不出現錯別字，不要出現有二義性的說法。特別要注意的是屏幕截圖或繪制圖形中的文字。

      印刷與包裝。檢查印刷質量；手冊厚度與開本是否合適；包裝盒的大小是否合適；有沒有零碎易丟失的小部件等等。

      21、如何理解壓力、負載、性能測試測試？

      性能測試是一個較大的范圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。

      壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操作都是壓力測試。

      而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問可以看作壓力測試，那么連續訪問8個小時就可以認為負載測試，1000個用戶連續訪問系統1個小時也可以看作是負載測試。

      實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體性能的高度上來對系統進行測試。

      22、什么是系統瓶頸？

      瓶頸主要是指整個軟硬件構成的軟件系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。

      嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，內存也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求。在用戶極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響用戶工作。

      因此我們測試系統瓶頸主要是實現下面兩個目的：

      -發現“表面”的瓶頸。主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然后解決瓶頸，這是性能測試的基本目標。

      -發現潛在的瓶頸并解決，保證系統的長期穩定性。主要是考慮用戶在將來擴展系統或者業務發生變化時，系統能夠適應變化。滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟件生命周期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化。

      23、文檔測試主要包含什么內容？

      在國內軟件開發管理中，文檔管理幾乎是最弱的一項，因而在測試工作中特別容易忽略文檔測試也就不足為奇了。要想給用戶提供完整的產品，文檔測試是必不可少的。文檔測試一般注重下面幾個方面：

      文檔的完整性：主要是測試文檔內容的全面性與完整性，從總體上把握文檔的質量。例如用戶手冊應該包括軟件的所有功能模塊。

      描述與軟件實際情況的一致性：主要測試軟件文檔與軟件實際的一致程度。例如用戶手冊基本完整后，我們還要注意用戶手冊與實際功能描述是否一致。因為文檔往往跟不上軟件版本的更新速度。

      易理解性：主要是檢查文檔對關鍵、重要的操作有無圖文說明，文字、圖表是否易于理解。對于關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明了。

      文檔中提供操作的實例：這項檢查內容主要針對用戶手冊。對主要功能和關鍵操作提供的應用實例是否豐富，提供的實例描述是否詳細。只有簡單的圖文說明，而無實例的用戶手冊看起來就像是軟件界面的簡單拷貝，對于用戶來說，實際上沒有什么幫助。

      印刷與包裝質量：主要是檢查軟件文檔的商品化程度。有些用戶手冊是簡單打印、裝訂而成，過于粗糙，不易于用戶保存。優秀的文檔例如用戶手冊和技術白皮書，應提供商品化包裝，并且印刷精美。

      24、功能測試用例需要詳細到什么程度才是合格的？

      這個問題也是測試工程師經常問的問題。有人主張測試用例詳細到每個步驟執行什么都要寫出來，目的是即使一個不了解系統的新手都可以按照測試用例來執行工作。主張這類寫法的人還可以舉出例子：歐美、日本等軟件外包文檔都是這樣做的。

      另外一種觀點就是主張寫的粗些，類似于編寫測試大綱。主張這種觀點的人是因為軟件開發需求管理不規范，變動十分頻繁，因而不能按照歐美的高標準來編寫測試用例。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。

      實際上，軟件測試用例的詳細程度首先要以覆蓋到測試點為基本要求。舉個例子：“用戶登陸系統”的測試用例可以不寫出具體的執行數據，但是至少要寫出五種以上情況（），如果只用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以采用等價劃分）。

      另一個影響測試用例的就是組織的開發能力和測試對象特點。如果開發力量比較落后，編寫較詳細的測試用例是不現實的，因為根本沒有那么大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善。測試對象特點重點是指測試對象在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。

      因此，測試用例的編寫要根據測試對象特點、團隊的執行能力等各個方面綜合起來決定編寫策略。最后要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時，不斷地提高自身能力。

      25、沒有產品說明書和需求文檔地情況下能夠進行黑盒測試嗎？

      這個問題是國內測試工程師經常遇到的問題，根源就是國內軟件開發文檔管理不規范，對變更的管理方法就更不合理了。實際上沒有任何文檔的時候，測試人員是能夠進行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據自己的專業技能、領域知識等不斷的深入了解測試對象、理解軟件功能，進而發現缺陷。

      在這種做法基本上把軟件當成了產品說明書，測試過程中要和開發人員不斷的進行交流。尤其在作項目的時候，進度壓力比較大，可以作為加急測試方案。最大的風險是不知道有些特性是否被遺漏。

      26、測試中的“殺蟲劑怪事”是指什么？

      “殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟件測試技術》第二版中提出。用于描述測試人員對同一測試對象進行的測試次數越多，發現的缺陷就會越來越少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本原因就是測試人員對測試軟件過于熟悉，形成思維定勢。

      為了克服這種現象，測試人員需要不斷編寫新的測試程序或者測試用例，對程序的不同部分進行測試，以發現更多的缺陷。也可以引用新人來測試軟件，剛剛進來的新手往往能發現一些意想不到的問題。

      27、完全測試程序是可能的嗎？

      軟件測試初學者可能認為拿到軟件后需要進行完全測試，找到全部的軟件缺陷，使軟件“零缺陷”發布。實際上完全測試是不可能的。主要有以下一個原因：

      -完全測試比較耗時，時間上不允許；

      -完全測試通常意味著較多資源投入，這在現實中往往是行不通的；

      -輸入量太大，不能一一進行測試；

      -輸出結果太多，只能分類進行驗證；

      -軟件實現途徑太多；

      -軟件產品說明書沒有客觀標準，從不同的角度看，軟件缺陷的標準不同；

      因此測試的程度要根據實際情況確定。

      28、軟件測試的風險主要體現在哪里？

      我們沒有對軟件進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。舉個例子，程序員為了方便，在調試程序時會彈出一些提示信息框，而這些提示只在某種條件下會彈出，碰巧程序發布前這些代碼中的一些沒有被注釋掉。在測試時測試工程師又沒有對其進行測試。如果客戶碰到它，這將是代價昂貴的缺陷，因為交付后才被客戶發現。

      因此，我們要盡可能的選擇最合適的測試量，把風險降低到最小。

      29、發現的缺陷越多，說明軟件缺陷越多嗎？

      這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個后，會接二連三的發現很多缺陷，頗有個人成就感。其中的原因主要如下：

      -代碼復用、拷貝代碼導致程序員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷。

      -程序員比較勞累是可以導致某些連續編寫的功能缺陷較多。程序員加班是一種司空見慣的現象，因此體力不只時容易編寫一些缺陷較多的程序。而這些連續潛伏缺陷恰恰時測試工程師大顯身手的地方。

      “缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象。如果軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就可以了。

      30、所有的軟件缺陷都能修復嗎？所有的軟件缺陷都要修復嗎？

      從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對于整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：

      -沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改。

      -有些缺陷只是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以后升級中進行修復。

      -不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。

      最后要說的是，缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。

      有想學習軟件測試的同學，可以參考千鋒軟件測試培訓班提供的軟件測試學習路線，內容包含軟件測試環境配置與管理，數據庫測試技術，軟件測試編程技術，應用程序測試技術，互聯網/移動互聯網測試技術等，根據千鋒軟件測試培訓機構提供的軟件測試學習路線圖，可以讓你對學好軟件測試需要掌握的知識有個清晰的了解，并能快速入門軟件測試。想要獲取學習路線或學習資料的同學可以添加我們的軟測技術交流qq群：858327674  加群找管理領取即可，軟測相關問題也可以加群解答，等你來哦~~~