《軟件測試》課件第9章

項目九對MercuryWebToursApplication網(wǎng)站的性能測試中?9.1問題情境9.2問題分析9.3任務的設計與實施9.4知識總結9.5應用實踐

對LoadRunner安裝時所帶的示例程序MercuryWebToursApplication用LoadRunner進行簡單的測試。9.1問題情境

MercuryWebToursApplication是惠普公司為LoadRunner測試工具編寫的一個以機票預訂為原型的示例程序，我們只對注冊部分進行簡單的測試。9.2問題分析

9.3.1錄制腳本

啟動LoadRunner，界面如圖9-1所示。9.3任務的設計與實施圖9-1LoadRunner啟動界面在LoadRunner啟動界面點擊“Create/EditScripts”，進入如圖9-2所示界面。圖9-2腳本錄制界面在腳本錄制界面，點擊“NewVuserScript”按鈕，進入如圖9-3所示界面。圖9-3協(xié)議選擇界面即將測試的應用程序是Web類型的，故采用HTTP協(xié)議。在協(xié)議選擇界面，選擇“Web(HTTP/HTML)”協(xié)議，點擊“OK”按鈕，進入如圖9-4所示界面。圖9-4任務向?qū)D9-5開始錄制圖9-6設置錄制參數(shù)在設置錄制參數(shù)界面，由于即將要測試的應用程序是Web類型的，因此在“Applicationtype”項選擇“InternetApplications”，在“Programtorecord”項選擇機器上的“MicrosoftInternet”，在“URLAddress”項輸入:1080/WebTours/，在“Workingdirectory”項選擇“C:\ProgramFiles\InternetExplorer”。然后確保示例程序“MercuryWebToursApplication”能夠正常打開。

其啟動方式為：首先選擇“開始—所有程序—MercuryLoadRunner—Samples—Web—StartWebServer”，其次選擇“開始—所有程序—MercuryLoadRunner—Samples—Web—MercuryWebToursApplication”，看是否能夠打開網(wǎng)頁。在確定能夠打開“MercuryWebToursApplication”后，點擊“OK”按鈕，LoadRunner開始錄制腳本。打開IE瀏覽器，如圖9-7所示。圖9-7MercuryWebToursApplication的首界面圖9-8MercuryWebToursApplication的注冊界面圖9-9MercuryWebToursApplication注冊成功界面此時停止腳本錄制。LoadRunner已經(jīng)把之前操作過程中所錄制的HTTP協(xié)議內(nèi)容轉(zhuǎn)換為腳本?？梢栽贚oadRunner主界面上選擇菜單“View—ScriptView”，則出現(xiàn)如圖9-10所示界面。圖9-10腳本界面至此即完成了最基本的腳本錄制，LoadRunner會自動形成基本的測試腳本代碼。但是這些測試腳本代碼還不能馬上用于測試，因為還需要對其進行參數(shù)化的設置，讓其可以更好地模擬顯示用戶使用軟件系統(tǒng)時的情形。9.3.2編輯腳本

1．編輯手動操作時對耽擱或是延誤時間的處理

在腳本錄制過程中，經(jīng)常會有許多的停頓，LoadRunner默認地會把停頓時間錄制下來加到腳本中，例如“l(fā)r_think_time(200)；”表示腳本在此時停頓了200秒的時間。很多時候這些值是不合理的，需要進行修改。根據(jù)實際情況在如圖9-10所示腳本界面上進行相應的修改。本例中將兩處的時間分別修改為25秒和35秒。

2．腳本參數(shù)化

在該任務中，我們注冊的是賬號，所以每次的用戶名應該是不一樣的，在此應該將用戶名參數(shù)化。

在代碼編輯區(qū)域中選中“chenwei”后，以右鍵選擇“ReplacewithaParameter”，出現(xiàn)如圖9-11所示界面。圖9-11參數(shù)化名稱和類型在參數(shù)化名稱和類型界面中，點擊“Properties…”按鈕，可進行參數(shù)化屬性的編輯，如圖9-12所示。圖9-12參數(shù)化屬性設置在參數(shù)化屬性設置界面，單擊“CreateTable”按鈕，可創(chuàng)建參數(shù)化表格并輸入?yún)?shù)數(shù)據(jù)，如圖9-13所示。圖9-13創(chuàng)建的參數(shù)表格如圖9-13所示，可將具體的參數(shù)逐個輸入，也可以點擊“EditwithNotepad”按鈕，用記事本編輯器來編輯，如圖9-14所示。圖9-14記事本中的邊界參數(shù)9.3.3可視化地添加事務

事務是用于模擬用戶的一個完整業(yè)務操作的過程，LoadRunner提供了可視化添加事務的方式。

首先在任務向?qū)Ы缑娴牡谌齻€步驟中點擊“Transactions”按鈕，則出現(xiàn)如圖9-15所示界面。圖9-15事務編輯界面在事務編輯界面中，LoadRunner把錄制過程中發(fā)生的動作以截獲的界面的方式列出來。點擊右邊的“NewTransaction”按鈕，可以進行事務的添加和編輯。在此只做默認處理。9.3.4運行腳本

在完成了測試腳本后，就可以設計運行場景并運行了。

1．設計運行場景

單擊任務向?qū)Ы缑嬷械摹癋inish”，出現(xiàn)如圖9-16所示界面。圖9-16完成界面圖9-17創(chuàng)建場景在圖9-17所示的創(chuàng)建場景界面中，可以選擇場景的創(chuàng)建類型，指定虛擬用戶的數(shù)量，確定壓力產(chǎn)生的機器名等，具體設置如圖9-17所示。然后點擊“OK”按鈕，LoadRunner就會調(diào)出“Controller”模塊，如圖9-18所示。圖9-18場景設計界面在場景設計界面中，可以進行進一步的場景設計。在此只指定場景運行的持續(xù)時間。在“GlobalSchedule”界面的列表中，選擇“Duration”并雙擊，出現(xiàn)如圖9-19所示界面，在該界面中修改相應的時間。圖9-19編輯場景持續(xù)運行的時間

2．運行場景

設定好時間后，就可以按運行按鈕(快捷鍵F5)，開始按照設計的場景運行腳本，如圖9-20所示。

可以通過選擇“Monitors”菜單下的“AddMeasurements”來添加對各種性能參數(shù)的監(jiān)控。圖9-20運行場景9.3.5分析結果

LoadRunner提供了專門的性能測試報告和分析工具，用于對測試過程中收集到的數(shù)據(jù)進行整理分析，匯總成測試報告，并用各種圖表展現(xiàn)出來。

1．初步的結果分析

場景運行完畢后，LoadRunner會自動收集運行過程中的所有監(jiān)控數(shù)據(jù)，并用圖表的方式展現(xiàn)出來，如圖9-21和圖9-22所示。圖9-21運行的虛擬用戶數(shù)和狀態(tài)統(tǒng)計表圖9-22事務相應時間及統(tǒng)計表如圖9-21所示，虛擬用戶在運行1分鐘后達到了峰值，也就是設定的10個虛擬用戶同時在運行中。除了狀態(tài)圖外，還給出了統(tǒng)計表。在圖9-22中展示了事務響應時間的狀態(tài)變化圖及事務響應時間統(tǒng)計表。

2．產(chǎn)生測試分析報告

如果想要查看更加詳細的分析圖表并產(chǎn)生測試報告，可選擇“Results”菜單下的“AnalyzeResult”，則LoadRunner會調(diào)出“Analysis”模塊，如圖9-23所示。圖9-23測試報告在這個界面中，包括了概要測試報告以及各種圖表報告。測試人員可按需要將其整合成一份完整的測試報告。

9.4.1LoadRunner的介紹

LoadRunner是一種預測系統(tǒng)行為和性能的負載測試工具。通過以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題，LoadRunner能夠?qū)φ麄€企業(yè)架構進行測試。通過使用LoadRunner，企業(yè)能最大限度地縮短測試時間，優(yōu)化性能和加速應用系統(tǒng)的發(fā)布周期。9.4知識總結LoadRunner是一種適用于各種體系架構的自動負載測試工具，它能預測系統(tǒng)行為并優(yōu)化系統(tǒng)性能。LoadRunner的測試對象是整個企業(yè)的系統(tǒng)，它通過模擬實際用戶的操作行為和實行實時性能監(jiān)測，來幫助用戶更快地查找和發(fā)現(xiàn)問題。此外，LoadRunner能支持廣泛的協(xié)議和技術，為用戶的特殊環(huán)境提供特殊的解決方案。LoadRunner的主要功能有下面6種。

