軟件系統常規測試過程概述_第1頁
軟件系統常規測試過程概述_第2頁
軟件系統常規測試過程概述_第3頁
軟件系統常規測試過程概述_第4頁
軟件系統常規測試過程概述_第5頁
已閱讀5頁,還剩109頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、技術創新,變革未來軟件系統常規測試過程概述2軟件系統測試執行階段軟件系統測試用例執行軟件系統測試軟件缺陷記錄、跟蹤軟件系統測試日報寫作軟件系統測試報告寫作軟件系統測試缺陷的回歸測試ST3單元測試和系統測試的區別單元測試早期測試;白盒測試;單元的具體實現、內部邏輯結構、數據流向;允許多個單元的測試同時開展。系統測試后期測試,錯誤定位困難;黑盒測試;基于需求規格說明書;站在用戶角度。4系統測試,是將已經集成好的軟件系統,作為整個基于計算機系統的一個元素,與計算機硬件、外設、某些支持軟件、數據和人員等其它系統元素結合在一起,在實際運行環境下,對計算機系統進行一系列的測試活動。系統測試(System

2、Testing)5系統測試的目的通過與系統的需求定義做比較,發現軟件與系統定義不符合或與之矛盾的地方驗證系統功能是否符合需求規格定義驗證系統的可靠性、可維護性、可用性、穩定性、容錯性等其他屬性系統測試的測試用例應根據需求分析說明書來設計,并在實際使用環境下運行。6系統測試的對象系統測試的對象是軟硬件集合在一起的系統,不應是獨立的軟件與硬件環境。驗證時應盡可能模擬實際的運行環境與條件。7單元、集成、系統測試比較考察范圍不同單元測試主要測試單元內部的數據結構、邏輯控制、異常處理等集成測試主要測試模塊之間的接口和接口數據傳遞關系,以及模塊組合后的整體功能系統測試主要測試整個系統相對于需求的符合度評估

3、基準不同系統測試的評估基準是測試用例對需求規格的覆蓋率單元測試評估的主要是邏輯覆蓋率集成測試評估的主要是接口覆蓋率8配置主測試環境遵循的原則主測試環境是測試軟件功能、安全可靠性、性能、易用性等大多數指標的主要環境。符合軟件運行的最低要求。測試環境首先要保證能支撐軟件正常運行。選用比較普及的OS和軟件平臺例如:一個軟件若聲稱支持“Windows9X/ME/NT/2000 professional”和“MS Office97/2000/XP”,一般我們會采用如“Windows2000 professionalMS Office2000”的流行環境營造相對簡單、獨立的測試環境。除了OS,測試機上只安

4、裝軟件運行和測試必需的軟件,以免不相關的軟件影響測試實施。無毒的環境利用有效的正版殺毒軟件檢測軟件環境,保證測試環境中沒有病毒。9配置輔測試環境遵循的原則兼容性測試在滿足軟件運行要求的范圍內,可選擇一些典型的OS和常用應用軟件對其安裝卸載和主要功能進行驗證。模擬真實環境測試有些軟件,特別是面向大眾的商品化軟件,在測試時常常需要考察在真實環境中的表現。橫向對比測試利用輔測試環境“克隆”出完全一致的測試環境,從而保證各個被測軟件平等對比。10軟件特性和常用系統測試類型的對應關系:功能性:功能測試、安全性測試、互連測試可靠性:可靠性測試、啟動/停止測試、恢復測試、健壯性測試、備份測試易用性:可用性測

5、試、文檔測試、安裝測試效率:強度測試、性能測試、指標測試、內存泄漏測試、容量測試、壓力測試維護性:可維護性測試可移植性:配置測試、兼容測試、安裝測試11系統測試用例編寫原則系統測試用例的設計根據是系統的需求規格說明書、各種規范系統測試用例的依據不是軟件本身系統測試用例不僅僅包括功能測試用例,同時還應該包含屬性測試用例12系統測試用例編寫思路(1)為系統功能性設計用例為系統可靠性設計用例為系統易用性設計用例為系統可移植性設計用例為系統可維護性設計用例為系統效率設計用例為系統異常設計用例13系統測試用例編寫思路(2)一、根據ISO9126質量模型分析需求規格說明書,將需測試的需求項歸納到各特性、子

6、特性下質量特性質量子特性測試項功能性適合性準確性互操作性安全性功能依從性效率時間特性資源利用性14系統測試用例編寫思路(3)二、對分析出來的測試需求項進行歸納、總結,確定需要進行何種類型的測試,并把各測試項歸類到各測試類型下:功能測試性能測試壓力測試容量測試安全性測試GUI測試可用性測試安裝測試配置測試異常測試(恢復性測試)備份測試健壯性測試文檔測試在線幫助測試網絡測試系統測試用例編寫思路(4)三、對各測試類型下的測試項細分,形成為測試子項:需求標識需求描述系統測試項標識系統測試項描述系統測試子項標識系統測試子項描述Router_V100_SRS_001路由管理Router_V100_ST_A

