軟件測(cè)試與軟件開(kāi)發(fā)過(guò)程

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

8.1 軟件開(kāi)發(fā)過(guò)程概述,各種角色及主要職責(zé),項(xiàng)目經(jīng)理（程序經(jīng)理）：,負(fù)責(zé)管理產(chǎn)品的質(zhì)量，以及項(xiàng)目的進(jìn)度和預(yù)算商業(yè)分析師（軟件分析師）：,分析客戶的真正需求，用能被程序員或其他設(shè)計(jì)人員理解的術(shù)語(yǔ)來(lái)定義客戶的需求架構(gòu)師（系統(tǒng)工程師）：,是產(chǎn)品小組的專家，負(fù)責(zé)系統(tǒng)的總體內(nèi)部設(shè)計(jì)（定義代碼，數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)通信和開(kāi)發(fā)策略等）程序員（開(kāi)發(fā)人員）：,設(shè)計(jì)、編寫程序并編寫內(nèi)部設(shè)計(jì)規(guī)格說(shuō)明測(cè)試員（質(zhì)量保證員）：,負(fù)責(zé)找出并報(bào)告軟件產(chǎn)品的問(wèn)題產(chǎn)品經(jīng)理（產(chǎn)品營(yíng)銷經(jīng)理）：,負(fù)責(zé)符合公司長(zhǎng)期戰(zhàn)略和形象的產(chǎn)品的交付，并在產(chǎn)品發(fā)布后負(fù)責(zé)市場(chǎng)營(yíng)銷活動(dòng)對(duì)產(chǎn)品的盈利負(fù)責(zé)技術(shù)支持代表：,負(fù)責(zé)處理客戶投訴和服務(wù)的小組的成員在產(chǎn)品開(kāi)發(fā)期間他們會(huì)盡力對(duì)產(chǎn)品的設(shè)計(jì)和手冊(cè)的內(nèi)容施加影響，以減少客戶的投訴技術(shù)文檔編寫員：,制作用戶手冊(cè)和在線幫助瀑布模型（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)目開(kāi)始階段自然存在的不確定性3）線性順序模型種特征導(dǎo)致工作中發(fā)生“阻塞”狀態(tài)8.1.1 軟件開(kāi)發(fā)生命周期模型,模型種類,有瀑布模型、原型模型、快速應(yīng)用開(kāi)發(fā)模型、增量模型、螺旋模型、V模型、形式方法模型、RUP（Rational Unified Process）模型、敏捷過(guò)程模型、構(gòu)件組裝模型、并發(fā)開(kāi)發(fā)模型等。

幾種比較流行的模型,1傳統(tǒng)的瀑布模型（Waterfall Model）,2原型模型（Prototyping Model）,3螺旋模型（Spiral Model）,原型模型（Prototyping Model）,在項(xiàng)目開(kāi)發(fā)的初始階段，人們對(duì)軟件的需求認(rèn)識(shí)常常不夠清晰，使得開(kāi)發(fā)項(xiàng)目難以做到一次開(kāi)發(fā)成功，出現(xiàn)返工再開(kāi)發(fā)在所難免因此，可以先做試驗(yàn)開(kāi)發(fā)，其目標(biāo)只是探索可行性，弄清軟件需求；然后在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品通常把第一次得到的試驗(yàn)性產(chǎn)品稱為“原型”螺旋模型（Spiral Model）,優(yōu)點(diǎn)：,1.瀑布模型與原型的迭代特征結(jié)合起來(lái)，加入兩種模型均忽略了的風(fēng)險(xiǎn)分析2.能夠快速開(kāi)發(fā)軟件的增量版本3.不要求每一個(gè)增量都是可以運(yùn)行的程序4.劃分為若干個(gè)框架活動(dòng)，活動(dòng)也稱,為任務(wù)區(qū)域包括,制定計(jì)劃,風(fēng)險(xiǎn)分析,實(shí)施工程,客戶評(píng)估,8.1.2 軟件測(cè)試與軟件開(kāi)發(fā)過(guò)程的關(guān)系,狹義定義測(cè)試：,比如“程序設(shè)計(jì)”與“測(cè)試”之間的關(guān)系，傳統(tǒng)上總以為程序設(shè)計(jì)在先，測(cè)試在后這種專指測(cè)試程序代碼，定義在編碼之后的“測(cè)試”是一種狹義定義的測(cè)試廣義定義測(cè)試：,這種測(cè)試活動(dòng)可以在軟件開(kāi)發(fā)生命周期的任何階段進(jìn)行但是，隨著開(kāi)發(fā)不斷地進(jìn)行，越到后續(xù)階段，找出錯(cuò)誤并改正它的代價(jià)會(huì)越大,全新的軟件開(kāi)發(fā)模式：,以測(cè)試驅(qū)動(dòng)軟件開(kāi)發(fā)。