1．輕松創(chuàng)建虛擬用戶

使用LoadRunner的VirtualUserGenerator，用戶能很簡便地創(chuàng)立起系統(tǒng)負載。該引擎能夠生成虛擬用戶，以虛擬用戶的方式模擬真實用戶的業(yè)務操作行為。它先記錄下業(yè)務流程，然后將其轉(zhuǎn)化為測試腳本。利用虛擬用戶，可以在Windows、UNIX或Linux機器上同時產(chǎn)生成千上萬個用戶訪問。所以LoadRunner能極大地減少負載測試所需的硬件和人力資源。

2．創(chuàng)建真實的負載

VirtualUsers建立起來后，用戶需要設定自己的負載方案、業(yè)務流程組合和虛擬用戶數(shù)量。利用LoadRunner的Controller，用戶能很快地組織起多用戶的測試方案。Controller的Rendezvous功能提供一個互動的環(huán)境，在其中用戶既能建立起持續(xù)且循環(huán)的負載，又能管理和驅(qū)動負載測試方案。而且，用戶可以利用它的日程計劃服務來定義用戶在什么時候訪問系統(tǒng)以產(chǎn)生負載。這樣，用戶就能將測試過程自動化。同樣用戶還可以用Controller來限定用戶的負載方案，在這個方案中所有的用戶同時執(zhí)行一個動作，例如登錄到一個庫存應用程序來模擬峰值負載的情況。另外，用戶還能監(jiān)測系統(tǒng)架構中各個組件的性能，包括服務器、數(shù)據(jù)庫、網(wǎng)絡設備等來幫助客戶決定系統(tǒng)的配置。

3．定位性能問題

LoadRunner內(nèi)含集成的實時監(jiān)測器，在負載測試過程的任何時候，用戶都可以觀察到應用系統(tǒng)的運行性能。這些性能監(jiān)測器為用戶實時顯示交易性能數(shù)據(jù)(如響應時間)和其他系統(tǒng)組件，包括ApplicationServer、WebServer、網(wǎng)絡設備和數(shù)據(jù)庫等的實時性能。這樣，用戶就可以在測試過程中從客戶和服務器這兩方面來評估這些系統(tǒng)組件的運行性能，從而更快地發(fā)現(xiàn)問題。利用LoadRunner的ContentCheck，用戶可以判斷負載下的應用程序功能正常與否。ContentCheck在VirtualUsers運行時，檢測應用程序的網(wǎng)絡數(shù)據(jù)包內(nèi)容，從中確定是否有錯誤內(nèi)容傳送出去。它的實時瀏覽器幫助用戶從終端用戶角度觀察程序的性能狀況。

4．分析結果以精確定位問題所在

一旦測試完畢，LoadRunner即收集匯總所有的測試數(shù)據(jù)，并提供高級的分析和報告工具，以便迅速查找到性能問題并追溯原由。通過使用LoadRunner的Web交易細節(jié)監(jiān)測器，用戶可以了解到將所有的圖像、框架和文本下載到每一網(wǎng)頁上所需的時間。例如，這個交易細節(jié)分析機制能夠分析是否因為一個大尺寸的圖形文件或是第三方的數(shù)據(jù)組件而使應用系統(tǒng)運行的速度減慢。另外，Web交易細節(jié)監(jiān)測器可分解用于客戶端、網(wǎng)絡和服務器上端到端的反應時間，以便于確認問題，定位查找真正出錯的組件。例如，用戶可以將網(wǎng)絡延時進行分解，以判斷DNS解析時間和連接服務器或SSL認證所花費的時間。通過使用LoadRunner的分析工具，用戶能很快地查找到出錯的位置和原因并做出相應的調(diào)整。

5．重復測試保證系統(tǒng)發(fā)布的高性能

負載測試是一個重復過程。每次處理完一個出錯情況，用戶都需要在相同的方案下對自己的應用程序再進行一次負載測試，以此檢驗自己所做的修正是否改善了運行性能。

6．其他功能

利用LoadRunner，用戶可以很方便地了解系統(tǒng)的性能。它的Controller允許用戶重復執(zhí)行與出錯修改前相同的測試方案。它的基于HTML的報告可為用戶提供一個比較性能結果所需的基準，以此衡量在一段時間內(nèi)，有多大程度的改進并確保應用成功。由于這些報告是基于HTML文本的，因此用戶可以將其公布于用戶公司的內(nèi)部網(wǎng)上，便于隨時查閱。9.4.2LoadRunner的安裝

雙擊setup啟動安裝，如圖9-24所示。圖9-24提取文件過程圖9-25檢測機器上有沒有安裝必備程序圖9-26LoadRunner安裝向?qū)g迎界面圖9-27協(xié)議聲明圖9-28設置用戶信息界面圖9-29安裝類型界面圖9-30安裝目錄界面圖9-31安裝確認界面圖9-32安裝進行中界面圖9-33安裝完成界面9.4.3LoadRunner的測試步驟

(1)用戶確定需要進行性能測試的業(yè)務或交易，通過用戶操作和VuserGenerator的錄制功能來記錄并生成虛擬用戶腳本。

(2)手工修改虛擬用戶腳本，確定腳本能夠回放成功。

(3)在Controller中對場景進行設置后，就可以啟動測試了。在測試過程中，Controller控制LoadGenerator對被測系統(tǒng)的加壓方式和行為。

(4)

Controller同時負責搜集被測系統(tǒng)各個環(huán)節(jié)的性能數(shù)據(jù)。各個LoadGenerator會記錄最終用戶響應時間和腳本執(zhí)行的日志。

(5)壓力運行結束以后，LoadGenerator將數(shù)據(jù)傳到Controller中，由Controller對測試結果進行匯總。

(6)測試人員借助數(shù)據(jù)分析工具Analysis對性能測試數(shù)據(jù)進行分析，進而確定瓶頸和調(diào)優(yōu)方法。

(7)針對性地對系統(tǒng)進行調(diào)優(yōu)，重復進行壓力測試，確定性能是否有所提高。9.4.4Web網(wǎng)站的測試

隨著Internet和Intranet/Extranet應用的快速增長，Web已經(jīng)對商業(yè)、工業(yè)、銀行、財政、教育、政府和娛樂及我們的工作和生活產(chǎn)生了深遠的影響。許多傳統(tǒng)的信息和數(shù)據(jù)庫系統(tǒng)正在被移植到互聯(lián)網(wǎng)上，電子商務迅速增長。范圍廣泛的、復雜的分布式應用正在Web環(huán)境中出現(xiàn)。Web的流行已無所不在，這是因為它能提供支持所有類型內(nèi)容連接的信息發(fā)布，容易為最終用戶存取。早在1998年就有了Web工程的概念。Web工程作為一門新興的學科，提倡使用一個過程和系統(tǒng)的方法來開發(fā)高質(zhì)量的基于Web的系統(tǒng)。它使用合理的、科學的工程和管理原則，用嚴密的和系統(tǒng)的方法來開發(fā)、發(fā)布和維護基于Web的系統(tǒng)。目前，對于Web工程的研究主要在國外開展，國內(nèi)才剛剛起步。在基于Web的系統(tǒng)開發(fā)中，如果缺乏嚴格的過程，我們在開發(fā)、發(fā)布、實施和維護Web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨著基于Web的系統(tǒng)變得越來越復雜，一個項目的失敗將可能導致很多問題。當這種情況發(fā)生時，我們對Web和Internet的信心可能會無法挽救地動搖，從而引起Web危機。而且，Web危機可能會比軟件開發(fā)人員所面對的軟件危機更加嚴重、更加廣泛。在Web工程過程中，基于Web系統(tǒng)的測試、確認和驗收是一項重要而富有挑戰(zhàn)性的工作?；赪eb的系統(tǒng)測試與傳統(tǒng)的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基于Web的系統(tǒng)變得困難。因此，我們必須為測試和評估復雜的基于Web的系統(tǒng)研究新的方法和技術。一般軟件的發(fā)布周期以月或以年計算，而Web應用的發(fā)布周期以天甚至以小時計算。Web測試人員必須處理更短的發(fā)布周期，測試人員和測試管理人員面臨著從測試傳統(tǒng)的C/S結構和框架環(huán)境到測試快速改變的Web應用系統(tǒng)的轉(zhuǎn)變。一個網(wǎng)站基本完工后，需要通過下面三步測試才可以交付使用：