7、ddRoute路由增加Router_V100_ST_AddRoute_HostRoute_增加主機路由Router_V100_ST_AddRoute_NetRoute_增加網絡路由Router_V100_ST_AddRoute_SpecRoute_增加特殊路由Router_V100_ST_DelRoute路由刪除Router_V100_ST_InqRoute路由查詢Router_V100_SRS_002路由協議Router_V100_ST_OSPFOSPF協議測試Router_V100_ST_RIPRIP協議測試16系統測試用例編寫思路(5)四、對各測試子項對應的具體需求規格進行分析,利用各種

8、系統測試用例設計方法,從各角度設計用例去對需求規格進行覆蓋,從而達到對需求的充分覆蓋:等價類劃分法邊值分析法狀態遷移圖法決策表正交試驗法錯誤猜測法17系統測試過程測試過程計劃設計實現執行;測試過程體現了測試設計和實現的分離測試實現測試執行系統測試計劃階段:完成系統測試計劃系統測試設計階段:完成系統測試方案系統測試實現階段:完成系統測試用例和腳本、系統測試規程、系統測試預測試項系統測試執行階段:執行系統測試預測試項、提交系統預測試報告;執行系統測試用例,提交測試日報,發現問題并提交缺陷報告、系統測試報告;進行回歸測試18系統測試執行的概念按一定的系統測試計劃,依據系統測試用例,完成測試的各項操作

9、任務;系統測試執行階段應完成:環境準備、測試操作、測試記錄、測試報告19系統測試預測試目的:驗證軟件系統基本功能或預測主要的系統功能,以確保其后的系統測試執行能順利進行20系統測試日報的寫作目的測試人員總結每天的測試工作,便于了解自己的測試進度和測試情況,用以調整下一天的工作計劃測試人員對被測對象每天給出評估結果,用以調整后續工作中的測試策略測試人員向測試經理反映測試中的困難,保證測試的順利進行測試經理通過測試日報,了解每個測試人員的工作進度,把握測試的整體進度,發現進度上的風險及時調整計劃21測試經理通過測試日報,了解各模塊缺陷發展趨勢,判斷測試是否可以退出開發經理可以通過軟件測試日報了解當

10、前被測試軟件的質量情況,并可以調整缺陷修改的人力資源如果產品有多個測試組并行測試,測試日報可以提供彼此測試交流的手段項目ID標題版本執行者測試階段日期概述執行用例數總用例數計劃執行用例數累計已執行用例數本日發現問題數累計發現問題數致命問題數問題單號嚴重問題數問題單號一般問題數問題單號困難系統測試日報的格式23測試報告的寫作目的軟件測試人員完成對上一個測試階段的總結,完成對被測試對象的評估,并對下一階段的測試工作給出建議測試經理通過測試報告了解被測試產品的質量情況、測試過程的質量軟件開發項目經理通過軟件測試報告了解開發產品的質量情況,并在下階段的開發工作中采取應對措施在軟件測試報告中,軟件測試人

11、員做出的軟件產品質量評估,可以作為產品是否商用發布的重要參考依據。24系統測試報告寫作要點概述測試時間、地點、人員環境描述總結和評價測試結果統計測試評估測試總結和改進建議遺留問題報告附件25系統測試結果統計工作量數據統計(規模:KLOC、測試執行:人時、工作量投入比例:人時/KLOC)缺陷統計(致命、嚴重、一般、提示)版本缺陷統計(V1、V2、V3、V4)累計遺留問題統計(V1、V2、V3、V4)26系統測試評估(1)靜態分析:效率分析測試活動持續時間:X人時執行用例數:Y個發現缺陷總數:Z個平均每小時用例數執行用例數/測試活動持續時間Y/X平均每小時發現缺陷數發現缺陷總數/測試活動持續時間Z

12、/X影響測試效率的原因分析:對影響測試的各種因素進行分析,如:測試環境,物料,突發任務等。27系統測試評估(2)靜態分析:充分性分析千行代碼用例數:根據用例統計對測試充分性進行點評分析執行結果統計根據結果統計對系統質量和測試過程進行點評28系統測試評估(3)測試對象的整體質量:質量穩定,適合大規模應用;存在少數嚴重問題,但有規避措施,可以使用;基本功能可用,但問題較多;基本功能不可用。也可采用打分方式。29系統測試總結和改進建議總結本次測試活動的經驗教訓,總結主要的測試活動和事件總結資源消耗數據,如總人員、總機時,每個主要測試活動花費的時間提供對本次測試過程活動的測試設計和操作的改進建議在測試

