軟件測試基礎

軟件測試基礎

一、測試和調試的區別：

　　測試能夠發現因爲軟件缺陷引發的失效。

　　調試是一種開發活動，用來識別引發缺陷的緣由，修改代碼以及驗證是不是否正確地修改了軟件的缺陷。

 

二、軟件測試的定義：

　　使用人工或自動化手段來運行或測試某個系統的過程，其目的在於檢驗它是否知足規定的需求或是弄清預期結果與實際結果之間的差異。

　　依據規範的軟件檢測過程和檢測方法，按照測試計劃和測試需求對被檢測軟件的文檔、程序和數據進行測試的技術活動。

 

三、軟件測試的目的：

　　一、驗證軟件是否知足軟件開發合同或項目開發計劃、系統設計文檔、軟件規格說明、軟件設計說明等規定的軟件質量要求。

　　二、經過測試，發現軟件缺陷。

　　三、爲軟件產品的質量測量和評價提供依據。

 

四、軟件測試的意義：

　　保證發佈出去的產品達到了標準。

 

五、軟件測試工程師的目標：

　　在最短的時間內儘量發現多的缺陷，並保證這些缺陷得以修復。

 

六、軟件測試原則：

　　一、全部的測試都應該追溯到用戶需求。

　　二、儘早啓動測試工做

　　三、應該在測試工做真正開始以前的較短期內就進行測試計劃。

　　四、Pareto法則應用於軟件測試

　　五、測試應該從「小規模」開始，逐步轉向「大規模」。

　　六、爲了達到最佳效果，應該由獨立的第三方來構造測試。

　　七、窮盡測試是不可能的

　　八、軟件測試是有風險的

　　九、測試旨在發現存在的缺陷

　　十、找到的缺陷越多，就說明軟件缺陷越多

　　十一、軟件測試員必須不斷編寫不一樣的、新的測試程序，對程序的不一樣部分進行測試，以找出更多軟件缺陷。

　　十二、並不是全部的軟件缺陷都須要修復。

 

七、軟件開發生命週期模型：

　　大爆炸模型

　　邊寫邊改模型

　　瀑布模型

　　螺旋模型

　　敏捷軟件開發模型

 

八、軟件測試過程模型：

　　v模型：

　　用戶需求—>需求分析—>概要設計—>詳細設計—>編碼—>單元測試—>集成測試—>系統測試—>驗收測試

　　單元測試和集成測試驗證程序設計，檢驗程序的執行是否知足軟件設計的需求。

　　

　　w模型：

　　基於測試的設計和不斷測試的原則，w模型既強調了測試方案設計，也強調了測試執行

　　

　　h模型：

　　真正的測試級別之間不存在嚴格的次序關係，各階段間能夠反覆觸發、迭代、增量。

　　爲了解決V模型和w模型存在的問題，有專家提出了H模型。它將測試活動徹底獨立出來，造成一個徹底獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。

　　x模型：

 

軟件缺陷管理

一、測試人員不能報什麼樣的問題？

　　一、不能報不是問題的bug

　　二、不能報沒法重現的bug

　　三、不能報重複的bug

 

二、軟件缺陷的定義：

　　一、軟件未達到產品說明書標準的功能

　　二、軟件出現了產品說明書指明不會出現的錯誤

　　三、軟件功能超出了產品說明書的指定範圍

　　四、軟件未達到產品說明書雖未指出但應該達到的目標

　　五、軟件測試員認爲軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認爲很差。

 

三、缺陷產生的緣由：

　　一、工期短，任務大

　　二、程序設計錯誤

　　三、文檔不完整

　　四、溝通交流不夠

　　五、軟硬件支持不完善

　　六、軟件的複雜性

　　七、需求不斷變化

 

四、缺陷產生的緣由：

　　一、大部分客戶不懂軟件開發技術，提出的需求不明確，或者提出的需求自己是矛盾的。

　　二、軟件產品的製造商沒法百分百地收集到用戶全部的需求

　　三、在軟件的需求調研和設計階段存在的各類問題會致使用戶需求被錯誤地理解和傳遞

