軟件測試用例設計方法之切面設計(2)

　　(3)、GUI界面的測試

　　這類測試是測試人員的強項，具體測試項目如限長、非法輸入等等，就不必贅述了。要提醒的是在測試時，一定要從實際使用者的操作習慣出發。要知道界面原型所能確定的也只是頁面的擺放顯示，而實際操作時的控制實現仍是編碼人員自行實現的，即使有編碼指南，其所及范圍也是十分有限。而許多編碼人員在用戶操作方便性上的考慮往往差強人意。所以測試人員就必須要把好這一關。

　　(4)、數據初始化情況測試

　　不該為空的數據是否有校驗;該有默認值的數據默認值是否正確;引用其它功能生成的數據，是否會實時刷新;頁面關閉或系統重啟后，數據的初始化設置等都是這類用例。

　　(5)、業務需求實現是否正確

　　這類問題往往是由于我們的需求說明欠詳細，而編碼人員的需求了解程度又較低造成。作為測試人員自然要對需求進行深刻研究，來對軟件實現進行把關。這里常見的一些關注點有：

　　u 數據的長度、類型控制是否合理(比如控制納稅人識別號只能為數字，但實際業務中是會有字母出現的);

　　u 業務邏輯控制是否合理(比如某數據項不提供修改，但實際業務中該數據項經常會需要改動);

　　u 提供的實現方式是否合理(比如只在某一頁面提供某數據的獲取功能，但根據業務劃分有些人員不能操作此頁面，卻必須要能看到該數據);

　　u 所做的數據控制是否合理(比如必須在A功能中新增數據，然后才能在B功能中操作，但實際業務中有可能會出現相反操作);

　　u 所做的數據控制是否完整(如授權的方式有普通按月、有買斷、有按數量控制，那么當同一企業嘗試同時存在以上幾種授權方式時，系統是否能有必要的控制);

　　u 還有其它一些操作細節上的滿足(如業務上需要批量操作的數據有否提供批量操作功能、導入失敗的結果文件是否能修改后直接再導入等)。

　　對于不滿足的需求，經開發組長、需求經理等確認不作修改的，就要作為軟件的缺限或限制在測試報告中進行說明民。

　　2、功能切面隱含測試項用例設計：

　　(1)、數據完整性的測試

　　當某數據被其它功能引用;或當前功能要引用其它來源的數據，就會涉及到數據完整性的測試。最常見的如被引用的數據刪除了，或關鍵字被修改了，引用的數據會否出錯;兩個途徑進入的數據會否沖突或重復;此外還有因為相關的幾個功能由不同人員編碼，從而導致彼此的控制不一致，如A功能進入的數據在可允許的極端情況下，到B功能中引用會否異常(最常見如用戶名錄入時允許長度10，但引用到某個單子填寫時允許長度是8，此時就會異常了)。

　　(2)、后臺的特殊處理

　　是指某功能除了表面所見以外的程序處理。比如訂單錄入，表面所見的就是訂單的保存，但后臺還會有重復數據的判斷、非法數據的處理、業務邏輯上沖突情況的處理以及其它種種根據需求設計所特有的處理。又比如備份功能，在備份前可能有數據的清空、備份目錄的清空、備份目標是否存在的校驗、備份文件重復時的處理等等。類似這些在分析設計中就未必會寫全了，還是要測試人員多花心思去思考挖掘。

　　(3)、功能業務之間的關聯與轉換

　　相關聯的幾個功能之間數據的傳遞，會否產生影響。比如新增錄入的某種特殊字符，要查詢時會引起查詢SQL語句異常;又如某下載文件名中存在中文等字符，下載時由于編碼問題導致亂碼的出現;再有報表填寫時到小數點后四位，生成報文時會不會被忽略成兩位了等等。象這種問題，通常只能是在每個功能設計用例時，盡量保證用例中的數據能涉及到允許范圍的各種情況，即充分運用等價類劃分+邊界值的方法設計出各種“稀奇古怪”的數據，并需驗證這些數據從頭流到尾，都還是能保持其正確性，而不僅僅是在當前功能中正確。

　　(4)、從設計實現發掘測試點

　　這個就是我們測試中最難捉的BUG了，它往往是由編碼人員自己在編碼時創造出來的，連設計人員都不會知道。

　　比如內部管理系統中，正常的產品，其類別通常是2位數字;如果是模塊，其類別就以產品代碼來取代。這時如何來判斷該產品是模塊呢?最保險的當然是校驗其產品類別字段的值能否在產品表中找到;也有比較簡單的方法就是直接判斷類別代碼大于2位還是小于等于2位。此時若能確切知道采用的是哪種實現方法，就可以直接找到其漏洞所在。比如采用后一種方法，當產品類別長度變化時，明顯系統會出錯。那么即使確認該實現方式不改，測試人員也應將其作為限制寫入測試報告，。讓大家知道這個產品類別長度是不能隨意變化的。

　　而讓人郁悶的是，類似這樣的實現，有太多的編碼人員都是隨性處理的，它們細而隱蔽，在系統數據正常情況下根本不會被發現;而在漫漫的軟件使用道路中，由于需求變更等原因對原有一些設計做維護變化，這種問題就會突然暴發出來讓人措不及防。所以要杜絕這類漏洞，除了測試人員要做土撥鼠，不停地對軟件各功能的實現細節進行挖掘外，也要多給編碼人員灌輸完美實現的理念，多用復雜但抗壓性高的代碼，來替代簡單但依賴性強的代碼。

　　(5)、并發操作時的測試

　　即兩個或多個用戶同時操作同一功能時，會否引起數據的混亂。通常在C/S結構下，如果有同時操作的可能，是需要作此測試的;而在B/S結構下由于其特殊性，此問題通常難以解決。除非就是某用戶一旦使用過某功能后，在一定時間內鎖定不允許再用，但這也會帶來實際應用中的不便，所以除非是特別核心的數據，一般我們也不會去做此控制，當然對于可能出現的并發沖突也就作為系統的限制進行遺留了。

　　3、特定切面用例設計

　　所謂特定切面，其實就是從另一個角度切割出來的用例面，所以具體的用例撰寫方式其實與功能切面是一致的。

　　4、隱含切面用例設計

　　隱含切面分以下幾種情況：

　　(1)、無界面的后臺功能

　　對這類測試項，需要通過參數設置、代碼調用等方式來實現測試，但具體的測試設計其實與普通功能測試并無二致。這里要注意，因為測試時往往前臺、后臺是分開來分別進行的，而實際運行時兩者很可能是交集的，所以測試時要多注意后臺功能的執行與前臺的一些功能執行會否產生沖突?比如后臺有個文件搬運的服務，那有沒有可能在前臺文件生成過程中，后臺執行文件搬運了?若有可能就要注意會否出現問題了。

原文轉自：http://www.anti-gravitydesign.com