13、過程中形成的對測試方案、測試用例的修改和補充的具體改進內容可列在本測試報告文檔的附錄中30系統測試遺留問題報告遺留問題是指測試過程中發生的并且在測試報告時仍沒有得到解決的測試問題。測試報告時已經得到解決,并已經過回歸驗證的測試問題不記入其中可對遺留問題數和級別進行統計要列出每個遺留問題的詳細情況,包括問題單號、問題級別、詳細描述、問題分析與對策等317.1 線索(Thread)的概念一、線索的看法和層次線索的看法:使用場景;系統級測試用例;激勵/響應對;系統級輸入序列產生的行為;端口輸入/輸出事件交替序列(系統級);機器指令序列 ;MM-路徑序列(集成級);源指令序列(單元級);原子系統功能序

14、列(系統級);32線索的層次:單元級:DD-路徑集成級:MM-路徑/模塊執行和消息交替序列系統級:ASF序列(端口輸入/輸出事件的交替序列)線索提供三層測試的統一視圖:單元測試:單個函數測試;集成測試:單元之間的交互;系統測試:檢查原子系統功能之間的交互。33四個侯選線索數字輸入(激勵/響應對,最小原子系統功能,集成測試)PIN輸入(激勵/響應對,原子系統功能,系統測試起點)簡單事務處理(多個原子系統功能交互,系統級線索)ATM卡輸入、PIN輸入、選擇事務處理類型、提供帳戶細節、引導操作、報告結果ATM會話(一系列線索之間的交互)二、系統級線索的例子-SATM系統注意:不應該集成大于原子系統功

15、能的單元,也不對小于原子系統功能的單元進行系統測試。34ASF由事件靜止點區分開,自然端點事件靜止的Petri網解釋:死鎖和激活 三、系統線索ASF:在系統層可以觀察得到的端口輸入輸出事件的行動。 ASF由端口輸入事件開始,端口輸出事件結束;例:SATM的數字輸入,ATM卡輸入,現金支付,會話關閉 ASF是集成測試的最大測試項和系統測試的最小測試項(可在兩個級別上測試ASF);例:SATM的數字輸入35定義ASF圖:有向圖,節點表示ASF,邊表示串行流;源/匯ASF:例, SATM的ATM卡輸入和會話結束系統線索: ASF圖從源ASF到匯ASF的路徑線索圖:有向圖,節點表示系統線索,邊表示單個

16、線索順序執行36 7.2 需求規格說明所有需求規格說明由五個基本概念表示:一、數據:經過初始化、存儲、更新、銷毀的信息二、行動:轉換、處理、活動三、設備:端口、傳送器、現金給付器、收據打印機四、事件:發生在端口設備上的系統級輸入/輸出。 注意:與語境有關的端口事件五、線索37六、采用五個基本概念建立需求模型結構模型(表示功能、數據的分解和組件接口,用于開發);語境模型(強調行動)行為/控制模型(需求的基礎)常用模型描述手段:決策表(轉換式)計算系統;有限狀態機(交互式)菜單驅動系統;Petri網并發系統;38基本結構之間建模關系結構模型語境模型數據事件行為線索設備行為模型39例:函數F在E1,

17、E2都發生了才發生的模型外部實體1事件存儲1外部實體2事件存儲2F函數F的事件劃分視圖E1E2缺點:不能通過模型區分到底是哪個事件先發生,只知道兩個事件一定發生。40空閑E1已發生準備執行FE1E2E2已發生E2E1函數F的有限狀態機顯式地顯示事件的兩種順序,兩種模型都描述了F的相同前提,但狀態機對測試人員來說更有用。41 7.3 SATM的系統線索首先討論狀態機的層次結構頂層狀態機(通過線索進行狀態切換)過程的階段劃分狀態轉移由邏輯事件引起421、卡輸入2、PIN輸入3、等待事務選擇有效卡/顯示屏幕2顯示屏幕1卡錯/顯示屏幕S1,退回卡成功PIN/顯示屏幕5PIN失敗/顯示屏幕4圖14-5

