軟件測試項目實戰(zhàn)（第四版） 課件全套 于艷華 第1-7章：測試計劃- 性能測試之LoadRunner

軟件測試項目實戰(zhàn)（第四版）第1章：測試計劃目錄CONTENTS1.1.1關于軟件測試0102031.1.2軟件測試階段和軟件測試種類1.1.3關于測試計劃Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.1.1.1關于軟件測試一、軟件測試概述1．關于軟件測試軟件測試是什么？軟件測試就是對項目開發(fā)過程的產(chǎn)品（編碼、文檔等）進行差錯審查，保證其質量的一種過程。軟件業(yè)的迅猛發(fā)展也就是近幾十年的過程，時間雖短，但許多誤解似乎已根深蒂固，對測試的偏見也是如此?！败浖闹攸c在于需求、在于分析、在于設計、在于開發(fā)，而測試容易，沒什么技術含量，找一些用戶，對照需求盡力去測即可；有時間多測，沒時間就少測?！边@種看法在許多項目經(jīng)理、軟件負責人的心中固守著，難以改變。這種觀念的結果有目共睹，是什么？很簡單，是大量軟件Bug、缺陷的“流失”，從測試人員手中悄然而過，流失到用戶手中，流失到項目維護階段。隨之而來的，便是用戶無休止的抱怨、維護人員無休止的“救火”、維護成本無休止的增加。這是軟件人員的夢魘！噩夢總有醒來時，經(jīng)過無數(shù)教訓的重擊，在不堪回首而不得不回首的經(jīng)歷中，軟件業(yè)的管理者發(fā)現(xiàn)：是他們錯了，軟件測試是不可忽視的?！八羞@些問題，假如在項目中測試到，便不會有造成不可收拾的結果了?！薄藗兘K于意識到測試簡單而純真的真諦。軟件測試從直觀上來講是對測試對象進行檢查、驗證，似乎很簡單，但實際不然，它是由許多處理環(huán)節(jié)構成的。根據(jù)測試目標、質量控制的要求，它被劃分為以下各類環(huán)節(jié)，并被設置了不同的準入、準出標準。第1章測試技劃添加標題Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.添加標題Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.（1）軟件測試原則①盡早和持續(xù)不斷的測試；②徹底完全的測試是不可能的；③軟件測試是有風險的行為；④并非所有的軟件錯誤都能修復；⑤反向思維邏輯；⑥由小到大的測試范圍；⑦避免測試自己的項目；⑧從用戶需求入手。（2）為什么不能完全測試①測試數(shù)據(jù)輸入量太大；②輸出結果太多；③軟件的操作步驟太多；④軟件說明書并非“盲人手冊”。第1章測試技劃（3）并非所有的錯誤都能修復，Bug不能被關閉的原因①不算真正的軟件錯誤；②沒有足夠的時間；③修復的風險太大；④不值得修復。（4）錯誤集中發(fā)生現(xiàn)象①軟件開發(fā)人員的疲勞，造成大量代碼壞塊；②程序人員往往會犯同樣的錯誤，因為大部分代碼都是復制、粘貼而來的；③軟件的基礎構架問題，有些軟件的底層支撐系統(tǒng)因為“年久失修”變得越來越力不從心了；④發(fā)現(xiàn)缺陷的時間越早，Bug所造成的損失會越小。（5）避免檢查自己的代碼的原因①程序員從來都不會承認自己寫的程序有錯誤；②程序員的測試思路有明顯的局限性；③多數(shù)程序員沒有經(jīng)過嚴格正規(guī)的職業(yè)訓練；④程序員無良好的Bug跟蹤和回歸測試經(jīng)驗。第1章測試技劃2．測試過程正常的測試案例使用方式如圖1-1所示，測試設計階段，相關測試設計人員會對測試對象進行了解、分析，為保證測試順利進行，保證測試覆蓋盡量多的測試對象，會設計測試案例、測試方案，在測試期間進行使用；測試發(fā)現(xiàn)錯誤時，軟件技術人員會根據(jù)測試的缺陷反饋結果及技術人員的軟件修改信息對測試程序進行修改，完畢后再進行回歸測試。但是由于軟件測試這個行業(yè)本身就興起較晚，現(xiàn)在仍然處于比較不規(guī)范且存在很多問題尚未解決的階段。傳統(tǒng)的測試過程，測試管理不嚴密，測試人員未建立完整的測試庫，未將測試案例、測試程序、測試方案進行有效保存，等到回歸測試時，相關測試程序等往往已不知去向，無處可尋了；即使能找到這些程序、案例，可往往因為回歸測試過于頻繁、項目期限日益迫近，已經(jīng)沒有時間來修改、完善這些程序及案例，只能憑借經(jīng)驗、記憶及技術人員的口述對程序修改過的地方草草重測一遍而已，缺乏正規(guī)化的測試過程，造成測試的虎頭蛇尾。圖1-1測試流程第1章測試技劃二、軟件測試概念通常對軟件測試的定義有兩種描述：定義1：軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。定義2：軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結構而精心設計的一批測試用例，并利用這些測試用例運行程序以及發(fā)現(xiàn)錯誤的過程，即執(zhí)行測試步驟。三、軟件測試人才的需要1．軟件測試需求你們那兒缺什么人？隨便咨詢IT企業(yè)的HR（humanresource，人力資源管理。），他們必然仰天長嘆一聲，百分百地回答：軟件測試人員?。?）企業(yè)的需求幾乎每個大中型IT企業(yè)的軟件產(chǎn)品在發(fā)布前都需要大量的質量控制、測試和文檔工作，而這些工作必須依靠擁有嫻熟技術的專業(yè)軟件人才來完成，軟件測試工程師擔任的就是這樣一個企業(yè)重頭角色。（2）許多IT企業(yè)沒有專職的測試機制軟件產(chǎn)品的質量控制與管理越來越受重視，并逐漸成為企業(yè)生存與發(fā)展的核心。在許多IT企業(yè)中，軟件測試并非只擔當“挑錯”的角色，沒有專職的測試機制。越來越多的IT企業(yè)已逐漸意識到測試環(huán)節(jié)在軟件產(chǎn)品研發(fā)中的重要性。此類軟件質量控制工作均需要擁有嫻熟技術的專業(yè)軟件測試人才來協(xié)作完成，軟件測試工程師作為一個重頭角色正成為IT企業(yè)招聘的熱點，其中軟件測試工程師成為IT就業(yè)市場的最新風向標。第1章測試技劃（3）軟件測試工程師的需求量由于我國企業(yè)對于軟件測試自動化技術在整個軟件行業(yè)中的重要作用認識較晚，因此，軟件測試工程師的數(shù)量不足，開發(fā)和測試人員的比例不合理。據(jù)調(diào)查，較好的企業(yè)中測試人員和開發(fā)人員的比例是1∶8，有的是1∶20，甚至沒有專職的測試工程師。軟件測試專業(yè)技術人員在供需之間存在著巨大的缺口。據(jù)有關數(shù)據(jù)顯示，我國目前軟件從業(yè)人才缺口高達40萬人。即使按照軟件開發(fā)工程師與測試工程師1∶5的崗位比例計算，我國對于軟件測試工程師的需求便有數(shù)十萬之多。業(yè)內(nèi)專家預計，在未來5～10年中，我國社會對軟件測試人才的需求量還將繼續(xù)增大。在國展舉辦的一次招聘會上，多家企業(yè)紛紛打出各類高薪招聘軟件測試人員的海報，出人意料的是收到的簡歷尚不足招聘崗位數(shù)的50%，而合格的竟不足30%。有行業(yè)專家表示，軟件測試人才供遠小于求的現(xiàn)實問題正影響著我國軟件業(yè)的健康發(fā)展。軟件測試是一項需具備較強專業(yè)技術的工作。在具體工作過程中，測試工程師要利用測試工具按照測試方案和流程對產(chǎn)品進行性能測試。目前已經(jīng)陷入“有活沒人干”的尷尬局面。（4）網(wǎng)絡測試的需求量包括微軟在內(nèi)的公司對基于網(wǎng)絡測試也沒有一套完整的體系，仍處于探索中。網(wǎng)絡測試是一個全新的、富有挑戰(zhàn)性的工作，軟件測試工程師的職業(yè)之路充滿希望。第1章測試技劃2．軟件測試工程師未來的發(fā)展空間軟件測試工程師未來的職業(yè)發(fā)展方向如下：（1）走技術路線，成長為高級軟件測試工程師，再向上可以成為軟件測試架構設計師。（2）向管理方向發(fā)展，做項目管理。（3）做開發(fā)人員，很容易轉去做產(chǎn)品編程。主要軟件測試人員有如下四大魅力元素：①就業(yè)競爭?。虎诟咝?jīng)]商量；③多元化發(fā)展；④無性別歧視。3．職位描述（1）按照測試流程和計劃，構建測試環(huán)境，設計測試腳本和用例，執(zhí)行測試腳本和測試用例，尋找Bug；（2）分析問題所在并進行準確定位和驗證，按照標準格式填寫并提交Bug報告；（3）跟蹤并驗證Bug，并確認問題得以解決；（4）按照標準格式填寫并提交測試報告，編寫其他相關文檔；（5）完成軟件開發(fā)的集成測試工作。4．一則招聘代碼測試工程師的招聘廣告職位要求：（1）熟練操作計算機，計算機基礎知識扎實；（2）熟悉常用的軟件測試方法、軟件工程知識，熟悉面向對象設計的測試工作；（3）熟悉常用的軟件開發(fā)環(huán)境，編程工具；（4）有良好的英語閱讀能力，能夠閱讀英文測試資料；（5）責任心強，具備良好的溝通能力。第1章測試技劃四、測試人員應該具備的職業(yè)素養(yǎng)與核心素養(yǎng)對于軟件測試人員來說需要具備一些職業(yè)素質和核心素養(yǎng)，我覺得首先最重要的是要有一定的理論知識和測試技能，這是測試工作的基礎。那么我們測試人員還應該具備哪些核心素質才能在工作當中被不斷的的認可呢？（一）細心、耐心、積極、主動作為一名測試人員首先要踏實細心。

