功能測試培訓(xùn)手冊

1、功能測試培訓(xùn)手冊第 一 章 測 試 概 述1. 測試發(fā)展測試是一個(gè)級其寬廣的概念， 并且涉及到我們生活的各個(gè)方面。 作為用戶， 他們希望所 使用的產(chǎn)品是可靠的、使用簡單方便及符合需要的。那么，怎樣才算是可靠的、符合需要的 呢？最簡單的方法是通過建立一些異常的環(huán)境及一些異常的操作， 看產(chǎn)品在這些異常的環(huán)境 及這些異常的操作下是否能正常工作。 這就是測試。 可以說， 測試是隨著社會化生產(chǎn)應(yīng)運(yùn)而 生的， 不是近代才出現(xiàn)的產(chǎn)物。 但是，我們這里強(qiáng)調(diào)的是對軟件產(chǎn)品的測試。軟件測試是軟 件工程的一個(gè)范疇， 或是說是軟件工程的一個(gè)部分。 這主要是因?yàn)闇y試活動(dòng)是一個(gè)工程性的 活動(dòng)而不是簡單、孤立的活動(dòng)。軟件測

2、試最早可以追溯到軟件開發(fā)的初期。 著計(jì)算機(jī)的誕生， 開始了軟件開發(fā)和軟件測 試。于早期的計(jì)算機(jī)運(yùn)行性能比較差， 軟件的可編程性范圍比較狹窄， 誤主要集中在元器件 的不穩(wěn)定上。 這一階段還沒有系統(tǒng)意義上的軟件測試， 更多的是一種調(diào)試性測試用。 測試用 例的設(shè)計(jì)和選取是在隨機(jī)的基礎(chǔ)上， 憑借測試人員一定的經(jīng)驗(yàn)進(jìn)行的。 測試更多的是為了證 明系統(tǒng)可以運(yùn)行起來。20 世紀(jì) 50 年代后期到 20世紀(jì) 60年代，高級語言相繼誕生并得到了廣泛的應(yīng)用，測試 的重點(diǎn)逐漸轉(zhuǎn)入到高級語言編寫的系統(tǒng)中來。與以往不同的是程序的復(fù)雜性增強(qiáng)了。但是， 由于受到硬件系統(tǒng)制約， 軟件相對而言僅占系統(tǒng)的次要位置。 軟件正確性的

3、把握主要依賴編 程人員的水平。因此，測試?yán)碚摵头椒ㄔ谶@一階段的發(fā)展比較緩慢。20 世紀(jì) 70 年代以后，隨著計(jì)算機(jī)處理速度的飛速提高，內(nèi)存和外存（主要是硬盤）容 量的快速增加， 軟件在整個(gè)系統(tǒng)中的重要性變得越來越高， 軟件的規(guī)模越來越大， 可視化編 程環(huán)境、 日益完善的軟件分析設(shè)計(jì)方法 （如面向?qū)ο蟮姆治鲈O(shè)計(jì)概念的產(chǎn)生） 以及新的軟件 開發(fā)過程模型的提出（如螺旋模型，增量模型等）使得大型軟件的開發(fā)成為可能；同時(shí)，由 于軟件規(guī)模和復(fù)雜度的急劇增加， 軟件的可靠性面臨危機(jī)； 軟件測試在這一階段承受了挑戰(zhàn)。 許多測試?yán)碚摵蜏y試方法相繼誕生， 逐漸形成一套體系。 同時(shí)，這一階段也孕育、 培養(yǎng)出了 一批

