系統升級測試模型

系統升級測試

隨着軟件行業敏捷開發的推動，軟件的版本迭代愈來愈快，升級測試在軟件測試中也變得愈來愈重要。升級測試是安裝測試的一個分支，主要檢驗軟件從低版本升級到高版本的能力，關注升級過程是否成功，用戶數據是否得以保留或更新，升級後系統文件是否更新、系統功能是否正常。

1.1升級測試 vs. 全新安裝測試

相對於軟件全新安裝來講，升級測試更爲複雜，主要的區別以下：

類別	全新安裝	升級測試
關注版本	一個（當前版本）	多個（多箇舊版本、當前版本）
測試前準備	沒有或不多	舊版本備份（數據、配置等）、模擬數據、模擬客戶環境等
執行過程複雜度	低（默認參數執行安裝）	高（版本驗證、新舊版本區別、參數的增減修改等等）
執行後驗證	迴歸測試	數據遷移和更新驗證、新功能驗證，迴歸測試

從圖表中可見，相對全新安裝，升級測試須要考慮的方面多且複雜，測試執行也須要更多的資源。

1.2升級測試中面臨的問題

升級測試很容易作，但作好卻很難。咱們常常會在升級測試中面臨各類各樣的困擾：

1. 如何準備升級前環境？
2. 客戶環境是怎樣的？
3. 怎樣創造數據？
4. 應該作到升級路徑全覆蓋仍是選擇性覆蓋？
5. 升級後如何驗證升級成功？
6. 升級後如何迴歸？

。。。。。。

面對這麼多問題，一開始總會讓咱們無所適從，那麼如何打開思路，進行高效升級測試呢？這就提到了升級測試模型。

2 升級測試模型

升級測試模型主要包括幾個測試階段：前期準備階段、升級過程測試階段以及後續的迴歸測試階段。每一個階段之間都有強關聯，在測試的過程當中須要特別注意，下面對各個階段進行展開介紹。

2.1升級前準備

升級測試前期準備主要包括：升級流程分析、環境搭建、數據準備以及備份策略。

 

• 升級流程分析：升級流程分析是測試準備中的一個重要關注點，就像產品功能測試的需求同樣，升級流程是很重要的升級測試需求來源。對於不一樣方式的升級流程而言，須要有不一樣的測試策略，好比對於如下的升級流程：

1. 文件替換升級：須要更關注文件替換後的版本更新，數據保留，迴歸策略等
2. 卸載-》安裝-》數據遷移：須要關注卸載安裝過程、數據的完整性，迴歸策略等

經過分析升級流程，畫出軟件升級的流程圖，並根據流程圖中的判斷邏輯建立邏輯路徑覆蓋測試用例，不只清晰並且不容易遺漏。（下圖來自互聯網）

 

因此在開展升級測試以前必定要對測試流程進行詳細的分析，以便在以後的升級測試中作到有的放矢。

• 環境搭建：對於升級前環境的搭建須要遵循20/80原則，由於不可能羅列全部用戶環境而且每一個都進行測試，建議的搭建策略：

1. 按照產品安裝文檔進行環境搭建
2. 分析客戶環境，對OS配置、第三方軟件及版本、產品舊版本、產品部署方式進行分析，選取具備表明性的環境配置以及典型的升級路徑

 

• 數據準備：升級前數據的準備對升級測試中數據完整性起到了決定性的做用，能夠經過如下幾種途徑來提升數據的覆蓋率：

1. 分析用戶使用場景，羅列經常使用場景並進行端到端的數據模擬
2. 分析客戶數據庫，針對數據表進行分析，得到經常使用場景
3. 若是版本合適，利用客戶的數據庫進行測試

 

• 備份策略：測試環境搭建好以後須要對數據庫、配置文件等進行備份，以便在後續測試中減小重複準備工做和進行升級先後的比較工做。

2.2升級過程驗證

升級過程測試階段依賴於升級前準備中的升級流程分析，不一樣的升級流程對升級過程的關注點也不一樣，本模型中羅列的是一些具備通用性的升級過程階段：版本檢查、軟件依賴檢查、安裝參數檢查、備份機制、產品模塊更新、用戶數據保留、文件版本檢查、升級日誌及失敗重試機制。

