軟件測試技術(shù)課件:系統(tǒng)測試_第1頁
軟件測試技術(shù)課件:系統(tǒng)測試_第2頁
軟件測試技術(shù)課件:系統(tǒng)測試_第3頁
軟件測試技術(shù)課件:系統(tǒng)測試_第4頁
軟件測試技術(shù)課件:系統(tǒng)測試_第5頁
已閱讀5頁,還剩90頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

系統(tǒng)測試測試生命周期用戶需求體系結(jié)構(gòu)設(shè)計詳細(xì)設(shè)計編碼實現(xiàn)單元測試集成測試系統(tǒng)測試驗收測試PrepareplanVerifyPrepareplanVerifyPrepareplanVerify軟件需求2各個測試階段對比測試階段目的執(zhí)行者測試方法單元測試查找獨立模塊中邏輯錯誤、數(shù)據(jù)錯誤和算法錯誤軟件工程師白盒測試集成測試查找模塊之間接口錯誤軟件工程師測試人員白盒測試自頂向下或自底向上系統(tǒng)測試對系統(tǒng)中各個組成部分進(jìn)行綜合性檢驗測試人員黑盒測試模擬用戶操作

回歸測試確認(rèn)軟件變更后是否仍滿足軟件需求測試人員黑盒測試模擬用戶操作驗收測試確認(rèn)軟件是否滿足用戶需求用戶項目組測試人員黑盒測試模擬用戶操作3系統(tǒng)測試概念使用人工或自動手段來運行或測定某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的系統(tǒng)需求或是弄清預(yù)期結(jié)果與實際結(jié)果之間的差別。驗證(Verification)

驗證確定工作產(chǎn)品正確反映了它們的規(guī)定需求。換言之,驗證保證“你正確地構(gòu)建了它”。確認(rèn)(Validation)

確認(rèn)確定提供的產(chǎn)品將滿足其預(yù)期使用。換言之,確認(rèn)保證“你構(gòu)建了正確的產(chǎn)品”。4系統(tǒng)測試概念為了發(fā)現(xiàn)缺陷并度量產(chǎn)品質(zhì)量,按照系統(tǒng)的功能和性能需求進(jìn)行的測試一般使用黑盒測試技術(shù)一般由獨立的測試人員完成對于模塊之間交互性比較強的軟件,還會有單獨的集成測試,用來發(fā)現(xiàn)模塊接口之間的錯誤。5系統(tǒng)測試的內(nèi)容功能測試恢復(fù)性測試(災(zāi)難測試、容錯測試)可用性測試安全性測試接口測試GUI測試安裝/升級測試配置測試/兼容性測試國際化(語言)測試用戶文檔測試……性能測試壓力測試容量測試可靠性測試邊界測試

……冒煙測試回歸測試隨機測試硬件系統(tǒng)專有測試可靠性試驗可生產(chǎn)性測試可維護(hù)性測試67性能測試8

性能測試的概念性能測試主要檢驗軟件是否達(dá)到需求規(guī)格說明書中規(guī)定的各類性能指標(biāo),并滿足一些性能相關(guān)的約束和限制條件。性能測試包括以下幾個方面:評估系統(tǒng)的能力。測試中得到的負(fù)荷和響應(yīng)時間等數(shù)據(jù)可以被用于驗證所計劃的模型的能力,并幫助做出決策。

識別系統(tǒng)中的弱點。受控的負(fù)荷可以被增加到一個極端的水平并突破它,從而修復(fù)系統(tǒng)的瓶頸或薄弱的地方。系統(tǒng)調(diào)優(yōu)。重復(fù)運行測試,驗證調(diào)整系統(tǒng)的活動得到了預(yù)期的結(jié)果,從而改進(jìn)性能,檢測軟件中的問題。一些常見的性能問題資源泄漏,包括內(nèi)存泄漏資源瓶頸,內(nèi)部資源(線程、放入池的對象)變得稀缺CPU使用率達(dá)到100%、系統(tǒng)被鎖定等

線程死鎖、線程阻塞等

數(shù)據(jù)庫連接成為性能瓶頸

查詢速度慢或列表效率低

受外部系統(tǒng)影響越來越大

