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

《軟件測試與軟件發(fā)開過程》由會員分享，可在線閱讀，更多相關(guān)《軟件測試與軟件發(fā)開過程（29頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。

1、Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Click to edit Master title style,*,軟件測試與軟件開發(fā)過程,8.1.1 軟件開發(fā)生命周期模型,1.,軟件開發(fā)過程概述,2.,各種軟件測試在軟件開發(fā)生命周期中的位置,

2、內(nèi)容提要,定義：,軟件測試,是軟件工程（Software Engineering）的一個(gè)重要分支，隨著軟件工程學(xué)科的發(fā)展，現(xiàn)在的軟件測試與傳統(tǒng)的軟件測試相比有了很大的發(fā)展，它與軟件開發(fā)過程和軟件質(zhì)量保證（Quality Assurance，QA）密切相關(guān)。,軟件開發(fā)過程,是生產(chǎn)軟件產(chǎn)品所用的工具、方法和實(shí)踐過程的集合。在商業(yè)上軟件開發(fā)通常是由一組協(xié)同工作的人來完成的，我們把這組人稱為開發(fā)團(tuán)隊(duì)。開發(fā)團(tuán)隊(duì)里有各種角色，一個(gè)人可以充當(dāng)不止一個(gè)角色，特別是在許多小公司，有時(shí)一個(gè)人身上集中了幾個(gè)角色。,生命周期,一個(gè)軟件產(chǎn)品是由上述多種角色的團(tuán)隊(duì)協(xié)同工作而完成的。從策劃、定義、開發(fā)、使用與維護(hù)直到最后廢

3、，要經(jīng)過一個(gè)漫長的時(shí)期，通常把這個(gè)時(shí)期稱為軟件的生命周期（Software Life Cycle），很多人也把它稱為軟件開發(fā)生命周期（Software Development Life Cycle）。,8.1 軟件開發(fā)過程概述,各種角色及主要職責(zé),項(xiàng)目經(jīng)理（程序經(jīng)理）：,負(fù)責(zé)管理產(chǎn)品的質(zhì)量，以及項(xiàng)目的進(jìn)度和預(yù)算。,商業(yè)分析師（軟件分析師）：,分析客戶的真正需求，用能被程序員或其他設(shè)計(jì)人員理解的術(shù)語來定義客戶的需求。,架構(gòu)師（系統(tǒng)工程師）：,是產(chǎn)品小組的專家，負(fù)責(zé)系統(tǒng)的總體內(nèi)部設(shè)計(jì)（定義代碼，數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)通信和開發(fā)策略等）。,程序員（開發(fā)人員）：,設(shè)計(jì)、編寫程序并編寫內(nèi)部設(shè)計(jì)規(guī)格說明。,測試員

4、（質(zhì)量保證員）：,負(fù)責(zé)找出并報(bào)告軟件產(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è)計(jì)和手冊的內(nèi)容施加影響，以減少客戶的投訴。,技術(shù)文檔編寫員：,制作用戶手冊和在線幫助。,瀑布模型（Waterfall Model）,幾個(gè)特征：,（1）階段間的順序性和依賴性,（2）推遲實(shí)現(xiàn)的觀點(diǎn),（3）質(zhì)量保證的觀點(diǎn),缺點(diǎn)：,（1）不適應(yīng)需求經(jīng)常發(fā)生變更的環(huán)境。,（2）瀑布模型也經(jīng)常不能接受項(xiàng)目開始階段自然存在的不確定性。,（3）線性順序模型

