集成測試

詞語解釋

集成測試是指在軟件開發(fā)過程中，將軟件的各個部分集成在一起，并進行測試的過程。它主要是為了檢查軟件的構(gòu)件之間是否能夠正確的連接在一起，以及檢查軟件的功能是否符合預期。集成測試在通信中的含義是，在軟件開發(fā)過程中，將軟件的各個部分集成在一起，并進行測試，以確保軟件的功能和性能能夠正常工作，以及軟件的構(gòu)件之間能夠正確的連接在一起。集成測試的應(yīng)用： 1、檢查軟件的功能：在集成測試中，可以檢查軟件的功能是否符合預期，以及檢查軟件的功能是否能夠正常工作。 2、檢查軟件的性能：在集成測試中，可以檢查軟件的性能，比如軟件的運行速度、內(nèi)存使用率、網(wǎng)絡(luò)傳輸速度等。 3、檢查軟件的構(gòu)件之間的連接：在集成測試中，可以檢查軟件的構(gòu)件之間是否能夠正確的連接在一起，以及檢查軟件的構(gòu)件之間的通信是否正常。 4、檢查軟件的穩(wěn)定性：在集成測試中，可以檢查軟件的穩(wěn)定性，即軟件在長時間運行后，是否能夠正常工作。集成測試是軟件開發(fā)過程中的一個重要環(huán)節(jié)，可以檢查軟件的功能、性能、構(gòu)件之間的連接以及軟件的穩(wěn)定性，確保軟件的正常工作。因此，集成測試在通信中具有重要的意義。