　　四、用戶需求隨着工做或使用環境的變化，以及時間的推移也會隨之改變

　　五、軟件技術的發展落後於不斷複雜的軟件需求

 

五、沒法再現的缺陷應當採起怎樣的處理方法？

　　一、首先，應當對這樣的缺陷進行詳細的記錄，並儘快提交給發開人員

　　二、其次，對於尋找難以再現的缺陷要合理地安排時間，要考慮到測試項目的總體進度，對一時難以再現的缺陷能夠暫時擱置，以保證項目的正常進度。

　　三、最後在測試過程當中對未再現缺陷予以關注

 

六、缺陷報告的寫做準則

　　一、準確：每一個組成部分描述準確，不要引發誤解

　　二、清晰：每一個組成部分的描述清晰，易於理解

　　三、簡潔：只包含必不可少的部分，不包含任何多餘的內容

　　四、完整：包含復現該缺陷的完整步驟和其餘本質信息

　　五、一致：按照一致的格式書寫所有缺陷報告

 

七、缺陷報告的內容有哪些？

　　缺陷的標題；缺陷的基本信息；測試的軟硬件環境；測試的軟件版本；缺陷的類型；缺陷的嚴重程度；缺陷的處理優先級；復現缺陷的操做步驟；缺陷的實際結果描述；指望的正確結果描述；註釋文字和截的缺陷圖像；

 

八、缺陷報告的讀者對象最但願得到的信息包括如下幾點：

　　一、易於搜索軟件測試報告的缺陷；

　　二、報告的軟件缺陷進行了必要的隔離，報告的缺陷信息具體、準確

　　三、軟件開發人員但願得到缺陷的本質特徵和復現步驟

　　四、市場和技術支持等部門但願得到缺陷類型分佈以及對市場和用戶的影響程度。

 

九、編寫缺陷報告的技巧：

　　一、組織

　　二、重現

　　三、隔離

　　四、概括

　　五、對比

　　六、總結

　　七、精簡

　　八、消除歧義

　　九、中立

　　十、檢查

 

十一、缺陷驗證分類：

　　一、致命：因爲程序引發的死機，機器藍屏，非法退出；程序產生的死循環；數據通信錯誤，沒法實時聊天；需求沒有實現

　　二、嚴重：輸入非法數據，程序異常退出，但該錯誤能夠繞過；申請號碼時必填的信息不填，能夠申請成功。聊天時的實時狀態顯示不正確。

　　三、通常：刪除操做韋給出提示，系統操做不方便，界面錯誤

　　四、較小錯誤：長時間操做未給出用戶進度提示，提示窗口不夠友好，用了專業術語

 

十二、缺陷管理的目的：

　　一、對個階段測試發現的缺陷進行跟蹤管理，以保證各級缺陷的修復率達到標準。主要實現如下目標：

　　　　及時瞭解並跟蹤每一個被發現的缺陷

　　　　確保每一個被發現的缺陷都能被處理

　　　　收集缺陷數據，並在其上進行數據分析，做爲組織過程的財富

 

1三、測試人員職責：

　　一、高級經理（EM）

　　　　裁決項目經理與測試組長有爭議的缺陷

　　二、項目經理（PM）

　　　　判斷是不是缺陷

　　　　負責指派缺陷給相關負責人

　　三、項目測試組長（TM）

　　　　決定缺陷管理方式和工具

　　　　管理缺陷狀態狀況

　　　　審覈測試人員提交的缺陷

　　　　對測試人員的工做質量進行跟蹤和評價

　　四、測試人員（TE）

　　　　編寫測試用例

　　　　負責缺陷的提交、跟蹤以分析

　　　　負責執行系統迴歸測試

　　　　提交週報、月報

　　五、項目相關開發人員（DE）

　　　　修復測試發現的缺陷

　　　　負責跟蹤修復缺陷的狀態

　　六、質量保證人員（SQA）

　　　　監控項目組缺陷管理規程執行狀況

 

1四、缺陷的狀態：

　　一、Submitted　　以提交　　以提交的缺陷

　　二、Open　　　　打開　　    確認「提交的缺陷」，等待處理