軟件測(cè)試貫穿了整個(gè)軟件開(kāi)發(fā)過(guò)程，軟件開(kāi)發(fā)生命周期的各個(gè)階段中都少不了相應(yīng)的測(cè)試，這種思想與軟件質(zhì)量保證的出發(fā)點(diǎn)是一致的8.2 各種軟件測(cè)試在軟件開(kāi)發(fā)生命周期中的位置,適用于所有的軟件生命周期的三個(gè)階段,軟件規(guī)劃,軟件開(kāi)發(fā),運(yùn)行與維護(hù),在軟件規(guī)劃階段中，,主要進(jìn)行軟件目標(biāo)的策劃、,可行性研究和軟件的需求分析工作軟件被定義之后，,進(jìn)入開(kāi)發(fā)階段，主要對(duì)軟件的體系架構(gòu)、,數(shù)據(jù)結(jié)構(gòu)和主要算法進(jìn)行設(shè)計(jì)；,將設(shè)計(jì)用程序語(yǔ)言編碼實(shí)現(xiàn)，并進(jìn)行測(cè)試軟件的運(yùn)行與維護(hù)階段在軟件生命周期中,占據(jù)的比例最大針對(duì)不同的需求，維護(hù)工作,一般可以分為糾錯(cuò)性維護(hù)、適應(yīng)性維護(hù)、,擴(kuò)充性維護(hù)和預(yù)防性維護(hù)等不同類型軟件開(kāi)發(fā)階段還可細(xì)分為軟件設(shè)計(jì)、編碼和測(cè)試階段,8.2.1 軟件規(guī)劃階段的測(cè)試,產(chǎn)品策劃,由項(xiàng)目經(jīng)理確定進(jìn)度計(jì)劃、項(xiàng)目范圍和開(kāi)發(fā)產(chǎn)品所需的資源,規(guī),劃,階,段,需求分析,由產(chǎn)品市場(chǎng)開(kāi)發(fā)團(tuán)隊(duì)根據(jù)客戶提出的要求來(lái)描述產(chǎn)品的需求,需求規(guī)格說(shuō)明文檔評(píng)審,這是否是真正的需求：,描述的產(chǎn)品是否就是要開(kāi)發(fā)的產(chǎn)品？,需求是否完備：,第一個(gè)發(fā)布的版本是否需要更多的功能？,需求是否兼容：,在邏輯上是否矛盾？需求是否可實(shí)現(xiàn)？,需求是否可實(shí)現(xiàn)？,需求是否合理：,在開(kāi)發(fā)進(jìn)度、費(fèi)用、產(chǎn)品性能、可靠性之間存在平衡關(guān)系，這些都考慮到了嗎？是否認(rèn)識(shí)到應(yīng)該根據(jù)實(shí)際安排一個(gè)優(yōu)先級(jí)計(jì)劃？,需求是否可測(cè)試：,從測(cè)試的角度出發(fā)，判斷這 樣的需 求實(shí)現(xiàn)的產(chǎn)品是否可以進(jìn)行測(cè)試。

文檔編寫是否規(guī)范，描述是否正確、完整和一致需求規(guī)格說(shuō)明文檔評(píng)審,在需求規(guī)格說(shuō)明評(píng)審?fù)ㄟ^(guò)后，測(cè)試或質(zhì)量保證人員就可以以該文檔為依據(jù)編寫測(cè)試計(jì)劃并以同行評(píng)審（Peer Review）的方式對(duì)測(cè)試計(jì)劃進(jìn)行評(píng)審評(píng)審人員應(yīng)該包括項(xiàng)目以外的測(cè)試或質(zhì)量保證人員、項(xiàng)目經(jīng)理和開(kāi)發(fā)人員（非必需）8.2.2 軟件設(shè)計(jì)階段的測(cè)試,定義,軟件設(shè)計(jì)階段是設(shè)計(jì)人員將軟件需求轉(zhuǎn)換為語(yǔ)言文字和圖表的集合，用來(lái)描述系統(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ì)主要從用戶的角度對(duì)產(chǎn)品進(jìn)行描述，內(nèi)部設(shè)計(jì)則描述產(chǎn)品的內(nèi)部工作機(jī)制它們是并行展開(kāi)，相互制約，相互要求概要設(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ì)階段的測(cè)試,由于設(shè)計(jì)依賴于需求文檔，如果文檔不存在、不完善或者始終處于變更之中，設(shè)計(jì)人員就需要與需求分析人員溝通，以確定軟件產(chǎn)品應(yīng)該具備什么能力因此設(shè)計(jì)階段也是對(duì)軟件需求的深化理解和完善階段設(shè)計(jì)文檔進(jìn)行評(píng)審,設(shè)計(jì)是否滿足需求：,如果需求規(guī)格說(shuō)明文檔是非正式的，可變的或是有歧義的，那么設(shè)計(jì)文檔就是對(duì)產(chǎn)品需求的第一份正式說(shuō)明。

