軟件測試流程

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

2、例和測試過程，要保證測試用例完全覆蓋測試需求；要根據(jù)測試用例實現(xiàn)具體的自動化腳本或者手工的操作步驟； 執(zhí)行測試階段則通過自動化測試工具或人手工來執(zhí)行那些自動化腳本或手工的操作步驟； 評估階段則要對軟件的質(zhì)量和測試工作自身的質(zhì)量做出一個客觀的評價。軟件測試的整體流程具體如下圖所示：需求階段：設(shè)計編碼階段：集成、系統(tǒng)、驗收階段：開發(fā)生命周期中的驗證活動：測試過程中文檔如下表所示：測試階段編寫人員編寫依據(jù)生成文檔測試計劃測試經(jīng)理或測試組長需求規(guī)格說明書或界面原型測試計劃測試設(shè)計測試設(shè)計人員需求規(guī)格說明書或界面原型測試用例設(shè)計測試策略測試實施測試執(zhí)行人員需求規(guī)格說明書 測試用例缺陷報告測試評估測試經(jīng)理

3、或測試組長測試總結(jié)報告測試階段與測試類型如下表所示：測試階段測試類型執(zhí)行人員單元測試模塊功能測試，包含部分接口測試、路徑測試開發(fā)人員集成測試接口測試、路徑測試、含部分功能測試開發(fā)人員，測試人員系統(tǒng)測試功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試測試人員驗收測試對于實際項目基本同上，并包含文檔測試；對于軟件產(chǎn)品主要測試相關(guān)技術(shù)文檔測試人員，可能包含用戶軟件測試流程，集成、系統(tǒng)、驗收如下圖所示：1.2. 單元測試目標(biāo)： 檢驗程序最小單元有無錯誤（類、文件、窗口、函數(shù)、菜單、報表或一個存儲過程）u 接口、數(shù)據(jù)結(jié)構(gòu)、邊界、覆蓋、邏輯 檢驗單元編碼與設(shè)

4、計十分吻合依據(jù)：詳細(xì)設(shè)計，編碼方法：白盒測試測試執(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)行單元測試之前，由項目負(fù)責(zé)人決定是否進(jìn)行靜態(tài)分析。(2) 單元測試的主要形式是結(jié)構(gòu)測試。(3) 單元測試的測試計劃應(yīng)該根據(jù)被測單元的性質(zhì)而制訂：如對系統(tǒng)控制單元應(yīng)主要采用結(jié)構(gòu)測試；對復(fù)雜

5、的計算單元應(yīng)主要采用算法分析測試用例；對界面單元就應(yīng)該測試各種選項的組合。(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è)計所需的測試用例

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

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

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

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

10、再需要樁模塊。自底向上集成的步驟如下：（1）由驅(qū)動模塊控制最底層模塊的并行測試，也可以把最底層模塊組合成實現(xiàn)某一特定軟件功能的簇，由驅(qū)動模塊控制它進(jìn)行測試。（2）用實際模塊代替驅(qū)動模塊，與它已測試的直屬子模塊集成為子系統(tǒng)。（3）為子系統(tǒng)配備驅(qū)動模塊，進(jìn)行新的測試。（4）判斷是否已集成到達(dá)主模塊，是否結(jié)束測試，否則執(zhí)行（2）。下圖說明自底向上集成和測試的順序：1.4. 系統(tǒng)測試目標(biāo)： 檢驗組成整個系統(tǒng)的代碼、以及系統(tǒng)的軟硬件配合有無錯誤 代碼實現(xiàn)的系統(tǒng)與用戶需求是否吻合 檢驗系統(tǒng)的文檔等各種是否完整、有效 模擬驗收測試的要求，檢查系統(tǒng)是否符合用戶的驗收標(biāo)準(zhǔn)時機(jī)：多數(shù)集成測試完成后方法：黑盒測試責(zé)

11、任：測試工程師1.5. 驗收測試目標(biāo)： 使客戶驗收簽字 系統(tǒng)是否符合事先約定的驗收標(biāo)準(zhǔn)時機(jī)：系統(tǒ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)部的用戶在模擬實際操作環(huán)境下進(jìn)行的測試。 測試可以在軟件編碼結(jié)束時開始，或在模塊（子系統(tǒng)）測試完成后開始，也可在確認(rèn)測試過程中軟件達(dá)到一定的穩(wěn)定和可靠程度之后再開始。 測試需要開發(fā)人員參與。 測試是由軟件用戶在實際使用環(huán)境下進(jìn)行的測試。這些用戶通常是與公司簽定了一定合同的外

12、部用戶，用戶在使用該產(chǎn)品時愿意返回有關(guān)錯誤信息給開發(fā)者。 測試時，開發(fā)人員不在測試現(xiàn)場。 只有當(dāng)測試達(dá)到一定可靠程度時，才能開始測試。 測試通常由主持產(chǎn)品發(fā)行的人員來管理。 測試 和測試區(qū)別n 測試盡量模擬用戶的使用環(huán)境測試真實用戶的使用環(huán)境n 測試開發(fā)方測試 測試最終用戶測試 問題：Beta測試屬于驗收測試嗎 答：是！ 所謂驗收測試(acceptance test)是在產(chǎn)品發(fā)布之前所進(jìn)行的軟件測試活動, 它是技術(shù)測試的最后一個階段,通過了驗收測試，產(chǎn)品就會進(jìn)入發(fā)布階段. 、測試 事實上，軟件開發(fā)人員不可能完全預(yù)見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，