(1)制作者測試：包括美工測試頁面、程序員測試功能。在做完后第一時間內(nèi)由制作者本人進行測試。測試包括以下兩方面：

首頁、二級頁面、三級頁面的頁面在各種常用分辨率下有無錯位，圖片上有無錯別字，各鏈接是否是死鏈接，各欄目圖片與內(nèi)容是否對應等。

功能達到客戶要求，數(shù)據(jù)庫鏈接正確，各個動態(tài)生成鏈接正確，傳遞參數(shù)格式、內(nèi)容正確，試圖填寫測試內(nèi)容沒有報錯，頁面顯示正確等。

(2)全面測試：根據(jù)交付標準和客戶要求，由專人進行全面測試。它也包括頁面和程序兩方面，而且要結合起來測試，保證填充足夠的內(nèi)容后不會導致頁面變形。另外要檢查是否有錯別字，文字內(nèi)容是否有常識性錯誤。

(3)發(fā)布測試：網(wǎng)站發(fā)布到主服務器之后的測試，主要是防止因環(huán)境不同而導致的錯誤。

1．功能測試

對于網(wǎng)站的測試而言，每一個獨立的功能模塊需要設計單獨的測試用例，主要依據(jù)為《需求規(guī)格說明書》及《詳細設計說明書》。對于應用程序模塊，需要設計者提供基本路徑測試法的測試用例。

1)鏈接測試

鏈接是Web應用系統(tǒng)的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面：

(1)測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面。

(2)測試所鏈接的頁面是否存在。

(3)保證Web應用系統(tǒng)上沒有孤立的頁面。所謂孤立頁面，是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問的頁面。

鏈接測試可以自動進行，現(xiàn)在已經(jīng)有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統(tǒng)的所有頁面開發(fā)完成之后進行鏈接測試。Xenu是一款主要測試鏈接正確性的工具，它只在對動態(tài)生成的頁面的測試中會出現(xiàn)一些錯誤。

2)表單測試

當用戶給Web應用系統(tǒng)提交信息時，就需要使用表單操作，例如用戶注冊、登錄、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如，用戶填寫的出生日期與職業(yè)是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，也要進行測試。例如，只能接受某些字符，測試時可以跳過這些字符，看系統(tǒng)是否會報錯。要測試這些程序，需要驗證服務器能否正確保存這些數(shù)據(jù)，而且后臺運行的程序能否正確解釋和使用這些信息。

B/S結構實現(xiàn)的功能主要有提交數(shù)據(jù)、處理數(shù)據(jù)等。如果有固定的操作流程，可以考慮自動化測試工具的錄制功能，編寫可重復使用的腳本代碼，也可以在測試、回歸測試時運行以便減輕測試人員的工作量。

對子系統(tǒng)各個功能模塊中的各項功能進行逐一測試，主要測試方法為邊界值測試、等價類測試以及異常類測試。測試中要保證每種類型都有兩個以上的典型數(shù)值的輸入，以確保測試輸入的全面性。

3)

Cookies測試

Cookies通常用來存儲用戶信息和用戶在某應用系統(tǒng)的操作。當一個用戶使用Cookies訪問了某一個應用系統(tǒng)時，Web服務器將發(fā)送關于用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，可用來創(chuàng)建動態(tài)和自定義頁面或者存儲登錄等信息。

如果Web應用系統(tǒng)使用了Cookies，就必須檢查Cookies是否能正常工作而且是否已經(jīng)對這些信息進行了加密。測試的內(nèi)容可包括Cookies是否起作用、是否按預定的時間進行保存、刷新對Cookies有什么影響等。

4)設計語言測試

Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環(huán)境中開發(fā)時，開發(fā)人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，對不同的腳本語言，例如Javascript、ActiveX、VBScript或Perl等也要進行驗證。

5)數(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)崩潰。

1)連接速度測試

用戶連接到Web應用系統(tǒng)的速度根據(jù)上網(wǎng)方式的變化而變化，它們或者是電話撥號，或者是寬帶上網(wǎng)。當下載一個程序時，用戶可以等待較長的時間，但如果僅僅訪問一個頁面，Web系統(tǒng)響應時間太長(例如超過5秒鐘)，用戶就會因沒有耐心等待而離開。

另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內(nèi)容，就需要重新登錄了。而且，連接速度太慢，還可能引起數(shù)據(jù)丟失，使用戶得不到真實的頁面。

2)負載測試

負載測試測量Web系統(tǒng)在某一負載級別上的性能，以保證Web系統(tǒng)在需求范圍內(nèi)能正常工作。負載級別可以是某個時刻同時訪問Web系統(tǒng)的用戶數(shù)量，也可以是在線數(shù)據(jù)處理的數(shù)量。

負載測試應該安排在Web系統(tǒng)發(fā)布以后，在實際的網(wǎng)絡環(huán)境中進行。因為一個企業(yè)內(nèi)部員工，特別是項目組人員總是有限的，而一個Web系統(tǒng)能同時處理的請求數(shù)量將遠遠超出這個限度，所以，只有放在Internet上進行負載測試，其結果才是正確可信的。

3)壓力測試

進行壓力測試是指實際破壞一個Web應用系統(tǒng)，以測試系統(tǒng)的反應。壓力測試主要測試系統(tǒng)的限制和故障恢復能力，也就是測試Web應用系統(tǒng)會不會崩潰，在什么情況下會崩潰。

壓力測試的區(qū)域包括表單、登錄和其他信息傳輸頁面等。

3．接口測試

在很多情況下，Web站點不是孤立的。Web站點可能會與外部服務器通信，請求數(shù)據(jù)、驗證數(shù)據(jù)或提交訂單。

1)服務器接口

第一個需要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，然后查看服務器記錄，并驗證在瀏覽器上看到的正是服務器上發(fā)生的。測試人員還可以查詢數(shù)據(jù)庫，確認事務數(shù)據(jù)已正確保存。

2)外部接口

有些Web系統(tǒng)有外部接口。例如，網(wǎng)上商店可能要實時驗證信用卡數(shù)據(jù)以減少欺詐行為的發(fā)生。測試的時候，要使用Web接口發(fā)送一些事務數(shù)據(jù)，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店只使用Visa卡和Mastercard卡，則可以嘗試使用Discover卡的數(shù)據(jù)(簡單的客戶端腳本能夠在提交事務之前對代碼進行識別，例如3表示AmericanExpress，4表示Visa，5表示Mastercard，6代表Discover)。通常，測試人員需要確認軟件能夠處理外部服務器返回的所有可能的消息。

3)錯誤處理

最容易被測試人員忽略的地方是接口錯誤處理。通常測試人員試圖確認系統(tǒng)能夠處理所有錯誤，但卻無法預期系統(tǒng)所有可能的錯誤。嘗試在處理過程中中斷事務，看看會發(fā)生什么情況，訂單是否完成，嘗試中斷用戶到服務器的網(wǎng)絡連接，嘗試中斷Web服務器到信用卡驗證服務器的連接。在這些情況下，查看系統(tǒng)能否正確處理這些錯誤，是否已對信用卡進行收費。如果用戶自己中斷事務處理，在訂單已保存而用戶沒有返回網(wǎng)站確認的時候，需要由客戶代表通知用戶進行訂單確認。

4．可用性/易用性測試

在可用性/易用性方面，目前只能采用手工測試的方法進行評判，而且缺乏一個好的評判基準，此方面需要共同討論。

1)導航測試

導航描述了用戶在不同的鏈接頁面之間的易操作性。通過考慮下列問題，可以決定一個Web應用系統(tǒng)是否易于導航：導航是否直觀，Web系統(tǒng)的主要部分是否可通過主頁存取，Web系統(tǒng)是否需要站點地圖、搜索引擎或其他的導航幫助等。在一個頁面上放太多的信息往往會起到與預期相反的效果。Web應用系統(tǒng)的用戶趨向于目的驅(qū)動，很快地掃描一個Web應用系統(tǒng)，看是否有滿足自己需要的信息，如果沒有，就會很快地離開，很少有用戶愿意花時間去熟悉Web應用系統(tǒng)的結構。因此，Web應用系統(tǒng)導航幫助要盡可能地準確。

