中文04中文測試員5

1、No.52 0 0 5 . 0 2THE SOFTEWARE TESTING ENGINEERING MAGAZINE 普及&共享&交流&提高2005 年 02 月第五期測試員電子期刊?本期導(dǎo)讀2第頁歡迎訪問我們的網(wǎng)站 - ?主辦方： 測試時代投稿： 主編： http審閱： Seanhe協(xié)作： Aken ? 軟件測試的新模型 . 通常情況下，一個軟件模型說明的內(nèi)容主要包括，在測試過程中你應(yīng)該考慮到哪些問題，如何對測試進行計劃，測試要達到什么目標詳見 P3. ? 嵌入式軟件測試策略 .在嵌入式領(lǐng)域目標系統(tǒng)的應(yīng)用系統(tǒng)日趨復(fù)雜，而由

2、于競爭要求產(chǎn)品快速上市，開發(fā)技術(shù)日新月異，同時硬件發(fā)展的日益穩(wěn)定，而軟件故障卻日益突出詳見 P15.? Rational Clear Quest 技 巧集.收集和整理了 Rational ClearQuest 常見的問題詳見 P20.? Junit 之走馬觀花篇. 我們細致地研究 JUint 框架并思索如何來構(gòu)造它。我們發(fā)現(xiàn)了許多不同層次上的教訓(xùn)。在本文中， 我們將嘗詳見 P26. ? 利用 Jmeter 測試 WebSphere 性能.本文描述如何部署 Apache 開放源代碼工具 JMeter ， 以基于 IBM WebSphere Application Server 和 WebSphe

3、re Branch Transformation Toolkit（ BTT）來測試中間件解決方案的響應(yīng)性詳見 P43.? 軟件測試要不要追究 Bug 發(fā)生的原因.軟件測試到底要不要追究 BUG 發(fā)生的原因呢？這個問題的爭議很多，有人認為尋找 BUG 的原因是開發(fā)的事情，軟件測試只要能發(fā)現(xiàn) Bug詳見 P52.? 使用 IBM Rational 的測試理念成功打造測試團隊.測試在所有的軟件開發(fā)過程中都是最重要的部分。在軟件開發(fā)過程中，一方面要求我們通過測試活動驗證所開發(fā)的軟件詳見 P54.第 3 頁2005 年 02 月第五期測試員電子期刊一、 軟件測試的新模型 作者：Brian Marick

4、翻譯：Blueski通常情況下，一個軟件模型說明的內(nèi)容主要包括，在測試過程中你應(yīng)該考慮到哪些問題，如何對測試進行計劃，測試要達到什么目標，什么時候開始，在測試中你要用到哪些信息資源。一個好的模型可以引導(dǎo)你對問題進行思考，而不好的模型則只能使你誤入歧途。 這里我要宣稱的是，目前的大多數(shù)軟件測試模型都是不好的模型。這是因為這些測試模型僅僅是軟件開發(fā)模型的一些裝飾和補充而已。 人們一直在苦苦尋找軟件開發(fā)的模型，在創(chuàng)建了新的模型后，就把測試作為一個階段放在模型的后面部分。因此測試總被作為一種事后行為，測試總是被開發(fā)所驅(qū)動?？偟膩碚f， 我們是在檢測他們的完成品。但是， 作為事后處理的測試， 其驅(qū)動方式是

5、不正確的。實際上它顯而易見地和開發(fā)過程中各種行為之間有關(guān)，測試沒有起到應(yīng)有的平衡作用。這樣的測試只是檢測了開發(fā)人員做了什么，而并沒有檢測到他們是否按照規(guī)則做了什么， 這樣的做法割裂了本該緊密聯(lián)系的行為， 剩下的只有那些匆忙而草率的想法所帶來的傷害。 而這樣做的結(jié)果就是效果很差的、效率很低的測試。效果很差的測試將導(dǎo)致很多bug 沒有被發(fā)現(xiàn)，而效率很低的測試所浪費的是成本。 在本文中，我要做 2 件事，其一，我要一個不好的模型，即 V 模型。我希望通過論述來表明，“單元測試” 和“ 集成測試” 這 2 個詞匯可以從我們的詞匯表中取消了。其二， 我將描述一個更好的模型。不過首先我認為，要真正擁有一個

6、充分合理的模型還為時尚早。我僅僅是描述了一些新模型應(yīng)該符合的重要的要求。這些要求將在本文末尾處列舉。 1. V 模型有什么問題呢？ 在本文中我要把 V 模型作為不好的模型的典型來進行分析。我選擇 V 模型作為分析的典型是因為 V 模型是最廣為人知的測試模型。 最典型的 V 模型版本一般會在其開始部分對軟件開發(fā)過程進行描述，如下圖所示： 歡迎訪問我們的網(wǎng)站 - ? 第 4 頁2005 年 02 月第五期測試員電子期刊圖 1-V 模型的各級開發(fā)階段 這是古老的瀑布模型。作為開發(fā)模型，它有很多問題，不過這里不作討論。盡管它的各種狀態(tài)是我們接著要討論的大家最熟悉的 V

