第一篇：軟件測試工作中使用QTP的總結(jié)

軟件測試工作中使用QTP的總結(jié)---轉(zhuǎn)

上一篇 / 下一篇2009-08-18 13:26:28 / 個人分類：測試

查看(68)/ 評論(1)/ 評分(1 / 0)

工具軟件一段時間不用就容易手生，有個備份整理以后復(fù)習(xí)都事半功倍。之前就打算好好弄一下一直拖著沒動筆。網(wǎng)上QTP的學(xué)習(xí)資料大把大把，那些基礎(chǔ)的理論東西看過就過了，實踐才是王道，操作幾個小時勝過看一天的說明文檔。這里列一些我在用QTP時遇到印象比較深刻的問題和解決方案，其他的小問題屬于QTP熟練操作的范疇就不贅述了。因為項目需要接觸了差不多三個月的QTP，自知離QTP高手還有段距離，學(xué)無止盡，有學(xué)習(xí)QTP的朋友歡迎發(fā)表高見大家互相進步~

1、QTP自帶函數(shù)print

調(diào)試代碼的時候一般習(xí)慣用Debug或者Msgbox函數(shù)。監(jiān)視變量運行時的值用Msgbox，個人感覺不方便的一點就是每次在msgbox窗口彈出來后，腳本會暫停執(zhí)行，等到鼠標點確定后窗口才會關(guān)閉繼續(xù)運行后續(xù)腳本，真的很煩，做自動化測試的時候我真的是已經(jīng)懶到不愿意動一根手指頭。某天無意發(fā)現(xiàn)QTP自帶的函數(shù)print也可以實現(xiàn)查看變量信息，窗口是非模式的，運行時變量值在 QuickTest Print Log窗口上輸出但腳本不用停下來等，而且可以在一個session運行完了之后查看所有需要監(jiān)視的變量值。

Eg:

Dim p

p=Browser(“xx”).page.(“xx”).webedit(“object_name”).GetROProperty(“value”)

print p2、calender控件

一般日期格式字段是同時支持手填日期格式的text field和用鼠標點日歷控件選擇。但是在DMPOD系統(tǒng)里發(fā)現(xiàn)部分日期格式的字段居然disable了用戶手動輸入的屬性，只能靠點日歷控件來選擇日期。結(jié)果錄到的腳本全變成了img.click，無法回放。查了很久突然某一天找到了辦法，繞過這個控件，強制轉(zhuǎn)換它的屬性值。

Eg:

Dim var_object

Set var_object=Browser(“xx”).page(“xx”).webedit(“calendar_name”).Object

Var_object.readonly=false

Browser(“xx”).page(“xx”).webedit(“calendar_name”).set “4/24/2009”

3、homepage menu

曾經(jīng)困擾了我很久。Homepage dropdown menu 需要鼠標移動到主菜單名上才會顯示子菜單目錄，click子菜單目錄進入頁面。QTP總是無法捕捉到鼠標移動帶出子菜單目錄這個操作，解決辦是用mouseover。

Eg:

Browser(“xx”).page(“xx”).webelment(“homepage menu name”).FireEvent “onMouseOver”

Browser(“xx”).page(“xx”).webelment(“sub menu name”).Click4、自定義checkpoint

在頁面提交保存后，自定義設(shè)置一個檢查點，通過判斷某個變量值是否滿足預(yù)期，如果是，則保存成功，如果不是則保存失敗。

Eg:

If Browser(“xx”).page.(“xx”).webedit(“object_name”).GetROProperty(“value”)=“AA” Then

Reporter.ReportEvent micPass,“AA checkpoint”,“page is saved successfully”

Else Reporter.ReportEvent micFail,“AA checkpoint”,“page is not saved successfully”

End If5、編程性描述語言識別對象

剛開始一段時間，一直不知道QTP除了用對象庫識別對象外，還可以用編程性描述語言。后來查了網(wǎng)上的資料才明白過來。

第一種方法：

Browser(“CreationTime:=0”).Page(“index:=1”).WebEdit(“name:=” & edit).Set “ha”

我沒有嘗試過，總感覺不如對象庫來的方便，在對象庫中可以直接選擇和修改用來識別對象的屬性，以及highlight object等功能。

第二種方法：

碰到過一個Case是，頁面上table A里的checkbox元素數(shù)量每次運行時都是不相同的，隨著頁面上另一個對象B的值而改變，對象B的值又是參數(shù)化的，最后造成checkbox數(shù)量運行前無法預(yù)知。操作時又需要每次都選上所有的checkbox。最后用這種識別對象方法可以順利實現(xiàn)。

Public function SelectAllCheckBox()

Set NewObject = Description.Create '創(chuàng)建滿足下面三個條件的對象集

NewObject(“micclass”).value =“WebCheckBox”

NewObject(“html tag”).value=“INPUT”

NewObject(“class”).value = “checkBox_class”