5、種特征導(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）,在項(xiàng)目開發(fā)的初始階段，人們對軟件的需求認(rèn)識常常不夠清晰，使得開發(fā)項(xiàng)目難以做到一次開發(fā)成功，出現(xiàn)返工再開發(fā)在所難免。因

6、此，可以先做試驗(yàn)開發(fā)，其目標(biāo)只是探索可行性，弄清軟件需求；然后在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品。通常把第一次得到的試驗(yàn)性產(chǎn)品稱為“原型”。,螺旋模型（Spiral Model）,優(yōu)點(diǎn)：,1.,瀑布模型與原型的迭代特征結(jié)合起來，加入兩種模型均忽略了的風(fēng)險(xiǎn)分析。,2.,能夠快速開發(fā)軟件的增量版本。,3.,不要求每一個(gè)增量都是可以運(yùn)行的程序。,4.劃分為若干個(gè)框架活動，活動也稱,為任務(wù)區(qū)域。,包括,制定計(jì)劃,風(fēng)險(xiǎn)分析,實(shí)施工程,客戶評估,8.1.2 軟件測試與軟件開發(fā)過程的關(guān)系,狹義定義測試,：,比如“程序設(shè)計(jì)”與“測試”之間的關(guān)系，傳統(tǒng)上總以為程序設(shè)計(jì)在先，測試在后。這種專指測試程序代碼，定義在編

7、碼之后的“測試”是一種狹義定義的測試。,廣義,定義,測試,：,這種測試活動可以在軟件開發(fā)生命周期的任何階段進(jìn)行。但是，隨著開發(fā)不斷地進(jìn)行，越到后續(xù)階段，找出錯(cuò)誤并改正它的代價(jià)會越大,全新的軟件開發(fā)模式,：,以測試驅(qū)動軟件開發(fā)。軟件測試貫穿了整個(gè)軟件開發(fā)過程，軟件開發(fā)生命周期的各個(gè)階段中都少不了相應(yīng)的測試，這種思想與軟件質(zhì)量保證的出發(fā)點(diǎn)是一致的。,8.2 各種軟件測試在軟件開發(fā)生命周期中的位置,適用于所有的軟件生命周期的三個(gè)階段,軟件規(guī)劃,軟件開發(fā),運(yùn)行與維護(hù),在軟件規(guī)劃階段中，,主要進(jìn)行軟件目標(biāo)的策劃、,可行性研究和軟件的需求分析工作。,軟件被定義之后，,進(jìn)入開發(fā)階段，主要對軟件的體系架構(gòu)、,

8、數(shù)據(jù)結(jié)構(gòu)和主要算法進(jìn)行設(shè)計(jì)；,將設(shè)計(jì)用程序語言編碼實(shí)現(xiàn)，并進(jìn)行測試。,軟件的運(yùn)行與維護(hù)階段在軟件生命周期中,占據(jù)的比例最大。針對不同的需求，維護(hù)工作,一般可以分為糾錯(cuò)性維護(hù)、適應(yīng)性維護(hù)、,擴(kuò)充性維護(hù)和預(yù)防性維護(hù)等不同類型。,軟件開發(fā)階段還可細(xì)分為軟件設(shè)計(jì)、編碼和測試階段,8.2.1 軟件規(guī)劃階段的測試,產(chǎn)品策劃,由,項(xiàng)目經(jīng)理確定進(jìn)度計(jì)劃、項(xiàng)目范圍和開發(fā)產(chǎn)品所需的資源,規(guī),劃,階,段,需求分析,由,產(chǎn)品市場開發(fā)團(tuán)隊(duì)根據(jù)客戶提出的要求來描述產(chǎn)品的需求,需求規(guī)格說明文檔評審,這是否是真正的需求：,描述的產(chǎn)品是否就是要開發(fā)的產(chǎn)品？,需求是否完備：,第一個(gè)發(fā)布的版本是否需要更多的功能？,需求是否兼容：,

9、在邏輯上是否矛盾？需求是否可實(shí)現(xiàn)？,需求是否合理：,在開發(fā)進(jìn)度、費(fèi)用、產(chǎn)品性能、可靠性之間存在平衡關(guān)系，這些都考慮到了嗎？是否認(rèn)識到應(yīng)該根據(jù)實(shí)際安排一個(gè)優(yōu)先級計(jì)劃？,需求是否可測試：,從測試的角度出發(fā)，判斷這 樣的需 求實(shí)現(xiàn)的產(chǎn)品是否可以進(jìn)行測試。,文檔編寫是否規(guī)范，描述是否正確、完整和一致。,需求規(guī)格說明文檔評審,在需求規(guī)格說明評審?fù)ㄟ^后，測試或質(zhì)量保證人員就可以以該文檔為依據(jù)編寫測試計(jì)劃。并以同行評審（Peer Review）的方式對測試計(jì)劃進(jìn)行評審。評審人員應(yīng)該包括項(xiàng)目以外的測試或質(zhì)量保證人員、項(xiàng)目經(jīng)理和開發(fā)人員（非必需）。,8.2.2 軟件設(shè)計(jì)階段的測試,定義,軟件設(shè)計(jì)階段是設(shè)計(jì)人員將

