軟件測試與軟件開發(fā)過程

Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,Click to edit Master title style,軟件測試與軟件開發(fā)過程,第8章,8.1.1 軟件開發(fā)生命周期模型,1.軟件開發(fā)過程概述,2.各種軟件測試在軟件開發(fā)生命周期中的位置,內(nèi)容提要,定義：,軟件測試,是軟件工程（Software Engineering）的一個重要分支，隨著軟件工程學(xué)科的發(fā)展，現(xiàn)在的軟件測試與傳統(tǒng)的軟件測試相比有了很大的發(fā)展，它與軟件開發(fā)過程和軟件質(zhì)量保證（Quality Assurance，QA）密切相關(guān)。,軟件開發(fā)過程,是生產(chǎn)軟件產(chǎn)品所用的工具、方法和實踐過程的集合。在商業(yè)上軟件開發(fā)通常是由一組協(xié)同工作的人來完成的，我們把這組人稱為開發(fā)團(tuán)隊。開發(fā)團(tuán)隊里有各種角色，一個人可以充當(dāng)不止一個角色，特別是在許多小公司，有時一個人身上集中了幾個角色。,生命周期,一個軟件產(chǎn)品是由上述多種角色的團(tuán)隊協(xié)同工作而完成的。從策劃、定義、開發(fā)、使用與維護(hù)直到最后廢，要經(jīng)過一個漫長的時期，通常把這個時期稱為軟件的生命周期（Software Life Cycle），很多人也把它稱為軟件開發(fā)生命周期（Software Development Life Cycle）。,8.1 軟件開發(fā)過程概述,各種角色及主要職責(zé),項目經(jīng)理（程序經(jīng)理）：,負(fù)責(zé)管理產(chǎn)品的質(zhì)量，以及項目的進(jìn)度和預(yù)算。,商業(yè)分析師（軟件分析師）：,分析客戶的真正需求，用能被程序員或其他設(shè)計人員理解的術(shù)語來定義客戶的需求。,架構(gòu)師（系統(tǒng)工程師）：,是產(chǎn)品小組的專家，負(fù)責(zé)系統(tǒng)的總體內(nèi)部設(shè)計（定義代碼，數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)通信和開發(fā)策略等）。,程序員（開發(fā)人員）：,設(shè)計、編寫程序并編寫內(nèi)部設(shè)計規(guī)格說明。,測試員（質(zhì)量保證員）：,負(fù)責(zé)找出并報告軟件產(chǎn)品的問題。,產(chǎn)品經(jīng)理（產(chǎn)品營銷經(jīng)理）：,負(fù)責(zé)符合公司長期戰(zhàn)略和形象的產(chǎn)品的交付，并在產(chǎn)品發(fā)布后負(fù)責(zé)市場營銷活動。對產(chǎn)品的盈利負(fù)責(zé)。,技術(shù)支持代表：,負(fù)責(zé)處理客戶投訴和服務(wù)的小組的成員。在產(chǎn)品開發(fā)期間他們會盡力對產(chǎn)品的設(shè)計和手冊的內(nèi)容施加影響，以減少客戶的投訴。,技術(shù)文檔編寫員：,制作用戶手冊和在線幫助。,瀑布模型（Waterfall Model）,幾個特征：,（1）階段間的順序性和依賴性,（2）推遲實現(xiàn)的觀點,（3）質(zhì)量保證的觀點,缺點：,（1）不適應(yīng)需求經(jīng)常發(fā)生變更的環(huán)境。,（2）瀑布模型也經(jīng)常不能接受項目開始階段自然存在的不確定性。,（3）線性順序模型種特征導(dǎo)致工作中發(fā)生“阻塞”狀態(tài)。,8.1.1 軟件開發(fā)生命周期模型,模型種類,有瀑布模型、原型模型、快速應(yīng)用開發(fā)模型、增量模型、螺旋模型、V模型、形式方法模型、RUP（Rational Unified Process）模型、敏捷過程模型、構(gòu)件組裝模型、并發(fā)開發(fā)模型等。,幾種比較流行的模型,1傳統(tǒng)的瀑布模型（Waterfall Model）,2原型模型（Prototyping Model）,3螺旋模型（Spiral Model）,原型模型（Prototyping Model）,在項目開發(fā)的初始階段，人們對軟件的需求認(rèn)識常常不夠清晰，使得開發(fā)項目難以做到一次開發(fā)成功，出現(xiàn)返工再開發(fā)在所難免。因此，可以先做試驗開發(fā)，其目標(biāo)只是探索可行性，弄清軟件需求；然后在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品。通常把第一次得到的試驗性產(chǎn)品稱為“原型”。,螺旋模型（Spiral Model）,優(yōu)點：,1.瀑布模型與原型的迭代特征結(jié)合起來，加入兩種模型均忽略了的風(fēng)險分析。,2.能夠快速開發(fā)軟件的增量版本。,3.不要求每一個增量都是可以運(yùn)行的程序。,4.劃分為若干個框架活動，活動也稱,為任務(wù)區(qū)域。,包括,制定計劃,風(fēng)險分析,實施工程,客戶評估,8.1.2 軟件測試與軟件開發(fā)過程的關(guān)系,狹義定義測試：,比如“程序設(shè)計”與“測試”之間的關(guān)系，傳統(tǒng)上總以為程序設(shè)計在先，測試在后。這種專指測試程序代碼，定義在編碼之后的“測試”是一種狹義定義的測試。,廣義定義測試：,這種測試活動可以在軟件開發(fā)生命周期的任何階段進(jìn)行。但是，隨著開發(fā)不斷地進(jìn)行，越到后續(xù)階段，找出錯誤并改正它的代價會越大,全新的軟件開發(fā)模式：,以測試驅(qū)動軟件開發(fā)。軟件測試貫穿了整個軟件開發(fā)過程，軟件開發(fā)生命周期的各個階段中都少不了相應(yīng)的測試，這種思想與軟件質(zhì)量保證的出發(fā)點是一致的。,8.2 各種軟件測試在軟件開發(fā)生命周期中的位置,適用于所有的軟件生命周期的三個階段,軟件規(guī)劃,軟件開發(fā),運(yùn)行與維護(hù),在軟件規(guī)劃階段中，,主要進(jìn)行軟件目標(biāo)的策劃、,可行性研究和軟件的需求分析工作。,軟件被定義之后，,進(jìn)入開發(fā)階段，主要對軟件的體系架構(gòu)、,數(shù)據(jù)結(jié)構(gòu)和主要算法進(jìn)行設(shè)計；,將設(shè)計用程序語言編碼實現(xiàn)，并進(jìn)行測試。,軟件的運(yùn)行與維護(hù)階段在軟件生命周期中,占據(jù)的比例最大。針對不同的需求，維護(hù)工作,一般可以分為糾錯性維護(hù)、適應(yīng)性維護(hù)、,擴(kuò)充性維護(hù)和預(yù)防性維護(hù)等不同類型。,軟件開發(fā)階段還可細(xì)分為軟件設(shè)計、編碼和測試階段,8.2.1 軟件規(guī)劃階段的測試,產(chǎn)品策劃,由項目經(jīng)理確定進(jìn)度計劃、項目范圍和開發(fā)產(chǎn)品所需的資源,規(guī),劃,階,段,需求分析,由產(chǎn)品市場開發(fā)團(tuán)隊根據(jù)客戶提出的要求來描述產(chǎn)品的需求,需求規(guī)格說明文檔評審,這是否是真正的需求：,描述的產(chǎn)品是否就是要開發(fā)的產(chǎn)品？,需求是否完備：,第一個發(fā)布的版本是否需要更多的功能？,需求是否兼容：,在邏輯上是否矛盾？需求是否可實現(xiàn)？,需求是否可實現(xiàn)？,需求是否合理：,在開發(fā)進(jìn)度、費(fèi)用、產(chǎn)品性能、可靠性之間存在平衡關(guān)系，這些都考慮到了嗎？是否認(rèn)識到應(yīng)該根據(jù)實際安排一個優(yōu)先級計劃？,需求是否可測試：,從測試的角度出發(fā)，判斷這 樣的需 求實現(xiàn)的產(chǎn)品是否可以進(jìn)行測試。,文檔編寫是否規(guī)范，描述是否正確、完整和一致。,需求規(guī)格說明文檔評審,在需求規(guī)格說明評審?fù)ㄟ^后，測試或質(zhì)量保證人員就可以以該文檔為依據(jù)編寫測試計劃。并以同行評審（Peer Review）的方式對測試計劃進(jìn)行評審。評審人員應(yīng)該包括項目以外的測試或質(zhì)量保證人員、項目經(jīng)理和開發(fā)人員（非必需）。,8.2.2 軟件設(shè)計階段的測試,定義,軟件設(shè)計階段是設(shè)計人員將軟件需求轉(zhuǎn)換為語言文字和圖表的集合，用來描述系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、算法和用戶界面。根據(jù)不同的設(shè)計方法和模式，設(shè)計分為外部設(shè)計和內(nèi)部設(shè)計，或者分為高層設(shè)計（或概要設(shè)計）和低層設(shè)計（或詳細(xì)設(shè)計）。,設(shè)計描述,外部設(shè)計主要從用戶的角度對產(chǎn)品進(jìn)行描述，內(nèi)部設(shè)計則描述產(chǎn)品的內(nèi)部工作機(jī)制。它們是并行展開，相互制約，相互要求。概要設(shè)計描述了總體上系統(tǒng)架構(gòu)應(yīng)該包含的組成元素，各個模塊之間的關(guān)聯(lián)。詳細(xì)設(shè)計主要描述各個模塊如何實現(xiàn)以及所用的算法和數(shù)據(jù)結(jié)構(gòu)。,8.2.2 軟件設(shè)計階段的測試,由于設(shè)計依賴于需求文檔，如果文檔不存在、不完善或者始終處于變更之中，設(shè)計人員就需要與需求分析人員溝通，以確定軟件產(chǎn)品應(yīng)該具備什么能力。因此設(shè)計階段也是對軟件需求的深化理解和完善階段。,設(shè)計文檔進(jìn)行評審,設(shè)計是否滿足需求：,如果需求規(guī)格說明文檔是非正式的，可變的或是有歧義的，那么設(shè)計文檔就是對產(chǎn)品需求的第一份正式說明。管理人員和市場營銷人員應(yīng)該從這個角度來評審文檔，而不僅僅局限于設(shè)計本身。同時還需要建立需求和設(shè)計之間的映射關(guān)系，可以很好地追蹤軟件設(shè)計和需求的關(guān)系，從而避免設(shè)計上的遺漏。,設(shè)計是否完備：,它是否規(guī)定了模塊間的關(guān)系，模塊如何傳遞數(shù)據(jù)，異常條件下會發(fā)生什么，每個模塊是否賦予了初始狀態(tài)等。,設(shè)計是否良好：,能否產(chǎn)出高效、簡潔、可測試、可維護(hù)的軟件產(chǎn)品。,設(shè)計是否可行：,計算機(jī)能運(yùn)行這么快嗎？內(nèi)存夠嗎？數(shù)據(jù)庫中的數(shù)據(jù)檢索速度能達(dá)到這么快嗎？,設(shè)計的錯誤處理程度如何。,同時還要評審文檔編寫是否規(guī)范，描述是否正確、完整和一致。,評審會議：,評審會議通常由,會議管理者（也是召集者）,主持，會議的目的在于識別出設(shè)計中存在的,問題，而如何修改和設(shè)計不是會議的內(nèi)容。,評審人員,把一系列問題帶入到會議中，評審的目的在于生成一個問題列,表，并確認(rèn)設(shè)計人員是否理解了其中的歧義或者容易混淆的問題。,會議記錄人員,記錄下所有達(dá)成共識的意見和遺留到下次要解決的問題。,在概要設(shè)計和詳細(xì)設(shè)計評審?fù)ㄟ^后，測試或質(zhì)量保證人員就可以以該文檔為依據(jù)編寫測試用例，并以同行評審的方式對測試用例進(jìn)行評審。評審人員應(yīng)該包括項目以外的測試或質(zhì)量保證人員、項目經(jīng)理和開發(fā)人員（非必需）。,8.2.3 軟件開發(fā)編碼階段的測試,在編碼階段程序員編寫代碼并對程序進(jìn)行測試。這里的測試我們稱之為白盒測試，它是編碼期間可供程序員使用的測試類型。白盒測試有別于黑盒測試，后者將程序視為一個黑盒子，你無法看到里面的內(nèi)容。而白盒測試需要程序員運(yùn)用自己的理解能力，深入到源程序中以開發(fā)測試用例。,通常認(rèn)為白盒測試是編程過程的一部分，這是因為當(dāng)模塊與系統(tǒng)其他部分集成之前或之后，程序員常規(guī)地都會對模塊進(jìn)行白盒測試。,8.2.3 軟件開發(fā)編碼階段的測試,白盒測試又可以分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試只要求提供程序的源代碼，代碼被檢查而不執(zhí)行。動態(tài)測試則執(zhí)行代碼，代碼被測試而不被檢查。靜態(tài)測試可以人工完成也可以借助專門的工具。,人工靜態(tài)測試方法,:,（1）個人的代碼走查（Walk Through）,（2）小組的代碼檢查（Inspection）,（3）代碼評審（Review）,人工靜態(tài)測試目的：由人閱讀代碼，以確定以下內(nèi)容：,代碼是否能夠滿足功能需求,代碼是否與初期開發(fā)的設(shè)計一致,是否遺漏功能代碼,代碼是否恰當(dāng)?shù)靥幚砹隋e誤,8.2.3 軟件開發(fā)編碼階段的測試,結(jié)構(gòu)測試：屬于動態(tài)白盒測試,主要考慮：代碼,代碼的結(jié)構(gòu),內(nèi)部設(shè)計以及設(shè)計是如何轉(zhuǎn)化為代碼的。,結(jié)構(gòu)測試可分為：1.單元測試,2.覆蓋測試。,單元測試是結(jié)構(gòu)測試的基本部分，它是對過程或程序的單個小部分,進(jìn)行測試。,單元測試有很多種方法。,由于程序員了解輸入變量和對應(yīng)的預(yù)期輸出變量，可以執(zhí)行一些容易的快速測試，以檢查所有明顯的錯誤。,對包含復(fù)雜邏輯和條件的模塊，程序員可以構(gòu)建一種調(diào)試版本，加入一些中間打印語句，監(jiān)測循環(huán)或迭代次數(shù)。重要的是一定要在修改了缺陷后刪除這些語句。,在調(diào)試器或集成開發(fā)環(huán)境中運(yùn)行被測產(chǎn)品，設(shè)置斷點并觀察各種系統(tǒng)參數(shù)或變量。,總結(jié)：這些方法更像“調(diào)試”而不是“測試”，它與代碼的結(jié)構(gòu)知識密切相關(guān)。,覆蓋測試,覆蓋測試,覆蓋測試要求,Contents,Contents,了解代碼和邏輯,了解如何編寫能夠覆蓋更多代碼的有效的測試用例,測試也可以叫做“灰盒測試”，因為它為了提高有效性綜合使用了白盒和黑盒測試方法,功能覆蓋,語句覆蓋,路徑覆蓋,條件覆蓋,覆蓋測試時運(yùn)行測試用例考察代碼的不同部分，包括設(shè)計和執(zhí)行測試用例，并確定測試覆蓋的代碼百分比。覆蓋測試有以下幾類覆蓋。,集成測試,定義,由于系統(tǒng)是逐步開發(fā)出來的，是過程與模塊的集合。一旦單個部件能夠運(yùn)行，就將一些部件放在一起測試。將產(chǎn)品的各個部分組裝起來測試稱為集成測試。,目標(biāo),發(fā)現(xiàn)與接口有關(guān)的問題,列子：,如數(shù)據(jù)穿過接口時有可能丟失；一個模塊對另一個模塊可能由于疏忽的問題而造成有害的影響；把子功能組合起來可能不產(chǎn)生預(yù)期的主功能；全程數(shù)據(jù)結(jié)構(gòu)有可能有錯誤等,集成測試,集成測試更多采用灰盒測試，即白盒加黑盒測試的方法。,主要幾種集成測試的策略：,（1）增量測試（incremental test）：又分為自頂向下（Top-Down）、自底向上（Bottom-Up）和混合式集成的策略。,（2）大爆炸測試（big bang test）：是一種非增量集成策略，也稱為一次性組裝或整體拼裝。,（3）冒煙測試（smoke test）：當(dāng)項目開發(fā)的時間比較緊的時候可以考慮冒煙測試的方法，軟件團(tuán)隊的人員可以定期地操作這個軟件系統(tǒng)。,冒煙測試包括如下的活動。,將已經(jīng)完成編碼的模塊集成為一個build系統(tǒng)，包括數(shù)據(jù)文件、庫文件、重用模塊和實現(xiàn)部分功能的組件。,對這個build系統(tǒng)做一系列的測試，發(fā)現(xiàn)錯誤，使得該系統(tǒng)可以正確運(yùn)行功能。,將一個build系統(tǒng)與另外的build系統(tǒng)不