功能子產品的驗收測試

目前期研發的功能子產品受到使用者的認可以後，需要這些功能子產品作為更大系統的組成部分融入到新的大系統之中。此時需要按照大系統的技術體制對現有開發的子產品進行改造，改造完成以後，再由大系統的測試部門對這些子產品進行驗收測試。子產品驗收測試的流程是先技術體制符合性檢查、再代碼靜态檢查、最後進行功能測試等内容。按照規定隻有上一階段的錯誤歸0後，才能進入下一階段的測試，版本更新後必須進行回歸測試。

整個組織流程如下：開發人員将webapp打包後入庫->系統配置人員進行菜單配置->系統部署人員将應用部署至測試環境->測試人員在測試機上進行測試和記錄問題，開發人員從旁講解協作->開發人員修訂系統，完成後傳回至第一步。

大系統一般會提供子產品內建架構、內建規範、底層的公共服務等，新的功能子產品改造後作為其架構上的插件進行使用。

技術體制符合性檢查

這裡一般會包括：

l  界面規範檢查：檢查子產品的前端界面是否符合開發規範，包括字型、顔色、配色方案、底色等，能夠使得新的子產品與原系統架構和子產品在界面上統一和和諧一緻；

l  資料通路規範檢查：由于資料的私密性，功能子產品不能直接通路資料庫，而必須通過一個統一的中間層架構進行通路，這個中間層大系統可以進行統一的管理和規範，子產品需要根據自己的需要開發中間層的實作注冊至資料通路管理架構之中；

l  資料庫設計規範檢查：包括庫名稱、表名稱、字段名稱、注釋、限制等要求，要求保證資料的一緻性，即子產品從大系統中的公共資料庫中擷取資料持久化至子產品私有庫時，如果公共資料庫的資料發生變化，私有庫的資料可能存在不一緻的風險和隐患；

l  服務規範性檢查：當子產品提供服務給其他子產品使用時必須通過服務架構進行，每個子產品需要按照服務開發規範開發的服務，注冊至服務架構供其他人或自己使用。子產品調用服務也必須通過服務架構進行。其注冊和調用過程由服務架構管理和監控；

代碼靜态檢查

使用商業的軟體，如klocwork進行，安裝其要求，不能有1~4級的錯誤，待錯誤歸0後，可以申請功能測試。Klocwork支援java、c、c++和c#語言，對代碼分析比較快，分析結果能夠導出為word或者Excel，同時給出代碼修改的建議。建議編寫代碼的工程師可以将自己的寫的代碼自己拿去用klocwork分析，對代碼編寫能力的提升會有不小的幫助，寫出能通過其測試的代碼也算是老鳥了。

這裡值得注意的是，由于知識産權的原因，子產品開發的源代碼并不送出給大系統總體，代碼審查結果可能存在開發人員隐瞞的情況（如将部分代碼私自隐藏，不參與代碼審查等手段）。而且對于web應用開發而言，klocwork隻能測試背景代碼，前台的JavaScript代碼并不支援，這對于有大量的前台代碼的web應用而言也不太合理。

功能測試

按照功能測試的用例，對子產品進行測試，同時對界面上可以點選的按鈕和連結、可以輸入的框等都要進行測試，模拟最終使用者的使用過程，有時候還得配合使用資料庫進行查驗。

這裡沒有說到性能測試，因為系統性能和伺服器的配置、網絡狀況等相關，而現在的伺服器是基于windows虛拟機的應用伺服器，伺服器資源不足，并且時間非常緊張，是以大系統暫時沒有要求和測試。