軟件測試項(xiàng)目實(shí)戰(zhàn)（第四版）課件 第一章：測試計(jì)劃

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

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

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

二）

好奇、懷疑、探究、求真

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

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

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

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

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

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

1．首先提高自己的測試?yán)碚摶A(chǔ)。所有的測試基礎(chǔ)概念其實(shí)都是通用的：靜態(tài)測試，動(dòng)態(tài)測試，

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

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

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

4．責(zé)任擔(dān)當(dāng)感

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

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

以主控模塊作為測試驅(qū)動(dòng)模塊，把對主控模塊進(jìn)行單元測試時(shí)引入的所有樁模塊用實(shí)際模塊替代；

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

每集成一個(gè)模塊立即測試一遍；

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

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

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

開發(fā)一個(gè)測試驅(qū)動(dòng)模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出；

對每個(gè)模塊群進(jìn)行測試；

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

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

開發(fā)一個(gè)測試驅(qū)動(dòng)模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出；

對每個(gè)模塊群進(jìn)行測試；

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

對應(yīng)幾條需求；

具有高層控制功能；

復(fù)雜、易出錯(cuò)；

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

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

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

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

想方設(shè)法截取或破譯口令；②

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

故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；④

試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時(shí)間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是，使非法侵入的代價(jià)超過被保護(hù)信息的價(jià)值。此時(shí)非法侵入者已無利可圖。（3）強(qiáng)度測試強(qiáng)度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強(qiáng)度測試總是迫使系統(tǒng)在異常的資源配置下運(yùn)行。例如，①

當(dāng)中斷的正常頻率為每秒一至兩個(gè)時(shí)，運(yùn)行每秒產(chǎn)生十個(gè)中斷的測試用例；②

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

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

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

、

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

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

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

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

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

版本進(jìn)行改錯(cuò)和完善。（1）驗(yàn)收測試過程過程如下：①

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

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

測試設(shè)計(jì)和測試用例設(shè)計(jì)：根據(jù)《驗(yàn)收測試計(jì)劃》和《項(xiàng)目驗(yàn)收準(zhǔn)則》編制測試用例，并經(jīng)過評審。④

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

測試實(shí)施：測試并記錄測試結(jié)果。⑥

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

試

階

段測

試

類

型執(zhí)

行

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

試

階

段測

試

類

型執(zhí)

行

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

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

正文

附錄

生效日期：

年

月

日編制：審核：批準(zhǔn)：表1-3修訂歷史記錄日

期版

本說

明作

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

第1章測試技劃目

錄一、簡介二、測試需求三、測試風(fēng)險(xiǎn)四、測試策略

五、工具

六、資源七、測試進(jìn)度和里程碑八、可交付工件

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

注需求規(guī)約

是

否

是

否

功能性規(guī)約

是

否

是

否

用例報(bào)告

是

否

是

否

項(xiàng)目計(jì)劃

是

否

是

否

設(shè)計(jì)規(guī)約

是

否

是

否

原型

是

否

是

否

用戶手冊

是

否

是

否

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

是

否

是

否

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

是

否

是

否

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

是

否

是

否

項(xiàng)目或業(yè)務(wù)風(fēng)險(xiǎn)評估

是

否

是

否

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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