10、軟件需求轉(zhuǎn)換為語言文字和圖表的集合，用來描述系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、算法和用戶界面。根據(jù)不同的設(shè)計(jì)方法和模式，設(shè)計(jì)分為外部設(shè)計(jì)和內(nèi)部設(shè)計(jì)，或者分為高層設(shè)計(jì)（或概要設(shè)計(jì)）和低層設(shè)計(jì)（或詳細(xì)設(shè)計(jì)）。,設(shè)計(jì),描述,外部設(shè)計(jì)主要從用戶的角度對產(chǎn)品進(jìn)行描述，內(nèi)部設(shè)計(jì)則描述產(chǎn)品的內(nèi)部工作機(jī)制。它們是并行展開，相互制約，相互要求。概要設(shè)計(jì)描述了總體上系統(tǒng)架構(gòu)應(yīng)該包含的組成元素，各個(gè)模塊之間的關(guān)聯(lián)。詳細(xì)設(shè)計(jì)主要描述各個(gè)模塊如何實(shí)現(xiàn)以及所用的算法和數(shù)據(jù)結(jié)構(gòu)。,8.2.2 軟件設(shè)計(jì)階段的測試,由于設(shè)計(jì)依賴于需求文檔，如果文檔不存在、不完善或者始終處于變更之中，設(shè)計(jì)人員就需要與需求分析人員溝通，以確定軟件產(chǎn)品應(yīng)該具備什

11、么能力。因此設(shè)計(jì)階段也是對軟件需求的深化理解和完善階段。,設(shè)計(jì)文檔進(jìn)行評審,設(shè)計(jì)是否滿足需求：,如果需求規(guī)格說明文檔是非正式的，可變的或是有歧義的，那么設(shè)計(jì)文檔就是對產(chǎn)品需求的第一份正式說明。管理人員和市場營銷人員應(yīng)該從這個(gè)角度來評審文檔，而不僅僅局限于設(shè)計(jì)本身。同時(shí)還需要建立需求和設(shè)計(jì)之間的映射關(guān)系，可以很好地追蹤軟件設(shè)計(jì)和需求的關(guān)系，從而避免設(shè)計(jì)上的遺漏。,設(shè)計(jì)是否完備：,它是否規(guī)定了模塊間的關(guān)系，模塊如何傳遞數(shù)據(jù)，異常條件下會發(fā)生什么，每個(gè)模塊是否賦予了初始狀態(tài)等。,設(shè)計(jì)是否良好：,能否產(chǎn)出高效、簡潔、可測試、可維護(hù)的軟件產(chǎn)品。,設(shè)計(jì)是否可行：,計(jì)算機(jī)能運(yùn)行這么快嗎？內(nèi)存夠嗎？數(shù)據(jù)庫中的

12、數(shù)據(jù)檢索速度能達(dá)到這么快嗎？,設(shè)計(jì)的錯(cuò)誤處理程度如何。,同時(shí)還要評審文檔編寫是否規(guī)范，描述是否正確、完整和一致。,評審會議通,評審會議通常由會議管理者（也是召集者）主持，會議的目的在于識別出設(shè)計(jì)中存在的問題，而如何修改和設(shè)計(jì)不是會議的內(nèi)容。評審人員把一系列問題帶入到會議中，評審的目的在于生成一個(gè)問題列表，并確認(rèn)設(shè)計(jì)人員是否理解了其中的歧義或者容易混淆的問題。會議記錄人員記錄下所有達(dá)成共識的意見和遺留到下次要解決的問題。,在概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)評審?fù)ㄟ^后，測試或質(zhì)量保證人員就可以以該文檔為依據(jù)編寫測試用例，并以同行評審的方式對測試用例進(jìn)行評審。評審人員應(yīng)該包括項(xiàng)目以外的測試或質(zhì)量保證人員、項(xiàng)目經(jīng)理

13、和開發(fā)人員（非必需）。,8.2.3 軟件開發(fā)編碼階段的測試,在編碼階段程序員編寫代碼并對程序進(jìn)行測試。這里的測試我們稱之為白盒測試，它是編碼期間可供程序員使用的測試類型。白盒測試有別于黑盒測試，后者將程序視為一個(gè)黑盒子，你無法看到里面的內(nèi)容。而白盒測試需要程序員運(yùn)用自己的理解能力，深入到源程序中以開發(fā)測試用例。,通常認(rèn)為白盒測試是編程過程的一部分，這是因?yàn)楫?dāng)模塊與系統(tǒng)其他部分集成之前或之后，程序員常規(guī)地都會對模塊進(jìn)行白盒測試。盡管大多數(shù)測試方面的書籍都會花很多篇幅來介紹白盒測試技術(shù)，作者們希望測試人員和程序員都進(jìn)行白盒測試，但是在實(shí)際的軟件開發(fā)項(xiàng)目中通常都是由程序員完成白盒測試。,8.2.3