Set NewObjects = Browser(“xx”).Page(“xx”).ChildObjects(NewObject)'實際運行時的對象

Numbers = NewObjects.Count 'checkbox的個數(shù)

For i = 0 to NewObjects.count –1 '循環(huán)

NewObjects(i).Set “ON” '每一個checkbox都set on

Next

End Function6、相對路徑

Setting: Tool--option--folder

經(jīng)常有action調(diào)用別的test里的action或者外部vbs文件，訪問功能庫和環(huán)境變量，這時使用相對路徑可以保存有效的路徑信息，提高了腳本可移植性。因為腳本文件是需要復(fù)制到別的機器共享給其他同事用的。

7、正則表達式對象庫里對每個對象都可以設(shè)置是否用正則表達式來參數(shù)化識別。腳本里也可以用。

當(dāng)時的case是，頁面提交保存完了會自動生成一個文檔號，文檔號是需要輸出到data table里，但是那個字段developer在設(shè)計的時候居然用了一個webelment的類而且字段值居然是整個table的name，如―xyz— ABC20090101‖，我只要后面的文檔號前面的―xyz—‖是多余的，需要拿到這個對象值后轉(zhuǎn)換成正確的字符串格式才能輸出到data table里。

Eg:

Function regEXfun(patrn,strng)

Dim regEX,Match,Matches

Set regEX = New RegExp

regEX.Pattern=patrn

regEX.IgnoreCase=False

Set Matches =regEX.Execute(strng)

Set Match=Matches(0)

RetStr=Match.value

regEXfun=RetStr

End Function

Dim preNO,newNO

preNO=Browser(“xx”).Page(“xx”).WebElement(“NO”).GetROProperty(“innertext”)

newNO=regEXfun(“ABC……..”,preNO)'雖然每次NO都不一樣，但是格式是固定的：字符串長度總是11位，以ABC開始，后面的數(shù)字是隨機，所以用ABC來匹配字符串

DataTable.Value(“NO”,dtGlobalSheet)=newNO8、密碼

如果登錄頁面的密碼數(shù)據(jù)來源是data table，那么要提前準備密碼。顯然只能用明文，比如123456，但是QTP錄制輸入密碼時自動生成的腳本是用SetSecure的方法生成一大串密文，如果這樣每次改密碼的時候都要用密文到data table里，很郁悶，這種case時只要手動把SetSecure改為Set就OK啦~

9、waitproperty

在用QTP的過程中,有時因為要等待某個對象的值出現(xiàn)，加上wait()方法.但是wait里的時間參數(shù),是根據(jù)經(jīng)驗估計出來的, 這個對象每次運行時可能需要load的時間不一樣，有時候9秒有時候3秒，只好設(shè)置成wait(10),讓QTP等10秒，但是如果對象在10秒內(nèi)已經(jīng) load完,QTP還是會繼續(xù)等到10秒后才往下繼續(xù)執(zhí)行,浪費了很多時間.有個辦法是用waitproperty 方法.這樣這個對象在10內(nèi)出現(xiàn)的話，QTP就會繼續(xù)往下執(zhí)行腳本，不用等完10秒。

Browser(“xx”).Page(“xx”).WebButton(“abc”).WaitProperty “visible”,true,10

第二篇：軟件測試 QTP教學(xué)演示文檔

risfeng.web-105.com 教學(xué)演示--注冊tester參數(shù)化測試

risfeng.web-105.com

risfeng.web-105.com

risfeng.web-105.com

教學(xué)演示--注冊tester參數(shù)化測試+文字驗證：

risfeng.web-105.com

risfeng.web-105.com

輸出值功能例子：

risfeng.web-105.com

risfeng.web-105.com

第三篇：軟件測試總結(jié)

1.軟件測試定義：由人工或自動方法來執(zhí)行或評價系統(tǒng)或系統(tǒng)部分的過程，以驗證它是否滿足規(guī)定的需求，或識別出期望的結(jié)果和實際結(jié)果之間的差異。2.軟件測試的分類：

測試對象或范圍分類：需求評審、設(shè)計評審、單元測試、程序測試、系統(tǒng)

測試、文檔測試、Web應(yīng)用測試、客戶端測試、數(shù)據(jù)庫測試等；

測試目的分類：集成測試、功能測試、壓力測試、性能測試等等； 靜態(tài)測試、動態(tài)測試； 白盒測試、黑盒測試。3.軟件測試的基本流程與原則

基本流程：

測試用例設(shè)計-輸入數(shù)據(jù)、預(yù)期結(jié)果； 測試執(zhí)行-輸入數(shù)據(jù)執(zhí)行被測對象； 檢查實際輸出與預(yù)期結(jié)果。基本原則：

開始測試時認定軟件有錯，測試要證明有錯； 測試應(yīng)該由獨立的測試團隊來完成； 測試設(shè)計必須設(shè)計對應(yīng)的預(yù)期輸出；