18、頂層SATM狀態機43“PIN輸入”狀態機輸入事件是邏輯事件、輸出事件是真正的端口事件狀態分解(圖14-6)端口事件(表14-1)端口輸入事件端口輸出事件有效卡顯示屏幕1錯卡顯示屏幕2正確的PIN顯示屏幕3錯誤的PIN顯示屏幕4取消顯示屏幕5442.1第一次PIN輸入嘗試2.2第二次PIN輸入嘗試2.3第三次PIN輸入嘗試3、等待交易選擇1、卡輸入屏幕1卡正常,屏幕S2正確PIN/屏幕S5卡錯/屏幕S1退卡PIN錯/屏幕S4PIN錯/屏幕S3PIN錯/屏幕S3正確PIN/屏幕S5正確PIN/屏幕S5圖14-6 PIN輸入有限狀態機ab1234545“PIN輸入嘗試”有限狀態機狀態分解(圖14-

19、7)端口事件(表14-2)端口輸入事件端口輸出事件數字回顯“X”取消回顯“XX”回顯“XXX-”回顯“XXXX”462.x.1收到0數字2.x.2收到1數字2.x.3收到2數字2.x.4收到3數字2.x.5收到4數字2.x.6按下“取消”正確PIN x5不正確PIN x6數字/回顯“X”x1數字/回顯“XX-”x2數字/回顯“XXX-”x3數字/回顯“XXXX”x4x7取消x8取消x9取消x10取消x11已取消圖14-7 PIN輸入嘗試有限狀態機 GetPIN47有限狀態機的層次結構,使線索的數量成倍增長。例:狀態2.1到3或1的線索(路徑)數量錯誤的數字或按下cancel(5X5X5)最終正

20、確的PIN輸入(1+5+25)共156條不同的路徑(圖14-6與圖14-7的結合)48例:走通層次狀態機的兩條路徑端口輸入事件端口輸出事件屏幕2顯示“”按下1屏幕2顯示“X”按下2屏幕2顯示“XX-”按下3屏幕2顯示“XXX-”按下4屏幕2顯示“XXXX”(正確的PIN)顯示屏幕51.第一次PIN輸入正確的端口事件序列(設PIN是1234)492.第三次PIN輸入正確的端口事件序列(設PIN是1234)端口輸入事件端口輸出事件屏幕2顯示“”按下1屏幕2顯示“X”按下2屏幕2顯示“XX-”按下3屏幕2顯示“XXX-”按下5屏幕2顯示“XXXX”(錯誤的PIN)顯示屏幕350端口輸入事件端口輸出事

21、件(第二次嘗試)屏幕2顯示“”按下1屏幕2顯示“X”按下2屏幕2顯示“XX-”按下3屏幕2顯示“XXX-”按下cancel(第二次嘗試結束)顯示屏幕351端口輸入事件端口輸出事件(第三次嘗試)屏幕2顯示“”按下1屏幕2顯示“X”按下2屏幕2顯示“XX-”按下3屏幕2顯示“XXX-”按下4屏幕2顯示“XXXX”(正確的PIN)顯示屏幕552 7.4 線索測試的結構測試策略根據線索生成測試用例,用有向圖選擇線索。(按照狀態機層次)自底向上組織線索例:SATM系統“PIN輸入嘗試”有限狀態機線索路徑(表14-5)“PIN輸入”狀態機線索路徑(表14-6)測試問題:分層機制使單獨測試不可行。53輸入事

22、件序列轉移的路徑1234x1 x2 x3 x4 x51235x1 x2 x3 x4 x6Cx7 x111Cx1 x8 x1112Cx1 x2 x9 x11123Cx1 x2 x3 x10 x11 “PIN輸入嘗試”有限狀態機中,共有6條路徑。經過路徑的線索以輸入鍵描述。表14-5 “PIN輸入嘗試”有限狀態機線索路徑54 上升到“PIN輸入”有限狀態機中,共有4條路徑。輸入事件序列轉移的路徑12341123512342 31235C12342 4 5CCC2 4 6表14-6 “PIN輸入”有限狀態機線索路徑55節點(狀態)與邊(轉換)的覆蓋指標上層狀態機以下層狀態機作為輸入和返回。SATM系

23、統一個線索的節點和邊的遍歷(表14-7)線索/狀態的關聯(表14-8)線索/轉換的關聯(表14-9)輸入事件2.12.x.12.x.22.x.32.x.42.x.52.x.62.22.3311234xxxxxxx12351234xxxxxxxxC1234xxxxxxxxx1C12C1234xxxxxxxxxx123C1C1Cxxxxxxxxx表14-8 線索/狀態的關聯輸入事件x1x2x3x4x5x6x7x8x9x10 x111234561234xxxxxx12351234xxxxxxxxC1234xxxxxxxxx1C12C1234xxxxxxxxxxx123C1C1Cxxxxxxxxx表1

