軟件測試基礎知識點

1.對某軟件，你是怎麼進行測試的？

答：外觀界面、功能、性能、安全性、兼容性，易用性

　　外觀界面測試：主要是測試軟件界面功能模塊的佈局是否合理、總體風格是否一致、界面中文字是否正確、命名是否統一，頁面是否美觀、文字、顏色、圖片組合是否完美等；

　　功能測試：測試軟件所呈現給用戶的全部功能點是否都能正常使用和操做，是否知足軟件需求規格說明書的要求

　　易用性測試：測試軟件是否易操做，主觀性比較強，站在用戶的角度體驗軟件產品好很差用

　　兼容性測試：測試該軟件與其餘軟件的兼容能力，主要考慮軟件與瀏覽器的兼容能力，包括分辨率的兼容

　　安全性測試：測試該軟件防止非法入侵的能力

　　性能測試：測試軟件在不一樣環境的壓力下是否能正常運轉，很重要的一個指標是系統響應時間，例如多人同時訪問某個網頁時，網頁是否能在規定時間內打開等指標

2.爲何要對需求文檔進行評審呢？

答：消除歧異，完善需求細節，並達成共識

3.如何評審需求文檔？

答：正確性：對照用戶的原始需求，檢查產品經理制定得軟件規格說明數書是否偏離了用戶原始需求的意思

　　明確性：檢查軟件需求規格說明書中的每個需求項是否存在一些含糊其辭的詞彙，用因而否清晰，是否有歧義

　　完整性：對照用戶的原始需求，檢查產品經理制定的軟件需求規格說明書是否覆蓋了用戶所提出來的全部需求項，每一個需求項有沒有遺漏用戶所提出的一些必要信息

　　優先級：軟件需求規格說明書對哪些功能比較重要，哪些功能比較次要是否做了標號和編號

　　一致性：檢查軟件需求規格說明書裏面的內容先後是否一致，確保不衝突，不矛盾

　　限制性：每一個需求項裏是否清晰的描述了這個軟件能作什麼，不能作什麼，能輸入什麼，不能輸入什麼，能輸出什麼，不能輸出什麼

4.軟件質量：用戶滿意，表示軟件質量很好，不然很差

5.黑盒測試：是指只測試軟件外部的功能特性，而不去測試軟件內部的代碼結構，黑盒測試也稱爲功能測試；

　白盒測試：是指只測試代碼結構，而不測試軟件的外部功能點

6.軟件測試分類：

測試類	測試方法	執行者	測試依據	測試內容
單元測試	白盒	開發人員	詳細設計文檔、概要設計文檔	代碼及代碼的邏輯結構
集成測試	白盒爲主， 黑盒爲輔	開發人員	詳細設計文檔、概要設計文檔 軟件需求規格說明書	模塊與模塊之間的接口
系統測試	黑盒	測試人員	軟件需求規格說明書	軟件的外觀界面、功能、易用性、兼容性、安全性、性能
驗收測試	黑盒	用戶	軟件需求規格說明書	軟件的外觀界面、功能、易用性、兼容性、安全性、性能

7.需求文檔：就是描述軟件要作成一個什麼樣的產品的說明文檔

8.測試工做從何時開始的？

答：我以前作的測試工做，通常都是從拿到需求文檔的時候就開始了，主要的工做就是評審需求文檔，評審的目的是消除歧義，完善需求細節，並達成共識

9.什麼叫8/2原則？

答：是指80%的錯誤是集中在20%的·模塊裏，常常出錯的模塊經修復後還會出錯

10.你有寫過軟件測試計劃嗎？

答：嗯，有寫過。不過咱們寫的是本身所負責模塊的測試計劃，項目的總體測試計劃通常由測試經理來寫的

11.軟件測試計劃包括哪些內容？

答：第一個是測試的範圍，主要是指的是系統測試的範圍以及本輪測試是測試所有的模塊仍是說只測試部分的模塊，是否須要進行外觀界面、功能、易用性、兼容性等測試

第二個是測試環境，指的是測試人員是在什麼樣的軟硬件環境下測試軟件