要對合理、不合理（有效、無效）輸入數(shù)據(jù)都進行測試； 檢查軟件的完備性、多余； 完整保留測試文檔；

一個被測對象中有錯誤的概率與已發(fā)現(xiàn)錯誤的個數(shù)成正比。4.Beizer測試成熟度級別：

0級：沒有區(qū)分測試與調(diào)試；

1級：測試的目的是證明軟件能用； 2級：測試的目的是證明軟件不能用；

3級：測試的目的不是為了證明什么，而是為了降低軟件使用風(fēng)險； 4級：測試是一種智能訓(xùn)練，能夠幫助專業(yè)人員開發(fā)出更高質(zhì)量的軟件。5.軟件測試與軟件工程，軟件過程的關(guān)系：

軟件工程：在給定的條件下（成本、時間）開發(fā)出高質(zhì)量的軟件產(chǎn)品。軟件生產(chǎn)過程的特性決定了軟件產(chǎn)品中不可避免包含有錯誤。軟件測試則是盡可能多地發(fā)現(xiàn)錯誤，從而保障軟件產(chǎn)品的質(zhì)量。6.McCall的質(zhì)量因素：

產(chǎn)品修改：

可維護性，靈活性，可測試性 產(chǎn)品轉(zhuǎn)移：

可移植性，可復(fù)用性，互操作性 產(chǎn)品運行：

正確性，易用性，可靠性，效率，完整性 7.軟件質(zhì)量困境

軟件質(zhì)量必須足夠好：存在價值

軟件產(chǎn)品無法完美：需要消耗過多的資源、時間、成本

軟件開發(fā)需要在兩個極端之間進行平衡：軟件足夠好的同時又不完美。8.質(zhì)量控制、質(zhì)量保證和質(zhì)量管理

軟件質(zhì)量控制其實是基本方法，通過一系列的技術(shù)來科學(xué)地測量過程的狀態(tài)。如缺陷率、測試覆蓋率等。

軟件質(zhì)量保證則是過程的參考、指南的集合，如ISO9000、CMM/CMMI等，著重內(nèi)部的檢查，確保已獲取認可的標準和步驟都已經(jīng)遵循。

軟件質(zhì)量管理則是實際操作的思想，質(zhì)量管理控制和協(xié)調(diào)組織的質(zhì)量活動，包括質(zhì)量控制、質(zhì)量保證和質(zhì)量改進。9.WebApp應(yīng)用的屬性：

網(wǎng)絡(luò)密集型應(yīng)用；并發(fā)性；大負載量；性能；高可靠性、高可用性；安全性-內(nèi)容敏感；

10.軟件評審的目的，評審度量及其應(yīng)用

評審的目標在于：盡早發(fā)現(xiàn)軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續(xù)活動，防止錯誤轉(zhuǎn)化為缺陷。

準備工作量Ep-實際評審會之前所需工作量； 評估工作量Ea-實際評審所花費的工作量 返工工作量Er-修改評審所發(fā)現(xiàn)錯誤的工作量 工作產(chǎn)品規(guī)模WPS-評審對象的規(guī)模

發(fā)現(xiàn)的主要錯誤數(shù)Errmajor-多于預(yù)期的改錯工作量的錯誤數(shù)目 發(fā)現(xiàn)的次要錯誤數(shù)Errminor-少于預(yù)期的改錯工作量的錯誤數(shù)目 總評審工作量Ereview = Ep+Ea+Er 錯誤總數(shù)Errtot = Errmajor+Errminor 錯誤密度：評審的每單位工作產(chǎn)品發(fā)現(xiàn)的錯誤數(shù)Ed = Errtot / WPS 錯誤密度數(shù)值的含義：較小（產(chǎn)品質(zhì)量非常好或評審不夠徹底）；較大（產(chǎn)品質(zhì)量存在缺陷）

11.軟件測試計劃：描述對計算機軟件配置項、子系統(tǒng)、系統(tǒng)進行測試的計劃安排，內(nèi)容包括測試的環(huán)境、測試工作的標識及測試工作的時間安排。

軟件測試報告：是對計算機軟件配置項、軟件系統(tǒng)或子系統(tǒng)，或與軟件相關(guān)項目執(zhí)行合格性測試的記錄 12.軟件測試活動

制訂測試計劃（測試分析員）

測試設(shè)計（測試設(shè)計人員）－方案設(shè)計 測試及測試用例設(shè)計 測試過程

樁模塊、驅(qū)動模塊設(shè)計

測試實施（測試設(shè)計員）－實現(xiàn)測試設(shè)計 單元測試（測試員）集成測試（測試員）系統(tǒng)測試（測試員）

評估測試（測試設(shè)計人員）

13.無向圖的相關(guān)定義：

連接性：節(jié)點ni、nj是連接的，當(dāng)且僅當(dāng)ni、nj在同一條路徑上。組件：圖的組件是相連節(jié)點的最大集合