24、4-9 線索/轉換的關聯58 7.5 線索測試的功能測試策略基于事件的線索測試適合:以事件驅動的系統(“反應式”系統)端口輸入事件的五個覆蓋指標:每個端口輸入事件發生;端口輸入事件的常見序列發生;每個端口輸入事件在所有“相關”數據語境中發生;按下B1在5種單獨的語境種發生,3種不同含義對于給定語境,所有不合適的輸入事件發生;對于給定語境,所有可能的輸入事件發生。59端口輸出事件的兩個覆蓋指標:每個端口輸出事件發生;每個端口輸出事件在每種原因下發生。難以定量描述,給定輸出事件只有少量原因,沒有被懷疑到的原因引起的輸出最難發現。出現屏幕10的原因:終端儲備現金可能用完、可能要連接到中央銀行獲得帳戶

25、余額、取款通道可能阻塞。60開發模型全狀態狀態關鍵原子系統功能ATM卡輸入、PIN輸入、事務處理、會話管理前提數據帶有PAN、PIN和帳戶余額的實際帳戶,ATM初始顯示S1,現金給付器總現金$500 7.6 SATM測試線索61SATM測試數據PAN預期PIN支票余額(美元)儲蓄余額(美元)10012341000.00800.002004567100.0090.00300678925.0020.0062 線索描述形式表格線索一余額查詢線索二支票帳戶存款線索三儲蓄帳戶取款線索1 ATM卡輸入 PIN輸入 事務處理請求 會話管理(余額) (PAN) 端口輸入 100 1234 B1,B1 B2 端

26、口輸出 S2 S5 S6,S14,$1000.00 S15,退卡,S1線索2 ATM卡輸入 PIN輸入 事務處理請求 會話管理(存款) (PAN) 端口輸入 100 1234 B2,B1,25.00 B2 端口輸出 S2 S5 S6,S7,S13,存款通道開 S15,退卡, S14,$1025.00 S1線索3 ATM卡輸入 PIN輸入 事務處理請求 會話管理(取款) (PAN) 端口輸入 100 1234 B3,B2,30.00 B2 端口輸出 S2 S5 S6,S7,S11,取款 S15,退卡,S1 通道開,3張10,S14,$770.00線索4 ATM卡輸入(PAN) PIN輸入 事務處

27、理請求 會話管理 端口輸入 400端口輸出 退出ATM卡,S1線索5 ATM卡輸入 PIN輸入 事務處理請求 會話管理(余額) (PAN) 端口輸入 100 12351234 與線索1相同端口輸出 S2 S3,S2,S5 線索6 ATM卡輸入 PIN輸入 事務處理請求 會話管理(余額) (PAN) 端口輸入 100 C1234 與線索1相同端口輸出 S2 S3,S2,S5線索7 ATM卡輸入 PIN輸入 事務處理請求 會話管理(余額) (PAN) 端口輸入 100 1C12C1234 與線索1相同端口輸出 S2 S3,S2,S3,S2,S5線索8 ATM卡輸入 PIN輸入 事務處理請求 會話管

28、理(余額) (PAN) 端口輸入 100 123C1C1C 與線索1相同端口輸出 S2 S3,S2,S3,S2,S4,S1線索9 ATM卡輸入 PIN輸入 事務處理請求 會話管理(提取) (PAN) 端口輸入 100 1234 B3,B2,15.00,取消 B2 端口輸出 S2 S5 S6,S7,S9,S7 S15,退卡,S1線索10 ATM卡輸入 PIN輸入 事務處理請求 會話管理(提取) (PAN) 端口輸入 300 6789 B3,B2,50.00,取消 B2 端口輸出 S2 S5 S6,S7,S8 S15,退卡,S1非10元整數倍多于余額線索11 ATM卡輸入 PIN輸入 事務處理請求

29、 會話管理(提取) (PAN) 端口輸入 100 1234 B3,B2,510.00,取消 B2 端口輸出 S2 S5 S6,S7,S10 S15,退卡,S1多于機器總額線索12 ATM卡輸入 PIN輸入 事務處理請求 會話管理(余額) (PAN) 端口輸入 100 1234 B1,B1 B1,取消 端口輸出 S2 S5 S6,S14,$1000.00 S5,S15,退卡,S1硬件失效線索13:覆蓋輸出屏幕12(存款不能被處理)語境有關輸入事件線索1422(表14-11)各輸出屏幕上的Cancel鍵,B1、B2功能鍵測試線索 按下的鍵 屏幕 邏輯含義6 取消 2 PIN輸入錯誤14 取消 5