　　三、Rejected　　  以決絕　　拒絕「提交的缺陷」，不須要修復或不是缺陷

　　四、Resolved　　以解決　　  缺陷被修復

　　五、Close　　　　已關閉　　確認被修復的缺陷，將其關閉

 

1五、缺陷的來源

　　一、Requirement　　因爲需求的問題引發的缺陷

　　二、Architecture　　 因爲架構的問題引發的缺陷

　　三、Design　　　　  因爲設計的問題引發的缺陷

　　四、Code　　　　　 因爲編碼的問題引發的缺陷

　　五、Test　　　　　　因爲測試的問題引發的缺陷

　　六、Integration　　　因爲集成的問題引發的缺陷

 

軟件測試過程

一、測試計劃編寫的依據

　　需求文檔，開發計劃，設計計劃

 

二、測試人員參加需求分析工做，帶來的好處

　　一、測試工程師參與需求分析，對需求瞭解很深入，減小了不少與開發人員的交互，節省了時間

　　二、早期肯定測試用例的編寫思路，爲測試打好了基礎

　　三、能夠獲取有些測試數據，爲測試用例設計提供幫助

　　四、能夠發現需求不合理的地方，下降了測試成本

 

三、如何編寫測試用例

　　一、採起SRS模板

　　二、指明需求的來源

　　三、爲每項需求註上標號

　　四、記錄業務規範

　　五、建立需求跟蹤能力矩陣

 

四、參與軟件需求評審都有哪些人員？

　　產品經理、項目經理、測試經理、開發人員、測試人員、高級經理、qa

 

五、測試用例是百分百的可以覆蓋需求的，可是不能百分百的發現全部的缺陷；若是咱們發現的缺陷不包含測試用例的話，解決方案是更新測試用例。

 

六、如何針對需求變動的項目進行測試？

　　組織一個由項目分析承擔者組成的小組做爲變動控制委員會，由他們來肯定進行哪些需求變動，此變動是否在項目範圍內，評估它們，並對此評估作出決策，已肯定選擇哪些，放棄哪些，並設置實現的優化順序，制定目標版本。

 

七、項目需求變動是由pmo項目管理組織它們來把控，咱們只負責變動後的需求的·測試，同時也要兼顧總體流程的測試。

 

八、測試計劃是由測試組長和測試經理來編寫的，測試人員負責執行。可是測試計劃不是一成不變的，要根據產品需求不斷變化來變化的；測試計劃是在開發計劃完成後編寫，參考依據：需求文檔、設計文檔、開發計劃

 

九、測試計劃的定義

　　一個敘述了預約的測試活動的範圍、途徑、資源已進度安排的文檔。它確認了測試項、被測特徵、測試任務、人員安排，以及任何偶發事件的風險。

 

十、軟件測試計劃的目的？

　　規定測試活動的範圍、方法、資源和進度；明確正在測試的項目、要測試的特徵、要執行的測試任務、每一個任務的負責人，以及與測試相關的分析。

 

十一、測試的時間很緊迫，如何來合理安排時間測試項目？

　　先對項目的重要功能進行測試，可以保證項目能夠暢通進行，保證項目不會出現404,500等嚴重頁面錯誤，而後再對項目其餘模塊測試，保證項目總體沒有大缺陷。

 

十二、測試結束後輸出的文檔有哪些？

　　一、測試計劃

　　二、測試用例

　　三、缺陷報告

　　四、測試報告

 

軟件測試級別、類型及方法

一、單元測試

　　對單個的軟件單元或者一組相關的軟件單元所進行的測試，時代碼級別的測試。好比：函數、源代碼文件、類。

 

二、集成測試

　　集成測試是對組件之間的接口進行測試，以及測試應該系統內不一樣部分的相互做用，好比操做系統、文件系統、硬件或系統之間的接口。

　　一種旨在暴露接口以及集成組件/系統間交互時存在的缺陷的測試。

　　測試的目的是發現接口的缺陷和集成後組件協同工做時的缺陷（若是操做系統的接口，與文本系統或硬件的接口）

 

