軟件測試面試題到這里已經分享了三期了，同學們是不是感覺意猶未盡呢？還是老規矩建議收藏起來慢慢看~

      31、軟件測試人員就是QA嗎？

      軟件測試人員的職責是盡可能早的找出軟件缺陷，確保得以修復。而質量保證人員（QA）主要職責是創建或者制定標準和方法，提高促進軟件開發能力和減少軟件缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作對象。

      軟件測試和質量是相輔相成的關系，都是為了提高軟件質量而工作。

      32、和用戶共同測試（UAT測試）的注意點有哪些？

      軟件產品在投產前，通常都會進行用戶驗收測試。如果用戶驗收測試沒有通過，直接結果就是那不到“Money”，間接影響是損害了公司的形象，而后者的影響往往更嚴重。根據作者的經驗，用戶驗收測試一定要讓用戶滿意。

      實際上用戶現場測試更趨于是一種演示。在不欺騙用戶的前提下，我們向用戶展示我們軟件的優點，最后讓“上帝”滿意并欣然掏出“銀子”才是我們的目標。因此用戶測試要注意下面的事項：

      （1）用戶現場測試不可能測試全部功能，因此要測試核心功能。這需要提前做好準備，這些核心功能一定要預先經過測試，證明沒有問題才可以和用戶共同進行測試。測試核心模塊的目的是建立用戶對軟件的信心。當然如果這些模塊如果問題較多，不應該進行演示。

      （2）如果某些模塊確實有問題，我們可以演示其它重要的業務功能模塊，必要時要向用戶做成合理的解釋。爭得時間后，及時修改缺陷來彌補。

      （3）永遠不能欺騙用戶，蒙混過關。道理很簡單，因為軟件是要給用戶用的，問題早晚會暴露出來，除非你可以馬上修改。

      和用戶進行測試還要注意各種交流技巧，爭取不但短期利益得到了滿足，還要為后面得合作打好基礎。

      33、如何編寫提交給用戶的測試報告？

      隨著測試工作越來越受重視，開發團隊向客戶提供測試文檔是不可避免的事情。很多人會問：“我們可以把工作中的測試報告提供給客戶嗎？”答案是否定的。因為提供內部測試報告，可能會讓客戶失去信心，甚至否定項目。

      測試報告一般分為內部測試報告和外部測試報告。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況，這里不過多討論，讀者可以參考相關教材。這里主要討論一下外部測試報告的寫法，一般外部測試報告要滿足下面幾個要求：

      -根據內部測試報告進行編寫，一般可以摘錄；

      -不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；

      -報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；

      -報告上面的內容盡量要真實可靠；

      -整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。

      總之，外部測試報告要小心謹慎的編寫。

      34、測試工具在測試工作中是什么地位？

      國內的很多測試工程師對測試工具相當迷戀，尤其是一些新手，甚至期望測試工具可以取代手工測試。測試工具在測試工作中起的是輔助作用，一般用來提高測試效率。自動化測試彌補了手工測試的不足，減輕一定的工作量。實際上測試工具是無法替代大多數手工測試的，而一些諸如性能測試等自動化測試也是手工所不能完成的。

      對于自動測試技術，應當依據軟件的不同情況來分別對待，一般自動技術會應用在引起大量重復性工作的地方、系統的壓力點、以及任何適合使用程序解決大批量輸入數據的地方。然后再尋找合適的自動測試工具，或者自己開發測試程序。一定不要為了使用測試工具而使用。

      35、寫出bug報告流轉的步驟，每步的責任人及主要完成的工作。

      （要結合自己實際的工作經驗進行回答，不同公司略有區別）

      測試人員提交新的Bug入庫，錯誤狀態為New。

      高級測試員/測試經理驗證錯誤，如果確認是錯誤，分配給開發組。設置狀態為Open。如果不是錯誤，則拒絕，設置為Declined狀態。

      開發經理分配bug至對應的模塊開發人員。

      開發人員查詢狀態為Open的Bug，如果不是錯誤，則置狀態為Declined；如果是Bug則修復并置狀態為Fixed。不能解決的Bug，要留下文字說明及保持Bug為Open狀態。

      對于不能解決和延期解決的Bug，不能由開發人員自己決定，一般要通過某種會議（評審會）通過才能認可。

      測試人員查詢狀態為Fixed的Bug，然后驗證Bug是否已解決，如解決，置Bug的狀態為Closed，如沒有解決,置bug狀態為Reopen。

      36、寫出bug報告當中一些必備的內容。

      硬件平臺和操作系統

      測試應用的硬件平臺（Platform），通常選擇“PC”。

      測試應用的操作系統平臺（OS）。

      37、開發人員老是犯一些低級錯誤怎么解決？

      這種現象在開發流程不規范的團隊里特別常見，尤其是一些“作坊式”的團隊里。解決這種問題一般從兩個方面入手：

      一方面從開發管理入手，也就是從根源來解決問題。可以制定規范的開發流程，甚至可以制定懲罰制度，還有就是軟件開發前做好規劃設計。

      另一方面就是加強測試，具體做法就是加強開發人員的自己測試，把這些問題“消滅”在開發階段，這是比較好的做法。

      此外，還可以通過規范的缺陷管理來對開發人員進行控制，比如測試部門整理出常見的缺陷，讓開發人員自己對照進行檢查，以減少這類低級錯誤的發生。

      開發人員犯錯誤是正常的現象，作為測試人員一定不能抱怨，要認認真真的解決問題才是上策。

      38、畫出軟件測試的V模型圖。

      39、為什么要在一個團隊中開展軟件測試工作？

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

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

      （根據項目經驗不同，靈活回答即可）

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

      41、您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同的測試類型的區別與聯系（如功能測試、性能測試……）

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

      功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。采用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。

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

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

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

      42、您認為做好測試用例設計工作的關鍵是什么？

      白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果。

      黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題。

      43、測試計劃工作的目的是什么？測試計劃工作的內容都包括什么？其中哪些是最重要的？

      軟件測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

      測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）

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

      1．等價類劃分

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

      2．邊界值分析法

      邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤. 

      使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.

      3．錯誤推測法

      基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.

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

      4．因果圖方法

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

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

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

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

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

      第四步：執行測試

      以上就是這一期的分享了。

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