性能測試舉例例如對一個網(wǎng)站進(jìn)行測試,模擬10到50個用戶同時在線并觀測系統(tǒng)表現(xiàn),就是在進(jìn)行常規(guī)性能測試;當(dāng)用戶增加到系統(tǒng)出項瓶頸時,如1000乃至上萬個用戶時,就變成了壓力測試。示例加載結(jié)果分析性能測試的分類壓力測試負(fù)載測試14壓力測試的概念壓力測試(StressTesting)是指模擬巨大的工作負(fù)荷,以查看系統(tǒng)在峰值使用情況下是否可以正常運行。壓力測試是通過逐步增加系統(tǒng)負(fù)載來測試系統(tǒng)性能的變化,并最終確定在什么負(fù)載條件下系統(tǒng)性能處于失效狀態(tài),以此來獲得系統(tǒng)性能提供的最大服務(wù)級別的測試。性能測試的步驟確定性能測試需求;計劃和設(shè)計測試;包括確定關(guān)鍵業(yè)務(wù)流程、測試類型和測試方法、選擇合適的測試工具、設(shè)計測試場景等測試工具的選擇;配置測試環(huán)境,盡量接近實際運行環(huán)境,即建立仿真環(huán)境作為性能測試環(huán)境,測試結(jié)果才能可信;實現(xiàn)測試設(shè)計(開發(fā)測試腳本);執(zhí)行測試;分析測試結(jié)果;重復(fù)上述(4)~(6)步驟,直至測試計劃完成,結(jié)果滿意;提交性能測試報告。負(fù)載測試(LoadTest)和并發(fā)測試:負(fù)載測試是通過逐步增加系統(tǒng)工作量,測試系統(tǒng)能力的變化,并最終確定在滿足功能指標(biāo)的情況下,系統(tǒng)所能承受的最大工作量的測試。壓力測試實質(zhì)上就是一種特定類型的負(fù)載測試。并發(fā)性測試是一種測試手段,在壓力測試中可以利用并發(fā)測試來進(jìn)行壓力測試。容量測試18容量測試的概念所謂的容量測試(VolumeTesting)是指,采用特定的手段測試系統(tǒng)能夠承載處理任務(wù)的極限值所從事的測試工作。這里的特定手段是指,測試人員根據(jù)實際運行中可能出現(xiàn)極限,制造相對應(yīng)的任務(wù)組合,來激發(fā)系統(tǒng)出現(xiàn)極限的情況。容量測試的目的容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理。通過測試,預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項指標(biāo)的極限值(如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等),確定系統(tǒng)在其極限值狀態(tài)下是否還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。容量測試往往應(yīng)用于數(shù)據(jù)庫方面的測試數(shù)據(jù)庫容量測試使測試對象處理大量的數(shù)據(jù),以確定是否達(dá)到了將使軟件發(fā)生故障的極限。容量測試還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。容量測試常用的用例設(shè)計方法容量測試常用的用例設(shè)計方法有邊界值分析、錯誤猜測法。常見的容量測試?yán)犹幚頂?shù)據(jù)敏感操作時進(jìn)行的相關(guān)數(shù)據(jù)比較;使用編譯器編譯一個極其龐大的源程序;使用一個鏈接編輯器編輯一個包含成千上萬模塊的程序;一個電路模擬器模擬包含成千上萬塊的電路;一個操作系統(tǒng)的任務(wù)隊列被充滿;一個測試形式的系統(tǒng)被灌輸了大量文檔格式;互聯(lián)網(wǎng)中龐大的E-mail信息和文件信息。健壯性測試24健壯性測試基本概念健壯性測試(RobustnessTesting)主要用于測試系統(tǒng)抵御錯誤的能力。這里的錯誤通常指的是由于設(shè)計缺陷而帶來的系統(tǒng)錯誤測試的重點為當(dāng)出現(xiàn)故障時,是否能夠自動恢復(fù)或忽略故障繼續(xù)運行。兩層含義:一是高可靠性;二是從錯誤中恢復(fù)的能力。健壯性測試方法健壯性測試可以根據(jù)以下方面評價系統(tǒng)的健壯性:通過:系統(tǒng)調(diào)用運行輸入的參數(shù)產(chǎn)生預(yù)期的正常結(jié)果。災(zāi)難性失效:這是系統(tǒng)健壯性測試中最嚴(yán)重的失效,這種失效只有通過系統(tǒng)重新引導(dǎo)才能得到解決。重啟失效:一個系統(tǒng)函數(shù)的調(diào)用沒有返回,使得調(diào)用它的程序掛起或停止。夭折失效:程序執(zhí)行時由于異常輸入,系統(tǒng)發(fā)出錯誤提示使程序中止。沉寂失效:異常輸入時,系統(tǒng)應(yīng)當(dāng)發(fā)出錯誤提示,但是測試結(jié)果卻沒有發(fā)生異常。干擾失效:指系統(tǒng)異常時返回了錯誤的提示,但是該錯誤提示不是期望中的錯誤。設(shè)計健壯性測試的策略基于錯誤的策略:確認(rèn)所有可能的錯誤源,為每一類錯誤開發(fā)錯誤注入技術(shù);基于覆蓋率的策略:接口覆蓋的數(shù)量,故障位置覆蓋的數(shù)量,例外覆蓋的數(shù)量;基于失效的策略:用例設(shè)計故障是否被處理了,例外是否被處理了,一個組件中的失效是否影響另一個組件;健壯性測試用例設(shè)計方法在進(jìn)行健壯性測試時,常用的用例設(shè)計方法主要有三種:故障插入測試,變異測試和錯誤猜測法。健壯性測試方法通常需要構(gòu)造一些不合理的輸入來引誘軟件出錯,如輸入錯誤的數(shù)據(jù)類型,輸入定義域之外的數(shù)值等。兼容性測試29兼容性測試概念兼容性測試是指檢查軟件之間是否能夠正確地進(jìn)行交互和共享信息。對新軟件進(jìn)行軟件兼容性測試,需要解決:1.軟件設(shè)計要求與何種其它平臺和應(yīng)用軟件保持兼容?如果要測試的軟件是一個平臺,那么設(shè)計要求什么應(yīng)用程序在其上運行?2.應(yīng)該遵守何種定義軟件之間交互當(dāng)?shù)貥?biāo)準(zhǔn)或者規(guī)范?3.軟件使用何種數(shù)據(jù)與其它平臺和軟件交互和共享信息?兼容性測試方法確定兼容性測試標(biāo)準(zhǔn)兼容性測試的標(biāo)準(zhǔn)一般可以分以下幾個方面:1.研究可能適用于軟件或者平臺的現(xiàn)有標(biāo)準(zhǔn)和規(guī)范(1)高級標(biāo)準(zhǔn):是產(chǎn)品普遍遵守的規(guī)則。(2)低級標(biāo)準(zhǔn):是本質(zhì)細(xì)節(jié)。兩者都很重要,都需要測試以保證兼容。2.高級標(biāo)準(zhǔn)和規(guī)范兼容性評價模型對新軟件進(jìn)行軟件兼容性測試,兼容性的評價模型包括:

1.軟件設(shè)計要求與何種其它平臺和應(yīng)用軟件保持兼容?如果要測試的軟件是一個平臺,那么設(shè)計要求什么應(yīng)用程序在其上運行?

2.應(yīng)該遵守何種定義軟件之間交互的標(biāo)準(zhǔn)或者規(guī)范?

3.軟件使用何種數(shù)據(jù)與其它平臺和軟件進(jìn)行交互和共享信息?這些問題的答案是基本的靜態(tài)測試——既有黑盒測試,也有白盒測試,包括整體分析產(chǎn)品說明書和所有支持說明書。兼容性測試執(zhí)行

測試軟件是否和系統(tǒng)的其它與之交互的元素之間兼容,如:瀏覽器、操作系統(tǒng)、硬件等。驗證測試對象在不同的軟件和硬件配置中的運行情況。系統(tǒng)兼容性測試B/S系統(tǒng)兼容性測試

C/S系統(tǒng)兼容性測試

安全測試常見安全漏洞分析緩沖區(qū)溢出非常普遍、非常危險的漏洞,在各操作系統(tǒng)、應(yīng)用軟件中廣泛存在,利用緩沖區(qū)溢出可以導(dǎo)致程序運行失敗、系統(tǒng)宕機、重新啟動等后果