第三個是測試策略，它的主要內容有進行測試的依據、系統測試准入和準出標準、測試工具的選擇、測試的重點及方法

　　　　其中，測試依據：須要指明軟件測試依據的標準文檔有哪些。其中有兩個重要的文檔，一個是軟件規格說明書，另外一個是測試用例

　　　　測試的准入標準：指系統知足什麼條件後才能開始進行系統測試，一般測試的准入標準是指經過冒煙測試

　　　　測試工具選擇：須要指明在測試過程當中會使用哪些工具。例如JIRA和Selenium這兩款測試工具

　　　　測試的準出標準：也叫測試經過標準。未關閉BUG的數量在不超過多少的狀況下。可視爲經過測試。

　　　　測試的重點及方法·：在作系統測試的過程中，應當標明要測試的重點模塊和區域。測試方法是黑盒測試，也就是手工測試

第四個是測試管理，指的是測試任務的分配、時間進度的安排、測試與開發的溝通方式等內容。

　　　　測試任務的分配：肯定整個測試範圍後，測試經理會根據團隊中每一個測試人員的特長分配相關任務，主要的兩項工做爲：一個是測試用例的設計和編寫，另外一個是測試用例的執行和操做

　　　　測試進度的安排：根據實際分配的工做任務來指定每一個測試人員進行每項測試工做的起始時間和完成時間

　　　　溝通方式：溝通方式有不少種，經常使用的有面對面的溝通、電子郵箱、以及BUG管理工具

第五個是測試風險：常見的風險有：需求文檔理解不透徹、測試時間估計不足及測試執行不到位

　　　　需求文檔理解不透徹：會致使測試人員對軟件功能模塊的理解存在誤差而影響判斷遇到的問題，從而產生無效BUG

　　　　測試時間估計不足：因爲對本身工做量的估計不足而致使在規定時間內沒法完成相應任務，會直接影響整個測試工做進度，形成測試計劃推遲的風險

　　　　測試執行不到位：有些測試人員存在一些僥倖心理，認爲有些功能模塊不重要而不去執行。

12.什麼是冒煙測試？

答：首先從所有用例中篩選一些基本的功能點進行測試，若是沒有問題才進入系統測試中，若是有問題則中止測試，待開發人員修復好後再進入系統測試的用例執行。選取qifenzhiyi到十五分之一之間

13.什麼是測試用例，它的基本元素有哪些？

答：測試用例就是用於測試的一個例子。主要有如下基本元素：

用例序號：---編號

測試模塊：---軟件的某個功能模塊

前置條件：---網絡正常，須要的數據正確無誤
測試環境：---軟件環境：操做系統windows，IE/Firefox
---硬件環境：PC臺式機：CPU/內存/硬盤
操做步驟：---執行測試操做的每一步的詳細描述，相應數據展示
預期結果：---需求規格說明書中明確的需求結果
實際結果：---執行操做後實際得出的結果
是否經過：---實際結果與預期結果是否一致，一致爲經過，否：則不經過
備註：---其餘要求說明等

 14.測試用例的做用

答：可讓測試人員做爲測試的標準，並指導測試人員進行測試工做，測試人員能夠按照測試用例的操做步驟和具體數據逐一執行測試，以發現問題並提交BUG，最終來改善軟件的質量

15.測試人員是依據什麼來設計測試用例的？

答：軟件需求規格說明書

16.功能測試的用例設計方法：等價類劃分法、邊界值分析法、錯誤推測法、正交表分析法、場景法、因果圖斷定法

等價類劃分法：把全部可能輸入的數據劃分爲若干個區域，而後從每一個區域當中取少數有表明性的數據測試便可。把符合需求規格中規定的數據稱爲有效數據，把不符合需求規格中規定的數據稱之爲無效等價類；

邊界值分析法：取稍高於或稍低於邊界的一些數據進行測試，程序在處理邊界數據的時候比較容易出錯

錯誤推測法：指的是測試人員憑本身的直覺、測試經驗、發散思惟去設計一些測試點，而這些測試點可能致使軟件出現錯誤。主要有：超長混合字符串、全角字符串、數字0、單引號等