14、軟件開發(fā)編碼階段的測試,白盒測試又可以分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試只要求提供程序的源代碼，代碼被檢查而不執(zhí)行。動態(tài)測試則執(zhí)行代碼，代碼被測試而不被檢查。靜態(tài)測試可以人工完成也可以借助專門的工具。,人工靜態(tài)測試方法,:,（1）個(gè)人的代碼走查（Walk Through）,（2）小組的代碼檢查（Inspection）,（3）代碼評審（Review）,其目的是由人閱讀代碼以確定以下內(nèi)容。,代碼是否能夠滿足功能需求,代碼是否與初期開發(fā)的設(shè)計(jì)一致,是否遺漏功能代碼,代碼是否恰當(dāng)?shù)靥幚砹隋e(cuò)誤,8.2.3 軟件開發(fā)編碼階段的測試,結(jié)構(gòu)測試屬于動態(tài)白盒測試，它主要考慮代碼、代碼的結(jié)構(gòu)、內(nèi)部設(shè)計(jì)以及設(shè)計(jì)是如何

15、轉(zhuǎn)化為代碼的。結(jié)構(gòu)測試又可以分為單元測試和覆蓋測試。,單元測試是結(jié)構(gòu)測試的基本部分，它是對過程或程序的單個(gè)小部分進(jìn)行測試。單元測試有很多種方法。,由于程序員了解輸入變量和對應(yīng)的預(yù)期輸出變量，可以執(zhí)行一些容易的快速測試，以檢查所有明顯的錯(cuò)誤。,對包含復(fù)雜邏輯和條件的模塊，程序員可以構(gòu)建一種調(diào)試版本，加入一些中間打印語句，監(jiān)測循環(huán)或迭代次數(shù)。重要的是一定要在修改了缺陷后刪除這些語句。,在調(diào)試器或集成開發(fā)環(huán)境中運(yùn)行被測產(chǎn)品，設(shè)置斷點(diǎn)并觀察各種系統(tǒng)參數(shù)或變量。,這些方法更像“調(diào)試”而不是“測試”，它與代碼的結(jié)構(gòu)知識密切相關(guān)。,覆蓋測試,覆蓋測試,覆蓋測試要求,Contents,Contents,了解代

16、碼和邏輯,了解如何編寫能夠覆蓋更多代碼的有效的測試用例,測試也可以叫做“灰盒測試”，因?yàn)樗鼮榱颂岣哂行跃C合使用了白盒和黑盒測試方法,功能覆蓋,語句覆蓋,路徑覆蓋,條件覆蓋,覆蓋測試時(shí)運(yùn)行測試用例考察代碼的不同部分，包括設(shè)計(jì)和執(zhí)行測試用例，并確定測試覆蓋的代碼百分比。覆蓋測試有以下幾類覆蓋。,集成測試,定義,由于系統(tǒng)是逐步開發(fā)出來的，是過程與模塊的集合。一旦單個(gè)部件能夠運(yùn)行，就將一些部件放在一起測試。將產(chǎn)品的各個(gè)部分組裝起來測試稱為集成測試。,目標(biāo),發(fā)現(xiàn)與接口有關(guān)的問題,列子：,如數(shù)據(jù)穿過接口時(shí)有可能丟失；一個(gè)模塊對另一個(gè)模塊可能由于疏忽的問題而造成有害的影響；把子功能組合起來可能不產(chǎn)生預(yù)期的主功能；全程數(shù)據(jù)結(jié)構(gòu)有可能有錯(cuò)誤等,集成測試,集成測試更多采用灰盒測試，即白盒加黑盒測試的方法。,主要幾種集成測試的策略：,（1）增量測試（incremental test）：又分為自頂向下（Top-Down）、自底向上（Bottom-Up）和混合式集成的策略。,（2）大爆炸測試（big bang test）：是一種非增量集成策略，也稱為一次性組裝或整體拼裝。,（3）冒煙測試（smoke test