　　某設(shè)計人員習慣于把所有模塊按設(shè)計要求一次全部組裝起來，然后進行整體測試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因為測試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。
　　概述
　　集成測試，也叫組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求）如根據(jù)結(jié)構(gòu)圖〕組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現(xiàn)。
　　集成測試方法
　　集成測試應(yīng)該考慮以下問題：
　　1、在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；
　　2、各個子功能組合起來，能否達到預期要求的父功能；
　　3、一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；
　　4、全局數(shù)據(jù)結(jié)構(gòu)是否有問題；
　　5、單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度。
　　因此，單元測試后，有必要進行集成測試，發(fā)現(xiàn)并排除在模塊連接中可能發(fā)生的上述問題，最終構(gòu)成要求的軟件子系統(tǒng)或系統(tǒng)。對子系統(tǒng)，集成測試也叫部件測試。
　　任何合理地組織集成測試，即選擇什么方式把模塊組裝起來形成一個可運行的系統(tǒng),直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號和測試的次序、生成測試用例和調(diào)試的費用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。
　　集成測試的實施
　　集成測試是一種正規(guī)測試過程，必須精心計劃，并與單元測試的完成時間協(xié)調(diào)起來。在制定測試計劃時，應(yīng)考慮如下因素：
　　1、是采用何種系統(tǒng)組裝方法來進行組裝測試；
　　2、組裝測試過程中連接各個模塊的順序；
　　3、模塊代碼編制和測試進度是否與組裝測試的順序一致
　　4、測試過程中是否需要專門的硬件設(shè)備；
　　解決了上述問題之后，就可以列出各個模塊的編制、測試計劃表，標明每個模塊單元測試完成的日期、首次集成測試的日期、集成測試全部完成的日期、以及需要的測試用例和所期望的測試結(jié)果。
　　在缺少軟件測試所需要的硬件設(shè)備時，應(yīng)檢查該硬件的交付日期是否與集成測試計劃一致。例如，若測試需要數(shù)字化儀和繪圖儀，則相應(yīng)測試應(yīng)安排在這些設(shè)備能夠投入使用之時，并需要為硬件的安裝和交付使用保留一段時間，以留下時間余量。此外，在測試計劃中需要考慮測試所需軟件（驅(qū)動模塊、樁模塊、測試用例生成程序等）的準備情況。
　　集成測試完成標準
　　怎樣判定集成測試過程完成了, 可按以下幾個方面檢查:
　　1、成功地執(zhí)行了測試計劃中規(guī)定的所有集成測試；
　　2、修正了所發(fā)現(xiàn)的錯誤；
　　3、測試結(jié)果通過了專門小組的評審。
　　集成測試應(yīng)由專門的測試小組來進行，測試小組由有經(jīng)驗的系統(tǒng)設(shè)計人員和程序員組成。整個測試活動要在評審人員出席的情況下進行。
　　在完成預定的組裝測試工作之后，測試小組應(yīng)負責對測試結(jié)果進行整理、分析，形成測試報告。測試報告中要記錄實際的測試結(jié)果、在測試中發(fā)現(xiàn)的問題、解決這些問題的方法以及解決之后再次測試的結(jié)果。此外還應(yīng)提出目前不能解決、還需要管理人員和開發(fā)人員注意的一些問題，提供測試評審和最終決策，以提出處理意見。
　　集成測試
　　集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應(yīng)該成對測試它們，而不是同時測試所有進程。
　　集成測試識別組合單元時出現(xiàn)的問題。通過使用要求在組合單元前測試每個單元并確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發(fā)現(xiàn)的任何錯誤很可能與單元之間的接口有關(guān)。這種方法將可能發(fā)生的情況數(shù)量減少到更簡單的分析級別。
　　集成測試是在單元測試的基礎(chǔ)上，測試在將所有的軟件單元按照概要設(shè)計規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達到或?qū)崿F(xiàn)相應(yīng)技術(shù)指標及要求的活動。也就是說，在集成測試之前，單元測試應(yīng)該已經(jīng)完成，集成測試中所使用的對象應(yīng)該是已經(jīng)經(jīng)過單元測試的軟件單元。這一點很重要，因為如果不經(jīng)過單元測試，那么集成測試的效果將會受到很大影響，并且會大幅增加軟件單元代碼糾錯的代價。
　　集成測試是單元測試的邏輯擴展。在現(xiàn)實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統(tǒng)或系統(tǒng)。集成測試采用的方法是測試軟件單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最后，還要測試構(gòu)成系統(tǒng)的所有模塊組合能否正常工作。集成測試所持的主要標準是《軟件概要設(shè)計規(guī)格說明》，任何不符合該說明的程序模塊行為都應(yīng)該加以記載并上報。
　　所有的軟件項目都不能擺脫系統(tǒng)集成這個階段。不管采用什么開發(fā)模式，具體的開發(fā)工作總得從一個一個的軟件單元做起，軟件單元只有經(jīng)過集成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現(xiàn)一些常見問題，工程實踐中，幾乎不存在軟件單元組裝過程中不出任何問題的情況。從圖1可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統(tǒng)測試是極不妥當?shù)淖龇ā?
　　集成測試的必要性還在于一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現(xiàn)。此外，在某些開發(fā)模式中，如迭代式開發(fā)，設(shè)計和實現(xiàn)是迭代進行的。在這種情況下，集成測試的意義還在于它能間接地驗證概要設(shè)計是否具有可行性。
　　集成測試的目的是確保各單元組合在一起后能夠按既定意圖協(xié)作運行，并確保增量的行為正確。它所測試的內(nèi)容包括單元間的接口以及集成后的功能。使用黑盒測試方法測試集成的功能。并且對以前的集成進行回歸測試。
　　一、集成測試過程
　　二、單元測試工作內(nèi)容及其流程
　　三、集成測試需求獲取
　　集成測試需求所確定的是對某一集成工作版本的測試的內(nèi)容，即測試的具體對象。集成測試需求主要來源于設(shè)計模型（Design Model）和集成構(gòu)件計劃（Integration Build Plan）。集成測試著重于集成版本的外部接口的行為。因此，測試需求須具有可觀測、可測評性。
　　1．集成工作版本應(yīng)分析其類協(xié)作與消息序列，從而找出該工作版本的外部接口。
　　2．由集成工作版本的外部接口確定集成測試用例。
　　3．測試用例應(yīng)覆蓋工作版本每一外部接口的所有消息流序列。
　　注意：一個外部接口和測試用例的關(guān)系是多對多，部分集成工作版本的測試需求可映射到系統(tǒng)測試需求，因此對這些集成測試用例可采用重用系統(tǒng)測試用例技術(shù)。
　　四、集成測試工作機制
　　軟件集成測試工作由產(chǎn)品評測部擔任。需要項目組相關(guān)角色配合完成。如圖示：
　　軟件評測部：
　　軟件項目組：
　　集成測試工作內(nèi)容及其流程工作流程：
　　五、集成測試產(chǎn)生的工件清單
　　1、軟件集成測試計劃
　　2、集成測試用例
　　3、測試過程
　　4、測試腳本
　　5、測試日志
　　6、測試評估摘要
　　六、集成測試常用方案選型
　　集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基于使用的集成測試等。在此，筆者將重點討論其中一些經(jīng)實踐檢驗和一些證實有效的集成測試方案。
　　&＃8226;自底向上集成測試
　　自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程序模塊結(jié)構(gòu)中最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝的，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）事前已經(jīng)完成組裝并經(jīng)過測試，所以不再需要編制樁模塊（一種能模擬真實模塊，給待測模塊提供調(diào)用接口或數(shù)據(jù)的測試用軟件模塊）。自底向上集成測試的步驟大致如下:
　　步驟一: 按照概要設(shè)計規(guī)格說明，明確有哪些被測模塊。在熟悉被測模塊性質(zhì)的基礎(chǔ)上對被測模塊進行分層，在同一層次上的測試可以并行進行，然后排出測試活動的先后關(guān)系，制定測試進度計劃。圖2給出了自底向上的集成測試過程中各測試活動的拓撲關(guān)系。利用圖論的相關(guān)知識，可以排出各活動之間的時間序列關(guān)系，處于同一層次的測試活動可以同時進行，而不會相互影響。
　　步驟二: 在步驟一的基礎(chǔ)上，按時間線序關(guān)系，將軟件單元集成為模塊，并測試在集成過程中出現(xiàn)的問題。這里，可能需要測試人員開發(fā)一些驅(qū)動模塊來驅(qū)動集成活動中形成的被測模塊。對于比較大的模塊，可以先將其中的某幾個軟件單元集成為子模塊，然后再集成為一個較大的模塊。
　　步驟三: 將各軟件模塊集成為子系統(tǒng)（或分系統(tǒng)）。檢測各自子系統(tǒng)是否能正常工作。同樣，可能需要測試人員開發(fā)少量的驅(qū)動模塊來驅(qū)動被測子系統(tǒng)。
　　步驟四: 將各子系統(tǒng)集成為最終用戶系統(tǒng)，測試是否存在各分系統(tǒng)能否在最終用戶系統(tǒng)中正常工作。
　　方案點評: 自底向上的集成測試方案是工程實踐中最常用的測試方法。相關(guān)技術(shù)也較為成熟。它的優(yōu)點很明顯: 管理方便、測試人員能較好地鎖定軟件故障所在位置。但它對于某些開發(fā)模式不適用，如使用XP開發(fā)方法，它會要求測試人員在全部軟件單元實現(xiàn)之前完成核心軟件部件的集成測試。盡管如此，自底向上的集成測試方法仍不失為一個可供參考的集成測試方案。
　　&＃8226;核心系統(tǒng)先行集成測試
　　核心系統(tǒng)先行集成測試法的思想是先對核心軟件部件進行集成測試，在測試通過的基礎(chǔ)上再按各外圍軟件部件的重要程度逐個集成到核心系統(tǒng)中。每次加入一個外圍軟件部件都產(chǎn)生一個產(chǎn)品基線，直至最后形成穩(wěn)定的軟件產(chǎn)品。核心系統(tǒng)先行集成測試法對應(yīng)的集成過程是一個逐漸趨于閉合的螺旋形曲線，代表產(chǎn)品逐步定型的過程。其步驟如下:
　　步驟一: 對核心系統(tǒng)中的每個模塊進行單獨的、充分的測試，必要時使用驅(qū)動模塊和樁模塊;
　　步驟二: 對于核心系統(tǒng)中的所有模塊一次性集合到被測系統(tǒng)中，解決集成中出現(xiàn)的各類問題。在核心系統(tǒng)規(guī)模相對較大的情況下，也可以按照自底向上的步驟，集成核心系統(tǒng)的各組成模塊。
　　步驟三: 按照各外圍軟件部件的重要程度以及模塊間的相互制約關(guān)系，擬定外圍軟件部件集成到核心系統(tǒng)中的順序方案。方案經(jīng)評審以后，即可進行外圍軟件部件的集成。
　　步驟四: 在外圍軟件部件添加到核心系統(tǒng)以前，外圍軟件部件應(yīng)先完成內(nèi)部的模塊級集成測試。
　　步驟五: 按順序不斷加入外圍軟件部件，排除外圍軟件部件集成中出現(xiàn)的問題，形成最終的用戶系統(tǒng)。
　　方案點評: 該集成測試方法對于快速軟件開發(fā)很有效果，適合較復雜系統(tǒng)的集成測試，能保證一些重要的功能和服務(wù)的實現(xiàn)。缺點是采用此法的系統(tǒng)一般應(yīng)能明確區(qū)分核心軟件部件和外圍軟件部件，核心軟件部件應(yīng)具有較高的耦合度，外圍軟件部件內(nèi)部也應(yīng)具有較高的耦合度，但各外圍軟件部件之間應(yīng)具有較低的耦合度。
　　&＃8226;高頻集成測試
　　高頻集成測試是指同步于軟件開發(fā)過程，每隔一段時間對開發(fā)團隊的現(xiàn)有代碼進行一次集成測試。如某些自動化集成測試工具能實現(xiàn)每日深夜對開發(fā)團隊的現(xiàn)有代碼進行一次集成測試，然后將測試結(jié)果發(fā)到各開發(fā)人員的電子郵箱中。該集成測試方法頻繁地將新代碼加入到一個已經(jīng)穩(wěn)定的基線中，以免集成故障難以發(fā)現(xiàn)，同時控制可能出現(xiàn)的基線偏差。使用高頻集成測試需要具備一定的條件: 可以持續(xù)獲得一個穩(wěn)定的增量，并且該增量內(nèi)部已被驗證沒有問題; 大部分有意義的功能增加可以在一個相對穩(wěn)定的時間間隔（如每個工作日）內(nèi)獲得; 測試包和代碼的開發(fā)工作必須是并行進行的，并且需要版本控制工具來保證始終維護的是測試腳本和代碼的最新版本; 必須借助于使用自動化工具來完成。高頻集成一個顯著的特點就是集成次數(shù)頻繁，顯然，人工的方法是不勝任的。
　　高頻集成測試一般采用如下步驟來完成:
　　步驟一: 選擇集成測試自動化工具。如很多Java項目采用Junit+Ant方案來實現(xiàn)集成測試的自動化，也有一些商業(yè)集成測試工具可供選擇。
　　步驟二: 設(shè)置版本控制工具，以確保集成測試自動化工具所獲得的版本是最新版本。如使用CVS進行版本控制。
　　步驟三: 測試人員和開發(fā)人員負責編寫對應(yīng)程序代碼的測試腳本。
　　步驟四: 設(shè)置自動化集成測試工具，每隔一段時間對配置管理庫的新添加的代碼進行自動化的集成測試，并將測試報告匯報給開發(fā)人員和測試人員。
　　步驟五: 測試人員監(jiān)督代碼開發(fā)人員及時關(guān)閉不合格項。
　　按照步驟三至步驟五不斷循環(huán)，直至形成最終軟件產(chǎn)品。
　　方案點評: 該測試方案能在開發(fā)過程中及時發(fā)現(xiàn)代碼錯誤，能直觀地看到開發(fā)團隊的有效工程進度。在此方案中，開發(fā)維護源代碼與開發(fā)維護軟件測試包被賦予了同等的重要性，這對有效防止錯誤、及時糾正錯誤都很有幫助。該方案的缺點在于測試包有時候可能不能暴露深層次的編碼錯誤和圖形界面錯誤。
　　以上我們介紹了幾種常見的集成測試方案，一般來講，在現(xiàn)代復雜軟件項目集成測試過程中，通常采用核心系統(tǒng)先行集成測試和高頻集成測試相結(jié)合的方式進行，自底向上的集成測試方案在采用傳統(tǒng)瀑布式開發(fā)模式的軟件項目集成過程中較為常見。讀者應(yīng)該結(jié)合項目的實際工程環(huán)境及各測試方案適用的范圍進行合理的選型。
　　附：集成測試計劃書模版
　　原創(chuàng)作者：jerry
　　轉(zhuǎn)載請注明：來自Sawin系統(tǒng)分析之窗
　　最后修改時間：2005-4-27
　　1引言
　　1.1編寫目的
　　本文是描述****集成測試的大綱文章，主要描述如何進行集成測試活動？如何控制集成測試活動？集成測試活動的流程以及集成測試活動的工作安排。本文主要的讀者對象是項目負責人，集成部門經(jīng)理，集成測試設(shè)計師。
　　1.2背景
　　項目名稱：***集成測試
　　項目相關(guān)對象：******************
　　1.3定義
　　**********：********************
　　1.4參考資料
　　《*********》
　　2測試項目
　　本測試主要為***系統(tǒng)的集成測試，目前***的版本為2.0,測試是***的最終集成測試，是建立在開發(fā)組程序員開發(fā)完畢自己的測試以及開發(fā)組測試的基礎(chǔ)之上
　　3 被測特性
　　3.1操作性測試
　　主要測試操作是否正確，有無誤差？分為兩部分：
　　3.1.1返回測試
　　由主界面逐級進入最終界面，按EXIT鍵逐級返回，檢查返回時候屏幕聚焦是否正確
　　比如：
　　1. 進入“系統(tǒng)設(shè)置”
　　2. 進入“頻道搜索”
　　3. 進入“自動頻道搜索”
　　4. 按EXIT鍵返回，檢查當前聚焦是否為“頻道搜索”
　　5. 按EXIT鍵返回，檢查當前聚焦是否為“系統(tǒng)設(shè)置”
　　3.1.2進入測試
　　由主界面逐級進入最終界面，按MENU鍵返回主界面，再次進入，檢查是否聚焦正確
　　比如：
　　1. 進入“系統(tǒng)設(shè)置”
　　2. 進入“頻道搜索”
　　3. 進入“自動頻道搜索”
　　4. 按MENU鍵返回主界面
　　5. 當前聚焦是否為“系統(tǒng)設(shè)置”
　　6. 進入“系統(tǒng)設(shè)置”，當前聚焦是否為“頻道搜索”
　　3.2功能測試
　　測試機頂盒中每個應(yīng)用的功能是否正確
　　3.3性能測試
　　3.3.1疲勞性測試
　　測試連續(xù)開機1個月不關(guān)機器，每3天去運行一次應(yīng)用�？聪到y(tǒng)的穩(wěn)定性
　　3.3.2大容量數(shù)據(jù)測試
　　前段***數(shù)據(jù)庫表中含有大量數(shù)據(jù)，測試***功能
　　4 不被測特性
　　5 測試方法
　　1. 書寫測試計劃
　　2. 審核測試計劃，未通過返回第一步
　　3. 書寫測試用例；
　　4. 審核測試用例，未通過返回第三步
　　5. 測試人員按照測試用例逐項進行測試活動,并且將測試結(jié)果填寫在測試報告上；（測試報告必須覆蓋所有測試用例）
　　6. 測試過程中發(fā)現(xiàn)bug，將bug填寫在bugzilla上發(fā)給集成部經(jīng)理；（bug狀態(tài)NEW）
　　7. 集成部經(jīng)理接到bugzilla發(fā)過來的bug
　　7.1 對于明顯的并且可以立刻解決的bug，將bug發(fā)給開發(fā)人員；（bug狀態(tài)ASSIGNED）;
　　7.2 對于不是bug的提交，集成部經(jīng)理通知測試設(shè)計人員和測試人員，對相應(yīng)文檔進行修改; （bug狀態(tài)RESOLVED，決定設(shè)置為INVALID）;
　　7.3 對于目前無法修改的,將這個bug放到下一輪次進行修改；（bug狀態(tài)RESOLVED，決定設(shè)置為REMIND）
　　8. 開發(fā)人員接到發(fā)過來的bug立刻修改;（bug狀態(tài)RESOLVED，決定設(shè)置為FIXED）
　　9. 測試人員接到bugzilla發(fā)過來的錯誤更改信息，應(yīng)該逐項復測，填寫新的測試報告（測試報告必須覆蓋上一次中所有REOPENED的測試用例）；
　　10. 如果復測有問題返回第六步（bug狀態(tài)REOPENED）
　　11. 否則關(guān)閉這項BUG（bug狀態(tài)CLOSED）
　　12. 本輪測試中測試用例中有95%一次性通過測試,結(jié)束測試任務(wù)；
　　13. 本輪測試中發(fā)現(xiàn)的錯誤有98%經(jīng)過修改并且通過再次測試（即bug狀態(tài)CLOSED），返回第五步進行新的一輪測試；
　　14. 測試任務(wù)結(jié)束后書寫測試總結(jié)報告；
　　15. 正規(guī)測試結(jié)束進入非正規(guī)測試，首先是ALPHA測試，請公司里其他非技術(shù)人員以用戶角色使用系統(tǒng)。發(fā)現(xiàn)bug通知測試人員，測試人員以正規(guī)流程處理bug事件；
　　16. 然后是BETA測試，請用戶代表進行測試。發(fā)現(xiàn)bug通知測試人員，測試人員以正規(guī)流程處理bug事件。
　　幾點說明：
　　O 測試回歸計劃為三次；
　　O 測試用例應(yīng)該寫得比較詳盡，步驟一定要標明清楚（應(yīng)該包括：編號，測試描述，前置條件，測試步驟以及測試希望結(jié)果）；
　　O 對于測試人員覺得應(yīng)該進行的測試項目，測試人員應(yīng)該報告測試設(shè)計人員，完善和健全測試用例；
　　O 測試報告與測試用例分開，測試報告標明測試用例序號以及是否通過Y/N；
　　O 對于集成部經(jīng)理無法決定的上交項目負責人決定；
　　O 性能測試中的疲勞性測試可以結(jié)合在功能測試部分，即測試期間不關(guān)閉機器；
　　O 性能測試中的大容量數(shù)據(jù)測試放在測試后部分輪次（第二步，只需要進行一次）
　　6 測試通過標準
　　測試結(jié)果與測試用例中期望的結(jié)果一致，測試通過，否則標明測試未通過。
　　6.1測試結(jié)果審批過程
　　6.1.1測試回歸申請結(jié)束
　　測試人員提出申請這輪測試結(jié)束，提交集成部經(jīng)理；
　　集成部經(jīng)理召集本組人員開會討論；
　　討論通過，進行下一輪測試，并且部署下一輪測試的注意事項，流程等內(nèi)容；
　　如果發(fā)現(xiàn)這輪測試目前還存在問題沒有解決，延期下一輪測試時間，討論下一步工作應(yīng)該如何進行。
　　6.1.2測試結(jié)果申請結(jié)束
　　測試人員提出申請測試結(jié)束，提交集成部經(jīng)理；
　　集成部經(jīng)理召集本組人員開會討論；
　　1. 討論通過，結(jié)束測試任務(wù)；
　　2. 如果發(fā)現(xiàn)目前測試還存在問題沒有解決，延期測試結(jié)束時間，并且討論下一步工作應(yīng)該如何進行。
　　7 測試掛起和恢復條件
　　7.1掛起條件
　　O 進入第一輪測試，測試人員大體了解一下產(chǎn)品情況，如果在一小時之內(nèi)發(fā)現(xiàn)５個以上（含５個）操作性錯誤，或者３個以上（含３個）功能性錯誤，退回測試組測試；
　　O 遇到有項目優(yōu)先級更高的集成測試任務(wù)；
　　O 遇到有項目優(yōu)先級更高的集成任務(wù)；
　　O 在測試復測過程中發(fā)現(xiàn)產(chǎn)品無法運行下去；
　　O 人員，設(shè)備不足。
　　7.2恢復條件
　　O 符合進入集成測試條件（一小時之內(nèi)發(fā)現(xiàn)５個以下（不含５個）操作性錯誤，或者３個以下（不含３個）功能性錯誤）；
　　O 項目優(yōu)先級更高的集成測試任務(wù)暫告完成；
　　O 項目優(yōu)先級更高的集成任務(wù)暫告完成；
　　O 復測過程中產(chǎn)品可以運行下去；
　　O 人員，設(shè)備到位。
　　8應(yīng)提供的測試文件
　　O 測試計劃書
　　O 測試用例
　　O 測試報告
　　O 測試總結(jié)
　　9測試任務(wù)
　　O 制定審核測試計劃
　　O 制定和審核測試用例
　　O 進行測試活動
　　O 書寫測試報告
　　10測試環(huán)境需求
　　10.1硬件需求
　　***********
　　10.2軟件需求
　　************
　　10.3測試工具
　　*************
　　10.4測試需要的條件
　　**************
　　10.4.1 需要的文檔
　　O 用戶手冊
　　O 應(yīng)用手冊
　　O 安裝說明
　　10.4.2需要完成的任務(wù)
　　O 程序員本人測試
　　O 測試組完成測試
　　11角色和職責
　　O 集成（測試）經(jīng)理：控制并完成測試任務(wù)和測試過程，決定測試人員提交上來的bug是否需要修改；
　　O 測試設(shè)計人員：書寫集成測試用例；
　　O 測試人員：按照測試用例進行測試活動；
　　O 開發(fā)人員：MHP程序bug修改；
　　O 用戶代表：進行BETA測試。
　　12 人員和培訓
　　O 集成測試經(jīng)理有責任對測試相關(guān)人員進行測試流程，規(guī)章制度培訓；
　　O 測試設(shè)計人員有責任對測試人員進行測試操作培訓
　　13 測試進度
　　測試工作進度(人＊工作日)
　　測試計劃８
　　測試設(shè)計 60
　　測試執(zhí)行總共進度 30
　　每次回歸進度 10
　　測試報告２
　　14風險及應(yīng)急計劃
　　設(shè)備不到位:加緊設(shè)備購買;
　　人員不到位
　　人員請假：請假人員回來加班或趕緊測試進度／申請調(diào)配新的人員；
　　人員離職：調(diào)配新的人員；
　　人員調(diào)配到其他部門或項目：調(diào)配新的人員；
　　開發(fā)人員開發(fā)頻頻出錯：通知開發(fā)部門，商量策略；
　　其他原因的測試工作頻頻被掛起或者掛起后遲遲恢復不了：加班或延期
　　15審批
　　集成部經(jīng)理技術(shù)部經(jīng)理
　　姓名：姓名：
　　日期：日期：

掃碼付費即可復制

集成測試

集成測試

相關(guān)討論貼

相關(guān)資料下載

隨機推薦詞語