圖G的圈復(fù)雜度V（G)＝e－n＋2p，其中e為G的邊數(shù)，n為節(jié)點數(shù)，p為組件數(shù)。14.圖覆蓋：給定一個關(guān)于圖G的準則C的測試需求集合TR，測試集合T在圖G上滿足準則C當(dāng)且僅當(dāng)對TR中每個測試需求tr，path(T)中至少存在一條測試路徑p滿足tr。

簡單路徑：如果從ni到nj的一條路徑中，除了始節(jié)點和終節(jié)點可以相同外，沒有任何節(jié)點出現(xiàn)次數(shù)多于一次，則該路徑為簡單路徑。

主路徑：如果從ni到nj是一條簡單路徑，并且它不作為任何其他簡單路徑的子路徑出現(xiàn)，則稱之為主路徑。

主路徑覆蓋（PPC）準則：TR包含圖中每一條主路徑。

指定路徑覆蓋（SPC)：TR包含一個測試路徑集S，S為指定參數(shù)。15.白盒測試方法

白盒測試：根據(jù)被測對象的內(nèi)部結(jié)構(gòu)和運行機制來設(shè)計測試用例的方法，又稱為結(jié)構(gòu)測試、邏輯驅(qū)動測試、覆蓋測試

被測對象的獨立路徑至少覆蓋一次； 所有邏輯取值測試[真、假]； 循環(huán)邊界測試；

檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)、邊界條件。16.黑盒測試方法

黑盒測試方法又稱功能測試方法、數(shù)據(jù)驅(qū)動測試方法，測試設(shè)計時不考慮被測對象的內(nèi)部結(jié)構(gòu)，以檢查系統(tǒng)功能（功能的正確、完整、邏輯流程、人機界面、文檔內(nèi)容、系統(tǒng)安裝/初始化）

以被測對象的外部特征為測試依據(jù)。17.模糊測試方法

模糊測試方法：構(gòu)造大量的隨機數(shù)據(jù)作為系統(tǒng)的輸入，從而檢驗系統(tǒng)在各種數(shù)據(jù)情況下是否出現(xiàn)問題。

18.增量測試：單元測試、調(diào)用依賴的模塊集成測試，逐步擴展直到形成整個軟件系統(tǒng)。

19.突擊測試：所有模塊一次性集成為一個完整的系統(tǒng)，然后進行完全測試。20.等價類劃分：

等價類劃分基于對輸入或輸出數(shù)據(jù)情況的評估，劃分成兩個或多個子集（等價類），然后從每個子集中選取一定的代表進行測試的測試用例設(shè)計方法。21.極限測試

極限編程：利用輕量、敏捷的開發(fā)過程，使開發(fā)人員能夠更快地完成應(yīng)用程序的開發(fā)。強調(diào)頻繁測試、測試驅(qū)動的方式保證軟件質(zhì)量。

極限測試：為滿足極限編程思想和過程而設(shè)計的一套測試策略和流程，原來的測試技術(shù)、方法均可以使用 22.配置項測試的內(nèi)容

功能: 適合性

準確性：功能的準確與精度要求 互操作性：與外部設(shè)備、系統(tǒng)的接口 安全保密性：數(shù)據(jù)訪問的可控制性 可靠性: 成熟性：容錯處理、平均無故障時間

容錯性：邊界條件、功能、性能的降級情況、誤操作模式、故障模式 易恢復(fù)性：自動修復(fù)能力/時間、平均宕機時間、平均恢復(fù)時間、恢復(fù)能力等 易用性

易理解性：功能描述清晰、準確；界面含義精確

易學(xué)性：在線幫助、幫助定位、各類手冊的易學(xué)、易用 易操作性：數(shù)據(jù)的有效檢查、解釋信息明確、界面切換 吸引性：人機界面定制 效率

時間特性：響應(yīng)時間、平均響應(yīng)時間、響應(yīng)極限時間、吞吐量、平均吞吐量、極限吞吐量，多任務(wù)并行測試

資源利用：大量并發(fā)任務(wù)下I/O設(shè)備利用、極限負載下I/O設(shè)備的負載、大量并發(fā)任務(wù)下用戶等待時間、內(nèi)存使用情況、數(shù)據(jù)傳輸能力等

維護性

易分析性：運行狀態(tài)數(shù)據(jù)易分析 易變更性：軟件的可配置、修改能力 易測試性：變更之后的易測試情況 可移植性

適應(yīng)性：不同軟件、硬件環(huán)境的適應(yīng)能力 易安裝性：安裝、配置的復(fù)雜程度、難以程度 共存性：與其他軟件協(xié)同的能力 易替換性：版本的替換難以程度 依從性

以上所有特性遵循標準、規(guī)范的情況測試

23系統(tǒng)測試：系統(tǒng)非功能性測試，以檢驗系統(tǒng)在超常數(shù)據(jù)規(guī)?；蜇撦d下，線程、CPU、內(nèi)存資源的利用和響應(yīng)時間、數(shù)據(jù)傳輸?shù)刃阅苤笜耸欠駶M足要求