三、系統測試

　　系統測試關注的是在開發項目或程序中定義的一個完整的系統/產品的行爲。

　　測試集成系統以驗證它是否知足指定需求的過程

　　一個集成測試的基於風險測試，爲的是確認此係統知足了特定的功能性和非功能性的需求。測試環境應儘量與之後的目標環境保持一致。

 

四、系統測試基於哪幾個方面？

　　基於需求的測試

　　基於業務流程的測試

　　用例測試

 

五、驗收測試

　　驗收測試一般是由使用系統的用戶或客戶來進行，同時系統的其餘利益相關者也可能參與其中。測試軟件是否達到需求說明書、開發說明書等標準。

 

六、Alpha測試和Beta測試

　　Alpha測試：潛在的客戶/用戶在開發場地進行的測試

　　Beta測試：由潛在客戶/用戶在他本身的環境下測試軟件系統

　　測試目的是識別在未知的或非指定的應用環境下對系統的影響。

 

七、維護測試

　　維護測試的任務是，針對運行系統的更改，或者新的環境對運行系統的影響而進行的測試。

　　一般維護測試是經過一個系統的修改、移植或退役時才才進行的測試。

　　維護：

　　　　　　計劃中的功能加強

　　　　　　糾正和應急更改

　　　　　　環境的變化好比計劃的操做系統或數據升級

　　　　　　或因爲新發現或暴露的操做系統漏洞而打的補丁

　　移植：

　　　　　　新環境的運行測試

　　　　　　對變動之後的軟件運行測試

　　退役：

　　　　　　數據移植測試

　　　　　　存在測試（若是須要長時間的數據保存）

 

八、其餘測試包括哪些：

　　負載

　　性能、效率

　　壓力

　　可用性，用戶的友好性

　　可靠性，穩定性

　　可移植性，互操做性

　　健壯性，可恢復性

　　安全性

　　容量

　　文檔

　　配置

　　兼容性，數據轉載

　　易變性

　　國際化/本地化

 

九、迴歸測試

　　對之前已經測試過·的·版本或者通過修改的程序進行從新測試，以保證修改沒有引入新的錯誤或者因爲修改發現之前未發現的錯誤。

　　

十、測試類型

　　功能測試：測試軟件項的功能特徵，功能指的是系統能作什麼

　　非功能測試：軟件測試項的非功能特性，非功能指系統工做的怎樣

　　結果測試：經過評估結果類型的覆蓋，來測量測試對完整性

 

十一、黑盒測試、白盒測試

　　黑盒測試：黑盒測試又稱爲功能測試或邏輯驅動測試，是從用戶觀點出發，主要以軟件規格說明書爲依據，對程序功能和程序接口進行的測試。

　　白盒測試：也稱結構測試或邏輯驅動測試。檢查程序中的每條通路是否都按照預約要求正確工做；須要徹底瞭解程序結構和處理過程。

 

十二、測試方法

　　一、靜態測試方法
　　　　針對代碼

　　二、動態測試方法

　　　　動態測試方法通常採起白盒測試和黑盒測試方法

 

1三、黑盒測試的方法：

　　功能分解

　　等價類劃分

　　邊界值分析

　　因果圖

　　斷定表

　　隨機測試

　　猜錯法

　　正交實驗法

 

1四、什麼是等價類劃分？

　　等價類劃分是一種重要的、經常使用的黑盒測試方法，不須要考慮程序內部結構，指須要考慮程序的輸入規格便可。它將不能窮舉的測試過程進行合理分類，從而保證設計出來的測試用例具備完整性和表明性。

　　有效等價類：指符合《需求規格說明書》，輸入合理的數據集合

　　無效等價類：指不符合《需求規格說明書》，輸入不合理的數據集合。

 

1五、什麼是邊界值

　　邊界是針對於輸入等價類和輸出等價類而言，稍高於其邊界值及稍低於其邊界值的一些特殊狀況。

 

1六、場景法

　　基本流：按照正確的業務流程來實現一條操做路徑（模擬正確的操做流程）

　　備選流：致使出現錯誤的操做流程（模擬錯誤的操做流程）

 