軟件測試，特別是當前國內(nèi)主流的手動黑盒功能測試?；旧宪浖y試的工作就是一項重復勞動，需要有一定的耐心來保證不在枯燥的重復勞動中放過那些微小缺陷。測試人員每天都要面對著枯燥的程序、需要規(guī)格說明書，從事著大量的重復工作，還要盡量發(fā)現(xiàn)產(chǎn)品中的

bug。如果不踏實，不細心，沒有面耐心，就無法掌握用戶對產(chǎn)品是怎么要求的，不細心，就特別容易一些產(chǎn)品中微笑的錯誤，而恰恰就是這些錯誤是最影響產(chǎn)品形象的問題。（

二）

好奇、懷疑、探究、求真

測試人員，如果只是測試產(chǎn)品能正常運行，就測試通過，這樣是無法發(fā)現(xiàn)問題的。測試人員進行測試的主要目的就是發(fā)現(xiàn)軟件存在缺陷，而不是證明它沒有缺陷。要具有懷疑一切的態(tài)度是一名合格的測試人員的基本要求。測試人員如果不認真負責，不抱著懷疑一切的態(tài)度。總想著這個功能應該沒什么問題，認為一般人不會去這樣操作它，這個功能沒什么用戶用不用認真測了。這樣發(fā)布的產(chǎn)品，是存在一定隱患的。所以一定要抱著懷疑一切的態(tài)度，從多個方面考慮，認為產(chǎn)品每個功能都可能有問題，多問一個為什么，如果這樣，行不行？，認真地測試產(chǎn)品的每一個測試點。第1章測試技劃（三）溝通、交流、團隊

眾所周知，測試的過程是一個發(fā)現(xiàn)問題并且跟蹤解決問題的一個過程，在這個過程中，要意識到測試、

開發(fā)、需求是一個團隊，一個整體。離了誰，產(chǎn)品的質量都無法保證。溝通能力作為一項特別重要的軟技能，在工作中起著舉足輕重的作用。作為一名測試人員，在提交問題的時候，要做到條理清晰，必要時配上圖片以便別人理解，自己提交的問題只有自己能看懂可不行。我們還需要和項目經(jīng)理交流了解最新的客戶需求，要和

開發(fā)人員溝通以便解決缺陷。

無論是和項目經(jīng)理還是開發(fā)員人交流的時候，態(tài)度很重要，特別是和開發(fā)人員交流時，可能會因為一個缺陷，兩人爭執(zhí)不下發(fā)生沖突，這時候我們測試人員要做到分析問題所在，同時也要聽聽開發(fā)人員的想法，心平氣和進行交流，最后實在是兩人都拿不定注意，可以請示上級。

（四）分析問題、解決問題、總結提升無論是哪個行業(yè)，都不能停滯不前，自我提高是必須的，這樣才不會被淘汰，那么作為一名優(yōu)秀的測試人員如何提高自己的測試能力呢？

1．首先提高自己的測試理論基礎。所有的測試基礎概念其實都是通用的：靜態(tài)測試，動態(tài)測試，

測試用例，等等以及一些測試相關技術：等價類劃分，邊界值，相信這些方法所有的人每天都在用，但是未必所有的人都能說明白。所以為自己每天所做的測試行動找點理論基礎，即有效率有與實踐相結合，這也是職業(yè)發(fā)展的重要一步。

2．要對測試的整體流程有完整的概念。這個是目前很多初級測試人員所欠缺的。目前大多數(shù)人只知道自己測試的是什么東西，但是不知道自己執(zhí)行的測試處于什么階段，下一個階段是什么，也許整個項目做完不知道；這對于一個產(chǎn)品來說是一個不負責任的行為，所以也就需要測試人員有端到端的測試意識和對測試流程的概念的認可，要有測試整體流程管理的概念。第1章測試技劃

3．為什么要執(zhí)行相關的測試工作。多問幾個為什么。有一個問題要先講清楚，就是有很多人還沒有注意到這個問題，領導讓怎么做就怎么做，也許真的做的很熟練了，但是一年后去問他為什么要這么做，相信他也說不出太多，反倒覺得就應該這么測。這樣帶來直接的弊端就是對自己的職業(yè)之路不負責任。另外，作為一名合格的測試人員，一定要注意進行總結。通過總結可以對自己的工作進行一個回顧分析，看看那些做得不錯，下次還繼續(xù)這么做。那些工作還有改進的余地。對自己能力的提高是一個很好的幫助。

4．責任擔當感

當代學生要在處理與社會、國家、國際等關系方面所形成的情感態(tài)度、價值取向和行為方式。具體包括社會責任、國家認同、國際理解等基本要點。測試人員要對所測試的對象質量負責，要能保證測試的覆蓋到每一需求點，同時要能保證功能都可以正確實現(xiàn)等或者達到了測試通過的標準。對于測試人員漏測，畢竟人不是完美的，難免會出現(xiàn)錯誤，但是不能以漏測來做為質量考核?？梢詫ζ溥M行分類分析，究竟是哪個環(huán)節(jié)出現(xiàn)的問題，提出來進行改進。比如說需求描述不完整，導致理解錯誤；隱含性需求未考慮到；易用性方面考慮不周；實際環(huán)境與測試環(huán)境有差異；自身經(jīng)驗不足等多方面。