可以利用它執(zhí)行非授權(quán)命令、甚至可以取得系統(tǒng)特權(quán),進(jìn)行非法操作緩沖區(qū)溢出攻擊有多種英文名稱:bufferoverflow,bufferoverrun,smashthestack,trashthestack,scribblethestack,manglethestack,memoryleak,overrunscrew;它們指的都是同一種攻擊手段。第一個緩沖區(qū)溢出攻擊--Morris蠕蟲,發(fā)生在1988年,由羅伯特,莫里斯(Rob。rtMorris)制造,它曾造成了全世界6000多臺網(wǎng)絡(luò)服務(wù)器癱瘓。概念緩沖區(qū)溢出是指當(dāng)計算機向緩沖區(qū)內(nèi)填充數(shù)據(jù)位數(shù)時超過了緩沖區(qū)本身的容量溢出的數(shù)據(jù)覆蓋在合法數(shù)據(jù)上,理想的情況是程序檢查數(shù)據(jù)長度并不允許輸入超過緩沖區(qū)長度的字符,但是絕大多數(shù)程序都會假設(shè)數(shù)據(jù)長度總是與所分配的儲存空間相匹配,這就為緩沖區(qū)溢出埋下隱患.操作系統(tǒng)所使用的緩沖區(qū)又被稱為"堆棧".在各個操作進(jìn)程之間,指令會被臨時儲存在"堆棧"當(dāng)中,"堆棧"也會出現(xiàn)緩沖區(qū)溢出。整數(shù)溢出整數(shù)溢出是另外一種常見的由于忽略安全而照成的漏洞。數(shù)據(jù)類型整數(shù)存儲的是一個固定長度的值,應(yīng)嘗試去存儲一個大于這個固定最大值的數(shù)據(jù)時,將會導(dǎo)致一個整數(shù)發(fā)生溢出現(xiàn)象shorta=32768;shortb=1;shortc=a+b;printf(“%d\n”,c);命令注入CommandInjection,即命令注入攻擊,是指這樣一種攻擊手段,黑客通過把HTML代碼輸入一個輸入機制(例如缺乏有效驗證限制的表格域)來改變網(wǎng)頁的動態(tài)生成的內(nèi)容。一個惡意黑客(也被稱為破裂者cracker)可以利用這種攻擊方法來非法獲取數(shù)據(jù)或者網(wǎng)絡(luò)資源。當(dāng)用戶進(jìn)入一個有命令注入漏洞的網(wǎng)頁時,他們的瀏覽器會通譯那個代碼,而這樣就可能會導(dǎo)致惡意命令掌控該用戶的電腦和他們的網(wǎng)絡(luò)。命令注入攻擊最初被稱為Shell命令注入攻擊,是由挪威一名程序員在1997年意外發(fā)現(xiàn)的。第一個命令注入攻擊程序能隨意地從一個網(wǎng)站刪除網(wǎng)頁,就像從磁盤或者硬盤移除文件一樣簡單。SQL注入所謂SQL注入,就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串,最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令,比如先前的很多影視網(wǎng)站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字符暴出的,這類表單特別容易受到SQL注入式攻擊.XSS跨站腳本攻擊跨站腳本攻擊(CrossSiteScripting),為不和層疊樣式表(CascadingStyleSheets,CSS)的縮寫混淆。故將跨站腳本攻擊縮寫為XSS。XSS是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計算機安全漏洞,它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。安裝性測試44安裝性測試的概念安裝性測試的目的就是要驗證系統(tǒng)成功安裝的能力,并保證程序安裝后能正常運行。因此清晰且簡單的安裝過程是系統(tǒng)文檔中最重要的部分。安裝性測試基本方法

