1、軟件測試流程1.軟件測試流程1.1.軟件測試整體流程首先看一下軟件生命周期。軟件開發全部過程、活動和任務的結構框架,是從可行性研究到需求分析,軟件設計,編碼,測試,軟件發布維護的過程。如下圖所示:b5E2RGbCAP在學習軟件測試整體流程的過程中,我們要明確這樣幾個問題:測試計劃的前期是否需要需求調研?測試具體分幾個階段,每個階段執行的依據是什么?每個階段的作用是什么?每個階段都需要生成哪些文檔,這些文檔對整個測試工作和產品的質量保障起到哪些作用?測試工作的各個階段:軟件測試工作必須要通過計劃測試、設計測試、執行測試、評估測試幾個階段來完成。計劃測試階段需要整理測試需求、制定測試計劃;設計測試

2、階段要設計測試用例和測試過程,要保證測試用例完全覆蓋測試需求;要根據測試用例實現具體的自動化腳本或者手工的操作步驟;p1EanqFDPw執行測試階段則通過自動化測試工具或人手工來執行那些自動化腳本或手工的操作步驟;評估階段則要對軟件的質量和測試工作自身的質量做出一個客觀的評價。軟件測試的整體流程具體如下圖所示:需求階段:設計編碼階段:集成、系統、驗收階段:開發生命周期中的驗證活動:軟件測試流程,集成、系統、驗收如下圖所示:1.2.單元測試目標:檢驗程序最小單元有無錯誤(類、文件、窗口、函數、菜單、報表或一個存儲過程)接口、數據結構、邊界、覆蓋、邏輯檢驗單元編碼與設計十分吻合依據:詳細設計,編碼

3、方法:白盒測試測試執行人:開發工程師進入條件:代碼無錯誤地通過編譯或匯編。測試內容:(1) 模塊接口:對被測模塊,信息是否能正確地流入和流出。(2) 局部數據結構:模塊的工作過程中,其內部的數據能否保持其完整性。(3) 邊界條件-在邊界上模塊是否能正常工作。(4) 覆蓋條件-模塊的運行是否達到了規定的邏輯覆蓋。(5) 出錯處理-檢查模塊的錯誤處理設施是否有效。具體要求:(1) 在進行單元測試之前,由項目負責人決定是否進行靜態分析。(2) 單元測試的主要形式是結構測試。(3) 單元測試的測試計劃應該根據被測單元的性質而制訂:如對系統控制單元應主要采用結構測試;對復雜的計算單元應主要采用算法分析測

4、試用例;對界面單元就應該測試各種選項的組合。DXDiTa9E3d(4) 語句覆蓋率應達到100%。(5) 分支覆蓋率應達到85%。(6) 單元測試由開發部負責開展。單元測試執行:在進行單元測試時,需設置若干輔助測試模塊。輔助模塊有兩種:一種是驅動模塊(Driver),用以模擬被測試模塊的上級模塊。另一種是樁模塊(Stub),用以模擬被測模塊工作過程中所調用的模塊。驅動模塊和樁模塊都是“替身”模塊,而不是軟件產品的真正組成的部分。下圖顯示了一般的單元測試環境。單元測試一般由開發設計人員本身完成。一般由開發組在組長的監督下進行,由編寫該單元的開發設計者設計所需的測試用例和測試數據,來測試該單元并修

5、改缺陷。RTCrpUDGiT開發組組長負責保證使用合適的測試技術,在合理的質量控制和監督下執行充分的測試。1.3.集成測試將經過單元測試的模塊按設計要求組裝起來,組合成所規定的軟件系統的過程稱為“集成”。目標:檢驗組成系統的模塊接口有無錯誤代碼實現的系統設計與需求定義是否吻合時機:主要的單元測試完成后,經常與單元測試同步進行方法:黑盒測試,白盒測試責任:開發工程師、測試工程師集成測試重點:1、各個模塊連接起來后,穿過模塊接口的數據是否會丟失,是否能夠按期望值傳遞給另外一個模塊;2、各個模塊連接起來后,需要判斷是否仍然存在單元測試時所沒發現的資源競爭問題;3、分別通過單元測試的子功能模塊集成到一

