時間：2022-09-19 06:54:33
開篇：寫作不僅是一種記錄，更是一種創(chuàng)造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇測試計劃，希望這些內(nèi)容能成為您創(chuàng)作過程中的良師益友，陪伴您不斷探索和進步。
作為軟件的重要環(huán)節(jié)，軟件測試越來越受到人們的重視。隨著軟件開發(fā)規(guī)模的增大、復(fù)雜程度的增加，以尋找軟件中的錯誤為目的的測試工作就顯得更加困難。然而，為了盡可能多地找出中的錯誤，生產(chǎn)出高的軟件產(chǎn)品，加強對測試工作的組織和管理就顯得尤為重要。
從軟件的生存周期看，測試往往指對程序的測試，這樣做的優(yōu)點是被測對象明確，測試的可作相對較強。但是，由于測試的依據(jù)是規(guī)格說明書、文檔和使用說明書，如果設(shè)計有錯誤，測試的質(zhì)量就難以保證。即使測試后發(fā)現(xiàn)是設(shè)計的錯誤，這時，修改的代價是相當昂貴的。因此，較理想的做法應(yīng)該是對軟件的開發(fā)過程，按軟件工程各階段形成的結(jié)果，分別進行嚴格的審查。軟件的生命周期可用圖1的表示。
為了確保軟件的質(zhì)量，對圖1的過程應(yīng)進行嚴格的管理。雖然測試是在實現(xiàn)且證后進行的，實際上，測試的準備工作在分析和設(shè)計階段就開始了。
軟件測試計劃作為軟件項目計劃的子計劃，在項目啟動初期是必須規(guī)劃的。在越來越多公司的軟件開發(fā)中，軟件質(zhì)量日益受到重視，測試過程也從一個相對獨立的步驟越來越緊密嵌套在軟件整個生命周期中，這樣，如何規(guī)劃整個項目周期的測試工作；如何將測試工作上升到測試管理的高度都依賴于測試計劃的制定。測試計劃因此也成為測試工作的賴于展開的基礎(chǔ)。
一個好的測試計劃可以起到如下作用
1. 避免測試的“事件驅(qū)動”
2. 使測試工作和整個開發(fā)工作融合起來
3. 資源和變更事先作為一個可控制的風險項目經(jīng)理圈子
測試計劃的模板在各個公司中都大同小異，在個人實踐中發(fā)現(xiàn)，測試計劃制定中存在的問題具有相似，下面重點就這些相似的問題談?wù)勅绾沃贫ㄜ浖椖繙y試計劃。
問題一：測試階段劃分
就通常軟件項目而言，基本上采用“瀑布型開發(fā)方式，這種開發(fā)方式下，各個項目主要活動比較清晰。整個項目生命周期為需設(shè)計編測試實施維護。然而，在制定測試計劃時候，有些測試經(jīng)理對測試的階段劃分還不是十分明晰，經(jīng)常*遇到的問題是把測試單純理解成系統(tǒng)測試，或者把把各類型測試設(shè)計（測試用例的編寫和測試數(shù)據(jù)準備）全部放入生命周期的“測試階段”，這樣造成的問題是浪費了開發(fā)階段可以并行的項目日程，另一方面造成測試不足。
相應(yīng)階段可以同步進行相應(yīng)的測試計劃編制，而測試設(shè)計也可以結(jié)合在開發(fā)過程中實現(xiàn)并行，測試的實施即執(zhí)行測試的活動即可連貫在開發(fā)之后。值得注意的是：單元測試和集成測試往往由開發(fā)人員承擔，因此這部分的階段劃分可能會安排在開發(fā)計劃而不是測試計劃中。
問題二：系統(tǒng)測試階段日程安排
劃分階段清楚了，隨之而來的問題是測試執(zhí)行需要多長的時間？標準的工程方法或CMM方式是對工作量進行估算，然后得出具體的估算值。但是這種方法過于復(fù)雜，可以另辟專題討論。一個可作的簡單方法是：根據(jù)測試執(zhí)行上一階段的活動時間進行換算，換算方法是與上一階段活動時間1：1.1～1.5左右。舉個例子，對測試經(jīng)理來說，因為開發(fā)計劃可能包含了單元測試和集成測試，系統(tǒng)測試的時間大概是編*階段（包含單元測試和集成測試）1到1.5倍。這種方法的優(yōu)點是簡單，依賴于項目計劃的日程安排，缺點是水分太多，難于量化。那么，可以采用的另一個簡單方法是經(jīng)驗評估。評估方法如下：項目管理者聯(lián)盟文章
1. 計算需求文檔的頁數(shù)，得出系統(tǒng)測試用例的頁數(shù)
需求頁數(shù)：系統(tǒng)測試用例頁數(shù)≈ 1：1
2. 由系統(tǒng)測試用例頁數(shù)計算編寫系統(tǒng)測試用例時間轉(zhuǎn)自項目管理者聯(lián)盟
編寫系統(tǒng)測試用例時間≈系統(tǒng)測試用例頁數(shù)×1小時
3. 計算執(zhí)行系統(tǒng)測試用例時間
編寫系統(tǒng)用例用時：執(zhí)行系統(tǒng)測試用時≈ 1：
4. 計算回歸測試包含的時間項目經(jīng)理博客
系統(tǒng)測試用時：回歸測試用時≈ 2：1
注：以上比值是個人工程經(jīng)驗值，需要更正比值的測試經(jīng)理可以在具體實踐中收集數(shù)據(jù)
基于以上方法優(yōu)點是需求為已知的，可以利用已知來推算未知，適用于需求是已知且相對穩(wěn)定的情況下；缺點是處于研發(fā)狀態(tài)的項目，需求不清晰的時候比較難計算。現(xiàn)套用一個例子加于說明：需求文檔頁數(shù)為500，系統(tǒng)測試用例頁數(shù)推算為500，則編寫系統(tǒng)測試用例時間為500小時，執(zhí)行系統(tǒng)測試用例時間為1000小時，回歸測試需要500小時，加起來總共為2000小時，按一天8小時計算，共計250個工作日/人；假如一個月為22個工作日，則共計約11人/月，即投入4個人需要3個月左右時間工作量完成。當然，這是系統(tǒng)測試需要的全部時間。根據(jù)測試階段劃分原則，設(shè)計用例時間可以和開發(fā)同步進行，只需在測試階段中安排的時間為1500小時即4人2個月工作量。
項目管理培訓(xùn)
（測試經(jīng)理在編寫測試計劃時候，測試進度中的計劃開始/結(jié)束時間往往用如20050101-20051201的具體時間劃分方式，這樣引起的問題是當項目計劃進行變更的時候，測試計劃時間不得不隨時調(diào)整，這種變更可能是頻繁而瑣碎的，可以替代的辦法是取消這種方式，采用30工作日/2人或者2人月這種工作量記錄方式，這樣一來，只需在項目計劃中跟蹤階段的具體開始時間即可，不必反復(fù)修改測試計劃。）
項目管理培訓(xùn)
值得注意的是：國內(nèi)大多數(shù)公司的測試時間都是不足的，不可能按照這樣的理想比例進行運作，因為測試執(zhí)行的時間實際上不可能占據(jù)整個項目周期的1/2，甚至要短于其中任何一個項目階段時間。即使是微軟的測試結(jié)束原則也并不是完成所有必需的測試，而是測試在按計劃結(jié)束的那一天結(jié)束！在測試時間不足的情況下，可參考下面項目計劃變更時的做法，因為計劃變更也涉及到測試時間不足的情況。
參考文獻：
[1]徐新海；林宇斐；易偉；；CPU-GPGPU異構(gòu)體系結(jié)構(gòu)相關(guān)技術(shù)綜述[J]；計算機工程與科學；2009年S1期
下面，筆者就通過具體案例為大家介紹ISTA標準在速凍食品運輸包裝測試中的成功應(yīng)用。
速凍食品的運輸安全問題
速凍食品是指將需速凍的食品經(jīng)適當?shù)那捌陬A(yù)處理后，在急速低溫（一般指–18℃以下）的環(huán)境下加工而成的凍結(jié)食品，其最大的特點是可以完全在低溫環(huán)境中維持食品原有的品質(zhì)，最大限度地保存食品的營養(yǎng)成分，而無須借助任何防腐劑或添加劑。
速凍食品的產(chǎn)銷過程可以簡單地概括為：加工、包裝、儲存、運輸、倉儲、銷售。在整個過程中都要保證速凍食品處于連貫的低溫環(huán)境（一般為–18～–20℃），不同種類的食品具有不同的低溫要求。
然而，對于速凍食品的包裝及運輸過程，往往很難保證其全程處于連貫的低溫環(huán)境，尤其是在轉(zhuǎn)移和搬運過程中，極可能造成速凍食品在一段時間內(nèi)發(fā)生解凍，從而導(dǎo)致速凍食品表面出現(xiàn)水氣凝露、食品軟化等現(xiàn)象；而當速凍食品再次置于低溫環(huán)境中時，水氣凝露就會在速凍食品表面凍結(jié)形成冰霜，解凍時間越長，冰霜就越多。這樣反復(fù)多次的解凍、凍結(jié)，很容易滋生細菌，從而產(chǎn)生速凍食品的衛(wèi)生安全問題，進而對人體健康造成傷害。
解凍是速凍食品在轉(zhuǎn)移和搬運過程中產(chǎn)生的常見現(xiàn)象之一，也是對速凍食品造成衛(wèi)生安全危害的主要過程之一，因為其容易使速凍食品遭受沖擊、振動、壓力等多種環(huán)境危害，如硬質(zhì)速凍食品容易出現(xiàn)斷裂、裂縫等情況；速凍食品軟化后容易在食品之間、食品與包裝之間產(chǎn)生粘連現(xiàn)象等。
速凍食品運輸包裝的測試要求
對速凍食品運輸包裝進行安全測試之前，首先要對速凍食品的實際運輸環(huán)境進行充分分析，從而判斷需要進行哪種單項測試。
在分析速凍食品的實際運輸環(huán)境時，不能忽略速凍食品運輸包裝的轉(zhuǎn)移和搬運過程，如果將連貫的低溫環(huán)境定義為“凍”的過程，將搬運過程定義為“化”的過程，那么速凍食品的實際運輸環(huán)境可以簡單地描述為：凍（生產(chǎn)倉儲）化（搬運）凍（運輸配送）化（搬運）凍（賣場銷售）的過程。
凍、化過程的反復(fù)轉(zhuǎn)換容易產(chǎn)生冰霜，而對于瓦楞紙箱而言，濕度的變化又會造成瓦楞紙箱性能的衰減，所以需對瓦楞紙箱進行抗壓測試。
運輸和搬運過程中會因振動、跌落或沖擊等對運輸包裝造成危害，所以對速凍食品進行相關(guān)的振動或跌落測試也是很有必要的。
案例解析：速凍湯圓運輸包裝
賣場銷售的速凍湯圓的包裝形式主要有兩種：一是袋內(nèi)散裝包裝，二是袋內(nèi)配有吸塑盤的包裝。速凍湯圓通常是定點生產(chǎn)，然后向全國范圍內(nèi)分銷，最后在各大賣場中進行零售。從包裝到銷售，速凍湯圓一般要經(jīng)歷如下過程：冷凍儲存、出貨裝卸、冷藏車運輸、收貨裝卸、冷凍儲存、出貨裝卸、冷藏車運輸分銷、賣場收貨裝卸、賣場上架。為保證速凍湯圓在這一過程中的衛(wèi)生安全，就需要對其運輸包裝進行嚴格的包裝測試。
1.測試對象
本次案例選取了某公司生產(chǎn)的系列速凍湯圓作為測試對象，其單箱瓦楞紙箱尺寸為415mm×320mm×200mm，毛重為10.46kg，單箱產(chǎn)品數(shù)量為24袋，單袋產(chǎn)品重量為400g，包裝形式為塑料袋散裝（如圖1）。運輸倉儲過程直接采用包裝箱堆碼，不采用托盤堆放。
2.測試標準
國際安全運輸協(xié)會（ISTA）除了根據(jù)產(chǎn)品或行業(yè)特點制定了一系列包裝測試標準外，還專門針對一些特殊產(chǎn)品及其特定的運輸環(huán)境建立了一個網(wǎng)絡(luò)在線互動標準，即ISTA Project 4AB標準，目前該標準僅為ISTA會員開發(fā)。ISTA 4AB標準的主要功能及使用要求如下。
(1)可以根據(jù)用戶輸入的參數(shù)自行生成實驗室測試計劃或方案，主要包括產(chǎn)品描述、包裝說明、運輸分配順序等內(nèi)容。
(2)要求用戶詳細定義與描述目標產(chǎn)品的分配運輸情況，如裝卸、運輸、倉儲的情況以及與環(huán)境條件的疊加情況。
(3)借助ISTA標準所構(gòu)建的后臺數(shù)據(jù)庫，通過計算機分析處理完成最終定義的測試計劃或方案。
3.測試計劃編制
進入ISTA Project 4AB標準測試計劃在線互動中心（如圖2）后，首先輸入速凍湯圓及其運輸包裝的相關(guān)信息；然后將運輸過程分解為“倉儲搬運運輸搬運倉儲搬運運輸搬運倉儲”9個環(huán)節(jié)，并分別輸入相關(guān)信息，運輸過程的各項參數(shù)如表1所示；最后按照ISTA Project 4AB標準得到速凍湯圓運輸包裝測試計劃。
4.測試驗證
速凍湯圓運輸包裝測試的整個過程均需在相應(yīng)的環(huán)境下完成相關(guān)測試項目，單項測試采用的測試方法如下。
(1)模擬運輸過程中的低溫冷凍環(huán)境，采用溫濕度環(huán)境處理箱對速凍湯圓進行低溫處理。
(2)對單箱速凍湯圓進行常溫和低溫冷凍處理后，再對空箱進行抗壓測試。
(3)對低溫冷凍處理后的單箱速凍湯圓，按要求完成跌落測試。
(4)對單箱速凍湯圓進行振動測試。由于振動測試是一個長時間的持續(xù)過程，并要求在低溫環(huán)境下完成測試過程，所以需要采用干冰對速凍湯圓外包裝進行低溫處理，以盡可能模擬持續(xù)低溫下的振動測試條件，同時采用配重進行振動加載模擬測試。
5.測試結(jié)果
完成上述測試后，經(jīng)檢查未發(fā)現(xiàn)速凍湯圓包裝袋有破損情況，表明該批速凍湯圓運輸包裝達到了速凍食品運輸包裝測試標準的要求。
通過上述案例的解析過程可以得知，速凍食品生產(chǎn)企業(yè)在選擇其產(chǎn)品運輸包裝測試標準時需要對產(chǎn)品的運輸環(huán)境進行充分了解，然后再利用ISTA Project 4AB標準測試計劃在線互動中心獲得可供參考的測試計劃，此外還要結(jié)合企業(yè)的實際情況及對產(chǎn)品運輸包裝的要求，制定一套企業(yè)獨有的運輸包裝測試標準，同時對產(chǎn)品的運輸環(huán)境進行監(jiān)控與調(diào)整，以確保測試標準符合實際的運輸環(huán)境要求。
小貼士
目前，涉及到速凍食品運輸包裝測試的相關(guān)規(guī)程和標準主要包括：1997年我國頒布的SN/T 0715-1997《出口冷凍食品類商品運輸包裝檢驗規(guī)程》以及2010年國際安全運輸協(xié)會（ISTA）頒布的ISTA 6-SAMSCLUB標準。
1測試流程不合理
1.1測試設(shè)計重點偏離使用QC軟件測試發(fā)現(xiàn)bug統(tǒng)計，如表1所示。根據(jù)表1工作量統(tǒng)計，25人/日為5個中級測試工程師一周的工作量，但是根據(jù)測試用例發(fā)現(xiàn)的bug數(shù)量僅占bug總量的44.18%，該比例顯示測試用例的設(shè)計重點嚴重出現(xiàn)偏離。需要在測試用例設(shè)計的方向上進行調(diào)整。
1.2測試過程不可控QC軟件測試計劃中測試執(zhí)行階段為2013.3.8-2013.3.27，執(zhí)行三輪測試；實際測試時間為2013.3.23-2013.4.20，執(zhí)行測試三輪，計劃完成時間嚴重偏離，表2為原計劃與實際計劃的對比。表2顯示測試計劃進行了較大調(diào)整，計劃截止時間比原計劃延遲23天。延遲原因經(jīng)分析主要為開發(fā)提交測試時間延遲，開發(fā)提交版本問題較多，測試計劃安排不合理，在兩輪測試間為安排開發(fā)修改bug時間等。想要解決該問題，不僅需要對測試過程進行管理，同時也需要對開發(fā)提交的測試版本質(zhì)量進行管理。
2軟件質(zhì)量管理改進對策
2.1需求工程管理軟件開發(fā)過程中，需求不明確會帶來需求的頻繁變更，浪費了很多時間。針對此項問題，可對需求相關(guān)的活動進行統(tǒng)一管理，其需求管理結(jié)構(gòu)圖如圖2所示。加強需求開發(fā)和需求管理的有機結(jié)合，不僅減少了需求的變更次數(shù)，還解決了工程師對需求不能理解到位的問題。需求開發(fā)和需求管理同樣重要，只有兩者互相配合才能做出用戶滿意的產(chǎn)品。
2.2立項管理為了使有限的資源發(fā)揮更高的價值，公司可通過立項管理流程進行立項管理，立項管理流程分為立項建議、立項評審和立項籌備三個階段，其具體流程圖3所示。
2.3測試流程管理針對測試流程中發(fā)現(xiàn)的問題，可對整體的測試流程做如下的改變：（1）測試部門可進行需求學習及需求討論，對理解不清楚及有疑問的需求，由研發(fā)設(shè)計部門進行解答，研發(fā)設(shè)計部門不能解答的由其聯(lián)系用戶確認后作出解答；（2）需求確認后，針對系統(tǒng)功能和性能等指標，由測試工程師進行測試測用例的設(shè)計，設(shè)計從兩個方面進行，一方面測試工程師根據(jù)需求進行測試用例的編寫，另一方面測試工程師可根據(jù)用戶反饋問題進行分析匯總；（3）使用QC功能測試工具對應(yīng)用軟件兼容性、操作系統(tǒng)兼容性進行測試，以便于使用測試工具完成多種環(huán)境下的功能和兼容性測試；（4）進行自由測試以便于對系統(tǒng)測試用例進行補充，分析測試用例未覆蓋問題的原因；（5）定期分析缺陷庫中的問題，分析問題產(chǎn)生的原因，進行測試用例的修改。
3結(jié)論
本文指出了軟件質(zhì)量管理過程中可能會引起軟件質(zhì)量問題的原因,對軟件質(zhì)量管理的相關(guān)問題進行了分析,歸納和總結(jié),這些問題在軟件開發(fā)人員中具有一定的普遍性。實踐表明,通過對這些問題進行分類,開發(fā)人員可以清楚地知道在軟件設(shè)計中容易出現(xiàn)的問題,能夠及時采取相應(yīng)的措施,推動軟件質(zhì)量的全面提高。
作者：翁婕丁鐵喬揚單位：南京萊斯信息技術(shù)股份有限公司質(zhì)量與技術(shù)管理部
【關(guān)鍵詞】計算機軟件；軟件測試；生命周期；BSS系統(tǒng)；IT系統(tǒng)
1 引言
通信行業(yè)通常有三個相對獨立的IT系統(tǒng)：OSS運營支撐系統(tǒng)、BSS業(yè)務(wù)支撐系統(tǒng)、管理支撐系統(tǒng)。其中，BSS是通信行業(yè)對外向客戶直接服務(wù)的系統(tǒng)，管理著企業(yè)的各類客戶資料，為各類客戶提供業(yè)務(wù)受理和計費服務(wù)。BSS系統(tǒng)做得好壞，直接牽涉到最終用戶對通信業(yè)務(wù)的使用。要保證BSS系統(tǒng)的質(zhì)量，就需要在BSS系統(tǒng)的各個環(huán)節(jié)把好質(zhì)量關(guān)。
本文的研究任務(wù)就是通過軟件測試環(huán)節(jié)提高BSS系統(tǒng)軟件的效率，從而大大提高企業(yè)的信息化服務(wù)水平，使業(yè)務(wù)支撐部門對業(yè)務(wù)部門進行強有力的支撐。
2 軟件測試研究基礎(chǔ)
軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試，甚至根據(jù)需要編寫不同的測試工具，設(shè)計和維護測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進行分析和評估。軟件測試貫穿整個軟件系統(tǒng)的生命周期中，為保證服務(wù)質(zhì)量，軟件測試要經(jīng)過開發(fā)過程中的單元測試，集成測試，以及軟件交付后的確認測試，系統(tǒng)測試，驗收測試，還有軟件使用后的回歸測試。如圖所示：
2.1 單元測試
單元測試是在軟件開發(fā)過程中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運行環(huán)境的過程中。
2.2 集成測試
集成測試，也叫組裝測試或聯(lián)合測試，是單元測試的邏輯擴展。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。
2.3確認測試
確認測試又稱有效性測試。有效性測試是在模擬的環(huán)境下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。任務(wù)是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。
2.4 系統(tǒng)測試
系統(tǒng)測試是將已經(jīng)確認的軟件、計算機硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，進行信息系統(tǒng)的各種組裝測試和確認測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。
2.5 驗收測試
驗收測試是系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關(guān)的用戶和獨立測試人員根據(jù)測試計劃和結(jié)果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。
2.6 回歸測試
伴隨著軟件生命周期中的任何一個階段，還有一個重要的測試環(huán)節(jié)是回歸測試。只要軟件發(fā)生了改變，就可能給該軟件帶來問題。軟件的改變可能是源于發(fā)現(xiàn)了錯誤并做了修改，也有可能是因為在集成或維護階段加入了新的模塊。
3 案例分析及研究
3.1 驗收測試在通信行業(yè)BSS系統(tǒng)中的應(yīng)用研究
本案中，軟件上線前，要經(jīng)過初驗和終驗，初驗是對軟件的初次驗收，根據(jù)合同要求，初驗時一般要滿足的條件是，軟件程序在一定的范圍內(nèi)上線試運行，并在試運行過程中故障率不超過一定的范圍。初驗過程中，使用人員對軟件進行充分的使用，盡量多的遍歷所有的分支點，對軟件開發(fā)商提出更詳細的需求改造要求，軟件廠家在此階段都會盡可能快地做出修改，并提交給使用人員。這樣重復(fù)多次，直到達到初驗要求，項目會繼續(xù)推廣到更大的范圍。大范圍使用后，使用人員會隨之增多，必將會碰到更大更多的問題，在經(jīng)過軟件廠家的修改優(yōu)化，達到軟件程序穩(wěn)定運行的效果，此時，項目才滿足終驗條件。終驗后，軟件廠家會維護一段時間，簽訂長期的維護合同。
根據(jù)這種情況，驗收測試是在軟件程序的初驗和終驗都要涉及到的。測試目的都是盡量查找軟件的漏洞以便得以修改，測試的方法是功能測試涉及較多一點。BSS系統(tǒng)驗收測試的目的是確認系統(tǒng)是否滿足產(chǎn)品需求規(guī)格說明和技術(shù)合同的相關(guān)規(guī)定，繼而能否滿足企業(yè)應(yīng)用需求。一般需要通過實施預(yù)定的測試計劃和測試執(zhí)行活動，確認系統(tǒng)的功能需求、性能需求和文檔需求。BSS系統(tǒng)是較復(fù)雜的大規(guī)模系統(tǒng)，其驗收測試具體包括：安裝測試、功能測試、界面測試、性能測試、文檔測試、負載壓力測試、恢復(fù)測試、安全性測試、兼容性測試等。
BSS系統(tǒng)的驗收測試一般由使用人員來做，且必須做到對每個細節(jié)和關(guān)鍵指標的反復(fù)測試。它的測試技術(shù)方法不僅有上述提到的幾種測試，還需要一些白盒測試，避免實現(xiàn)當前功能的情況下影響到其他模塊。它的測試用例，需要反復(fù)推算，尋找到最佳用例，以盡多的遍歷各測試節(jié)點，對程序、數(shù)據(jù)、文檔都要做到細致的測試。
根據(jù)以上分析，驗收測試涉及BSS系統(tǒng)的各環(huán)節(jié)內(nèi)容。其中，最主要要審核的內(nèi)容就是根據(jù)軟件的需求分析，檢驗要交付的軟件系統(tǒng)是否滿足需求分析中的內(nèi)容。具體來說，根據(jù)驗收測試方法和它所屬的狀態(tài)及重要性，在BSS系統(tǒng)中，驗收測試的審核內(nèi)容，可以用以下文檔驗收來體現(xiàn)。
軟件開放商應(yīng)向企業(yè)項目組成員提供以下文檔：《軟件需求分析書》、《驗收測試計劃》和《項目驗收準則》、《測試用例設(shè)計》、《測試環(huán)境標準》、《測試報告》、《測試結(jié)果分析》、《缺陷報告》、《驗收測試報告》、《使用說明》或《操作文檔》、《試運行報告》。另外，使用人員根據(jù)軟件廠家提供的上述文檔，挑選重要的測試項，組織使用人員重新編寫測試用例并進行測試，編寫客戶方自己的《驗收測試計劃》、《驗收測試報告》、《驗收測試結(jié)果及分析》。根據(jù)《驗收測試結(jié)果及分析》組織項目成員討論是否驗收此項目。
驗收測試流程圖：
根據(jù)上述要求，在本案例中，驗收測試方面存在以下不足：
第一、《驗收測試計劃》和《項目驗收準則》沒有專門的文檔。如果我們能在需求分析書完成后能夠定制獨立的《驗收測試計劃》和《項目驗收準則》，則更有利于我們做好驗收測試工作，做好終驗工作。第二、沒有《缺陷報告》，程序的開發(fā)總要伴隨著缺陷的產(chǎn)生，雖然開放人員在逐漸的解決這些缺陷問題，但總有一些問題解決不了。第三、甲方對驗收測試重視不足，沒有獨立的《驗收測試計劃》、《驗收測試報告》、《驗收測試結(jié)果及分析》，沒有獨立的驗收文檔，對結(jié)果也沒有做分析。第四、在驗收測試整個過程中，甲方過于依賴乙方。整個流程以乙方提供驗收文檔為主，甲方雖驗收了文檔等資料，但并沒有根據(jù)資料編制驗收測試方案，也沒有做驗收測試報告及分析，只是在乙方提供驗收測試文檔中根據(jù)驗收測試用例進行了測試。
在實際運用中，首先要重視軟件測試的重要性，另外不能過于依賴軟件開發(fā)商，要建立企業(yè)自己的IT人員測試組，對軟件進行詳盡的各方面的測試。
3.2 回歸測試在通信行業(yè)BSS系統(tǒng)中的應(yīng)用研究
實際工作中，回歸測試需要反復(fù)進行，當測試者一次又一次地完成相同的測試時，這些回歸測試將變得非常令人厭煩，為了支持多種回歸測試策略，可以運用自動測試工具，以便滿足達到不同回歸測試目標的要求。
通信行業(yè)BSS系統(tǒng)的回歸測試特別頻繁，每月的應(yīng)用變更幾十例，有新增的功能，也有變更的功能，還有修復(fù)的功能。這些變更都需要回歸測試來驗證功能是否達到需求的要求。根據(jù)軟件特性，進行的回歸測試大都需要結(jié)合軟件模塊自身的功能，手工完成驗證，并且不同的模塊的回歸測試方法也可能不同。進行回歸測試時，不但檢驗新增模塊的功能是否實現(xiàn)，還要驗證是否影響了周邊其他模塊的功能，同時檢查整個大的模塊的功能是否正常，也就是考察軟件自身的功能和兼容性。
4總結(jié)與展望
實踐證明：將軟件測試的方法引入通信行業(yè)的BSS系統(tǒng)中，在軟件測試的各個環(huán)節(jié)都能夠詳細和規(guī)范的記錄測試相關(guān)信息，使管理層能夠方便的掌握到整個軟件的問題、配置、變更、等環(huán)節(jié)的信息，為領(lǐng)導(dǎo)決策提供了強有力的支持，達到了軟件使用的目的。大幅提高了系統(tǒng)的軟件維護效率和整個BSS系統(tǒng)的準確性，使BSS系統(tǒng)對企業(yè)的業(yè)務(wù)能夠快速高效的支撐。
參考文獻
[1]（美）馬瑟著.王峰，郭長國，陳振華等譯.軟件測試基礎(chǔ)教程[M].北京：機械工業(yè)出版社，2011.
[2]陳能技.軟件測試技術(shù)大全[M].北京：人民郵電出版社，2011.
關(guān)鍵詞：軟件測試 課程教學 問題 對策
中圖分類號：G4 文獻標識碼：A 文章編號：1672-3791（2016）07（b）-0112-02
在社會高度信息化的今天，人們使用各種各樣的軟件產(chǎn)品處理日常生活、工作事務(wù)，比如查看天氣、交通導(dǎo)航、撰寫報告、統(tǒng)計業(yè)績等。隨著市場需求的擴大，軟件開發(fā)投入增多，同一主題的應(yīng)用軟件越來越多。面對消費者挑剔的眼光，軟件供應(yīng)方必須不斷提高軟件的功能性、智能化和友好程度，盡可能地降低出現(xiàn)bug的機率。這就必須要在產(chǎn)品前，進行嚴格的科學測試。因此，軟件測試在整個軟件產(chǎn)品的開發(fā)過程中顯得越來越重要。面對軟件企業(yè)需要大量軟件測試人才的形勢，高職院校應(yīng)該重視軟件測試這門課程的教學，培養(yǎng)出大量優(yōu)秀的軟件測試人才。
1 高職院校《軟件測試》教學中存在的問題
1.1 理論教學方法單一，缺乏多樣性
軟件的開發(fā)過程一般根據(jù)瀑布模型分為問題定義、需求分析、設(shè)計、編碼、測試與維護，軟件測試通常只作為軟件工程的一部分內(nèi)容來講解。但由于近年來軟件測試越來越受到重視，很多高職院校把這部分內(nèi)容獨立出來作為一門課程，一般由擔任軟件工程教學的老師來承擔軟件測試的教學。但承擔教學的老師往往缺少企業(yè)工作的經(jīng)驗，他們按照傳統(tǒng)的方法來講解：測試概述、測試過程、測試方法、測試工具與測試管理等。先做好PPT，演示書上的內(nèi)容，課后布置一些思考性的問題，學生為了應(yīng)付期末考試，也只能照搬照抄，死記硬背一些理論，達不到學以致用的目的。這種教學方式還停留在老師教，學生跟著學的填鴨式教學，缺乏信息化時代教學的多樣性。
1.2 實踐教學環(huán)節(jié)薄弱，缺少能動性
軟件測試按照過程可以分為單元測試、集成測試、確認測試、系統(tǒng)測試與驗收測試。由于軟件測試是一個新興的領(lǐng)域，很難找到合適的教材，現(xiàn)有的教材都是對這一測試過程進行理論性的介紹，沒有對一個軟件產(chǎn)品進行完整性測試，缺少規(guī)范的測試計劃、測試用例、測試文檔的編寫，對于測試過程中需要使用的測試工具也是一筆帶過。學生學完主要內(nèi)容后不能對一個軟件產(chǎn)品進行測試，達不到融會貫通的目的。由于實踐教學環(huán)節(jié)的薄弱，很難培養(yǎng)學生的動手能力與企業(yè)需要的團隊協(xié)作能力。
1.3 整體課程認識不足，缺乏前瞻性
很多軟件專業(yè)的學生臨近畢業(yè)時，由于自身能力的不足，沒有辦法選擇軟件開發(fā)方面的工作，認為軟件測試無非是找找軟件產(chǎn)品的錯誤，是一件非常容易的事情。等到真正開始做測試工作時，才發(fā)現(xiàn)規(guī)范的測試計劃、測試用例、測試報告完全不會寫，簡單的測試工具也不會使用，又匆忙去找培訓(xùn)機構(gòu)開始培訓(xùn)，這樣既浪費時間又浪費金錢。
2 《軟件測試》教學對策探討
2.1 合理選擇教學內(nèi)容，構(gòu)建學生的專業(yè)知識體系
在教學內(nèi)容的選擇上，應(yīng)切合高職學生的實際情況，引入案例，采用情景模式教學。內(nèi)容大致可以分為5個教學情景，循序漸進幫助學生構(gòu)建專業(yè)知識體系。第一個情景為制定軟件測試計劃：包括選擇什么樣的項目進行測試（可以是每個小組自己在前期的學習中編寫的項目，也可以是老師推薦的項目，或者是自己在網(wǎng)絡(luò)上下載的項目），編寫測試用例，測試要達到的目標等。第二個情景為黑盒測試：主要講解等價類劃分法、邊界值法、因果圖法、決策表法、正交實驗法與錯誤推測法等；會使用QTP進行自動化測試。第三個情景為白盒測試：主要講解邏輯覆蓋法與路徑測試法；會使用Junit工具進行自動化測試。第四個情景為性能測試：使用Loadrunner工具進行自動化測試。最后一個情景為測試報告的編寫：完成功能測試的bug匯集與性能測試的負載情況分析等。
2.2 完善考核評價體系，突出職業(yè)崗位能力的培養(yǎng)
學生完成軟件測試學習后要能勝任軟件測試員或軟件測試工程師的工作，因此，為了契合他們以后從事崗位的基本能力，對于課程的考核，應(yīng)從多方面進行：理論知識的掌握程度（60%）、規(guī)范文檔的編寫能力（10%）、PPT的制作能力（10%）、上臺講解的能力（10%）、團隊的協(xié)作能力（10%）等。理論知識的考核主要針對每節(jié)課后的作業(yè)是否能夠準確按時地完成；規(guī)范文檔的考核主要看學生是否能夠規(guī)范地編寫一個項目的測試計劃、測試用例以及測試報告；在每一個教學情景完成后每個小組要制作PPT并上臺講解完成作業(yè)的情況，是否能夠正確地收集bug并進行分析，是否能正確錄制腳本并進行回歸測試等；通過完成作業(yè)的情況及上臺講解的能力能反映出一個團隊的協(xié)作能力。
2.3 建設(shè)專業(yè)的實訓(xùn)環(huán)境，培養(yǎng)學生分析問題與解決問題的能力
為了讓學生能更真實地體驗企業(yè)環(huán)境，授課地點放在理論實踐一體化的實驗室進行，專門為軟件專業(yè)學生所搭建的實驗平臺，安裝軟件企業(yè)通用的一些測試工具，如Loadrunner、QTP、Junit等，并且有專用的網(wǎng)絡(luò)可供學生上網(wǎng)查詢問題。學生可以隨時進實驗室進行實踐，老師也方便指導(dǎo)學生。這種專業(yè)的實驗環(huán)境更能培養(yǎng)學生分析問題與解決問題的能力。
2.4 豐富師生教學的組織形式，促進學生知識多元化的發(fā)展
高職院校的教師往往理論知識扎實，實踐經(jīng)驗不足。因此，為了更好地培養(yǎng)學生，應(yīng)定期選派一些優(yōu)秀的教師到軟件公司的測試部門實習，學習對一個完整項目的功能測試與性能測試過程，在公司允許的情況下，將測試項目引入到教學中，可以豐富實踐教學，促進教學方法與教學手段的改進。另外，可以聘請一些軟件公司的軟件測試負責人參與到教學中，充分利用他們豐富的實踐經(jīng)驗，指導(dǎo)學生的實踐教學。還可以定期邀請一些行業(yè)專家為學生開設(shè)專題講座，讓學生了解軟件測試的最新前沿知識，為學生最終進入軟件企業(yè)實習做好理論與實踐上的鋪墊。在學習中，學生組建3人小組，1人任測試組長，2人為組員。可以固定小組成員完成全部課程內(nèi)容，也可以按教學情景確定小組成員，讓同學之間有更多的交流和互動。
3 結(jié)語
軟件測試與軟件產(chǎn)品的質(zhì)量息息相關(guān)，要做好軟件測試，就需要大量的軟件測試人才，高職院校軟件專業(yè)要與軟件企業(yè)緊密結(jié)合，做好輸送人才的基地。我們要建立為企業(yè)服務(wù)、以學生為主體的思想，從教材的建設(shè)、實驗室的搭建、師資的培養(yǎng)、對學生的考核機制等方面進行探討，尋找培養(yǎng)優(yōu)秀人才的最佳教學方法。
參考文獻
[1] 王帥，朱彬，李麗萍.軟件測試課程建設(shè)的幾點措施[J].計算機教育，2010（8）：66-68.
1、需求分析，測試開發(fā)人員對這一環(huán)節(jié)的理解程度直接影響到接下來的測試任務(wù)的開展；
2、測試計劃，有負責人編寫，依據(jù)主要是項目開發(fā)計劃和測試需求分析結(jié)果而制定；
3、測試設(shè)計，主要包括測試用例編寫和測試場景設(shè)計兩方面；
4、測試環(huán)境的搭建，符合要求的測試環(huán)境能夠幫助我們準確的測出軟件問題，并且做出正確的判斷；
5、測試執(zhí)行；
6、測試記錄；
7、缺陷管理；
8、軟件評估，軟件經(jīng)過一輪又一輪測試后，確認軟件無重大問題或者問題很少的情況下，對準備發(fā)給客戶的軟件進行評估，以確定是否能夠發(fā)行給客戶或投放市場；
9、測試總結(jié)；
1、面試官您好，我叫XXX，來自北京。201X年畢業(yè)于XXX大學，有2年軟件測試工作經(jīng)驗，之前在XXX公司擔任軟件測試工程師一職。
2、在公司里我先后負責了兩個項目的測試，分別為XX項目和XX項目，在這兩個項目中我負責了測試計劃和方案的編寫，測試用例的設(shè)計，測試環(huán)境的搭建以及測試執(zhí)行和編寫測試報告等工作。
3、對于linux、數(shù)據(jù)庫、fiddler、jmeter的應(yīng)用都比較熟悉。也用jmeter做過一些性能測試，最近一段時間也做了自動化測試，主要是用的python selenium框架實現(xiàn)的。
4、在工作中我組要負責功能測試，其次還參與了一些非功能測試，如兼容性測試，易用性測試，性能測試等。我來貴公司是求職軟件測試工程師，希望得到這樣一個機會。
（來源：文章屋網(wǎng) ）
關(guān)鍵詞：視頻監(jiān)控；軟件自動化；測試技術(shù)；實現(xiàn)
中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2017）01-0240-02
隨著科學技術(shù)的不嘟步，視頻監(jiān)控設(shè)備已經(jīng)應(yīng)用到了各個領(lǐng)域當中。視頻監(jiān)控設(shè)備本身具有業(yè)務(wù)邏輯性強與界面復(fù)雜的特點，為提高設(shè)備性能以及質(zhì)量，在將其投入使用之前，必須對其加以測試，以最大程度確保其應(yīng)用的有效性。
1 自動化測試技術(shù)及流程
自動化測試技術(shù)是測試技術(shù)中的一種，特點在于以自動化測試設(shè)備，代替了人工測試，提高了重復(fù)測試的效率。將該技術(shù)應(yīng)用于視頻監(jiān)控的測試過程中，可以在短時間內(nèi)，得出準確的測試結(jié)果，以此為指導(dǎo)，縮短產(chǎn)品研發(fā)周期，使其能夠更快的投入市場。
自動化測試技術(shù)的應(yīng)用要在堅持相應(yīng)流程的基礎(chǔ)上實現(xiàn)，以自動化技術(shù)為基礎(chǔ)所實現(xiàn)的測試，需要經(jīng)過包括自動化測試需求分析以及自動化總體方案設(shè)計與自動化策略分析等流程。除此之外，還需要通過測試用例、測試套與測試腳本編寫，進如到測試腳本調(diào)試過程（在此之前，需經(jīng)過AW實現(xiàn)與AW調(diào)試的過程），并在調(diào)試完成之后，使測試腳本能夠執(zhí)行。
2 視頻監(jiān)控自動化測試設(shè)計
2.1 測試計劃
對測試計劃的設(shè)計是保證視頻監(jiān)控自動化測試設(shè)計順利實現(xiàn)的基礎(chǔ)，主要需要考慮的問題較多，包括測試度量、測試環(huán)境準備配置、自動化測試決策以及測試范圍的控制與測試進展的監(jiān)控等多方面內(nèi)容，要在綜合考慮上述問題的基礎(chǔ)上，提高測試計劃的合理性。
2.2 測試策略
測試策略主要包括以下三方面：
首先，提取模塊是測試的第一步，要在待測試的視頻監(jiān)控系統(tǒng)中，對適合的模塊進行提取，并對其投入產(chǎn)出的比例進行計算。
其次，綜合各個模塊測試的設(shè)計時間，對其進行合理評估。
最后，實現(xiàn)自動化測試優(yōu)先級，在此之前，需要確定產(chǎn)品的研發(fā)周期等問題。
3 面向視頻監(jiān)控的軟件自動化測試技術(shù)與實現(xiàn)
驅(qū)動層與應(yīng)用層是面向視頻監(jiān)控的軟件自動化測試的兩個主要層面，對其設(shè)計與實現(xiàn)問題進行分析，是提高測試技術(shù)應(yīng)用有效性的主要保證。
3.1 驅(qū)動層的設(shè)計與實現(xiàn)
驅(qū)動層的設(shè)計與實現(xiàn)應(yīng)以RFT工具與Robot測試框架為基礎(chǔ)，通過后者關(guān)鍵詞驅(qū)動的方式，實現(xiàn)前者對Web界面的自動化測試。上述測試手段能夠充分結(jié)合兩者的優(yōu)勢，達到提高測試效率以及有效性的目的。
3.1.1 遠程控制服務(wù)器的設(shè)計
在RFT工具與Robot測試框架的支持下，首先應(yīng)完成遠程控制服務(wù)器的設(shè)計。首先要啟動測試框架并讀入數(shù)據(jù)，在此基礎(chǔ)上，Robot測試框架能夠自動實現(xiàn)對數(shù)據(jù)的處理，生成命令，并將其發(fā)送到遠程控制服務(wù)器當中，此時關(guān)鍵詞轉(zhuǎn)化便能夠?qū)崿F(xiàn)，繼而進入到驅(qū)動層中讀取命令，并自動生成測試腳本，最終完成遠程控制服務(wù)器的設(shè)計。
3.1.2 對象管理
對象管理即對視頻監(jiān)控系統(tǒng)中各項有關(guān)文本信息的管理，是基于Web界面的管理。主要包括測試對象映射編輯、對象識別、對象加載與對象查找四部分管理內(nèi)容。首先，要完成對象映射編輯過程，這一過程可以采用對象映射編輯器來完成，編輯器包括對象樹與對象識別屬性兩部分，前者能夠?qū)崿F(xiàn)對對象的識別。
3.1.3 動作執(zhí)行
以下為動作執(zhí)行的常見操作：
Click（…）
Double Click（…）
Select（…）
set Text（…）
get Text（…）
在動作執(zhí)行過程中，需要對上述常見操作加以重視。
3.1.4 結(jié)果驗證
在得出測試結(jié)果之后，需要對結(jié)果進行驗證，以確保其合理性，具體驗證過程需要按照相應(yīng)流程來進行，首先從將期望數(shù)據(jù)與實際數(shù)據(jù)做比較開始，到將比較結(jié)果寫入日志為止，最終完成驗證過程，結(jié)束測試。
3.2 應(yīng)用層的設(shè)計與實現(xiàn)
應(yīng)用層的設(shè)計與實現(xiàn)應(yīng)以Robot框架為基礎(chǔ)，在設(shè)計關(guān)鍵詞與測試用例的基礎(chǔ)上，達到自動化測試技術(shù)的要要求。
3.2.1 關(guān)鍵詞驅(qū)動測試
關(guān)鍵詞驅(qū)動測試包括設(shè)計與實現(xiàn)兩個階段。在設(shè)計階段，要對關(guān)鍵詞進行定義，并確定其參數(shù)，在綜合種種數(shù)據(jù)的基礎(chǔ)上，生成數(shù)據(jù)表，并實現(xiàn)對用戶登陸等過程的控制。在實現(xiàn)階段，應(yīng)注意Enter Text與Click等關(guān)鍵詞的底層腳本實現(xiàn)問題。
3.2.2 視頻監(jiān)控的測試用例設(shè)計
視頻監(jiān)控系統(tǒng)的測試用例設(shè)計應(yīng)從測試用例分類的方向出發(fā)來實現(xiàn)。總的來說，測試用例設(shè)計主要包括配置測試、功能測試、性能規(guī)格測試、壓力測試、異常測試與組合測試幾種。以配置測試為例，主要測試的是產(chǎn)品配置十分能夠滿足國家以及相應(yīng)領(lǐng)域的生產(chǎn)要求，而功能測試，目的則在于判斷產(chǎn)品功能是否符合實際情況。
3.2.3 關(guān)鍵詞驅(qū)動表設(shè)計
關(guān)鍵詞驅(qū)動表的設(shè)計對于原始輸入數(shù)據(jù)信息要求較高，同時，其也體現(xiàn)著測試對象的業(yè)務(wù)邏輯，因此對驅(qū)動表進行設(shè)計十分重要。在設(shè)計過程中，應(yīng)從概念設(shè)計出發(fā)，逐一完成三級驅(qū)動表格的設(shè)計，即高級、中級和底層，以提高設(shè)計水平，保證測試結(jié)果的合理性與視頻監(jiān)控產(chǎn)品功能。
4 結(jié)語
綜上所述，面向視頻監(jiān)控的軟件自動化測試的主要目的在于確保視頻監(jiān)控產(chǎn)品的配置能夠滿足相應(yīng)設(shè)計要求，與此同時，判斷其性能是否達標。在這一過程中，應(yīng)對驅(qū)動層與應(yīng)用層加以重點設(shè)計，并確保其能夠順利實現(xiàn)，最終達到提高設(shè)計水平的目的，范圍到自動化測試中，便是測試效果的改善，與此同時，將其應(yīng)用于視頻監(jiān)控中，能夠達到提高監(jiān)控實時性與效率的目的，對此，有關(guān)人員必須加以重視。
參考文獻
關(guān)鍵詞：軟件測試；集成測試；調(diào)用圖；MM-路徑
中圖分類號：TP317文獻標識碼：A文章編號：1007-9599 (2012) 03-0000-02
Analysis of Integration Testing of Software Testing
Hou Yanfang,Chu Shulai
(Zhoukou Vocational and Technical College,Zhoukou466001,China)
Abstract:The integration testing plays a very important role in software testing,the concept of integration testing,integration testing strategy and the main types of integration testing (phase) briefly discusses the analysis of several key integration testing.
Keywords:Software testing;Integration testing;Call graph;MM-path
軟件測試作為軟件質(zhì)量保證的關(guān)鍵技術(shù)之一，其目的就是能夠有效地發(fā)現(xiàn)軟件中的錯誤或缺陷。集成測試是軟件測試中處于組件測試和系統(tǒng)測試之間一個非常重要的環(huán)節(jié)，這是因為所有組件都經(jīng)過測試并能正常運行并不意味著這些組件放到一起經(jīng)過集成后還能正常運行，正是基于這一點，很多大的軟件公司成立了專門關(guān)注集成測試的測試團隊，如能恰當實施，集成測試能大大減少一些在系統(tǒng)測試階段才會發(fā)現(xiàn)的缺陷。
一、集成測試的概念
（一）集成測試的定義
集成測試是構(gòu)造軟件體系結(jié)構(gòu)的系統(tǒng)化技術(shù)，同時也是進行一些旨在發(fā)現(xiàn)與接口相關(guān)的錯誤的測試。其目標是利用已通過單元測試的構(gòu)件建立設(shè)計中描述的程序結(jié)構(gòu)。
（二）集成測試遵循的原則
集成測試遵循的原則主要包括：所有公共接口都要被測試到；關(guān)鍵模塊必須進行充分的測試；集成測試應(yīng)當按一定的層次進行；集成測試的策略選擇應(yīng)當綜合考慮質(zhì)量、成本和進度之間的關(guān)系；集成測試應(yīng)當盡早開始，并已總體設(shè)計為基礎(chǔ)；在模塊與接口的劃分上，測試人員應(yīng)當和開發(fā)人員進行充分的溝通；當接口發(fā)生修改時，涉及的相關(guān)接口必須進行再測試；測試執(zhí)行結(jié)果應(yīng)當如實的記錄；集成測試應(yīng)根據(jù)集成測試計劃和方案進行，不能隨意測試；項目管理者應(yīng)保證審核測試用例。
（三）集成測試的任務(wù)
集成測試的主要任務(wù)包括：將各模塊連接起來，檢查模塊相互調(diào)用時，數(shù)據(jù)經(jīng)過接口是否丟失；將各個子功能組合起來，檢查能否達到預(yù)期要求的各項功能；一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；全局數(shù)據(jù)結(jié)構(gòu)是否有問題，會不會被異常修改；單個模塊的誤差積累起來，是否被放大，從而達到不可接受的程度。
（四）集成測試的文檔
軟件集成的總體計劃和特定的測試描述應(yīng)該在測試規(guī)約中文檔化。這個文檔包含測試計劃和測試規(guī)程，它是軟件過程的工作產(chǎn)品，也是軟件配置的一部分。
下列準則和相應(yīng)的測試可應(yīng)用于所有的測試階段：接口一致性。當每個模塊（或簇）引入程序結(jié)構(gòu)中時，要對其內(nèi)部和外部接口進行測試；功能有效性。執(zhí)行的測試旨在發(fā)現(xiàn)功能錯誤；信息內(nèi)容。執(zhí)行的測試旨在發(fā)現(xiàn)與局部或全局數(shù)據(jù)結(jié)構(gòu)相關(guān)的錯誤；性能。執(zhí)行的測試旨在驗證軟件設(shè)計期間建立的性能邊界。
測試計劃主要包括：集成測試的進度，確定每個階段的開始和結(jié)束時間；附加軟件（樁模塊及驅(qū)動模塊）的簡要描述側(cè)重于專門進行的工作的特征；描述測試環(huán)境和資源；特殊的硬件配置、特殊的仿真器和專門的測試工具或技術(shù)也是需要討論的問題；詳細測試規(guī)程。
測試規(guī)約：集成策略（包含在測試計劃中）和測試細節(jié)（在測試規(guī)程中描述）是最基本的成分，因此必須要有。
二、集成測試的策略
驅(qū)動模塊（Driver）：用來模擬待測模塊的上級模塊。驅(qū)動模塊在集成測試中接受測試數(shù)據(jù)，將相關(guān)的數(shù)據(jù)傳送給待測模塊，啟動待測模塊，并打印出相應(yīng)的結(jié)果。樁模塊（Stub）：也稱為存根程序，用以模擬待測模塊工作過程中所調(diào)用的模塊。樁模塊由待測模塊調(diào)用，它們一般只進行很少的數(shù)據(jù)處理，例如打印入口和返回，以便于檢驗待測模塊與下級模塊的接口。
一般可分為非增量集成和增量式集成，其中增量集成指的是程序以小增量的方式逐步進行構(gòu)造和測試，這樣錯誤易于分離和糾正，更易于對接口進行徹底測試，而且可以運用系統(tǒng)化的測試方法，傳統(tǒng)的將增量測試策略分為自頂向下集成、自底向上集成以及三明治集成。
三、集成測試的主要類型（階段）
（一）基于功能分解的集成
在討論集成測試時，測試方法都基于采用樹或文字形式來表示的功能分解。這類討論不可避免地要深入到將要集成的模塊的順序。
1.自頂向下集成（從樹頂開始向下）。深度優(yōu)先集成是首先集成結(jié)構(gòu)中主控路徑下的所有模塊。
2.自底向上集成（從樹底開始向上）。自底向上集成是自頂向下順序的“鏡像”，不同的是，樁由模擬功能分解樹上一層單元的驅(qū)動模塊替代。在自底向上集成中，首先從分解樹的葉子開始，并用特別編寫的驅(qū)動模塊進行測試。驅(qū)動模塊中的一次性代碼比樁中的少。大多數(shù)系統(tǒng)在接近葉子節(jié)點時都有相當高的扇出數(shù)，因此在自底向上集成順序中，不需要同樣數(shù)量的驅(qū)動模塊，不過代價是驅(qū)動模塊都比較復(fù)雜。
3.三明治集成（前兩種方法的某種組合）。三明治集成測試是將自頂向下測試與自底向上測試兩種模式有機結(jié)合起來，采用并行的自頂向下、自底向上集成方式，形成的方法。三明治集成測試更重要的是采取持續(xù)集成的策略。樁和驅(qū)動的開發(fā)工作都比較小，不過代價是作為大爆炸集成的后果，在一定程度上增加了定位缺陷的難度。
（二）基于功能分解方法的優(yōu)缺點
1.自頂向下集成，其優(yōu)點：在于它可以自然地做到逐步求精，一開始就能讓測試者看到系統(tǒng)的框架。缺點：需要提供樁模塊，樁模塊是對被調(diào)用子模塊的模擬，可能不能反映真實情況，因此測試有可能不充分。
由于被調(diào)用模擬子模塊不能模擬數(shù)據(jù)，如果模塊間的數(shù)據(jù)流不能構(gòu)成有向無環(huán)圖，一些模塊的測試數(shù)據(jù)便難以生成。同時，觀察和解釋測試輸出往往也是困難的。
2.自底向上集成，其優(yōu)點：由于驅(qū)動模塊模擬了所有調(diào)用參數(shù)，即便數(shù)據(jù)流并未構(gòu)成有向無環(huán)圖，生成測試數(shù)據(jù)也沒有困難。如果關(guān)鍵的模塊是在結(jié)構(gòu)圖的底部，那么自底向上測試是有優(yōu)越性的。缺點：直到最后一個模塊被加入進去之后才能看到整個程序(系統(tǒng))的框架。
3.三明治集成測試采用自頂向下、自底向上集成相結(jié)合的方式，并采取持續(xù)集成的策略，有助于盡早發(fā)現(xiàn)缺陷，也有利于提高工作效率。
4.功能分解缺點。為了滿足項目管理的需要，而不是為了滿足軟件開發(fā)人員的需要。樁或驅(qū)動的開發(fā)工作量，此外還有重新測試所需工作量的問題。對于自頂向下集成，需要開發(fā)（節(jié)點-1個）樁模塊；對于自底向上集成，需要開發(fā)（節(jié)點-葉子）個驅(qū)動模塊。
（三）基于調(diào)用圖的集成
基于調(diào)用圖的集成一般分為成對集成和相鄰集成。基于調(diào)用圖方法的優(yōu)點：偏離了純結(jié)構(gòu)基礎(chǔ)，轉(zhuǎn)向行為基礎(chǔ)，因此底層假設(shè)是一種改進；這些技術(shù)還免除了樁／驅(qū)動器開發(fā)工作量；與以構(gòu)建和合成為特征的開發(fā)匹配得很好。缺點：缺陷隔離問題，尤其是對有大量鄰居的情況；清除缺陷后，意味著以前測試過的包含已變更代碼的鄰居，都需要重新進行測試。
（四）基于路徑的集成
將集成測試的側(cè)重點由測試單獨開發(fā)并通過測試的單元之間的接口，轉(zhuǎn)移到這些單元的交互上，即它們的“協(xié)同功能”上。接口是結(jié)構(gòu)性的，而交互是功能性的。
MM-路徑是功能性測試和結(jié)構(gòu)性測試的一種混合，其優(yōu)點：它與實際系統(tǒng)行為結(jié)合緊密，而不依賴于基于分解和調(diào)用圖集成的結(jié)構(gòu)性推動。基于路徑集成測試也適用于面向?qū)ο蟮能浖y試。缺點：需要更多的工作量標識MM-路徑。這種工作量可能會與樁和驅(qū)動的開發(fā)所需工作量有偏差。
（五）面向?qū)ο蟓h(huán)境中的集成測試
兩種不同的策略：
1.基于線程的測試(thread-based testing）。
2.基于使用的測試（use-based testing）。
驅(qū)動程序和樁程序：驅(qū)動程序可用于測試低層中的操作和整組類的測試。驅(qū)動程序也可用于代替用戶界面以便在界面實現(xiàn)之前就可以進行系統(tǒng)功能的測試。樁程序可用于在需要類間的協(xié)作但其中的一個或多個協(xié)作類仍未完全實現(xiàn)的情況下。
四、結(jié)語
集成測試既是一種測試類型也是一個測試階段，因為集成定義為一組交互，因此組件之間的所有已定義的交互都需要測試，體系結(jié)構(gòu)和設(shè)計可以提供系統(tǒng)內(nèi)部的交互細節(jié)，但是測試一個系統(tǒng)與另一個系統(tǒng)之間的交互要求對這些系統(tǒng)一起工作的方式有深刻理解，此時的集成測試是一個階段。由于集成測試的目標是模塊之間的交互，這種測試就像白盒、黑盒及其它類型的測試一樣，也有一套技術(shù)和方法，因此集成測試也被看作是一種測試類型。
參考文獻：
[1]周燕,宋敬華.面向?qū)ο蟮募蓽y試順序的研究[J].計算機測量與控制,2010,9
[2]張云崗,劉春茂.軟件測試技術(shù)淺析[J].技術(shù)與市場,2011,2
[3]朱家云.淺析軟件測試[J].信息系統(tǒng)工程,2011,4
[4王麗達.論軟件系統(tǒng)的測試[J].經(jīng)濟研究導(dǎo)刊,2011,14
[5]劉欣.軟件測試方法分析與實踐[D].北京郵電大學,2009
[6]趙,孫寧.軟件測試技術(shù)：基于案例的測試[M].北京:機械工業(yè)出版社,2011
關(guān)鍵詞：Delphi程序設(shè)計；模擬教學法；角色分配
中圖分類號：G642 文獻標識碼：A 文章編號：1009-3044（2014）22-5260-05
Delphi程序設(shè)計是我院軟件技術(shù)專業(yè)三年級學生的選修課程，該課程采用面向?qū)ο蟪绦蛟O(shè)計方法。程序設(shè)計是一門概念復(fù)雜、抽象、知識面廣的課程。每位學生都想著有一天自己的程序能在指縫間源源不斷的敲擊出來，自己設(shè)計的系統(tǒng)能完美運行。然而在真正學習該課程后，開始編寫系統(tǒng)程序時，往往無所下手，沒有頭緒，沒有思路，盡管當時努力學習課程，通過考試，但并沒有體會到理論聯(lián)系實際的樂趣，便逐漸使學生失去了編程的興趣。
Delphi程序設(shè)計的前導(dǎo)課程是VB、C程序設(shè)計和數(shù)據(jù)庫系統(tǒng)、軟件工程。因此學生們已具備軟件工程開發(fā)思想，編程能力和數(shù)據(jù)庫基礎(chǔ)。該課程進一步提高學生的編程能力、分析解決問題的能力及用軟件工程的思想和方法設(shè)計開發(fā)功能較完整的實際應(yīng)用系統(tǒng)，并提高學生的分工協(xié)作、團隊合作、口頭表達及文字表述能力方面的能力。
1 模擬教學法
如何提高學生的學習積極性，從傳統(tǒng)教學法到任務(wù)驅(qū)動法的教學過程使學生的學習積極性提升上來了，但并不符合當前企業(yè)的崗位實際需要。如何既能保證學生的學習興趣不減，又能使學生更好地理解軟件企業(yè)的崗位需要，提高協(xié)作能力，課程教學過程中設(shè)計了一套模擬教學法，也就是模擬企業(yè)在軟件開發(fā)過程中崗位需求的設(shè)置，結(jié)合高職院校學生的實際學習情況，將模擬教學法應(yīng)用到Delphi程序設(shè)計課程中。模擬教學法結(jié)合案例教學法、項目教學法、角色扮演和探索式教學法。將全體成員分成若干小組，采用小組合作，明確分工，演示匯報的方式完成課程教學。
2 實踐及過程
2.1角色扮演及職業(yè)生涯規(guī)劃
課程中最先講解的是角色扮演。軟件工程的思想，是針對不同的難度和規(guī)模的項目，會有不同的人員配置方案，學生應(yīng)充分理解這些角色及職責，為自己的職業(yè)生涯進行規(guī)劃，拉近自己與企業(yè)的距離，由于課程中學時有限，只選取了部分角色讓學生了解、掌握。
部分角色的職責：
1） 項目經(jīng)理
? 組織項目所需的各項資源
? 設(shè)置項目組中的各種角色，并分配好各角色的責任與權(quán)限
? 定制項目組內(nèi)外的溝通計劃。（必要時可配置管理要求寫項目策劃目錄中的《項目溝通計劃》
2） 需求分析員
? 在項目前期根據(jù)《需求調(diào)研計劃》對客戶進行需求調(diào)研
? 收集整理客戶需求，負責編寫《用戶需求說明書》
? 代表項目組與用戶溝通與項目需求有關(guān)的所有事項。
3） 系統(tǒng)設(shè)計工程師
? 根據(jù)需求分析結(jié)果及概要設(shè)計規(guī)范設(shè)計、編制概要設(shè)計說明。
? 保證概要設(shè)計的科學性、可行性，并與需求分析一致。
? 協(xié)助項目經(jīng)理制定項目開發(fā)計劃。
? 依照開發(fā)計劃的要求保證設(shè)計進度。
? 參與需求分析、概要設(shè)計、詳細設(shè)計等過程的階段評審，從是否達到概要設(shè)計的角度提出評審意見。
4） 高級軟件工程師
? 根據(jù)概要設(shè)計結(jié)果及詳細設(shè)計規(guī)范設(shè)計、編制詳細設(shè)計文檔。
? 保證詳細設(shè)計滿足概要設(shè)計對功能界定、可靠性、用戶界面等各方面的要求。
? 依照開發(fā)計劃的要求保證設(shè)計進度。
? 參與概要設(shè)計、詳細設(shè)計、軟件實現(xiàn)等過程的階段評審，從是否達到詳細設(shè)計要求的角度提出評審意見。
5） 編碼人員
? 根據(jù)《系統(tǒng)概要設(shè)計說明書》編寫《系統(tǒng)詳細說明書》。
? 按《系統(tǒng)詳細設(shè)計說明書》進行代碼實現(xiàn)。
? 控制本模塊的開發(fā)進度。
6） 測試人員
? 獨立編寫測試計劃。
? 獨立編寫測試用例。
? 協(xié)調(diào)測試團隊內(nèi)部的工作以及與開發(fā)團隊之間的工作。
? 完成“執(zhí)行測試”的工作。
7） 美工
? 負責完成軟件設(shè)計師安排的功能界面設(shè)計。
? 負責對項目整體色彩的調(diào)配。
? 向系統(tǒng)分析師提出項目美化的建議。
8） 客戶經(jīng)理
? 在項目實施階段，跟蹤、檢查實施人員的工作質(zhì)量。
? 負責協(xié)助用戶進行“用戶確認測試”和編寫《確認測試報告》。
9） 維護人員
? 制訂具體項目的質(zhì)量保證計劃及執(zhí)行。
? 評審的組織。
? 研發(fā)流程的執(zhí)行監(jiān)督、反饋、數(shù)據(jù)收集。
依據(jù)上述角色介紹，由學生選擇角色并制定自己的職業(yè)生涯規(guī)劃，這樣可以鍛煉學生的語言表達能力，為后期小組演示匯報預(yù)演。讓學生勝任角色，成功扮演角色，同時要有教師的適當指導(dǎo)、發(fā)揮學生的各自特點，使他們適應(yīng)角色。以下是小組內(nèi)選擇項目經(jīng)理角色的職業(yè)生涯規(guī)劃：
1） 項目經(jīng)理：完成不同階段的任務(wù)。
2） 項目經(jīng)理具備的素質(zhì)：認真負責的態(tài)度；有扎實的技術(shù)；協(xié)調(diào)各部門的能力；項目總體規(guī)劃能力。
3） 選擇職業(yè)的原則：擇已所愛，擇世所需，擇己所長。
4） 項目經(jīng)理的工作職責：
? 所管轄的區(qū)域客戶進行信息跟蹤、分析及報告，并定期進行更新。
? 所管轄的區(qū)域客戶的產(chǎn)品開發(fā)進行項目管理，滿足用戶需求。
? 經(jīng)常與客戶進行溝通、與客戶保持親密聯(lián)系，定期走訪、了解產(chǎn)品的質(zhì)量等情況。
5） 項目經(jīng)理需要了解你所在企業(yè)的軟件項目技術(shù)特點，了解軟件項目的售前過程，招標方案；掌握需求分析――概要設(shè)計――詳細設(shè)計――開發(fā)進度控制――風險控制――測試流程――現(xiàn)場實施――驗收――售后服務(wù)等業(yè)務(wù)。
6） 努力的方向 ：項目經(jīng)理是一個管理者，因此要鍛煉自己的組織管理能力，增強自己的團隊精神，技術(shù)才是硬道理，努力學好專業(yè)知識，熟悉自身的IT業(yè)務(wù)，做一個洞察力很強的人，培養(yǎng)認真負責的態(tài)度，擁有扎實的技術(shù)，并協(xié)調(diào)好各部門的能力提高項目總體規(guī)劃能力。
2.2需求分析階段
教學第二步，項目選題應(yīng)該是對知識的深入學習。使用企業(yè)真實案例讓各小組分別完成。模擬現(xiàn)實工作環(huán)境、真實事件，讓學生按照工作流程，在工作過程中扮演接近真實身份的角色，從而理解角色的作用、工作內(nèi)容等，以達到體驗真實工作崗位的目的。學生在扮演角色的過程中充分運用所學知識，發(fā)揮自己的才能和想象空間，增強對實際問題的預(yù)測和處理能力。Delphi程序設(shè)計課程中給出企業(yè)的真實開發(fā)案例，整個開發(fā)設(shè)計過程應(yīng)體現(xiàn)軟件工程的思想和方法、運用數(shù)據(jù)庫技術(shù)和程序開發(fā)技術(shù)。
需求分析是軟件開發(fā)過程中至關(guān)重要的環(huán)節(jié)，本階段的角色扮演者應(yīng)充分理解用戶的實際需要，并寫成書面文字，以備后續(xù)環(huán)節(jié)設(shè)計及實現(xiàn)。如果本環(huán)節(jié)需求獲取不準確，后期更正將會付出10倍甚至更多的代價來彌補。鑒于學生們無實際工作經(jīng)驗，不知道此環(huán)節(jié)的重要性，所以從這一階段開始，就讓學生正式進入角色，完成工作。
如何確定用戶？采用指導(dǎo)教師為指定題目中的實際用戶，題目為：生產(chǎn)許可證申報系統(tǒng)。先給每個小組一定的準備時間，商量獲取需求信息的方法，可以是用戶面談，用戶調(diào)查，從行業(yè)標準和規(guī)則中提取需求信息。在與用戶溝通交流的過程中，盡量提供給學生真實的工作過程環(huán)境。以下是需求分析員的實踐結(jié)果：
根據(jù)與用戶談話、調(diào)查及從行業(yè)標準和規(guī)則中提取的信息，要求生產(chǎn)許可證申報系統(tǒng)實現(xiàn)以下幾個主要功能：
1） 申報單位申報數(shù)據(jù)要從手工完成的過程中解放出來，在這里開發(fā)完成企業(yè)基本資料錄入。
2） 由于申報單位要有自身的經(jīng)濟發(fā)展，生產(chǎn)的產(chǎn)品會隨著社會的需求而增多，申報產(chǎn)品是一個長期需要，所以系統(tǒng)在完成數(shù)據(jù)的添加、修改、刪除功能。
3） 對于申報企業(yè)基本信息的變化的處理，如單位地址變更或者法人信息變更系統(tǒng)，在這里要完成資料變更功能。
4） 用戶相關(guān)信息錄入后，根據(jù)實際需要遞交評審部門全國生產(chǎn)許可證申請書或地方生產(chǎn)許可證申請書，在這里要完成報表打印功能。
5） 為了減輕評審部門數(shù)據(jù)錄入的工作量，在申報系統(tǒng)中申報單位將錄入的數(shù)據(jù)進行上報的功能開發(fā)。
它主要能夠?qū)崿F(xiàn)申報數(shù)據(jù)錄入、生產(chǎn)許可證申請書打印、數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)上報等內(nèi)容。生產(chǎn)許可證申報系統(tǒng)在實際運行和使用過程中，性能上應(yīng)能達到：
1） 容量要求：需要系統(tǒng)處理和存儲的數(shù)據(jù)主要有申報單位基本信息、申報產(chǎn)品基本信息、主要技術(shù)人員信息、與產(chǎn)品有關(guān)的生產(chǎn)設(shè)備、原材料、檢測儀器信息等，由于采用了關(guān)系型數(shù)據(jù)庫Paradox，因此在數(shù)據(jù)庫容量方面足以滿足需要。
2） 數(shù)據(jù)精確度：要按照嚴格的數(shù)據(jù)格式輸入，否則系統(tǒng)不給予響應(yīng)處理并提示警告信息。進行查詢時要保證查全率，所有相應(yīng)域包括查詢關(guān)鍵詞的記錄都應(yīng)能查到。因為申報的數(shù)據(jù)的記錄量會很大。
3） 設(shè)計有效的輸入方式，方便用戶操作，有效減少重復(fù)數(shù)據(jù)輸入的工作量，以提高申報數(shù)據(jù)錄入的工作效率
4） 時間特性方面：一般操作的響應(yīng)時間控制在1～2秒內(nèi)，對數(shù)據(jù)轉(zhuǎn)換和打印機的操作也應(yīng)控制在用戶可接受的時間范圍內(nèi)完成。
5） 適應(yīng)性方面：生產(chǎn)許可證申報和管理系統(tǒng)應(yīng)滿足申報單位和評審部門使用的需求。
6） 人機交互友好性：在用戶界面的使用上，應(yīng)有全新感覺，操作簡便，一目了然，視圖友好等特點，并用使用習慣性的菜單界面驅(qū)動方式，給具體操作用戶極大的便利，能單獨支持鼠標和鍵盤，便于用戶操作使用。
7） 硬件接口方面，保證申報數(shù)據(jù)與存儲介質(zhì)之間的數(shù)據(jù)傳輸?shù)耐暾?/p>
8） 軟件接口方面，運行于Windows95及更高版本具有Win32 API的操作系統(tǒng)之上。
9） 系統(tǒng)健壯性，正常使用本系統(tǒng)時不應(yīng)出現(xiàn)錯誤，若運行時遇到不可恢復(fù)的系統(tǒng)錯誤，也必須保證數(shù)據(jù)庫完好無損。
10） 系統(tǒng)安全性：申報數(shù)據(jù)數(shù)據(jù)中許多是涉及到企業(yè)機密的商業(yè)信息，有效防止與系統(tǒng)無關(guān)人員竊取企業(yè)的商業(yè)機密。
11） 系統(tǒng)可靠性：為了提高系統(tǒng)可靠性，減少系統(tǒng)故障，需盡可能采用模塊化、結(jié)構(gòu)化設(shè)計。
12） 系統(tǒng)通用性：通用化程度高，適用于所有申報單位使用。
2.3設(shè)計階段
該環(huán)節(jié)軟件開發(fā)公司與用戶接觸較少，屬于內(nèi)部設(shè)計開發(fā)階段，主要包括數(shù)據(jù)庫的結(jié)構(gòu)設(shè)計，實施及應(yīng)用程序的總體設(shè)計、詳細設(shè)計、編碼和調(diào)試等。在設(shè)計過程中嚴格控制工作進度。以下是系統(tǒng)設(shè)計工程師和高級軟件工程師的部分實踐結(jié)果：
2.4 代碼編寫及美工過程
代碼實現(xiàn)部分，因工作量大，所以需要小組內(nèi)成員全體參與，編碼能力強的同學可以多寫幾個功能，代碼學的不好的同學，分配做報表或者美工。
2.5 測試階段
就測試而言，用面向?qū)ο箝_發(fā)方法的系統(tǒng)測試與其他方法開發(fā)的系統(tǒng)測試沒有什么不同，在所有開發(fā)系統(tǒng)中都是根據(jù)規(guī)范說明來驗證系統(tǒng)設(shè)計的正確性。程序驗證應(yīng)盡可能早地開始。程序測試步驟是從最低層開始，從單元測試、綜合測試、到系統(tǒng)測試。單元測試是系統(tǒng)構(gòu)件的分體測試，將測試好的系統(tǒng)構(gòu)件接起來看它們之間相互作用的正確性稱綜合測試，最后是整個系統(tǒng)的測試，包括軟件系統(tǒng)所在相關(guān)環(huán)境的測試。通常綜合測試是一種“主攻”活動，在系統(tǒng)開發(fā)期是非常關(guān)鍵的。這一階段應(yīng)隨著連接已開發(fā)的每一部分，再看它們的實際工作，這種“主攻”活動在面向?qū)ο笙到y(tǒng)中是一種實質(zhì)性的、漸漸增長的測試策略。測試活動在早期的開發(fā)過程中就應(yīng)開始。當開始開發(fā)時，就可做測試計劃。測試計劃一般在分析期做，而實際的測試通常等到系統(tǒng)構(gòu)造后進行。事先根據(jù)期望的方法和層次建立測試導(dǎo)向圖，然后確定是自動測試還是手工測試，測試計劃需反復(fù)多次。
測試計劃如下：
雖然每位同學都有自己要扮演的角色，但在課程中的每個環(huán)節(jié)每位學生都必須參與，特別是設(shè)計及編碼階段，因為系統(tǒng)要實現(xiàn)的功能很多，所以每位學生都要負責一個或幾個模塊的設(shè)計及代碼實現(xiàn)。不能說測試人員光管測試，不參與其他工作。
2.6 評價
關(guān)鍵詞：測試風險 風險識別 應(yīng)對計劃措施 風險控制。
一、前言
吉林省電子信息產(chǎn)品監(jiān)督檢驗研究院/中國賽寶（吉林）實驗室（）始建于1973年，隸屬于吉林省工業(yè)和信息化廳，是非盈利性事業(yè)單位，業(yè)務(wù)領(lǐng)域涉及電子元器件及液晶、家電、視聽、安防、計算機、通訊、醫(yī)用電器設(shè)備、電池等電子應(yīng)用產(chǎn)品及計算軟件產(chǎn)品、網(wǎng)絡(luò)系統(tǒng)、信息安全的質(zhì)量監(jiān)督、檢驗、鑒定和仲裁，其中，軟件產(chǎn)品測試業(yè)務(wù)是我院重要的一項核心業(yè)務(wù)。我院軟件產(chǎn)品測試業(yè)務(wù)于2004年通過了中國合格評定國家認可委員會（CNAS）的評審，是省內(nèi)唯一授權(quán)的第三方軟件評測機構(gòu)，同時，也是我省雙軟認定工作中唯一指定進行軟件產(chǎn)品登記測試的單位，現(xiàn)開展軟件測試服務(wù)已經(jīng)10余年，主要開展的項目有：軟件產(chǎn)品的登記測試、鑒定測試、確認測試、性能測試、驗收測試、定制性測試、白盒測試等。經(jīng)過多年的持續(xù)發(fā)展，目前擁有一批高素質(zhì)、高水平的專業(yè)測試人才隊伍和先進的測試設(shè)備，優(yōu)質(zhì)、高效地完成了各種類型的軟件產(chǎn)品測試項目，得到了廣大客戶的高度認可和好評。
二、背景和立意
軟件測試風險管理在軟件測試項目中的地位是不容忽視的，本文主要通過對軟件測試項目在測試風險管理方面的相關(guān)內(nèi)容的討論，使讀者從中會體會到軟件測試風險管理對測試項目的重要性和給項目帶來的幫助。
三、以“鍋爐優(yōu)化燃燒專家診斷系統(tǒng)”軟件的測試風險管理為例，論述軟件測試的風險管理。
1、系統(tǒng)描述：
“鍋爐優(yōu)化燃燒專家診斷系統(tǒng)”軟件（以下簡稱本軟件）應(yīng)用于鍋爐設(shè)備燃燒情況的監(jiān)測領(lǐng)域，通過溫度場范圍、煙氣場范圍、計算診斷結(jié)果范圍等初始參數(shù)設(shè)置，模擬量量程、一次風差量程等串口設(shè)置，及開始設(shè)置、保存數(shù)據(jù)等模塊，實現(xiàn)了鍋爐內(nèi)部溫度場及煙氣場的情況推算及結(jié)果顯示等功能。對本軟件測試的要求是在20個工作日內(nèi)完成本項測試任務(wù)，在最后回歸測試時的結(jié)果需達到預(yù)期要求。
2、測試類型：功能測試
功能測試是黑盒測試，是對軟件產(chǎn)品的各項功能進行驗證的測試，注重于測試軟件的功能性需求。
3、編制測試風險管理計劃
在測試的初期，我們會編制測試風險管理計劃，主要描述如何在對本軟件的測試中處理和執(zhí)行風險管理活動在責任、資源、時間等方面的安排。我們?nèi)婵紤]了風險對測試的影響，制定了充分的測試風險管理計劃。其中，我們詳細編制了單個測試風險管理計劃和綜合測試風險管理計劃，為后續(xù)實施的測試風險管理做好了準備，并形成了依據(jù)。
4、測試風險識別及測試風險分析
本軟件測試之前，我們以會議討論的形式，根據(jù)以往的經(jīng)驗，列出檢查項目列表，并進行分解，通過假定分析，最后研究、識別、確定了影響測試計劃實施的因素。
我們還對預(yù)測的測試風險進行了分析，確定測試風險對測試的影響程度及發(fā)生幾率，并對風險進行量化、選擇、排序，確定哪些風險是可以接受的，哪些風險是必須要應(yīng)對的，哪些風險是可以忽略的。進行測試風險管理應(yīng)該把主要精力集中在那些概率高、影響力大的風險上。
經(jīng)過測試風險識別及風險分析，確定測試過程中我們主要關(guān)注的可能存在的對測試影響程度大的主要風險，如下：
（1）由于本軟件是針對鍋爐設(shè)備燃燒情況的監(jiān)測領(lǐng)域的軟件，需要測試人員對鍋爐設(shè)備燃燒情況的監(jiān)測領(lǐng)域相關(guān)知識有所了解，故測試人員對鍋爐設(shè)備燃燒情況的監(jiān)測領(lǐng)域了解不足或不了解，導(dǎo)致測試人員對被測系統(tǒng)的業(yè)務(wù)流程不熟悉，對需求的理解上把握不準、理解不透徹、理解錯誤等，對測試形成風險。
（2）測試人員出具軟件測試問題報告單后，與企業(yè)開發(fā)人員交流時，開發(fā)人員對發(fā)現(xiàn)的問題理解程度不佳，導(dǎo)致對測試問題的修改不滿足要求，或由于企業(yè)原因，企業(yè)再次報送相關(guān)修改結(jié)果速度過慢。
（3）測試人員實施測試時的測試方法有錯誤或缺失，導(dǎo)致對功能點沒有采用正確的測試方法，或某些測試方法被忽視，如邊界測試等，導(dǎo)致測試不充分。
（4）測試環(huán)境出現(xiàn)故障，給測試帶來的影響。
5、測試風險應(yīng)對計劃措施
對已識別的主要風險制定的對應(yīng)應(yīng)對計劃措施，如下：
（1）請企業(yè)相關(guān)人員培訓(xùn)測試人員學習鍋爐設(shè)備燃燒情況的監(jiān)測領(lǐng)域的相關(guān)知識，測試人員也要通過網(wǎng)絡(luò)和書籍多查找鍋爐設(shè)備燃燒情況的監(jiān)測領(lǐng)域相關(guān)資料，做好測試前了解行業(yè)知識的準備。
（2）加強對測試人員的溝通能力和服務(wù)意思的培訓(xùn)，保證測試人員能詳細、認真、準確的講解測試問題報告單中體現(xiàn)的bug，使得企業(yè)軟件開發(fā)人員能明白測試人員的講解，并確認軟件中存在的bug，及時快速的修復(fù)bug，且在與企業(yè)人員溝通中，強調(diào)測試進度及修改速度的重要性，督促企業(yè)人員盡快再次報送相關(guān)修改結(jié)果，保證測試按測試計劃完成。
（3）加強對測試人員測試方法相關(guān)知識的培訓(xùn)，要求測試人員主動翻閱歷史測試經(jīng)驗的積累記錄，充實經(jīng)驗方面的不足，并向有經(jīng)驗的人員請教。
（4）嚴格按照軟件文檔的要求搭建測試環(huán)境，盡量避免測試環(huán)境出現(xiàn)故障，安排1名維護人員（兼職），當測試環(huán)境出現(xiàn)故障時，盡快安排維護人員整修、排除故障，盡量減小對測試進度的影響。
6、測試風險控制及實際測試情況
在進行測試的過程中，我們會對已識別出的測試風險的狀態(tài)進行跟蹤，監(jiān)控測試風險的發(fā)生，做好對測試風險的監(jiān)督控制，及時應(yīng)對已發(fā)生的測試風險，并深入分析，繼續(xù)識別新出現(xiàn)的測試風險，復(fù)審測試風險應(yīng)對計劃措施的執(zhí)行情況和效果，根據(jù)實際情況修改測試風險應(yīng)對計劃措施，對新識別的測試風險，制定新的測試風險應(yīng)對計劃措施。
在實際測試時，我們對已出現(xiàn)的測試風險按照測試風險應(yīng)對計劃措施做好了相應(yīng)的應(yīng)對措施，效果十分明顯，有效的避免了測試風險對測試的影響或把測試風險的影響降到了最低，但還是由于企業(yè)原因，企業(yè)再次報送相關(guān)修改結(jié)果過慢，影響了測試進度，我們對晚報送的修改結(jié)果進行了加班測試、并添加測試人員的應(yīng)對措施，雖然根據(jù)測試計劃規(guī)定，實施測試的時間延期了1天，但我們縮短了出具測試報告的時間，使得測試任務(wù)按時圓滿的完成了，測試結(jié)果得到了客戶的認可，而且，我們在測試的過程中給企業(yè)提出了許多規(guī)范、改善、優(yōu)化企業(yè)軟件開發(fā)或維護方面的建議，企業(yè)人員對我們的建議予以接受，同時，企業(yè)對我們的服務(wù)態(tài)度及服務(wù)質(zhì)量給予了高度的評價和贊揚，肯定了我們各方面的服務(wù)。
四、總結(jié)
通過對“鍋爐優(yōu)化燃燒專家診斷系統(tǒng)”軟件的測試風險管理案例的討論，論述了怎樣進行軟件測試的風險管理，總結(jié)了本人對軟件測試風險管理的認識和積累的經(jīng)驗，希望能通過本文使讀者有所收獲。
對軟件測試管理方面的研究，我們還要繼續(xù)努力，不斷加強測試管理方面的知識積累及探索，提高測試管理方面的能力和水平，使自己成為優(yōu)秀的軟件評測員及測試管理員。
參考文獻：
[1]《軟件測試方法和技術(shù)》作者：朱少民；出版日期：2005年7月；出版社：清華大學出版社
執(zhí)行標準：
[1]《GB/T 17544-1998 信息技術(shù) 軟件包 質(zhì)量要求和測試》
[2]《GB/T 16260.1-2006 軟件工程 產(chǎn)品質(zhì)量 第1部分：質(zhì)量模型》
[3]《GB/T 16260.2-2006 軟件工程 產(chǎn)品質(zhì)量 第2部分：外部度量》
關(guān)鍵詞：信息系統(tǒng)工程；監(jiān)理目標；模型應(yīng)用；控制
中圖分類號：C931文獻標識碼： A
一、信息系統(tǒng)工程監(jiān)理概述
信息系統(tǒng)工程監(jiān)理的定義是獨立于信息化技術(shù)產(chǎn)品生產(chǎn)、銷售與系統(tǒng)集成行業(yè)之外，并擁有足夠信息技術(shù)實力，有良好信譽的信息系統(tǒng)工程監(jiān)理單位。而信息系統(tǒng)工程監(jiān)理單位主要受到業(yè)主單位的委托，根據(jù)相應(yīng)的法律法規(guī)和信息系統(tǒng)工程建設(shè)合同，對信息系統(tǒng)工程項目的實施進行監(jiān)督。并且監(jiān)督環(huán)節(jié)是信息系統(tǒng)工程對建設(shè)單位所提供的針對，也作為信息系統(tǒng)工程領(lǐng)域中的社會治理結(jié)構(gòu)而存在，也是第三方結(jié)構(gòu)與信息系統(tǒng)提供規(guī)劃與組織、管理與控制、溝通與協(xié)調(diào)等方面具有重要作用。
信息系統(tǒng)工程監(jiān)理通常對項目進行全程監(jiān)理，并從需求進行分析，從而達到監(jiān)理方案的優(yōu)化，以及設(shè)備和技術(shù)方面的選擇。并且信息系統(tǒng)工程監(jiān)理還對組織管理、投資控制、糾紛調(diào)解和驗收測試等環(huán)節(jié)發(fā)揮作用，信息系統(tǒng)工程監(jiān)理的服務(wù)內(nèi)容包括項目的監(jiān)督和質(zhì)量控制，也可以作為某一專項環(huán)節(jié)的監(jiān)理服務(wù)工作。
二、信息系統(tǒng)工程建設(shè)的目標控制點
1、投資控制
工程投資控制就是在投資決策階段、設(shè)計階段、建設(shè)項目發(fā)包階段和建設(shè)實施階段,把建設(shè)項目投資的發(fā)生控制在批準的投資限額以內(nèi),隨時糾正發(fā)生的偏差,以保證項目投資管理目標的實現(xiàn),從而謀求在各個項目中能合理使用人力、物力、財力,取得較好的投資效益和社會效益。
2、進度控制
工程進度控制就是對工程項目各建設(shè)階段的工作內(nèi)容、工作程序、持續(xù)時間和銜接關(guān)系編制計劃,將該計劃付諸實施,在實施過程中經(jīng)常檢查實際進度是否按計劃要求進行,對出現(xiàn)的偏差分析原因,采取補救措施或調(diào)整、修改原計劃,直至工程竣工,交付使用。進度控制的最終目的是確保項目進度目標的實現(xiàn),項目進度控制的總目標是建設(shè)工期。
3、質(zhì)量控制
工程質(zhì)量控制就是為達到工程質(zhì)量要求所采取的作業(yè)行動與技術(shù)活動。工程項目質(zhì)量要求，主要表現(xiàn)為工程合同、用戶需求說明書、設(shè)計文件、技術(shù)規(guī)范規(guī)定的質(zhì)量標準。
三、目標控制的監(jiān)理重點
1、信息系統(tǒng)工程的投資控制監(jiān)理重點
信息系統(tǒng)工程實施階段投資控制的監(jiān)理重點，是通過工程付款控制、新增工程費控制、預(yù)防并處理好費用索賠、挖掘節(jié)約投資潛力,來努力實現(xiàn)實際發(fā)生的費用不超過計劃投資。為做好投資控制，信息系統(tǒng)工程監(jiān)理人員應(yīng)在軟件工程實施前協(xié)助業(yè)主認真審核軟件需求說明書。審核工作主要包括:
（1）承建單位和建設(shè)單位對實際需求理解上的偏差；
（2）需求說明是否能覆蓋用戶需求，內(nèi)容是否齊全、規(guī)范；
（3）建設(shè)單位對系統(tǒng)性能、系統(tǒng)接口、用戶界面、綜合查詢、軟件設(shè)計約束條件等方面的需求在軟件需求說明中是否有相關(guān)描述。
認真審核并盡早發(fā)現(xiàn)這三方面的問題和漏洞十分重要,而發(fā)現(xiàn)得越早就越易于更改。因此,及時發(fā)現(xiàn)、及時更改,對落實減少投資、避免返工,確保工程進度、工程質(zhì)量,都有正面重大影響。
此外，在工程實施過程中，建設(shè)單位的需求出現(xiàn)變化(例如:對系統(tǒng)性能提出更高的要求)通常是難免的。而這種需求變更所造成的投資變化比率，一般占投資總額的30%。為控制好變更費用，監(jiān)理工程師需憑借其豐富的專業(yè)經(jīng)驗，對相關(guān)方案進行仔細審查和適度優(yōu)化，并請承建單位提供選定方案的工程概算，供業(yè)主參考、決策。在處理索賠問題時，監(jiān)理人員在工程索賠方面要堅持“既要維護業(yè)主的利益，也應(yīng)不損害承包商的合法權(quán)益”原則，對工程量進行認真審查、復(fù)核后,簽認新增工作量。
2、信息系統(tǒng)工程監(jiān)理的進度控制監(jiān)理重點
為做好進度控制，信息系統(tǒng)工程監(jiān)理人員首先應(yīng)檢查系統(tǒng)開發(fā)組人員、配置管理人員的資質(zhì)和到位情況，審核承建單位所報周計劃和周報表，分析實際工作量與計劃工作量之間的差距，如若發(fā)現(xiàn)工程進度滯后，則應(yīng)要求承建單位增加資深或有經(jīng)驗的開發(fā)人員數(shù)量，從而趕上進度計劃。其次，要求承建單位依軟件測試計劃及早進行應(yīng)用系統(tǒng)軟件的各種內(nèi)部測試，要求承建方利用分階段交付方法及時向業(yè)主展示應(yīng)用系統(tǒng)的主要功能和特性，以便業(yè)主以自身特點及早發(fā)現(xiàn)不足提出新的性能或功能方面的要求。最后，定期核定工程量，請業(yè)主及時分期下?lián)芄こ炭钜彩潜ＷC工程按期完成的一項重要因素。在工程實施階段，必然會遇到大量的問題，這就需要監(jiān)理人員通過各種溝通方式協(xié)調(diào)多方關(guān)系，以期盡快解決遇到的問題，保證工程順利進行。
3、信息系統(tǒng)工程監(jiān)理的質(zhì)量控制監(jiān)理重點
信息系統(tǒng)工程實施階段質(zhì)量控制的主要任務(wù)，是通過對工程實施階段人員資質(zhì)、設(shè)備、測試方式、方法實施全面控制，以期按標準達到預(yù)定的工程質(zhì)量要求。為做好質(zhì)量控制工作，信息系統(tǒng)工程監(jiān)理人員從跟蹤需求調(diào)研到需求報告評審，從檢查設(shè)計文檔和編碼、測試以及對程序進行測試檢查，到最后協(xié)助用戶進行系統(tǒng)驗收，其中各個環(huán)節(jié)都要仔細控制。對軟件的測試是對信息系統(tǒng)工程質(zhì)量控制的重要一環(huán)。承建單位內(nèi)部在應(yīng)用系統(tǒng)代碼實現(xiàn)階段所進行的單元測試和集成測試不作為監(jiān)理檢查監(jiān)督的重點，具有軟件測試資格的監(jiān)理工程師測試的重點是對應(yīng)用系統(tǒng)功能和性能進行的系統(tǒng)測試和驗證用戶需求是否被覆蓋的驗收測試。其主要工作是審查承建單位提交的測試計劃和測試用例，根據(jù)軟件測試理論檢查測試用例是否能覆蓋項目建設(shè)合同中對系統(tǒng)功能和軟件需求說明書的要求，承建單位提交的測試計劃是否合理；審核承建單位提交的系統(tǒng)測試分析報告；要求承建單位及時提供用戶手冊和操作手冊等相關(guān)文檔。
四、信息系統(tǒng)工程監(jiān)理目標控制模型的應(yīng)用
信息系統(tǒng)工程的監(jiān)理環(huán)節(jié)具有較高的復(fù)雜程度，因此單一的模型很難對監(jiān)理體系的整個體系進行充分概括。通過對傳統(tǒng)建筑工程監(jiān)理環(huán)節(jié)進行借鑒，并通過結(jié)合信息系統(tǒng)工程的特點，充分應(yīng)用新型軟件工程項目管理技術(shù)，需要從兩個維度對信息系統(tǒng)工程監(jiān)理模型應(yīng)用進行介紹：
1、時序維度的監(jiān)理實施模型應(yīng)用
該模型的基礎(chǔ)是監(jiān)理工作的時間順序，并通過信息系統(tǒng)工程的生命周期，主要分為三個階段：前期監(jiān)理、中期監(jiān)理和后期監(jiān)理。前期監(jiān)理主要的工作是更多的了解信息系統(tǒng)工程的意義，并對參與招標的建設(shè)單位提供有效的保住，在招標的同時，提出重要功能和總體目的。并對初步方案進行擬定，以及對實施技術(shù)的考察環(huán)節(jié)進行負責。中期監(jiān)理則是根據(jù)信息系統(tǒng)工程不同的情況，具有差異性。差異性主要體現(xiàn)在信息系統(tǒng)工程與組織的關(guān)系方面，組織的支持是信息系統(tǒng)工程成功實施的基礎(chǔ)保障，因此中期監(jiān)理的主要任務(wù)是對監(jiān)督軟硬件設(shè)備的采購情況，以及實施計劃進行詳細的審核。并對具體項目進行風險控制，檢驗具體項目的關(guān)鍵性因素，并對符合要求的項目簽署合格證書，以此來保證工程質(zhì)量。后期監(jiān)理主要是對整個施工過程進行充分的記錄，并在完工之后進行有效的分析，從而對施工結(jié)果進行評判，并對整體工程監(jiān)理過程進行總結(jié)概括。
2、管理維度的監(jiān)理實施模型應(yīng)用。與時序維度的監(jiān)理
實施模型不同的事，項目管理維度的監(jiān)理實施模型更傾向于管理職能，并可以在監(jiān)理的過程中充分借鑒相關(guān)的管理學理論，從而充實項目管理的科學性。并通過項目管理使得信息
系統(tǒng)工程的各個環(huán)節(jié)能夠充分合作，并對各個環(huán)節(jié)的需求進行充分的滿足，能充分的優(yōu)化資源利用。但項目管理維度的監(jiān)理實施模型應(yīng)用需要具有充分的管理知識以及應(yīng)用領(lǐng)域的專業(yè)知識。工程監(jiān)理工作本身便屬于管理的范疇，如果將工程分為基本工程和支持工程，則工程監(jiān)理對象屬于基本工程，而監(jiān)理環(huán)節(jié)根據(jù)自身監(jiān)督、評價和調(diào)理的定義，更接近支持工程的范疇。因此項目管理維度的監(jiān)理實施模型應(yīng)用需要具有成熟的項目管理知識，并結(jié)合不同項目的特點，制定相應(yīng)管理戰(zhàn)略，從而完善整個項目管理體系，加強信息系統(tǒng)工程監(jiān)理體系的指導(dǎo)意義，有效的保證工程監(jiān)理環(huán)節(jié)對工程質(zhì)量的控制。
結(jié)語
隨著我國工程建設(shè)監(jiān)理制度的發(fā)展，我國的信息系統(tǒng)工程監(jiān)理也得到了長足的進步。而通過對信息系統(tǒng)工程監(jiān)理工作的特點，以及信息技術(shù)服務(wù)的相應(yīng)技術(shù)參考模型進行分析，能夠有效地對信息系統(tǒng)工程監(jiān)理技術(shù)參考模型的基本要素及構(gòu)成進行研究，從而使得技術(shù)參考模型給我適合監(jiān)理國家標準。