安裝測試應(yīng)考慮多個方面的內(nèi)容,其方法和應(yīng)考慮的方面主要有以下:首先,應(yīng)參照安裝手冊中的步驟進(jìn)行安裝,主要考慮到安裝過程中所有的缺省選項和典型選項的驗證。安裝前應(yīng)先備份測試機的注冊表。安裝有自動安裝和手工配置之分,應(yīng)測試不同的安裝組合的正確性,最終使所有組合均能安裝成功。安裝過程中異常配置或狀態(tài)情況(繼電等)要進(jìn)行測試。檢查安裝后能否產(chǎn)生正確或是多余的目錄結(jié)構(gòu)和文件,以及文件屬性是否正確。安裝測試應(yīng)該在所有的運行環(huán)境上進(jìn)行驗證,如操作系統(tǒng),數(shù)據(jù)庫,硬件環(huán)境,網(wǎng)絡(luò)環(huán)境等。至少要在一臺筆記本上進(jìn)行安裝測試,臺式機和筆記本硬件的差別會造成其安裝時出現(xiàn)問題。安裝后應(yīng)執(zhí)行卸載操作,檢測系統(tǒng)是否可以正確完成任務(wù)。檢測安裝該程序是否對其他的應(yīng)用程序造成影響。如有web服務(wù),應(yīng)檢測會不會引起多個web服務(wù)的沖突。配置性測試48配置性測試的概念配置測試(ConfigurationTesting)是驗證系統(tǒng)在不同的系統(tǒng)配置下能否正確工作,這些配置包括:軟件,硬件,網(wǎng)絡(luò)等。如果開始準(zhǔn)備進(jìn)行軟件的配置測試,就要考慮哪些配置與程序的關(guān)系最密切。通常認(rèn)為的理想狀況是所有生產(chǎn)廠家都嚴(yán)格遵照一套標(biāo)準(zhǔn)來設(shè)計硬件,那么所有使用這些硬件的軟件就可以正常運行了,但是在實際應(yīng)用中,標(biāo)準(zhǔn)并沒有被嚴(yán)格遵守,一般都是由各個組織或公司自行定義規(guī)范。配置性測試方法在進(jìn)行配置測試之前,有兩項準(zhǔn)備工作需要提前完成。第一是分離配置缺陷。第二是計算配置測試工作量。配置測試用例從以下方面考慮確定所需的硬件類型。確定有哪些廠商的硬件,型號和驅(qū)動程序可用。確定要測試的設(shè)備驅(qū)動程序,一般選擇操作系統(tǒng)附帶的驅(qū)動程序,硬件附帶的驅(qū)動程序或者硬件或操作系統(tǒng)公司網(wǎng)站上提供的最新的驅(qū)動程序。確定可能的硬件特性,模式和選項。將確定后的硬件配置縮減為可控制的范圍。明確與硬件配置有關(guān)的軟件唯一特性。設(shè)計在每一種配置中執(zhí)行的測試用例。在每種配置中執(zhí)行測試。執(zhí)行測試用例,仔細(xì)記錄并向開發(fā)小組報告結(jié)果,必要時還要向硬件生產(chǎn)廠商報告。明確配置問題的準(zhǔn)確原因通常很困難,并且非常耗時,軟件測試員需要和程序員緊密合作。如果軟件缺陷是硬件的原因,就利用生產(chǎn)廠商的網(wǎng)站向其報告問題。反復(fù)測試直到小組對結(jié)果滿意為止。配置測試一般不會貫穿整個項目期間。最初可能會嘗試一些配置,接著整個測試通過,然后在越來越小的范圍內(nèi)確認(rèn)缺陷的修復(fù)。最后達(dá)到?jīng)]有未解決的缺陷或缺陷限于不常見或不可能的配置上。文檔性測試54

文檔性測試的概念軟件產(chǎn)品由可運行的程序、數(shù)據(jù)和文檔組成。文檔是軟件的一個重要組成部分。在軟件的整個生命周期中,會產(chǎn)生許多文檔,在各個階段中以文檔作為前階段工作成果的總結(jié)和后階段工作的依據(jù)。軟件文檔的分類

用戶文檔

開發(fā)文檔

管理文檔用戶手冊,操作手冊,維護(hù)修改建議軟件需求說明書,數(shù)據(jù)庫設(shè)計說明書,概要設(shè)計說明書,詳細(xì)設(shè)計說明書,可行性研究報告項目開發(fā)計劃,測試計劃,測試報告,開發(fā)進(jìn)度月報。開發(fā)總結(jié)報告文檔性測試的概念文檔測試(DocumentationTesting)主要針對系統(tǒng)提交給用戶的文檔進(jìn)行驗證,目標(biāo)是驗證軟件文檔是否正確記錄系統(tǒng)的開發(fā)全過程的技術(shù)細(xì)節(jié)。通過文檔測試可以改進(jìn)系統(tǒng)的可用性、可靠性、可維護(hù)性和安裝性。文檔測試的內(nèi)容(1)用戶文檔測試內(nèi)容(2)開發(fā)文檔測試內(nèi)容用戶文檔測試內(nèi)容

