【正文】 測試計劃、集成測試規(guī)格說明書和集成測試分析報告。（2）集成測試過程中連接各個模塊的順序。自底向上的增殖方式。自頂向下的增殖方式。組成時需要考慮的問題：1）在把各個模塊連接起的時候，穿越模塊接口的數(shù)據(jù)是否會丟失； 2）一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；3）各個子功能組合起來，能否達到預(yù)期要求的父功能；4）全局數(shù)據(jù)結(jié)構(gòu)是否有問題； 5）單個模塊的誤差累積起來，是否會放大，以至達到不能接受的程度。模塊和錯誤處理功能包含有錯誤或缺陷：出錯的描述難以理解；出錯的描述不足以對錯誤定位，不足以確定出錯的原因；顯示的錯誤與實際的錯誤不符；對錯誤條件的處理不正確；在對錯誤進行處理之前，錯誤條件已經(jīng)引起系統(tǒng)的干預(yù)等。在進行單元測試時，測試者需要依據(jù)詳細設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。不論是批處理的輸入/輸出方式，還是交互式的輸入/輸出方式，在設(shè)計和程序編碼時都應(yīng)考慮下列原則。（3）使用注釋說明復(fù)雜數(shù)據(jù)結(jié)構(gòu)。程序良好的風(fēng)格表現(xiàn)在源程序文檔化、數(shù)據(jù)說明的方法、語句結(jié)構(gòu)的輸入/輸出方法這四個方面，軟件編碼規(guī)范評測也是圍繞這四個方面展開。需求說明書評測內(nèi)容。原則3：如果目標軟件只是一個大系統(tǒng)中的一個元素，那么整個系統(tǒng)也包括在規(guī)格說明的描述之中。編制良好的需求說明書8條原則：功能與實現(xiàn)分離；要求使用面向處理的規(guī)格說明語言；描述該目標軟件與系統(tǒng)的其他系統(tǒng)元素交互的方式；規(guī)格說明必須包括系統(tǒng)運行的環(huán)境；系統(tǒng)規(guī)格說明必須是一個認識的模型；規(guī)格說明必須是可操作的；規(guī)格說明必須容許不完備性并允許擴充；規(guī)格說明必須局部化和松散的耦合。 軟件開發(fā)與軟件測試軟件開發(fā)的過程是一個自頂向下，逐步細化的過程。前置測試模型它是一個將測試和開發(fā)緊密結(jié)合的模型，該模型提供了輕松的方式，可使你的項目加快速度。軟件測試要盡早準備，盡早執(zhí)行。W模型也是有局限性。在V模型中增加軟件和開發(fā)階段應(yīng)同步進行的測試。V模型存在一定的局限性，它僅僅是測試過程作為在需求分析、概要設(shè)計、詳細設(shè)計及編碼后的一個階段。 白盒測試又稱結(jié)構(gòu)測試。（2）黑盒測試通過軟件的外部表現(xiàn)來發(fā)現(xiàn)其缺陷和錯誤。（3）第三方測試介于軟件開發(fā)方和用戶方之間的測試組織的測試。216。集成測試是檢驗程序或部件的接口關(guān)系，逐步集成為符合概要設(shè)計要求的程序部件或整個系統(tǒng)。系統(tǒng)測試是在真實或模擬系統(tǒng)運行的環(huán)境下，檢查完整的程序系統(tǒng)能否（包括硬件、外設(shè)、網(wǎng)絡(luò)和系統(tǒng)軟件、支持平臺等）正確配置、連接，并滿足用戶需求。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。驗證與確認都屬于軟件測試，它包括對軟件分析、設(shè)計以及程序的驗證和確認。）軟件測試對象根據(jù)軟件定義，軟件包括程序、數(shù)據(jù)和文檔，所以軟件測試并不僅僅是程序測試。 輸出結(jié)果太多；軟件測試是保證軟件質(zhì)量的一個重要環(huán)節(jié)。軟件質(zhì)量定義是：軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力。測試的含義為“為檢驗產(chǎn)品是否滿足需求為目標”。軟件測試的目的是為了發(fā)現(xiàn)軟件中存在的錯誤，但是，其根本目的是為了提高軟件質(zhì)量，降低軟件項目的風(fēng)險。軟件的質(zhì)量風(fēng)險表現(xiàn)在兩個方面，一種是內(nèi)部風(fēng)險，一種是外部風(fēng)險。“軟件測試”的經(jīng)典定義是在規(guī)定條件下對程序進行操作，以發(fā)現(xiàn)錯誤，對軟件質(zhì)量進行評估。軟件質(zhì)量包括：內(nèi)部質(zhì)量、外部質(zhì)量、使用質(zhì)量三個部分。軟件測試目的測試目的三個觀點：測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤；一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試；測試的目的，是想以最少的人力、物力和時間找出軟件潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造居的隱患所帶來的商業(yè)風(fēng)險。 在有限的時間和資源條件下，軟件趨于完美，是不可能的。在軟件編碼結(jié)束后，對編寫的每一個程序模塊進行測試，稱為模塊測試或單元測試。需求分析、概要設(shè)計、詳細設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細設(shè)計規(guī)格說明以及源程序，都應(yīng)成為“軟件測試”的對象。多個模塊可以平行地獨立進行單元測試。驗收測試：按照項目任務(wù)書或合同、供需雙方約定的驗收依據(jù)文檔進行的對整個系統(tǒng)的測試與評審，決定是否接收或拒收系統(tǒng)。冒煙測試也叫驗證測試、提交測試。 驗收測試按照項目任務(wù)書或合同、供需雙方約定的驗收依據(jù)文檔進行的對整個系統(tǒng)的測試與評審，決定是否接收或拒收系統(tǒng)。一般情況下是在模擬用戶真實應(yīng)用環(huán)境下，進行軟件確認測試。黑盒測試法把測試對象看成一個黑盒子，完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過程。通過對程序內(nèi)部結(jié)構(gòu)的分析、檢測來尋找問題。需求分析階段隱藏的問題一直到后期的驗收測試才被發(fā)現(xiàn)。局限性：軟件開發(fā)和測試保持一種線性的前后關(guān)系，需要有嚴格的指令表示上一階段完全結(jié)束，才可正式開始下一個階段。W模型和V模型都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動。軟件測試是根據(jù)被測物的不同而分層次進行的。前置測試模型體現(xiàn)了以下的要點：（1）開發(fā)和測試相結(jié)合；前置測試模型將開發(fā)和測試的生命周期整合在一起，標識了項目生命周期從開始到結(jié)束之間的關(guān)鍵行為。測試過程則是依照相反的順序安排自底向上，逐步集成的過程。（1）需求說明書評測 需求說明書是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設(shè)計約束的說明、性能需求和設(shè)計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。原則4：規(guī)格說明必須包括系統(tǒng)運行的環(huán)境。需求說明書評測作為需求分析階段工作的復(fù)查手段，應(yīng)該對功能的正確性、完整性和清晰性，以及其他需求給予評測。源程序文檔化（1）符號名的命名。語句結(jié)構(gòu)在設(shè)計階段確定了軟件的邏輯流結(jié)構(gòu)，但構(gòu)造單個語句則是編碼階段的任務(wù)。輸入和輸出在設(shè)計和程序編碼時都應(yīng)考慮下列原則。這要求對所有的局部的和全局的數(shù)據(jù)結(jié)構(gòu)、外部接口和程序代碼的關(guān)鍵部分，都要進行桌面檢查和嚴格的代碼審查。5）邊界測試單元測試步驟：驅(qū)動模塊（driver）相當于所測模塊的主程序。子系統(tǒng)的集成測試稱為部件測試，它所做的工作是要找出組裝后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。步驟如下：首先以主模塊作為所測模塊兼驅(qū)動模塊，所有直屬于主模塊的下屬模塊全部用樁模塊代替，對主模塊進行測試。提高測試效率。（3）模塊代碼編制和測試進度是否與集成測試的順序一致。（3）確認測試確認測試的任務(wù)是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。（2）測試結(jié)果與預(yù)期的結(jié)果不符。V過程包括軟件產(chǎn)品和過程的分析、評價、評審、審核、評估和測試。獨立驗證和確認：由在技術(shù)、管理和財務(wù)上與開發(fā)組織有規(guī)定程度獨立性的組織執(zhí)行的Vamp。V過程中的測試測試過程。（2）軟件缺陷存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望或不可接受的偏差。設(shè)計方案（軟件設(shè)計說明書）是軟件缺陷第二來源。修正（Fixed）：開發(fā)人員已完成修正，等待測試人員驗證。自動化測試的定義：通過測試工具或其他手段，按照測試工程師的預(yù)定計劃對軟件產(chǎn)品進行自動的測試，它是軟件測試的一個重要的組成部分，它能夠完成許多手工無法完成或難以實現(xiàn)的一些測試。當你進行錄制時，測試工具會對你選取的每個對象做惟一描述并寫入相應(yīng)的文件中。調(diào)試腳本：腳本錄制或編輯結(jié)束后，在調(diào)試模式下運行腳本。在進行測試腳本錄制與分配的過程中，應(yīng)遵循如下幾個原則。在軟件質(zhì)量中用于測量一種量化的標度和方法即為“測度”，而名詞的“度量”用來指測量的結(jié)果。如圖33所示說明了質(zhì)量特性與質(zhì)量子特性的層次結(jié)構(gòu)。GB/T189052002《軟件工程 產(chǎn)品評價》。（GB/）軟件產(chǎn)品的一般評價過程是：確立評價需求，然后，規(guī)定、設(shè)計和執(zhí)行評價。（3）確立度量評定等級（4）確立評估準則GB/T162602003《軟件工程 產(chǎn)品質(zhì)量》。標準的變化標準之間的關(guān)系GB/，GB/T16260的評價過程與度量是遵循GB/T18905的。（4）使用質(zhì)量 使用質(zhì)量是從用戶觀點出發(fā)，來看待軟件產(chǎn)品用于特定環(huán)境和條件下的質(zhì)量。（1）適合性（2）準確性（3）互操作性（4）保密安全（5）功能性依從性可靠性在指定條件下使用時，軟件產(chǎn)品維持規(guī)定的性能級別的能力。（3）共存性共存性是指軟件產(chǎn)品在公共環(huán)境中同與其分享公共資源的其他獨立軟件共存的能力。（2）可再現(xiàn)性：由不同評價者按同一評價規(guī)格說明對同一產(chǎn)品進行評價，應(yīng)產(chǎn)生同一種可接受的結(jié)果。（2）評價規(guī)格說明：確定對軟件及其部件實行的所有分析和測量，標識要分析和測量的軟件部件。（2）評價需求應(yīng)由GB/T16260中定義為“質(zhì)量特性”的一系列質(zhì)量需求組成，還可能用到一些子特性。評價執(zhí)行目的評價執(zhí)行目的是根據(jù)評價需求，按照評價規(guī)格說明中的規(guī)定和評價計劃，從對軟件產(chǎn)品的測量和驗證中獲得結(jié)果，執(zhí)行這些動作將完成評價報告和評價記錄的草稿。規(guī)定何時何人創(chuàng)立新的基線，如何創(chuàng)立。確定測試報告提交的時間與方式。測試人員的選擇測試人員的能力包括以下幾項：測試人員的能力包括以下幾項。”風(fēng)險分析是一個對潛在問題識別和評估的過程，即對測試的對象進行優(yōu)先級劃分。準備工作一般包括：硬件配置、軟件配置、測試環(huán)境建立，以及測試環(huán)境的確定等。非一致成本還包括外部故障（軟件遺留錯誤影響客戶）引起部分。 測試用例就是設(shè)計一個情況，軟件程序在這種情況下，必須能夠正常運行并且達到程序所設(shè)計的執(zhí)行結(jié)果。（2）測試用例的使用令軟件測試的實施重點突出、目的明確。等價類劃分是一種典型的黑盒測試方法，用這一方法設(shè)計測試用例完全不考慮程序的內(nèi)部結(jié)構(gòu)，只根據(jù)對程序的要求和說明，即需求規(guī)格說明書。有效等價類：指對程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)結(jié)構(gòu)的集合。（6）在確知已劃分的等價類中，各元素在程序處理中的方式不同的情況下，則應(yīng)再將該等價類進一步地劃分為更小的等價類。（3）根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則（1）。利用因果圖導(dǎo)出測試用例需要經(jīng)過以下幾個步驟：（1）分析程序規(guī)格說明的描述中，哪些是原因，哪些是結(jié)果。（5）為判定表中每一列表示的情況設(shè)計測試用例。動作項：列出在條件項的各種取值情況下應(yīng)該采取的動作。制定初始判定表。 正交試驗設(shè)計方法依據(jù)Galois理論，正交試驗設(shè)計方法是從大量的試驗數(shù)據(jù)中挑選適量的、有代表性的點，從而合理地安排測試的一種科學(xué)的試驗設(shè)計方法。一個結(jié)構(gòu)化的狀態(tài)遷移中，定義3種形式的循環(huán)：順序、選擇和重復(fù)。第6章白盒測試技術(shù)類型和單位分析引用分析表達式分析對表達式進行分析，以發(fā)現(xiàn)和糾正在表達式中出現(xiàn)的錯誤。正交試驗測試用例設(shè)計步驟利用正交試驗設(shè)計測試用例的步驟如下：提取功能說明，構(gòu)造因子“——”狀態(tài)表。合并相似規(guī)則或者相同動作。在判定表中貫穿也就有多少條規(guī)則，條件項和動作項就有多少列。判定表組成判定表是分析和表達多邏輯條件下執(zhí)行不同操作的情況的工具。（2）分析程序規(guī)格說明的描述中語義的內(nèi)容，并將其表示成連接各個原因與各個結(jié)果的“因果圖”。（5）如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例。（2）設(shè)計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。無效等價類：與有效等價類的定義恰巧相反。等價類劃分的辦法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。（4）功能模塊的通用化和復(fù)用化使軟件易于開發(fā)，而測試用例的通用化和復(fù)用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷率升。軟件開發(fā)人員接獲通知后，將這個問題修改完成于下一個測試版本內(nèi)，軟件測試工程師取得新的測試版本后，必須利用同一個用例來測試這個問題，確保該問題已修改完成。（DDP）（DDP Defect Detection Percentage）缺陷探測率DDP是另一個衡量測試工作效率的軟件質(zhì)量成本的指標。完全重新測試：部分重新測試：部分重新測試選擇方法有兩種：（1）對由于程序變化而受到影響的每一部分進行重新測試； （2）對與變化有密切和直接關(guān)系的部分進行重新測試。通常風(fēng)險分析采用兩種方法：表格分析法和矩陣分析法。測試人員的激勵（1）X理論+Y理論X理論：胡蘿卜+大棒——迫使人們工作；Y理論：經(jīng)理的職能不是督促人們工作，而是使人們有可能工作。確定審計的內(nèi)容與方式。確定變更請求的處理程序和終止條件。1）管理請求者提供的產(chǎn)品部件；2）管理評價動作所產(chǎn)生的數(shù)據(jù)（包括報告和記錄）；3）管理評價執(zhí)行動作的工具。認可與報告評價規(guī)格說明的目的評價規(guī)格說明編制編制評價規(guī)格說明的活動由下列3個子活動組成：（1）分析產(chǎn)品的描述（2）規(guī)定對產(chǎn)品及部件執(zhí)行的測量（3）按照評價需求驗證編制的規(guī)格說明評價規(guī)格說明的內(nèi)容評價規(guī)格說明應(yīng)包括：（1）評價范圍，涉及在產(chǎn)品說明中標識的產(chǎn)品硬件；（2）評價執(zhí)行所需的信息，在產(chǎn)品說明中列出的軟件部件及其他相關(guān)文檔之間的相互引用；（3）要執(zhí)行的測量和驗證的規(guī)格說明，以及對要評價的產(chǎn)品部件的引用；（4）測量的驗證的規(guī)格說明與評價需求之間，與引用標準或?qū)λ械拿總€測量或驗證的理由之間映射。（4）評價記錄：評價執(zhí)行計劃時詳細記載的動作組成；記錄由評價者保留。（4）客觀性：評價結(jié)果應(yīng)是客觀事實，即不帶有評價者的感情色彩或主觀意見。（5）可移植性依從性可移植性依從性是指軟件產(chǎn)品依附于同可移植性相關(guān)的標準或約定的能力。（1）易