正交表分析法：能夠有效的減小用例設計個數的方法，就是在測試有多個輸入項時，測試人員能夠測試其中一個輸入項的時候能夠默認其餘的輸入項都是正確的

場景法：用戶可能給到一個場景或簡單的業務流程或一段簡單的文字需求描述，此時測試人員須要根據本身已有的業務流程或已有的場景和需求，充分發揮對用戶實際業務的場景的想象

因果圖斷定法：咱們輸入的條件可能有不少種，每一種條件之間的組合均可能造成一個新的結果，咱們把其中的條件和結果經過圖形的方法表現出來，最後經過斷定表進行展示

17.用例設計思路：首先分析需求規格，再進行基本功能的測試點分析

18.從哪幾個方面來對測試用例進行評審？

第一：測試用例是否依據軟件需求規格說明書來寫的

第二：測試用例中的執行步驟、輸入數據是否清晰、簡潔、正確；對於重複度高的執行步驟，是否進行了簡化

第三：每一個測試用例是否都有明確的預期結果

第四：測試用例中是否存在多餘用例

第五：測試用例是否覆蓋了需求規格中全部的功能點，必需要測試什麼功能、若是有些功能的用例沒有設計到會形成什麼後果

19.您是怎麼設計測試用例的？

答：嗯，我以爲設計一個功能模塊的測試用例主要是基於如下的幾個方面：

　　首先最主要的仍是要參考軟件需求規格說明書，而後儘量挖掘出更多的需求細節進行用例設計

　　第二：能夠憑藉本身的一些測試經驗和常識來設計

　　第三：能夠參考其餘同事曾寫過的測試用例

　　第四：能夠經過網上的一些資料做爲補充

20.如何保證測試用例的質量（怎麼樣的用例纔算得上是一個好的用例）

答：第一：要確保測試用例是針對需求規格來寫的，確保測試點能覆蓋到全部的需求點

　　第二：要保證操做步驟、具體數據、預期結果的清晰性、間潔性、明確性；以確保測試用例的可操做性和可複用性

　　第三：確保有足夠多的異常測試用例（若有效等值類之外的測試點），同時要確保沒有多餘的重複的用例

　　第四：就是要對測試用例進行評審

21.若是沒有需求文檔，你是如何設計測試用例的？

答：首先我會大致的測試一下軟件，如邊界值、輸入數據類型等需求不明確的問題反饋給本身的上司或產品經理，待產品經理給出相應的標準後在進行設計

　　第二：若是在測試軟件過程當中發現有些功能模塊的需求很是不明確，已經影響到用戶對產品功能的正確使用，對於此類的重大問題，我會及時反饋

　　第三：我會經過參加項目的各類討論會、會經過以往的測試用例、以往所提的bug中、以往的用戶手冊和過程幫助文檔；或去諮詢產品人員的方式儘量的去了解相關的需求信息，以此爲基礎設計測試用例並測試軟件

　　第四：能夠對找照軟件的功能直接設計用例，而後提交給測試組

22.B/S結構和C/S結構

答：B/S結構是Browser/Server，即瀏覽器/服務器，是使用瀏覽器訪問服務器的模式

　　C/S結構是Client/Server，即客戶端/服務器，在客戶的電腦上要安裝一個軟件，而後使用客戶端的軟件去訪問服務器的模式

23.網頁的兼容性測試你是怎麼作的？

答：對於網頁兼容性這一塊，

　　第一：考慮各類瀏覽器對前臺頁面的兼容性測試

　　第二：考慮分辨率的兼容性

　　第三：考慮其返回頁面的相應時間

 24.迴歸測試：開發人員把bug修復好後，測試人員從新驗證下bug是否被開發人員修復好

25.一個完整的bug包括哪些內容？

答：bug編號、軟件名稱和版本號、測試環境、bug等級、bug的概要、bug的具體描述、bug處理的優先級、bug提交人、bug發現的時間、bug的處理人、bug的狀態（new，open，fixed已修復，reopen，rejected，close）、必要的附件、其餘備註

26.你和開發人員就bug發生了爭議你是怎麼處理的？

答：首先的話我會對事不對人，不能由於bug而激化了雙方的矛盾