1七、流程分析法

　　流程分析法主要是針對測試場景類型屬於流程測試場景的測試環境下的測試子項進行設計，是從白盒測試方法中的路徑覆蓋分析法借鑑過來的一種方法。

 

1八、軟件測試計劃包括什麼？

　　測試項，被測特徵，測試任務，人員安排，以及任何偶發事件的風險。

　　

軟件測試流程

　　一、項目立項（公司高層、架構師、產品經理、總經理、總監、老闆、公司的商務）

　　二、商務談判（跟客戶進行談判，簽定合同  ——  軟件開發業務模塊，報價）正式啓動

　　三、需求分析（產品經理 —> 需求調研—>產品的初稿—>產品需求說明書—>通過開會討論最終定稿造成完整的產品需求說明書）

　　四、需求評審（產品經理、項目經理、測試經理、開發人員、測試人員、ui）

　　五、測試計劃（測試組長或者測試經理，測試計劃不是一成不變的，要通過屢次的迭代，比較完善測試計劃需求不斷進行修改和評審）

　　六、測試用例（測試人員，依據是產品需求說明書、設計文檔、demo）測試用例不能發現全部的缺陷可是必定要覆蓋全部的需求，經過評審的方式來完善測試用例

　　七、搭建項目環境（測試環境獨立）

　　八、冒煙測試（咱們在開始正式執行測試的時候由1-2名測試人員進行10-15分鐘的冒煙測試，主要是測試業務流程是否完善、界面不要報500,404的錯誤），若是出現這些問題就不能正常的開展工做，反饋給主管，由主管反饋給項目經理進行修復。

　　九、正式執行測試（執行測試用例，發現bug，報bug）

　　十、確認測試（項目經理分配bug給開發進行修改）

　　十一、迴歸測試（測試人員針對開發修復bug訂單版本進行驗證，經過關閉，不經過返回開發繼續修改直到經過關閉掉缺陷）

　　十二、測試報告

 

二、測試用例的特色：

　　能夠最大限度地找出軟件隱藏的缺陷

　　能夠最高效率地找出軟件缺陷

　　能夠最大程度地知足測試覆蓋需求

　　既不過度複雜，也不過度簡單

　　使軟件缺陷的表現能夠清楚的斷定

　　　　測試用例包含指望的正確結果

　　　　待查的輸出結果或文件必須簡單明瞭

　　不包含重複的測試用例

　　測試用例內容清晰、格式一致、分類組織

 

三、測試用例的元素

　　一個測試用例包含了以下部分：對一個特定的測試對象，在規定的條件或環境下（前置條件和後署部分），輸入一組數據或執行操做步驟後，生成一組相對應的指望的結果。

　　測試目標：爲何而測試？功能、性能、可用性、兼容性、容錯性、安全性等

　　測試對象：測試什麼？被測試的項目，如對象、函數、類、菜單、按鈕、表格、接口、整個系統等。

　　測試環境：在哪裏測試？測試用例運行時所處的環境，包括系統的配置和設定等要求，也包括操做系統、瀏覽器、通信協議等單機或網絡環境。

　　測試前提：何時能夠測？測試用例運行時所處的前提或條件限制。

　　輸入數據：哪些數據？在操做時，系統所接受的各類可變化的數據，如數字、字符、文件等。

　　操做步驟：而後測？執行軟件和程序的前後次序步驟等。如打開對話框、點擊按鈕等。

 

四、測試用例設計準則

　　基於測試需求的準則。應按照測試類別的不一樣要求，設計測試用例。

　　基於測試方法的原則。應明確所採起的測試用例設計方法。

　　兼顧測試充分性和效率的原則。

　　測試執行的可再現性原則。

 

五、如何保證測試用例的質量？

　　首先，要對用戶需求、服務質量要求、產品特性有深入且全面的理解

　　其次，採起正確、恰當的方法進行用例設計。

　　再者，按照測試用例的標準格式或規範的模板來書寫測試用例。

　　除此以外，對測試用例的檢查、評審，也是一種提升測試用例質量的主要有效手段。