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