30、事務處理選擇錯誤15 取消 6 帳戶選擇錯誤16 取消 7 金額輸入錯誤17 取消 8 金額輸入錯誤18 取消 13 取款信封未就緒1 B1 5 余額1 B1 6 支票19 B1 10 是(暫時無法取款)20 B1 12 是(暫時無法存款)12 B1 14 是(另一個事務處理)2 B2 5 存款3 B2 6 儲蓄21 B2 10 否(沒有其他事務處理)22 B2 12 否(沒有其他事務處理)1 B2 14 否(沒有其他事務處理)70偽結構系統測試將基于圖的指標用作功能線索的一種交叉檢查。基于系統控制模型導出功能線索邊和節點的覆蓋指標決策表設計每個規則的測試用例(轉換式)有限狀態機設計覆蓋每個狀

31、態、轉換、路徑的測試用例(交互式)Petri網設計覆蓋每個地點、轉移、轉移序列的測試用例(并發系統)7.7 系統測試原則解決線索爆炸問題71運行剖面Zipfs law(80%的活動發生在20%的空間中)以系統線索出現的頻率選擇測試用例;以決策樹確定系統運行剖面(圖14-10)給定轉移概率,線索的總概率就是各轉移概率的乘積。有效卡:0.95 卡錯:0.05PIN正確:0.90 PIN不正確:0.10B1:0.05 B2:0.10 B3:0.85現金不足:0.10 正常:0.85 余額不足:0.0572常見線索 概率有效ATM卡 0.95PIN第一次嘗試正確 0.90取款 0.85正常 0.85

32、0.617737573罕見線索 概率有效ATM卡 0.95PIN第一次嘗試錯誤 0.10PIN第二次嘗試錯誤 0.10PIN第三次嘗試正確 0.90取款 0.85現金不足 0.10 0.0007267574功能測試性能測試穩定性測試負載測試壓力測試安全性測試恢復性測試備份測試GUI測試健壯性測試兼容性測試可用性測試可安裝性測試文檔測試在線幫助測試數據轉換測試可靠性測試Web網站測試7.8 系統測試方法751.功能測試功能測試是系統測試中最基本的測試,主要根據產品的需求規格說明書和測試需求列表,驗證產品的功能實現是否符合產品的需求規格。為了發現以下幾類錯誤:是否有不正確或遺漏了的功能?功能實現是

33、否滿足用戶需求和系統設計的隱藏需求?能否正確地接受輸入?能否正確地輸出結果?要求測試設計者對產品的規格說明、需求文檔、產品業務功能都非常熟悉,測試用例設計方法也要掌握。762.性能測試性能測試用來檢查系統是否滿足在需求說明書中規定的性能。特別是針對嵌入式實時系統。性能測試可以在測試過程的任意階段進行,但只有當整個系統的所有成分都集成到一起后,才能檢查一個系統的真正性能。性能測試必須要有工具支持,用于GUI或Web的性能測試工具在市面上能見到。773.穩定性測試是指連續運行被測系統,檢查系統運行時的穩定程度。通常用mtbf(mean time between failure)來衡量系統的穩定性,

34、mtbf越大,系統的穩定性越強采用24*7(24小時*7天)的方式讓系統不間斷運行,至于具體運行多少天,是一周還是一個月,視項目的實際情況而定。78負載測試是指讓被測系統在其能忍受的壓力的極限范圍之內連續運行,來測試系統的穩定性。負載測試需要給被測系統施加其剛好能承受的壓力 。負載測試為測試系統在臨界狀態下運行是否穩定提供了一種辦法。 795.壓力測試壓力測試:是指持續不斷的給被測系統增加壓力,直到將被測系統壓垮為止,用來測試系統所能承受的最大壓力。比如不斷增加并發的登錄用戶數,20,30,50,當增加到70個用戶并發登錄時,系統崩潰了,就可以知道163郵箱所能承載的最大登錄并發數為70個左右

35、。 806.安全性測試安全性測試是要檢驗在系統中已經存在的系統安全性、保密性措施是否發揮作用,有無漏洞。主要是測試系統在沒有授權的內部或者外部用戶對系統進行攻擊或者惡意破壞時軟件如何進行處理,是否仍能保證數據的安全。測試人員可以學習一些黑客技術,來對系統進行攻擊。81 破壞系統的保護機構以進入系統的主要方法:正面攻擊或從側面、背面攻擊系統中易受損壞的那些部分;以系統輸入為突破口,利用輸入的容錯性進行正面攻擊;申請和占用過多的資源壓垮系統,以破壞安全措施,從而進入系統;故意使系統出錯,利用系統恢復的過程,竊取用戶口令及其它有用的信息;通過瀏覽殘留在計算機各種資源中的垃圾(無用信息),以獲取如口令