導航的另一個重要方面是Web應用系統(tǒng)的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統(tǒng)里面是否還有內(nèi)容，內(nèi)容在什么地方。Web應用系統(tǒng)的層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。

2)圖形測試

在Web應用系統(tǒng)中，適當?shù)膱D片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統(tǒng)的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內(nèi)容有以下四種：

(1)要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統(tǒng)的圖片尺寸要盡量地小，并且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面上。

(2)驗證所有頁面字體的風格是否一致。

(3)背景顏色應該與字體顏色和前景顏色相搭配。

(4)圖片的大小和質(zhì)量也是一個很重要的因素，一般采用JPG或GIF壓縮格式。

3)內(nèi)容測試

內(nèi)容測試用來檢驗Web應用系統(tǒng)提供信息的正確性、準確性和相關性。信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛。信息的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行，例如使用MicrosoftWord的“拼寫與語法檢查”功能。信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中所謂的“相關文章列表”。

4)整體界面測試

整體界面是指整個Web應用系統(tǒng)的頁面結構設計要給用戶一個整體感。例如，當用戶瀏覽Web應用系統(tǒng)時是否感到舒適，是否憑直覺就知道要找的信息在什么地方，整個Web應用系統(tǒng)的設計風格是否一致。

對整體界面的測試過程，其實是一個對最終用戶進行調(diào)查的過程。一般Web應用系統(tǒng)采取在主頁上做一個調(diào)查問卷的形式，來得到最終用戶的反饋信息。

對所有的可用性測試來說，都需要有外部人員(與Web應用系統(tǒng)開發(fā)沒有聯(lián)系或聯(lián)系很少的人員)的參與，最好是最終用戶的參與。

5．兼容性測試

兼容性測試需要驗證應用程序是否可以在用戶使用的機器上運行。如果用戶是全球范圍的，需要測試各種操作系統(tǒng)、瀏覽器、視頻設置和Modem速度。最后，還要嘗試各種設置的組合。

1)平臺測試

市場上有很多不同的操作系統(tǒng)類型，最常見的有Windows、UNIX、Macintosh、Linux等。Web應用系統(tǒng)的最終用戶究竟使用哪一種操作系統(tǒng)，取決于用戶系統(tǒng)的配置。這樣，就可能會發(fā)生兼容性問題，同一個應用可能在某些操作系統(tǒng)下能正常運行，但在另外的操作系統(tǒng)下可能會運行失敗。因此，在Web系統(tǒng)發(fā)布之前，需要在各種操作系統(tǒng)下對Web系統(tǒng)進行兼容性測試。

2)瀏覽器測試

瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java、

Javascript、ActiveX、plug-ins或不同的HTML規(guī)格有不同的支持。例如，ActiveX是Microsoft的產(chǎn)品，是為InternetExplorer而設計的，Javascript是Netscape的產(chǎn)品，Java是Sun的產(chǎn)品等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，有時甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。

測試瀏覽器兼容性的一個方法是創(chuàng)建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。

3)視頻測試

視頻測試是測試頁面版式在640

×

400、600

×

800或1024

×

768等不同的分辨率模式

下是否顯示正常，字體是否太小(或者是太大)以至于無法瀏覽，文本和圖片是否對齊等問題。

4)

Modem連接速率測試

如果用戶使用28.8KModem上網(wǎng)，而測試人員在測試的時候使用的是2M或更高的網(wǎng)速，則不會發(fā)現(xiàn)這樣的缺陷。那么，用戶在下載文章或演示的時候，可能就會等待比較長的時間，這個時候用戶不會耐心等待操作的完成。這對于Web系統(tǒng)來說也是一個嚴重的缺陷，因此在設計Web系統(tǒng)時要考慮到不同網(wǎng)速的用戶。

5)打印機測試

用戶可能會將網(wǎng)頁打印下來，因此網(wǎng)頁在設計的時候要考慮到打印問題，注意節(jié)約紙張和油墨。有不少用戶喜歡閱讀而不是盯著屏幕，因此需要驗證網(wǎng)頁打印是否正常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不一樣。測試人員至少需要驗證訂單確認頁面的打印是正常的。

6)組合測試

最后需要進行組合測試。600

×

800的分辨率在MAC機上可能不錯，但是在IBM兼容機上卻很難看。在IBM機器上使用Netscape能正常顯示，但卻無法使用Linux來瀏覽。

如果是內(nèi)部使用的Web站點，測試可能會輕松一些。如果公司指定使用某個類型的瀏覽器，那么只需在該瀏覽器上進行測試。如果所有的人都使用T1專線，可能不需要測試下載施加。但需要注意的是，可能會有員工從家里撥號進入系統(tǒng)。有些內(nèi)部應用程序，開發(fā)部門可能在系統(tǒng)需求中聲明不支持某些系統(tǒng)而只支持那些已設置的系統(tǒng)，但是理想的情況是，系統(tǒng)能在所有機器上運行，這樣就不會限制將來的發(fā)展和變動。

6．安全性測試

Web應用系統(tǒng)的安全性測試區(qū)域主要有以下幾個方面。

1)目錄設置

Web安全的第一步就是正確設置目錄。每個目錄下應該有index.html或main.html頁面，這樣就不會顯示該目錄下的所有內(nèi)容。如果沒有執(zhí)行這條規(guī)則，那么選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑“…com/objects/images”，然后在瀏覽器地址欄中手工輸入該路徑，發(fā)現(xiàn)該站點所有圖片的列表。這可能沒什么關系，但是進入下一級目錄“…com/objects”，在該目錄下有很多資料，其中有些是已過期的頁面。如果該公司每個月都要更改產(chǎn)品價格信息，并且保存過期頁面，那么只要翻看一下這些記錄，就可以估計他們的邊際利潤以及他們?yōu)榱藸幦∫粋€合同還有多大的降價空間。如果某個客戶在談判之前查看了這些信息，他們在談判桌上肯定處于上風。

2)登錄

現(xiàn)在的Web應用系統(tǒng)基本采用先注冊后登錄的方式。因此，必須測試有效和無效的用戶名和密碼，要注意是否對大小寫敏感、可以試多少次的限制、是否可以不登錄而直接瀏覽某個頁面等。

3)Session

Web應用系統(tǒng)是否有超時的限制，也就是說，用戶登錄后在一定時間內(nèi)(例如15分鐘)沒有點擊任何頁面，是否需要重新登錄才能正常使用。

4)日志文件

為了保證Web應用系統(tǒng)的安全性，建立日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。

5)加密

當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

6)安全漏洞

服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試未經(jīng)過授權就不能在服務器端放置和編輯腳本的問題。

7．代碼合法性測試

代碼合法性測試主要包括以下兩個部分：

(1)程序代碼合法性檢查。程序代碼合法性檢查主要標準為《intergrp小組編程規(guī)范》，目前采用由SCM管理員進行規(guī)范的檢查，未來期望能夠由相應的工具進行測試。

(2)顯示代碼合法性檢查。顯示代碼的合法性檢查主要分為Html、Javascript、Css代碼檢查，目前采用HTML代碼檢查——采用CSEHTMLValidator進行測試，JavaScript、CSS也可以在網(wǎng)上下載相應的測試工具。

8．文檔測試

1)產(chǎn)品說明書屬性檢查清單

(1)完整：是否有遺漏和丟失，是否完全，是否包含全部內(nèi)容。

(2)準確：既定解決方案是否正確，目標是否明確，有沒有錯誤。

(3)精確：不含糊，清晰，描述是否一清二楚，是否是自說自話，是否容易看懂和理解。

(4)一致：產(chǎn)品功能描述是否自相矛盾，與其他功能有沒有沖突。

(5)貼切：描述功能的陳述是否必要，有沒有多余信息，功能是否是客戶原來的要求。

(6)合理：在特定的預算和進度下，以現(xiàn)有人力、物力和資源能否實現(xiàn)。

(7)代碼無關：是否堅持定義產(chǎn)品，而不是定義其所信賴的軟件設計、架構和代碼。

(8)可測試性：特性能否測試，測試員建立驗證操作的測試程序能否提供足夠的信息。

2)產(chǎn)品說明書用語檢查清單