24.測試計劃

確定測試充分性要求：覆蓋范圍、覆蓋程度 確定測試終止要求； 確定測試所需資源； 確定測試的軟件特性； 確定測試技術(shù)、方法； 確定測試準出條件； 確定測試進度計劃； 測試風(fēng)險分析。

25.測試設(shè)計：測試設(shè)計人員、測試程序員

測試用例設(shè)計：依據(jù)測試特性； 獲取測試數(shù)據(jù)；

確定測試順序：資源、被測特性； 獲取測試資源：軟硬件、工具； 編寫測試程序； 建立測試環(huán)境； 撰寫測試設(shè)計說明。

26.測試總結(jié)：

測試分析員－測試報告

總結(jié)測試計劃、測試說明的變化情況； 異常終止時測試未覆蓋范圍； 未能解決的測試問題； 總結(jié)測試結(jié)果（發(fā)現(xiàn)問題）； 編寫測試報告；

根據(jù)問題報告、測試記錄，編寫測試問題報告。

27.軟件可靠性：在給定的運行時間內(nèi)和給定的系統(tǒng)配置環(huán)境下，運行給定的軟件功能時所 表現(xiàn)出來的質(zhì)量能力 28.系統(tǒng)性能指標

系統(tǒng)資源利用率：分析性能指標，改善性能系統(tǒng)行為指標 請求響應(yīng)時間：一次請求完成時間

事務(wù)響應(yīng)時間：一個事務(wù)所有請求完成的總時間

數(shù)據(jù)吞吐量：單位時間內(nèi)服務(wù)器接收、發(fā)送的數(shù)據(jù)量。

29.驗收測試：用戶執(zhí)行的、使用真實數(shù)據(jù)進行的測試，依據(jù)需求規(guī)格中的確認標準進行測試。回歸測試：驗證已測試過的內(nèi)容不受變更影響，確認變更沒有引入新的錯誤。

30.α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操 作環(huán)境下進行的測試。

Beta測試由軟件的最終用戶在一個或多個客戶場所進行，開發(fā)者通常不在Beta測試的現(xiàn)場。

31.WebApp測試關(guān)注的主要內(nèi)容 Web內(nèi)容測試 界面 構(gòu)件

導(dǎo)航測試 安全性 性能

32.測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序路徑或核實是否滿足某個特定需求。

33.軟件生存期定義：從軟件產(chǎn)品設(shè)計到軟件被淘汰的時間段。又稱軟件生命周期、生存周期。進一步劃分為兩個階段：開發(fā)階段和維護階段（40%+60%）。

34.軟件安全定義：一種軟件質(zhì)量保證活動，他主要用來識別和評估可能對軟件產(chǎn)生負面影響并促使整個系統(tǒng)失效的潛在災(zāi)難。

35.軟件評審的目標在于：盡早發(fā)現(xiàn)軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續(xù)活動，防止錯誤轉(zhuǎn)化為缺陷。36.V模型

優(yōu)點：既有底層測試又有高層測試。底層：單元測試。高層：系統(tǒng)測試。

將開發(fā)階段清楚的表現(xiàn)出來，便于控制開發(fā)的過程。當(dāng)所有階段都結(jié)束時，軟件開發(fā)就結(jié)束了。

缺點：容易讓人誤解為測試是在開發(fā)完成之后的一個階段。

由于它的順序性，當(dāng)編碼完成之后，正式進入測試時，這時發(fā)現(xiàn)的一些bug可能不容易找到其根源。

實際中，由于需求變更較大，導(dǎo)致要重復(fù)變更需求、設(shè)計、編碼、測試，返工量大。37.W模型：

優(yōu)點：

將測試貫穿到整個軟件生命周期中，且除了代碼要測試，需求、設(shè)計等都要測試。更早介入軟件開發(fā)中，能盡早發(fā)現(xiàn)缺陷并修復(fù)。

測試與開發(fā)獨立起來，并與開發(fā)并行。缺點：

對有些項目，開發(fā)過程中根本沒有文檔產(chǎn)生，故W模型無法使用。

對于需求和設(shè)計的測試技術(shù)要求很高，實踐起來很困難。

從N0中某節(jié)點開始到Nf中某節(jié)點結(jié)束的一條路徑稱為一條測試路徑。

1.軟件缺陷：（符合下列規(guī)則的叫軟件缺陷)：

１）．軟件未達到產(chǎn)品說明書的功能

２）．軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤

３）．軟件功能超出產(chǎn)品說明書指明范圍

４）．軟件未達到產(chǎn)品說明書雖未指出但應(yīng)達到的目標

５）．軟件測試員認為難以理解、不易使用、運行速度緩慢、或者最終用戶認為不好

2.單元測試：單元測試是對軟件設(shè)計的最小單元——模塊進行正確性檢驗的測試工作，主要測試模塊在語法、格式和邏輯上的錯誤。3.回歸測試

