系統升級測試
隨着軟件行業敏捷開發的推進，軟件的版本迭代越來越快，升級測試在軟件測試中也變得越來越重要。升級測試是安裝測試的一個分支，主要檢驗軟件從低版本升級到高版本的能力，關注升級過程是否成功，用戶數據是否得以保留或更新，升級后系統文件是否更新、系統功能是否正常。
1.1升級測試 vs. 全新安裝測試
相對於軟件全新安裝來說，升級測試更為復雜，主要的區別如下：
| 類別 |
全新安裝 |
升級測試 |
| 關注版本 |
一個（當前版本） |
多個（多個舊版本、當前版本） |
| 測試前准備 |
沒有或很少 |
舊版本備份（數據、配置等）、模擬數據、模擬客戶環境等 |
| 執行過程復雜度 |
低（默認參數執行安裝） |
高（版本驗證、新舊版本區別、參數的增減修改等等） |
| 執行后驗證 |
回歸測試 |
數據遷移和更新驗證、新功能驗證，回歸測試 |
從圖表中可見，相對全新安裝，升級測試需要考慮的方面多且復雜，測試執行也需要更多的資源。
1.2升級測試中面臨的問題
升級測試很容易做，但做好卻很難。我們經常會在升級測試中面臨各種各樣的困擾：
- 如何准備升級前環境？
- 客戶環境是怎樣的？
- 怎樣創造數據？
- 應該做到升級路徑全覆蓋還是選擇性覆蓋？
- 升級后如何驗證升級成功？
- 升級后如何回歸？
。。。。。。
面對這么多問題，一開始總會讓我們無所適從，那么如何打開思路，進行高效升級測試呢？這就提到了升級測試模型。
2 升級測試模型
升級測試模型主要包括幾個測試階段：前期准備階段、升級過程測試階段以及后續的回歸測試階段。每個階段之間都有強關聯，在測試的過程中需要特別注意，下面對各個階段進行展開介紹。
2.1升級前准備
升級測試前期准備主要包括：升級流程分析、環境搭建、數據准備以及備份策略。
- 升級流程分析：升級流程分析是測試准備中的一個重要關注點，就像產品功能測試的需求一樣，升級流程是很重要的升級測試需求來源。對於不同方式的升級流程而言，需要有不同的測試策略，比如對於以下的升級流程：
- 文件替換升級：需要更關注文件替換后的版本更新，數據保留，回歸策略等
- 卸載-》安裝-》數據遷移：需要關注卸載安裝過程、數據的完整性，回歸策略等
通過分析升級流程，畫出軟件升級的流程圖，並根據流程圖中的判斷邏輯創建邏輯路徑覆蓋測試用例，不僅清晰而且不容易遺漏。（下圖來自互聯網）
所以在開展升級測試之前一定要對測試流程進行詳細的分析，以便在之后的升級測試中做到有的放矢。
- 環境搭建：對於升級前環境的搭建需要遵循20/80原則，因為不可能羅列所有用戶環境並且每個都進行測試，建議的搭建策略：
- 按照產品安裝文檔進行環境搭建
- 分析客戶環境，對OS配置、第三方軟件及版本、產品舊版本、產品部署方式進行分析，選取具有代表性的環境配置以及典型的升級路徑
- 數據准備：升級前數據的准備對升級測試中數據完整性起到了決定性的作用，可以通過以下幾種途徑來提高數據的覆蓋率：
- 分析用戶使用場景，羅列常用場景並進行端到端的數據模擬
- 分析客戶數據庫，針對數據表進行分析，獲得常用場景
- 如果版本合適，利用客戶的數據庫進行測試
- 備份策略：測試環境搭建好之后需要對數據庫、配置文件等進行備份，以便在后續測試中減少重復准備工作和進行升級前后的比較工作。
2.2升級過程驗證
升級過程測試階段依賴於升級前准備中的升級流程分析，不同的升級流程對升級過程的關注點也不同，本模型中羅列的是一些具有通用性的升級過程階段：版本檢查、軟件依賴檢查、安裝參數檢查、備份機制、產品模塊更新、用戶數據保留、文件版本檢查、升級日志及失敗重試機制。
下面着重介紹比較重要的幾個驗證階段:
- 軟件依賴檢查：對於大型的軟件系統而言，一般都有所依賴的第三方軟件，比如說數據庫、.NET等。產品新舊版本之間可能用到的第三方軟件產品或者版本不同（在升級前准備階段的環境搭建中羅列），針對這種情況，升級程序需要提供對第三方軟件的檢測，盡早給出提示信息，避免產品升級之后產品不能工作的情況發生。
- 產品模塊更新：產品模塊的更新包括模塊的添加、更新和刪除。該部分的驗證需要更多依賴對於產品不同版本之間的分析和理解：
- 對於升級前版本存在、新版本刪除的模塊，在升級之后需要刪除，包括安裝目錄、數據庫表、配置文件等。
- 對於升級前版本不存在的模塊，升級后需要正確安裝
- 對於需要更新的模塊，需要驗證安裝文件是否更新
- 用戶數據保留（完整性）：用戶數據的驗證主要包括數據庫和配置文件的驗證，主要的驗證方式：
- 數據庫數據驗證：
a) 升級后新版本和之前版本數據庫中用戶數據的比較（檢查用戶數據是否保留）
b) 升級后新版本和全新安裝新版本進行比較（檢查數據庫結構是否一致）
c) 升級后新版本和全新安裝新版本數據庫默認數據進行比較（驗證默認數據的准確性）
對於數據庫的驗證包括數據庫的結構和數據的驗證：結構包括表、索引、視圖、存儲過程以及agent job等；數據的驗證主要包括對主要數據表的數據進行驗證。
因為這一部分是比較容易出問題的，這里羅列一些比較好的實踐和注意點：
1) 針對數據庫比較龐大的系統，具體分析數據庫，獲取關注的數據庫表，忽略不關注表（比如一些可以刪除的history或者log表）的數據比較。
2) 某些情況下，數據庫在升級之后一些數據的id會變化，需要確保以該id為foreign key的列也得到相應的更新
3) 針對某些數據變化的列，需要特別注意分析業務邏輯判斷是否需要更改，比如某列的默認值為0，用戶在使用過程中修改為1，而新版本的默認值為5，這就需要判斷升級后是保留用戶原系統的值1，還是使用新系統的默認值5，這是需要特別注意的
另外針對數據庫的比較有很多好用的工具，如Visual Studio自帶的數據庫比較、DB Comparer等。
- 配置文件的驗證：
a) 升級后新版本和之前版本配置文件進行比較（保證用戶在之前版本中的配置保留）
b) 升級后新版本和全新安裝新版本配置進行比較（保證配置結構和數據正確）
2.3非功能測試和負面測試
非功能性測試：這里主要列出了性能方面的時間以及內存消耗。這部分在數據庫過大的情況下數據遷移比較容易出現時間過長、內存占用過大的情況。
負面測試：主要來驗證升級程序針對一些打斷或者邊緣情況的處理能力，保證能夠失敗重試，或者即使不能升級成功也可以恢復到升級前的狀態
2.4回歸測試
經過了升級過程的驗證，新版本已經安裝成功，這時候就需要驗證新版本是否能夠工作正常。回歸測試的級別和策略需要視產品性質而定，一般分為：
- BVT驗證：最基本的驗證測試，用來保證安裝完成后基本工作工作正常
- 基於改動的功能驗證：該部分需要對升級前后的產品差異有清晰的了解，針對相應的改動有側重點的開展測試
- 新功能驗證：針對新版本的新特性進行測試
- 用戶數據驗證：有了對升級過程中的數據完整性的驗證，可以保證用戶數據得以保留，這樣還不夠，需要通過客戶端進行數據展現，保證展現正常
3總結
升級測試模型提供了升級測試開展的一個突破口，針對升級過程中的前期准備，升級過程驗證以及后續升級完成后的回歸測試打開了一些思路，並且對1.2中升級測試中的問題提出了一些解決方案，但羅列的各個檢測點不一定適用於所有的產品，大家可以在具體的測試過程中有所取舍。
附錄：升級測試模型（upgrade testing model)