新添加的內(nèi)容Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.1.1.2軟件測試階段和軟件測試種類第1章測試技劃一、軟件測試階段軟件的測試階段就是測試將按照什么樣的思路和方式進行。通常，軟件測試要經(jīng)過單元測試、集成測試、確認測試、系統(tǒng)測試以及驗收測試。這些階段和開發(fā)過程是相對應的。關于測試階段的叫法有多種，比如測試類型，測試策略等。1．單元測試（1）什么是單元測試單元測試是針對軟件設計的最小單位—程序模塊甚至代碼段進行正確性檢驗的測試工作。（2）什么時候進行單元測試在程序員編碼之后，代碼已通過編譯后進行單元測試，而且在前期就應該做一些準備工作．如單元測試計劃，單元測試用例等。（3）由誰來進行單元測試白盒測試工程師或開發(fā)人員。（4）單元測試的依據(jù)是什么源程序本身、《詳細設計》文檔。（5）單元測試通過的標準是什么程序通過所有單元測試的用例；語句的覆蓋率達到100%；分支的覆蓋率達到85%。第1章測試技劃（6）如何進行單元測試單元測試主要用白盒測試方法，一般先靜態(tài)檢查代碼是否符合規(guī)范，然后動態(tài)地運行代碼，檢查其運行結果。一個單元測試的小例子如下：該程序實現(xiàn)的功能如下，在主函數(shù)main()里面定義了一個含有5個整型元素的數(shù)組，用一個循環(huán)來實現(xiàn)數(shù)組元素的輸入，每次循環(huán)都調(diào)用1次iszero函數(shù)，如果輸入的數(shù)組元素不等于0，則打印輸出本身，如果為0，則輸出1。單元測試的一般步驟為編譯運行程序（查看能否正確運行）—靜態(tài)測試（檢查代碼是否符合規(guī)范）—動態(tài)測試（深入檢查代碼的正確性，容錯性和邊界值等）。①編譯運行程序。首先編譯程序，沒有語法上的錯誤，編譯通過。然后運行程序，輸入12340，按回車鍵。輸出12341，符合預期結果。②靜態(tài)測試。檢查程序中不符合編碼規(guī)范的地方。第1章測試技劃#include<stdio.h>voidiszero(intm){if(m!=0)printf("%d",m);else

printf("%d",1);}voidmain(void){inta[5];inti=0;printf("請輸入5個整數(shù)＼n");for(i=0;i<=4;i++){scanf("%d",&a[i]);iszero(a[i]);}}通過靜態(tài)測試檢查可以發(fā)現(xiàn)的問題有：函數(shù)之間沒有空行；低層次語句與高層次語句之間沒有縮進；沒有注釋。③動態(tài)測試邊界值問題沒有提示輸入1234567，運行結果12345，結果正確，但輸入超過5個元素，程序沒有提示非法數(shù)據(jù)的容錯性。第1章測試技劃（7）附：編碼規(guī)范①一行代碼只做一件事情，如只定義一個變量，或只寫一條語句，容易閱讀和注釋；②代碼行的最大長度值控制在70～80個字，否則不便于閱讀和打??；③函數(shù)與函數(shù)之間，定義語句和執(zhí)行語句之間最好加空行，空行不會浪費內(nèi)存；④在程序的開頭加注釋，說明程序的基本信息；在重要的函數(shù)模塊處加注釋，說明各函數(shù)的功能；⑤低層次的語句比高層次的語句縮進一個TAB鍵（4個空格），使程序結構更清晰；⑥不要漏掉函數(shù)的參數(shù)和返回值，如果沒有，則用void表示。2．集成測試集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發(fā)現(xiàn)與接口有關的問題。由于在產(chǎn)品提交到測試部門前，產(chǎn)品開發(fā)小組都要進行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的。時常有這樣的情況發(fā)生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調(diào)用時接口會引入許多新問題。例如，數(shù)據(jù)經(jīng)過接口可能丟失；一個模塊對另一模塊可能造成不應有的影響；幾個子功能組合起來不能實現(xiàn)主功能；誤差不斷積累達到不可接受的程度；全局數(shù)據(jù)結構出現(xiàn)錯誤，等等。綜合測試是組裝軟件的系統(tǒng)測試技術，按設計要求把通過單元測試的各個模塊組裝在一起之后，進行綜合測試以便發(fā)現(xiàn)與接口有關的各種錯誤。某設計人員習慣于把所有模塊按設計要求一次全部組裝起來，然后進行整體測試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因為測試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。第1章測試技劃（1）集成測試的非增量方式非增量式測試采用一步到位的方法構造測試。在對所有模塊進行測試后，按照程序結構圖將各模塊連接起來，把連接后的模塊當成一個整體進行測試。實例：對如下程序結構（a），如何進行非增量方式測試，測試過程如圖（b）～（h）所示。第1章測試技劃2）增量式測試增量式集成測試可按照不同次序實施，由此產(chǎn)生了兩種不同的方法，即自頂向下結合的方法和自底向上結合的方法。①自頂向下結合方法自頂向下集成是構造程序結構的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結構，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起。深度優(yōu)先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據(jù)問題的特性確定。以圖1-2為例，若選擇了最左一條路徑，首先將模塊M1，M2，M5和M8集成在一起，再將M6集成起來，然后考慮中間和右邊的路徑。廣度優(yōu)先策略則不然，它沿控制層次結構水平地向下移動。仍然以圖1-2為例，首先把M2、M3和M4與主控模塊集成在一起，再將M5和M6與其他模塊集成起來。圖1-2自頂向下集成第1章測試技劃由于下文用到樁模塊的概念，在此先向讀者介紹一下。在集成測試前要為被測模塊編制一些模擬其下級模塊功能的“替身”模塊，以代替被測模塊的接口，接受或傳遞被測模塊的數(shù)據(jù)，這些專供測試用的“假”模塊稱為被測模塊的樁模塊。自頂向下綜合測試的具體步驟為：

以主控模塊作為測試驅動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代；

依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個樁模塊；

每集成一個模塊立即測試一遍；

只有每組測試完成后，才著手替換下一個樁模塊；

為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復已做過的測試）。從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個程序結構構造完畢。圖1-2中，實線表示已部分完成的結構，若采用深度優(yōu)先策略，下一步將用模塊M7替換樁模塊S7，當然M7本身可能又帶有樁模塊，隨后將被對應的實際模塊替代。最后直至樁模塊S4被替代完畢為止。自頂向下集成的優(yōu)點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此較早地發(fā)現(xiàn)錯誤。缺點是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要數(shù)據(jù)不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發(fā)能模擬真實模塊的樁模塊；第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正，并且失去了在組裝模塊時進行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行，下面專門討論。第1章測試技劃例：有如下程序結構圖（a），按照自頂向下的方法完成測試活動的過程如下。第1章測試技劃②自底向上集成自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。自底向上綜合測試的步驟分為：

把底層模塊組織成實現(xiàn)某個子功能的模塊群（cluster）；

開發(fā)一個測試驅動模塊，控制測試數(shù)據(jù)的輸入和測試結果的輸出；

對每個模塊群進行測試；

刪除測試使用的驅動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構造完畢。圖1-3說明了上述過程。首先“原子”模塊被分為三個模塊群，每個模塊群引入一個驅動模塊進行測試。因模塊群1、模塊群2中的模塊均隸屬于模塊Ma，因此在驅動模塊D1、D2去掉后，模塊群1與模塊群2直接與Ma接口，這時可將D3去掉，將Mb與模塊群3直接接口，對Mb進行集成測試。這樣繼續(xù)下去，直至最后將驅動模塊D4、D5也去掉，最后Ma、Mb和Mc全部集成在一起進行測試。第1章測試技劃②自底向上集成自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。自底向上綜合測試的步驟分為：

把底層模塊組織成實現(xiàn)某個子功能的模塊群（cluster）；

開發(fā)一個測試驅動模塊，控制測試數(shù)據(jù)的輸入和測試結果的輸出；

對每個模塊群進行測試；

