目前市面上的不少軟件都會用到多方登錄或者編輯的並發性問題，針對並發性問題有若幹種方法，主要有以下幾種：

• 保守方式：這種並發性模型在數據上加了鎖。如果一個用戶已經打開了一條記錄，那麽在允許編輯的環境中，系統就會拒絕來自其他用戶的讀取數據請求。適用於出現一個以上用戶同時編輯相同數據的情況。（缺點：當一個用戶已經打開某個數據時，其他用戶就不能訪問它了，這樣導致了系統在使用上有些不方便。由於系統需要管理這些記錄鎖，所以模型在實現上也會有一定的復雜度。）
• 開放方式：總是允許用戶讀取數據，甚至還可能允許更新數據。但是用戶試圖保存數據時，系統會檢查自從這個用戶檢索數據以後是否有其他人更新過數據。如果有，那麽更新就失敗了。適用於不太可能出現多人同時修改同一數據的情況。（缺點：使用不便，用戶花費了大量時間來更新一條數據卻發現根本不能保存。此時必須要重新檢索記錄並重新完成修改。）
• 沒有並發保護：勝利屬於最後一個用戶。這種方法並不對多個用戶編輯湘潭的數據提供保護。（缺點：第一個用戶的修改結果將會丟失，此外，當兩個用戶試圖同時保存數據時，這種方法可能會導致數據損壞。）

對於不同的並發性模型，測試過程中應該關註的要點：

• 保守方式：主要關心的是驗證能否正確地取得、釋放加在記錄上的鎖，並且能正確處理應用程序中所有可能更新這條記錄的部分。這裏主要關心的是以下三個方面：

1) 鎖的獲得。關鍵是系統必須把鎖正確地分配給第一個請求的用戶。獲得鎖的操作是可以測試的：讓兩個用戶試圖同時進入編輯狀態，或者使用腳本來產生比如1000個或者更多的編輯數據請求，這些請求是幾乎同時的，以此來驗證只有一個請求獲得成功。

2) 鎖的效用。如果一個用戶獲得了鎖，那麽系統必須保證其他任何用戶不能用任何方法修改這個數據，其中包括對數據的更新和刪除。具體的驗證方法是：讓一個用戶打開一條記錄（進入編輯模式並且保持這個狀態），同時其他用戶在應用程序的所有地方試圖編輯、刪除或者以其他方式更新數據。系統應該拒絕所有其他用戶更新數據的企圖。

3) 鎖的釋放。測試人員必須驗證：當編輯數據的用戶釋放了這條記錄以後（無論是更新完畢還是取消操作），系統能夠成功地讓其他用戶使用這條記錄。釋放鎖需要註意的一個重要方面是錯誤處理，也就是持有鎖的用戶遇到錯誤（如客戶端系統崩潰了）的情況下，系統應該完成什麽樣的操作。鎖是否就失去了控制（處於無法釋放的狀態）？系統從釋放鎖的故障中重新恢復的能力需要重點考慮。

• 開放方式。更新是唯一需要關註的要點。測試開放的並發性的最佳方式是綜合使用手動和自動測試技術。

1) 在手動的方法中，兩個測試人員編輯數據，然後試圖同時保存數據。第一個用戶更新操作應該是成功的，但是第二個用戶應該得到一條消息，其內容是另一個人已經更新了數據，此時，他需要重新裝載數據並且重新完成修改操作。

2) 除了手動測試以外，還應該使用自動和海量的測試方法。為了保證開放的加鎖機制能夠使得同一時刻只有一個用戶更新了記錄，我們可以利用腳本發起成百上千的、幾乎同時發生的更新請求進行測試。其余的用戶都應該收到錯誤消息，消息內容類似於：因為另一個用戶已經更新了記錄，所以記錄不能保存。

3) 與保守並發模型一樣，測試人員必須保證對所有可能修改數據的地方，開放的並發性得到驗證。其中包括來自用戶界面的不同部分的記錄操作。

• 沒有並發控制。最簡單的也是最容易出錯的方法是系統不具備任何並發性控制。測試這樣的系統和測試開放的並發模型非常相似，區別只是：無論更新請求的順序如何，所有用戶都應該成功完成更新操作。在這裏也應該綜合使用手動和自動測試技術，但是在沒有並發控制的情況下，應該關註的是數據的完整性。測試人員還應該驗證是否正確地處理了更新錯誤，例如：當一個用戶試圖更新某條記錄時，它卻被刪除了。

淺談並發性模型的測試策略