現在基本每個項目都開始或多或少的有自動化測試用例了，當然也就有了一些測試框架，還有一些比較有名的開源框架比如，selenium staf等等，如果目前項目中你要負責開發一款自動化測試框架呢，前段時間負責一款接口測試自動化測試框架的設計開發，它不同于以往我開發的測試框，他是和數據庫打交道的，所以如何讓準備數據更靈活更方便是我著重考慮的，目前開發已完成并且很好用。哈哈
正好在著說說測試框架設計
測試框架，目前業內來看就三種：
1、錄制回放的框架
2、數據驅動的框架，這種框架又分為數據和用例分類和數據與用例為一體，當然他們各有利弊
3、關鍵字驅動的測試框架
總的來說，第一種最簡單，但是缺點也很明顯，不以維護，第二種和第三種不相伯仲，需要根據具體的問題具體分析，但是第三其實有一些人工智能的影子，可以代碼生成代碼，BDD測試（Behavior. Driven Development）框架，比如jbehave easyb其實就可以看做關鍵字驅動的測試框架
數據驅動的測試框架，在上個我負責的項目中，實際我也是使用這個方案的，數據驅動的框架中，數據時重點，如何讓用戶更容易的造數和是用他是你框架成功與否！這里大家簡單來看其實就是一個三層結構，數據準備層，測試過程規范層，drive層，負責執行等等
這里的數據是否分離呢，其實這個問題是沒有更好答案的，要具體問題具體分析，因為數據如果分離，以后的case變化可能只需要維護數據，case的代碼是不用動的。當時你能控制的是數據塊，可能是一個文件等等，不方便深入到數據的內部。如果不分離好處是，你在case中一眼能看到你的數據，你想測試的是什么，并且整個測試過程是你可見，測試數據完全可控制的，比如一個log，已\001分割，你可以完全控制log中分割的每個字段。但是會增加維護的成本，目前我剛開發完成的框架支持以上兩種數據提供，測試人員根據具體情況使用
關鍵字驅動框架，如果需求是數據和業務case盡可能的分離，那第三種方式是比較適合的，它可以保證業務與實現分離，數據與業務分離，層次清晰，易于維護。
大家還可以嘗試一下代碼生成代碼，在上個我寫的框架中，就運用了這個方法，很多common的東西，有固定格式的項目的具體的代碼文件都可以考慮用代碼生成代碼，能很大限度的提高效率。
版權聲明：本文出自 shadowwalker 的51Testing軟件測試博客：http://www.51testing.com/?622454
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。