刪除測試使用的驅動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構造完畢。圖1-3說明了上述過程。首先“原子”模塊被分為三個模塊群，每個模塊群引入一個驅動模塊進行測試。因模塊群1、模塊群2中的模塊均隸屬于模塊Ma，因此在驅動模塊D1、D2去掉后，模塊群1與模塊群2直接與Ma接口，這時可將D3去掉，將Mb與模塊群3直接接口，對Mb進行集成測試。這樣繼續(xù)下去，直至最后將驅動模塊D4、D5也去掉，最后Ma、Mb和Mc全部集成在一起進行測試。第1章測試技劃自底向上集成方法不用樁模塊，測試用例的設計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象。它與自頂向下綜合測試方法的優(yōu)缺點正好相反。因此，在測試軟件系統(tǒng)時，應根據(jù)軟件的特點和工程的進度，選用適當?shù)臏y試策略，有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。例：有如下程序結構圖（a），用自底向上的測試方法進行測試的過程如下：第1章測試技劃第1章測試技劃此外，在綜合測試中尤其要注意關鍵模塊，所謂關鍵模塊一般都具有下述一個或多個特征：

對應幾條需求；

具有高層控制功能；

復雜、易出錯；

有特殊的性能要求。關鍵模塊應盡早測試，并反復進行回歸測試。3．系統(tǒng)測試系統(tǒng)測試是在集成測試通過后進行的，目的是充分運行系統(tǒng)，驗證各子系統(tǒng)是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產(chǎn)品的質量有重大的影響。計算機軟件是基于計算機系統(tǒng)的一個重要組成部分，軟件開發(fā)完畢后應與系統(tǒng)中其他成分集成在一起，此時需要進行一系列系統(tǒng)集成和確認測試。對這些測試的詳細討論已超出軟件工程的范圍，這些測試也不可能僅由軟件開發(fā)人員完成。在系統(tǒng)測試之前，軟件工程師應完成下列工作：

為測試軟件系統(tǒng)的輸入信息設計出錯處理通路；

設計測試用例，模擬錯誤數(shù)據(jù)和軟件界面可能發(fā)生的錯誤，記錄測試結果，為系統(tǒng)測試提供經(jīng)驗和幫助；

參與系統(tǒng)測試的規(guī)劃和設計，保證軟件測試的合理性。系統(tǒng)測試應該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能正常工作并完成所賦予的任務。下面簡單討論幾類系統(tǒng)測試。（1）恢復測試恢復測試主要檢查系統(tǒng)的容錯能力。當系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)?；謴蜏y試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復。對于自動恢復需驗證重新初始化（reinitialization）、檢查點（checkpointingmechanisms）、數(shù)據(jù)恢復（datarecovery）和重新啟動（restart）等機制的正確性；對于人工干預的恢復系統(tǒng)，還需估測平均修復時間，確定其是否在可接受的范圍內(nèi)。第1章測試技劃（2）安全測試安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，①

想方設法截取或破譯口令；②

專門定做軟件破壞系統(tǒng)的保護機制；③

故意導致系統(tǒng)失敗，企圖趁恢復之機非法進入；④

試圖通過瀏覽非保密數(shù)據(jù)，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統(tǒng)。因此系統(tǒng)安全設計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。（3）強度測試強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統(tǒng)在異常的資源配置下運行。例如，①

當中斷的正常頻率為每秒一至兩個時，運行每秒產(chǎn)生十個中斷的測試用例；②

定量地增長數(shù)據(jù)輸入率，檢查輸入子功能的反應能力；③

運行需要最大存儲空間（或其他資源）的測試用例；④

運行可能導致操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動的測試用例，等等。（4）性能測試對于那些實時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統(tǒng)真正集成之后，在真實環(huán)境中才能全面、可靠地測試運行操作系統(tǒng)，性能測試就是為了完成這一任務。性能測試有時與強度測試相結合，經(jīng)常需要其他軟硬件的配套支持。4．驗收測試驗收測試（acceptancetesting）以需求階段的《需求規(guī)格說明書》為驗收標準，測試時要求模擬實際用戶的運行環(huán)境。對于實際項目可以和客戶共同進行，對于產(chǎn)品來說就是最后一次的系統(tǒng)測試。測試內(nèi)容為對功能模塊的全面測試，尤其要進行文檔測試。驗收測試是系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關的用戶和/或獨立測試人員根據(jù)測試計劃和結果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。這是管理性和防御性控制。第1章測試技劃驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務。驗收測試是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所期待的那樣。通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步—確認測試即可開始。確認測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。實現(xiàn)軟件確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無論是計劃還是過程，都應該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準確，人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。確認測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴重錯誤和偏差一般很難在預定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。確認測試的另一個重要環(huán)節(jié)是配置復審。復審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節(jié)。事實上，軟件開發(fā)人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤地理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以是有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤，導致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為

、

測試的過程，以便發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。第1章測試技劃測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶對即將面市的軟件產(chǎn)品（稱為

版本）進行測試，試圖發(fā)現(xiàn)錯誤并修正。

測試的關鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過測試調(diào)整的軟件產(chǎn)品稱為

版本。緊隨其后的測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實際使用

版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對

版本進行改錯和完善。（1）驗收測試過程過程如下：①

軟件需求分析：了解軟件功能和性能要求、軟硬件環(huán)境要求等，并特別要了解軟件的質量要求和驗收要求。②

編制《驗收測試計劃》和《項目驗收準則》：根據(jù)軟件需求和驗收要求編制測試計劃，制定需測試的測試項，制定測試策略及驗收通過準則，并經(jīng)過客戶參與的計劃評審。③

測試設計和測試用例設計：根據(jù)《驗收測試計劃》和《項目驗收準則》編制測試用例，并經(jīng)過評審。④

測試環(huán)境搭建：建立測試的硬件環(huán)境、軟件環(huán)境等（可在委托客戶提供的環(huán)境中進行測試）。⑤

測試實施：測試并記錄測試結果。⑥

測試結果分析：根據(jù)驗收通過準則分析測試結果，做出驗收是否通過及測試評價。⑦

測試報告：根據(jù)測試結果編制缺陷報告和驗收測試報告，并提交給客戶。（2）驗收測試的總體思路用戶驗收測試是軟件開發(fā)結束后，用戶對軟件產(chǎn)品投入實際應用以前進行的最后一次質量檢驗活動。它要回答開發(fā)的軟件產(chǎn)品是否符合預期的各項要求，以及用戶能否接受的問題。由于它不只是檢驗軟件某個方面的質量，而是要進行全面的質量檢驗，并且要決定軟件是否合格，因此驗收測試是一項嚴格的正式測試活動。需要根據(jù)事先制定的計劃，進行軟件配置評審、功能測試、性能測試等多方面檢測。第1章測試技劃用戶驗收測試的每一個相對獨立的部分，都應該有目標（本步驟的目的）、啟動標準（著手本步驟必須滿足的條件）、活動（構成本步驟的具體活動）、完成標準（完成本步驟要滿足的條件）和度量（應該收集的產(chǎn)品與過程數(shù)據(jù)）。在實際驗收測試過程中，收集度量數(shù)據(jù)，不是一件容易的事情。①

軟件配置審核。對于一個外包的軟件項目而言，軟件承包方通常要提供如下相關的軟件配置內(nèi)容：

可執(zhí)行程序、源程序、配置腳本、測試程序或腳本。

主要的開發(fā)類文檔：《需求分析說明書》、《概要設計說明書》、《詳細設計說明書》、《數(shù)據(jù)庫設計說明書》、《測試計劃》、《測試報告》、《程序維護手冊》、《程序員開發(fā)手冊》、《用戶操作手冊》、《項目總結報告》。