(1)說明：對問題的描述通常表現(xiàn)為粉飾沒有仔細考慮的功能，這可歸結于前文所述的屬性。從產(chǎn)品說明書上找出這樣的用語，仔細審視它們在文中是怎樣使用的，產(chǎn)品說明書可能會為其掩飾和開脫，也可能含糊其辭，無論是哪一種情況都可視為軟件缺陷。

(2)總是、每一種、所有、沒有、從不：如果看到此類絕對或肯定的、切實認定的敘述，軟件測試員就可以著手設計針鋒相對的案例。

(3)當然、因此、明顯、顯然、必然：這些詞語意圖誘使接受假定情況，不要中了圈套。

(4)某些、有時、常常、通常、慣常、經(jīng)常、大多、幾乎：這些詞語太過模糊?！坝袝r”發(fā)生作用的功能無法測試。

(5)等等、諸如此類、依此類推：以這樣的詞結束的功能清單無法測試。功能清單要絕對或者解釋明確，以免讓人迷惑，不知如何推論。

(6)良好、迅速、廉價、高效、小、穩(wěn)定：這些是不確定的說法，不可測試。如果在產(chǎn)品說明書中出現(xiàn)，就必須進一步指明含義。

(7)已處理、已拒絕、已忽略、已消除：這些詞匯可能會隱藏大量需要說明的功能。

(8)如果……那么……(沒有否則)：找出有“如果……那么……”而缺少配套的“否則”結構的陳述，想一想“如果”沒有發(fā)生會怎樣。9.4.5軟件測試質(zhì)量保證

1．軟件質(zhì)量保證與軟件測試

軟件質(zhì)量(SoftWareQuality)是貫穿軟件生存期的一個極為重要的問題，是軟件開發(fā)過程中所使用的各種開發(fā)技術和驗證方法的最終體現(xiàn)。因此，在軟件生存期中要特別重視質(zhì)量的保證，以生成高質(zhì)量的軟件產(chǎn)品。

1)軟件質(zhì)量保證

軟件質(zhì)量是一個軟件企業(yè)成功的必要條件，其重要性無論怎樣強調(diào)都不過分。軟件質(zhì)量與傳統(tǒng)意義上的質(zhì)量概念并無本質(zhì)差別，只是針對軟件的某些特性進行了調(diào)整。

軟件質(zhì)量由三部分構成：

軟件產(chǎn)品的質(zhì)量，即滿足使用要求的程度。

軟件開發(fā)過程的質(zhì)量，即能否滿足開發(fā)所帶來的成本、時間和風險等要求。

軟件在其商業(yè)環(huán)境中所表現(xiàn)的質(zhì)量。

總結起來，高品質(zhì)軟件應該是相對的無產(chǎn)品缺陷或只有極少量的缺陷，它能夠準時遞交給客戶，所花費用都在預算內(nèi)，并且滿足客戶需求，是可維護的。但是，有關質(zhì)量好壞的最終評價依賴于用戶的反饋。

軟件質(zhì)量具有以下三個特性：

(1)可說明性：用戶可以基于產(chǎn)品或服務的描述和定義加以使用。

(2)有效性：產(chǎn)品或服務對于客戶的需求是否能保持有效，如具有99.99%有效性，就可以說達到質(zhì)量要求。

(3)易用性：對于用戶，產(chǎn)品或服務非常容易使用并且一定是非常有用的功能。

過程質(zhì)量是探索復雜系統(tǒng)開發(fā)過程的秩序，按一定規(guī)程工作，可以較合理地達到目標。規(guī)程由一系列活動組成，形成方法體系，建立嚴格的工程控制方法，要求每一個人都要遵守工程規(guī)范。目前主要流行的過程改進模型有兩種：軟件能力成熟度模型(CMM)和國際標準過程模型。

軟件質(zhì)量保證(SQA)是指建立一套有計劃、有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。軟件質(zhì)量保證的目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產(chǎn)品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質(zhì)量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構方針的要求。

軟件的質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品，進一步來說，軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動，即為了確定、達到和維護需要的軟件質(zhì)量而進行的所有有計劃、有系統(tǒng)的管理活動。

任何形式的產(chǎn)品都是多個過程得到的結果，因此對過程進行管理與控制是提高產(chǎn)品質(zhì)量的一個重要途徑。對于一個軟件項目，質(zhì)量保證活動是自始至終的，它的管理對象是軟件過程，是對過程的管理。影響SQA活動效果的重要因素有以下幾個：

(1)知識結構：SQA人員的職責是審查軟件設計和開發(fā)人員的活動，驗證他們是否將選定的標準、方法和規(guī)程應用到活動中去。因此，SQA工作的有效執(zhí)行需要SQA人員掌握專業(yè)的技術。

(2)經(jīng)驗：SQA人員的經(jīng)驗對任務的實現(xiàn)同樣重要。應當選擇那些經(jīng)驗豐富的人來做SQA，同時為SQA人員進行專門的培訓，以使他們能夠勝任這項工作。

(3)依據(jù)：SQA人員的工作要有依據(jù)和判斷的標準，如果沒有這些標準，SQA人員就無法準確地判斷開發(fā)活動中的問題，容易引發(fā)不必要的爭論。因此公司應當建立開發(fā)標準和規(guī)程。

(4)全員參與：全員參與至關重要，高層管理者必須重視軟件質(zhì)量保證活動。

(5)把握重點：SQA人員在工作過程中一定要抓住問題的重點和本質(zhì)，盡可能避免陷入對細節(jié)的爭論之中。

2)軟件質(zhì)量保證與軟件測試的關系

軟件質(zhì)量保證與軟件測試二者之間既存在包含又存有交叉的關系。軟件測試能夠找出軟件缺陷，確保軟件產(chǎn)品滿足需求。但是測試不是質(zhì)量保證，二者并不等同。測試可以查找錯誤并進行修改，從而提高軟件產(chǎn)品的質(zhì)量。軟件質(zhì)量保證則是避免錯誤以求高質(zhì)量，并且還有其他方面的措施以保證質(zhì)量問題。

從共同點的角度看，軟件測試和軟件質(zhì)量保證的目的都是盡力確保軟件產(chǎn)品滿足需求，從而開發(fā)出高質(zhì)量的軟件產(chǎn)品，兩個流程都是貫穿整個軟件開發(fā)生命周期的。正規(guī)的軟件測試系統(tǒng)主要包括制定測試計劃、設計測試用例、實施測試、建立和更新測試文檔。而軟件質(zhì)量保證的工作主要為制定軟件質(zhì)量要求、組織正式審查、管理軟件測試、對軟件的變更進行控制、對軟件質(zhì)量進行度量、對軟件質(zhì)量情況及時記錄和報告。軟件質(zhì)量保證的職能是向管理層提供正確的可行信息，從而促進和輔助設計流程的改進。軟件質(zhì)量保證的職能還包括監(jiān)督測試流程，這樣測試工作就可以被客觀地審查和評估，同時也有助于測試流程的改進。

二者的不同之處在于，軟件質(zhì)量保證工作側重對軟件開發(fā)流程中的各個過程進行管理與控制，杜絕軟件缺陷的產(chǎn)生；而測試則是對已產(chǎn)生的軟件缺陷進行修復。

2．軟件測試管理和軟件測試團隊職責

隨著軟件開發(fā)規(guī)模的增大、復雜程度的增加，以尋找軟件中的錯誤為目的的測試工作就顯得更加困難。統(tǒng)計表明，開發(fā)較大規(guī)模的軟件，有40%以上的精力是耗費在測試上的。即使是富有經(jīng)驗的程序員，也難免在編碼中發(fā)生錯誤，何況有些錯誤在設計甚至分析階段就已埋下“禍根”。無論是早期潛藏下來的錯誤還是編碼中新引入的錯誤，若不及時排除，輕則降低軟件的可靠性，重則導致整個系統(tǒng)的失敗。為了盡可能多地找出程序中的錯誤，生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，加強對測試工作的組織和管理就顯得尤為重要。

1)軟件測試的組織

(1)測試的過程及組織。根據(jù)軟件測試計劃，由一位對整個系統(tǒng)設計熟悉的設計人員編寫測試大綱，明確測試的內(nèi)容和測試通過的準則，設計完整、合理的測試用例，以便系統(tǒng)實現(xiàn)后進行全面測試。當軟件由開發(fā)人員完成并檢驗后，提交測試組，由測試負責人組織測試。測試一般可以以下列方式組織：