36、,安全碼,譯碼關鍵字等信息;瀏覽全局數據,期望從中找到進入系統的關鍵字;瀏覽那些邏輯上不存在,但物理上還存在的各種記錄和資料等。827.恢復性測試恢復測試的目標是驗證系統從軟件或者硬件失敗中恢復的能力;恢復測試是要證實在克服硬件故障(包括掉電、硬件或網絡出錯等)后,系統能否正常地繼續進行工作,并不對系統造成任何損害。可采用各種人工干預的手段,模擬硬件故障,故意造成軟件出錯。掉電測試:測試軟件系統在發生電源中斷時能否保護當時的狀態且不毀壞數據,然后在電源恢復時從保留的斷點處重新進行操作。838. 備份測試備份測試是恢復性測試的一個補充,并且應當是恢復性測試的一個部分。備份測試的目的是驗證系統在軟

37、件或者硬件失敗的事件中備份它數據的能力。849.GUI測試為了讓軟件能夠更好地服務于用戶,進行GUI測試變得非常重要了。GUI測試包括:界面實現與界面設計的吻合情況;確認界面處理的正確性。GUI系統分為:界面層、界面與功能的接口層、功能層。界面的美學具有很大的主觀性,如何才能代表大部分客戶的意見是界面測試的一個難點。8510. 健壯性測試也叫容錯性測試(Fault ToleranceTesting),主要用于測試系統在出現故障時,是否能夠自動恢復或者忽略故障繼續運行。必須小心地設計實現系統,尤其是在系統的異常處理方面。一個健壯的系統是設計出來的而不是測試出來的。8611.兼容性測試檢查軟件之間

38、是否正確地交互和共享信息兼容性包括向前兼容或向后兼容不同版本間的兼容標準和規范 MS Windows認證徽標,為了得到這個徽標,軟件必須通過獨立測試實驗室的兼容性測試,確保在Windows OS 上能平穩可靠的運行。數據共享兼容如:Windows環境下,對某個程序進行兼容性測試就要確認其數據能夠利用剪切板與其他程序進行相互復制8712.可用性測試可用性測試是為了檢測用戶在理解和使用系統方面到底有多好,包括:系統功能、系統發布、幫助文本和過程,以保證用戶能夠舒適地和系統交互。可使用性測試主要從使用的合理性和方便性等角度對軟件系統進行檢查,發現人為因素或使用上的問題。88一些應當關注的可用性問題包

39、括:過分復雜的功能或者指令;困難的安裝過程;錯誤信息過于簡單,如:“系統錯誤”非標準的GUI接口;用戶被迫去記住太多的信息;難以登錄;幫助文本上下文不敏感或者不夠詳細;默認不夠清晰;接口太簡單或者太復雜8913.可安裝性測試一個軟件的安裝程序應當平滑地集成用戶的新軟件到已有的系統中去,對話窗口提供簡單、容易理解的安裝選項和支持信息,完成安裝過程。可安裝性測試的目的是驗證成功安裝系統的能力,不是找軟件錯誤,而是找安裝錯誤。清晰并且簡單的安裝過程是系統文檔中最重要的部分。901 文檔測試這種測試是驗證用戶文檔是正確的并且保證操作手冊的過程能夠正確工作。用戶文檔中所使用的例子必須在測試中一一試過,確

40、保敘述正確無誤。有助于發現系統中的不足/使系統更可用;可減少客戶支持成本。9115. 在線幫助測試一個糟糕的在線幫助會大大打擊用戶對系統的信心。一個好的系統,必須要有完備的幫助體系,包括用戶操作手冊,實時在線幫助等。在線幫助測試用于驗證系統的實時在線幫助的可用性和正確性。9216. 數據轉換測試實際應用環境中,經常遇到環境需要升級的問題,新系統使用老數據是否會出現問題?據轉換測試的目標在于驗證已存在數據的轉換并載入一個新的數據庫是否是有效的。9317.可靠性測試軟件可靠性:在規定環境,規定時間內,一個系統或其功能無故障運行的可能性。如果系統需求說明書中有對可靠性的要求,則需進行可靠性測試。軟件

41、可靠性指標: 平均失效間隔時間 MTBF (Mean Time Between Failures) 是否超過規定時限? 因故障而停機的時間 MTTR (Mean Time To Repairs) 在一年中應不超過多少時間。9418.Web網站測試功能測試鏈接測試表單測試Cookies測試設計語言測試數據庫測試性能測試連接速度測試容量測試壓力測試可用性測試導航測試 圖形測試 內容測試 整體界面測試客戶端兼容性測試平臺測試 瀏覽器測試安全性測試95Web網站測試 - 功能測試(1)1.鏈接測試目的 測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面;測試所鏈接的頁面是否存在;保證Web應用系統上