主要的管理類文檔：《項目計劃書》、《質量控制計劃》、《配置管理計劃》、《用戶培訓計劃》、《質量總結報告》、《評審報告》、《會議記錄》、《開發(fā)進度月報》。在開發(fā)類文檔中，容易被忽視的文檔有《程序維護手冊》和《程序員開發(fā)手冊》?！冻绦蚓S護手冊》的主要內(nèi)容包括：系統(tǒng)說明（包括程序說明）、操作環(huán)境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發(fā)工作提供有用的技術信息?！冻绦騿T開發(fā)手冊》的主要內(nèi)容包括：系統(tǒng)目標、開發(fā)環(huán)境使用說明、測試環(huán)境使用說明、編碼規(guī)范及相應的流程等，實際上就是程序員的培訓手冊。不同大小的項目，都必須具備上述的文檔內(nèi)容，只是可以根據(jù)實際情況進行重新組織。對上述的提交物，最好在合同中規(guī)定階段提交的時間，以免發(fā)生糾紛。通常，正式的審核過程分為5個步驟：計劃、預備會議（可選）、準備階段、審核會議和問題追蹤。預備會議是對審核內(nèi)容進行介紹并討論。準備階段就是各責任人事先審核并記錄發(fā)現(xiàn)的問題。審核會議是最終確定工作產(chǎn)品中包含的錯誤和缺陷。第1章測試技劃審核要達到的基本目標是：根據(jù)共同制定的審核表，盡可能地發(fā)現(xiàn)被審核內(nèi)容中存在的問題，并最終得到解決。在根據(jù)相應的審核表進行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。在實際的驗收測試執(zhí)行過程中，常常會發(fā)現(xiàn)文檔審核是最難的工作，一方面是由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續(xù)時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。②

可執(zhí)行程序的測試。在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成后，就可以進行驗收測試的最后一個步驟—可執(zhí)行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。要注意的是不能直接使用開發(fā)方提供的可執(zhí)行程序用于測試，而要按照開發(fā)方提供的編譯步驟，從源代碼重新生成可執(zhí)行程序。在真正進行用戶驗收測試之前一般應該已經(jīng)完成了以下工作（也可以根據(jù)實際情況有選擇地采用或增加）：

軟件開發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。

驗收測試計劃已經(jīng)過評審并批準，并且置于文檔控制之下。

對軟件需求說明書的審查已經(jīng)完成。

對概要設計、詳細設計的審查已經(jīng)完成。

對所有關鍵模塊的代碼審查已經(jīng)完成。

對單元、集成、系統(tǒng)測試計劃和報告的審查已經(jīng)完成。

所有的測試腳本已完成，并至少執(zhí)行過一次，且通過評審。

使用配置管理工具且代碼置于配置控制之下。

軟件問題處理流程已經(jīng)就緒。

已經(jīng)制定、評審并批準驗收測試完成標準。第1章測試技劃具體的測試內(nèi)容通常可以包括：安裝（升級）、啟動與關機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復測試（在出現(xiàn)掉電、硬件故障或切換、網(wǎng)絡故障等情況時，系統(tǒng)是否能夠正常運行）、可靠性測試等。性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于開發(fā)方已經(jīng)事先進行過性能測試和壓力測試，因此可以直接使用開發(fā)方的輔助工具。也可以通過購買或自己開發(fā)來獲得輔助工具。具體的測試方法可以參考相關的軟件工程書籍。如果執(zhí)行了所有的測試案例、測試程序或腳本，用戶驗收測試中發(fā)現(xiàn)的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發(fā)生的變化，用戶驗收測試就完成了。盡管測試階段的劃分十分明確，但是在具體的項目和產(chǎn)品的測試中，尤其在執(zhí)行測試時，會根據(jù)實際需要來開展。關于軟件測試階段的理論可以參看朱少民編寫的《全程軟件測試》一書中軟件測試過程和開發(fā)過程的V模型關系。測試的各個階段所用時間比例是不同的，根據(jù)該階段的性質，確定時間長短。當然，具體情況要具體掌握，根據(jù)不同項目不同情況，各測試階段所用時間長短可隨時調(diào)節(jié)。圖1-4直觀地描述出了測試各階段所用的時間對比。第1章測試技劃二、軟件測試的種類對于測試種類的說法很多，最多的能達到幾十種測試種類。但是實際工作中很多測試是互相包含的。按照企業(yè)中實際工作需要，通常主要進行下面幾種類型的測試：功能測試、健壯性測試、接口測試、強度測試、壓力測試、性能測試、用戶界面測試、可靠性測試、安裝/反安裝測試、幫助文檔測試。下面介紹幾種重要的測試種類及其測試的內(nèi)容：第1章測試技劃1．功能測試功能測試主要針對產(chǎn)品需求說明書的測試，是驗證功能是否適合需求，包括原定功能的檢驗、是否有冗余功能、遺漏功能。這類測試應由測試員做，這并不意味著程序員在發(fā)布前不必檢查他們的代碼能否工作，他們也需要進行基本功能的測試。2．接口測試程序員對各個模塊進行系統(tǒng)聯(lián)調(diào)的測試，包含程序內(nèi)接口和程序外接口測試。這個測試，在單元測試階段進行了一部分工作，而大部分都是在集成測試階段完成的。由開發(fā)人員進行。3．性能測試在交替進行負荷和強迫測試時常用的術語。性能測試關注的是系統(tǒng)的整體。它和通常所說的強度、壓力/負載測試有密切關系。所以壓力和強度測試應該與性能測試一同進行。4．用戶界面測試對系統(tǒng)的界面進行測試，測試用戶界面是否友好、是否方便易用、設計是否合理、位置是否正確等一系列界面問題。5．安裝/反安裝測試安裝測試主要檢驗軟件是否可以正確安裝，安裝文件的各項設置是否有效，安裝后能否影響原系統(tǒng)；反安裝是逆過程，測試是否刪除干凈，是否影響原系統(tǒng)等。6．文檔測試主要測試開發(fā)過程中針對用戶的文檔，以需求、用戶手冊、安裝手冊等為主，檢驗文檔是否和實際應用存在差別。文檔測試不需要編寫測試用例。測試種類的劃分不要拘泥于上面的形式，總體來說應該服從于測試策略，可以根據(jù)具體工作的特點進行安排，為了工作更容易開展，完全可以把一些測試合并在一起進行。在后面的性能測試用例的編寫上，充分體現(xiàn)了這一思想。第1章測試技劃表1-1測試的種類、階段和執(zhí)行人員的關系測

試

階

段測

試

類

型執(zhí)

行

者單元測試模塊功能測試，包含部分接口測試、路徑測試開發(fā)工程師集成測試接口測試、路徑測試，含部分功能測試開發(fā)工程師（如果測試人員水平較高，可以由測試人員執(zhí)行）測

試

階

段測

試

類

型執(zhí)

行

者系統(tǒng)測試功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試測試工程師驗收測試對于實際項目來說基本同上，并包含文檔測試；對于軟件產(chǎn)品，主要測試相關的技術文檔測試工程師（根據(jù)實際需要，可能包含用戶）總之，測試的種類應該盡量少，這樣每次都可以執(zhí)行更多的測試內(nèi)容。例如在進行功能測試的同時，完全可以進行健壯性的測試（當然如果產(chǎn)品健壯性方面要求較高，就可以把健壯性測試作為獨立的測試）。也就是說測試各個階段中對執(zhí)行不同的測試種類采用不同的測試技術。關于測試技術下面進行講解。Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.1.1.3關于測試計劃第1章測試技劃軟件測試計劃是指導測試過程的綱領性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風險分析等內(nèi)容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體

