測試分析與設計模式(2)

　　實現特性視角

　　從實現特性角度上討論抽象工廠，其要注意的是與動態綁定如plug-in等等方式的合用。動態綁定方式雖然在實現上提供了非常靈活的運行時的行為決定能力;但是其帶來的穩定，效率，易讀和維護性上的風險。 特別是抽象工廠模式將使用者與實現者在2個不同緯度上隔離開，這將使得問題的定位變得困難。

　　從測試角度分析要測試的點時，應該對抽象和繼承的對象創建方法進行測試。 特別是與動態綁定合用時。同時應該特別注意對抽象工廠和繼承的具體工廠類進行對象創建的回歸測試。因為代碼的變更和維護比較容易引起方法語義的變化，從而對抽象工廠的使用者帶來影響。

　　所有的創建相關的模式在具體實現上都應該考慮內存/資源的分配，競爭，以及并發的情況。

　　錯誤模型視角

　　對于上層語義來說，抽象工廠應該特別考慮，避免抽象類定義中混淆進繼承類的特性。比如方法中包含特定繼承類實現的功能的定義和依賴。 在測試分析中應該對抽象工廠類，以及繼承于該抽象工廠類的具體工廠類中的方法，屬性進行推敲，確定只有不依賴于特定實現的方法和屬性才能存在于抽象工廠類中。 具體到測試分析活動中，對方法和屬性的語義進行“測試”，“測試”其是否對于各種具體實現是“通用”的。

　　對于邏輯算法來說抽象工廠一般不包含復雜的業務邏輯。 具體的業務邏輯往往存在于具體的工廠類中。所以對于邏輯的正確性的測試應該更多的對具體工廠類進行。

　　對于抽象工廠模式，由于其根本上是創建對象的方法。所以從可能的錯誤情況來看，對象創建的失敗情況是必須要仔細測試的。 對于創建失敗的情況，不僅僅要測試當獲取資源失敗的情況下的創建失敗，還應該測試在不合適的環境/前提下的創建失敗。(比如在Linux環境下創建為windows適配的對象)

　　對于對象的創建失敗，在一個對象包含多個資源的情況下，應該設計測試用例測試某個資源獲取失敗后，對已經獲取的資源的釋放情況。

　　更加進一步，取決于實現邏輯和方法，當實現邏輯中運用到或者有可能受外部環境(軟件/硬件)影響時，考慮對象創建中的單態，中斷，并發，超時，溢出等等情況。

原文轉自：http://www.kjueaiud.com