指軟件系統(tǒng)被修改或擴充（如系統(tǒng)功能增強或升級）后重新進行的測試，是為了保證對軟件所做的修改沒有引入新的錯誤而重復(fù)進行的測試。

4.等價類：指某個輸入域的子集合，在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。

第四篇：軟件測試總結(jié)

面向?qū)ο蟪绦虻能浖y試方法

在軟件生命周期過程中，軟件測試是保證軟件質(zhì)量的關(guān)鍵環(huán)節(jié)之一。面向?qū)ο蠓椒▽W(xué)在軟件工程中的引入極大地方便了軟件的設(shè)計、開發(fā)和維護，為創(chuàng)建高可靠性的軟件系統(tǒng)提供了重要保證。但面向?qū)ο蟪绦虻姆庋b、繼承、多態(tài)和異常處理機制等新特性卻給測試帶來新的挑戰(zhàn)。一方面需要調(diào)整、改進傳統(tǒng)的測試策略和方法；另一方面探索出適應(yīng)面向?qū)ο蟪绦蛱卣鞯臏y試理論與技術(shù)也尤為必要。

面向?qū)ο?Object Oriented,OO)是當(dāng)前計算機界關(guān)心的重點，它是90年代軟件開發(fā)方法的主流。面向?qū)ο蟮母拍詈蛻?yīng)用已超越了程序設(shè)計和軟件開發(fā)，擴展到很寬的范圍。如數(shù)據(jù)庫系統(tǒng)、交互式界面、應(yīng)用結(jié)構(gòu)、應(yīng)用平臺、分布式系統(tǒng)、網(wǎng)絡(luò)管理結(jié)構(gòu)、CAD技術(shù)、人工智能等領(lǐng)域。

面向?qū)ο蟮亩x或說明對象的定義的非常少。其初，“面向?qū)ο蟆笔菍Ｖ冈诔绦蛟O(shè)計中采用封裝、繼承、抽象等設(shè)計方法?？墒?，這個定義顯然不能再適合現(xiàn)在情況。面向?qū)ο蟮乃枷胍呀?jīng)涉及到軟件開發(fā)的各個方面。如，面向?qū)ο蟮姆治觯∣OA，Object Oriented Analysis），面向?qū)ο蟮脑O(shè)計（OOD，Object Oriented Design）、以及我們經(jīng)常說的面向?qū)ο蟮木幊虒崿F(xiàn)（OOP，Object Oriented Programming）。許多有關(guān)面向?qū)ο蟮奈恼露贾皇侵v述在面向?qū)ο蟮拈_發(fā)中所需要注意的問題或所采用的比較好的設(shè)計方法。看這些文章只有真正懂得什么是對象，什么是面向?qū)ο?，才能最大程度地對自己有所裨益。這一點，恐怕對初學(xué)者甚至是從事相關(guān)工作多年的人員也會對它們的概念模糊不清。

1、面向?qū)ο蟮幕靖拍?/p>

(1)對象。

對象是人們要進行研究的任何事物，從最簡單的整數(shù)到復(fù)雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規(guī)則、計劃或事件。

(2)對象的狀態(tài)和行為。

對象具有狀態(tài)，一個對象用數(shù)據(jù)值來描述它的狀態(tài)。

對象還有操作，用于改變對象的狀態(tài)，對象及其操作就是對象的行為。

對象實現(xiàn)了數(shù)據(jù)和操作的結(jié)合，使數(shù)據(jù)和操作封裝于對象的統(tǒng)一體中

(3)類。具有相同或相似性質(zhì)的對象的抽象就是類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。

類具有屬性，它是對象的狀態(tài)的抽象，用數(shù)據(jù)結(jié)構(gòu)來描述類的屬性。

類具有操作，它是對象的行為的抽象，用操作名和實現(xiàn)該操作的方法來描述。

(4)類的結(jié)構(gòu)。

在客觀世界中有若干類，這些類之間有一定的結(jié)構(gòu)關(guān)系。通常有兩種主要的結(jié)構(gòu)關(guān)系，即一般--具體結(jié)構(gòu)關(guān)系，整體--部分結(jié)構(gòu)關(guān)系。

①一般——具體結(jié)構(gòu)稱為分類結(jié)構(gòu)，也可以說是“或”關(guān)系，或者是“is a”關(guān)系。

②整體——部分結(jié)構(gòu)稱為組裝結(jié)構(gòu)，它們之間的關(guān)系是一種“與”關(guān)系，或者是“has a”關(guān)系。

(5)消息和方法。

對象之間進行通信的結(jié)構(gòu)叫做消息。在對象的操作中，當(dāng)一個消息發(fā)送給某個對象時，消息包含接收對象去執(zhí)行某種操作的信息。發(fā)送一條消息至少要包括說明接受消息的對象名、發(fā)送給該對象的消息名（即對象名、方法名）。一般還要對參數(shù)加以說明，參數(shù)可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。