4、出色的測試專家。隨著軟件產(chǎn)業(yè)化的發(fā)展， 人們對軟件的質(zhì)量、 成本和進(jìn)度提出了較高的要求。 質(zhì)量的控 制已經(jīng)不再是傳統(tǒng)意義上的軟件測試。 傳統(tǒng)的軟件測試是基于代碼運(yùn)行的， 只有在軟件開發(fā) 的后期才能介入。 然而， 產(chǎn)業(yè)界的大量研究表明， 設(shè)計(jì)活動(dòng)引入的錯(cuò)誤占軟件過程中出現(xiàn)所 有錯(cuò)誤數(shù)量的5065%。根據(jù)IBM的研究結(jié)果，假定在分析階段發(fā)現(xiàn)的錯(cuò)誤其改正成本為 1個(gè)貨幣單位，那么在測試之前（設(shè)計(jì)編碼階段）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為6.5個(gè)貨幣單位，在測試時(shí)（集成測試，系統(tǒng)測試和驗(yàn)收測試）發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為15個(gè)貨幣單位， 而在發(fā)布之后 （已經(jīng)交到用戶手上） 發(fā)現(xiàn)一個(gè)錯(cuò)誤的修改成本約為 60

5、100 個(gè)貨幣 單位。該比例同樣也適用于發(fā)現(xiàn)一個(gè)錯(cuò)誤需要的時(shí)間代價(jià)。IBM 的研究結(jié)果還表明：缺陷存在放大趨勢。如果在需求階段漏過一個(gè)錯(cuò)誤，該錯(cuò)誤 可能會引起 N 個(gè)設(shè)計(jì)錯(cuò)誤。 N 稱為放大系數(shù)。一般而言，不同階段其 N 不同。經(jīng)驗(yàn)表明， 從概要設(shè)計(jì)到詳細(xì)設(shè)計(jì)的錯(cuò)誤放大系數(shù)大約為1.5，從詳細(xì)設(shè)計(jì)到編碼階段的錯(cuò)誤放大系數(shù)大約為 3。圖 1-1 表示了缺陷放大模型大致狀況。圖1-1缺陷放大模型圖因?yàn)橛猩厦孢@些內(nèi)在因素的制約，就不難想象為什么很多軟件產(chǎn)品在其開發(fā)過程中投入了大量的時(shí)間和金錢在沒完沒了的系統(tǒng)測試上，而最后得到的產(chǎn)品卻依舊是低質(zhì)量的軟件。 在經(jīng)過了大量的失敗實(shí)踐之后，人們逐漸發(fā)現(xiàn)，一個(gè)

6、軟件的成功不可能僅僅依賴于軟件開發(fā)技術(shù)是否選進(jìn)。相反，軟件產(chǎn)業(yè)化要求有一個(gè)規(guī)范的軟件開發(fā)過程，一個(gè)全局的質(zhì)量控制體系。一個(gè)好的軟件開發(fā)過程為軟件的開發(fā)指明了一條通向成功的捷徑。在此要求下，許多優(yōu)秀的軟件開發(fā)過程，開發(fā)規(guī)范應(yīng)運(yùn)而生，如CMM、IPD、RUP、CMMI等。在這些過程中，測試已經(jīng)不再是一個(gè)編碼后才進(jìn)行的活動(dòng)，而是一個(gè)基于軟件開發(fā)整個(gè)生命周期的質(zhì)量控制活動(dòng)。測試的概念也擴(kuò)展到了靜態(tài)測試（靜態(tài)測試：不實(shí)際運(yùn)行軟件，主要是對軟件的編程格式、結(jié)構(gòu)等方面進(jìn)行評估。靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它 可以由人工進(jìn)行，充分發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具自動(dòng)進(jìn)行。）范疇