①編寫測試大綱、測試用例。測試人員要仔細閱讀有關資料，包括規(guī)格說明、設計文檔、使用說明書及在設計過程中形成的測試大綱、測試內(nèi)容及測試的通過準則，全面熟悉系統(tǒng)，編寫測試計劃，設計測試用例，作好測試前的準備工作。

②將測試過程分階段。軟件測試過程按各測試階段的先后順序可分為單元測試、集成測試、確認(有效性)測試、系統(tǒng)測試和驗收(用戶)測試五個階段。

(2)測試人員組織。人是測試工作中最有價值也是最重要的資源，沒有一個合格的負責人、積極的測試小組，測試就不可能實現(xiàn)。為高質(zhì)高效地完成測試任務，應該組織測試人員進行集體學習，做到如下幾點：

測試項目的負責人必須做到：把要做的事情理清楚；把要達到的目的說清楚；把做事情的思路和方法理清楚；把合理的資源調(diào)配到合適的位置上，讓興趣和能力結合。從大的方面需要先將這些事情理清楚，才可能使得一個團隊具有非常好的戰(zhàn)斗力。組織測試人員定期培訓，讓團隊的每個人具備應有的溝通能力、技術能力、自信心、懷疑精神、自我督促能力和洞察力。

組織測試人員進行工作總結，例如在什么地方容易犯錯誤，犯什么類型的錯誤，犯錯誤的原因是什么。還需要對各種錯誤進行統(tǒng)計，以找到問題的根本原因。就問題而討論問題，提出問題的實質(zhì)是什么，然后改進。

組織測試人員提出意見。因為如果一個團隊要發(fā)展，是需要大家一起努力的，但是做起來卻很難。避免一言堂，讓大家充分參與到設計中，在其中找到自我的感覺，這樣每一個人才能關心項目的每一個角落，工作才能更有效率。

(3)軟件測試文件組織。軟件測試文件描述要執(zhí)行的軟件測試及測試的結果。由于軟件測試是一個很復雜的過程，同時也是設計軟件開發(fā)其他階段的工作，對于保證軟件的質(zhì)量和它的運行有著重要意義，因此必須把對它們的要求、過程及測試結果以正式的文件形式寫出。測試文件的編寫是測試工作規(guī)范化的一個組成部分。測試文件不只在測試階段才考慮，應在軟件開發(fā)的需求分析階段就開始著手，因為測試文件與用戶有著密切的關系。在設計階段的一些設計方案也應在測試文件中得到反映，以利于設計的檢驗。測試文件對于測試階段工作的指導與評價作用更是非常明顯的。需要特別指出的是，在已開發(fā)的軟件投入運行的維護階段，常常還要進行再測試或回歸測試，這時仍需用到測試文件。①測試文件的類型。根據(jù)測試文件所起的作用不同，通常把測試文件分成兩類，即測試計劃和測試分析報告。測試計劃詳細規(guī)定測試的要求，包括測試的目的和內(nèi)容、方法和步驟，以及測試的準則等。由于要測試的內(nèi)容可能涉及軟件的需求和軟件的設計，因此必須及早開始測試計劃的編寫工作。通常，測試計劃的編寫從需求分析階段開始，到軟件設計階段結束時完成。測試報告用來對測試結果進行分析說明，即經(jīng)過測試后，軟件具有的能力，以及它的缺陷和限制，并給出評價的結論性意見。這些意見既是對軟件質(zhì)量的評價，又是決定該軟件能否交付用戶使用的依據(jù)。由于要反映測試工作的情況，測試文件自然要在測試階段內(nèi)編寫。②測試文件的重要性。測試文件的重要性表現(xiàn)在以下幾個方面：

驗證需求的正確性：測試文件中規(guī)定了用以驗證軟件需求的測試條件，研究這些測試條件對弄清用戶需求是十分有益的。

檢驗測試資源：測試計劃不僅要用文件的形式把測試過程規(guī)定下來，還應說明測試工作必不可少的資源，進而檢驗這些資源是否可以得到，即它的可用性如何。如果某個測試計劃已經(jīng)編寫出來，但所需資源仍未落實，那就必須及早解決。

明確任務的風險：有了測試計劃，就可以弄清楚測試可以做什么，不能做什么。了解測試任務的風險有助于對潛藏的問題事先作好思想上和物質(zhì)上的準備。

生成測試用例：測試用例的好壞決定著測試工作的效率，選擇合適的測試用例是作好測試工作的關鍵。在測試文件編制過程中，按規(guī)定的要求精心設計測試用例具有重要的意義。

評價測試結果：測試文件包括測試用例，即若干測試數(shù)據(jù)及對應的預期測試結果。完成測試后，將測試結果與預期的結果進行比較，便可對已進行的測試提出評價意見。

再測試：測試文件規(guī)定的和說明的內(nèi)容對維護階段要進行的再測試是非常有用的。

決定測試的有效性：完成測試后，把測試結果寫入文件，這對分析測試的有效性，甚至整個軟件的可用性提供了依據(jù)。同時還可以證實有關方面的結論。

③測試文件的編制。在軟件的需求分析階段，就開始測試文件的編制工作，各種測試文件的編寫應按一定的格式進行。

確定進行各階段測試所需要的標準和策略，掌握其相關文檔。

確定監(jiān)督、管理和控制各測試階段的準則和方法。

確?？梢垣@得必要的資源和信息，以支持測試流程的正常進行和監(jiān)督工作的順利開展。

為了提高測試質(zhì)量，實行適當改進措施。

2)軟件測試的管理

在前面介紹了軟件測試是軟件質(zhì)量保證的關鍵步驟。為了真正做好軟件測試工作，系統(tǒng)地建立一個軟件測試管理體系是非常重要的，只有這樣才能確保軟件測試在軟件質(zhì)量保證中發(fā)揮應有的關鍵作用。

建立軟件測試管理體系有以下幾個方面：

確定軟件測試的每個階段，制定測試計劃、設計測試用例、實施測試、建立和更新測試文檔以及測試管理。

確定階段間的相互關系。制定測試計劃、設計測試用例、實施測試三個階段是按順序依次進行并且相互作用的，階段間的銜接是規(guī)范化的，即每個階段有開始標志和結束標志。測試管理對這三個階段進行監(jiān)督和管理。建立和更新測試文檔則貫穿整個測試流程。軟件測試管理的主要內(nèi)容如下：

(1)軟件產(chǎn)品的監(jiān)督和測量。對軟件產(chǎn)品的質(zhì)量特性進行監(jiān)督和測量，主要依據(jù)軟件需求規(guī)格說明書，驗證產(chǎn)品是否滿足要求，所開發(fā)的軟件產(chǎn)品是否可以交付。要預先設定質(zhì)量度量指標并進行測試，只有符合預先設定的指標才可以交付。

(2)對不符合要求的產(chǎn)品的識別和控制。對于軟件測試中發(fā)現(xiàn)的軟件缺陷，要認真記錄它們的屬性和處理辦法，并進行跟蹤，直至最終被修復。在修復軟件缺陷之后，要再次進行驗證測試。

(3)軟件過程的監(jiān)督和測量。從軟件測試中可以獲取大量關于軟件過程及其結果的數(shù)據(jù)和信息，利用它們可判斷這些過程的有效性，為軟件過程的正常運行和持續(xù)改進提供決策依據(jù)。

(4)產(chǎn)品設計和開發(fā)的驗證。通過設計測試用例對需求分析、軟件設計、程序代碼進行驗證，確保程序代碼與軟件設計說明書一致，軟件設計說明書與需求規(guī)格說明書一致。對于驗證中發(fā)現(xiàn)的不合格現(xiàn)象，同樣要認真記錄和處理，并跟蹤解決。解決之后，也要再次進行驗證。

3)測試團隊總的職責

組織一支優(yōu)秀的測試團隊是做好軟件測試工作的基本保障。良好的組織結構和人員劃分會促進測試工作的順利開展和實施，提高軟件測試的效率和質(zhì)量，從而大大提高軟件產(chǎn)品的開發(fā)效率和產(chǎn)品質(zhì)量。

在科學的管理體系下，軟件測試團隊各個成員要明確自身責任，既要完成本職工作又要相互協(xié)調(diào)好，為整個測試流程負責。軟件測試團隊人員的基本責任應該包括以下幾點：

盡早發(fā)現(xiàn)軟件產(chǎn)品中的所有問題；