7、模型的基礎(chǔ)。我的意見同時也針對其它的裝飾在一些更好的開發(fā)模型之上的測試模型， 例如螺旋模型Boehm88。 在 V 模型中，測試過程被加在開發(fā)過程的后半部分，如下圖所示： 圖 2-V 模型示意圖 單元測試所檢測的是，代碼的開發(fā)是否符合詳細設(shè)計的要求。集成測試所檢測的是， 此前測試過的各組成部分是否能完好地結(jié)合到一起。系統(tǒng)測試所檢測的是， 已集成在一起的產(chǎn)品是否符合系統(tǒng)規(guī)格說明書的要求。而驗收測試則檢測產(chǎn)品是否符合最終用戶的需求。 對于測試設(shè)計，顯而易見的是，V 模型的用戶往往會把執(zhí)行測試與測試設(shè)計分開對待。在開發(fā)文檔準備就緒后， 就可以開始進行相關(guān)的測試設(shè)計。如下圖所示， 相應(yīng)的測試設(shè)計覆蓋在

8、了相關(guān)的開發(fā)過程之上： 歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊圖 3-將測試設(shè)計覆蓋了開發(fā)過程后的 V 模型 V 模型有著很吸引人的對稱外形，并且把很多人都帶入了歧途。本文將集中討論它在單元測試和集成測試中引起的問題。 為了說明的方便，這里專門制作了以下圖片，圖中包括一個單獨的單元，以及一個單元組， 我稱之為子系統(tǒng)（ subsystem）。 圖 4-一個假想的子系統(tǒng) 對于一個單元應(yīng)該多大才最為合適的問題，已經(jīng)有過很多的討論，究竟一個單元僅僅是一個函數(shù)，一個類， 還是相關(guān)的類的集合？這些討論并不影響我在這里所要闡述的觀點。我們權(quán)且認為

9、一個單元就是一個具有最小程度的代碼塊，開發(fā)人員可以對進行獨立地討論。 V 模型認為人們首先應(yīng)該對每一個單元進行測試。當子系統(tǒng)中所有的單元都已經(jīng)測試完畢， 它們將被集中到一起進行測試， 以驗證它們是否可以構(gòu)成一個可運行的整體。 那么，如何針對單元進行測試呢？我們會查看在詳細設(shè)計中對接口的定義，或者查看源代碼， 或者同時對兩者進行查看， 找出符合某些測試設(shè)計中的有關(guān)準則的輸入數(shù)據(jù)來進行輸入， 然后檢查結(jié)果， 看其是否正確。由于各單元一般來說不能獨立地運行，所以我們不得不另外設(shè)計樁模塊（ Stub）和驅(qū)動模塊（ Driver），如下圖所示。 5第頁歡迎訪問我們的網(wǎng)站

10、- ?2005 年 02 月第五期測試員電子期刊圖 5：單元及其外部的驅(qū)動模塊和樁模塊 圖中的箭頭代表了測試的執(zhí)行軌跡。這就是大多數(shù)人所說的“單元測試” 。我認為這樣的方法有時候是一種不好的方法。 同樣的輸入也可以有同一子系統(tǒng)中的其它單元來提供，這樣，其它的單元既扮演了樁模塊， 又扮演了驅(qū)動模塊。如下圖所示： 圖 6-子系統(tǒng)內(nèi)部各單元間的測試執(zhí)行軌跡 到底選擇哪一種方法，這需要一種折衷和權(quán)衡。設(shè)計樁模塊和驅(qū)動模塊要付出多少代價？這些模塊如何進行維護？ 子系統(tǒng)是否會由此而掩蓋了一些故障？ 在整個子系統(tǒng)范圍內(nèi)進行排錯的困難程度有多大？ 如果我們的測試直到集成測試時才真正開始， 那么一些 bug 可

11、能較晚才被發(fā)現(xiàn)。由此造成的代價同設(shè)計樁模塊和驅(qū)動模塊的代價如何比較？ 等等。 V 模型沒有去考慮這些問題，當單元開發(fā)完成后就執(zhí)行單元測試，而當自系統(tǒng)被集中在一起后就執(zhí)行集成測試， 僅此而已。令我奇怪和沮喪的是， 人們從不去做一些權(quán)衡， 他們已經(jīng)受制于他們的模型。 因此，一個有用的模型應(yīng)該允許測試人員考慮節(jié)省并推遲測試的可能性。 一個測試，如果要發(fā)現(xiàn)一個特定的單元中的 bug，最好是在該單元保持獨立的情況下執(zhí)行， 并且在其外部輔以特定的樁模塊和驅(qū)動模塊。而另一種方法則是讓它作為子系統(tǒng)的一部分來進行測試，該測試的設(shè)計主要是為了發(fā)現(xiàn)集成的問題。由于一個子系統(tǒng)本身也需要樁模塊和驅(qū)動模塊來模擬該子系統(tǒng)和

12、其它子系統(tǒng)的聯(lián)系，因此， 單元測試和集成測試可能被推遲到至少整個系統(tǒng)已經(jīng)部分集成的時候。在這種情況下，測試者可能通過產(chǎn)品的外部接口同時進行單元測試、集成測試和系統(tǒng)測試，同樣的， 其主要目的還是為了減少總體生命周期的成本，對測試成本和延期進行測試及由此造成延期發(fā)現(xiàn) bug 的代價成本進行權(quán)衡。據(jù)此而言， “單元測試”、“ 集成測試” 和“ 系統(tǒng)測試” 的區(qū)別已經(jīng)大大削弱了。其結(jié)果可參考下圖： 6第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊 圖 7-新的方法：在部分階段延遲進行單元測試和集成測試 在上圖右邊的方塊中， 最好要改成為“執(zhí)行某