7、。軟件測試的V模型說明了何時(shí)應(yīng)進(jìn)行測試。但是，該模型僅涉及到單元測試、集成測 試、系統(tǒng)測試和驗(yàn)收測試的過程，以及這些測試與前期階段的對應(yīng)關(guān)系。其實(shí)，在開發(fā)過程 中，測試始終在扮演著驗(yàn)證和確認(rèn)的角色。如在功能性需求分析階段，除了要考慮系統(tǒng)測試范圍的內(nèi)容外，還必須包括功能需求本身的測試。從需求考慮系統(tǒng)測試范圍，主要是考慮系統(tǒng)測試應(yīng)當(dāng)按照功能需求的內(nèi)容測試系統(tǒng)是否符合需求；而需求本身的測試則是測試需求的完整性、一致性、無沖突性等。軟件測試V模型如圖1-2所示。需求分析驗(yàn)證和確認(rèn)概要設(shè)計(jì)予驗(yàn)證和確認(rèn)詳細(xì)設(shè)計(jì)編碼執(zhí)行集成測試曲驗(yàn)證和確認(rèn)皆執(zhí)行單元測試代碼審查驗(yàn)證和確認(rèn)集成測試計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)單元測試計(jì)劃

8、、設(shè)計(jì)、實(shí)現(xiàn)系統(tǒng)測試計(jì)劃、1執(zhí)行系統(tǒng)測試設(shè)計(jì)、實(shí)現(xiàn)圖1-2測試V模型2. 什么是軟件測試簡單地說，如果你寫了一段代碼，我來幫你查看代碼并找出里面的錯(cuò)誤，這就是測試。也可以這么說：軟件測試目的在于發(fā)現(xiàn)錯(cuò)誤；一個(gè)好的測試用例在于發(fā)現(xiàn)從前未發(fā)現(xiàn)的錯(cuò)誤； 一個(gè)成功的測試是發(fā)現(xiàn)了從前未發(fā)現(xiàn)的錯(cuò)誤的測試。軟件測試在一定程度上是直觀的，但總體上是系統(tǒng)的。好的測試涉及的內(nèi)容遠(yuǎn)不只是將程序運(yùn)行幾次看它是否正常工作。對程序的徹底分析有利于你更系統(tǒng)、更有效地進(jìn)行測試。2.1. IEEE的定義1983年，IEEE提出了軟件工程標(biāo)準(zhǔn)術(shù)語，軟件測試定義為：“使用人工和自動(dòng)手段來運(yùn)行或測試某個(gè)系統(tǒng)的過程，其目的在于檢驗(yàn)它是

9、否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。”該定義明確提出了軟件測試以檢驗(yàn)是否滿足需求為目標(biāo)。2.2. 測試在軟件開發(fā)中的角色為了更好地理解測試，必須了解測試在軟件開發(fā)中所扮演的角色。主要如下： 測試是執(zhí)行或者摸擬一個(gè)系統(tǒng)程序的操作。測試是為了建立一個(gè)信心， 即軟件是按照它所要求的方式執(zhí)行的， 而不會執(zhí)行它不 被希望的操作。測試是帶著發(fā)現(xiàn)問題和錯(cuò)誤的意圖來分析程序的。 測試是度量程序的功能和質(zhì)量的。測試是評價(jià)程序和項(xiàng)目工作產(chǎn)品的屬性和能力的， 并且評估其是否獲得了期望和可 接受的結(jié)果。測試除了包括執(zhí)行代碼的測試，還包括監(jiān)視和結(jié)構(gòu)化同行評審。3. 為什么要進(jìn)行軟件測試AirLie 軟

10、件咨詢中心提出了 5 個(gè)主要的原因，它們是： 一個(gè)糟糕的測試程序可能導(dǎo)致任務(wù)的失敗， 更嚴(yán)重的是可能影響操作的性能和可靠 性，并且可能會導(dǎo)致在維護(hù)維護(hù)階段花費(fèi)巨大的成本。一個(gè)好的測試程序是項(xiàng)目的主要成本。 復(fù)雜的項(xiàng)目需要花費(fèi)超過項(xiàng)目一半以上的成 本在軟件測試和驗(yàn)證上。 為了使測試有效， 必須提前花費(fèi)適當(dāng)?shù)臅r(shí)間在計(jì)劃和組織 測試上面。一個(gè)好的程序可以極大地幫助你定義需求和設(shè)計(jì)。 這有助于項(xiàng)目在一開始時(shí)就步入 正軌，并且它對整個(gè)項(xiàng)目的成功有著重要的影響。一個(gè)好的測試可以迫使你在工作時(shí)必須去面對和處理問題， 并且會使重新工作或修 改缺陷的成本變得很低。一個(gè)好的測試不能彌補(bǔ)一個(gè)糟糕的軟件項(xiàng)目， 但是的