類中操作的實現(xiàn)過程叫做方法，一個方法有方法名、參數(shù)、方法體。消

2、面向?qū)ο蟮奶卣?/p>

(1)對象唯一性。

每個對象都有自身唯一的標識，通過這種標識，可找到相應(yīng)的對象。在對象的整個生命期中，它的標識都不改變，不同的對象不能有相同的標識。

(2)分類性。

分類性是指將具有一致的數(shù)據(jù)結(jié)構(gòu)(屬性)和行為(操作)的對象抽象成類。一個類就是這樣一種抽象，它反映了與應(yīng)用有關(guān)的重要性質(zhì)，而忽略其他一些無關(guān)內(nèi)容。任何類的劃分都是主觀的，但必須與具體的應(yīng)用有關(guān)。

(3)繼承性。

繼承性是子類自動共享父類數(shù)據(jù)結(jié)構(gòu)和方法的機制，這是類之間的一種關(guān)系。在定義和實現(xiàn)一個類的時候，可以在一個已經(jīng)存在的類的基礎(chǔ)之上來進行，把這個已經(jīng)存在的類所定義的內(nèi)容作為自己的內(nèi)容，并加入若干新的內(nèi)容。繼承性是面向?qū)ο蟪绦蛟O(shè)計語言不同于其它語言的最重要的特點，是其他語言所沒有的。

在類層次中，子類只繼承一個父類的數(shù)據(jù)結(jié)構(gòu)和方法，則稱為單重繼承。

在類層次中，子類繼承了多個父類的數(shù)據(jù)結(jié)構(gòu)和方法，則稱為多重繼承。

在軟件開發(fā)中，類的繼承性使所建立的軟件具有開放性、可擴充性，這是信息組織與分類的行之有效的方法，它簡化了對象、類的創(chuàng)建工作量，增加了代碼的可重性。

采用繼承性，提供了類的規(guī)范的等級結(jié)構(gòu)。通過類的繼承關(guān)系，使公共的特性能夠共享，提高了軟件的重用性。

(4)多態(tài)性(多形性)多態(tài)性使指相同的操作或函數(shù)、過程可作用于多種類型的對象上并獲得不同的結(jié)果。不同的對象，收到同一消息可以產(chǎn)生不同的結(jié)果，這種現(xiàn)象稱為多態(tài)性。

多態(tài)性允許每個對象以適合自身的方式去響應(yīng)共同的消息。

多態(tài)性增強了軟件的靈活性和重用性。

面向?qū)ο蠓椒ǖ幕舅枷胧且唬好嫦驅(qū)ο蠓椒ㄊ且环N運用對象、類、封裝、繼承、多態(tài)和消息等概念來構(gòu)造、測試、重構(gòu)軟件的方法。

二： 面向?qū)ο蠓椒ㄊ且哉J識論為基礎(chǔ)，用對象來理解和分析問題空間，并設(shè)計和開發(fā)出由對象構(gòu)成的軟件系統(tǒng)（解空間）的方法。由于問題空間和解空間都是由對象組成的，這樣可以消除由于問題空間和求解空間結(jié)構(gòu)上的不一致帶來的問題。簡言之，面向?qū)ο缶褪敲嫦蚴虑楸旧?，面向?qū)ο蟮姆治鲞^程就是認識客觀世界的過程。

面向?qū)ο蠓椒◤膶ο蟪霭l(fā)，發(fā)展出對象，類，消息，繼承等概念。

面向?qū)ο蠓椒ǖ闹饕獌?yōu)點是：符合人們通常的思維方式；從分析到設(shè)計再到編碼采用一致的模型表示具有高度連續(xù)性；軟件重用性好。

面向?qū)ο筌浖y試的特點是: 1.掌握代碼檢查、走查與評審的基本方法和技術(shù)； 2.掌握白盒測試和黑盒測試的測試用例的設(shè)計原則和方法； 3.掌握單元測試和集成測試的基本策略和方法；

4.了解系統(tǒng)測試、性能測試和可靠性測試的基本概念和方法； 5.了解面向?qū)ο筌浖蚖EB應(yīng)用軟件測試的基本概念和方法； 6.掌握軟件測試過程管理的基本知識和管理方法； 7.熟悉軟件測試的標準和文檔；

8.掌握QESuite軟件測試過程管理平臺和QESat/C++軟件分析和工具的使用方法。

第五篇：軟件測試工作中 QA 的角色和分工

1、測試的角色(Test)要獨立出來么 ?

2、獨立出來的測試角色怎么才能發(fā)揮作用?

有些成功人士和成功的公司號稱沒必要有獨立的測試角色(Test)，你怎么看?

大多數(shù)的開發(fā)團隊并不需要一個獨立的測試角色。即使有一個，他的所有的開發(fā)時間比上所有的測試時間應(yīng)該>20：1。

我正好在寫相關(guān)的教案，也來湊個熱鬧。