13、些適當?shù)臏y試并得到相應(yīng)的結(jié)果”。 圖中的左邊會怎樣？ 考慮一下系統(tǒng)測試設(shè)計，它的主要根據(jù)和信息來源是是規(guī)格說明。假設(shè)你知道有 2 個單元處在一個特定的子系統(tǒng)中， 它們在運行時相互聯(lián)系， 并且要執(zhí)行規(guī)格說明中的一個特定的聲明。為什么不在該子系統(tǒng)被集成時立即對此規(guī)格說明中的聲明進行測試， 就象是在設(shè)計完成后立即開始測試的設(shè)計一樣呢？ 如果該聲明的執(zhí)行和子系統(tǒng)外的子系統(tǒng)沒有任何關(guān)系， 為什么還要等到整個系統(tǒng)完成以后再測試呢？ 難道越早發(fā)現(xiàn) bug 成本越低不對嗎？ 在上一張圖片中， 我們用了向上指的箭頭（ 更有效， 但在時間上有延遲）。這里還可以把箭頭往下指（ 在時間上提前）： 圖 8-新的方法：在

14、不同階段上提前進行測試設(shè)計 7第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊在這種情況下，左邊的方塊中最好被標記為：“在當前信息條件和情況下可以做的任何測試設(shè)計”。這樣， 當測試設(shè)計得自于系統(tǒng)中某一個組件的描述時，模型必須允許這樣的測試在組件被裝配之前被執(zhí)行。我必須承認我的圖片非常難看， 這些箭頭指得到處都是，對此我有 2 點說明： 1. 我們所討論的事情不是創(chuàng)造美，而是想要發(fā)現(xiàn)盡可能多的嚴重錯誤，同時盡可能地降低成本。 2. 難看的部分原因也是因為必須按照某些次序來執(zhí)行的結(jié)果，亦即開發(fā)人員先提供系統(tǒng)描述文檔， 然后測試和這些文檔進行關(guān)

15、聯(lián)。這些文檔就象是堅實的老橡樹，而測試設(shè)計則象是細細的枝條纏繞在樹上。如果我們采用不同的原理來進行組織， 圖片可能就會變得好看些。但復(fù)雜性仍不可避免， 因為我們要討論的問題本身就很復(fù)雜。 V 模型失敗的原因是它把系統(tǒng)開發(fā)過程劃分為具有固定邊界的不同階段，這使得人們很難跨過這些邊界來采集測試所需要的信息。有些測試應(yīng)該執(zhí)行得更早些， 有些測試則需要延后進行。而且， 它也阻礙了你從系統(tǒng)描述的不同階段中取得信息進行綜合。例如， 某些組織有時執(zhí)行這樣的做法， 即對完成的工作進行簽署。這樣的規(guī)定也擴展到系統(tǒng)測試的設(shè)計。簽署表示已經(jīng)過評估，該測試設(shè)計工作已經(jīng)完成， 除非對應(yīng)的設(shè)計文檔改變， 否則就不會被修訂

16、。如果同這些測試相關(guān)的信息后來被重新挖掘和認識， 例如， 架構(gòu)設(shè)計表明有些測試是多余的， 或者，詳細設(shè)計表明有一個內(nèi)部的邊界可以和已存在的系統(tǒng)測試組合在一起進行測試的話， 那么實際上還需要繼續(xù)調(diào)整原來的系統(tǒng)測試設(shè)計。 因此，模型必須允許利用不同來源的綜合信息進行個別的測試設(shè)計。另外，模型還應(yīng)該允許在新的信息來源出現(xiàn)后重新進行測試的設(shè)計。 2.一個不同的模型 讓我們來看本文的第二項內(nèi)容，一個不同的模型。 很多時候人們把代碼移交給其他人，并且說：“希望你能接受和喜歡它?！?這不僅發(fā)生在將整個項目放在一張光盤中交給客戶的時候， 也發(fā)生在項目內(nèi)部。 例如，一個小組對另一個小組說：“ 我們已經(jīng)完成了為

17、COMM 庫加入了對 XML 的支持。源代碼現(xiàn)在已經(jīng)放在 master 庫中， 可執(zhí)行庫則已經(jīng)加入到集成與創(chuàng)建的環(huán)境中。XARG 小組的工作已經(jīng)沒有什么阻礙了， 隨時去取吧?！?某個程序員檢查了 bug 的修改并且發(fā)出郵件：“我已經(jīng)修改了 Bug 列表中的那個Bug， 很抱歉！” 至此， 早先受該問題影響的其它代碼就可以繼續(xù)處理了。 在這些情況下，人們要把代碼移交給其它人，其中有可能會存在一些影響。測試人員需要干預(yù)這個過程。在移交之前，測試人員應(yīng)執(zhí)行這些代碼，發(fā)現(xiàn)其中的 bug8第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊（ 影響），

18、 并且提出問題：“ 你確實要提交這些嗎？” 由此， 移交的內(nèi)容可能會被延期， 直到 bug 被修復(fù)好。 盡管你還要做其它的各種測試，這項測試仍然是很基本的測試工作。如果你沒有做這樣的測試， 就不能算是合格的測試人員。 我們的測試模型必須包含這一重要的現(xiàn)實需要：針對代碼移交的測試。由此，測試模型應(yīng)提示進行針對每一次代碼移交的測試。 就讓我以支持 XML 的 COMM 庫作為例子。這里存在著一個小組把代碼移交給 XARG小組以進行項目的余下部分。那么誰會遭受影響？ 要將這些支持 XML 的代碼直接進行使用的 XARG 小組可能會立即受到影響； 這可能會在稍后影響到市場人員，他們要在一個行業(yè)展示會議