11、確有助于發(fā)現(xiàn)許多問題并且至 少使得你盡早知道你處在問題當(dāng)中。只要是人，都會犯錯(cuò)。即使是一個(gè)優(yōu)秀的程序員，也會犯低級性的錯(cuò)誤。正因如此，測 試是必須的。常見導(dǎo)致錯(cuò)誤的根源有： 缺乏有效的溝通，或者沒有進(jìn)行溝通?，F(xiàn)在的軟件開發(fā)已經(jīng)不是一個(gè)人的事情了，往往涉及到多個(gè)人，甚至幾十、幾百個(gè)人。 同時(shí)軟件的開發(fā)還需要與不同的人， 不同的部門進(jìn)行溝通。 如果在溝通方面表現(xiàn)不力， 最后 會導(dǎo)致產(chǎn)品無法集成，或者集成出來的產(chǎn)品無法滿足用戶需要。軟件復(fù)雜度 軟件越復(fù)雜就越容易出錯(cuò)。 在當(dāng)今的軟件開發(fā)中， 對于一些沒有經(jīng)驗(yàn)的人來說， 軟件復(fù) 雜性可能是難以理解的。 圖形化界面、客戶服務(wù)器和分布式的應(yīng)用、 數(shù)據(jù)通信、

12、 大規(guī)模關(guān) 系數(shù)據(jù)庫、 應(yīng)用程序的規(guī)模等指數(shù)般地增加了軟件復(fù)雜度。 面向?qū)ο蠹夹g(shù)也有可能增加軟件 復(fù)雜度，除非能夠被很好地工程化。編程錯(cuò)誤編程錯(cuò)誤是程序員經(jīng)常會犯的錯(cuò)誤， 包括語法錯(cuò)誤、語義錯(cuò)誤、拼寫錯(cuò)誤、編程規(guī)范錯(cuò) 誤。有很多錯(cuò)誤可以通過編譯器直接找到， 但是遺留下來的錯(cuò)誤就必須通過嚴(yán)格的測試才能 發(fā)現(xiàn)。不斷變更的需求在實(shí)際項(xiàng)目開發(fā)過程中， 不斷變更的需求是項(xiàng)目失敗的最大殺手。用戶可能不知道變更的影響，或者知道影響卻還是需要進(jìn)行變更。這些會引起項(xiàng)目重新設(shè)計(jì)，工程的重新安排， 對其他項(xiàng)目產(chǎn)生影響。已完成的工作可能不得不重做或推翻。硬件需求可能也會受到影響。 如果存在許多小的變更或者任何大的改動(dòng)

13、，由于項(xiàng)目中不同部分間可知和不可知的依賴關(guān) 系，這樣就會產(chǎn)生問題，跟蹤變更的復(fù)雜性也可能引入錯(cuò)誤。項(xiàng)目開發(fā)人員的積極性也會受到打擊。在一些快速變化的商業(yè)環(huán)境下，不斷變更的需求可能是一種殘酷的現(xiàn)實(shí)。在此情況下，管理人員必須了解結(jié)果的風(fēng)險(xiǎn)，QA工程師和測試工程師必須適應(yīng)和計(jì)劃進(jìn)行大規(guī)模的測試來防止不可避免的 BUG出現(xiàn)無法控制的局面。時(shí)間的壓力進(jìn)度壓力是每個(gè)從事軟件開發(fā)人員都會碰到的問題。為了搶占市場，他們必須比競爭對手早一步把產(chǎn)品提供出來， 于是不合理的進(jìn)度安排就產(chǎn)生了。不斷加班加點(diǎn)，最終導(dǎo)致大量錯(cuò)誤的產(chǎn)生。另一方面，由于軟件項(xiàng)目的時(shí)間安排是最難的，通常需要很多猜測性的工作。 因此，當(dāng)最后期限來