督促軟件開發(fā)人員及時解決測試中發(fā)現(xiàn)的缺陷；

幫助項目管理人員制定合理的產(chǎn)品開發(fā)計劃；

對軟件產(chǎn)品中的問題進行分析和跟蹤調(diào)查，形成文檔，以便讓項目管理人員和相關產(chǎn)品開發(fā)人員對當前產(chǎn)品的質(zhì)量情況有全面的了解；

協(xié)助完善軟件開發(fā)流程，提高產(chǎn)品開發(fā)的效率。

4)軟件開發(fā)和測試過程的組織結構與職責劃分

圖9-34表示的是軟件開發(fā)和測試過程中的組織結構。參與整個軟件生產(chǎn)流程的人員種類很多，結構圖中列舉了具有代表性的開發(fā)和測試人員。其中，產(chǎn)品經(jīng)理和產(chǎn)品開發(fā)代表是核心領導。以軟件開發(fā)經(jīng)理為首的開發(fā)部門和以軟件測試經(jīng)理為首的測試部分既各有分工又需要相互合作，共同開發(fā)軟件，確保軟件質(zhì)量符合設計標準。

圖9-34軟件開發(fā)和測試過程中的組織結構

(1)在需求分析階段中，軟件開發(fā)人員的職責如下：

①軟件開發(fā)項目經(jīng)理的職責是：

帶領項目組分析審核工作任務書；

帶領項目組與系統(tǒng)工程師進行需求交流并進行分析和文檔化；

需求跟蹤。

②軟件開發(fā)工程師的職責是：

完成軟件需求說明書(SRS)文檔；

完成需求跟蹤；

參加SRS審查；

根據(jù)SRS評審專家意見，修改SRS文檔。

③開發(fā)代表的職責是：

與項目組一起審查項目任務書；

在評審結束后，批準SRS文檔。

(2)在需求分析階段中，軟件測試人員的職責如下：

①質(zhì)量保證/軟件測試經(jīng)理的職責是：

監(jiān)督項目組遵循需求管理流程；

參加SRS審查；

保證相關組參加SRS審查。

②軟件測試項目經(jīng)理的職責是：

參與開發(fā)人員的軟件需求分析，提出可測試性需求；

組織人員參與SRS的評審工作；

組織軟件系統(tǒng)測試計劃寫作；

組織軟件系統(tǒng)測試方案寫作。

③軟件測試工程師的職責是：

參與SRS評審工作；

協(xié)助軟件測試項目經(jīng)理完成軟件系統(tǒng)測試計劃的寫作；

協(xié)助軟件測試經(jīng)理完成軟件系統(tǒng)測試方案的寫作。

(3)在軟件設計階段中，軟件開發(fā)人員的職責如下：

①軟件開發(fā)項目經(jīng)理的職責是：

在項目計劃中標識設計活動并確保有足夠的資源；

從項目成員中標識出設計人員，負責設計工作；

確保設計人員按照本流程開發(fā)相應的設計說明書(HLD和LLD)；

確保按照審查規(guī)程進行設計的審查；

批準設計說明書(HLD和LLD)；

確保更新了需求跟蹤矩陣；

確保設計文檔按照配置管理流程來控制。

②軟件開發(fā)工程師的職責是：

完成設計文檔；

完成需求跟蹤；

參加設計文檔審查；

根據(jù)評審專家意見，修改設計文檔。

③相關評審專家的職責是：

針對設計文檔，提交評審意見；

參加設計文檔的評審會議；

確認修改后的意見。

(4)在軟件設計階段中，軟件測試人員的職責如下：

①質(zhì)量保證/軟件測試經(jīng)理的職責是：

監(jiān)督項目組遵循軟件設計流程；

參加設計審查；

保證相關組參加設計審查。

②軟件測試項目經(jīng)理的職責是：

組織所有的測試活動；

制定測試策略；

確保測試活動有合適的計劃；

審核并批準單元測試和集成測試的測試計劃；

確保所有分配需求被跟蹤和驗證；

確保測試策略在簽發(fā)后基線化，單元測試計劃(UTP)、集成測試計劃(ITP)、系統(tǒng)測試計劃(STP)在審查和批準后基線化。

需要說明的是，基線是指一個被正式評審和批準的規(guī)格和產(chǎn)品，它作為進一步開發(fā)的一個基礎必須通過正式的變更流程來變更。

③軟件測試工程師的職責是：

準備測試計劃(STP/UTP/ITP)；

撰寫單元測試(UT)/集成測試(IT)/系統(tǒng)測試(ST)測試用例；

完成需求跟蹤。

(5)軟件測試執(zhí)行階段，軟件測試人員的職責如下：

①軟件開發(fā)項目經(jīng)理的職責是：

確保缺陷分發(fā)給相關軟件工程師并及時得到解決；

參與需求變更評審。

②軟件開發(fā)工程師的職責是：

修正缺陷；

驗證相關的缺陷已經(jīng)被修正。

③軟件測試項目經(jīng)理的職責是：

組織所有的測試活動；

確保選擇適合的測試工具以及測試環(huán)境的建立；

確保測試活動的計劃得到執(zhí)行并獲得資源；

確保缺陷分發(fā)給相關軟件工程師并及時得到解決；

審核并批準測試報告；

審核并批準測試狀態(tài)報告。

④軟件測試工程師的職責是：

搭建測試環(huán)境；

執(zhí)行測試用例；

將測試中發(fā)現(xiàn)的所有缺陷填寫在缺陷報告中；

回歸測試；

準備測試報告；

測試期間，每周準備測試狀態(tài)報告。

3．ISO9000標準

近年來，國際上影響最為深遠的質(zhì)量管理標準當屬國際標準化組織于1987年公布的ISO9000系列標準了。這一國際標準發(fā)源于歐洲經(jīng)濟共同體，但很快就被美國、日本等國所采用。到目前為止，已有70多個國家在它們的企業(yè)中采用和實施了這一系列標準。一套國際標準在如此短的時間內(nèi)為這么多的國家采用，影響如此廣泛，實屬罕見。中國對此也十分重視，采取了積極態(tài)度，一方面確定對其等同采用，發(fā)布了與其相應的質(zhì)量管理國家標準系列GB/T19000；同時積極組織實施和開展質(zhì)量認證工作。計算機軟件行業(yè)自然也和其他領域一樣被席卷進去。

ISO9000有兩個顯著特點：

它的目標在于開發(fā)過程，而不是產(chǎn)品。它關心的是進行工作的組織方式而不是工作成果。

ISO9000只決定過程的要求是什么，而不管如何達到。

ISO9000標準中針對軟件的部分是ISO9001和ISO9000-3。ISO9001負責設計、開發(fā)、生產(chǎn)、安裝和服務產(chǎn)品方面的事務。ISO9000-3負責開發(fā)、供應、安裝和維護計算機軟件方面的事務。

ISO9000-3的核心內(nèi)容包括：

合同評審；

需方需求規(guī)格說明；

開發(fā)計劃；

設計和實現(xiàn)；

測試和確認；

驗收；

復制、交付和安裝；

維護。

1)合同評審

在投標、接受合同或訂單之前，供方應對標書、合同或訂單進行評審，以確保如下方面的實施：

各項要求都有明確規(guī)定并形成文件。在以口頭方式接到訂單而對要求沒有書面說明的情況下，供方應確保訂單的要求在其接受之前得到同意。

任何與投標不一致的合同或訂單的要求已經(jīng)得到解決。

供方具有滿足合同或訂單要求的能力。

2)需方需求規(guī)格說明

在某一具體項目進行開發(fā)前，應具有一套該項目的完整、精確、無歧義的功能需求，這些需求應包括需方的所有要求。該需求應足以成為產(chǎn)品驗收確認時的依據(jù)。在制定需求規(guī)格說明時應注意以下幾點：

雙方指定專人負責。

需求認可和更改的批準。

防止誤解，定義好術語，對需求的前景進行說明。

記錄和評審雙方討論的結果，以備將來查詢某些需求、確定原因時使用。3)開發(fā)計劃

在項目進行前制定開發(fā)計劃，作為總體的策劃，指導整個項目有序的進行。開發(fā)計劃要求包括以下方面：

項目定義。

項目資源組織管理。

開發(fā)階段。

進度。

確定質(zhì)量保證計劃、測試計劃、集成計劃等。