在用戶文檔測試時,測試人員假定自己是用戶,按照文檔中的說明進(jìn)行操作。在進(jìn)行文檔測試的時候,可以考慮以下幾個方面:把用戶文檔作為測試用例選擇依據(jù);確切的按照文檔所描述的方法使用系統(tǒng);測試每個提示和建議,檢查每條陳述;查找容易誤導(dǎo)用戶的內(nèi)容;用戶文檔測試內(nèi)容把缺陷并入缺陷跟蹤庫;測試每個在線幫助超鏈接;測試每條語句,不要想當(dāng)然;表現(xiàn)的像一個技術(shù)編輯而不是一個被動的評審者;首先對整個文檔進(jìn)行一般的評審,然后進(jìn)行一個詳細(xì)的評審;檢查所有的錯誤信息;用戶文檔測試內(nèi)容測試文檔中提供的每個樣例;保證所有索引的入口有文檔文本;保證文檔覆蓋所有關(guān)鍵用戶功能;保證閱讀類型不是太技術(shù)化;尋找相對比較弱的區(qū)域,這些區(qū)域需要更多的解釋。開發(fā)文檔測試內(nèi)容系統(tǒng)定義的目標(biāo)是否與用戶的要求一致;系統(tǒng)需求分析階段提供的文檔資料是否齊全;文檔中的所有描述是否完整、清晰,準(zhǔn)確地反映用戶要求;與所有其他系統(tǒng)成份的重要接口是否都已經(jīng)描述;被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定;開發(fā)文檔測試內(nèi)容所有圖表是否清楚,在不補充說明時能否理解;主要功能是否已包括在規(guī)定的軟件范圍之內(nèi),是否都己充分說明;軟件的行為和它必須處理的信息、必須完成的功能是否一致;設(shè)計的約束條件或限制條件是否符合實際;是否考慮了開發(fā)的技術(shù)風(fēng)險;開發(fā)文檔測試內(nèi)容是否考慮過軟件需求的其他方案;是否考慮過將來可能會提出的軟件需求;是否詳細(xì)制定了檢驗標(biāo)準(zhǔn),它們能否對系統(tǒng)定義是否成功進(jìn)行確認(rèn);有沒有遺漏、重復(fù)或不一致的地方;用戶是否審查了初步的用戶手冊或原型;項目開發(fā)計劃中的估算是否受到了影響;開發(fā)文檔測試內(nèi)容接口:即分析軟件各部分之間的聯(lián)系,確認(rèn)軟件的內(nèi)部接口與外部接口是否已經(jīng)明確定義。模塊是否滿足高內(nèi)聚低耦合的要求。模塊作用范圍是否在其控制范圍之內(nèi);風(fēng)險:即確認(rèn)該軟件設(shè)計在現(xiàn)有的技術(shù)條件下和預(yù)算范圍內(nèi)是否能按時實現(xiàn);實用性:即確認(rèn)該軟件設(shè)計對于需求的解決方案是否實用;開發(fā)文檔測試內(nèi)容技術(shù)清晰度:即確認(rèn)該軟件設(shè)計是否以一種易于翻譯成代碼的形式表達(dá);可維護(hù)性:從軟件維護(hù)的角度出發(fā),確認(rèn)該軟件設(shè)計是否考慮了方便未來的維護(hù);質(zhì)量:即確認(rèn)該軟件設(shè)計是否表現(xiàn)出良好的質(zhì)量特征;各種選擇方案:看是否考慮過其他方案,比較各種選擇方案的標(biāo)準(zhǔn)是什么;開發(fā)文檔測試內(nèi)容限制:評估對該軟件的限制是否實現(xiàn),是否與需求一致;其他具體問題:對于文檔、可測試性、設(shè)計過程等進(jìn)行評估。文檔性測試方法非代碼的文檔測試主要檢查文檔的正確性、完備性和可理解性。正確性是指不要把軟件的功能和操作寫錯,也不允許文檔內(nèi)容前后矛盾。完備性是指文檔不可以虎頭蛇尾,更不許漏掉關(guān)鍵內(nèi)容。文檔中很多內(nèi)容對開發(fā)者可能是顯然的,但對用戶而言不見得都是顯然的。文檔能否讓大眾用戶看得懂,能否理解術(shù)語?縮寫用戶是否理解?內(nèi)容和主題是否一致?文檔性測試方法行之有效的用戶文檔測試方法可以分兩大類:走查,只通過閱讀文檔,不必執(zhí)行程序就可完成測試,方法有文檔走查、邊界值檢查、標(biāo)識符檢查、標(biāo)題及標(biāo)題編號檢查、引用測試、可用性測試;驗證,對比文檔和程序執(zhí)行結(jié)果,用于測試操作步驟、示例和屏幕截圖,方法有:操作流程檢查、鏈接測試、界面截圖測試。測試技術(shù)適宜找出的Bug類型語言類錯誤版面類錯誤邏輯類錯誤一致性錯誤聯(lián)機文檔功能錯誤文檔走查√√√√√數(shù)據(jù)校對√√操作流程檢查√√引用測試√鏈接測試√可用性測試√界面截圖測試√GUI測試71GUI測試的概念GUI測試是對圖形用戶界面進(jìn)行的測試。一般來說,當(dāng)一個軟件產(chǎn)品完成GUI設(shè)計后,就確定了它的外觀架構(gòu)和GUI元素。進(jìn)入開發(fā)測試階段后,軟件開發(fā)工程師和軟件測試工程師通過對GUI的操作來測試和驗證軟件的功能。GUI測試方法1.基于GUI的手工測試方法。2.基于GUI的自動化測試方法?;贕UI的手工測試方法手工測試方法是按照軟件產(chǎn)品的文檔說明設(shè)計測試用例,依靠人工敲擊鍵盤的方式輸入測試數(shù)據(jù),然后根據(jù)實際的運行結(jié)果與預(yù)期的結(jié)果相比較得出測試結(jié)論。但是當(dāng)今的軟件產(chǎn)品的功能越來越復(fù)雜,越來越完善,一般一套軟件包括豐富的用戶界面,每個界面里又有相當(dāng)數(shù)量的對象元素,所以GUI測試完全依靠手工測試方法是難以達(dá)到測試目標(biāo)的?;贕UI的自動化測試方法GUI的自動化測試方法包括兩個方面:一是選擇一個能夠完全滿足測試自動化需要的測試工具,二是使用編程語言如Java,C++等編寫自動化測試腳本。但是任何一種工具都不能夠完全支持眾多不同應(yīng)用的測試,所以常用的做法是使用一種主要的自動化測試工具,并且使用編程語言編寫自動化測試腳本以彌補測試工具的不足之處。GUI