14、臨時(shí)，錯(cuò)誤也就伴隨發(fā)生了。缺乏文檔資料代碼由于人員的變動(dòng)和產(chǎn)品的生命周期演進(jìn)， 在一個(gè)組織中很難保證一個(gè)人一直待在某個(gè)產(chǎn) 品開發(fā)活動(dòng)中。因此對于后面進(jìn)入產(chǎn)品的人員來說， 去讀懂和維護(hù)一個(gè)沒有文檔的糟糕代碼 是一個(gè)災(zāi)難。最終的結(jié)果只會導(dǎo)致更多的問題。軟件開發(fā)工具當(dāng)產(chǎn)品開發(fā)依賴于某些工具時(shí)，那么這些工具本身隱藏的問題可能會導(dǎo)致產(chǎn)品的缺陷。 因此，在選擇軟件開發(fā)工具時(shí)，盡可能選擇比較成熟的產(chǎn)品，不要去追求技術(shù)最新的開發(fā)工 具。這類工具往往本身還存在很多問題。4. 測試的目的從歷史的觀點(diǎn)來看，測試關(guān)注于執(zhí)行軟件來獲得軟件在可用性方面的信心并且證明軟件能夠滿意地工作。這引導(dǎo)測試把重點(diǎn)投入在檢測和排除缺陷

15、上?，F(xiàn)代的軟件測試持續(xù)了這個(gè)觀點(diǎn)。同時(shí)，還認(rèn)識到許多重要的缺陷主要來自于對需求和設(shè)計(jì)的誤解、遺漏和不正確。國 此，早期的結(jié)構(gòu)化同行評審被用于幫助預(yù)防編碼前的缺陷。證明、檢驗(yàn)和預(yù)防已經(jīng)成為一個(gè)良好的測試的重要目標(biāo)。這一發(fā)展過程如圖4-1所示。證明檢測預(yù)測表明軟件能夠工作發(fā)現(xiàn)錯(cuò)誤管理質(zhì)量20世紀(jì)60年代20世紀(jì)70年代中期20世紀(jì)90年代圖4-1發(fā)展過程圖4.1. 證明獲取系統(tǒng)在可接受風(fēng)險(xiǎn)范圍內(nèi)可用的信心；嘗試在非正常情況和條件下的功能和特性； 保證一個(gè)工作產(chǎn)品是完整的并且可用或者可被集成。4.2. 檢測發(fā)現(xiàn)缺陷、錯(cuò)誤和系統(tǒng)不足； 定義系統(tǒng)的能力和局限性； 提供組件、工作產(chǎn)品和系統(tǒng)的質(zhì)量信息。4.3. 預(yù)防澄清系統(tǒng)的規(guī)格和性能； 提供預(yù)防或減少可能制造錯(cuò)誤的信息； 在過程中盡早檢測錯(cuò)誤； 確認(rèn)問題和風(fēng)險(xiǎn)，并且提前確認(rèn)解決這些問題和風(fēng)險(xiǎn)的途徑。5. 黑盒測試5.1. 什么是黑盒測試黑盒測試 (Black Box Testing )又叫功能測試 (Functional Testing )。這是因?yàn)樵诤?盒測試中，主要關(guān)注于被測軟件的 功能實(shí)現(xiàn) ，而不是內(nèi)部邏輯。黑盒測試是與白盒測 試截然不同的測試概念，也是在軟件測試中使用得最早、最廣泛的一類測試。在黑盒 測試中，被測對象的內(nèi)部結(jié)構(gòu)、動(dòng)作情況對測試人員是不