　　第二：多是我寫得bug開發人員看不懂，耐心的和開發人員描述清楚，並帶有充足的依據和理由

　　第三：若是寫清楚了，但開發人員仍是不肯意修改的話，能夠找一個合適的時間、心平氣和的和開發人員溝通，說明bug的產品質量可能產生的不良影響，溝經過程不能意氣用事

　　第四：經溝通後，若是開發人員仍是不肯意修改，能夠向測試經理彙報，或由測試經理召開bug評審大會

27.如何提一個高質量的bug？

答：第一：寫清楚bug的概要，要使開發人員一看到bug概要的時候就知道這個bug單提的是什麼bug

　　第二：bug的具體描述，也就是bug的重現步驟，bug記錄的細節越詳細越好

　　第三：能附上相應的截圖和日誌

　　第四：所測的版本號和測試的環境要寫清楚

28.若是你發了一個bug，但以後也沒有重現過了，你怎麼辦？

答：首先我會截圖，並收集日誌，以保留好測試現場；

若是說這個bug只出現過一次，後面就沒有出現過，那麼我會千方百計讓這個bug重現；

萬一沒有重現，我仍是會提交bug給開發人員，有截圖和日誌也一併附上，若是開發人員要求重現，那後期就繼續觀察，若是最終沒有重現，則把此問題反映給測試經理，匯同開發人員進行評審和商量

29.一份軟件測試報告都包含哪些內容？

答：測試報告是一份描述軟件的測試環境、測試依據、測試過程、測試範圍、測試結果分析、系統存在的風險以及測試結論；

　　測試過程：測試人員、測試時間、測試地點、測試的版本等信息點。

　　測試環境：軟件和硬件環境

　　功能點測試範圍：具體所測模塊及分佈在該模塊上的全部功能點

　　測試結果分析：bug的問題彙總、bug的分佈狀況

　　系統存在的風險：系統中遺留的bug會對軟件形成什麼的風險

　　測試結論：在報告的最後給出一個是否能上線的結論

30.軟件測試工做結束的標準是什麼？

答：第一：已經按照測試計劃中的安排完成了全部的測試工做

　   第二：測試用例已經所有執行完畢，並進行了歸整

　　第三：每一個測試人員手上的bug都處於關閉狀態或者是被清理完成

　　第四：迴歸測試所有執行完成，已沒有發現能夠影響產品上線的bug，軟件產品具有了上線標準

　　第五：每一個測試人員所負責的測試報告已完成，並提交給了測試經理

31.軟件的測試流程是怎麼樣的？（說一下測試流程）

答：有如下幾個階段：需求評審，測試計劃制定，測試用例設計，用例評審、環境搭建、測試執行（提交bug，迴歸測試）、寫測試報告

32.你如何理解測試這分工做？（談談對軟件測試的理解）

答：軟件測試的主要任務是發現軟件中的bug，因此軟件測試對於軟件的質量有明顯的改善做用，起到監督和推進做用，能縮短軟件開發的週期，加快軟件發佈的進程

32.bug的處理流程：

（1）首先是測試人員發現了一個bug並且在bug缺陷管理工具裏沒有相同的bug，就須要填寫相
關的bug信息，並提交給測試經理
（2）若是這個bug不是一個真正的bug, 測試經理須要close這個bug

（3）測試經理須要審查bug的各類信息都完備，若是有信息不完整，他須要把狀態改
成」feedback（反饋）」 並從新發給提交者

（4）若是這個bug是一個真正存在的bug, 測試經理須要把這個bug分配給相關的開發團隊的項
目經理, 而且把bug狀態改爲Assigned（分配）

（5） 項目經理審查bug,而且分配給相應的開發人員去改正。

（6）開發人員收到bug之後，對相關的bug進行改正，而且從新分配給提交bug的測試人員而且
把狀態改爲」Fixed（修復）」

（7）測試人員須要對這個bug進行從新測試，保證相關的缺陷已經改正，測試人員能夠reopen （從新打開）這個bug，若是缺陷依然存在，從新分配給相關的開發人員，bug若是缺陷已經改 正，則關閉這個bug。