戰(zhàn)術。所以其中最重要的是測試策略和測試方法（最好是能先評審）。做好測試計劃工作的關鍵是什么？1．明確測試的目標，增強測試計劃的實用性編寫軟件測試計劃的重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具具有較高的實用性，便于使用，生成的測試結果直觀、準確。2．堅持“5W”規(guī)則，明確內(nèi)容與過程3．采用評審和更新機制，保證測試計劃滿足實際需求測試計劃設計完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃可能內(nèi)容不準確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導測試執(zhí)行人員。4．分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例應把詳細的測試技術指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔中，把用于指導測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。第1章測試技劃一、關于測試計劃俗話說：凡事預則立，不預則廢！軟件測試同樣，在測試項目之初就要制訂相應的測試計劃。接下來了解一下如何編寫測試計劃。1．為什么要編寫測試計劃（1）領導能夠根據(jù)測試計劃做宏觀調(diào)控，進行相應資源配置等；（2）測試人員能夠了解整個項目測試情況以及項目測試不同階段所要進行的工作等；（3）便于其他人員了解測試人員的工作內(nèi)容，進行有關配合工作。2．什么時間開始編寫測試計劃軟件測試計劃在項目啟動初期就應該規(guī)劃。3．由誰來編寫測試計劃軟件測試計劃一般由具有豐富經(jīng)驗的項目測試負責人來編寫。4．測試計劃編寫6要素（5W1H）（1）Why—為什么要進行這些測試；（2）What—測試哪些方面，不同階段的工作內(nèi)容；（3）When—測試不同階段的起止時間；（4）Where—相應文檔，缺陷的存放位置，測試環(huán)境等；（5）Who—項目有關人員組成，安排哪些測試人員進行測試；（6）How—如何去做，使用哪些測試工具以及測試方法進行測試。二、測試計劃模板因為各個公司的測試計劃模板是不同的，這是一個比較完整的測試計劃模板，寫得很詳細（見表1-2、表1-3），學生可以參考模板完成天天超市管理系統(tǒng)測試計劃的撰寫。第1章測試技劃項目名稱（項目編號）測試計劃（部門名稱）×××軟件公司表1-2測試計劃說明表總頁數(shù)

正文

附錄

生效日期：

年

月

日編制：審核：批準：表1-3修訂歷史記錄日

期版

本說

明作

者<日/月/年><x.x><詳細信息><姓名>

第1章測試技劃目

錄一、簡介二、測試需求三、測試風險四、測試策略

五、工具

六、資源七、測試進度和里程碑八、可交付工件

一、簡介1．目的<項目名稱>的“測試計劃”文檔的目的是：（1）提供一個對項目軟件進行測試的總體安排和進度計劃，確定現(xiàn)有項目的信息和應測試軟件構件。（2）標明推薦的測試需求（高層次）。（3）推薦可采用的測試策略，并對這些策略加以說明。（4）確定所需的資源，并對測試的工作量進行估計。（5）列出測試項目的可交付元素。2．背景輸入測試對象（組件、應用程序、系統(tǒng)等）及其目標的簡要說明。需要包括的信息有：主要的功能和特性、測試對象的構架以及項目的簡史。本部分應該只包含3～5個段落。刪除第1章測試技劃3．范圍描述測試的各個階段，例如，單元測試、集成測試或系統(tǒng)測試，并說明本計劃所針對的測試類型（如功能測試或性能測試）。簡要地列出測試對象中將接受測試或將不接受測試的那些特性和功能。如果在編寫此文檔的過程中做出的某些假設可能會影響測試設計、開發(fā)或實施，則列出所有這些假設。列出可能會影響測試設計、開發(fā)或實施的所有風險或意外事件。列出可能會影響測試設計、開發(fā)或實施的所有約束。4．使用文檔表1-4列出了制訂測試計劃所用的文檔，并標明了文檔的可用性。注：可以視情況刪除或添加項目。表1-4測試計劃使用文檔列表文檔（版本/日期）已創(chuàng)建或可用已被接受或已經(jīng)過復審作者或來源備

注需求規(guī)約

是

否

是

否

功能性規(guī)約

是

否

是

否

用例報告

是

否

是

否

項目計劃

是

否

是

否

設計規(guī)約

是

否

是

否

原型

是

否

是

否

用戶手冊

是

否

是

否

業(yè)務模型或業(yè)務流程

是

否

是

否

數(shù)據(jù)模型或數(shù)據(jù)流

是

否

是

否

業(yè)務功能和業(yè)務規(guī)則

是

否

是

否

項目或業(yè)務風險評估

是

否

是

否

第1章測試技劃（8）容量測試；（9）安全性和訪問控制測試；（10）故障轉移/恢復測試；（11）配置測試；（12）安裝測試。三、測試風險軟件測試風險是不可避免的、總是存在的，所以對測試風險的管理非常重要，必須盡力降低測試中所存在的風險，最大程度地保證質量和滿足客戶的需求。在測試工作中，主要的風險有：（1）質量需求或產(chǎn)品的特性理解不準確，造成測試范圍分析的誤差，結果某些地方始終測試不到或驗證的標準不對。（2）測試用例沒有得到百分之百的執(zhí)行，如有些測試用例被有意或無意的遺漏。（3）需求的臨時或突然變化，導致設計的修改和代碼的重寫，測試時間不夠。（4）質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智。（5）測試用例設計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等。（6）測試環(huán)境，一般不可能和實際運行環(huán)境完全一致，造成測試結果的誤差。（7）有些缺陷出現(xiàn)頻率不是百分之百，不容易被發(fā)現(xiàn)；如果代碼質量差，軟件缺陷很多，被漏檢的缺陷可能性就大。（8）回歸測試一般不運行全部測試用例，是有選擇性的執(zhí)行，必然帶來風險。前面三種風險是可以避免的，而4～7的四種風險是不能避免的，可以降到最低。最后一種回歸測試風險是可以避免，但出于時間或成本的考慮，一般也是存在的。針對上述軟件測試的風險，有一些有效的測試風險控制方法，如：測試環(huán)境不對可以通過事先列出要檢查的所有條目，在測試環(huán)境設置好后，由其他人員按已列出條目逐條檢查。第1章測試技劃有些測試風險可能帶來的后果非常嚴重，能否將它轉化為其他一些不會引起嚴重后果的低風險。如產(chǎn)品發(fā)布前夕，在某個不是很重要的新功能上發(fā)現(xiàn)一個嚴重的缺陷，如果修正這個缺陷，很有可能引起某個原有功能上的缺陷。這時處理這個缺陷所帶來的風險就很大，對策是去掉那個新功能，轉移這種風險。有些風險不可避免，就設法降低風險，如“程序中未發(fā)現(xiàn)的缺陷”這種風險總是存在，我們就要通過提高測試用例的覆蓋率（如達到99.9%）來降低這種風險。為了避免、轉移或降低風險，事先要做好風險管理計劃和控制風險的策略，并對風險的處理還要制訂一些應急的、有效的處理方案。四、測試策略測試策略提供了推薦用于測試對象的方法。第二部分“測試需求”中說明了將要測試哪些對象，而本部分則要說明如何對測試對象進行測試。對于每種測試，都應提供測試說明，并解釋其實施和執(zhí)行的原因。如果不實施和執(zhí)行某種測試，則應該用一句話加以說明，并陳述這樣做的理由。制定測試策略時所考慮的主要事項有：將要使用的方法以及判斷測試何時完成的標準。下面列出了在進行每項測試時需考慮的事項，除此之外，測試還只應在安全的環(huán)境中使用已知的、受控的數(shù)據(jù)庫來執(zhí)行。測試類型有如下幾種：（1）數(shù)據(jù)和數(shù)據(jù)庫完整性測試數(shù)據(jù)庫和數(shù)據(jù)庫進程應作為<項目名稱>中的子系統(tǒng)來進行測試。在測試這些子系統(tǒng)時，不應將測試對象的用戶界面用做數(shù)據(jù)的接口。對于數(shù)據(jù)庫管理系統(tǒng)（DBMS），還需要進行深入的研究，以確定可以支持以下測試的工具和方法。數(shù)據(jù)庫測試如表1-5所示。第1章測試技劃表1-5數(shù)據(jù)庫測試說明表測試目標確保數(shù)據(jù)庫訪問方法和進程正常運行，數(shù)據(jù)不會遭到損壞。方

法調(diào)用各個數(shù)據(jù)庫訪問方法和進程，并在其中填充有效的或無效

的數(shù)據(jù)或對數(shù)據(jù)的請求。檢查數(shù)據(jù)庫，確保數(shù)據(jù)已按預期的方式填充，并且所有