19、上為“合作伙伴發(fā)行”版本提品演示和宣傳，而 XML 支持是影響他們銷售的重要部分； 還有， 它可能損害采納我們的產(chǎn)品的合作伙伴。 現(xiàn)在我們可以提出一些有趣的關(guān)于測試計劃的問題了。最簡單的可以做的事情是，在移交的時候立即執(zhí)行 XML 支持的完整測試。（“ 完整” 的含義是， 為此設(shè)計盡可能多的測試）但也許一些 XML 特性并不是 XARG 小組所需要的，因此可以把它們放在合作伙伴版本封版（ 下圖中的“ Partner Release”）的測試中去。這意味著可以把一些 XML 相關(guān)測試放到稍后的移交過程中去?；蛘呋谄渌碛?， 例如在近階段有其它的測試任務(wù)要執(zhí)行。而 XARG 小組則要因 XML

20、中的 bug 修復(fù)而延遲一小段時間。 我們的測試計劃所表示的進度可以通過在開發(fā)的時間線上進行注解的方式來表現(xiàn)，如下圖所示： 圖 9： 添加在開發(fā)計劃之上的測試計劃 我們應(yīng)嚴格地圍繞在 XML 支持的功能交接的時段里進行測試。測試設(shè)計和測試支持工作要早于測試執(zhí)行。而另外的 XML 測試則要延遲到基于整個項目范圍的“ 代碼第頁9歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊完成”（ 圖中的“ Code Complete” 里程碑），或者要等到全部的子系統(tǒng)被集中在一起，而且整個產(chǎn)品為了行業(yè)會議而在經(jīng)過穩(wěn)定化處理后創(chuàng)建了版本（ 圖中的“ Partn

21、er Release” 里程碑）。 顯然， 有兩項內(nèi)容沒有包含在代碼完成里程碑中： 還有大量其它的測試工作（ 包括設(shè)計、工具選用）。這些工作可能因為 COMM 以外的子系統(tǒng)的交接而延期。而且， 還有用于完成里程碑中所規(guī)定的某些風險的測試， 例如， 可能還有一組用于運行市場人員的演示 Demo 腳本的測試， 包括她可能在無意中引起的偏離。其目的是要避免這樣的情況， 即當她站在1000 人的觀眾面前時， 她還僅僅是第一次以某種特定的順序來輸入數(shù)據(jù)。 一些首次交接時進行的 XML 測試需要在代碼完成里程碑上再次執(zhí)行。 我的觀點是，測試計劃是由很多困難的決定所組成，這些決定包括人員組織安排、機器資源配

22、置、測試設(shè)計的時間定位、測試支持代碼的數(shù)量、哪些測試要做自動化， 等等。這些決定應(yīng)根據(jù)單獨的交接中的內(nèi)容信息來作出。如果僅有一次交接， 那么你可以更順利一些。測試計劃還應(yīng)繼續(xù)考慮以下問題： 1. 風險分析， 誰會因此受到損害， 以什么方式？ 2. 選定一種測試途徑來定位特定的風險。 3. 對測試設(shè)計和執(zhí)行的周期和成本進行估計。 4. 在項目進度上的特定位置， 將計劃納入執(zhí)行的行動： A. 開始對測試進行設(shè)計 B. 同時設(shè)計和創(chuàng)建一些支持測試的代碼 C. 在全部測試完成以前就執(zhí)行部分的測試， 因為可能存在不只一次的交接，在每一次交接的測試規(guī)劃中， 可能存在一些潛在的復(fù)雜的相互影響。工作安排不得不

23、進行一些調(diào)整以達到相互間的平衡。測試支持代碼和工具需要在各項任務(wù)中得到共享。你還必須考慮到在什么程度上讓那些為早先的交接所設(shè)計的測試在以后重新執(zhí)行， 等等。 這看起來很復(fù)雜?？瓷先ニ坪跤刑嗟膬?nèi)容需要跟蹤，而且太多的內(nèi)容可能被忽略。也許你認為我是在要求你要對每一次交接來執(zhí)行 IEEE 829 IEEE98中關(guān)于測試計劃的要求， 然后把它們合并為一份貫穿整個項目的針對交接進行測試的測試計劃。 是， 也不是。思考問題總是要占用時間的。太多的計劃可能會減少結(jié)果的產(chǎn)出。在有些時候，你需要做的是停止計劃并開始行動。例如，你無法思考并描述每一個bug 修復(fù)， 盡管 bug 修復(fù)也是一種交接。 但是 bug

24、 修復(fù)是實際工作中現(xiàn)實存在的問題?？傮w項目計劃中應(yīng)該包含 bug 修復(fù)。10第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊需要強調(diào)的是，你應(yīng)該有一個默認的 bug 修改處理的標準過程，該過程應(yīng)包括運行于每一個提交的 bug 修復(fù)的驗證過程。你還需要努力地去思考問題。很多時候， 各項驗證是被放在一起同時進行并完成的。 比較現(xiàn)實地來說，一個模型應(yīng)該允許一些機械式行為， 例如， “ 不管是哪一個 X 類型的交接，都要執(zhí)行下列操作” 。同時我們鼓勵對特定的交接執(zhí)行剛剛夠的檢查， 對于風險越小的交接， 就越可以采用機械式的測試行為。 一個明確考慮