下面着重介紹比較重要的幾個驗證階段:

• 軟件依賴檢查：對於大型的軟件系統而言，通常都有所依賴的第三方軟件，好比說數據庫、.NET等。產品新舊版本之間可能用到的第三方軟件產品或者版本不一樣（在升級前準備階段的環境搭建中羅列），針對這種狀況，升級程序須要提供對第三方軟件的檢測，儘早給出提示信息，避免產品升級以後產品不能工做的狀況發生。

 

• 產品模塊更新：產品模塊的更新包括模塊的添加、更新和刪除。該部分的驗證須要更多依賴對於產品不一樣版本之間的分析和理解：

 

1. 對於升級前版本存在、新版本刪除的模塊，在升級以後須要刪除，包括安裝目錄、數據庫表、配置文件等。
2. 對於升級前版本不存在的模塊，升級後須要正確安裝
3. 對於須要更新的模塊，須要驗證安裝文件是否更新

 

 

• 用戶數據保留（完整性）：用戶數據的驗證主要包括數據庫和配置文件的驗證，主要的驗證方式：

1. 數據庫數據驗證：

a)       升級後新版本和以前版本數據庫中用戶數據的比較（檢查用戶數據是否保留）

b)      升級後新版本和全新安裝新版本進行比較（檢查數據庫結構是否一致）

c)        升級後新版本和全新安裝新版本數據庫默認數據進行比較（驗證默認數據的準確性）

對於數據庫的驗證包括數據庫的結構和數據的驗證：結構包括表、索引、視圖、存儲過程以及agent job等；數據的驗證主要包括對主要數據表的數據進行驗證。

由於這一部分是比較容易出問題的，這裏羅列一些比較好的實踐和注意點：

1)      針對數據庫比較龐大的系統，具體分析數據庫，獲取關注的數據庫表，忽略不關注表（好比一些能夠刪除的history或者log表）的數據比較。

2)      某些狀況下，數據庫在升級以後一些數據的id會變化，須要確保以該id爲foreign key的列也獲得相應的更新

3)      針對某些數據變化的列，須要特別注意分析業務邏輯判斷是否須要更改，好比某列的默認值爲0，用戶在使用過程當中修改成1，而新版本的默認值爲5，這就須要判斷升級後是保留用戶原系統的值1，仍是使用新系統的默認值5，這是須要特別注意的

 

另外針對數據庫的比較有不少好用的工具，如Visual Studio自帶的數據庫比較、DB Comparer等。

1. 配置文件的驗證：

a)       升級後新版本和以前版本配置文件進行比較（保證用戶在以前版本中的配置保留）

b)      升級後新版本和全新安裝新版本配置進行比較（保證配置結構和數據正確）

2.3非功能測試和負面測試

                               

                非功能性測試：這裏主要列出了性能方面的時間以及內存消耗。這部分在數據庫過大的狀況下數據遷移比較容易出現時間過長、內存佔用過大的狀況。

                負面測試：主要來驗證升級程序針對一些打斷或者邊緣狀況的處理能力，保證可以失敗重試，或者即便不能升級成功也能夠恢復到升級前的狀態

2.4迴歸測試

通過了升級過程的驗證，新版本已經安裝成功，這時候就須要驗證新版本是否可以工做正常。迴歸測試的級別和策略須要視產品性質而定，通常分爲：

1. BVT驗證：最基本的驗證測試，用來保證安裝完成後基本工做工做正常
2. 基於改動的功能驗證：該部分須要對升級先後的產品差別有清晰的瞭解，針對相應的改動有側重點的開展測試
3. 新功能驗證：針對新版本的新特性進行測試
4. 用戶數據驗證：有了對升級過程當中的數據完整性的驗證，能夠保證用戶數據得以保留，這樣還不夠，須要經過客戶端進行數據展示，保證展示正常

3總結

      升級測試模型提供了升級測試開展的一個突破口，針對升級過程當中的前期準備，升級過程驗證以及後續升級完成後的迴歸測試打開了一些思路，而且對1.2中升級測試中的問題提出了一些解決方案，但羅列的各個檢測點不必定適用於全部的產品，你們能夠在具體的測試過程當中有所取捨。

 

附錄：升級測試模型（upgrade testing model)