42、沒有孤立的頁面,所謂孤立頁面是指沒有鏈接指向該頁面,只有知道正確的URL地址才能訪問。 鏈接測試可以自動進行,現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成,也就是說,在整個Web應用系統的所有頁面開發完成之后進行鏈接測試。 96Web網站測試 - 功能測試(2)2.表單測試 當用戶給Web應用系統管理員提交信息時,就需要使用表單操作,例如用戶注冊、登陸、信息提交等。在這種情況下,我們必須測試提交操作的完整性,以校驗提交給服務器的信息的正確性。例如:用戶填寫的出生日期與職業是否恰當,填寫的所屬省份與所在城市是否匹配等。如果使用了默認值,還要檢驗默認值的正確性。如果表單只能接受指定的

43、某些值,則也要進行測試。例如:只能接受某些字符,測試時可以跳過這些字符,看系統是否會報錯。97Web網站測試 - 功能測試(3)3.Cookies測試 Cookies通常用來存儲用戶信息和用戶在某應用系統的操作,當一個用戶使用Cookies訪問了某一個應用系統時,Web服務器將發送關于用戶的信息,把該信息以Cookies的形式存儲在客戶端計算機上,這可用來創建動態和自定義頁面或者存儲登陸等信息。 如果Web應用系統使用了Cookies,就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用,是否按預定的時間進行保存,刷新對Cookies有什么影響等。 98Web網站測

44、試 - 功能測試(4)設計語言測試Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題,例如使用哪種版本的HTML等。當在分布式環境中開發時,開發人員都不在一起,這個問題就顯得尤為重要。99Web網站測試 - 功能測試(5)5.數據庫測試在Web應用技術中,數據庫起著重要的作用,數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在使用了數據庫的Web應用系統中,一般情況下,可能發生兩種錯誤,分別是數據一致性錯誤和輸出錯誤。100Web網站測試 - 性能測試(1)1.連接速度測試用戶連接到Web應用系統的速度根據上網方式的變化而變化,他們或許是電話撥號,或是寬帶

45、上網;當下載一個程序時,用戶可以等較長的時間,但如果僅僅訪問一個頁面就不會這樣;有些頁面有超時的限制,如果響應速度太慢,用戶可能還沒來得及瀏覽內容,就需要重新登陸了。而且,連接速度太慢,還可能引起數據丟失,使用戶得不到真實的頁面。 101Web網站測試 - 性能測試(2)2.容量測試容量測試是為了測量Web系統在某一負載級別上的性能,以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量,也可以是在線數據處理的數量。例如:Web應用系統能允許多少個用戶同時在線?如果超過了這個數量,會出現什么現象?Web應用系統能否處理大量用戶對同一個頁面的請求? 102We

46、b網站測試 - 性能測試(3)3.壓力測試壓力測試應該安排在Web系統發布以后,在實際的網絡環境中進行測試。Intranet的用戶數目總是有限的,只有放在Internet上,接受負載測試,其結果才是正確可信的。 壓力測試是測試系統的限制和故障恢復能力,也就是測試Web應用系統會不會崩潰,在什么情況下會崩潰。壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。103Web網站測試 - 可用性測試(1)1.導航測試 考慮下列問題:導航是否直觀?Web系統的主要部分是否可通過主頁存取?Web系統是否需要站點地圖、搜索引擎或其他的導航幫助? Web應用系統的用戶趨向于目的驅動,很少有用戶愿意花時間去熟悉

47、Web應用系統的結構,因此,Web應用系統導航幫助要盡可能地準確。 導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統里面是否還有內容,內容在什么地方。 Web應用系統的層次一旦決定,就要著手測試用戶導航功能,讓最終用戶參與這種測試,效果將更加明顯。 104Web網站測試-可用性測試(2)2.圖形測試:在Web應用系統中,適當的圖片和動畫可以美化頁面。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。要確保圖形有明確的用途,圖片或動畫不要胡亂地堆在一起,以免浪費傳輸時間。Web應用系統的圖片尺寸要盡量地小

48、,并且要能清楚地說明某件事情,一般都鏈接到某個具體的頁面。 驗證所有頁面字體的風格是否一致。 背景顏色應該與字體顏色和前景顏色相搭配。 圖片的大小和質量也是一個很重要的因素,一般采用JPG或GIF壓縮。105Web網站測試-可用性測試(3)3.內容測試:內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。 信息的正確性是指信息是可靠的還是誤傳的。例如,在商品價格列表中,錯誤的價格可能引起財政問題甚至導致法律糾紛;信息的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行,例如使用Microsoft Word的“拼音與語法檢查”功能;信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口,也就是一般W

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論