25、到基本的測試現(xiàn)實的模型肯定會比忽略這些現(xiàn)實或者把你的工作復(fù)雜性完全抽象化的模型做得更好。文檔則是另一個例子。 我還沒有提到需求及規(guī)格說明書，或者設(shè)計文檔。某個交接中產(chǎn)生的一系列變化會引起很多爭議。這些文檔所扮演的角色是什么呢？它們常常是這么被使用的： 圖 10：測試中對開發(fā)文檔的利用 文檔可以指導(dǎo)你在一個交接變化時如何做出反應(yīng)。如果你有一份很好的需求文檔， 它可能是產(chǎn)品所解決的問題的描述， 盡管也許不是很直接。它可以幫助你對風險進行分析。一份好的規(guī)格說明應(yīng)對系統(tǒng)的行為進行描述。這將幫助你把測試方法轉(zhuǎn)化為具體的測試。一份好的架構(gòu)設(shè)計則可以幫助你理解變化可能引起的幾種不同的情況： 系統(tǒng)的其它部分會

26、受到怎樣的影響？ 什么測試需要再次進行？ 我并不是經(jīng)常能看到好的文檔。需求文檔常常象是市場銷售用的系統(tǒng)特性列表。規(guī)格說明書有時就象是在代碼完成后提交的用戶手冊文件。而設(shè)計文檔經(jīng)常不存在。 好了，通過針對交接所引起的變化的集中討論，我已把測試過程和軟件開發(fā)過程相對地分離開了。如果文檔中關(guān)于“ XML 支持功能加入到 COMM” 的描述很薄弱的話， 我會盡自己所知來進行盡可能好的測試設(shè)計。然后， 假如在項目后期， XML 相關(guān)的 用戶文檔出來了， 我就可以對后來再次提交的交接增加相關(guān)的測試。假如市場需求改變了， 她們經(jīng)常會這么做， 我還會在此后增加或者去除一些測試。所有這一切看起來是這樣的： 11

27、第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊 圖 11-在文檔不完整的條件下進行測試，并在后期補充測試 這樣，雖然項目文檔總是不到位，而且經(jīng)常延遲提交，測試的效果也因此常常被降低， 我們還是要避免測試受到項目文檔的制約。 頭腦靈活的測試人員并不過于相信文檔。畢竟，總是人在犯錯誤。那么，難道不是人在寫這些文檔嗎？ 由于“ 正式的” 文檔是很薄弱的，測試模型必須明確地鼓勵在測試過程中使用項目文檔之外的各種不同信息來源。 測試人員必須和程序員、用戶、市場人員、技術(shù)作者以及任何的可能為實現(xiàn)更好測試提供線索的人進行交流。測試人員還應(yīng)該努力把自己

28、沉浸在某些技術(shù)所構(gòu)建的氛圍中。例如， 我希望測試人員在做 XML 測試工作時常去訪問 W3 組織的 XML 地址（ /XML/）以及其它 XML 站點、郵件列表，甚至包括比較特別的 如 Dave Winer 的 DaveNet/腳本新聞（ /）。這些資源并不是所謂的“ 輔助通道” ，而是可以被列入計劃和進度日程的資源。 另外，所執(zhí)行的測試本身也是一種有用的信息的資源。好的測試人員會仔細閱讀bug 報告， 因為這些報告講授了系統(tǒng)所存在的薄弱之處。特別地， 這些報告還暗示了一些正式的架構(gòu)設(shè)計所沒有提供的架構(gòu)上的策略。執(zhí)行

29、測試的行為應(yīng)該產(chǎn)生一些新的測試想法。如果模型沒有考慮到這些， 那么它就是一個落后的模型。 因此，測試模型應(yīng)該包含反饋的循環(huán)，讓測試設(shè)計可以考慮到，在運行測試時還可以繼續(xù)發(fā)現(xiàn)到更多的測試內(nèi)容。 在我們的工作中，真正的復(fù)雜性來自于所有計劃的執(zhí)行都處于一個不確定的、容易忽略的環(huán)境里。代碼并不是唯一在不斷變化的東西。而計劃日程也在改變。新的功能擴充會帶來新的里程碑。某些功能會從當前版本中去除。在開發(fā)過程中， 所有人-市場人員、開發(fā)人員和測試人員， 都會逐漸對諸如“ 產(chǎn)品究竟提供什么” 這樣12第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊的問題

30、有越來越清晰的了解。在這些情形下， 我們怎么能說測試計劃的第一個版本會是完全正確的呢？ 因此，模型應(yīng)該要求測試計劃人制定明確的規(guī)定，對已交接的交接內(nèi)容，新的交接， 以及交接內(nèi)容的變更進行負責。 3. 總結(jié) V 模型有以下的缺陷， 其它模型實際上也與此相似： 1. 忽略了這樣的事實情況， 即軟件開發(fā)是由一系列的交接所組成， 每一次交接內(nèi)容都改變了前一次交接的行為。 2. 依賴于開發(fā)文檔的存在， 及文檔的精確性、完整性， 并且沒有對時間進行限制。 3. 認定一種測試的設(shè)計是依據(jù)某一個單獨的文檔，而不包括根據(jù)其前后階段的文檔的修改而作相應(yīng)修改。 4. 認定這些依賴于某個單獨文檔的測試一定要在一起執(zhí)行

31、。 我大致描述了一個替代模型， 但還不夠精細。它考慮到了代碼的交接和里程碑。對測試成本控制作了以下明確描述： 測試設(shè)計的目標是定義好可能發(fā)現(xiàn) bug 的測試輸入，而測試執(zhí)行的目標是以各種方式加入這些數(shù)據(jù)， 并檢驗結(jié)果，由此來降低整個生命周期的成本。 我們的模型假設(shè)軟件產(chǎn)品總是不完美的，開發(fā)過程中有很多變更，而且對產(chǎn)品的測試也是一個不斷學習的過程。 過去， 我很少考慮到模型。表面上我一直還在用 V 模型。雖然我按此制訂計劃， 但我總是還要花費很多額外的精力和時間來考慮模型中沒有提到的方面。換言之， 模型造成了一些阻礙， 因此我有必要對此進行研究。 對一個新的模型來說，對模型所提出的要求必須非常明