數(shù)據(jù)庫事件都按正常方式出現(xiàn)；或者檢查所返回的數(shù)據(jù)，確保為正當?shù)睦碛蓹z索到了正確的數(shù)據(jù)。完成標準所有的數(shù)據(jù)庫訪問方法和進程都按照設計的方式運行，數(shù)據(jù)沒有遭到損壞。需考慮的特殊事項測試可能需要DBMS開發(fā)環(huán)境或驅動程序以便在數(shù)據(jù)庫中直接輸入或修改數(shù)據(jù)。進程應該以手工方式調(diào)用。應使用小型或最小的數(shù)據(jù)庫（其中的記錄數(shù)很有限）來使所有無法接受的事件具有更大的可見性。（2）功能測試測試對象的功能測試應該側重于可以被直接追蹤到用例或業(yè)務功能和業(yè)務規(guī)則的所有測試需求。這些測試的目標在于核實能否正確地接受、處理和檢索數(shù)據(jù)以及業(yè)務規(guī)則是否正確實施。這種類型的測試基于黑盒方法，即通過圖形用戶界面（GUI）與應用程序交互并分析輸出結果來驗證應用程序及其內(nèi)部進程。表1-6列出的是每個應用程序推薦的測試方法概要。第1章測試技劃表1-6功能測試說明表測試目標確保測試對象的功能正常，其中包括導航、數(shù)據(jù)輸入、處理和檢索等。方

法利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例、用例流或功能，以核實以下內(nèi)容：在使用有效數(shù)據(jù)時得到預期的結果。在使用無效數(shù)據(jù)時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。完成標準所計劃的測試已全部執(zhí)行。所發(fā)現(xiàn)的缺陷已全部解決。需考慮的特殊事項確定或說明那些將對功能測試的實施和執(zhí)行造成影響的事項或因素（內(nèi)部的或外部的）。（3）業(yè)務周期測試業(yè)務周期測試應模擬在一段時間內(nèi)對<項目名稱>執(zhí)行的活動。應先確定一段時間（例如一年），然后執(zhí)行將在該時段內(nèi)發(fā)生的事務和活動。這種測試包括所有的每日、每周和每月的周期，以及所有與日期相關的事件（如備忘錄）。業(yè)務周期測試如表1-7所示。第1章測試技劃表1-7業(yè)務周期測試說明表測試目標確保測試對象及后臺進程都按照所要求的業(yè)務模型和時間表正確運行。方

法通過執(zhí)行以下活動，測試將模擬若干個業(yè)務周期：將修改或增強對測試對象進行的功能測試，以增加每項功能的執(zhí)行次數(shù)，從而在指定的時段內(nèi)模擬若干個不同的用戶。將使用有效的和無效的日期或時段來執(zhí)行所有與時間或日期相關的功能。將在適當?shù)臅r候執(zhí)行或啟動所有周期性出現(xiàn)的功能。在測試中還將使用有效的和無效的數(shù)據(jù)，以核實以下內(nèi)容：在使用有效數(shù)據(jù)時得到預期的結果。在使用無效數(shù)據(jù)時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。完成標準所計劃的測試已全部執(zhí)行。所發(fā)現(xiàn)的缺陷已全部解決。需考慮的特殊事項系統(tǒng)日期和事件可能需要特殊的支持活動。需要通過業(yè)務模型來確定相應的測試需求和測試過程。（4）用戶界面測試通過用戶界面（UI）測試來核實用戶與軟件的交互。UI測試的目標在于確保用戶界面向用戶提供了適當?shù)脑L問和瀏覽測試對象功能的操作。除此之外，UI測試還要確保UI功能內(nèi)部的對象符合預期要求，并遵循公司或行業(yè)的標準。用戶界面測試如表1-8所示。第1章測試技劃表1-8用戶界面測試說明表測試目標核實以下內(nèi)容：通過瀏覽測試對象可正確反映業(yè)務的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法（Tab鍵、鼠標移動和快捷鍵）的使用。窗口的對象和特征（例如：菜單、大小、位置、狀態(tài)和中心）都符合標準。方

法為每個窗口創(chuàng)建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，并處于正常的對象狀態(tài)。完成標準證實各個窗口都與基準版本保持一致，或符合可接受標準。需考慮的特殊事項并不是所有定制或第三方對象的特征都可訪問。（5）性能評價性能評價是一種性能測試，它對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估。性能評價的目標是核實性能需求是否都已滿足。實施和執(zhí)行性能評價的目的是將測試對象的性能為當做條件（如工作量或硬件配置）的一種函數(shù)來進行評價和微調(diào)。性能測試如表1-9所示。表1-9性能測試說明表測試目標核實所指定的事務或業(yè)務功能在以下情況下的性能行為：正常的預期工作量。預期的最繁重工作量。第1章測試技劃方

法使用為功能或業(yè)務周期測試制定的測試過程。通過修改數(shù)據(jù)文件來增加事務數(shù)量，或通過修改腳本來增加每項事務的迭代次數(shù)。腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務為基準），并在多臺客戶機（虛擬的或實際的客戶機，請參見下面的“需考慮的特殊事項”）上重復。完成標準單個事務或單個用戶：在每個事務所預期或要求的時間范圍內(nèi)成功地完成測試腳本，沒有發(fā)生任何故障。多個事務或多個用戶：在可接受的時間范圍內(nèi)成功地完成測試腳本，沒有發(fā)生任何故障。需考慮的特殊事項綜合的性能測試還包括在服務器上添加后臺工作量?？刹捎枚喾N方法來執(zhí)行此操作，其中包括：直接將“事務強行分配到”服務器上，這通常以“結構化查詢語言”（SQL）調(diào)用的形式來實現(xiàn)。通過創(chuàng)建“虛擬的”用戶負載來模擬許多個（通常為數(shù)百個）客戶機。此負載可通過“遠程終端仿真”（RemoteTerminalEmulation）工具來實現(xiàn)。此技術還可用于在網(wǎng)絡中加載“流量”。使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統(tǒng)上添加負載。性能測試應該在專用的計算機上或在專用的機時內(nèi)執(zhí)行，以便實現(xiàn)完全的控制和精確的評測。性能測試所用的數(shù)據(jù)庫應該是與實際大小相同或等比例縮放的數(shù)據(jù)庫。測試目標核實所指定的事務或業(yè)務功能在以下情況下的性能行為：正常的預期工作量。預期的最繁重工作量。第1章測試技劃

注：以下事務均指“邏輯業(yè)務事務”。這種事務被定義為將由系統(tǒng)的某個主角通過使用測試對象來執(zhí)行的特定用例，例如，添加或修改某個合同。（6）負載測試負載測試是一種性能測試。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運行的能力。負載測試的目標是確定并確保系統(tǒng)在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。負載測試如表1-10所示。注：以下事務均指“邏輯業(yè)務事務”。這些事務被定義為將由系統(tǒng)的最終用戶通過使用應用程序來執(zhí)行的具體功能，例如，添加或修改某個合同。表1-10負載測試說明表測試目標核實所指定的事務或商業(yè)理由在不同的工作量條件下的性能行為時間。方

法使用為功能或業(yè)務周期測試制定的測試。通過修改數(shù)據(jù)文件來增加事務數(shù)量，或通過修改測試來增加每項事務發(fā)生的次數(shù)。完成標準多個事務或多個用戶：在可接受的時間范圍內(nèi)成功地完成測試，沒有發(fā)生任何故障。需考慮的特殊事項負載測試應該在專用的計算機上或在專用的機時內(nèi)執(zhí)行，以便實現(xiàn)完全的控制和精確的評測。負載測試所用的數(shù)據(jù)庫應該是與實際大小相同或等比例縮放的數(shù)據(jù)庫。第1章測試技劃（7）強度測試強度測試是一種性能測試，實施和執(zhí)行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內(nèi)存或磁盤空間不足，測試對象就可能會表現(xiàn)出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能是由于爭用共享資源（如數(shù)據(jù)庫鎖或網(wǎng)絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。強度測試如表1-11所示。注：以下提到的事務都是指邏輯業(yè)務事務。表1-11強度測試說明表測試目標核實測試對象能夠在以下強度條件下正常運行，不會出現(xiàn)任何錯誤：服務器上幾乎沒有或根本沒有可用的內(nèi)存（RAM和DASD）。連接或模擬了最大實際（或實際可承受）數(shù)量的客戶機。多個用戶對相同的數(shù)據(jù)/賬戶執(zhí)行相同的事務。最繁重的事務量或最差的事務組合（請參見上面的“性能測試”）注：強度測試的目標還可表述為確定和記錄那些使系統(tǒng)無法繼續(xù)正常運行的情況或條件。方

