測試現在被普遍認爲“保證產品質量”這個籠統的說法下，而測試本身是什麼呢？今天我們就測試本身跟大家一起討論。
測試是在研發產品的整個過程中的一個跟蹤活動,他在各個階段報告給人們當前項目的狀況,能夠督促和提示項目經理或者高層經理對項目的關注點.
國內的測試的定義,一般是在產品的研發後期,對產品的功能進行驗證的一個系列活動。
國外的測試已經發展比較成型了，而國內的測試現在還處於摸索階段，至於超着那個方向去發展，我覺得大家目前還是處於比較迷茫的階段。
主要原因是：國內軟件產業起步晚，而且質量意識不強，造成了軟件工業發展緩慢，配套行業（測試發展緩慢），我覺得這個很正常，因爲從人類歷史發展的角度來看，這個是必須經歷的階段，從有這個概念到摸索，目前國內的測試應該處於沉思期，主要是沒有一個全套的指導思想，另外一個原因是行業發展方向不明朗。
國內存在對測試的誤解，所以造成了測試現在成了大家進入企業的跳板，要麼就是覺得自己的能力還不夠，目前只能從事測試，要麼就沒有編寫程序的能力，但是同類產品比較瞭解，所以做測試。
如果我們把測試的方法整理成技術，那麼他形成一個規則或者說是一個標尺，我們只是分析什麼樣產品的需要用什麼方法來測試，而且需要了解的知識架構是什麼？怎麼把這些知識穿插起來，那麼積累就不會被約束，但是不能撇開經驗，因爲經驗本身是設計出好的案例的基礎，但不是唯一的基礎。
我們再來看看測試案例的設計，測試案例的設計在國內現在是一些剛剛入行的不會寫程序或者程序功底比較差的人在寫案例，那麼這些人設計出來的案例只是包含了整個測試過程中功能測試的一部分案例而已，因爲他們不懂得或者不理解程序，不是從原理上去分析產品，不是從邏輯上去分析產品，而是從用戶使用的角度去分析產品，這樣設計出來的案例的可行性和可信度多大呢？大家可想而知了。所以我們在整個引導大家的過程中，從技術和方法，結合具體實例和針對不同類型的產品的測試方法進行跟蹤和描述。
首先，什麼叫測試？測試幹什麼？
測試，是在開發過程中的一種活動，它是分白盒測試和黑盒測試。在不同的階段不同的人所承擔着測試這個角色，我們把整個活動統稱爲測試。
測試的工作內容主要包含了設計測試計劃，設計測試案例，執行測試，進行測試總結。
執行測試是在產品開發的整個過程中進行的，包括了單元測試，系統測試，集成測試，系統測試和驗收測試，那麼不同的階段測試的重點不同。
單元測試的重點是函數級，包括需求，包括算法，包括接口預留等內容。
集成測試是指把小模塊結合起來，測試的重點是輸入輸出數據，參數的處理，錯誤預處理，接口規範，參數約束等測試內容。
系統測試的重點是功能性質，它的測試重點是按照需求來對照測試， 主要是功能實現的情況，包括功能使用邏輯和操作邏輯，操作系統，兼容性（軟件和硬件）等內容。
驗收測試，主要是合同性質而言的，在國外現在軟件外包情況比較多，那麼雙方按照合同規定履行自己的職責，把功能按照合同約定的形式條條比對。這是主要方面，那麼在企業內部，驗收測試是除了功能驗收以外，還包括易用性，軟件的親和度等方面的內容。
測試的分類
單元測試
單元測試是在測試過程中的最小粒度，它在執行的過程中緊密的依照程序框架對產品的函數和模塊進行測試，包含入庫和出口的參數，輸入和輸出信息，錯誤處理信息，部分邊界數值測試。
這個部分的測試工作在國內現在是開發人員進行的。我相信未來的發展應該是測試工程師來做這個事情。那麼需要測試人員需要深刻的理解程序，理解需求，理解設計，這樣才能發現問題。
還有一種在國內先在操作的方法，就是當一個模塊給某個開發工程師以後，需要他給大家講解他要完成這個模塊或者函數的整體流程和思路，進行統一評審，使得問題能夠暴露的更充分些，這樣做的目的有以下個。
第一，使得大家對設計者的思路明晰的理解，以便以後調用或者配合的時候能夠真切的提出需求或者相對完美配合。
第二，在評審的過程中，如果發現問題，那麼大家可能沒有犯過，這樣就會更加提高警惕，如果犯過，就會回想當時自己怎麼解決的或者規避的，使得大家能夠在錯誤的過程中快速提高。
第三，可以對平常犯錯誤進行一個積累，我覺得這是生動的教科書，可以使得新的人員在新上手的時候遇到這樣的問題以後，我們就可以給他一個解決問題的方法或者方向。
回顧，我們上面給大家介紹了兩種方法，第一種就是通過在開發的過程種進行測試，由開發（測試）工程師寫測試代碼，對所編寫的函數或者模塊進行測試，第二種就是通過代碼互評發現問題，將問題進行積累，形成知識積累庫，以便使得新人在同樣的方面不至於再犯錯誤。
單元測試非常重要，因爲他影響的範圍和寬度比較大，也許由於一個函數或者參數問題，造成後面暴露出很多表象問題出現。而且如果單元測試做不好，使得集成測試或者後面系統測試的壓力很大，而且項目的費用和進度可能就會飈升。
對單元測試，現在用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. 我們不需要培訓！
我們所有的人都在某一些方面具有一定的經驗，我們沒有時間能夠花費在使用新工具的培訓上。當一個對自動化工具還不是很熟悉的組織或者項目團隊開始實施自動化測試時，培訓和指導是至關重要的。如果我們允許組織或者項目團隊在沒有關於應該如何做的任何知識的情況下實施自動化的測試，那將肯定會以失敗告終。
用於實施自動化測試方案的預算會被超出，測試會被延誤並且更壞的情況是自動化測試將被放棄。組織和項目團隊需要儘量避免一些認識上的缺陷，尤其是自動化測試的維護成本和當測試人員嘗試和確認工具如何工作時產生的挫敗感。
你需要確保你的測試過程是適當的 － 如果測試過程是不合理的，引入自動化測試只會給軟件組織或者項目團隊帶來更大的混亂。因此，我建議希望實施自動化測試方案的組織或者項目團隊應該在實施之前建立"訓練營"，並將重點放在培訓測試團隊能夠很好的利用一個原型的項目上。
爲第一個原型項目制定一個實施計劃，下面包括原型項目的最小化的描述：當先狀態我們希望實現什麼 － 建立成功的因素期待的回報（第一次自動化測試工作被期望驗證什麼）找到一個"簡單的"測試的痛處並盡力的通過自動化測試解決它，這可以被作爲在同一時間上使測試運行在多個平臺上的樣例說明被需要的資源和時間......
一開始你就要大聲的說出成功的信心 － 讓人們瞭解你所展示的進展。這將吸引更多的關注和資源。
2.4. 我們必須 100% 的自動化
從管理的角度來說，100% 的自動化目標只是一個從理論上可能達到的，但是實際上達到 100% 的自動化的代價是十分昂貴的。一個 40-60% 的利用自動化的程度已經是非常好的了。
達到這個級別以上將增加測試相關的維護成本。由於對每一個構建版本的需求變化的複雜度，你將花費更多的時間在變更測試用例上以使他們能夠正確的運行。
在這種情況下，通過告知管理層100% 的自動化目標是相當昂貴的來確立一個合理的期望值纔是明智之舉。對於決定自動化一個測試用例的一般規則是這個測試用例必須被運行 4 次以上。
這個數字是基於用戶對測試工具有良好的技能並且有一個良好的測試框架的。如果情況不是這樣的化，整個數字能夠是 10-20次或者更高。一個例子，在一個項目中測試人員花費和兩週的時間將手工測試的 23天的任務轉換成了自動化測試的用例。在完成使，項目能夠在 4 個小時在多個平臺上運行相同數量的測試用例。
2.5. 測試框架
測試框架對於產生成功的測試自動化的適當基礎是重要的。很多考慮必須被解決以使測試自動化更加有效地被使用。重點必須在：維護成本維護成本是成功的使用自動化測試的最重要的問題之一。維護成本直接聯繫到前面已經提到過的自動化測試的成熟度。組織或者項目必須至少要在成熟度的 3 級使用高度的測試庫才能使維護和更新測試功能變得容易。
測試數據
什麼樣類型的數據將被使用？要爲每一個測試用例生成測試數據還是使用在被測試應用中已有的數據。在很多的情況下一個測試數據被創建了，刪除他們是不可能的。
可測試性
自動化測試方案能夠有效的測試嗎？例如，被適當命名的對象（不僅僅是索引Id）。一個簡單的例子是所有的對話框都有相同的 ＃id 和相同的標題，所不同的僅僅是顯示的文字信息。當測試應該覆蓋多種語言的方案時，對話框的測試就是一個挑戰。
測試人員的技能
被包括在自動化測試的創建中的人員應該具有什麼樣的技能呢？如果他們具有良好的開發背景，那麼成熟度 3 級是足夠了。如果他們有很少的或者根本沒有開發的經驗，我們被迫使找到或者培訓一個自動化測試專家的小組，並直接到達成熟度 5級，在成熟度 5 級測試的創建與實際的測試執行被分離開。
一個好的構建過程
自動化測試的引入在"構建團隊"上加入了一些約束。爲了實現自動化測試的高利用率（迴歸測試），要求具有一個高的構建頻率。每週僅僅運行自動化的測試不是好的自動化測試的使用率。將回歸測試增加到每天一次將幫助快速的發現新的問題並使開發人員更加容易的發現問題的根源，因爲對測試的反饋時間是比較短的（開發人員能夠記住他們昨天做了什麼）。所有權不同的測試庫的所有權的定義是重要的。一個好的方案會將測試庫的組織劃分爲三個級別：
級別 1 － 全局的
這個一個通常的級別。被存儲在這個級別的測試功能能夠被所有的項目訪問。通用的和通常的功能象登陸、創建一個用戶都是這個級別很好的候選者。
級別 2 － 項目
在這個級別的測試功能是與特定的測試項目相關的，但是通常在項目中有用的比一定在項目外是有用的。通常級別 2 是級別 1 的功能的提供者。
級別 3 － 腳本
功能被直接關聯到特定的測試腳本。 I在這個級別中，通常一個測試功能的第一個版本是被開發的。在新的測試腳本的創建期間已有測試功能的重用性被發現，並被移到了級別 2 中。在這個級別上儘量最小化功能的數量，因爲它將增加維護工作量。還有很多有關測試框架的問題，但是這裏所提及的是一些基本的要被解決的問題。
3. 在哪裏使用自動化測試
有很多的情況下使用自動化的測試可以降低測試成本。我將盡量的突出在自動化測試中的不同的測試技術技術 描述 備註單元測試/組件測試 這個測試工作通常是開發人員的職責，很多不同的方法能夠被使用，比如"測試先行"，它是一個測試框架，開發人員在編寫代碼前編寫不同的單元測試。當測試通過時，代碼也被完成了。
通過使用正式的單元測試，不僅能夠幫助開發人員產出更加穩定的代碼而且能夠是軟件的整體質量更加的好。冒煙測試 冒煙測試是一般驗證別測試系統的功能性測試用例的集合。
冒煙測試背後的思想是確保基礎是可以工作的，以便"大的"測試工作能夠開始。 在構建過程能夠確保構建已經爲測試準備好時，冒煙測試通常是自動化的運行。功能/集成測試 這裏測試的工作關注在驗證在不同的組件之間的集成上。
這些類型的測試通常是被測試系統的更加複雜測試的基礎，大量的邊緣測試被合併以製造出不同的錯誤處理測試。系統測試 － 用例測試 這種測試是通過執行用戶場景模擬真實用戶使用系統以證明系統具有被期望的功能的測試。 這裏不需要進行自動化的測試。
安裝測試、安全性測試通常是有手工完成的，因爲系統的環境是恆定不變的。迴歸測試 迴歸測試實際上是重複已經存在的測試。通常如果是手工完成的化，這種測試只在項目的結尾執行執行一到兩次。 這裏完全有潛力應用自動化的測試。你能夠在每次構建完成後執行自動化的迴歸測試，以驗證被測試系統的改變是否影響了系統的其他功能。
性能測試 性能測試包括以下不同測試形式：
- 負載測試
- 壓力測試
- 併發測試
-.....
如果沒有自動化的測試工具，你將不能執行通過模擬用戶的負載實現的高密集度的性能測試。
4. 什麼時候使用自動化測試
我對什麼時候應該使用自動化測試和什麼時候應該使用手工測試進行了一個概要的總結：使用自動化測試 使用手工測試項目沒有嚴格的時間壓力具有良好定義的測試策略和測試計劃你直到要測試什麼，
你知道什麼時候測試對於自動化測試你擁有一個能夠被識別的測試框架和候選者能夠確保多個測試運行的構建策略多平臺環境需要被測試你擁有運行測試的硬件你擁有關注在自動化過程上的資源被測試系統是可自動化測試的 沒有適當的測試過程沒有一個測試什麼，什麼時候測試的清晰的藍圖在一個項目中，你是一個新人，並且還不是完全的理解方案的功能性和或者設計你或者整個項目在時間的壓力下在團隊中沒有資源或者具有自動化測試技能的人沒有硬件如果你正在從事自動化測試，那麼一定要記住要關注將自動化測試與手工測試結合起來使用。
首先，對於自動化測試率的目標是 10/90 （10% 的自動化測試和 90%的手工測試）。當這些目標都實現了，可以將自動化測試的使用率提高。記住創建自動化測試的測試用例要比創建手工測試的測試用例花費更多的時間。不要將你所有的測試時間都用在自動化的測試用例上。同時也要記住在測試期間對每一個被發現的錯誤都要花費一定的時間去處理。
5. 自動化測試的好處如果你正在你的組織中引入自動化測試，記住有很多不同的方面被包含了進了。今天在測試工作如何被進行上有很多不同的視圖。爲了能夠成功的實施自動化測試你應該提出這些問題：
測試覆蓋什麼？－ 我們沒有覆蓋什麼？
由於遺漏的測試我們沒有發現的"bug"會帶來什麼樣的成本？由於不好的測試，破壞已有功能性的成本是多少？如果"瑣碎的"測試被每天的運行，對於你的項目意味着什麼？如果我們能夠每天向開發人員提供他們最近代碼變更相關的反饋，對項目有怎樣的影響？這些問題都能夠被自動化測試滿足。你必須從自動化測試成熟度的級別 1 或者 級別 2 開始，並開始測量結果。根據我的經驗快速的向開發人員反饋並每天運行測試對於向自動化測試成熟度的級別 4或者 級別 5 是非常有好處的。
自動化測試有以下的貢獻：
降低風險 － 你知道你測試了什麼和沒測試什麼測試能在項目的早期開始並隨着時間一直擴展快速的反饋 － 自動化測試用例能夠隨時的運行在多個平臺上的測試能夠同時進行
更好的估計 － 你能夠對測試進度和被使用的時間有更好的瞭解優秀人員的集中 － 你能夠得到一個專家的團隊，並將他們的知識傳播給其他的項目喜悅 -你和你的團隊正獲得着成功
測試工具介紹
下面我介紹市面上相對比較廣泛的測試軟件，Rational中的Robot和MI公司的WinRunner的具體的用法。
Robot，俗稱機器人。它有幾個特點，第一，Robot它的語法相對簡單，是一種類似於VB的語法，所以上手快；第二，Robot的腳本組織結構類似於C的結構，相對容易理解；第三，Robot運行環境和可參數化，所以容易維護；第四，要求的機器配置相對較低；第五，Rantional系統集成的很多產品很優秀，而且適合面很廣；第六，相對價格比較低廉。
WinRunner的功能相對Robot相對來說有一下幾個特點。
第1， WinRunner的語法結構是類似於C的語法，理解相對容易；
第2， WinRunner的腳本組織形式是以目錄的形式組織的，所以相對來說比較好管理；
第3， WinRunner支持當前市面上的很多系統；
第4， 可以隨時Update檢查點的內容，使得腳本的維護量減少
第5， 機器配置相對要求高些；
第6， 集成了很多優秀的組件。
下面我就嘗試寫一個Robot的腳本。
題目：請檢查各種我們規定的字符是否過濾掉了，如果那些詞語沒有過濾掉請記錄下來。
測試腳本：
Function T_OpenTestFile(Filename as string)as integer
{
。。。。。。。。。。。。。
}
Funciton T_FilterWord(getword as string)as integer
{
。。。。。。。。。。。。
}
以上是兩個SBL文件，相當於C中的函數實體
那麼我們要建立一個SBH，相當於C中的頭文件，紅色的部分類似於一個類庫，我們把相關的或者具有相似屬性的操作或者函數定義在同一個類庫中。
Declare Function T_OpenTestFile Basiclib T_FileOpertion(filename as string) as integer
Declare Function T_FilterWord Basiclib T_FileOpertion(getword as string) as integer
我們現在建立一個腳本文件REC
＃include T_FileOpertion.sbh
Main()
{
。。。。。。。
}
在此腳本中就可以調用上面那兩個函數了。在以後的測試中，我們只需要維護過濾詞文件庫就可以了。這樣提高了工作效率，保證了測試的正常進行。
下面我就舉個例子，來嘗試用WinRunner的使用方法，其實例子相對很簡單，主要是想告訴大家這種語言腳本的組織方法是怎麼樣的？
測試工具在實際工作中的應用
現在在測試行業說的最多的有兩個問題，第一個問題是測試的待遇和地位，第二個問題是自動化問題。我這裏不談測試的地位，只談自動化測試。
如何做好自動化測試？這裏給出幾個分析方法，第一，被測試產品是否有延續性？第二，被測試產品的維護頻繁度？第三，被測試產品自動化的難度如何？
其次，如何選擇自動化工具，選擇容易上手的，測試腳本和測試數據容易維護的，價格低廉的。
正確的理解測試工具需要我們去引導，我們應該清楚的知道那些應該自動化，那麼能自動化，那些自動化程度會更高等。
工作中的自動化
測試的幾中方法
數據驅動法
數據驅動是測試中最常用的一種方法，它是在不修改測試程序的情況下或者稍微修改測試程序的情況下，不段的增加測試案例來進行自動測試的一種方法。
舉一個具體的例子：例如我們檢查登陸驗證（用戶名稱），
如果我們採用自動化測試，我們只需要在測試配置文件中增加或者刪除修改配置文件就可以達到測試的效果了。
要將兩個文件進行比較，就可以得到被測試程序的處理能力和結果了。
樁驅動
樁驅動也是一種常見的測試方法。這種測試方法是把某個模塊假設是正確的，然後把這個模塊作爲主核心，然後測試他傳出的參數和數據給其他模塊來處理，查看處理的結果。
我那EXCEL中數據舉一個現實的例子，大家都知道，當你輸入等號的時候，Excel認爲你需要計算，那麼處理流程就應該是接受鍵盤消息，然後處理。如果我們把輸入做爲一個樁，那麼來查看計算結果的話，就可以知道那些信息處理了，那些信息沒有處理。
樁驅動的核心其實很簡單,就是首先對樁模塊做一個假設和詳細測試,認爲樁模塊是足夠健壯的;第二,樁模塊是驅動機,能夠和很多模塊發生調用關係,是核心部件.
關鍵字驅動
關鍵字驅動和樁驅動有些相似的地方，關鍵字驅動的核心是
網絡方面的測試方法
數據庫測試要點
網絡遊戲測試要點
下面我和大家探討網絡遊戲的測試方法。網絡遊戲是一個信息相對集中的一個網絡產品，它牽扯到客戶端和服務端以及客戶端之間的通訊。下面我們就結合具體的例子來分析
我舉一個Mmog的例子（注：mmog是大型網絡遊戲的縮寫），大型網絡遊戲主要是即時戰略性質的，所以通訊上採用TCP協議來發送數據包。TCP協議發送數據包的優點是儘量能夠減少數據包的丟失，他是對數據包的一個精包裝，一般的發送數據包採用實時處理的形式，即採用堵塞式的處理模式，而不是等到一定空間的數據包滿了以後才一起發送（非堵塞式的處理模式）。
上面我們只是簡單的講了mmog遊戲數據包發送的形式。下面我們分析網絡遊戲服務端測試的重點。
網絡遊戲服務端的主要作用：下發玩家信息，仲裁勝負信息，仲裁裝備信息，服務器之間中轉信息，狀態存盤，玩家信息存盤等。我們來一個個的分析，服務端要處理這麼多的事情，在處理什麼事情的時候壓力最大呢？那肯定是下發玩家信息最大，爲什麼這麼說呢？因爲在下發玩家信息的時候，服務端會把每個人的信息和地圖上的所有的信息，而且這個信息是當地圖上的玩家和元素的增多而增多，當地圖上的人越多的情況下，服務器的處理信息的量就很大。那麼分析這麼多，我們主要測試什麼？測試同步消息的傳遞。就是在很多玩家的情況下，信息能否順利的通知給各個玩家。
如果做這樣的事情呢？根據經驗（可以另外想辦法），建議編寫一個機器人，我們能夠操作機器人，這個機器人需要處理什麼事情呢？希望機器人能夠在以玩家爲中心的地方隨意走動，能夠跟隨玩家跨地圖，能夠按照設定施放技能，能夠聊天。通過機器人的每一個動作我們來觀察服務的各個性能表現。關心那些性能表現？大家可以參考LoadRunner提供的業界比較官方的指標進行覈對。
網絡遊戲服務端的測試相對比較複雜，對測試人員的要求比較高，測試人員必須瞭解用什麼協議通訊的，怎麼通訊的，服務器都處理了那些事情才能具體的分析測試重點和測試方法怎麼做。
對於客戶端的測試應該相對簡單些，我這裏說的客戶端的測試不包含數據平衡部分。客戶端主要是驗證功能邏輯。例如我舉個例子，任務系統，現在每個遊戲都有任務系統。如果測試任務系統，我們應該怎麼測試？首先完成任務的條件是什麼？完成任務需要什麼道具？玩家能得到什麼道具？道具是否可以交易，拾撿？道具是否可以買賣？玩家跟NPC交付任務斷線處理？NPC在不同的狀態下所說話的內容？是公共任務還是門派任務？在得到道具過程中儲物箱滿了會怎麼處理？在負重超出了本身能力的情況下怎麼處理？等等，把細節的問題考慮清楚了，這樣設計案例執行就是了，沒有自動化的必要（但是可以在組件測試中進行自動化，系統測試沒有必要自動化）。
客戶端還有一個測試點就是地圖，因爲地圖是遊戲的門面，所以地圖的檢查點：絢麗度，整個地圖的亮度，不同分辨率下的地圖顯示，地圖的拼接，地圖上NPC或者怪物的分佈等等。網絡遊戲的測試是積極具有挑戰性，包括能力，耐力，創造力的人奮鬥。
還有一種是休息類遊戲，例如盛大網絡的泡泡，客戶端之間主要是通過UDP進行通訊。關於UDP通訊的檢查和測試我在這裏先不做詳細描述，以後進行補充。
C/S結構測試要點
網絡遊戲現在是C/S架構的一種，但是我們平常所說的C/S是一種類似於銀行系統，購物系統等，這種系統要求：服務器處理能力強，反饋及時，但是有一個特點，這種服務器壓力是出現在業務繁忙的時候，所以在測試這種軟件的時候，需要完全弄清楚業務邏輯，業務點在那裏？信息同步在那些方面需要關注？服務端數據處理流程是什麼？如果把以上問題搞清楚了，測試的重點也就出來了，這裏我不再舉具體的例子，因爲C/S架構的軟件是相通的。
下面我就舉個例子,給大家看看,關於C/S架構的mmog類型的遊戲測試,服務器的壓力那裏,測試的重點在那裏?
市面上90%以上mmog類型遊戲採用的結構。
當客戶端要求登陸服務器的時候,通過賬號數據庫驗證,然後取出該賬號對應的角色,然後告訴客戶端你是我們的用戶,然後由網關把該玩家連接到響應的GameSvr上.
客戶端向服務器發送登陸請求,如果採用非阻塞式,使得各個客戶端的請求形成非隊列式,那麼服務器壓力不會很大,如果採用阻塞式,那麼客戶端感覺服務器處理速度就會很慢,玩家不答應,所以大多采用非阻塞式,處理速度快.而且玩家和賬號數據庫不是長期保持連接,只是保持一個心跳而已.這樣就得出一個結論,用戶在登陸的時候,對服務器不會造成多少壓力.
那麼什麼時候會造成壓力呢?
玩家走路,大家都知道,網絡最主要的特點是同步信息,也就是說,當一個玩家走動以後,服務器首先要計算一次,當前玩家指的座標是否正確,其次,服務器要下發消息,告訴周圍的玩家,他現在在那裏,怎麼樣的姿態存在.因爲服務器會給一定範圍內的玩家通知這些信息,造成服務器壓力增多,因爲服務器(GaemSvr)和玩家保持的是一個TCP的長連接,如果當前服務器或者一屏(或者說一定範圍內的玩家相對比較多)的情況下,服務器要處理當前服務器上類似於上面描述的若干個這樣的情況,造成服務器壓力巨大.
除了走路,還有什麼會造成服務器壓力大呢?
聊天,爲什麼說聊天會造成服務器壓力比較大呢?因爲當A對B說話,服務器需要尋找,當前B在那裏,然後通知A,B在,你可以說話給他,這個時候A纔可能和B說話.如果人相對比較多的話,可能造成服務器壓力大.
跨服務器行走,也會造成服務器壓力巨大?
因爲當你從一個服務器跨到另外一個服務器的時候,服務器需要把第一個服務器上玩家的數據拷貝的另外一個服務器,然後初始化一個實體,然後再告訴DB,把這個人的數據存盤一次,然後再嘗試跨服務器,如果跨不成功,如果成功,則把該數據初始化給本玩家,如果不可以,則另外處理,這樣造成服務器的壓力大.
總上所述,不是所有的C/S結構的產品,我們以上來就模擬人多的情況怎麼樣,而是要分析,那塊的壓力真正的大,壓力大的情況下會影響到遊戲邏輯和數據在那裏?需要冷靜的分析這些情況,纔可能有效的執行測試.
綜上所述,我們知道網絡的測試重點是相同通訊,數據同步和存儲,那麼在進行測試的時候,需要熟悉的瞭解各個部分相互通訊的模式是TCP還是UDP模式,那麼各個模式有各個模式的特點.
TCP是通訊協議是把數據包進行精包裝,然後在網絡鏈路中進行發送,它需要進行三次握手纔可以確定數據包的發送與否,丟包的機率很小,但是自身有補償機制,使得包數據傳輸的過程中可靠性大大加強但是缺點是速度相對很慢.
UDP通訊是另外一種數據包傳送模式,這種方式的特點是傳送速度快,但是容易造成數據包丟棄.
所以除了瞭解各個部分的通訊協議之外還需要了解,當丟包了以後,對數據包進行補償的兩種方法,第一種方法是把從丟失的第一個包到當前包作爲一個整體的包,進行包的重播,這樣的方法會使得從客戶端看到通常我們在遊戲中所出現的”卡”現象,還有另外一種補償機制,就是把前面的數據包丟棄,然後播放最後一個數據包信息,這樣就會在其他的客戶端看到一些莫名其妙的現象.
WEB測試要點
Web測試的要點其實很多，但是Web測試的着力點其實不多，因爲基於Web現在有兩個重點，一種是基於平面的靜態的，只是更新新聞，那麼這個的測試點相對簡單，主要是各個鏈接正確性，服務器瀏覽量等，還有另外一種就是基於Web的P To P的通訊，需要註冊，牽扯到用戶信息，那麼這些測試重點在於P To P通訊的順暢性，數據的可靠性。
嵌入式軟件的測試方法
手機軟件測試
手機現在在社會上應用很廣，同時針對手機上的功能增加也非常快，例如，藍牙，例如，短信，例如，信息下載，手機遊戲等，這說明在未來發展中，手機將人們帶在一個孤獨的社會中去。
簡單回想，我們的上輩人開始用手機，那是後簡單的目的：就是通訊，而且還必須在既定範圍內，價格高昂等，這些只有很富有的人才能染指的東西現在在社會中的每個角落都可能。放羊的。。。。
那麼手機軟件怎麼測試呢？測試什麼呢？怎麼組織呢？
那麼我做簡單的分析：首先確定手機軟件是嵌入式軟件，那麼我們拋開IC測試，拋開盲區，耐久性，耐碰撞性測試不提，就軟件本身測試需要考慮的內容。
我們說了這麼多，我們整理出來手機軟件測試的核心是數據的時效性，怎麼理解呢？不能說我發了個短信，對方一天都無法收到？或者我打電話，對方沒有任何反映，這就說明有問題。
在例如，通過手機的紅外線，能把地址薄中的資料傳送的電腦中，如果在傳送的過程中出錯，或者對操作系統有要求，或者在傳輸的過程造成數據丟失，導出來的數據是無法識別的格式等，都會造成該功能無效。
再如，手機信息的存儲問題，因爲手機本身有自己的系統，有自己處理信息的方式和格式，那就牽掣到的問題和外界信息交互的問題，外界需要了解其格式，閱讀其格式，就需要和外界有比較信任的通訊。
其次，是測試本身的功能，例如，能夠正常撥打電話，能夠正常編輯信息，能夠正常保存朋友電話，能夠有歷史記錄，能夠正常鬧鐘和各種設置，能夠正常有提示信息等。
我再舉個例子，手機中游戲軟件的測試，我們先了解手機中游戲開發語言Java，其次，由於手機中的內存大小優先，所以遊戲的大小以及運行的各種指標都很小，所以用KJava。還有一個特點，手機中的遊戲是回合制，所以類似的同步要求不是很高，所以測試重點就有所改變。
那麼像手機遊戲的測試點在那裏呢？瞭解這個方面的測試，需要了解幾個問題，運營商對產品的要求：
運營商對開發商提出的要求，一般情況有這麼幾種。第一，應用程序的大小；第二，應用程序的命名規則；第三，應用程序版本控制規則；第四，明確提出所支持的機器的類型；第五，採用的編碼格式UTF_8的編碼還是其他的編碼；第六，外部中斷的處理邏輯；第七，比對壓縮後的文件和先前文件的比較。
上面我提出了手機軟件測試的七個重點，下面我逐步添加詳細介紹各個部分的細節。
第一，應用程序的大小。由於應用程序在被下載時百寶箱會根據需要插入5K的程序代碼，因此要求SP提交的應用程序其大小不能超過手機最大下載尺寸減5K，下表列出了目前市場上部分JAVA手機對JAR文件下載的字節數限制情況（未列入機型請SP諮詢手機廠家）
其次，由於應用程序在被下載時百寶箱會根據需要插入程序代碼，這段代碼在手機上執行時要佔用10K左右的堆內存，因此要求SP提交的應用程序在運行時要預留至少10K的堆內存。
第二，應用程序的命名規則。應用程序的命名規則的字符長度不能超過12個字符長度，而且命名有一定的規則，需要SP和提供商商定，但是必須依照行業標準。另外，在提交的時候，需要了解一些要求，由於各個SP開發商開發環境，編譯環境等問題，所以運營商都提出嚴格的打包要求。
SP遞交應用程序打包要求：
1. JDK使用1.3.1版本（國際版）；
2. 打包工具使用SUN公司提供的J2ME Wireless Toolkit (midp1.0版本，1.0.3或1.0.4)；
由於SUN公司的WTK只支持標準的midp1.0，不支持各手機擴展的API，需要SP對所使用的WTK進行擴充纔可以支持手機擴展的API，方法是：將擴展API加到D:WTK104libmidpapi.zip（假設WTK安裝在D:WTK104目錄下）中即可。
3. 不做擾碼或使用RetroGuard進行擾碼，不得使用別的擾碼工具。
說明：1. SP在開發時仍然可以使用原來的工具進行開發，但遞交應用時請使用SUN公司的WTK進行打包；
2. 如果SP不按照要求進行打包，出現百寶箱不能識別API的情況時將按照測試未通過的情況處理。
第三，版本控制要求是，版本控制的格式x.x.x，應該嚴格遵守這個規則。
辦公類產品的延續性相對較長，所以部分模塊有利於自動化測試。我在這裏介紹辦公類產品的測試重點在那裏？
辦公類產品的特點是人們在辦公中經常要用到，頻率很高，所以簡單，易用，方便操作容易理解成爲辦公類產品的首要要求。
其次辦公類產品考慮的機器的硬件配置，例如顯卡，打印機等外設
第三，辦公類產品還需要測試兼容性，因爲自身延續性長的特點。
第四，辦公類產品需要保證數據安全
第五，辦公類產品本身的功能邏輯
那麼怎麼才能做好辦公類軟件的測試呢？
首先辦公軟件的核心是辦公，日常生活中要用到，那麼按照各種排版格式自己去排版就好了，在這個過程中詳細得出一些結論：
第一可操作性；第二，各個模塊的使用邏輯，例如：在文件中插入對象，對象能否體現出來，設置對象的繞排方式，能否設置成功，能否體現，設置對象是否打印；第三，存盤，數據安全考慮，看存盤後對象是否保存，各種字體設置是否保存，繞排方式是否保存等。第四，兼容性，因爲用戶使用的辦公類軟件很多，需要文件共享兼容。其次是本身高低版本的兼容性，需要着重考慮。第五，文件大小和不同文件格式的存盤信息。第六，各種性能指標，包括啓動速度，佔用磁盤大小，在使用的過程中CPU的佔有情況；第七，快捷鍵的設定和檢查，不要和系統的快捷鍵衝突，並且支持系統的各種設置支持系統剪貼板功能；第八，支持網絡傳輸，能夠自由的通訊和共享，能夠支持協同工作，能夠充分體現修改數據的同步信息。
殺毒類產品測試
殺毒類軟件是一種工具類軟件，隨着網絡的普及，殺毒軟件也越發顯得重要，那麼殺毒軟件的測試重點是：
能夠發現病毒
操作系統檢查
能夠正確的報告並且查殺病毒
佔有的CPU佔有情況
查殺病毒的內存使用情況
數據安全
軟件衝突
病毒庫升級
自動更新
那麼在殺毒軟件的時候，還有一個重要的東西，就是用戶的數據安全，當殺毒軟件能夠清除含毒文件中的毒的時候，一定要包含用戶文件的可靠性。
ERP軟件的測試方法
驗證測試
測試管理工作
我沒有讀過管理方面，只是看了一些書而已，在幾個團隊中應用，效果還可以，所以拿出來和大家交流。
其實無論是開發管理和測試管理，其核心應該是“理”，如果理都不通，那麼管只能是強制性質，那麼在軟件行業，創造性的企業中，可能不能維持的很久，所以需要先“理”清楚了，然後我們來管，到那個時候也就不用管了，因爲理順了，所以大家都知道該怎麼樣做，什麼時候做了。
那麼談到“理”，我們需要理什麼呢？理事情，把要做的事情理清楚；理目標，把要達到的目的說清楚；理思路，把做事情的思路和方法理清楚；理資源，把合理的資源調配到合適的位置上，讓興趣和能力結合。我覺得從大的方面就需要先將這些事情理清楚了，纔可能使得一個團隊具有非常的戰鬥力。
其次，還需要和善的溝通，做到無所不曉，因爲在一個團隊中，氣氛非常重要，也許一個人的今天心情不好，造成跟他配合的幾個人都無法工作順心，也許是感應。所以需要和大家開誠佈公，把能講的問題，能講的事情講清楚，讓大家覺得你可以依靠，可以把心思告訴你，你盡力爲大家解決後患問題，讓他們能夠開心踏實的做事情。
另外，需要換位思考，充分讓大家提出意見，因爲如果一個團隊要發展，是需要大家一起努力的，這是大家都熟知的道理，但是做起來很難。避免一言堂，讓大家充分參與到設計中，在其中找到自我的感覺，找到這裏沒有他是不可以的，這樣每一個人才能關心項目的每一個角落，而不是爲了工作而工作了。
其二，需要在“理”的基礎上幫助大家總結，大家在什麼地方容易犯錯誤，犯什麼類型的錯誤，犯錯誤的原因是由於我們的思想老化了，需要改進做事情的方式，還是由於工作能力或者經驗的問題。
那麼就需要對各種錯誤進行統計，以找到問題的根本原因。就問題而討論問題，問題的實質出在那裏，然後幫大家改進，自己同時也會進步。給大家講我現實中的例子吧，我曾經帶的一個測試組，大家做事情都很賣力，而且成績也非常顯著，但是在做的過程中總是會有問題發生，問題到底出在那裏呢？後來找到了原因，就是由於工作環節中出現問題了，所以他總是在那裏犯錯誤，因爲他是把工作當成工作來做了，所以他就改這個地方，我後來找到他，也找到了問題的原因，一起把問題解決了。後來我就告訴他們，如果誰在同一個地方犯同樣的錯誤，我們的結論是他不懂，教他，共同學習，直到他告訴我可以了；如果第二次犯錯誤，那麼我們給的結果是，他忘記了，好再學，直到他告訴我，他可以了；第三次犯同樣的錯誤，我們給的結論是故意犯錯誤的，那麼就要全組請喝可樂一灌。
這個例子在現實生活中很多，主要是引導，因爲如果把工作當成工作來作，可能不會用“心”，因爲如果是用“心”工作他會找竅門，會找方法，負責他會厭煩；如果把工作當成自己未來的事業來做，那麼就會用心工作，這樣就需要我們正確的引導。
開發方面開發分析
因爲我們是第一次做MP3的產品，所以從技術上還處於摸索階段，第二我們對產品的質量意識還存在一點問題，第三，四方溝通或者說回饋不夠.
進度問題
四方配合問題，因爲在任何一家公司做嵌入式軟件的企業，存在硬件、軟件開發，市場開發，測試準備四個方面的組織需要開展工作，所以那個組織的進度耽誤都會嚴重影響產品的發佈週期，在現在競爭日益劇烈的市場中，必須把握市場機會，所以需要對進度進行把握。
建議採用作戰圖的形式，對各個階段點進行有利的把握，以給各個方面贏取更多的時間，明確職責範圍，則權利的有利結合，激發各個方面的積極性。採用利益共同體的原則，將各個方面合理的結合，讓開發關心測試工作，讓測試關心開發工作，這樣形成一個有利的整體，讓市場及時反饋信息，使得項目順利進展。
溝通問題
SPEC設計完成後，各個方面在限定的時間內做出反饋，以及時跟進，以便對產品有個明確的定位，各個方面對方案認可後，切實執行，如果出現技術問題，及時通知有關人士，以便進度和方案進行合理的修改和微調。在產品開發階段，需要及時的總結可能遇到的問題和對問題的解決方案，通知相關人士，使得項目組的人有一種歸宿感覺。
開發需要給每個Bug做出合理的解釋，或者對我們的測試人員進行相關培訓，以便測試人員能夠深切的理解產品，能夠對產品進行合理嚴格的測試。
這裏提出一個建議,在測試人員提出Bug以後,知道表現,一定要弄清楚問題發生在那裏,是什麼導致這個Bug發生,纔能有效的分析結構,有效的進行案例的補償和測試.
跟蹤問題
跟蹤問題牽扯到Bug的跟蹤和進度跟蹤，Bug的跟蹤需要一套流程，及時的出來Bug,使得發現Bug和解決問題形成一個完整的流程。
進度跟蹤的方法，建議採用階段點產品，定義明確的時間點，明確各個時間點上完成的功能點，保證產品可以編譯，可以抽查，可以運行以完成的相關功能。這樣使得大家在各個時期能夠看到大家都在進步，產品在進步，有利於整個團隊的士氣。
版本控制問題
定製嚴格的產品發佈流程，降低由於時間問題，壓縮測試時間，給產品發佈帶來的風險。建議採用的方法，由項目組定製編譯計劃，然後有相關人士進行討論，各個方面達成共識之後，堅決執行。
版本控制和進度控制密切相關。
進行嚴格的代碼管理，以保證公司機密資料，在代碼Check in 和Check Out的時候建議由專人進行審覈後方能入庫，以免誤操作或者敵意的操作造成代碼沖刷。控制版本有幾個好處和優點。
關於Bug的回饋優點
第1、 開發方面回饋速度快
第2、 解決速度快
關於測試情況的總結
第1、 涵蓋情況
第2、 Bug的質量問題
開發體系問題
第1、 設計的分析做嗎？技術難度？設計的合理行，進度的可行性？
第2、 單元測試做了嗎？
第3、 CVS的Check In控制了嗎？
第4、 進度風險預估了嗎？
第5、 進度控制如何進行的？
產品方面：
產品分析：整個產品在開發前期，市場已經找到了市場切入點，但是在現在產品要發佈了，我們不能或者說很難用一系列的數據做說明，告訴高層這個產品可以發佈了或者說不能發佈，因爲分析的數據太少了。因爲數據是說明問題的基礎，但是現在定了產品發佈的標準，只是一個現存數據，沒有預估分析可能性，對產品投入市場可能存在風險。
建議：
第1、 案例執行率
第2、 案例發現bug率
第3、 重複bug率
第4、 KLOC
第5、 產品日測試彙總圖（察看歷史曲線）
對產品研發整體改進思路
第一步、增強開發質量意識
做法：這個是個長遠任務，但是我們可以做具體的事情，例如：檢查開發單元測試情況或者單元測試代碼等活動
對設計的模塊案例檢查回饋情況，把質量和開發邦定，不要讓測試單獨承擔這個壓力。
活動方式：宣講，制度，執行，邦定
第二步、增強測試本身素質
做法：因爲測試不成型，這是現狀，所以我們通過提供一些數據來提高案例設計的能力或者說告訴測試人員我們的缺陷在那裏。這個是長遠的事情，因爲需要人力去做這個事情。提供如下數據：重複報告率，案例和Bug的比率等。加強程序概念的培訓或者框架的瞭解，盡力從程序的概念上理解產品，儘量避免例冗餘。
活動方式：培訓，數據，比較
第三步、對產品開發過程中版本編譯的控制
做法：CVS庫權限控制，所有的Check in和Check out需要控制，檢查代碼後方可入庫。另外需要制訂完整的開發計劃和編譯計劃，使得項目跟蹤超向正規。
活動方式：專人控制，以面沖掉原來的代碼
第四步、進度控制
做法：在產品開發週期中定製完整的編譯計劃，對階段性產品進行測試或者抽查。以保後期測試時間的爭取和質量的保證。
活動方式：認可，執行，調整
第五步、控制進度問題
做法：明確開發模式，列舉詳細的開發進度，詳細提出開發的功能情況，樹立作戰詳細進度表或者叫作戰牌，以鼓舞士氣，讓每個參與者瞭解進度
活動方式：承諾，監督，跟蹤
1做法：統一平臺，統一流程，統一做事方式，實現任務單跟蹤
活動方式：準則，平臺，優化。
混跡在互聯網圈的軟件測試開發一枚，
專注軟件測試自動化方向，爬蟲國內外測試資源，分享給自學愛好者。
知乎專欄：軟件自動化測試共享站 。
微博：@ 西說測試
QQ羣:330374464 。
公衆號：testpu 。