4)設計和實現(xiàn)

設計和實現(xiàn)活動是將需求規(guī)格說明轉(zhuǎn)化為軟件產(chǎn)品的過程。為保證軟件產(chǎn)品的質(zhì)量，這些活動必須在嚴格規(guī)定的方法下進行，不能依賴于事后的審查監(jiān)督。

(1)設計。設計階段要滿足各階段的共同要求。此外，設計階段還應考慮如下幾方面：

選用適合所開發(fā)產(chǎn)品類型的設計方法；

總結、吸取以往項目的經(jīng)驗教訓；

設計應考慮軟件以后的測試、維護和使用。

(2)實現(xiàn)。規(guī)定編程規(guī)則、編程語言、命名約定、編碼和注釋規(guī)則等，要求在實現(xiàn)過程中嚴格遵守既定開發(fā)規(guī)則，選用合適的方法和工具實現(xiàn)產(chǎn)品。

(3)評審。為使需求規(guī)格說明得以滿足，上述規(guī)則方法得以實施，必須以評審的方式加以保證。直到所有被發(fā)現(xiàn)的缺陷都被消除或確定缺陷的風險可被控制后，才能進入下一步的設計或?qū)崿F(xiàn)工作。

5)測試和確認

要具有完整的測試計劃，測試計劃要經(jīng)過評審，并以此為依據(jù)進行測試活動。

(1)測試計劃包括以下幾個方面：

包括單元測試計劃、集成測試計劃、系統(tǒng)測試計劃、驗收測試計劃；

制定測試用例、測試數(shù)據(jù)和預期結果；

考慮要進行的測試類型；

描述測試環(huán)境、工具以及測試軟件；

軟件產(chǎn)品是否完成的判斷準則；

測試所需人員及其要求。

(2)測試活動應包括以下幾個方面：

記錄發(fā)現(xiàn)的問題，指出可能受影響的其他部分軟件，通知相關負責人員；

確定受影響的其他部分軟件，并對其進行重新測試；

評價測試是否適度和適當；

在驗收和交付產(chǎn)品前，必須盡可能在類似使用環(huán)境中進行確認測試。

6)驗收

當軟件產(chǎn)品已經(jīng)完成，經(jīng)過內(nèi)部確認測試準備好交付后，應要求需方根據(jù)合同中的規(guī)定原則判斷是否可以進行驗收。對于驗收中發(fā)現(xiàn)問題的處理辦法由雙方商定并納入文檔。具備驗收條件后，應制定驗收計劃并逐步實施。驗收計劃應包括：時間進度、評估規(guī)程、軟件/硬件環(huán)境、驗收準則。

7)復制、交付和安裝并制定安裝分發(fā)計劃

(1)復制。制作好安裝程序，復制好必要的副本，準備好該交付的操作手冊、用戶指南等文檔。

(2)交付。交付前應對所交付產(chǎn)品的正確性及完整性進行檢驗。

(3)安裝。就以下方面雙方應明確商定各自的作用、責任和義務：

時間進度及安排，包括非工作時間及假日的工作人員安排及工作責任；

提供出入便利條件；

指定熟練人員的密切配合；

提供必要的系統(tǒng)及設備；

對每次安裝的確認條件需明確規(guī)定；

對每次安裝認可的正式規(guī)程。

8)維護

對于軟件產(chǎn)品在初次交付及安裝后必須提供的維護，應在合同中明確規(guī)定。合同中應明確以下各項的維護期：程序、數(shù)據(jù)、規(guī)格說明。維護工作一般包括問題的解決、接口的調(diào)整、功能擴充和性能改進。

4．能力成熟度模型(CapabilityMaturityModel，CMM)

CMM即軟件能力成熟度模型。設計并實施CMM是為了指導軟件組織達到以下要求：

(1)確定當前過程的成熟度等級，識別出對軟件質(zhì)量和過程改進至關重要的問題，選擇其過程改進策略。

(2)通過關注一組有限的活動，并為實現(xiàn)它們而積極工作，組織能穩(wěn)步地改善其軟件過程，使其軟件過程能力持續(xù)不斷地增長。

1)軟件機構的成熟性

多年來軟件開發(fā)項目不能如期交付，軟件產(chǎn)品的質(zhì)量不能令客戶滿意，軟件開發(fā)的開銷超出項目開始時所做的預算，這些都是許多軟件開發(fā)機構遇到的難題。近20年中，不少人力圖采用新的軟件開發(fā)技術來解決軟件生產(chǎn)率和軟件質(zhì)量存在的問題，但結果卻不能令人滿意。這一現(xiàn)象促使人們進一步考察軟件過程，從而發(fā)現(xiàn)，關鍵問題在于軟件開發(fā)過程的管理很不完善。事實表明，在無規(guī)則和混亂的管理條件下，先進的技術和工具并不能發(fā)揮應有的作用。人們認識到改進軟件過程的管理是解決上述難題的突破口。有時，個別項目完成得比較好是因為有個別優(yōu)秀的軟件人員參與工作，并不是因為遵循了成熟的軟件過程。要想使多個項目都能很好地完成，不出現(xiàn)上述問題，除非讓這幾個優(yōu)秀的軟件人員承擔所有的項目，但這畢竟是不可能的。穩(wěn)定、持續(xù)地保證軟件高質(zhì)量的完成，只能依靠建立反映有效軟件工程實踐和管理實踐的過程基礎設施才能達到。

對于不同的軟件開發(fā)機構，在組織人員完成軟件項目時所依據(jù)的管理策略有很大差別，因而軟件項目所遵循的軟件過程也有很大差別。在此，可用軟件機構的成熟度加以區(qū)別。

2)能力成熟度模型(CMM)

CMM是一個行業(yè)標準模型，用于定義和評價軟件公司開發(fā)過程的成熟度，一般將軟件過程能力成熟度分為以下五個等級：

(1)初始級(等級1)：軟件過程的特點是無秩序的，偶爾甚至是混亂的。幾乎沒有什么過程是經(jīng)過定義的，成功依賴于個人的努力。

(2)可重復級(等級2)：已建立基本的項目管理過程用于跟蹤成本、進度和功能性。必要的過程記錄已經(jīng)就位，使具有類似應用的項目能重復以前的成功。

(3)已定義級(等級3)：管理活動和工程活動兩方面的軟件過程均已文檔化、標準化、并集成到組織的標準軟件過程中。全部項目均采用供開發(fā)和維護軟件的組織標準軟件過程中一個經(jīng)批準的剪裁本。

(4)已管理級(等級4)：已采集詳細的有關軟件過程和產(chǎn)品質(zhì)量的度量。無論軟件過程還是產(chǎn)品均得到定量了解和控制。

(5)優(yōu)化級(等級5)：利用來自過程和來自新思想、新技術先導性試驗的定量反饋信息，使持續(xù)過程改進成為可能。

3)利用CMM對軟件機構進行成熟度評估

評估過程有以下幾步：

(1)建立評估組。評估組成員應對軟件過程、軟件技術和應用領域很熟悉，有實踐經(jīng)驗，能夠提出見解。

(2)評估組準備具體審定評估問題，決定對每一個問題要求展示哪些材料和工具。

(3)項目準備。評估組與被評估機構領導商定選擇哪些處在不同開發(fā)階段的項目和典型的標準實施作為評估對象，并將評估時間安排通知被評估項目負責人。

(4)進行評估。對被評估機構的管理人員和項目負責人說明評估過程。評估組與項目負責人一起就所列出的問題逐一對照審查，保證對問題的回答有一致的解釋，從而取得一組初始答案。

(5)初評。對每個項目和整個機構做出成熟度等級初評。

(6)討論初評結果。使用備用資料及工具演示，可進一步證實某些問題的答案，從而決定可能的成熟度等級。

(7)給出最后的結論。由評估組綜合問題的答案以及背景證據(jù)，作出最終評估結論。9.4.6軟件測試經(jīng)驗與原則

測試是一個極其廣泛的領域，需要花費大量的時間和精力去研究和實踐。正如其他知識領域一樣，不可能在完全掌握了所有知識之后才開始應用。測試的知識是在不斷的實踐中積累并發(fā)展的。

下面介紹一下軟件測試人員在工作中進行測試的一些經(jīng)驗和原則：

(1)測試的GoodEnough原則。GoodEnough原則是一種權衡投入/產(chǎn)出比的原則：不充分