法使用為性能評價或負載測試制定的測試。要對有限的資源進行測試，就應該在一臺計算機上運行測試，而且應該減少或限制服務器上的RAM和DASD。對于其他強度測試，應該使用多臺客戶機來運行相同的測試或互補的測試，以產(chǎn)生最繁重的事務量或最差的事務組合。完成標準所計劃的測試已全部執(zhí)行，并且在達到或超出指定的系統(tǒng)限制時沒有出現(xiàn)任何軟件故障，或者導致系統(tǒng)出現(xiàn)故障的條件并不在指定的條件范圍之內(nèi)。需考慮的特殊事項如果要增加網(wǎng)絡工作強度，可能會需要使用網(wǎng)絡工具來給網(wǎng)絡加載消息或信息包。應該暫時減少用于系統(tǒng)的DASD，以限制數(shù)據(jù)庫可用空間的增長。使多個客戶機對相同的記錄或數(shù)據(jù)賬戶同時進行的訪問達到同步。第1章測試技劃（8）容量測試容量測試使測試對象處理大量的數(shù)據(jù)，以確定是否達到了將使軟件發(fā)生故障的極限。容量測試還將確定測試對象在給定時間內(nèi)是否能夠持續(xù)處理的最大負載或工作量。例如，如果測試對象正在為生成一份報表而處理一組數(shù)據(jù)庫記錄，那么容量測試就會使用一個大型的測試數(shù)據(jù)庫，檢驗該軟件是否正常運行并生成了正確的報表。容量測試如表1-12所示。表1-12容量測試說明表測試目標核實測試對象在以下大容量條件下能否正常運行：連接（或模擬了）最大（實際或實際可承受）數(shù)量的客戶機，所有客戶機在長時間內(nèi)執(zhí)行相同的、且情況（性能）最差的業(yè)務功能。已達到最大的數(shù)據(jù)庫大?。▽嶋H的或按比例縮放的），而且同時執(zhí)行了多個查詢或報表事務。方

法使用為性能評價或負載測試制定的測試。應該使用多臺客戶機來運行相同的測試或互補的測試，以便在長時間內(nèi)產(chǎn)生最繁重的事務量或最差的事務組合（請參見上面的“強度測試”）。創(chuàng)建最大的數(shù)據(jù)庫大?。▽嶋H的、按比例縮放的、或輸入了代表性數(shù)據(jù)的數(shù)據(jù)庫），并使用多臺客戶機在長時間內(nèi)同時運行查詢和報表事務。完成標準所計劃的測試已全部執(zhí)行，而且在達到或超出指定的系統(tǒng)限制時沒有出現(xiàn)任何軟件故障。需考慮的特殊事項對于上述的大容量條件，哪個時段是可以接受的時間？第1章測試技劃（9）安全性和訪問控制測試安全性和訪問控制測試側重于安全性的兩個關鍵方面（如表1-13所示）：①

應用程序級別的安全性，包括對數(shù)據(jù)或業(yè)務功能的訪問。②

系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或遠程訪問。應用程序級別的安全性可確保：在預期的安全性情況下，主角只能訪問特定的功能或用例，或者只能訪問有限的數(shù)據(jù)。例如，可能會允許所有人輸入數(shù)據(jù)，創(chuàng)建新賬戶，但只有經(jīng)理才能刪除這些數(shù)據(jù)或賬戶。如果具有數(shù)據(jù)級別的安全性，測試就可確?！坝脩纛愋鸵弧蹦軌蚩吹剿锌蛻粜畔?，（包括財務數(shù)據(jù)），而“用戶類型二”只能看見同一客戶的統(tǒng)計數(shù)據(jù)。系統(tǒng)級別的安全性可確保只有具備系統(tǒng)訪問權限的用戶才能訪問應用程序，而且只能通過相應的網(wǎng)關來訪問。表1-13安全性和訪問控制測試說明表測試目標應用程序級別的安全性：核實主角只能訪問其所屬用戶類型已被授權使用的那些功能或數(shù)據(jù)。系統(tǒng)級別的安全性：核實只有具備系統(tǒng)和應用程序訪問權限的主角才能訪問系統(tǒng)和應用程序。方

法應用程序級別的安全性：確定并列出各用戶類型及其被授權使用的功能或數(shù)據(jù)。為各用戶類型創(chuàng)建測試，并通過創(chuàng)建各用戶類型所特有的事務來核實其權限。修改用戶類型并為相同的用戶重新運行測試。對于每種用戶類型，確保正確地提供或拒絕了這些附加的功能或數(shù)據(jù)。系統(tǒng)級別的訪問：請參見下面的“需考慮的特殊事項”。完成標準各種已知的主角類型都可訪問相應的功能或數(shù)據(jù)，而且所有事務都按照預期的方式運行，并在先前的應用程序功能測試中運行了所有的事務。需考慮的特殊事項必須與相應的網(wǎng)絡或系統(tǒng)管理員一起對系統(tǒng)訪問權進行檢查和討論。由于此測試可能是網(wǎng)絡管理或系統(tǒng)管理的職能，可能不需要執(zhí)行此測試。第1章測試技劃（10）故障轉移和恢復測試故障轉移和恢復測試可確保測試對象能成功完成故障轉移，并從硬件、軟件或網(wǎng)絡等方面的各種故障中進行恢復，這些故障導致數(shù)據(jù)意外丟失或破壞了數(shù)據(jù)的完整性。故障轉移測試可確保：對于必須始終保持運行狀態(tài)的系統(tǒng)來說，如果發(fā)生了故障，那么備選或備份的系統(tǒng)就適當?shù)貙l(fā)生故障的系統(tǒng)“接管”過來，而且不會丟失任何數(shù)據(jù)或事務。恢復測試是一種相反的測試流程。其中，將應用程序或系統(tǒng)置于極端的條件下（或者是模仿的極端條件下），以產(chǎn)生故障，例如設備輸入/輸出（I/O）故障或無效的數(shù)據(jù)庫指針和關鍵字。啟用恢復流程后，將監(jiān)測和檢查應用程序和系統(tǒng)，以核實應用程序或系統(tǒng)是正確無誤的，或數(shù)據(jù)已得到了恢復，如表1-14所示。表1-14故障轉移和恢復測試說明表測試目標確保恢復進程（手工或自動）將數(shù)據(jù)庫、應用程序和系統(tǒng)正確地恢復到了預期的已知狀態(tài)。測試中將包括以下各種情況：客戶機斷電。服務器斷電。通過網(wǎng)絡服務器產(chǎn)生的通信中斷。DASD和/或DASD控制器被中斷、斷電或與DASD和/或DASD控制器的通信中斷。周期未完成（數(shù)據(jù)過濾進程被中斷，數(shù)據(jù)同步進程被中

斷）。數(shù)據(jù)庫指針或關鍵字無效。數(shù)據(jù)庫中的數(shù)據(jù)元素無效或遭到破壞。第1章測試技劃方

法應該使用為功能和業(yè)務周期測試創(chuàng)建的測試來創(chuàng)建一系列的事務。一旦達到預期的測試起點，就應該分別執(zhí)行或模擬以下操作：客戶機斷電：關閉PC的電源。服務器斷電：模擬或啟動服務器的斷電過程。通過網(wǎng)絡服務器產(chǎn)