軟件測試流程2

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

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

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

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

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

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

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

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

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

10、完整、有效模擬驗(yàn)收測試的要求,檢查系統(tǒng)是否符合用戶的驗(yàn)收標(biāo)準(zhǔn)時機(jī):多數(shù)集成測試完成后方法:黑盒測試責(zé)任:測試工程師1.5.驗(yàn)收測試目標(biāo):使客戶驗(yàn)收簽字系統(tǒng)是否符合事先約定的驗(yàn)收標(biāo)準(zhǔn)時機(jī):系統(tǒng)測試完成后,在項(xiàng)目組看來開發(fā)和測試工作已經(jīng)全部完成,可以交付使用方法:黑盒測試責(zé)任:產(chǎn)品經(jīng)理或其他高級經(jīng)理開發(fā)工程師測試工程師用戶1.6.測試與測試(beta 測試)測試是由用戶在開發(fā)環(huán)境下進(jìn)行的測試,也可以是開發(fā)機(jī)構(gòu)內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的測試。測試可以在軟件編碼結(jié)束時開始,或在模塊(子系統(tǒng))測試完成后開始,也可在確認(rèn)測試過程中軟件達(dá)到一定的穩(wěn)定和可靠程度之后再開始。EmxvxOtOco測試需

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

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

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

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

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

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

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

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

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

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

21、發(fā)現(xiàn)的錯誤類型:語法錯誤編譯錯誤Memory leakPerformance problem邏輯問題判定條件問題編程規(guī)范測試技術(shù)基本路徑控制結(jié)構(gòu)基本路徑測試,如下圖所示:優(yōu)缺點(diǎn)比較,如下圖所示:靜態(tài)測試與動態(tài)測試:靜態(tài)測試(Static testing):不實(shí)際運(yùn)行被測試的程序測試對象:軟件文檔(用戶類,開發(fā)類)源代碼(邏輯錯誤,代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格)分類:代碼走查(walkthrough)代碼審查(Inspection)技術(shù)評審(Review)動態(tài)測試(Dynamic Testing):通過執(zhí)行軟件的手段來測試軟件靜態(tài)測試技術(shù):代碼走查(walkthrough)開發(fā)組內(nèi)部進(jìn)行的,采用講解、討

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