管理人員和市場(chǎng)營(yíng)銷人員應(yīng)該從這個(gè)角度來(lái)評(píng)審文檔，而不僅僅局限于設(shè)計(jì)本身同時(shí)還需要建立需求和設(shè)計(jì)之間的映射關(guān)系，可以很好地追蹤軟件設(shè)計(jì)和需求的關(guān)系，從而避免設(shè)計(jì)上的遺漏設(shè)計(jì)是否完備：,它是否規(guī)定了模塊間的關(guān)系，模塊如何傳遞數(shù)據(jù)，異常條件下會(huì)發(fā)生什么，每個(gè)模塊是否賦予了初始狀態(tài)等設(shè)計(jì)是否良好：,能否產(chǎn)出高效、簡(jiǎn)潔、可測(cè)試、可維護(hù)的軟件產(chǎn)品設(shè)計(jì)是否可行：,計(jì)算機(jī)能運(yùn)行這么快嗎？?jī)?nèi)存夠嗎？數(shù)據(jù)庫(kù)中的數(shù)據(jù)檢索速度能達(dá)到這么快嗎？,設(shè)計(jì)的錯(cuò)誤處理程度如何同時(shí)還要評(píng)審文檔編寫是否規(guī)范，描述是否正確、完整和一致評(píng)審會(huì)議：,評(píng)審會(huì)議通常由,會(huì)議管理者（也是召集者）,主持，會(huì)議的目的在于識(shí)別出設(shè)計(jì)中存在的,問(wèn)題，而如何修改和設(shè)計(jì)不是會(huì)議的內(nèi)容評(píng)審人員,把一系列問(wèn)題帶入到會(huì)議中，評(píng)審的目的在于生成一個(gè)問(wèn)題列,表，并確認(rèn)設(shè)計(jì)人員是否理解了其中的歧義或者容易混淆的問(wèn)題會(huì)議記錄人員,記錄下所有達(dá)成共識(shí)的意見(jiàn)和遺留到下次要解決的問(wèn)題在概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)評(píng)審?fù)ㄟ^(guò)后，測(cè)試或質(zhì)量保證人員就可以以該文檔為依據(jù)編寫測(cè)試用例，并以同行評(píng)審的方式對(duì)測(cè)試用例進(jìn)行評(píng)審評(píng)審人員應(yīng)該包括項(xiàng)目以外的測(cè)試或質(zhì)量保證人員、項(xiàng)目經(jīng)理和開(kāi)發(fā)人員（非必需）。

8.2.3 軟件開(kāi)發(fā)編碼階段的測(cè)試,在編碼階段程序員編寫代碼并對(duì)程序進(jìn)行測(cè)試這里的測(cè)試我們稱之為白盒測(cè)試，它是編碼期間可供程序員使用的測(cè)試類型白盒測(cè)試有別于黑盒測(cè)試，后者將程序視為一個(gè)黑盒子，你無(wú)法看到里面的內(nèi)容而白盒測(cè)試需要程序員運(yùn)用自己的理解能力，深入到源程序中以開(kāi)發(fā)測(cè)試用例通常認(rèn)為白盒測(cè)試是編程過(guò)程的一部分，這是因?yàn)楫?dāng)模塊與系統(tǒng)其他部分集成之前或之后，程序員常規(guī)地都會(huì)對(duì)模塊進(jìn)行白盒測(cè)試8.2.3 軟件開(kāi)發(fā)編碼階段的測(cè)試,白盒測(cè)試又可以分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試靜態(tài)測(cè)試只要求提供程序的源代碼，代碼被檢查而不執(zhí)行動(dòng)態(tài)測(cè)試則執(zhí)行代碼，代碼被測(cè)試而不被檢查靜態(tài)測(cè)試可以人工完成也可以借助專門的工具人工靜態(tài)測(cè)試方法,:,（1）個(gè)人的代碼走查（Walk Through）,（2）小組的代碼檢查（Inspection）,（3）代碼評(píng)審（Review）,人工靜態(tài)測(cè)試目的：由人閱讀代碼，以確定以下內(nèi)容：,代碼是否能夠滿足功能需求,代碼是否與初期開(kāi)發(fā)的設(shè)計(jì)一致,是否遺漏功能代碼,代碼是否恰當(dāng)?shù)靥幚砹隋e(cuò)誤,8.2.3 軟件開(kāi)發(fā)編碼階段的測(cè)試,結(jié)構(gòu)測(cè)試：屬于動(dòng)態(tài)白盒測(cè)試,主要考慮：代碼,代碼的結(jié)構(gòu),內(nèi)部設(shè)計(jì)以及設(shè)計(jì)是如何轉(zhuǎn)化為代碼的。