測試的指南1.窗口窗口是否基于相關(guān)的輸入和菜單命令適當(dāng)?shù)卮蜷_窗口能否改變大小、移動和滾動窗口中的數(shù)據(jù)內(nèi)容能否用鼠標(biāo)、功能鍵、方向鍵和鍵盤訪問當(dāng)被覆蓋并重新調(diào)用后,窗口能否正確地顯示需要時能否使用所有窗口相關(guān)的功能所有窗口相關(guān)的功能是否可操作是否有相關(guān)的下拉式菜單、工具條、滾動條、對話框、按鈕、圖標(biāo)和其他控制可為窗口使用,并適當(dāng)?shù)仫@示顯示多個窗口時,窗口的名稱是否被適當(dāng)?shù)仫@示活動窗口是否被適當(dāng)?shù)丶恿寥绻褂枚嗳蝿?wù),是否所有的窗口被實時更新多次或不正確按鼠標(biāo)是否會導(dǎo)致無法預(yù)料的副作用窗口的聲音和顏色提示與窗口的操作順序是否符合要求窗口是否正確地被關(guān)閉2.下拉式菜單和鼠標(biāo)菜單項是否顯示在合適的語境中應(yīng)用程序的菜單項是否顯示系統(tǒng)相關(guān)的特性(如時鐘顯示)下拉式操作是否運行正確菜單、調(diào)色板和工具條是否運行正確是否適當(dāng)?shù)亓谐隽怂械牟藛喂δ芎拖吕阶庸δ苁欠窨梢酝ㄟ^鼠標(biāo)訪問所有的菜單功能文本字體、大小和格式是否正確是否能夠用其他的文本命令激活每個菜單功能菜單功能是否根據(jù)當(dāng)前的窗口操作加亮或變灰菜單功能是否正確執(zhí)行菜單功能的名字是否具有自解釋性菜單項是否有幫助在整個交互式語境中,是否可以識別鼠標(biāo)操作如果要求多次點擊鼠標(biāo),是否能夠在語境中正確識別光標(biāo)、處理指示器和識別指針是否根據(jù)操作適當(dāng)?shù)馗淖?.?dāng)?shù)據(jù)項字母數(shù)字?jǐn)?shù)據(jù)項是否能夠正確回顯,并輸入到系統(tǒng)中圖形模式的數(shù)據(jù)項(如滾動條)是否正常工作是否能夠識別非法數(shù)據(jù)數(shù)據(jù)輸入消息是否可理解驗收測試79驗收測試的概念驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準(zhǔn)備就緒,并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。實施驗收測試的常用策略主要有三種,分別是正式驗收測試、非正式驗收測試和Beta測試。策略的選擇通常建立在合同需求、公司標(biāo)準(zhǔn)以及應(yīng)用領(lǐng)域的基礎(chǔ)上1.正式驗收測試

