軟體測試藍圖：軟體測試理論到實戰進階，一篇文章就夠了
來自專欄 西說測試
測試現在被普遍認為「保證產品質量」這個籠統的說法下，而測試本身是什麼呢？今天我們就測試本身跟大家一起討論。
測試是在研發產品的整個過程中的一個跟蹤活動,他在各個階段報告給人們當前項目的狀況,能夠督促和提示項目經理或者高層經理對項目的關注點.
國內的測試的定義,一般是在產品的研發後期,對產品的功能進行驗證的一個系列活動。
國外的測試已經發展比較成型了，而國內的測試現在還處於摸索階段，至於超著那個方向去發展，我覺得大家目前還是處於比較迷茫的階段。
主要原因是：國內軟體產業起步晚，而且質量意識不強，造成了軟體工業發展緩慢，配套行業（測試發展緩慢），我覺得這個很正常，因為從人類歷史發展的角度來看，這個是必須經歷的階段，從有這個概念到摸索，目前國內的測試應該處於沉思期，主要是沒有一個全套的指導思想，另外一個原因是行業發展方向不明朗。
國內存在對測試的誤解，所以造成了測試現在成了大家進入企業的跳板，要麼就是覺得自己的能力還不夠，目前只能從事測試，要麼就沒有編寫程序的能力，但是同類產品比較了解，所以做測試。
如果我們把測試的方法整理成技術，那麼他形成一個規則或者說是一個標尺，我們只是分析什麼樣產品的需要用什麼方法來測試，而且需要了解的知識架構是什麼？怎麼把這些知識穿插起來，那麼積累就不會被約束，但是不能撇開經驗，因為經驗本身是設計出好的案例的基礎，但不是唯一的基礎。
我們再來看看測試案例的設計，測試案例的設計在國內現在是一些剛剛入行的不會寫程序或者程序功底比較差的人在寫案例，那麼這些人設計出來的案例只是包含了整個測試過程中功能測試的一部分案例而已，因為他們不懂得或者不理解程序，不是從原理上去分析產品，不是從邏輯上去分析產品，而是從用戶使用的角度去分析產品，這樣設計出來的案例的可行性和可信度多大呢？大家可想而知了。所以我們在整個引導大家的過程中，從技術和方法，結合具體實例和針對不同類型的產品的測試方法進行跟蹤和描述。
首先，什麼叫測試？測試幹什麼？
測試，是在開發過程中的一種活動，它是分白盒測試和黑盒測試。在不同的階段不同的人所承擔著測試這個角色，我們把整個活動統稱為測試。
測試的工作內容主要包含了設計測試計劃，設計測試案例，執行測試，進行測試總結。
執行測試是在產品開發的整個過程中進行的，包括了單元測試，系統測試，集成測試，系統測試和驗收測試，那麼不同的階段測試的重點不同。
單元測試的重點是函數級，包括需求，包括演算法，包括介面預留等內容。
集成測試是指把小模塊結合起來，測試的重點是輸入輸出數據，參數的處理，錯誤預處理，介面規範，參數約束等測試內容。
系統測試的重點是功能性質，它的測試重點是按照需求來對照測試， 主要是功能實現的情況，包括功能使用邏輯和操作邏輯，操作系統，兼容性（軟體和硬體）等內容。
驗收測試，主要是合同性質而言的，在國外現在軟體外包情況比較多，那麼雙方按照合同規定履行自己的職責，把功能按照合同約定的形式條條比對。這是主要方面，那麼在企業內部，驗收測試是除了功能驗收以外，還包括易用性，軟體的親和度等方面的內容。
測試的分類
單元測試
單元測試是在測試過程中的最小粒度，它在執行的過程中緊密的依照程序框架對產品的函數和模塊進行測試，包含入庫和出口的參數，輸入和輸出信息，錯誤處理信息，部分邊界數值測試。
這個部分的測試工作在國內現在是開發人員進行的。我相信未來的發展應該是測試工程師來做這個事情。那麼需要測試人員需要深刻的理解程序，理解需求，理解設計，這樣才能發現問題。
還有一種在國內先在操作的方法，就是當一個模塊給某個開發工程師以後，需要他給大家講解他要完成這個模塊或者函數的整體流程和思路，進行統一評審，使得問題能夠暴露的更充分些，這樣做的目的有以下個。
第一，使得大家對設計者的思路明晰的理解，以便以後調用或者配合的時候能夠真切的提出需求或者相對完美配合。
第二，在評審的過程中，如果發現問題，那麼大家可能沒有犯過，這樣就會更加提高警惕，如果犯過，就會回想當時自己怎麼解決的或者規避的，使得大家能夠在錯誤的過程中快速提高。
第三，可以對平常犯錯誤進行一個積累，我覺得這是生動的教科書，可以使得新的人員在新上手的時候遇到這樣的問題以後，我們就可以給他一個解決問題的方法或者方向。
回顧，我們上面給大家介紹了兩種方法，第一種就是通過在開發的過程種進行測試，由開發（測試）工程師寫測試代碼，對所編寫的函數或者模塊進行測試，第二種就是通過代碼互評發現問題，將問題進行積累，形成知識積累庫，以便使得新人在同樣的方面不至於再犯錯誤。
單元測試非常重要，因為他影響的範圍和寬度比較大，也許由於一個函數或者參數問題，造成後面暴露出很多表象問題出現。而且如果單元測試做不好，使得集成測試或者後面系統測試的壓力很大，而且項目的費用和進度可能就會飈升。
對單元測試，現在用CPPUnit的比較多，市場上也有其他對應的產品，他們在不同的軟體單位不同的階段。正確的理解單元測試的重要性是意識，需要在過程改進種不停的總結，慢慢的積累，將質量意識滲透到整個開放過程中的各個環節。
保證單元測試順利進行，需要滲透軟體工程的很多思想，把CMM和跟蹤機制建立起來，問題的分類、跟蹤，如果把軟體環節整個活動都滲透了，那麼產品質量的意識自然就增強了。
COM思想現在在大的項目現在體現的淋漓盡致，因為如果不採用COM機制，維護和升級以及修改測試的成本很大，所以現在大型項目基本上都採用COM的組織形式。
說了這麼多，單元測試做什麼呢？單元測試主要是做一下幾個事情：
第1， 模塊或者函數的設計稿
第2， 代碼規範，其中包含代碼書寫規範，對齊方式
第3， 代碼的注釋。非常重要
第4， 參數類型，數據長度,指針，數組長度大小
第5， 輸入輸出參數和結果
第6， 創建對象後是否刪除了，如果在這裡沒有刪除，請註明在那裡刪除
第7， 是否應用了沒有初試化的變數，如果是，請指明該變數在那裡初始化
第8， 變數是否聲明，聲明是否按照要求進行
第9， 調用此函數需要的滿足條件需要註明
第10， 在此函數或者模塊中用到了系統或者其他第三方插件函數，需要滿足的系統條件
上面我只是列舉了一些在測試過程中發現或者隱藏的問題，我想可能還有很多情況引發問題，請大家補充，以便在工作中有操作性。
集成測試
集成測試是在保證單元測試進行後進行的一個動作，能否集成的標誌不是所有的代碼編譯通過了就算是可以集成了，而是所有的能夠在這個虛擬環境下能夠正常運轉。
在集成測試種一般採用的方法是數據驅動或者樁驅動，因為集成測試不能看到產品的表象，因為他是一些數據流的中間段，我們渴望能夠對中間數據進行分析，就可以知道或者就渴望知道流程或者演算法中有什麼不妥當的地方。
集成測試比較適合做成自動化測試，當然首先我們分析了適合做自動化的條件是滿足的，我這裡就不講詳細的方法，到後面的自動化測試介紹中，我會提到這個方面的問題。下面和大家一起揭開測試自動化的神秘面紗以及給大家講一些構建冒煙的概念。
冒煙測試的出處是，由於生活習慣等原因，人們會定期的做某個事情，就像人們會約定成俗的認為12:00是吃飯下班的時間。那個時候大家都會做飯，哈哈，自然會從煙囪冒煙。
在軟體行業裡面的約定是當產品到達某個階段之後，為了驗證產品的各個部分的銜接程度，為了驗證項目的進展程度，為了驗證產品的（已完成）功能的全面穩定程度，由測試主導的一種測試方法，主要的操作就是，在產品開發計劃定製完成以後，依照開發計劃指定完整的編譯計劃，按照開發計劃和編譯計劃，各個單位按照要求完成自己的作業，然後在編譯點上驗證完成程度。
集成測試也是不可缺少的一個部分，很多單位為了趕進度，會將這個部分省略掉，就甩手給測試小組，如果沒有對應的測試小組，就會是程序員進行簡單的使用後就交付市場，危險，這是個定時炸彈。因為他時刻有可能產生市場對企業影響的額度，以及企業本身的聲譽問題。
集成測試是在單元測試完成後進行的測試環節中的一個測試，主要是測試各個模塊和函數之間的相互銜接情況，互動情況，輸入輸出情況。所以集成測試也很重要。
那麼集成測試一般採用什麼方法呢？集成測試一般採用樁驅動的方法，因為在單元測試我們檢查的相對比較詳細，那麼在集成測試的重點其實要保證邏輯上了。我簡單的介紹樁驅動的實現方法。
我們可以定義很多個樁，使得測試效率提高。
我們把上面的內容進行簡單的總結：集成測試就是測試各個組件之間的配合情況。所以集成測試是為系統測試提供了一些基本保證，但是不要完全依賴。
採用的方法給大家介紹了，這樣可以採用測試或者程序編碼的形式實現測試。
系統測試
系統測試是測試過程中的一個轉折點，因為在現在國內的企業中，不同的產品面對不同的用戶群體，所以有的企業經過第三方產品的驗收測試，有的企業則沒有通過驗收，而是一些工具類或者通用類的產品，那麼他的驗收測試是經過廣大的用戶群來做的，也就是說凡是通用類產品的系統測試必須嚴謹測試以後，才可以投放到市場。但是對於對企業或者其他專業性單位定製的產品我們必須進行驗收測試。
系統測試工作是一個重複老動很多的工作，需要在工作種把握幾個重點，系統測試是保證系統能夠正常運轉，包括了功能，易用性，健壯性，壓力，邊界數值設定等各個方面的內容。要想在這個階段的工作種找到樂趣，就要不停的摸索，找出能夠將機器代替人的所有的東西，找工作的快感。
系統測試需要有廣泛的知識面，對測試工程師的要求需要了解和掌握很多方面的知識，需要了解問題可能出現的原因，已經出現這個問題可能是由於什麼原因造成的，以便我們能夠及時的補充測試案例，保證或者降低產推出的風險。
目前軟體測試行業發展還不成熟，大多數系統測試都在測試組做，而且測試組幾乎到系統測試測試階段才會接觸到產品。我們也把系統測試簡單的說明一下。
目前系統測試基本上採用黑盒測試方法，而且基本上局限在手公測試上面。
我們不知道被測試軟體是怎麼實現的，做了什麼事情，我們只知道我們要它做什麼，我們想得到什麼，至於程序內部怎麼實現，我們並不關心，我們只是關心結果。這是一種純粹黑盒的測試。
這個階段是測試發現問題的主要階段，最少從目前市場上的產品情況來看是這樣的。在這個階段60%的問題會暴露出來，如果不進行單元測試和集成測試，這個階段的測試量和測試點很重要。
黑盒測試的核心是需要找到測試的重點在那裡？測試的切入點在那裡。系統測試重複的工作量比較大，而且如果是一個大型的項目，涉及的內容相對比較多，而且如果組織不好，或者沒有找到重點，需要一遍遍的重複。所以需要自動化測試的需要合理的設計，使得我們的重複工作盡量減少，以提高工作效率。
驗收測試
驗收測試類似於客戶驗證產品的質量，在軟體行業發展的過程中，各種承包項目類似於國外的外包項目將會不斷的出現，那麼外包項目的質量問題需要大家共同討論。
外包項目的操作流程是當承包方提出具體的需求，然後有承包商來按照需求來開發項目，包括單元測試，系統測試，集成測試等各個方面的測試，經過被承包商測試後的產品提交給外包商的時候，需要進行驗收測試，驗收測試可以是外包商本身提供一套測試方案，然後對照具體的需求，進行產品驗證測試。也可以是雙方找一個共同的第三方，進行產品的驗證測試。
驗收測試的測試重點主要是產品是否按照需求開發的，而不從針對功能進行的測試。所以驗收測試基本上不需要多少專業水平，也可以是承包商找到使用該產品的用戶，來體驗該產品是否能夠滿足使用要求。這樣以來使得雙方可以有一個共同的平台，避免商業矛盾的產生。
驗收測試的測試手段目前來說還是靠用戶體驗。對照合同的需求進行測試，是第三方按照雙方達成的共識來跟蹤和測試軟體是否能達成的需求。
測試方法
黑盒測試
顧名思義，黑盒就是外面不知道盒子裡面在作什麼，怎麼作，只知道我的輸入他需要有反應，無論是正確的還是錯誤的，都需要有回饋信息。黑盒測試需要懂產品的使用方法，操作方法，把儘可能多的情況暴露出來，通過這種方法進行測試。
黑盒測試的隨機性比較大，在大部分案例執行完成以後，大概能夠測試40%的功能，據美國一個官方的數據說，20%的問題是在開發過程中發現的，80%的問題是在系統測試和集成測試過程中發現的，其中80%的比例我們還是需要在細分，20%的是使用的問題，20%是程序的問題，5%邏輯問題,剩下的都是莫名其妙的問題，這樣的數據對測試的一個引導是：要想發現更多的問題，需要更多的思考，更多的組合。這樣無畏的增加了很多工作量，人們在疲憊的執行著測試案例，渴望從中發現新的問題。
這樣的案例設計思想使得我們在開發一個大型的產品或者延續性產品的時候，整個測試案例的延續性很差，重用性也很差。所以我們在這裡需要糾正一個概念，黑盒測試不簡單的使用，案例設計也不是無謂的組合。
那麼如何設計好的測試案例呢？如何在開發過程中很好的結合2/8原則呢？當前包括以後，不可能出現一個積極完美的產品，一個錯誤也沒有，但是我們作為軟體工程師，肯定渴望自己參與開發的產品穩定，易用，人們寄予無限的稱讚，這是一種奢望，那麼我們把這種奢望修改一下，就是渴望我們參與的產品，能夠滿足當前大多數人的需求，穩定是否更合理呢？
白盒測試
白盒測試是一種高技能的測試，它是一種基於源代碼下的測試，這種測試要求對程序的要求很高，需要了解程序的構架，具體需求，以及一些編寫程序的技巧，能夠檢查一些程序規範，指針，變數，數組越界等問題，使得問題在前期就暴露出來。
一般程序所容易犯的錯誤,沒有定義變數,無效引用,野指針,超過數組下標,內存分配後沒有刪除等,無法調入循環體,函數本身沒有析構,導致循環實效或者死循環.參數類型不匹配,調用系統的函數沒有考慮到系統的兼容性等.
白盒測試一般是以單元或者模塊為基礎的。目前的做法是把他歸結為開發的範疇，用轉人或者兼職的人去看代碼或者利用部分工具，例如Rational系列，Boundchecker等工具，他們可以幫助人為的發現變數沒有初始化，指針錯誤等。大大的減少了人力。
我下面講講BoundChecker最實用的東西。
例如：我們發現一個現象：有個軟體再Win98下運行不起來，或者總是出現莫名其妙的錯誤，再Win2000下或者更高系統下運行正常。
上面是一個現象，是我們再日常測試中經常遇到的現象,我們分析可能導致出錯的原因：操作系統本身出錯的原因，導致軟體無法再此系統下運行，另外一個原因：軟體中用到了某些函數不支持此操作系統。還有一個原因，軟體運行的硬體環境再此系統下不能滿足
灰盒測試
灰盒測試是介於黑盒測試和白盒測試之間的一種測試.這個階段的測試重點是各個組件之間的邏輯,這個時期的測試重點是各個DLL文件的參數和邏輯是否正確,測試的重點是DLL本身.然後採用樁驅動,把各個DLL或者函數按照一定的邏輯串起來,達到在產品還沒有界面的情況下能看到一種既定情況下的結果輸出.
灰盒測試的要求相對白盒測試來說要求相對較低,對測試案例的要求也相對較低,只要求能夠檢測DLL處理輸入和輸出的能力,異常情況下的處理而已.
測試方面
案例設計問題
分析：因為現在從總體上看，案例設計很細，但是重複和不必要的東西太多了，個人認為原因有三個：
第1、 設計案例的不了解產品設計的框架（從程序概念上講）
第2、 案例的設計沒有一個反饋，涵蓋情況不知
第3、 開發產品質量意識淡薄，測試壓力太大
第4、 測試人員的素質分析沒有，我們看不清問題出現在那裡
進度問題
第1、 測試的整體計劃裡面沒有重複考慮風險，時間問題緊迫
第2、 回歸測試無法保證
結合開發模型，跟大家一起分析各個時期要作的時期
怎麼樣閱讀需求呢？
我們在測試的時候，我們需要通篇的閱讀需求，那麼怎麼閱讀需求呢？需要了解什麼內容呢？實際的可操作的在那裡呢？
我詳細說我的認識，需求我們需要了解我們需要做什麼類型的產品，這種產品需要什麼樣的基礎知識，我們應該補充學習那些基礎知識，市面上是否有同類型的或者相似的產品，他們曾經出了那些問題等，把自己先充實了，這是看需求的主要目的和重要目的。
測試改進方案
以上對存在的問題進行了分析，我們需要找到自己的弱項在那裡，那麼從現在看來，我們現在測試隊伍沒有建立，沒有形成相應的體制。主要表現在一下幾個方面：
測試工作需要回饋
回顧一，測試案例執行跟蹤和統計不明確。
問題：如果測試案例不進行跟蹤，無法證明或者檢測我們案例設計的好壞，無法改進工作方法或者改善我們的思路，所以需要通過這裡把自身問題看清楚，這樣有利於工作的開展。
在我們日常的生活中，存在這一種現象，因為這種現象導致了測試一些列的發展。大家普遍認為，測試的含金量不高，導致了測試工作就是一些不願意做開發或者沒有能力做開發的人來做，其二，他們對測試設計的測試案例從不認真的審查，認為就那麼回事情。出現這種問題的願意是由於開發還沒有清楚的認識到測試是一個服務部門，是為他們服務的，從私利的角度來講，我們拋開項目的關係，測試的主要工作是為了幫助開發將自己寫的代碼更實用一些，讓市場更認可一些，讓開發人員的成就感強一些。
如果大家都從這個角度考慮問題，那就可能緩解或者解決上面的第二個問題。
關於測試含金量不高的說法，我不贊成這個說法，在目前國內的大環境下，測試是這樣的，但是它在朝自己預想的發展。而開發的發展除了新的語言在發展以外，思想或者體系我們能增加或者能設想的空間已經不多了，而對於測試是一個全新的行業，他發展首先需要支持，需要理解，我相信國內測試在5~10以後，發展更加迅猛。因為就算是現在很小的軟體企業，已經開始重視測試了。
回顧二，測試需要和開發有共同語言
當你開心或者興奮的發現問題以後，你能告訴我這個問題發生的原因嗎？當你發現問題以後，你能告訴我問題可能在那個環節發生的？你能告訴我類似於此類問題可能在那裡還會發生。
所以，當你進行測試的時候，渴望測試人員完全了解被測試對象的架構，然後針對此類軟體需要補充基礎知識，把自己補充起來，不至於開發人員給你講任何事情，你不理解，或者很難理解，那麼如果真的是這樣，我對你個人設計的測試案例會打一個問號。
靠自己的基礎知識，詳細拜讀設計稿件，從設計稿件中如果能發現問題或者風險，你就有長足的進步了。
回顧三，補充測試案例
我相信大家都有這個體會，在設計案例的過程中，大家想到這裡，想到那裡，總之想的很詳細，但是在真正做測試工作的時候，總是發現一些bug與我們設計的測試案例無關。
怎麼會發生這樣的事情呢？因為我們設計案例是寄予自己的經驗和對軟體的理解去設計案例，勢必會造成這樣的局面。現在我推進一種方法。就是在設計測試案例的時候，渴望每個人把自己負責的模塊劃個流程圖出來，包括所有的出口和入口，包括信息流怎麼流轉的，如果把這張圖形能夠完全的划出來，說明你的理解要深一步，那麼設計的案例含金量會高。
測試工作需要總結
測試的總結機制沒有
i. 測試案例的執行情況
ii. 測試案例發現問題情況
iii. 測試案例的冗餘情況
iv. 測試周期內的曲線項目進展情況
需要交流平台和形式
信息交流平台和積累
v. 資源共享
vi. 信息共享
vii. 提高自己在開發中的信心，不要總是喊狼來了
viii. 人和人之間需要溝通和認同，團體也一樣
測試人員交流什麼呢？
在一個組織中，應該讓所有的人熟悉每個模塊的設計思路和測試思想，讓每個設計的人告訴大家，宣講出來，這樣大家在看這塊的時候，就知道那裡容易出問題，出了那些問題。如果進行測試是最有效的，如果設計案例能抓住問題的核心。在設計階段，如果把設計的案例給開發人員看看，能規避一些設計上的缺陷。
在應該團體中大家都應該有共享的概念，我個人推薦的學習方法，是偷，我別人學了很多年的思想精華部分，在很短的時間內接受並吸收，這樣會提高整個團隊的素質。如果每個人都在共享，那麼每個人都在進步，所以需要交流，包括思想，包括方法等。
採用的方法
讓別人給服務說話，清楚認識自己
讓開發人員說話，讓對應開發人員給我們的測試案例提出相應的意見，保證測試案例的覆蓋面，以把握重點。
在整個開發過程中，由需求，開發，測試完整的團隊，準確的說還有市場部分，我們都把它歸結為需求的搜索和定義部分。那麼在整個產品研發的過程中，各個部分需要完整的配合，否則整個產品都不能按時上市。作為為開發和需求服務的測試部分，應該擺正自己的位置，我們是一個團隊中的一部分，是不可以缺少的一部分。
人貴有自知，也難有自知。只有在認識自己的基礎上才能選擇好自己的生活道路。首先要認清自己的能力。人的能力可以有天壤之別，但只要不辜負自己這塊材料，也就可以問心無愧了。認識自己尤忌自大，這會使你為自己訂立高不可攀的奮鬥目標，到頭來高不成、低不就。其次要認識自己的本性。心理學家把人分成六個類型：經濟型、理論型、社會型、審美型、宗教型和權力型。要選擇一個適合自己本性的生活目標。
看清楚了自己，就可以很好的改善，也能把自己的事情做好，同時呢，才能更好的服務。
自己回頭看
讓執行測試案例的人員反饋給我們數據，說明案例的冗餘情況，這樣會慢慢提高自己的設計水平。
因為人們習慣於談成績，問題在成績中可以淡化，我不同意此觀點。
其實在現實生活中，大家都經歷了很多事情，都學會了總結，可是同樣的錯誤在現實中會多次出現，為什麼呢？是因為回頭了多次，沒有總結，總結了沒有執行，執行了沒有改變方式，改變方式了但是沒有認真考慮，還是錯的。
把自己犯的錯誤列舉出來，然後找出出現問題的真正原因，才是自己最大的進步。如果淡化錯誤，將來可能就會將成績磨滅掉，所以積累，回頭是工作中需要重視的問題。
還有一種論點，說公司多麼多麼重視開發，不重視測試，我對這種論調積極反感，這只是個人感覺。為什麼這麼說呢？
對公司來說，要靠項目和產品維持生存，對嗎？從這個方面來說開發重要，產品質量不重要嗎？這個問題很多人問我，我回答說，重要，非常重要，那為什麼測試的價值體現不出來呢？主要是兩個方面的原因，一個是公司引導不正確，各個部分的同事為這個項目負責，而不是開發為這個項目負責，其二呢，主要是因為我們是維護，而不是創造，如果你告訴老闆，這個產品我們改變測試策略，能夠提高工作效率，這個產品可以提前2個月發布，而且我保證質量。我相信你的價值也即體現出來了，如果不可以，說明還是沒有找到合適的方法。
了解同類產品
讓市場人員反饋同類產品的問題以及市場對我們產品的需求。測試過程是反映當前產品的質量，為什麼要研究競爭對手的產品呢？
首先，測試中包含易用性測試，測試什麼內容呢？就是測試怎麼好用，客戶是怎麼用的，我們怎麼設計更貼近用戶，那麼不研究競爭對手，我們怎麼可能佔領上風。
其次，了解競爭對手的產品，有利於測試工作捕捉重點，使得工作開展有利有節。
可謂知己知彼，百戰不殆，所以在現在的市場競爭中，了解同類產品才可能發現對方的缺點，給以打擊，發現對方的優點，快速學習，閉門造車必定失敗。
提高自身素質
從程序的概念理解產品，這樣測試案例可以設計的比較有針對性。
常言說得好，「識重於才」，而見識卻往往是生活閱歷造就的。對於一個初出茅廬的人，智者的指點是至關重要有時甚至是決定性的。回想我十年來的經歷，很多失敗其實是沒有人指點而造成的。要尋找一個精神上的導師，他可以是你的父母，也可以是其他師長。他閱歷豐富而又不拘泥於自己的老經驗；他能在緊要關頭給予你原則上的指導和精神上的支持。有時候僅僅是他失敗的經驗就會使你受益匪淺。
如何提高程序能力
耳濡目染
讓開發或者設計人員在討論開發方案的時候參與旁聽，耳濡目染。其實這只是一種輔助的手段。
電視劇《霍元甲》播出以後，得到大家的欣賞。原因是因為他本人身體虛弱，所以父親從小不讓練武功，而生長在那樣的環境中，他天天可以看到兄弟們在練功，招式已經記憶在心理，但是苦在沒有練功的機會，他利用體力勞動的過程中，改變勞動方式，趁機練功，後來發展到獨創「迷綜拳」。
程序設計和開發是一個硬功夫，也是一個長遠的事情，它是一個積累的過程，不能一蹴而就，需要苦心練，多些理解，多些思考。
面對程序開發，不要有太多的壓力，因為程序開發就跟你學說話一樣，因為語言本身有很多通性，高級語言和低級語言本質上差別不大，所以紮實的從基礎的東西學起，這樣才能完全的積累下來。
計算機發展速度很快，各種概念，各種語言發展都很快，掌握實質，不斷學習，才能把握。所以還是需要多看，多想，多練。
自己練內功
從自身做起，了解程序架構和開發模式，努力提高理解和產品的單元測試或者組件測試能力，這樣以來可以了解程序的很多演算法，使得在產品的開發過程中就能把問題發現並且能夠得到及時的解決。
其次能夠提高大家參與到項目的榮譽感，因為在測試本身是一個服務性的行業，那麼服務行業的特點是不停的改變思路，改變服務模式，提高服務質量，當服務做好了，那麼在整個研發中就可以找到自己也是其中一個分子的感覺。
其三，練好內功，為自己將來提高工作效率，進行一些自動測試以及從程序架構的概念上設計測試案例提供了技術保障。
以上是自己練好內功的用途。
在過去社會中，有很多擂台賽，目的是切磋技藝，弘揚中華武術，各個門派直接交流和學習的過程，為了在擂台賽中取的很好的成績，我們需要努力練功，其次是多學本門派和其他門派的武功，或者自創武功，在擂台上能夠發揮的淋漓盡致，因為武功的最高境界就是沒有招式，要達到這個境界，需要內功深厚，避免走火入魔，需要毅力，需要創新。
理論就是理論，無論在那裡看到的理論都是一定的基礎的，因為所有的理論基礎需要一個證明此理論的平台或者條件，所有一定要看，想，用。看別人是怎麼用的，在什麼情況下用的，用的目的是解決什麼問題，在什麼樣的環境下能夠做出來，需要什麼樣的支撐；想自己現在目前是否有這個環境，就目前的環境能夠做什麼，如果要搭建對方的環境需要多長時間，這個做法中存在什麼不託的地方，有什麼需要改進的地方；在自己工作的環節中找找看，看自己是否適合用這個東西，如果適合，怎麼用，用到什麼程度，如果非常認可別人的做法，需要衡量需要多少資源和時間，努力找自己的結合點。
千萬不要再我們看到一個理論或者方法的時候就去推動它，或者原理實踐過一個什麼思想就想在新的環境下實踐他，都是不可取的。好的事情或者好的做事方式他需要一些條件支撐，一旦硬套，就可能出現問題。
實踐中檢驗
嘗試做一些灰盒測試部分（目前暫時是想法，但是還不完善）。灰盒測試是界與白盒測試和黑盒測試之間的一種臨街狀態。
測試發展
測試在國內還是處於摸索階段，在過去的發展階段，大家只是初步針對不同的軟體產生了不同的測試方式，但在操作方法，操作流程等方面還需要繼續摸索。對潛入式軟體來說，行業內始終認為潛入式軟體是最難進行測試的，因為他需要很廣的知識面，需要對各個點的設計原理進行分析和測試。
在目前國內開發眼中的測試還沒有形成概念，我們需要不斷的改變形象，加深他們對測試的印象，以便我們獲取更多的幫助和協助。
測試未來發展需要兩條腿走路，這樣能夠在各個環節保證產品的質量。
第一步，系統測試繼續練內功，將案例設計的能力提高
第二步，需要進行灰盒測試，對產品進行代碼級的測試
第三步，需要進行部分白盒測試或者由開發人員進行執行
要達到一定的認同和發展,測試人員需要努力學習,打下紮實基
礎,這樣才能一步步的成功.
如何提高測試
提高測試需要從幾個方面著手，其實只是自己的一些感覺，不一定就需要按部就班，需要找自己適合的點。
制定完備的測試計劃
清楚的認識測試計劃，測試計劃是一個文檔，能夠保證整個研發過程中順利執行的一個指導性文檔，它描述了幾個方面的問題。
第1、 描述了項目的目的
第2、 描述了項目的開發周期
第3、 描述了在測試中遇到的技術
第4、 描述了測試案例的設計周期
第5、 描述測試案例的執行周期
第6、 描述了測試過程中用到的工具或者技術
第7、 描述了測試過程中用到的資源情況
第8、 描述了測試過程中可能遇到的風險以及規避方法
提高案例設計水平
明確了解現在目前流行切實用的幾種案例設計的方法，因為在不同的產品不同的要求有不同的設計手段，我們需要不斷的學習和總結，在為了測試領域中，許多新鮮的詞語都會出現。
這種方法類似與工業領域的隨即抽取統計分析法，但是工業性質牽扯到損壞或者人為原因，統計出來存在這偏差，但是應用與軟體方面，雖然存在著偏差，但是不可能象硬體那麼偏差很高。
等效法
明確測試的目標，一般適合用到的範圍是，制定被測試的對象是在滿足某個條件的區間內的所有的所有數據。
案例設計方法：從其中區間數據段中選擇任意一個或者兩個數據，只要這個數據滿足了，那麼其他的數據就是滿足的。
我現在舉一些例子，來說明等效法在測試過程中如何應用的。
範例1：在登陸某系統需要驗證用戶名，要求是長度是最小是6位，最長是14位，名字中可以包含數字，但是不能以數字開頭，可以包含各種符號，不能包含中文。
1、隨意字母組合成一個12位的姓名，測試是否可以通過驗證。
2.、隨意生成一個長度12位的姓名，測試是否可以通過驗證
3、測試以任意一個數字打頭12位的姓名，測試是否可以通過驗證
4、測試姓名長度位12位且包含中文情況，測試是否可以通過驗證
5、測試長度不滿足條件情況下，是否通過驗證
6、如果長度不滿足，是以數字開頭的，提示信息驗證
7、如果長度不滿足，姓名中包含中文的，提示信息驗證
………….
(註：)這個可能比較簡單，但是說明一個問題：為什麼隨意生成一個12位姓名的,其實你選擇8位姓名長度或者10位姓名長度是一樣的，所以這種情況下考慮採用等效方法比較合適。
範例2:有這麼一個需求，要求選擇1~12之間進行調整，手機的背光就會隨著數值的變化而變化。總體的是數值越大越暗。
以上需求是大家經常可以看到的。
測試案例設計：清晰記憶1的情況，然後隨意調整一個數值，因為要求是變化了，至於變化成什麼樣子，變暗到什麼程度才正確，沒有明確的指標數值，所以只需要記住臨街點1的情況，然後隨意調整一個數據，然後和當前調整後的數據進行比較。
（註：）沒有明確的說明，只是含糊的結果，但是總體的結果是在變化，那麼這個時候比較適合使用等效法。
因果分析法
需要有一定的程序基礎，了解程序的架構，就是當問題發生以後，能夠有效的補充相關的案例或者篩選相關的案例。因果分析的核心是從自己的理解去分析問題所在的真正原因。
範例1：刪除磁碟上某個文件失敗，分析原因：如果是管理員許可權，那麼可以隨意刪除，無論這個文件的屬性是只讀的還是存檔的，那麼如果不能刪除磁碟文件，除非是壞道上的文件。分析完成以後，使得測試案例設計有針對性，而不是盲目的將所有的文件格式都去嘗試一次。
範例2：假設我們用Excel作一個計算，結果和我們用計算器計算的結果不同。
分析：Excel的計算函數單獨運算沒有錯誤，然後插入一行，結果錯誤了，說明插入行導致計算錯誤，那麼插入一行怎麼會引起函數計算錯誤呢？原因是由於插入行後，導致傳給計算函數的區域沒有更新，所以造成計算結果錯誤，那麼這個Bug就很明確了。
範例3:假設我們平常在做講座的時候發現在某台機器上就會死機。這是一種現象。
分析：為什麼在這台機器上死，在其他機器上不死。原因有兩個，第一個先找系統原因，是否是我們的產品在當前這個系統下有Bug,經過驗證沒有，那問題出在那裡？
其實演示產品需要的是硬體的支持，那就是顯卡，如果顯卡內存不夠大，可能導致某些演示文件死。
（注）因果分析需要有廣泛的知識面，使得我們在分析的時候能夠拓寬面積，模糊的定位問題。
範例4:用戶給我發送一個文件，列印的時候發現是亂碼。後來逼迫無奈，就讓用戶將這個文件傳真給我。這是現象。
分析：為什麼列印出現亂碼？問題基本定位，系統字型檔不夠，系統下列印驅動問題，列印虛擬內存問題，操作系統問題，軟體本身問題？最後問題經過驗證，最終歸結為在此操作系統下，列印驅動程序有問題，使得文件不能正常列印。
（註：問題需要先框定範圍，不要亂了套路。）
邏輯分析法
在邏輯分析方面，也需要有一定的程序理解能力。從程序邏輯和日常常識去判斷問題。邏輯分析法其實就一堆假設的羅列，推論出系列結果的假設，然後將假設反推翻，問題就可以暴露出來。無論那種方法都是通過表現去分析問題的實質的。
範例1:我們在做MP3播放器快進和快退測試中，要考慮的同步問題，就是我們液晶顯示屏上出現的歌詞進度，時間進度和我們耳朵聽到的進度不同。我們分析一下，為什麼出現不同步現象，為什麼其他的能同步，就某一個或者某幾個不能同步。
首先我們了解同步的演算法：快進和快退是按照當前歌曲的數據流來計算應該到那裡，它是以當前歌曲的數據流為係數，然後進行的一些調整，那麼出現不同步的原因是由於係數不同造成的，所以考慮到同步問題，我們需要找不同格式不同數據流的歌曲，這樣問題容易暴露，容易清楚的定位問題的真正原因。
範例2
我們來分析網路遊戲中的交易系統，就是在遊戲兩個人進行物品和金錢的交易。
怎麼設計這裡的案例呢？
邊界數值分析法
在測試案例執行的過程中，所有調節的數據都需要考慮到邊界數值的測試方法，這裡我就不在贅述。但是需要注意，邊界數值的測試不是枚舉，只是抽樣的方法。
逃避測試的誤區，市場需求引導產品質量
測試是為了驗證需求，保證產品質量，無論如何你都不可能做成100%的測試，不可能做成No Errors。所以我們針對不同的產品，不同的市場定位，確定不同的測試方針。
因為企業面對的是客戶，面對是企業長遠利益，那麼我們不可能倉促的推出產品為了迎合市場，而是需要研究，調查市場的真正需求，把用戶所關心的功能提供給用戶，使得其更加完善，更加穩定。
我們從企業來分析，首先任何一家企業要生存，必須需要市場空間的支撐，目的是為了盈利，我覺得沒有必要說的那麼冠冕堂皇，這是事實，但是在把握產品質量和市場需求的時候，我相信很多企業會選擇市場需求的，因為這是機會，是把握企業生存的機會，特別是對於發展性企業來說。（企業原因）
我們從開發來分析，因為在開發的過程中，由於軟體行業的高流動行和知識更新快的特點，風險加大，使得開發周期很難把握，這樣使得產品測試時間很難控制。因為開發的進度包括市場提出需求的技術風險都很難把握。（開發的原因）
我們從測試來分析，測試在很多企業中是沒有的，那麼開發人員自己來做，如果有測試人員，那測試也是隨意性非常強，造成產品上市後預留很多無法預估的風險，為企業的形象蒙上了面紗（測試模式）
合理利用2/8原則
測試是列舉，不是枚舉，所以設計案例的時候全面是不可能的，那麼需要靈活的運用2/8原則，使得測試重點清楚，容易控制。
基於產品在開發過程中的種種風險，我們在有限的人力和資源的情況下，合理的利用2/8原則，如何把握2/8原則？首先需要了解產品的特點，讓所有參與測試的人員能夠了解產品的特點，這樣使得工作具有針對性，至於產品的噱頭，我們可以進行充足的測試，因為只是我們的產品立足市場的點。
在時間有限的情況下，把常用的功能測試保證了，不要攤全，攤寬，這樣到最後都無法總計產品的質量概念了。
以上這麼說，是一種概況，在實際的工作中大家需要總結，把進度，時間，質量等進行權衡，以保證產品的順利發布。
回歸測試的概念
測試次數不是輪迴，測試的不同次數不是輪迴，而是為了驗證問題，那麼什麼時候適合安排一輪測試，需要定義標準，否則耗時耗力。
回歸測試是不可缺少的環節，在一個產品測試完成後，直接到用戶手頭的時候，需要千萬小心，需要進行一次徹底的回歸測試，這個時候包括所有的功能以及所有已經修正的問題。避免版本出現問題。
其實在不同的資料中對回歸測試有不同的解釋，我就不在這裡贅述。我想表明我的觀點是，依照不同的開發模式，回歸測試所在的時間段也不相同；當前的開發模式有瀑布型和迭代型，例如，在瀑布型的開發模式中，所有的測試活動（手工測試，系統測試，部分集成測試）都在最後進行的，而切所理解的回顧測試是為了保證在新的版本中測試修改後的問題，其實這個測試只是保證了其中一部分工作
測試的概念
測試不是為了驗證問題，而是為了發現以前設計中沒有發現的問題。
自動測試只是測試的一種手段，目的是為了提高工作效率
測試工具只是利用，不能依靠，因為工具本身沒有智能的判斷是否會有問題發生，自動測試不是利於測試工具，而是需要編寫或者利於測試平台，編寫適合自己的測試工作進展。
如何調整團隊的作戰能力
建議性質：因為曾經帶過四個團隊，而且這個經驗最少在我身上是成功的。
形式分析
測試團隊，測試團隊在現在國內來說在慢慢的得到重視，之所以原來不重視是因為整個行業處於摸索期，不知道採用什麼方法，什麼技術，作什麼事情等的情況下，使得測試員好像是一些沒有能力人的集合（宣講，不聽的宣講）。
目標計劃引導
測試技術和未來發展規劃，因為任何人的發展需要目標，那麼一個人的發展目標假如它和這個行業相關，那麼它會付出一切，努力的工作，所以需要大家認可一個目標，並且讓大家認為是可行的，然後我們分步驟一步步的去實現它。讓他或者大家能夠看到自己所喜歡或者從事行業的發展方向。
過過老師癮
因為在做任何事情的時候，每個人都有自己的想法或者步驟，講出來就好，這就需要開始的時候我們以任務的形式下達，我相信，到後來大家願意自己站出來講了，我告訴你原因。因為人本身有羞怯感，怕幾個方面，怕講錯，怕人多，怕提問。
那麼如果把這幾個問題都解決了，是否羞怯感就沒有了呢？
如何解決個人怕的問題：引導，因為一個人如果不能把自己的想法和思路講出來，那麼不可能把事情做的很好，其二，就是如果你把你的想法說出來，別人可能會指出你思路中走彎路的地方，對個人來說可以跳高工作效率，使得思路更加完善。
其三，如果大家都把自己的思路說出來了，你不就節省的很多學習時間嗎，另外你想過沒有，當別人形成這個想法的時候，需要一定的積累，那是他的心血，這不就輕輕鬆鬆讓你學到了嗎？如果固步自封，那麼你的思路有可能是錯的，有可能是對的，但是你的知識面就只能局限在你所考慮的範圍內，對個人發展不利。
定學習目標
在軟體行業裡面，要有發展，就需要不停的學習，不停的進步，不停的總結，才可能有長遠發展，所以需要定義在這個行業階段行的學習目標，讓人感覺這個行業現有的水平只是維持，要發展，需要學習。
在工作中學習的方法，除了自學以外，就是「偷」了，所謂偷，就是要學會問問題，把你想知道的東西刨根問底，當別人回答你問題的時候，他一定是用他知道的東西的精華來總結，那麼這樣你在很短的時間內，把他總結的精華全給你了。
在學習的過程中，需要學會總結，把能總結的都整理出來，第一是經驗的積累，第二呢能夠做到分門別類，逐類旁通，使得相同或者類似的錯誤不要重范。
興趣和愛好
一個人工作有兩種情況，第一中是真正的工作，完成就算完成了，自己也在不斷的學習，不斷的總結，但是缺乏激情。第二中是把工作當成自己的事業，渴望自己在這個方面成為權威或者說業界能夠說話的人，也是在不斷學習，不斷的總結，培養職業性，培養和引導大家的興趣和愛好，因為只有你了解了興趣和愛好，才能更融洽的調和整個工作組的氣氛，這對測試行業的領導者來說是個挑戰。
歪曲理論推理
「測試人員是由於技術不過硬，才去做測試的。」針對這個觀點，我說說自己的看法。好，我給測試說幾句，測試水平不過硬成立，假設成立，那麼這是相對的，相對開發來說的，而且這種論調都是從開發那裡擴散或傳播出來的，測試在後期發現問題後，開發也許心理很痛苦，但是他不願意暴露在臉上，使得有些問題越發變的嚴重，不得不修改。那麼在產品後期暴露那麼多問題，說明了什麼呢？這麼低水平的測試都能考慮到你程序設計的種種漏洞，那麼說明了程序水平開發有待提高。
在IT現在的行業中，開發的流程，模式，以及各種約定成俗
的東西越來越多，而且相對穩定，而測試是一個全新的行業，它需要大家摸索支持，需要大家共同建立起來。
其實，在原來的開發模式中，商家為了適應市場，為了保證利潤的最大化，為了使得產品能夠順利的適應市場，那麼採用各種方法，使得產品質量的定位淡薄，而現在隨著人們的要求越來越高，商家的意識越來越強，各個公司或者組織渴望成立測試部門，保證產品的質量，使得測試這個行業在最近幾年才發展起來。
正確理解自動測試
首先，自動化測試是測試行業是技術，但是不是說用了自動化測試了就能發現更多的問題,它只是提高了工作效率而已.
自動化的概念是人們在工業生產的過程中，為了提高工作效率，不斷的對操作方法或者技術或者工具進行改進，減少人們普遍的手工勞動，節省時間和成本。
而軟體行業的自動化測試同樣也有節約成本，提高效率的需求。所以所有的改進需要考慮到成本的問題。
自動化測試的大前提
第1. 產品本身特徵具有長期可維護性
第2. 產品本身非緊迫的大項目
第3. 產品結構相對複雜
第4. 資源投入相對充裕
那麼作為成本，需要從幾個方面去考慮，第一實現成本，第二，人力成本，第三，新技術的風險，第四，節省的成本，第五，被自動化的功能是否需要大量的手工勞動。
所以我們理解自動化一定從成本的概念上考慮， 最少從自動化測試概念的起步應該從這個方面考慮。那麼自動化測試的重點就在於他節省人力，節省時間，得到的數據更精確些，而且操作的可重複性和Bug的可重現性更強一些。
下面我就對自動化測試做一個詳細的解釋，跟大家分享。
1. 簡介
本文關注於一個實施自動化測試框架的組織的主要方面和影響。本文的意圖是提供一些能夠成功的實施自動化測試的指導方針。
2. 測試自動化的神話
有很多關於自動化測試的神話。其中的一些是真實的，而其他的一些是不正確的設想，這些不正確的設想會嚴重的威脅到實施自動化測試的成功。
2.1. 我們在時間上是緊迫的 － 項目已經落後了 － 讓我們使用自動化測試吧！這種情況將不能成為現實。實際上，正確的思想應該是 － 我們時間急迫 － 我們決不應該使用自動化測試。
如果項目已經陷入到了麻煩之中，不建議實施自動化的功能測試。項目很可能因為需要大量的測試框架的準備和實施會被托跨。我餓建議將重點放在以下的事情上：
優化測試的過程。調查並建議在目前工作基礎上的測試方法和過程。建議借鑒 RUP的相關思想和過程。引進或者使單元/組件測試正式化。這是我們能夠快速獲得受益的很好的方法。如果正式的組件測試被使用，我建議可以使用 Rational PurifyPlus 進行單元或者組件測試。根據我的經驗儘早的使用 Rational PurifyPlus 是非常值得的。在一個引入和 Rational PurifyPlus 的項目中，通常會在組件的級別得到 百分之三十的性能提升。僅僅在項目團隊能夠對 下列問題的回答是"Yes"時：項目能夠被適當的推延。存在能夠通過實施自動化測試被達到的精確的目標。項目具備建立適當的測試框架的必要條件。
那麼，你可以在一個時間緊迫的項目中適當的實施測試自動化。但是根據經驗這種情況是很難發生的。總而言之，我只能說"對不起，銀彈根本不存在"。
2.2. 測試自動化就是捕獲和回放
在過去的日子中，自動化的測試工具只是被看作是一種捕獲和回放的工具。當前這個神話仍然在很多測試人員的思想中。而事實上自動化測試已經遠不止捕獲和回放這麼簡單了。按照成熟度自動化的測試可以被劃分為 5 個級別。
2.2.1. 級別 1：捕獲和回放
這是使用自動化測試的最低的級別，同時這並不是自動化測試最有用的使用方式。優點：自動化的測試腳本能夠被自動的生成，而不需要有任何的編程知識。缺點：你會擁有大量的測試腳本，同時當需求鬍子和應用發生變化時相應的測試腳本也必須被重新錄製。用法：當測試的系統不會發生變化時 － 小規模的自動化。
2.2.2. 級別 2：捕獲、編輯和回放
在這個級別中，你使用自動化的測試工具來捕獲你想要測試的功能。將測試腳本中的任何寫死的測試數據，比如名字、帳號等等，從測試腳本的代碼中完全刪除，並將他們轉換成為變數。優點：測試腳本開始變得更加的完善和靈活，並且可以大大的減少腳本的數量和維護的
工作。缺點：需要一定的編知識。頻繁的變化可能會引起"義大利麵條式的代碼"，並且變更和維護幾乎是不可能的。用法：當進行回歸測試時，被測試的應用有很小的變化，比如僅僅是針對計算的代碼變
化，但是沒有關於 GUI 界面的變化。你能夠使用這種技術通過快速的編製一些測試腳本以檢驗你的想法來探索你的預定的測試設計。當我在沒有任何象需求或者設計模型這樣的文檔的情況下第一次操作一個產品時和我需要獲得一系列內部構建版本的穩定性的第一印象時，我使用過這種技術。通常如果適當的軟體配置管理（SCM）與良好的內建設計相結合時，使用級別 2 的技術已經足夠了。
2.2.3. 級別 3：編程和回放
這個級別是面對多個構建版本的有效使用測試自動化的第一個級別。你需要在實際的投資開始顯現之前確保團隊和客戶對項目的安全感。如果沒有對測試自動化工具的適當的培訓測試人員將不具備到達這個級別的能力。在自動化測試工具中的所有測試功能都必須被很好的理解，並且要掌握測試腳本語言的知識。好處：你確定了測試腳本的設計。適當的設計是必要的。編碼的習慣必須是適當的。使用與開發中相同的編碼習慣是非常好的。這將開始搭建起測試和開發之間的橋樑。在項目的早期就可以開始自動化的測試。你能夠在項目的早期就開始進行測試腳本的設計。與開發人員交並調查他們認為可能會存在問題的區域。確保了開發人員關注在獲得能夠被測試的方案上。缺點： 要求測試人員具有很好的軟體技能，包括設計、開發等。用法：大規模的測試套件被開發、執行和維護的專業自動化測試。級別 3 使你能夠使用自動化測試並構建不同的回歸測試（重用已有的自動化測試
用例）。根據我的經驗在看到更多切實的回報之前，為了達到這個級別，有大量的工作和影響項目的活動必須被做。因此快速的建立和證明自動化測試的價值是至關重要的。找到乏味的測試（例如，邊緣測試和特定的功能測試用例是首先進行自動化測試的良好候選者）。首先創建少量的能夠測試一些基本功能（比如，登陸和創建用戶等）的測自動化測試用例。
2.2.4. 級別 4：數據驅動的測試
對於自動化測試來說這是一個專業的測試級別。你現在要利用測試工具提供的所有的測試功能。你擁有一個強大的測試框架，這個測試框架是基於能夠使你根據被測試系統的變化快速創建一個測試腳本的測試功能庫的。維護的成本相對是比較低的。你在你的測試中會使用到大量真實的數據。優點：你能夠維護和使用良好的並且有效的模擬真實生活中數據的測試數據。缺點：軟體開發的技能是基礎，並且需要訪問相關的測試數據。用法：大規模的測試套件被開發、執行和維護的專業自動化測試。級別 4 要求一些非常良好的測試數據。一個測試人員必須要花費一些時間來識別在哪裡收集數據和收集哪些數據。使用現實生活中的數據是最基本的以從測試中得到完全的回報。使用適當的數據將為你提供通常僅僅在項目的後期才會發現的或者是有客戶發現的錯誤的能力。現在你能夠通過使用現實的數據開運行大量的測試。
2.2.5. 級別 5：使用動作詞的測試自動化
這是自動化測試的最高級別。主要的思想是將測試用例從測試工具中分離出來。這個級別要求有一個具有高技能測試人員測小的團隊，這些測試人員能夠將測試工具的非常深層次的知識與他們具備的較深的編程能力結合起來。
這個團隊負責在測試工具中生成並維護測試的功能性，能夠使測試工具從外部的來源，比如 excel 表或者資料庫中執行測試用例。這種測試概念最初是由 CMG 開發的。與 CMG 方案相比，其他的可能的開放源碼的方案有被 Carl Nagle 和SAS Institute 開發的DDE。
使用 DDE 的概念，關注點是當在Excel表中創建測試用例的時候，放置使用包括被使用的特定動作詞語的一些類型的模板。執行的過程是從 Excel 表中讀取測試用例，並將測試用例轉換成為測試工具能夠理解的形式，然後使用不同的測試功能來執行測試。
這個概念變得越來越流，因為測試與用例一起使用是非常有用的。優點：測試用例的設計被從測試工具中分離了出來 － 關注在設計良好的測試用例上。允許快速的測試用例的執行和基於用例的更好的估計。缺點：需要一個具有工具技能和開發技能的測試團隊，以提供並維護測試工程（框架）。
用法：專業的測試自動化將技能的使用最優化的結合起來如果工具不具備使用內建的對象映射的可能性，那麼這個方案對於消除與 GUI 相關的大部分維護成本是優秀的。在一些組織中已經創建了這種方案，並且他們其中的一些已經實現了高度的自動化（60%），並且他們都得到了巨大的回報。
如果測試框架是適當的，我們能夠使用 excel 來生成實際的測試用例。這個級別對於那些按照正規基礎使用用例的組織或者項目來說是非常優秀的。有多少測試用的估計是被需要的，並且當用例適當時需要做的工作也是非常簡單的。你可以集中時間來生成第一個包含被需要的"對象映射"的測試用例（主流程）。依靠被測試應用的複雜程度，通常這會花費大約半天到一天的時間。
後續的被需要的每一個測試用例大概會花費 15 到 20 分鐘的時間，因為通常多數的測試用例可以複製已有的測試用例，並對其進行必要的修改，通常這種修改是有限的。動作詞語框架能夠通過使用用例使緊密的並行測試用例的開發變得可能。
2.3. 我們不需要培訓！
我們所有的人都在某一些方面具有一定的經驗，我們沒有時間能夠花費在使用新工具的培訓上。當一個對自動化工具還不是很熟悉的組織或者項目團隊開始實施自動化測試時，培訓和指導是至關重要的。如果我們允許組織或者項目團隊在沒有關於應該如何做的任何知識的情況下實施自動化的測試，那將肯定會以失敗告終。
用於實施自動化測試方案的預算會被超出，測試會被延誤並且更壞的情況是自動化測試將被放棄。組織和項目團隊需要盡量避免一些認識上的缺陷，尤其是自動化測試的維護成本和當測試人員嘗試和確認工具如何工作時產生的挫敗感。
混跡在互聯網圈的軟體測試開發一枚，
專註軟體測試自動化方向，爬蟲國內外測試資源，分享給自學愛好者。 知乎專欄：軟體自動化測試共享站 。 微博：@ 西說測試 。 QQ群:330374464 。 公眾號：testpu 。
推薦閱讀：
※深入解剖安卓單元測試，逐一攻破難點
※測試人的自我修養（二）
※Web測試和App測試有什麼區別？
※交叉測試、探索性測試的概念、價值、實踐