6、起能否實現所期望的父功能;4、兼容性,檢查引入一個模塊后,是否對其他與之相關的模塊產生負面影響;5、全局數據結構是否正確,是否被不正常的修改;6、集成后,每個模塊的誤差是否會累計擴大,是否會達到了不可接受的程度。集成測試方式:將模塊連接起來組成一個可運行的系統,有兩種方法;非漸增式測試和漸增式測試。(1)非漸增式測試(Non-incremental testing)當每個模塊都進行單元測試后,按照軟件結構要求把所有模塊連接起來織成一個完整的程序,對全程序進行測試。這種測試方法叫非漸增式測試。5PCzVD7HxA例如,有一塊系統結構,如圖(a)所示,其單元測試和集成順序如圖(b)所示。模塊d1、

7、d2、d3、d4、d5是對各個模塊做單元測試時建立的驅動模塊,s1、s2、s3、s4、s5是為單元測試而建立的樁模塊。jLBHrnAILg這種一次性集成方式將所測模塊連接起來進行測試,但是一次試運行成功地可能性并不大。其結果如果存在錯誤,不易找到原因,查錯和改錯都會遇到困難。xHAQX74J0X(2)漸增式集成方式逐次將未曾測試的模塊和已測試的模塊(或子系統)結合成程序包,然后將這些模塊集成為較大系統,在集成的過程中邊連接邊測試,以發現連接過程中產生的問題。最后逐步集成為要求的軟件系統。LDAYtRyKfE根據集成的過程又可以分為自頂向下集成自底向上集成三明治”集成法自頂向下的集成方式這種集成

8、方式是將模塊按系統的程序結構,沿控制層次自頂向下進行集成。步驟:(1)以主模塊為所測模塊兼驅動模塊,所有直屬于主模塊的下屬模塊全部用樁模塊進行模擬測試。(2)采用深度優先或寬度優先的策略,用實際模塊替換相應樁模塊,再用樁代替它們的直接下屬模塊,與已測試的模塊或子系統集成為新的子系統。如下圖Zzz6ZB2Ltk(3)進行回歸測試(即重新執行以前做過的全部測試或部分測試),排除集成過程中引起錯誤的可能。(4)判斷是否所有的模塊都已集成到系統中,是則結束測試,否則轉到(2)去執行。自底向上的集成方式這種集成的方式是從程序模塊結構的最底層的模塊開始集成和測試。因為模塊是自底向上進行集成,對于一個給定的

9、模塊,它的子模塊(包括子模塊的所有下屬模塊)已經集成并測試完成,所以不再需要樁模塊。自底向上集成的步驟如下:dvzfvkwMI1(1)由驅動模塊控制最底層模塊的并行測試,也可以把最底層模塊組合成實現某一特定軟件功能的簇,由驅動模塊控制它進行測試。rqyn14ZNXI(2)用實際模塊代替驅動模塊,與它已測試的直屬子模塊集成為子系統。(3)為子系統配備驅動模塊,進行新的測試。(4)判斷是否已集成到達主模塊,是否結束測試,否則執行(2)。下圖說明自底向上集成和測試的順序:1.4.系統測試目標:檢驗組成整個系統的代碼、以及系統的軟硬件配合有無錯誤代碼實現的系統與用戶需求是否吻合檢驗系統的文檔等各種是否

10、完整、有效模擬驗收測試的要求,檢查系統是否符合用戶的驗收標準時機:多數集成測試完成后方法:黑盒測試責任:測試工程師1.5.驗收測試目標:使客戶驗收簽字系統是否符合事先約定的驗收標準時機:系統測試完成后,在項目組看來開發和測試工作已經全部完成,可以交付使用方法:黑盒測試責任:產品經理或其他高級經理開發工程師測試工程師用戶1.6.測試與測試(beta 測試)測試是由用戶在開發環境下進行的測試,也可以是開發機構內部的用戶在模擬實際操作環境下進行的測試。測試可以在軟件編碼結束時開始,或在模塊(子系統)測試完成后開始,也可在確認測試過程中軟件達到一定的穩定和可靠程度之后再開始。EmxvxOtOco測試需

11、要開發人員參與。測試是由軟件用戶在實際使用環境下進行的測試。這些用戶通常是與公司簽定了一定合同的外部用戶,用戶在使用該產品時愿意返回有關錯誤信息給開發者。SixE2yXPq5測試時,開發人員不在測試現場。只有當測試達到一定可靠程度時,才能開始測試。測試通常由主持產品發行的人員來管理。測試和測試區別測試盡量模擬用戶的使用環境測試真實用戶的使用環境測試開發方測試測試最終用戶測試問題:Beta測試屬于驗收測試嗎答:是!所謂驗收測試(acceptance test)是在產品發布之前所進行的軟件測試活動, 它是技術測試的最后一個階段,通過了驗收測試,產品就會進入發布階段.6ewMyirQFL、測試事實上