13、亦可能對設(shè)計者自認(rèn)明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進(jìn)行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。 測試過程總結(jié)，如下圖所示：2. 常用測試技術(shù)首先看一下軟件測試的分類：l 按測試階段分類 單元測試、集成測試、系統(tǒng)測試、驗收測試l 按測試策略分類 黑盒/白盒測試、動態(tài)/靜態(tài)測試、手工/自動測試l 按測試技術(shù)方法分類 功能測試、性能測試、壓力測試、易用性測試、安裝測試、容錯性測試、兼容性測試、安全性測試l 黑盒測試/白盒測試-從要不要看代碼來區(qū)分l 動態(tài)測試/靜態(tài)測試-從要不要運(yùn)行軟件來區(qū)分而常用的測試技術(shù)如下圖所示：

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

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

16、列表框中每個條目的功能。 列表框內(nèi)容多要使用滾動條。 列表框允許多選時，要分別檢查按Shift選中條目、按Ctrl選中條目和直接用鼠標(biāo)選中多項條目。 列表框如下圖所示：控件中滾動條測試： 滾動條是否能拖動 滾動條拖動時屏幕刷新情況 滾動條拖動時顯示信息的顯示 滾動條的上下按鈕是否可用 如下圖所示：控件組合操作：即各種控件的組合使用： 控件間的相互作用 Tab鍵的順序 熱鍵的使用 回車鍵和ESC鍵的使用 控件組合后功能的實現(xiàn)如下圖所示：對登錄操作測試如下圖所示： 輸入正確的用戶名和密碼，點“確定”，用戶可以正確登錄 輸入不正確的用戶名，正確的密碼，點“確定”。系統(tǒng)提示錯誤。 輸入正確的用戶名，不

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

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

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

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

21、檔中示例要載入并使用，保證其可以正確執(zhí)行 錯別字：無錯別字，標(biāo)點符號正確 排版：排版正確，風(fēng)格一致設(shè)計易用性測試用例：實例分析：優(yōu)秀界面的特點：l 符合標(biāo)準(zhǔn)和規(guī)范 l 直觀性 l 一致性 l 靈活性 l 舒適性 l 正確性 l 實用性 3. 軟件測試策略我們無法為軟件做窮舉測試，存在著組合爆炸的情況。軟件測試中的“殺蟲劑”現(xiàn)象。我們無法修復(fù)所有發(fā)現(xiàn)的錯誤。黑盒測試l 黑盒測試是對需求的所有輸入條件進(jìn)行測試l 黑盒測試發(fā)現(xiàn)的錯誤類型 功能不對或遺漏 界面錯誤 數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤 性能錯誤 初始化和終止錯誤黑盒測試關(guān)注點：l 功能： 如何測試功能的有效性 何種類型的輸入會產(chǎn)生好的測試用例

22、 系統(tǒng)是否對特定的輸入值敏感l(wèi) 數(shù)值： 如何分隔數(shù)據(jù)類的邊界 系統(tǒng)能夠承受何種數(shù)據(jù)率和數(shù)據(jù)量 特定類型的數(shù)據(jù)組合會對系統(tǒng)產(chǎn)生何種影響l 界面l 性能l 其他白盒測試：l 白盒測試發(fā)現(xiàn)的錯誤類型： 語法錯誤 編譯錯誤 Memory leak Performance problem 邏輯問題 判定條件問題 編程規(guī)范l 測試技術(shù) 基本路徑 控制結(jié)構(gòu)基本路徑測試，如下圖所示：優(yōu)缺點比較，如下圖所示：靜態(tài)測試與動態(tài)測試：靜態(tài)測試（Static testing）：不實際運(yùn)行被測試的程序 測試對象： 軟件文檔（用戶類，開發(fā)類） 源代碼（邏輯錯誤，代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格） 分類： 代碼走查（walkthroug

23、h） 代碼審查(Inspection) 技術(shù)評審(Review)動態(tài)測試（Dynamic Testing）：通過執(zhí)行軟件的手段來測試軟件靜態(tài)測試技術(shù)：代碼走查（walkthrough） 開發(fā)組內(nèi)部進(jìn)行的，采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯誤的活動代碼審查(Inspection) 開發(fā)組內(nèi)部進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯誤的活動。一般有正式的計劃、流程和結(jié)果報告技術(shù)評審(Review) 開發(fā)組、測試組和相關(guān)人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯誤的活動。一般有正式的計劃、流程和結(jié)果報告黑盒測試與白盒測試：白盒測試（White Box Testing） 又稱結(jié)構(gòu)測試，邏輯驅(qū)動測試或基于程序的測試 深入到代碼一級的測試，使用這種技術(shù)發(fā)現(xiàn)問題最早，效果也是最好的。但效率很低。 這一階段測試以軟件開