32、確，這就象業(yè)務(wù)需求對產(chǎn)品開發(fā)非常重要一樣。我希望自己對本文中所提倡的模型的要求的描述能夠和 V 模型中的描述一樣精確， 并具有同樣的指導(dǎo)意義。 理想的測試模型應(yīng)該包括下列要求： 1. 使測試對項目中的每一次代碼交接有所反應(yīng)。 2. 要求測試計劃人制定明確的規(guī)定，對已交接的交接內(nèi)容，新的交接，以及交接內(nèi)容的變更進行負責。 13第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊3. 在測試設(shè)計中，除了使用項目文檔外，還應(yīng)明確鼓勵使用其它各種信息，這些信息有不同來源。 4. 事實上項目文檔總是不到位，而且經(jīng)常延遲提交，測試的效果也因此常常被降低。

33、但我們還是要盡量避免測試受到項目文檔的制約。 5. 允許根據(jù)多種來源提供的綜合信息來設(shè)計一些獨立的測試。 6. 讓測試被重新設(shè)計， 以新的信息形式進行表現(xiàn)。 7. 包含反饋的循環(huán)，讓測試設(shè)計可以考慮到，在運行測試時還可以繼續(xù)發(fā)現(xiàn)到更多的測試內(nèi)容。 8. 讓測試人員認識到， 避免測試的延遲可以節(jié)省成本。 9. 在組件被組裝到程序中去之前對組件的執(zhí)行進行測試。 感謝 是 James Bach 最早讓我認識到，在測試計劃中應(yīng)考慮到交接。Noel Nyman 和 Johanna Rothman 在一份草案中提供了一些有幫助的評論。Kamesh Pemmaraju 和 Carol Stollmeyer

34、使我終于沒有放棄對原理的辯解和闡述， 不僅是在細節(jié)方面， 也在實際生活中， 以及每一個實際項目中。他們給了我很大的促進， 使我去地思考問題。 參考Boehm88Barry W. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer, 1988 年 5 月IEEE98IEEE Standard for Software Test Documentation, IEEE 標準 829-1998, 電子和電氣工程師學會, 1998Marick98Brian Marick, “When Should