正式驗收測試是一項管理嚴(yán)格的過程,它通常是系統(tǒng)測試的延續(xù)。計劃和設(shè)計這些測試的周密和詳細(xì)程度不亞于系統(tǒng)測試。選擇的測試用例應(yīng)當(dāng)是系統(tǒng)測試中所執(zhí)行測試用例的子集,并且不應(yīng)當(dāng)偏離所選擇的測試用例方向。在很多項目中,正式驗收測試是通過自動化測試工具執(zhí)行的。2.非正式驗收測試在非正式驗收測試中,執(zhí)行測試過程的限定不像正式驗收測試中那樣嚴(yán)格,那樣組織有序,而且更為主觀。非正式驗收測試確定并記錄要研究的功能和業(yè)務(wù)任務(wù),但沒有可以遵循的特定測試用例,測試內(nèi)容由各測試人員決定。多數(shù)情況下,非正式驗收測試是由內(nèi)部測試人員組織執(zhí)行的。3.Beta測試在以上三種驗收測試策略中,Beta測試需要的控制是最少的。在Beta測試中,采用的數(shù)據(jù)和方法完全由各測試人員決定。各測試人員負(fù)責(zé)創(chuàng)建自己的環(huán)境,選擇數(shù)據(jù),并決定要研究的功能、特性和任務(wù)。各測試人員負(fù)責(zé)確定自己對于系統(tǒng)當(dāng)前狀態(tài)的接受標(biāo)準(zhǔn)。Beta測試由最終用戶實施,通常開發(fā)組織對最終用戶的管理很少或不進(jìn)行管理。Beta測試是所有驗收測試策略中最主觀的。驗收測試方法1.驗收測試的過程2.驗收測試用例的設(shè)計要點驗收測試的過程(1)軟件需求分析:了解軟件功能和性能要求、軟硬件環(huán)境要求等,并特別要了解軟件的質(zhì)量要求和驗收要求。(2)編制《驗收測試計劃》和《項目驗收準(zhǔn)則》:根據(jù)軟件需求和驗收要求編制測試計劃,制定所需測試的測試項,制定測試策略及驗收通過準(zhǔn)則,并由客戶參與計劃評審。(3)測試設(shè)計和測試用例設(shè)計:根據(jù)《驗收測試計劃》和《項目驗收準(zhǔn)則》編寫測試用例,并經(jīng)過評審。(4)測試環(huán)境搭建:建立測試的硬件環(huán)境、軟件環(huán)境等。(5)測試實施:測試并記錄測試結(jié)果。(6)測試結(jié)果分析:根據(jù)驗收通過準(zhǔn)則分析測試結(jié)果,給出驗收是否通過和測試評價。(7)測試報告:根據(jù)測試結(jié)果編制缺陷報告和驗收測試報告,并提交給客戶。關(guān)于系統(tǒng)測試注意:實際上,以上測試內(nèi)容并不是都要進(jìn)行的,而是在制定測試策略和測試計劃的時候有不同的側(cè)重點,這與測試目標(biāo)、測試資源、軟件系統(tǒng)特點和業(yè)務(wù)環(huán)境有關(guān)。87系統(tǒng)測試過程88與

溫馨提示

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

評論

0/150

提交評論