結(jié)構(gòu)測(cè)試可分為：1.單元測(cè)試,2.覆蓋測(cè)試單元測(cè)試是結(jié)構(gòu)測(cè)試的基本部分，它是對(duì)過(guò)程或程序的單個(gè)小部分,進(jìn)行測(cè)試單元測(cè)試有很多種方法由于程序員了解輸入變量和對(duì)應(yīng)的預(yù)期輸出變量，可以執(zhí)行一些容易的快速測(cè)試，以檢查所有明顯的錯(cuò)誤對(duì)包含復(fù)雜邏輯和條件的模塊，程序員可以構(gòu)建一種調(diào)試版本，加入一些中間打印語(yǔ)句，監(jiān)測(cè)循環(huán)或迭代次數(shù)重要的是一定要在修改了缺陷后刪除這些語(yǔ)句在調(diào)試器或集成開(kāi)發(fā)環(huán)境中運(yùn)行被測(cè)產(chǎn)品，設(shè)置斷點(diǎn)并觀察各種系統(tǒng)參數(shù)或變量總結(jié)：這些方法更像“調(diào)試”而不是“測(cè)試”，它與代碼的結(jié)構(gòu)知識(shí)密切相關(guān)覆蓋測(cè)試,覆蓋測(cè)試,覆蓋測(cè)試要求,Contents,Contents,了解代碼和邏輯,了解如何編寫能夠覆蓋更多代碼的有效的測(cè)試用例,測(cè)試也可以叫做“灰盒測(cè)試”，因?yàn)樗鼮榱颂岣哂行跃C合使用了白盒和黑盒測(cè)試方法,功能覆蓋,語(yǔ)句覆蓋,路徑覆蓋,條件覆蓋,覆蓋測(cè)試時(shí)運(yùn)行測(cè)試用例考察代碼的不同部分，包括設(shè)計(jì)和執(zhí)行測(cè)試用例，并確定測(cè)試覆蓋的代碼百分比覆蓋測(cè)試有以下幾類覆蓋集成測(cè)試,定義,由于系統(tǒng)是逐步開(kāi)發(fā)出來(lái)的，是過(guò)程與模塊的集合一旦單個(gè)部件能夠運(yùn)行，就將一些部件放在一起測(cè)試將產(chǎn)品的各個(gè)部分組裝起來(lái)測(cè)試稱為集成測(cè)試。

目標(biāo),發(fā)現(xiàn)與接口有關(guān)的問(wèn)題,列子：,如數(shù)據(jù)穿過(guò)接口時(shí)有可能丟失；一個(gè)模塊對(duì)另一個(gè)模塊可能由于疏忽的問(wèn)題而造成有害的影響；把子功能組合起來(lái)可能不產(chǎn)生預(yù)期的主功能；全程數(shù)據(jù)結(jié)構(gòu)有可能有錯(cuò)誤等,集成測(cè)試,集成測(cè)試更多采用灰盒測(cè)試，即白盒加黑盒測(cè)試的方法主要幾種集成測(cè)試的策略：,（1）增量測(cè)試（incremental test）：又分為自頂向下（Top-Down）、自底向上（Bottom-Up）和混合式集成的策略2）大爆炸測(cè)試（big bang test）：是一種非增量集成策略，也稱為一次性組裝或整體拼裝3）冒煙測(cè)試（smoke test）：當(dāng)項(xiàng)目開(kāi)發(fā)的時(shí)間比較緊的時(shí)候可以考慮冒煙測(cè)試的方法，軟件團(tuán)隊(duì)的人員可以定期地操作這個(gè)軟件系統(tǒng)冒煙測(cè)試包括如下的活動(dòng)將已經(jīng)完成編碼的模塊集成為一個(gè)build系統(tǒng)，包括數(shù)據(jù)文件、庫(kù)文件、重用模塊和實(shí)現(xiàn)部分功能的組件對(duì)這個(gè)build系統(tǒng)做一系列的測(cè)試，發(fā)現(xiàn)錯(cuò)誤，使得該系統(tǒng)可以正確運(yùn)行功能將一個(gè)build系統(tǒng)與另外的build系統(tǒng)不。