12、,軟件開發人員不可能完全預見用戶實際使用程序的情況。例如,用戶可能錯誤的理解命令,或提供一些奇怪的數據組合,亦可能對設計者自認明了的輸出kavU42VRUs信息迷惑不解,等等。因此,軟件是否真正滿足最終用戶的要求,應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試,也可以有計劃、有系統的測試。測試過程總結,如下圖所示:2.常用測試技術首先看一下軟件測試的分類:按測試階段分類單元測試、集成測試、系統測試、驗收測試按測試策略分類黑盒/白盒測試、動態/靜態測試、手工/自動測試按測試技術方法分類功能測試、性能測試、壓力測試、易用性測試、安裝測試、容錯性測試、兼容性測試、安全性測試黑盒測試/白

13、盒測試-從要不要看代碼來區分動態測試/靜態測試-從要不要運行軟件來區分而常用的測試技術如下圖所示:2.1.功能測試功能測試:使用測試應用系統的功能需求的黑盒測試方法。這類測試應由測試員做,這并不意味著程序員在發布前不必檢查他們的代碼能否工作。運行系統,查看其功能是否正常實現,是否滿足需求。對于需求沒有涵蓋,但功能實現上不合理的地方(從用戶角度考慮)與項目經理溝通,進行系統完善。y6v3ALoS89功能測試參考:參考需求分析、規格說明書、測試計劃、測試用例等文檔多與開發人員、用戶及其他項目相關人員溝通功能測試的控件操作,如下圖所示:控件中文本框測試:從輸入數據的內容,長度,類型,格式等幾個方面來

14、考慮。文本框如下圖所示:控件中按鈕測試:按鈕功能是否實現提示信息是否正確對于不符合業務背景的輸入數據是否有相應的處理按鈕如下圖所示:控件中單選框測試:單選按鈕是否同時只能選中一個各單選按鈕功能是否能正確完成是否有默認被選中的選項單選框如下圖所示:控件中updown+文本框測試:上下箭頭的控制邊界值的測試默認值的測試非法輸入字符的測試如下圖所示:控件中組合列表框測試:條目內容的檢查條目功能的是否實現列表框中是否能輸入數據控件中復選框測試:多個復選框可以同時選中。多個復選框可以被部分選中。多個復選框可以都不被選中。例如,即不選輪廓,也不選陰影字體逐一執行每個復選框的功能。每個復選框都可能有三種狀態

15、:選中、未選中和部分選中。控件中列表框測試:條目內容正確。逐一執行列表框中每個條目的功能。列表框內容多要使用滾動條。列表框允許多選時,要分別檢查按Shift選中條目、按Ctrl選中條目和直接用鼠標選中多項條目。列表框如下圖所示:控件中滾動條測試:滾動條是否能拖動滾動條拖動時屏幕刷新情況滾動條拖動時顯示信息的顯示滾動條的上下按鈕是否可用如下圖所示:控件組合操作:即各種控件的組合使用:控件間的相互作用Tab鍵的順序熱鍵的使用回車鍵和ESC鍵的使用控件組合后功能的實現如下圖所示:對登錄操作測試如下圖所示:輸入正確的用戶名和密碼,點“確定”,用戶可以正確登錄輸入不正確的用戶名,正確的密碼,點“確定”。

16、系統提示錯誤。輸入正確的用戶名,不正確的密碼,點“確定”。系統提示錯誤。輸入不正確的用戶名,不正確的密碼,點“確定”。系統提示錯誤。輸入三次錯誤的登錄信息,自動退出。輸入允許的最大長度為20個字符的用戶名和最大長度為20個字符的密碼,可以正確登錄輸入超過允許的最大長度的用戶名和最大長度的密碼。系統提示錯誤。進入登錄界面,接受默認值,什么都不輸入,直接按確定輸入特殊字符。例如,輸入正確用戶名,按Backspace或Delete鍵刪除用戶名,再次輸入用戶名;或者輸入ASCII表中的不可顯示的字符如NUL,LF等。M2ub6vSTnP點“取消”,退出程序。入正確的用戶名或密碼,點“取消”退出程序后,

