軟件測試基本理論 2007-10-20 16:52
分類(lèi)：求職就業(yè) 字號： 大大 中中 小小 軟件工程模型
談起測試學(xué)，不得不討論一下軟件工程模型，因為測試學(xué)與軟件工程學(xué)的發(fā)展依依相關(guān)，相輔相成。另外對于比較先進(jìn)的測試理念，測試工程師應該貫穿于軟件工程的整體過(guò)程之中。
瀑布模型
這個(gè)模型大概是現在最經(jīng)典的軟件工程模型，業(yè)務(wù)建模-〉系統分析-〉概要設計-〉詳細設計-〉編碼-〉測試-〉部署。
但是這個(gè)模型存在著(zhù)比較嚴重的問(wèn)題：
1，不可反復，不適應與需求變更處理：由于瀑布模型從業(yè)務(wù)建模到部署一脈相承，不可以回復?，F代軟件項目中需求變更是無(wú)處不存在的：唯一不變的就是需求變更。而運用這種模型，只要項目需求發(fā)生變化，就要打翻重新進(jìn)行系統分析，概要設計，詳細設計…
2，用戶(hù)很難在項目初期了解項目狀態(tài)：由于用戶(hù)在項目初期很難提出自己的需求，他們有時(shí)候也不知道該做些啥？而利用瀑布模型只有到編碼結束，用戶(hù)才可以看到正正他們所需要的產(chǎn)品，而初期這些產(chǎn)品往往是他們所了解不全的，需要補充的，客戶(hù)往往在這個(gè)時(shí)期推翻他們的需求，要求另立需求，這樣往往給客戶(hù)方，需求方帶來(lái)比較麻煩的結果。
迭代模型和螺旋模型：
這兩個(gè)模型往往在概念上區別不明顯，許多書(shū)上將這兩個(gè)模型混為一談。其實(shí)這兩個(gè)模型的思想本質(zhì)上是一致的。他將客戶(hù)的需求按照用戶(hù)的重要等級和模塊自身的等級，從最基礎的進(jìn)行分析，設計，編碼，測試，然后再進(jìn)入下一輪迭代。這樣用戶(hù)可以在每一輪結束就可以看到產(chǎn)品的一些雛形，進(jìn)行需求變更和下一輪的建議，由于初期開(kāi)發(fā)工作比較少，用戶(hù)又可以在產(chǎn)品初期提出相對可觀(guān)的下一輪的需求，所以這樣的模型往往利于現在軟件公司產(chǎn)品的開(kāi)發(fā)，著(zhù)名的RUP工具每一項都遵循迭代的思想。
測試模型
V模型
單元測試--編碼
集成測試--詳細設計
系統測試--總體設計
接收測試--產(chǎn)品
單元測試相對于編碼進(jìn)行，這一步往往由測試人員來(lái)執行；
集成測試相對于詳細設計，他將模塊由上到下，由下到上進(jìn)行逐步的集成。以測試模塊與模塊，類(lèi)與類(lèi)之間的關(guān)聯(lián)性；
系統測試是相對于總體設計而言的，測試人員站在用戶(hù)的角度對系統進(jìn)行全面的測試工作；
接收測試是用戶(hù)對產(chǎn)品進(jìn)行測試，一般分為Alpha測試和Beta測試。Alpha測試一般由公司內部的非技術(shù)人員或非參與人員對產(chǎn)品進(jìn)行的測試；Beta測試往往是指定客戶(hù)對公司進(jìn)行測試，是系統推出市場(chǎng)之前，測試階段推出的第二個(gè)版本。
V模型可以運用于瀑布模型和迭代模型
X模型
X模型是將軟件系統分為若干模塊，對每個(gè)模塊進(jìn)行單元，集成以及系統測試，然后統一對模塊進(jìn)行集成測試，這種測試方法目前軟件行業(yè)處于淘汰趨勢。
前置模型
圖示中所列出的是面向對象的前置模型，其他編成方法的前置模型大小意，就是將測試貫穿于軟件開(kāi)發(fā)的全部過(guò)程。在需求，設計和編碼階段對產(chǎn)生的工件進(jìn)行復審，提出自己的建議和意見(jiàn)。對于前置軟件測試法，bug在軟件前期就可以發(fā)現從而降低軟件開(kāi)發(fā)成本。
不利用前置方法的bug曲線(xiàn)。
利用前置方法的bug曲線(xiàn),bug在開(kāi)始之前就能夠被發(fā)現。
軟件測試方法
白盒 黑盒
動(dòng)態(tài) 就是利用KDE的調試功能逐步調試程序，進(jìn)行測試 就是普通所說(shuō)的通過(guò)人工或者自動(dòng)方法進(jìn)行測試
靜態(tài) 即test review 就是對需求，設計工件進(jìn)行審核
軟件測試步驟
測試計劃
書(shū)寫(xiě)測試用例
開(kāi)發(fā)測試代碼
開(kāi)展測試工作（往往需要進(jìn)行幾次輪測包括測試和復測，每次對于測試中的bug，要求開(kāi)發(fā)人員給與明確答復修改完畢，非法bug以及下一版中解決）
2 評估測試
軟件測試類(lèi)型
1.數據和數據庫完整性測試
在項目名稱(chēng)中，數據庫和數據庫進(jìn)程應作為一個(gè)子系統來(lái)進(jìn)行測試。在測試這些子系統時(shí)，不應將測試對象的用戶(hù)界面用作數據的接口。對于數據庫管理系統 (DBMS)，還需要進(jìn)行深入的研究，以確定可以支持以下測試的工具和技術(shù)。
2.功能測試
對測試對象的功能測試應側重于所有可直接追蹤到用例或業(yè)務(wù)功能和業(yè)務(wù)規則的測試需求。這種測試的目標是核實(shí)數據的接受、處理和檢索是否正確，以及業(yè)務(wù)規則的實(shí)施是否恰當。此類(lèi)測試基于黑盒技術(shù)，該技術(shù)通過(guò)圖形用戶(hù)界面 (GUI) 與應用程序進(jìn)行交互，并對交互的輸出或結果進(jìn)行分析，以此來(lái)核實(shí)應用程序及其內部進(jìn)程。以下為各種應用程序列出了推薦使用的測試概要：
3.UI測試
用戶(hù)界面 (UI) 測試用于核實(shí)用戶(hù)與軟件之間的交互。UI 測試的目標是確保用戶(hù)界面會(huì )通過(guò)測試對象的功能來(lái)為用戶(hù)提供相應的訪(fǎng)問(wèn)或瀏覽功能。另外，UI 測試還可確保 UI 中的對象按照預期的方式運行，并符合公司或行業(yè)的標準。包括用戶(hù)友好性，人性化測試。
4.性能測試
4.1負載測試：
負載測試是一種性能測試。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載測試的目標是確定并確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。
4.2強度測試
是一種性能測試，實(shí)施和執行此類(lèi)測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤(pán)空間不足，測試對象就可能會(huì )表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數據庫鎖或網(wǎng)絡(luò )帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。
4.3容量測試
容量測試使測試對象處理大量的數據，以確定是否達到了將使軟件發(fā)生故障的極限。容量測試還將確定測試對象在給定時(shí)間內能夠持續處理的最大負載或工作量。例如，如果測試對象正在為生成一份報表而處理一組數據庫記錄，那么容量測試就會(huì )使用一個(gè)大型的測試數據庫，檢驗該軟件是否正常運行并生成了正確的報表。
4.4基準測試
與已知系統的比較
4.5競爭測試
軟件競爭使用各種資源（數據紀錄，內存等）
5. 安全性和訪(fǎng)問(wèn)控制測試
安全性和訪(fǎng)問(wèn)控制測試側重于安全性的兩個(gè)關(guān)鍵方面：
應用程序級別的安全性，包括對數據或業(yè)務(wù)功能的訪(fǎng)問(wèn)
系統級別的安全性，包括對系統的登錄或遠程訪(fǎng)問(wèn)。
應用程序級別的安全性可確保：在預期的安全性情況下，主角只能訪(fǎng)問(wèn)特定的功能或用例，或者只能訪(fǎng)問(wèn)有限的數據。例如，可能會(huì )允許所有人輸入數據，創(chuàng )建新賬戶(hù)，但只有管理員才能刪除這些數據或賬戶(hù)。如果具有數據級別的安全性，測試就可確保“用戶(hù)類(lèi)型一” 能夠看到所有客戶(hù)消息（包括財務(wù)數據），而“用戶(hù)二”只能看見(jiàn)同一客戶(hù)的統計數據。
系統級別的安全性可確保只有具備系統訪(fǎng)問(wèn)權限的用戶(hù)才能訪(fǎng)問(wèn)應用程序，而且只能通過(guò)相應的網(wǎng)關(guān)來(lái)訪(fǎng)問(wèn)。
6.故障轉移和恢復測試
可確保測試對象能成功完成故障轉移，并能從導致意外數據損失或數據完整性破壞的各種硬件、軟件或網(wǎng)絡(luò )故障中恢復。
故障轉移測試可確保：對于必須持續運行的系統，一旦發(fā)生故障，備用系統就將不失時(shí)機地“頂替”發(fā)生故障的系統，以避免丟失任何數據或事務(wù)。
恢復測試是一種對抗性的測試過(guò)程。在這種測試中，將把應用程序或系統置于極端的條件下（或者是模擬的極端條件下），以產(chǎn)生故障（例如設備輸入/輸出 (I/O) 故障或無(wú)效的數據庫指針和關(guān)健字）。然后調用恢復進(jìn)程并監測和檢查應用程序和系統，核實(shí)應用程序或系統和數據已得到了正確的恢復。
7.配置測試
配置測試核實(shí)測試對象在不同的軟件和硬件配置中的運行情況。在大多數生產(chǎn)環(huán)境中，客戶(hù)機工作站、網(wǎng)絡(luò )連接和數據庫服務(wù)器的具體硬件規格會(huì )有所不同?？蛻?hù)機工作站可能會(huì )安裝不同的軟件例如，應用程序、驅動(dòng)程序等而且在任何時(shí)候，都可能運行許多不同的軟件組合，從而占用不同的資源。（如瀏覽器版本。OS版本等）
8.安裝測試
安裝測試有兩個(gè)目的。第一個(gè)目的是確保該軟件在正常情況和異常情況的不同條件下: 例如，進(jìn)行首次安裝、升級、完整的或自定義的安裝_都能進(jìn)行安裝。異常情況包括磁盤(pán)空間不足、缺少目錄創(chuàng )建權限等。第二個(gè)目的是核實(shí)軟件在安裝后可立即正常運行。這通常是指運行大量為功能測試制定的測試。
9.本地化測試
又稱(chēng)本地化測試，是指為各個(gè)地方開(kāi)發(fā)產(chǎn)品的測試，如英文版，中文版等等，包括程序是否能夠正常運行，界面是否符合當地習俗，快捷鍵是否正常起作用等等，特別測試在A(yíng)語(yǔ)言環(huán)境下運行B語(yǔ)言軟件（比如在英文win98下試圖運行中文版的程序），出現現象是否正常。
10.文字測試
測試文字是否拼寫(xiě)正確，是否易懂，不存在二義性，沒(méi)有語(yǔ)法錯誤；文字與內容是否由出入等等，包括圖片文字
11.分辨率測試
測試在不同分辨率下，界面的美觀(guān)程度,分為800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字體下測試
12發(fā)布測試
主要在產(chǎn)品發(fā)布前對一些附帶產(chǎn)品，比如說(shuō)明書(shū)，廣告稿等進(jìn)行測試
12.1說(shuō)明書(shū)測試
主要為語(yǔ)言檢查，功能檢查，圖片檢查
語(yǔ)言檢查：檢查說(shuō)明書(shū)語(yǔ)言是否正確，用詞是否易于理解；
功能檢查：功能是否描述完全，或者描述了并沒(méi)有的功能等；
圖片檢查:：檢查圖片是否正確
12.2宣傳材料測試
主要測試產(chǎn)品中的附帶的宣傳材料中的語(yǔ)言，描述功能，圖片
12.3幫助文件測試
幫助文件是否正確，易懂，是否人性化
12.4廣告用語(yǔ)
產(chǎn)品出公司前的廣告材料文字，功能，圖片，人性化的檢查
軟件測試曲線(xiàn)
大家都知道軟件的bug是不可能為零的，它一般隨著(zhù)時(shí)間的推移bug數逼近于零，用一個(gè)曲線(xiàn)圖表示：
這里橫坐標是時(shí)間，縱坐標是還沒(méi)有發(fā)現的bugs數。項目開(kāi)始之前bug為無(wú)窮大，隨著(zhù)時(shí)間的推移，bug趨于零但是不會(huì )等于零。
由于bug不會(huì )等于零，難道產(chǎn)品就不發(fā)布了嗎？還有一種bug可以確定產(chǎn)品發(fā)布時(shí)間。
橫坐標為時(shí)間，縱坐標是已經(jīng)發(fā)現的bugs數，當這個(gè)曲線(xiàn)趨于平穩，也就是說(shuō)它的斜率趨于零的時(shí)候，這個(gè)產(chǎn)品就可以發(fā)布了。
軟件的殺蟲(chóng)劑現象
由于測試人員的思路不盡相同，每個(gè)人測試的側重點(diǎn)不同，由于都按照測試用例進(jìn)行測試，但是測試用例一般僅描述系統的一些基本測試項，不會(huì )將所有的測試用例方方面面都寫(xiě)到，有時(shí)還需要測試人員的經(jīng)驗和素質(zhì)。所以A測試某個(gè)產(chǎn)品用了七個(gè)工作日，第一天到第四天報出許多bug,但從第五天開(kāi)始幾乎報不出啥 bug了。七天后換了B,B一下子又測試出一堆bug,不能說(shuō)A的水平差，只能說(shuō)，該產(chǎn)品已經(jīng)對A產(chǎn)生了抗藥性，這就是測試學(xué)中的殺蟲(chóng)劑現象。用圖表示：
所以在測試中每次輪流測試最好安排不同的測試人員進(jìn)行不同模塊測試工作，以避免殺蟲(chóng)劑現象產(chǎn)生。
