【互聯(lián)網(wǎng)行業(yè)】網(wǎng)站測試-網(wǎng)站測試主要方面的測試方法_第1頁
【互聯(lián)網(wǎng)行業(yè)】網(wǎng)站測試-網(wǎng)站測試主要方面的測試方法_第2頁
【互聯(lián)網(wǎng)行業(yè)】網(wǎng)站測試-網(wǎng)站測試主要方面的測試方法_第3頁
【互聯(lián)網(wǎng)行業(yè)】網(wǎng)站測試-網(wǎng)站測試主要方面的測試方法_第4頁
【互聯(lián)網(wǎng)行業(yè)】網(wǎng)站測試-網(wǎng)站測試主要方面的測試方法_第5頁
已閱讀5頁,還剩6頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

網(wǎng)站測試的主要方面1功能測試對于網(wǎng)站的測試而言,每一個獨立的功能模塊需要單獨的測試用例的設計導出,主要依據(jù)為《需求規(guī)格說明書》及《詳細設計說明書》,對于應用程序模塊需要設計者提供基本路徑測試法的測試用例?!矜溄訙y試鏈接是Web應用系統(tǒng)的一個主要特征,它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面:1)測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面;2)測試所鏈接的頁面是否存在;3)保證Web應用系統(tǒng)上沒有孤立的頁面,所謂孤立頁面是指沒有鏈接指向該頁面,只有知道正確的URL地址才能訪問。鏈接測試可以自動進行,現(xiàn)在已經(jīng)有許多工具可以采用。鏈接測試必須在集成測試階段完成,也就是說,在整個Web應用系統(tǒng)的所有頁面開發(fā)完成之后進行鏈接測試。Xenu------主要測試鏈接的正確性的工具可惜的是對于動態(tài)生成的頁面的測試會出現(xiàn)一些錯誤?!癖韱螠y試當用戶給Web應用系統(tǒng)管理員提交信息時,就需要使用表單操作,例如用戶注冊、登陸、信息提交等。在這種情況下,我們必須測試提交操作的完整性,以校驗提交給服務器的信息的正確性。例如:用戶填寫的出生日期與職業(yè)是否恰當,填寫的所屬省份與所在城市是否匹配等。如果使用了默認值,還要檢驗默認值的正確性。如果表單只能接受指定的某些值,則也要進行測試。例如:只能接受某些字符,測試時可以跳過這些字符,看系統(tǒng)是否會報錯。要測試這些程序,需要驗證服務器能正確保存這些數(shù)據(jù),而且后臺運行的程序能正確解釋和使用這些信息。B/S結構實現(xiàn)的功能可能主要的就在這里,提交數(shù)據(jù),處理數(shù)據(jù)等如果有固定的操作流程可以考慮自動化測試工具的錄制功能,編寫可重復使用的腳本代碼,可以在測試、回歸測試時運行以便減輕測試人員工作量。我們對UM子系統(tǒng)中各個功能模塊中的各項功能進行逐一的測試,主要測試方法為:邊界值測試、等價類測試,以及異常類測試。測試中要保證每種類型都有2個以上的典型數(shù)值的輸入,以確保測試輸入的全面性?!馛ookies測試Cookies通常用來存儲用戶信息和用戶在某應用系統(tǒng)的操作,當一個用戶使用Cookies訪問了某一個應用系統(tǒng)時,Web服務器將發(fā)送關于用戶的信息,把該信息以Cookies的形式存儲在客戶端計算機上,這可用來創(chuàng)建動態(tài)和自定義頁面或者存儲登陸等信息。如果Web應用系統(tǒng)使用了Cookies,就必須檢查Cookies是否能正常工作而且對這些信息已經(jīng)加密。測試的內容可包括Cookies是否起作用,是否按預定的時間進行保存,刷新對Cookies有什么影響等。●設計語言測試Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題,例如使用哪種版本的HTML等。當在分布式環(huán)境中開發(fā)時,開發(fā)人員都不在一起,這個問題就顯得尤為重要。除了HTML的版本問題外,不同的腳本語言,例如Java、JavaScript、ActiveX、VBScript或Perl等也要進行驗證?!駭?shù)據(jù)庫測試在Web應用技術中,數(shù)據(jù)庫起著重要的作用,數(shù)據(jù)庫為Web應用系統(tǒng)的管理、運行、查詢和實現(xiàn)用戶對數(shù)據(jù)存儲的請求等提供空間。在Web應用中,最常用的數(shù)據(jù)庫類型是關系型數(shù)據(jù)庫,可以使用SQL對信息進行處理。在使用了數(shù)據(jù)庫的Web應用系統(tǒng)中,一般情況下,可能發(fā)生兩種錯誤,分別是數(shù)據(jù)一致性錯誤和輸出錯誤。數(shù)據(jù)一致性錯誤主要是由于用戶提交的表單信息不正確而造成的,而輸出錯誤主要是由于網(wǎng)絡速度或程序設計問題等引起的,針對這兩種情況,可分別進行測試。2性能測試網(wǎng)站的性能測試對于網(wǎng)站的運行而言異常重要,但是目前對于網(wǎng)站的性能測試做的不夠,我們在進行系統(tǒng)設計時也沒有一個很好的基準可以參考,因而建立網(wǎng)站的性能測試的一整套的測試方案將是至關重要的。網(wǎng)站的性能測試主要從三個方面進行:連接速度測試、負荷測試(Load)和壓力測試(Stress).連接速度測試指的是打開網(wǎng)頁的響應速度測試。負荷測試指的是進行一些邊界數(shù)據(jù)的測試,壓力測試更像是惡意測試,壓力測試傾向應該是致使整個系統(tǒng)崩潰?!襁B接速度測試用戶連接到Web應用系統(tǒng)的速度根據(jù)上網(wǎng)方式的變化而變化,他們或許是電話撥號,或是寬帶上網(wǎng)。當下載一個程序時,用戶可以等較長的時間,但如果僅僅訪問一個頁面就不會這樣。如果Web系統(tǒng)響應時間太長(例如超過5秒鐘),用戶就會因沒有耐心等待而離開。另外,有些頁面有超時的限制,如果響應速度太慢,用戶可能還沒來得及瀏覽內容,就需要重新登陸了。而且,連接速度太慢,還可能引起數(shù)據(jù)丟失,使用戶得不到真實的頁面。●負載測試負載測試是為了測量Web系統(tǒng)在某一負載級別上的性能,以保證Web系統(tǒng)在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統(tǒng)的用戶數(shù)量,也可以是在線數(shù)據(jù)處理的數(shù)量。例如:Web應用系統(tǒng)能允許多少個用戶同時在線?如果超過了這個數(shù)量,會出現(xiàn)什么現(xiàn)象?Web應用系統(tǒng)能否處理大量用戶對同一個頁面的請求?●壓力測試負載測試應該安排在Web系統(tǒng)發(fā)布以后,在實際的網(wǎng)絡環(huán)境中進行測試。因為一個企業(yè)內部員工,特別是項目組人員總是有限的,而一個Web系統(tǒng)能同時處理的請求數(shù)量將遠遠超出這個限度,所以,只有放在Internet上,接受負載測試,其結果才是正確可信的。進行壓力測試是指實際破壞一個Web應用系統(tǒng),測試系統(tǒng)的反映。壓力測試是測試系統(tǒng)的限制和故障恢復能力,也就是測試Web應用系統(tǒng)會不會崩潰,在什么情況下會崩潰。黑客常常提供錯誤的數(shù)據(jù)負載,直到Web應用系統(tǒng)崩潰,接著當系統(tǒng)重新啟動時獲得存取權。壓力測試的區(qū)域包括表單、登陸和其他信息傳輸頁面等。采用的測試工具:性能測試可以采用相應的工具進行自動化測試,我們目前采用如下工具ab-----Apache的測試工具OpenSTA—開發(fā)系統(tǒng)測試架構3接口測試在很多情況下,web站點不是孤立。Web站點可能會與外部服務器通訊,請求數(shù)據(jù)、驗證數(shù)據(jù)或提交訂單Web應用程序測試方法和測試技術詳述1.概述隨著web應用的增多,新的模式解決方案中以web為核心的應用也越來越多,很多公司各種應用的架構都以B/S及web應用為主,但是有關WEB測試方面的內容并沒有相應的總結,所以我在這里對web的測試方法和采用的測試技術進行總結,便于內部交流。測試方法盡量涵蓋web程序的各個方面,測試技術方面在繼承傳統(tǒng)測試技術的技術上結合web應用的特點。相關的測試和實現(xiàn)技術也有著很大的關系,由于本公司使用J2EE體系,也許例子中只有JAVA平臺可以使用,.NET平臺測試技術暫時不涉及,如果你有請與我聯(lián)系。2.測試方法說明:測試方法的選擇取決你的測試策略。一般的web測試和以往的應用程序的測試的側重點不完全相同,基本包括以下幾個方面。當然圓滿的完成測試還要有好的團體和流程等的方方面面的支持,你同樣應該對這些方面進行注意。有些測試方法設計到了流程,哪些應該在你的測試團隊建設中建立。2.1界面測試現(xiàn)在一般人都有使用瀏覽器瀏覽網(wǎng)頁的經(jīng)歷,用戶雖然不是專業(yè)人員但是對界面效果的印象是很重要的。如果你注重這方面的測試,那么驗證應用程序是否易于使用就非常重要了。很多人認為這是測試中最不重要的部分,但是恰恰相反界面對不懂技術的客戶來說那相當關鍵,慢慢體會你會明白的。方法上可以根據(jù)設計文檔,如果夠專業(yè)的話可以專業(yè)美工人員,來確定整體風格頁面風格,然后根據(jù)這個可以頁面人員可以生成靜態(tài)的HTML,CSS等甚至生成幾套不用的方案來討論,或者交給客戶評審,最后形成統(tǒng)一的風格的頁面/框架。注意不要靠程序員的美術素養(yǎng)形成你的web風格,那樣可能會很糟糕。主要包括以下幾個方面的內容:站點地圖和導航條位置、是否合理、是否可以導航等內容布局布局是否合理,滾動條等簡介說明說明文字是否合理,位置,是否正確背景/色調是否正確、美觀,是否符合用戶需求;頁面在窗口中的顯示是否正確、美觀(在調整瀏覽器窗口大小時,屏幕刷新是否正確)表單樣式大小,格式,是否對提交數(shù)據(jù)進行驗證(如果在頁面部分進行驗證的話)等連接連接的形式,位置,是否易于理解等web測試的主要頁面元素頁面元素的容錯性列表(如輸入框、時間列表或日歷)頁面元素清單(為實現(xiàn)功能,是否將所需要的元素全部都列出來了,如按鈕、單選框、復選框、列表框、超連接、輸入框等等)頁面元素的容錯性是否存在頁面元素的容錯性是否正確頁面元素基本功能是否實現(xiàn)(如文字特效、動畫特效、按鈕、超連接)頁面元素的外形、擺放位置(如按鈕、列表框、核選框、輸入框、超連接等)頁面元素是否顯示正確(主要針對文字、圖形、簽章)元素是否顯示(元素是否存在)頁面元素清單(為實現(xiàn)功能,是否將所需要的元素全部都列出來了,如按鈕、單選框、復選框、列表框、超連接、輸入框等等)測試技術通過頁面走查,瀏覽確定使用的頁面是否符合需求。可以結合兼容性測試對不用分辨率下頁面顯示效果,如果有影響應該交給設計人員提出解決方案??梢越Y合數(shù)據(jù)定義文檔查看表單項的內容,長度等信息。對于動態(tài)生成的頁面最好也能進行瀏覽查看。如Servelet部分可以結合編碼規(guī)范,進行代碼走查。是否支持中文,如果數(shù)據(jù)用XM封裝要做的工作會多一點等等。界面測試要素:符合標準和規(guī)范,靈活性,正確性,直觀性,舒適性,實用性,一致性1.直觀性:用戶界面是否潔凈,不唐突,不擁擠.界面不應該為用戶制造障礙.所需功能或者期待的響應應該明顯,并在預期出現(xiàn)的地方.界面組織和布局合理嗎是否允許用戶輕松地從一個功能轉到另一個功能下一步做什么明顯嗎任何時刻都可以決定放棄或者退回,退出嗎輸入得到承認了嗎菜單或者窗口是否深藏不露有多余功能嗎軟件整體抑或局部是否做得太多是否有太多特性把工作復雜化了是否感到信息太龐雜如果其他所有努力失敗,幫助系統(tǒng)真能幫忙嗎2.一致性快速鍵和菜單選項.在Windows中按F1鍵總是得到幫助信息術語和命令.整個軟件使用同樣的術語嗎特性命名一致嗎例如,Find是否一直叫Find,而不是有時叫Search軟件是否一直面向同一級別用戶帶有花哨用戶界面的趣味賀卡程序不應該顯示泄露技術機密的錯誤提示信息.按鈕位置和等價的按鍵.大家是否注意到對話框有OK按鈕和Cance按鈕時,OK按鈕總是在上方或者左方,而Cance按鈕總是在下方或右方同樣原因,Cance按鈕的等價按鍵通常是Esc,而選中按鈕的等價按鈕通常是Enter.保持一致.3.靈活性狀態(tài)跳轉.靈活的軟件實現(xiàn)同一任務有多種選擇方式.狀態(tài)終止和跳過,具有容錯處理能力.數(shù)據(jù)輸入和輸出.用戶希望有多種方法輸入數(shù)據(jù)和查看結果.例如,在寫字板插入文字可用鍵盤輸入,粘貼,從6種文件格式讀入,作為對象插入,或者用鼠標從其他程序拖動.4.舒適性恰當.軟件外觀和感覺應該與所做的工作和使用者相符.錯誤處理.程序應該在用戶執(zhí)行嚴重錯誤的操作之前提出警告,并允許用戶恢復由于錯誤操作導致丟失的數(shù)據(jù).如大家認為undo/redo是當然的.性能.快不見得是好事.要讓用戶看得清程序在做什么,它是有反應的.2.2功能測試對功能測試是測試中的重點主要包括一下幾個方面的內容連接這個連接和界面測試中的連接不同那里注重的是連接方式和位置,如是圖像還是文字放置的位置等,還是其他的方式。這里的連接注重功能。如是否有連接,連接的是否是說明的位置等。表單提交應當模擬用戶提交,驗證是否完成功能,如注冊信息,要測試這些程序,需要驗證服務器能正確保存這些數(shù)據(jù),而且后臺運行的程序能正確解釋和使用這些信息。還有數(shù)據(jù)正確性驗證,異常處理等,最好結合易用性要求等。B/S結構實現(xiàn)的功能可能主要的就在這里,提交數(shù)據(jù),處理數(shù)據(jù)等如果有固定的操作流程可以考慮自動化測試工具的錄制功能,編寫可重復使用的腳本代碼,可以在測試、回歸測試時運行以便減輕測試人員工作量。Cookies驗證如果系統(tǒng)使用了cookie,測試人員需要對它們進行檢測。如果在cookies中保存了注冊信息,請確認該cookie能夠正常工作而且已對這些信息已經(jīng)加密。如果使用cookie來統(tǒng)計次數(shù),需要驗證次數(shù)累計正確。關于cookie的使用可以參考瀏覽器的幫助信息。如果使用B/S結構cookies中存放的信息更多。功能易用性測試完成了功能測試可以對應用性進行了解,最好聽聽客戶的反映,在可以的情況下對程序進行改進是很有必要的,和客戶保持互動對系統(tǒng)滿意度也是很有幫助的。測試技術功能測試的測試技術可是很多的,我們可以結合實際環(huán)境選擇使用白盒測試技術(WhiteBoxTesting)深入到代碼一級的測試,使用這種技術發(fā)現(xiàn)問題最早,效果也是最好的。該技術主要的特征是測試對象進入了代碼內部,根據(jù)開發(fā)人員對代碼和對程序的熟悉程度,對有需要的部分進行在軟件編碼階段,開發(fā)人員根據(jù)自己對代碼的理解和接觸所進行的軟件測試叫做白盒測試。這一階段測試以軟件開發(fā)人員為主,在JAVA平臺使用Xunit系列工具進行測試,Xunit測試工具是類一級的測試工具對每一個類和該類的方法進行測試。黑盒測試技術(BlackBoxTesting)黑盒測試的內容主要有以下幾個方面,但是主要還是功能部分。主要是覆蓋全部的功能,可以結合兼容,性能測試等方面進行,根據(jù)軟件需求,設計文檔,模擬客戶場景隨系統(tǒng)進行實際的測試,這種測試技術是使用最多的測試技術涵蓋了測試的方方面面,可以考慮以下方面正確性(Correctness):計算結果,命名等方面可用性(Usability):是否可以滿足軟件的需求說明。邊界條件(BoundaryCondition)輸入部分的邊界值,就是使用一般書中說的等價類劃分,試試最大最小和非法數(shù)據(jù)等等.性能(Performance)正常使用的時間內系統(tǒng)完成一個任務需要的時間,多人同時使用的時候響應時間,在可以接受范圍內.J2EE技術實現(xiàn)的系統(tǒng)在性能方面更是需要照顧的,一般原則是3秒以下接受,3-5秒可以接受,5秒以上就影響易用性了.如果在測試過程中發(fā)現(xiàn)性能問題,修復起來是非常艱難的,因為這常常意味著程序的算法不好,結構不好,或者設計有問題。因此在產品開發(fā)的開始階段,就要考慮到軟件的性能問題壓力測試(Stress)多用戶情況可以考慮使用壓力測試工具,建議將壓力和性能測試結合起來進行.如果有負載平衡的話還要在服務器端打開監(jiān)測工具,查看服務器CPU使用率,內存占用情況,如果有必要可以模擬大量數(shù)據(jù)輸入,對硬盤的影響等等信息.如果有必要的話必須進行性能優(yōu)化(軟硬件都可以).這里的壓力測試針對的是某幾項功能,.錯誤恢復(ErrorRecovery)錯誤處理,頁面數(shù)據(jù)驗證,包括突然間斷電,輸入臟數(shù)據(jù)等.安全性測試(Security)這個領域正在研究中,不過防火墻,補丁包.殺毒軟件等的就不必說了,不過可以考慮破壞性測試時任意.看了一些資料后得知,這里面設計到的知識\內容可以寫本書了,不是一兩句可以說清的,特別是一些商務網(wǎng)站,或者跟錢有關,或者和公司秘密有關的web更是,需要這方面的測試,在外國有一種專門干這一行的人叫安全顧問,可以審核代碼,提出安全建議,出現(xiàn)緊急事件是的處理辦法等,在國內沒有聽說哪里有專門搞安全技術測試的內容.兼容性(Compatibility)不同瀏覽器,不同應用程序版本在實現(xiàn)功能時的表現(xiàn),不同的上網(wǎng)方式,如果你測試的是一個公共網(wǎng)站的話.兼容性測試內容詳述硬件平臺瀏覽器軟件和版本:瀏覽器插件,瀏覽器選項,視頻分辨率和色深.文字大小,調制解調器速率.軟件配置(Configuration)如IE瀏覽器的不用選項-安全設定最高,禁用腳本程序,等等,你們的程序在各種不用的設置下表現(xiàn)如何.單元測試技術(UnitTest):2.2.1下面是對白盒測試和單元測試的區(qū)別的論述:單元測試和白盒測試是不同的,雖然單元測試和白盒測試都是關注功能雖然他們都需要代碼支持,但是級別不同,白盒測試關注的是類中一個方法的功能是更小的單位,但是完成一個單元測試可能需要N多類,所以說作單元測試需要什么寫驅動和穩(wěn)定樁,比如查詢單元是一個查詢包包N多的測試類,測試數(shù)據(jù),運行他需要提供數(shù)據(jù)的部分,輸入?yún)?shù)和發(fā)出命令的驅動等等.是比類大的一個整體進行的.另一個明顯的區(qū)別是白盒測試不會關注類接口,但是單元測試主要的內容就是類接口測試.不過很多時候是很少區(qū)分的,因為這兩種技術實現(xiàn)起來有很多相互關聯(lián)的部分.不過要看你對質量的關注程度來決定.2.2.2功能測試邊界測試\越界測試技術詳述邊界條件邊界條件是指軟件計劃的操作界限所在的邊緣條件.如果軟件測試問題包含確定的邊界,那么數(shù)據(jù)類型可能是:數(shù)值速度字符地址位置尺寸數(shù)量同時,考慮這些類型的下述特征:第一個/最后一個最小值/最大值開始/完成超過/在內空/滿最短/最長最慢/最快最早/最遲最大/最小最高/最低相鄰/最遠越界測試通常是簡單加1或者很小的數(shù)(對于最大值)和減少1或者很小的數(shù)(對于最小值),例如:第一個減1/最后一個加1開始減1/完成加1空了再減/滿了再加慢上加慢/快上加快最大數(shù)加1/最小數(shù)減1最小值減1/最大值加1剛好超過/剛好在內短了再短/長了再長早了更早/晚了更晚最高加1/最低減1另一些該注意的輸入:默認,空白,空值,零值和無;非法,錯誤,不正確和垃圾數(shù)據(jù).2.2.3狀態(tài)測試技術軟件可能進入的每一種獨立狀態(tài);從一種狀態(tài)轉入另一種狀態(tài)所需的輸入和條件;進入或退出某種狀態(tài)時的設置條件及輸入結果.具體測試方法可以參考如下:每種狀態(tài)至少訪問一次;測試看起來最常見最普遍的狀態(tài)轉換;測試狀態(tài)之間最不常用的分支測試所有錯誤狀態(tài)及其返回值測試隨機狀態(tài)轉換2.2.4競爭條件測試技術競爭條件典型情形參考如下:兩個不同的程序同時保存或打開同一個文檔共享同一臺打印機,通信端口或者其他外圍設備當軟件處于讀取或者修改狀態(tài)時按鍵或者單擊鼠標同時關閉或者啟動軟件的多個實例同時使用不同的程序訪問一個共同數(shù)據(jù)庫2.3負載\壓力測試(StressTest)在這里的負載\壓力和功能測試中的不同,他是系統(tǒng)測試的內容,是基本功能已經(jīng)通過后進行的.可以在集成測試階段,亦可以在系統(tǒng)測試階段進行.使用負載測試工具進行,虛擬一定數(shù)量的用戶看一看系統(tǒng)的表現(xiàn),是否滿足定義中的指標.負載測試一般使用工具完成,oadrunner,weboad,was,ew,e-test等,主要的內容都是編寫出測試腳本,腳本中一般包括用戶一般常用的功能,然后運行,得出報告。所以負載測試包括的主要內容就不介紹了。負載測試技術在各種極限情況下對產品進行測試(如很多人同時使用該軟件,或者反復運行該軟件),以檢查產品的長期穩(wěn)定性。例如,使用壓力測試工具對web服務器進行壓力測試.本項測試可以幫助找到一些大型的問題,如死機、崩損、內存泄漏等,因為有些存在內存泄漏問題的程序,在運行一兩次時可能不會出現(xiàn)問題,但是如果運行了成千上萬次,內存泄漏得越來越多,就會導致系統(tǒng)崩滑。用J2EE實現(xiàn)的系統(tǒng)很少但是并不是沒有內存問題.無論什么工具基本的技術都是利用線程技術模仿和虛擬用戶,在這里主要的難點在與測試腳本的編寫,每種工具使用的腳本都不一樣,但是大多數(shù)工具都提供錄制功能就算是不會編碼的測試人員同樣可以測試。對負載工具的延伸使用可以進行系統(tǒng)穩(wěn)定性測試,系統(tǒng)極限測試,如使用100的oadSize連續(xù)使用24小時,微軟定義的通過準則是通過72小時測試的程序一般不會出現(xiàn)穩(wěn)定性的問題。2.4回歸測試(RegressionTest)過一段時間以后,再回過頭來對以前修復過的Bug重新進行測試,看該Bug是否會重新出現(xiàn)。回歸測試技術可以在測試的各個階段出現(xiàn),無論是單元測試還是集成測試還是系統(tǒng)測試。是對以前問題進行驗證的過程。回歸測試的目的就是保證以前已經(jīng)修復的Bug不會再出現(xiàn)。實際上,許多Bug都是在回歸測試時發(fā)現(xiàn)的,在此階段,我們首先要檢查以前找到的Bug是否已經(jīng)更正了。值得注意的是,已經(jīng)更正的Bug也可能又回來了,有的Bug經(jīng)過修改之后可能又產生了新的Bug。所以,回歸測試可保證已更正的Bug不再重現(xiàn),不產生新的Bug。2.5Apha和Beta測試(AphaandBetaTest):在正式發(fā)布產品之前往往要先發(fā)布一些測試版,讓用戶能夠反饋出相關信息,或者找到存在的Bug,以便在正式版中得到解決。特別是在有客戶參加的情況下,對系統(tǒng)進行測試可能會出現(xiàn)一些我們沒有考慮的情況,還可以解決一些客戶實際關心的問題不同的測試技術區(qū)分3.1覆蓋測試技術說明:測試覆蓋率可以看出測試的完成度,在測試分析報告中可以作為量化指標的依據(jù),測試覆蓋率越高效果越好。覆蓋測試可以是程序代碼的執(zhí)行路徑覆蓋,亦可以是功能實現(xiàn)的步驟覆蓋(可以理解成流程圖的路徑覆蓋)。該技術可以用在任何測試階段,包括單元測壞死、集成測試、系統(tǒng)測試。使用該技術時可以使用以上的任何測試方法和測試技術。3.2白盒測試和黑盒測試技術白盒測試技術(WhiteBoxTesting)該技術主要的特征是測試對象進入了代碼內部,根據(jù)開發(fā)人員對代碼和對程序的熟悉程度,對有需要的部分進行在軟件編碼階段,開發(fā)人員根據(jù)自己對代碼的理解和接觸所進行的軟件測試叫做白盒測試。這一階段測試以軟件開發(fā)人員為主,使用Xunit系列工具進行測試,可以包括很多方面如功能性能等。黑盒測試(BlackBoxTesting)測試的主體部分黑盒測試的內容主要有以下幾個方面,但是主要還是功能部分。主要是覆蓋全部的功能,可以結合兼容,性能測試等方面進行,包括的不同測試類型請參考以上內容。3.3手工測試和自動化測試手工測試(ManualTesting):即依靠人力來查找Bug。方法可以參考上邊的測試,也可以根據(jù)對實現(xiàn)技術及經(jīng)驗等進行不同的測試。自動測試(AutomationTesting)使用有針對工具實行??梢宰鞒鲎詣踊瘻y試的計劃,對可以進行自動化測試的部分編寫或者錄制相應的腳本,可以加入功能,容錯,表單提交等,可以參考MI,Rationa或者其他類測試工具說明.根據(jù)權威的軟件測試經(jīng)驗,手工測試還是主要的測試方法,自動測試不夠靈活,在這里不再詳述。微軟的測試過程80%還是手工完成。自動測試永遠也代替不了手工測試,但是手工測試的工作量很大是不爭的事實。3.4根據(jù)RUP標準按階段區(qū)分測試單元測試在上邊有詳細的敘述,還有針對單元測試和集成測試的論述,請參考。集成測試分為功能集成測試和系統(tǒng)集成測試,相互有調用的功能集成,在系統(tǒng)環(huán)境下功能相互調用的影響等,使用方法可以任意選用上面的內容。注重功能方面。系統(tǒng)測試在功能實現(xiàn)的基礎上,可以加入兼容性,易用性,性能等等驗收測試可以包括Alpha和Beta測試,在這里就不再詳述。4.存在風險及解決方法說明:測試不能找出所有的問題,只是盡量將問題在開發(fā)階段解決大多數(shù)的問題而已。測試風險如下:軟硬件的測試環(huán)境提供上也對測試結果有很大的影響。測試團隊的水平,經(jīng)驗,合作效果等整個開發(fā)流程對測試的重視程度,測試的進

溫馨提示

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

評論

0/150

提交評論