17、再次進入登錄界面直接按確定。檢查程序的默認值是否改變密碼顯示為*,不能顯示為輸入的具體字母或數字Tab鍵的順序為用戶、密碼、確定、取消文件操作打開文件測試:打開在任意位置的文件以各種方式打開文件打開任意格式的文件打開文件對話框中的各按鈕如下圖所示:文件操作保存文件測試:在任意位置保存文件以各種方式保存文件保存任意格式的文件保存文件對話框中的各按鈕如下圖所示:文件操作保存文件測試:正常關閉文件,系統提供確認信息。通過菜單或窗口按鈕關閉。非正常關閉。文件操作打印文件測試:本地打印和網絡打印是否能完成打印界面的各屬性的設置打印界面的各按鈕功能是否能實現如下圖所示:編輯操作測試:查找、搜尋中考慮輸入的

18、內容和長度替換中考慮輸入的內容和長度編輯操作窗體的功能測試如下圖所示:插入操作測試:復制操作測試:鼠標測試:如何進行測試:左右鍵操作是否能完成單擊、雙擊、三擊是否能完成拖放、滾輪等功能是否能完成移動、點擊的速度如下圖所示:2.2.界面測試窗體需要測試:窗體大小移動窗體縮放窗體顯示分辨率狀態欄工具欄錯誤信息父窗口子窗口如下圖所示:控件界面測試案例:控件界面測試檢查列表:菜單界面測試:菜單界面測試檢查清單,如下圖所示:特殊屬性檢查清單,如下圖所示:界面設計總體原則:界面的長寬比例按鈕的大小背景的搭配顏色的搭配測試技術小結:測試用例設計的目的是導出可能發現錯誤的測試集測試case設計的技術主要是白盒

19、和黑盒白盒測試注重程序的結構,是小規模的低層測試黑盒測試注重需求的實現,是大規模的高層測試還有大量的特定軟件系統的測試方法,需要專門的測試技術和指南測試永無止境,設計測試case最終目的是為了盡量多的發現問題,在產品發布前解決文檔測試技術小結:文檔測試審查單:術語:用戶是否理解;是否需要定義;是否標準、前后一致標題:是否合適,是否和實際產品一致內容:功能描述正確、清晰逐步執行:確保所有信息真實正確和實際產品功能一致;檢查搜索的正確性;檢查網站URL 能否正確鏈接圖表和拷屏:圖表準確;拷屏版本一致;圖表標題正確示例:對文檔中示例要載入并使用,保證其可以正確執行錯別字:無錯別字,標點符號正確排版:

20、排版正確,風格一致設計易用性測試用例:實例分析:優秀界面的特點:符合標準和規范直觀性一致性靈活性舒適性正確性實用性3.軟件測試策略我們無法為軟件做窮舉測試,存在著組合爆炸的情況。軟件測試中的“殺蟲劑”現象。我們無法修復所有發現的錯誤。黑盒測試黑盒測試是對需求的所有輸入條件進行測試黑盒測試發現的錯誤類型功能不對或遺漏界面錯誤數據結構或外部數據庫訪問錯誤性能錯誤初始化和終止錯誤黑盒測試關注點:功能:如何測試功能的有效性何種類型的輸入會產生好的測試用例系統是否對特定的輸入值敏感數值:如何分隔數據類的邊界系統能夠承受何種數據率和數據量特定類型的數據組合會對系統產生何種影響界面性能其他白盒測試:白盒測試

21、發現的錯誤類型:語法錯誤編譯錯誤Memory leakPerformance problem邏輯問題判定條件問題編程規范測試技術基本路徑控制結構基本路徑測試,如下圖所示:優缺點比較,如下圖所示:靜態測試與動態測試:靜態測試(Static testing):不實際運行被測試的程序測試對象:軟件文檔(用戶類,開發類)源代碼(邏輯錯誤,代碼標準/規范/風格)分類:代碼走查(walkthrough)代碼審查(Inspection)技術評審(Review)動態測試(Dynamic Testing):通過執行軟件的手段來測試軟件靜態測試技術:代碼走查(walkthrough)開發組內部進行的,采用講解、討

22、論和模擬運行的方式進行的查找錯誤的活動代碼審查(Inspection)0YujCfmUCw開發組內部進行的,采用講解、提問并使用Checklist方式進行的查找錯誤的活動。一般有正式的計劃、流程和結果報告eUts8ZQVRd技術評審(Review)開發組、測試組和相關人員(QA、產品經理等)聯合進行的,采用講解、提問并使用Checklist方式進行的查找錯誤的活動。一般有正式的計劃、流程和結果報告sQsAEJkW5T黑盒測試與白盒測試:白盒測試(White Box Testing)又稱結構測試,邏輯驅動測試或基于程序的測試深入到代碼一級的測試,使用這種技術發現問題最早,效果也是最好的。但效率很低。這一階段測試以軟件開發人員為主,在JAVA 平臺使用Xunit 系列工具進