35、 a Test be Automated?” 國際質(zhì)量（/pub/papers/automate.pdf）,1998 年 5 月14第頁歡迎訪問我們的網(wǎng)站 - ? 北京慧靈科技有限公司依托測試時代資源，推出面向?qū)嵺`的軟件測試專業(yè)課程，由國內(nèi)著名軟件企業(yè)的一線技術(shù)專家主講，為您的企業(yè)解 決實踐中的關(guān)鍵問題。如果您培訓(xùn)的目的不是拿一個證書，而是想學習 軟件測試的最佳實踐，那我們會是您一個不錯的選擇。 詳情請登陸公司網(wǎng)站： 2005 年 02 月第五期測試員電子期刊二、嵌入式軟件測試策略作者： a

36、dmin在嵌入式領(lǐng)域目標系統(tǒng)的應(yīng)用系統(tǒng)日趨復(fù)雜，而由于競爭要求產(chǎn)品快速上市，開發(fā)技術(shù)日新月異，同時硬件發(fā)展的日益穩(wěn)定，而軟件故障卻日益突出，軟件的重要性逐漸引起人們的重視，越來越多的人認識到嵌入式系統(tǒng)的測試勢在必行。提到嵌入式軟件測試，首先要簡單介紹一些軟件工程的一些觀點，現(xiàn)在，被普遍接受的軟件的定義是：軟件(software)是計算機系統(tǒng)中與硬件(hardware)相互依存的另一部分，它包括程序(program)、相關(guān)數(shù)據(jù)(data)及其說明文檔(document)。其中程序是按照事先設(shè)計的功能和性能要求執(zhí)行的指令序列；數(shù)據(jù)是是程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu)；文檔是與程序開發(fā)維護和使用有關(guān)的各

37、種圖文資料。 對于一般商用軟件的測試，嵌入式軟件測試有其自身的特點和測試困難。 由于嵌入式系統(tǒng)的自身特點，如實時性(Real-timing)，內(nèi)存不豐富，I / O 通道少，開發(fā)工具昂貴，并且與硬件緊密相關(guān) CPU 種類繁多，等等。嵌入式軟件的開發(fā)和測試也就與一般商用軟件的開發(fā)和測試策略有了很大的不同，可以說嵌入式軟件是最難測試的一種軟件。 嵌入式軟件測試使用有效的測試策略是唯一的出路，它可以使開發(fā)的效率最大化，避免目標系統(tǒng)的瓶頸，使用在線仿真器節(jié)省昂貴的目標資源。自從出現(xiàn)高級語言，開發(fā)環(huán)境與最終運行環(huán)境通常都是存在差異的，嵌入式系統(tǒng)更是如此。開發(fā)環(huán)境被認為是主機平臺，軟件運行環(huán)境為目標平臺。

38、相應(yīng)的測試為 host-target 測試或 cross-testing。 討論嵌入式軟件測試首先就會遇到一個問題：為什么不把所有測試都放在目標上進行呢？因為若所有測試都放在目標平臺上有很多不利的因素： 1）測試軟件，可能會造成與開發(fā)者爭奪時間的瓶頸，避免它只有提供更多的目標環(huán)境。 2）目標環(huán)境可能還不可行。 3）比起主機平臺環(huán)境，目標環(huán)境通常是不精密的和不方便的。 4）提供給開發(fā)者的目標環(huán)境和聯(lián)合開發(fā)環(huán)境通常是很昂貴的。 5）開發(fā)和測試工作可能會妨礙目標環(huán)境已存在持續(xù)的應(yīng)用 從經(jīng)濟上和開發(fā)效率上考慮，軟件開發(fā)周期中盡可能大的比例在主機系統(tǒng)環(huán)境中進行， 其中包括測試。 15第頁www.ltes

39、歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊 確定 host-target 測試環(huán)境后，開發(fā)測試人員又會遇到以下的問題： 1）多少開發(fā)人員會卷入測試工作（單元測試，軟件集成，系統(tǒng)測試）? 2）多少軟件應(yīng)該測試，測試會花費多長時間？ 3）在主機環(huán)境和目標環(huán)境有哪些軟件工具，價格怎樣，適合怎樣? 4）多少目標環(huán)境可以提供給開發(fā)者，什么時候? 5）主機和目標機之間的連接怎樣？ 6）被測軟件下載到目標機有多快? 7）使用主機與目標環(huán)境之間有什么限制（如軟件安全標準）? 任何人或組織進行嵌入式軟件的測試都應(yīng)深入考慮以上問題，結(jié)合自身實際情況，選定合理測試策略和方案

40、。 對于嵌入式軟件測試或叫交叉測試（cross-test），在測試的各個階段有著通用的策略： 1單元測試： 所有單元級測試都可以在主機環(huán)境上進行，除非少數(shù)情況，特別具體指定了單元測試直接在目標環(huán)境進行。最大化在主機環(huán)境進行軟件測試的比例，通過盡可能小的目標單元訪問所有目標指定的界面。 在主機平臺上運行測試速度比在目標平臺上快的多，當在主機平成測試，可以在目標環(huán)境上重復(fù)作一簡單的確認測試，確認測試結(jié)果在主機和目標機上沒有被他們的不同影響。在目標環(huán)境上進行確認測試將確定一些未知的，未預(yù)料到的，未說明的主機與目標機的不同。例如，目標編譯器可能有 bug，但在主機編譯器上沒有。 2集成測試： 軟件集成

41、也可在主機環(huán)境上完成，在主機平臺上模擬目標環(huán)境運行，當然在目標環(huán)境上重復(fù)測試也是必須的，在此級別上的確認測試將確定一些環(huán)境上的問題，比如內(nèi)存定位和分配上的一些錯誤。 在主機環(huán)境上的集成測試的使用，依賴于目標系統(tǒng)的具體功能有多少。有些嵌入式系統(tǒng)與目標環(huán)境耦合的非常緊密，若在主機環(huán)境做集成是不切實際的。一個大型軟件的開發(fā)可以分幾個級別的集成。別的軟件集成在主機平臺上完成有很大優(yōu)勢，越往后的集成越依賴于目標環(huán)境。 16第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊3系統(tǒng)測試和確認測試 所有的系統(tǒng)測試和確認測試必須在目標環(huán)境下執(zhí)行。當然在主機上

42、開發(fā)和執(zhí)行系統(tǒng)測試，然后移植到目標環(huán)境重復(fù)執(zhí)行是很方便的。對目標系統(tǒng)的依賴性會妨礙將主機環(huán)境上的系統(tǒng)測試移植到目標系統(tǒng)上，況且只有少數(shù)開發(fā)者會卷入系統(tǒng)測試，所以有時放棄在主機環(huán)境上執(zhí)行系統(tǒng)測試可能更方便。 確認測試最終的實施舞臺必須在目標環(huán)境中，系統(tǒng)的確認必須在真實系統(tǒng)之下測試，而不能在主機環(huán)境下模擬。這關(guān)系到嵌入式軟件的最終使用。 包括恢復(fù)測試、安全測試、強度測試、性能測試，已超出了軟件測試的范疇，本文暫不討論。 使用有效的 cross-test 測試策略可極大的提高嵌入式軟件開發(fā)測試的水平和效率，當然正確的測試工具使用也是必不可少的： 總結(jié)一下，應(yīng)用以上測試工具進行.Cross-test

43、時的策略： A) 使用測試工具的插裝功能（主機環(huán)境）執(zhí)行靜態(tài)測試分析，并且為動態(tài)覆蓋測試準備好一插裝好的軟件代碼。 B) 使用源碼在主機環(huán)境執(zhí)行功能測試，修正軟件的錯誤和測試腳本中的錯誤。 C) 使用插裝后的軟件代碼執(zhí)行覆蓋率測試，添加測試用例或修正軟件的錯誤，保證達到所要求的覆蓋率目標。 D) 在目標環(huán)境下重復(fù)（B），確認軟件在目標環(huán)境中執(zhí)行測試的正確性。 E) 若測試需要達到的完整性，最好在目標系統(tǒng)上重復(fù)（C），確定軟件的覆蓋率沒有改變。 通常在主機環(huán)境執(zhí)行多數(shù)的測試，只是在最終確定測試結(jié)果和最后的系統(tǒng)測試才移植到目標環(huán)境，這樣可以避免發(fā)生訪問目標系統(tǒng)資源上的瓶頸，也可以減少在昂貴資源如在

44、線仿真器上的費用。另外，若目標系統(tǒng)的硬件由于某種原因而不能使用時，最后的確認測試可以推遲直到目標硬件可用，這為嵌入式軟件的開發(fā)測試提供了彈性。設(shè)計軟件的可移植性是成功進行 cross-test 的先決條件，它通常可以提高軟件的質(zhì)量，并且度軟件的維護大有益處。以上所提到的測試工具，都可以通過各自的方式提供測試在主機與目標之間的移植，從而使嵌入式軟件的測試得以方便的執(zhí)行。 使用有效的 cross-test 測試策略可極大的提高嵌入式軟件開發(fā)測試的水平和效率，提高嵌入式軟件的質(zhì)量。 17第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊附錄： 1

45、). HOST-TARGET 的連接方法簡介： 圖 1- 直接連接 圖 2 - 通過仿真器連接 18第頁歡迎訪問我們的網(wǎng)站 - ? 2005 年 02 月第五期測試員電子期刊 圖 3 - 使用介質(zhì)進行間接連接 圖 4 - 使用 PROM 等傳遞被測軟件 圖 5 - 測試的交互界面19第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊圖 6 - 無交互界面的連接-三、Rational ClearQuest 技巧集 作者： pyp & http 前提： Rational ClearQuest 的版本為 2002.

46、05.00 問題一： 給某些字段設(shè)置使用權(quán)限， 只有相關(guān)人員才能看到某些字段而進行填寫，對于一般人員使它變?yōu)椴灰姡?我該如何設(shè)置呢？ 解答提示：一個比較簡單的方法可以讓別人看不到你設(shè)置的字段：設(shè)置一個新的組，把想看新字段的人加到這個組中，在 Designer 中，設(shè)置 Forms 的時候，加一個 Tab頁， 把只想讓一部分人看到的字段都加到這個頁中， 鼠標右擊這個字段，在屬性頁中， 有“ User Group Access” 這個選擇， 選擇你想要看的組加到列表中就可以了。在使用的過程中， 只有相關(guān)的組成員才能看到這個 tab 頁， 也就間接的等于別人看不到這些字段了。 問題二：在 Web 端

47、訪問的時候，只能看到提示“ Restricted Query Not Defined” 。 解答提示：一般是因為沒有注冊的緣故，使用 CQ 的過程中，必須對 Web 服務(wù)器進行License 注冊。 問題三： 如何讓一些 Database 不顯示在客戶端和 Web 端的使用列表中。 20第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 02 月第五期測試員電子期刊解答提示： 在使用 CQ 的過程中， 必須選擇 Database 才可以進入客戶端或 Web 端。而 Database 的內(nèi)容， 與選擇的 Schema Repository(s)有關(guān)，下面就是如何讓部分Da

48、tabase 不顯示在列表中。 在 Designer 中， 選擇菜單中的 Database-Update User Database Properties，選擇不需要顯示的 Logical Database Name， 點擊“ Properties” 按鈕，進入配置頁面。在配置頁面中， 把“ Production Database”選擇為“ Test Database” ， 點擊“ Update” ， 則此 Database 將不會顯示在列表中。如果將來想要恢復(fù)， 只要把“ Test Database” 再選擇成“ Production Database”即可。 問題四： 在 project

49、的 Forms 下， 我為項目經(jīng)理設(shè)計了一個下拉列表框， 請問： 如何將 users 下面的 field:login_name、fullname 下面的記錄值自動在這個下拉列表框里顯示。格式就是： login_name(fullname)。 解答提示： 這個我并不清楚你要做什么， 是在下拉框中顯示所有用戶的登陸名和全稱， 還是顯示一個組的， 或者是顯示當前登陸用戶的？ 如 果 顯示 當前 用 戶的 ，則 比 較 的簡 單。 直接login_name=session.GetUserLoginName,full_name=login_name.fullname,把login_name 和 full

50、_name 拼成一個字符串顯示出來就可以了。 如 果是 在 組 中的，你 可以查看安裝 目 錄 ClearQuestapihelpindex.htm中Session Object，User Object，Group Object，Groups Object 幾章。我的想法是：在 field 的 Choice List 中， 使用程序進行列表內(nèi)容的控制， 建立一個 session，使用 session.GetUserGroups 取到用戶組， 再 for each user in 用戶組，在里面choices.additem(user)，但是我試驗了一個上午，不知道什么原因，一直都沒有成功過，你

51、不妨再仔細的看看 Rational ClearQuest API Reference 里面的東西吧。如果能解決， 最好告訴我解決的辦法， 我也學習學習。 問題五： 對于特定的字段， 強制要求用戶每次 Action 的時候， 都必須填寫。 解答提示： 在字段的 Permission 中，用下面的代碼控制： SetFieldvalue Field1, 把字段的值設(shè)置為空 Field_Permission=AD_MANDATORY 讓字段必填 在 Behaviors 中把需要必填的字段狀態(tài)設(shè)置成 Hook 就可以了。 21第頁歡迎訪問我們的網(wǎng)站 - ?2005 年 0

52、2 月第五期測試員電子期刊 問題六：在 Clearquest Designer 里設(shè)置 Field 時那些 Type 都代表什么意思？ 比如， Type 里的 REFERENCE,REFERENCE_LIST 都是什么類型， 設(shè)置成這個類型后， 會出現(xiàn)什么結(jié)果？ 您能給我詳細說一下嗎？ 解答提示：在 ClearQuest Designer Help 中的 Selecting a field data type 中有相應(yīng)的說明。 ClearQuest supports the following field data types: Data Description/Comments ATTACH

53、MENT_LIST: Allows records to store files related to the record. DATE_TIME: SQL date and time. INT: SQL integer. MULTILINE_STRING: A variable-length string of unlimited size. REFERENCE: A reference to a unique key in a record type.For REFERENCE type fields, you must select a state-based or stateless record type to refer to. You can also enter