[這篇文章的一些事例來自于我曾經(jīng)和現(xiàn)在的團隊。希望這些例子不足以影響相關(guān)人物和團隊的偉大形象。任何軟件團隊都會犯錯誤，偉大的團隊有勇氣面對自己的錯誤并不斷改進。]

首先，明確兩個概念：

1、軟件測試(Test)：運用定義好的流程，工具去驗證軟件能實現(xiàn)預(yù)先設(shè)計的功能和特性，工作的流程和結(jié)果通常是可量化的，例如，測試用例，bugs，代碼覆蓋率，MTTF，軟件效能的參數(shù)。[注：正因為流程和結(jié)果是可明確定義的，可量化的，很多測試工作可以自動化]

2、軟件質(zhì)量保證工作(QualityAssurance)：軟件團隊的成員為了讓軟件達到事先定義的質(zhì)量而進行的所有活動，包括測試工作。

對于這兩個術(shù)語，不同人有不同的定義，有人認為它們是互通的，在《現(xiàn)代軟件工程》的上下文中我盡量使用上述的定義.測試的角色(Test)要獨立出來么?

回答：首先，領(lǐng)測國際相信有分工是好事，軟件團隊中應(yīng)該有獨立的測試(Testing)角色。所有人都可以參與QA的工作(報告bug什么的)，但是最后要有 一個角色對QA這件事負責(zé)。不但角色要獨立，而且在最后軟件發(fā)布的時候，必須得到此角色的簽字保證(signoff)。我在微軟參與的項目都是這樣做的。

在開始論證之前，先引用斯密特·亞當(dāng)斯的《國富論》來暖場(我沒讀過這本書，直接從網(wǎng)上抄的)。

亞當(dāng)斯認為，分工的起源是由人的才能具有自然差異。…假定個人樂于專業(yè)化及提高生產(chǎn)力，經(jīng)由剩余產(chǎn)品之交換行為，促使個人增加財富，此等過程將擴大社會 生產(chǎn)，促進社會繁榮，并達私利與公益之調(diào)和。他列舉制針業(yè)來說明?！叭绻麄兏髯元毩⒐ぷ?，不專習(xí)一種特殊業(yè)務(wù)，那么他們不論是誰，絕對不能一日制造二十 枚針，說不定一天連一枚也制造不出來。他們不但不能制出今日由適當(dāng)分工合作而制成的數(shù)量的二百四十分之一，就連這數(shù)量的四千八百分之一，恐怕也制造不出 來?！?/p>

分工促進勞動生產(chǎn)力的原因有三：第一，勞動者的技巧因?qū)I(yè)而日進;第二，由一種工作轉(zhuǎn)到另一種工作，通常需損失不少時間，有了分工，就可以免除這種損失;第三，許多簡化勞動和縮減勞動的機械發(fā)明，只有在分工的基礎(chǔ)上方才可能。

我們看團隊形式的職業(yè)體育比賽，各個位置的分工都很明確，拿足球來說，有專注進攻的，有專注防守的，但是在我的印象中，那些偉大的前鋒大多數(shù)只管一件事-進攻。亨利(ThierryHenry)參加防守么?

1、當(dāng)然一些球賽也有沒有分工的時候，原因有好幾個：

2、事太小，幾個小孩踢個半場。

3、無知，小孩們剛開始玩球。

4、人手不夠，一對一打籃球，你要參與防守么?沙灘排球，兩人都是全攻全守。

如果你的軟件團隊做的事情和上面的情況類似，那當(dāng)然不必分工。你們做的很可能不是商用軟件，你的軟件團隊大概也不用受什么軟件工程規(guī)律的束縛。

任何產(chǎn)業(yè)產(chǎn)業(yè)成熟到一定階段的時候，獨立的質(zhì)量保證角色是不可避免的。團隊內(nèi)部有QA角色，團隊外部也有獨立的QA角色。

拿藥品和食品來做例子，除了生產(chǎn)廠家自己的檢測之外，這些產(chǎn)品還要接受行業(yè)主管部門相關(guān)機構(gòu)的檢測和認可(藥品檢驗，食品檢驗)，才能上市。在出現(xiàn)爭議的情況下，還要第三方機構(gòu)來進行測試或認證。

有人也許這樣建議：

這些藥品都是藥廠同一批工人一邊制造一邊測試出來的，特別有保證!不用測了，趕緊吃了吧!

也許還有人這樣建議：

這個十字坡夫妻店的農(nóng)家飯都是他們自己親手做的，很可信，咱們今晚就去吃飯住一宿吧。

我們每天經(jīng)常使用的電子產(chǎn)品，從大彩電到電影插座，也經(jīng)歷了很多團隊內(nèi)部的和外部的測試，請隨手拿過任何一個電器，你會在背面看到密密麻麻的小字，其中肯定有下列標記之一：

沒有這些標記的產(chǎn)品電子產(chǎn)品，市面上很少看到。