PAGEPAGE1目錄目錄 2測試介紹 4序 7測試的分類 8單元測試 8集成測試 10系統(tǒng)測試 13驗收測試 15測試方法 16黑盒測試 16白盒測試 17灰盒測試 17測試方面 18測試改進方案 20測試工作需要回饋 20測試工作需要總結(jié) 22需要交流平臺和形式 22采用的方法 23讓別人給服務(wù)說話，清楚認識自己 23自己回頭看 24了解同類產(chǎn)品 25提高自身素質(zhì) 25如何提高程序能力 26耳濡目染 26自己練內(nèi)功 27實踐中檢驗 28測試發(fā)展 28如何提高測試 29制定完備的測試計劃 29提高案例設(shè)計水平 30逃避測試的誤區(qū) 34如何調(diào)整團隊的作戰(zhàn)能力 37歪曲理論推理 39正確理解自動測試 40測試工具介紹 53測試的幾中方法 54網(wǎng)絡(luò)方面的測試方法 55數(shù)據(jù)庫測試要點 55網(wǎng)絡(luò)游戲測試要點 55C/S結(jié)構(gòu)測試要點 58WEB測試要點 61嵌入式軟件的測試方法 61手機軟件測試 61MP3軟件測試 63通用軟件的測試方法 63辦公類產(chǎn)品測試 63殺毒類產(chǎn)品測試 64ERP軟件的測試方法 64驗證測試 64測試管理工作 64開發(fā)方面 66開發(fā)分析 66問題分析 67目前存在的問題 67產(chǎn)品方面 70第一步、增強開發(fā)質(zhì)量意識 71第二步、增強測試本身素質(zhì) 71第三步、對產(chǎn)品開發(fā)過程中版本編譯的控制 71第四步、進度控制 72第五步、控制進度問題 72

測試介紹測試現(xiàn)在被普遍認為“保證產(chǎn)品質(zhì)量”這個籠統(tǒng)的說法下，而測試本身是什么呢？今天我們就測試本身跟大家一起討論。測試是在研發(fā)產(chǎn)品的整個過程中的一個跟蹤活動,他在各個階段報告給人們當前項目的狀況,能夠督促和提示項目經(jīng)理或者高層經(jīng)理對項目的關(guān)注點.國內(nèi)的測試的定義,一般是在產(chǎn)品的研發(fā)后期,對產(chǎn)品的功能進行驗證的一個系列活動。國外的測試已經(jīng)發(fā)展比較成型了，而國內(nèi)的測試現(xiàn)在還處于摸索階段，至于超著那個方向去發(fā)展，我覺得大家目前還是處于比較迷茫的階段。 主要原因是：國內(nèi)軟件產(chǎn)業(yè)起步晚，而且質(zhì)量意識不強，造成了軟件工業(yè)發(fā)展緩慢，配套行業(yè)（測試發(fā)展緩慢），我覺得這個很正常，因為從人類歷史發(fā)展的角度來看，這個是必須經(jīng)歷的階段，從有這個概念到摸索，目前國內(nèi)的測試應(yīng)該處于沉思期，主要是沒有一個全套的指導(dǎo)思想，另外一個原因是行業(yè)發(fā)展方向不明朗。國內(nèi)存在對測試的誤解，所以造成了測試現(xiàn)在成了大家進入企業(yè)的跳板，要么就是覺得自己的能力還不夠，目前只能從事測試，要么就沒有編寫程序的能力，但是同類產(chǎn)品比較了解，所以做測試。 我對這個問題我有自己的看法，我覺得在企業(yè)發(fā)展的同時，個人要發(fā)展，那么個人怎么發(fā)展呢？（我說的是測試人員），在國內(nèi)，對應(yīng)的測試的技術(shù)總結(jié)的相對很少，并且現(xiàn)在國內(nèi)的企業(yè)測試都是把測試過同類產(chǎn)品當成了經(jīng)驗。我個人覺得這并不是錯，但是我個人覺得有點偏頗。因為真正從事測試行業(yè)的人都知道，測試是需要一定的技術(shù)功底的，在國內(nèi)雖然對測試這么要求，是因為國內(nèi)的大環(huán)境有質(zhì)量的意識形態(tài)所導(dǎo)致，對質(zhì)量的意識還只是停留在理解和使用上，不是從設(shè)計或者原理或者其他方面保證質(zhì)量的。如果我們說對測試的定義是對某類產(chǎn)品的經(jīng)驗上，那么這個人是對和他合作過的程序員和設(shè)計師比較了解，而且能夠總結(jié)出來某些人在那些方便容易出錯，但是當更換環(huán)境以后，這些經(jīng)驗是否還能有用呢？如果我們把測試的方法整理成技術(shù)，那么他形成一個規(guī)則或者說是一個標尺，我們只是分析什么樣產(chǎn)品的需要用什么方法來測試，而且需要了解的知識架構(gòu)是什么？怎么把這些知識穿插起來，那么積累就不會被約束，但是不能撇開經(jīng)驗，因為經(jīng)驗本身是設(shè)計出好的案例的基礎(chǔ)，但不是唯一的基礎(chǔ)。 我們再來看看測試案例的設(shè)計，測試案例的設(shè)計在國內(nèi)現(xiàn)在是一些剛剛?cè)胄械牟粫懗绦蚧蛘叱绦蚬Φ妆容^差的人在寫案例，那么這些人設(shè)計出來的案例只是包含了整個測試過程中功能測試的一部分案例而已，因為他們不懂得或者不理解程序，不是從原理上去分析產(chǎn)品，不是從邏輯上去分析產(chǎn)品，而是從用戶使用的角度去分析產(chǎn)品，這樣設(shè)計出來的案例的可行性和可信度多大呢？大家可想而知了。所以我們在整個引導(dǎo)大家的過程中，從技術(shù)和方法，結(jié)合具體實例和針對不同類型的產(chǎn)品的測試方法進行跟蹤和描述。 首先，什么叫測試？測試干什么？測試，是在開發(fā)過程中的一種活動，它是分白盒測試和黑盒測試。在不同的階段不同的人所承擔著測試這個角色，我們把整個活動統(tǒng)稱為測試。測試的工作內(nèi)容主要包含了設(shè)計測試計劃，設(shè)計測試案例，執(zhí)行測試，進行測試總結(jié)。執(zhí)行測試是在產(chǎn)品開發(fā)的整個過程中進行的，包括了單元測試，系統(tǒng)測試，集成測試，系統(tǒng)測試和驗收測試，那么不同的階段測試的重點不同。單元測試的重點是函數(shù)級，包括需求，包括算法，包括接口預(yù)留等內(nèi)容。集成測試是指把小模塊結(jié)合起來，測試的重點是輸入輸出數(shù)據(jù)，參數(shù)的處理，錯誤預(yù)處理，接口規(guī)范，參數(shù)約束等測試內(nèi)容。系統(tǒng)測試的重點是功能性質(zhì)，它的測試重點是按照需求來對照測試，主要是功能實現(xiàn)的情況，包括功能使用邏輯和操作邏輯，操作系統(tǒng)，兼容性（軟件和硬件）等內(nèi)容。驗收測試，主要是合同性質(zhì)而言的，在國外現(xiàn)在軟件外包情況比較多，那么雙方按照合同規(guī)定履行自己的職責，把功能按照合同約定的形式條條比對。這是主要方面，那么在企業(yè)內(nèi)部，驗收測試是除了功能驗收以外，還包括易用性，軟件的親和度等方面的內(nèi)容。

序我是一個充滿激情的人，我把所有的激情投入到生活的每一個空間。我是一個不停折騰的人，因為生活在不停的折騰我。我是一個不服輸?shù)娜?，因為我知道這個社會不會同情弱者，只有不停的折騰，才有可能把握自己的命運。我是一個傲慢的人，因為我把自己已經(jīng)當成是行業(yè)的開拓者。我是一個平和的人，因為我和不同的角色在對話我是一個開放的人，我會將我知道的或者了解的用無私的信鴿傳播

測試藍本（初稿）王振剛（2004-4-14）測試的分類 單元測試 單元測試是在測試過程中的最小粒度，它在執(zhí)行的過程中緊密的依照程序框架對產(chǎn)品的函數(shù)和模塊進行測試，包含入庫和出口的參數(shù)，輸入和輸出信息，錯誤處理信息，部分邊界數(shù)值測試。 這個部分的測試工作在國內(nèi)現(xiàn)在是開發(fā)人員進行的。我相信未來的發(fā)展應(yīng)該是測試工程師來做這個事情。那么需要測試人員需要深刻的理解程序，理解需求，理解設(shè)計，這樣才能發(fā)現(xiàn)問題。 還有一種在國內(nèi)先在操作的方法，就是當一個模塊給某個開發(fā)工程師以后，需要他給大家講解他要完成這個模塊或者函數(shù)的整體流程和思路，進行統(tǒng)一評審，使得問題能夠暴露的更充分些，這樣做的目的有以下個，第一，使得大家對設(shè)計者的思路明晰的理解，以便以后調(diào)用或者配合的時候能夠真切的提出需求或者相對完美配合。第二，在評審的過程中，如果發(fā)現(xiàn)問題，那么大家可能沒有犯過，這樣就會更加提高警惕，如果犯過，就會回想當時自己怎么解決的或者規(guī)避的，使得大家能夠在錯誤的過程中快速提高。第三，可以對平常犯錯誤進行一個積累，我覺得這是生動的教科書，可以使得新的人員在新上手的時候遇到這樣的問題以后，我們就可以給他一個解決問題的方法或者方向。 回顧，我們上面給大家介紹了兩種方法，第一種就是通過在開發(fā)的過程種進行測試，由開發(fā)（測試）工程師寫測試代碼，對所編寫的函數(shù)或者模塊進行測試，第二種就是通過代碼互評發(fā)現(xiàn)問題，將問題進行積累，形成知識積累庫，以便使得新人在同樣的方面不至于再犯錯誤。 單元測試非常重要，因為他影響的范圍和寬度比較大，也許由于一個函數(shù)或者參數(shù)問題，造成后面暴露出很多表象問題出現(xiàn)。而且如果單元測試做不好，使得集成測試或者后面系統(tǒng)測試的壓力很大，而且項目的費用和進度可能就會飚升。 對單元測試，現(xiàn)在用CPPUnit的比較多，市場上也有其他對應(yīng)的產(chǎn)品，他們在不同的軟件單位不同的階段。正確的理解單元測試的重要性是意識，需要在過程改進種不停的總結(jié)，慢慢的積累，將質(zhì)量意識滲透到整個開放過程中的各個環(huán)節(jié)。 保證單元測試順利進行，需要滲透軟件工程的很多思想，把CMM和跟蹤機制建立起來，問題的分類、跟蹤，如果把軟件環(huán)節(jié)整個活動都滲透了，那么產(chǎn)品質(zhì)量的意識自然就增強了。 COM思想現(xiàn)在在大的項目現(xiàn)在體現(xiàn)的淋漓盡致，因為如果不采用COM機制，維護和升級以及修改測試的成本很大，所以現(xiàn)在大型項目基本上都采用COM的組織形式。 說了這么多，單元測試做什么呢？單元測試主要是做一下幾個事情：模塊或者函數(shù)的設(shè)計稿代碼規(guī)范，其中包含代碼書寫規(guī)范，對齊方式代碼的注釋。非常重要參數(shù)類型，數(shù)據(jù)長度,指針，數(shù)組長度大小輸入輸出參數(shù)和結(jié)果創(chuàng)建對象后是否刪除了，如果在這里沒有刪除，請注明在那里刪除是否應(yīng)用了沒有初試化的變量，如果是，請指明該變量在那里初始化變量是否聲明，聲明是否按照要求進行調(diào)用此函數(shù)需要的滿足條件需要注明在此函數(shù)或者模塊中用到了系統(tǒng)或者其他第三方插件函數(shù)，需要滿足的系統(tǒng)條件上面我只是列舉了一些在測試過程中發(fā)現(xiàn)或者隱藏的問題，我想可能還有很多情況引發(fā)問題，請大家補充，以便在工作中有操作性。 集成測試 集成測試是在保證單元測試進行后進行的一個動作，能否集成的標志不是所有的代碼編譯通過了就算是可以集成了，而是所有的能夠在這個虛擬環(huán)境下能夠正常運轉(zhuǎn)。 在集成測試種一般采用的方法是數(shù)據(jù)驅(qū)動或者樁驅(qū)動，因為集成測試不能看到產(chǎn)品的表象，因為他是一些數(shù)據(jù)流的中間段，我們渴望能夠?qū)χ虚g數(shù)據(jù)進行分析，就可以知道或者就渴望知道流程或者算法中有什么不妥當?shù)牡胤健?集成測試比較適合做成自動化測試，當然首先我們分析了適合做自動化的條件是滿足的，我這里就不講詳細的方法，到后面的自動化測試介紹中，我會提到這個方面的問題。下面和大家一起揭開測試自動化的神秘面紗以及給大家講一些構(gòu)建冒煙的概念。 冒煙測試的出處是，由于生活習慣等原因，人們會定期的做某個事情，就像人們會約定成俗的認為12:00是吃飯下班的時間。那個時候大家都會做飯，哈哈，自然會從煙囪冒煙。在軟件行業(yè)里面的約定是當產(chǎn)品到達某個階段之后，為了驗證產(chǎn)品的各個部分的銜接程度，為了驗證項目的進展程度，為了驗證產(chǎn)品的（已完成）功能的全面穩(wěn)定程度，由測試主導(dǎo)的一種測試方法，主要的操作就是，在產(chǎn)品開發(fā)計劃定制完成以后，依照開發(fā)計劃指定完整的編譯計劃，按照開發(fā)計劃和編譯計劃，各個單位按照要求完成自己的作業(yè)，然后在編譯點上驗證完成程度。 集成測試也是不可缺少的一個部分，很多單位為了趕進度，會將這個部分省略掉，就甩手給測試小組，如果沒有對應(yīng)的測試小組，就會是程序員進行簡單的使用后就交付市場，危險，這是個定時炸彈。因為他時刻有可能產(chǎn)生市場對企業(yè)影響的額度，以及企業(yè)本身的聲譽問題。 集成測試是在單元測試完成后進行的測試環(huán)節(jié)中的一個測試，主要是測試各個模塊和函數(shù)之間的相互銜接情況，互動情況，輸入輸出情況。所以集成測試也很重要。 那么集成測試一般采用什么方法呢？集成測試一般采用樁驅(qū)動的方法，因為在單元測試我們檢查的相對比較詳細，那么在集成測試的重點其實要保證邏輯上了。我簡單的介紹樁驅(qū)動的實現(xiàn)方法。樁模塊（函數(shù)）樁模塊（函數(shù)）在單元測試已經(jīng)作過詳細的測試關(guān)聯(lián)模塊或者函數(shù)1關(guān)聯(lián)模塊或者函數(shù)2關(guān)聯(lián)模塊或者函數(shù)3關(guān)聯(lián)模塊或者函數(shù)4關(guān)聯(lián)模塊或者函數(shù)6關(guān)聯(lián)模塊或者函數(shù)5請大家看上面的圖，這個一定是一個有意義的組合。是函數(shù)間形成一個簡單的邏輯關(guān)系。 從上面的圖上我們可以看到，如果中間的模塊或者函數(shù)是經(jīng)過我們進行過詳細的測試，基本上可以保證沒有什么錯誤，那么如果這個邏輯出去，導(dǎo)致出錯，一定是輸入的過程或者接收了輸出參數(shù)處理出錯了。使得我們問題很好的定位。 我們可以定義很多個樁，使得測試效率提高。我們把上面的內(nèi)容進行簡單的總結(jié)：集成測試就是測試各個組件之間的配合情況。所以集成測試是為系統(tǒng)測試提供了一些基本保證，但是不要完全依賴。采用的方法給大家介紹了，這樣可以采用測試或者程序編碼的形式實現(xiàn)測試。 系統(tǒng)測試 系統(tǒng)測試是測試過程中的一個轉(zhuǎn)折點，因為在現(xiàn)在國內(nèi)的企業(yè)中，不同的產(chǎn)品面對不同的用戶群體，所以有的企業(yè)經(jīng)過第三方產(chǎn)品的驗收測試，有的企業(yè)則沒有通過驗收，而是一些工具類或者通用類的產(chǎn)品，那么他的驗收測試是經(jīng)過廣大的用戶群來做的，也就是說凡是通用類產(chǎn)品的系統(tǒng)測試必須嚴謹測試以后，才可以投放到市場。但是對于對企業(yè)或者其他專業(yè)性單位定制的產(chǎn)品我們必須進行驗收測試。 系統(tǒng)測試工作是一個重復(fù)老動很多的工作，需要在工作種把握幾個重點，系統(tǒng)測試是保證系統(tǒng)能夠正常運轉(zhuǎn)，包括了功能，易用性，健壯性，壓力，邊界數(shù)值設(shè)定等各個方面的內(nèi)容。要想在這個階段的工作種找到樂趣，就要不停的摸索，找出能夠?qū)C器代替人的所有的東西，找工作的快感。 系統(tǒng)測試需要有廣泛的知識面，對測試工程師的要求需要了解和掌握很多方面的知識，需要了解問題可能出現(xiàn)的原因，已經(jīng)出現(xiàn)這個問題可能是由于什么原因造成的，以便我們能夠及時的補充測試案例，保證或者降低產(chǎn)推出的風險。 目前軟件測試行業(yè)發(fā)展還不成熟，大多數(shù)系統(tǒng)測試都在測試組做，而且測試組幾乎到系統(tǒng)測試測試階段才會接觸到產(chǎn)品。我們也把系統(tǒng)測試簡單的說明一下。 目前系統(tǒng)測試基本上采用黑盒測試方法，而且基本上局限在手公測試上面。被測試的軟件被測試的軟件從上面簡單的圖形可以看出來，我們不知道被測試軟件是怎么實現(xiàn)的，做了什么事情，我們只知道我們要它做什么，我們想得到什么，至于程序內(nèi)部怎么實現(xiàn)，我們并不關(guān)心，我們只是關(guān)心結(jié)果。這是一種純粹黑盒的測試。 這個階段是測試發(fā)現(xiàn)問題的主要階段，最少從目前市場上的產(chǎn)品情況來看是這樣的。在這個階段60%的問題會暴露出來，如果不進行單元測試和集成測試，這個階段的測試量和測試點很重要。 黑盒測試的核心是需要找到測試的重點在那里？測試的切入點在那里。系統(tǒng)測試重復(fù)的工作量比較大，而且如果是一個大型的項目，涉及的內(nèi)容相對比較多，而且如果組織不好，或者沒有找到重點，需要一遍遍的重復(fù)。所以需要自動化測試的需要合理的設(shè)計，使得我們的重復(fù)工作盡量減少，以提高工作效率。

驗收測試 驗收測試類似于客戶驗證產(chǎn)品的質(zhì)量，在軟件行業(yè)發(fā)展的過程中，各種承包項目類似于國外的外包項目將會不斷的出現(xiàn)，那么外包項目的質(zhì)量問題需要大家共同討論。 外包項目的操作流程是當承包方提出具體的需求，然后有承包商來按照需求來開發(fā)項目，包括單元測試，系統(tǒng)測試，集成測試等各個方面的測試，經(jīng)過被承包商測試后的產(chǎn)品提交給外包商的時候，需要進行驗收測試，驗收測試可以是外包商本身提供一套測試方案，然后對照具體的需求，進行產(chǎn)品驗證測試。也可以是雙方找一個共同的第三方，進行產(chǎn)品的驗證測試。 驗收測試的測試重點主要是產(chǎn)品是否按照需求開發(fā)的，而不從針對功能進行的測試。所以驗收測試基本上不需要多少專業(yè)水平，也可以是承包商找到使用該產(chǎn)品的用戶，來體驗該產(chǎn)品是否能夠滿足使用要求。這樣以來使得雙方可以有一個共同的平臺，避免商業(yè)矛盾的產(chǎn)生。 驗收測試的測試手段目前來說還是靠用戶體驗。對照合同的需求進行測試，是第三方按照雙方達成的共識來跟蹤和測試軟件是否能達成的需求。測試方法 黑盒測試 顧名思義，黑盒就是外面不知道盒子里面在作什么，怎么作，只知道我的輸入他需要有反應(yīng)，無論是正確的還是錯誤的，都需要有回饋信息。黑盒測試需要懂產(chǎn)品的使用方法，操作方法，把盡可能多的情況暴露出來，通過這種方法進行測試。 黑盒測試的隨機性比較大，在大部分案例執(zhí)行完成以后，大概能夠測試40%的功能，據(jù)美國一個官方的數(shù)據(jù)說，20%的問題是在開發(fā)過程中發(fā)現(xiàn)的，80%的問題是在系統(tǒng)測試和集成測試過程中發(fā)現(xiàn)的，其中80%的比例我們還是需要在細分，20%的是使用的問題，20%是程序的問題，5%邏輯問題,剩下的都是莫名其妙的問題，這樣的數(shù)據(jù)對測試的一個引導(dǎo)是：要想發(fā)現(xiàn)更多的問題，需要更多的思考，更多的組合。這樣無畏的增加了很多工作量，人們在疲憊的執(zhí)行著測試案例，渴望從中發(fā)現(xiàn)新的問題。 這樣的案例設(shè)計思想使得我們在開發(fā)一個大型的產(chǎn)品或者延續(xù)性產(chǎn)品的時候，整個測試案例的延續(xù)性很差，重用性也很差。所以我們在這里需要糾正一個概念，黑盒測試不簡單的使用，案例設(shè)計也不是無謂的組合。 那么如何設(shè)計好的測試案例呢？如何在開發(fā)過程中很好的結(jié)合2/8原則呢？當前包括以后，不可能出現(xiàn)一個積極完美的產(chǎn)品，一個錯誤也沒有，但是我們作為軟件工程師，肯定渴望自己參與開發(fā)的產(chǎn)品穩(wěn)定，易用，人們寄予無限的稱贊，這是一種奢望，那么我們把這種奢望修改一下，就是渴望我們參與的產(chǎn)品，能夠滿足當前大多數(shù)人的需求，穩(wěn)定是否更合理呢？ 白盒測試 白盒測試是一種高技能的測試，它是一種基于源代碼下的測試，這種測試要求對程序的要求很高，需要了解程序的構(gòu)架，具體需求，以及一些編寫程序的技巧，能夠檢查一些程序規(guī)范，指針，變量，數(shù)組越界等問題，使得問題在前期就暴露出來。 一般程序所容易犯的錯誤,沒有定義變量,無效引用,野指針,超過數(shù)組下標,內(nèi)存分配后沒有刪除等,無法調(diào)入循環(huán)體,函數(shù)本身沒有析構(gòu),導(dǎo)致循環(huán)實效或者死循環(huán).參數(shù)類型不匹配,調(diào)用系統(tǒng)的函數(shù)沒有考慮到系統(tǒng)的兼容性等. 白盒測試一般是以單元或者模塊為基礎(chǔ)的。目前的做法是把他歸結(jié)為開發(fā)的范疇，用轉(zhuǎn)人或者兼職的人去看代碼或者利用部分工具，例如Rational系列，Boundchecker等工具，他們可以幫助人為的發(fā)現(xiàn)變量沒有初始化，指針錯誤等。大大的減少了人力。 我下面講講BoundChecker最實用的東西。例如：我們發(fā)現(xiàn)一個現(xiàn)象：有個軟件再Win98下運行不起來，或者總是出現(xiàn)莫名其妙的錯誤，再Win2000下或者更高系統(tǒng)下運行正常。上面是一個現(xiàn)象，是我們再日常測試中經(jīng)常遇到的現(xiàn)象,我們分析可能導(dǎo)致出錯的原因：操作系統(tǒng)本身出錯的原因，導(dǎo)致軟件無法再此系統(tǒng)下運行，另外一個原因：軟件中用到了某些函數(shù)不支持此操作系統(tǒng)。還有一個原因，軟件運行的硬件環(huán)境再此系統(tǒng)下不能滿足 灰盒測試 灰盒測試是介于黑盒測試和白盒測試之間的一種測試.這個階段的測試重點是各個組件之間的邏輯,這個時期的測試重點是各個DLL文件的參數(shù)和邏輯是否正確,測試的重點是DLL本身.然后采用樁驅(qū)動,把各個DLL或者函數(shù)按照一定的邏輯串起來,達到在產(chǎn)品還沒有界面的情況下能看到一種既定情況下的結(jié)果輸出. 灰盒測試的要求相對白盒測試來說要求相對較低,對測試案例的要求也相對較低,只要求能夠檢測DLL處理輸入和輸出的能力,異常情況下的處理而已.測試方面 案例設(shè)計問題 分析：因為現(xiàn)在從總體上看，案例設(shè)計很細，但是重復(fù)和不必要的東西太多了，個人認為原因有三個：設(shè)計案例的不了解產(chǎn)品設(shè)計的框架（從程序概念上講）案例的設(shè)計沒有一個反饋，涵蓋情況不知開發(fā)產(chǎn)品質(zhì)量意識淡薄，測試壓力太大測試人員的素質(zhì)分析沒有，我們看不清問題出現(xiàn)在那里 進度問題測試的整體計劃里面沒有重復(fù)考慮風險，時間問題緊迫回歸測試無法保證結(jié)合開發(fā)模型，跟大家一起分析各個時期要作的時期所有工作準備就緒，開始執(zhí)行需求所有工作準備就緒，開始執(zhí)行需求概要設(shè)計詳細設(shè)計編碼通透的理解需求，補充開發(fā)此類產(chǎn)品測試所需要的知識和資料開始設(shè)計測試案例，研討測試方法開始實施方法，進行測試前的準備和試驗工作大家可以看到這個圖和一般的書本上描述的不太相同，這是我結(jié)合具體的業(yè)務(wù)來分析。需求需求閱讀需求怎么樣閱讀需求呢？ 我們在測試的時候，我們需要通篇的閱讀需求，那么怎么閱讀需求呢？需要了解什么內(nèi)容呢？實際的可操作的在那里呢？ 我詳細說我的認識，需求我們需要了解我們需要做什么類型的產(chǎn)品，這種產(chǎn)品需要什么樣的基礎(chǔ)知識，我們應(yīng)該補充學習那些基礎(chǔ)知識，市面上是否有同類型的或者相似的產(chǎn)品，他們曾經(jīng)出了那些問題等，把自己先充實了，這是看需求的主要目的和重要目的。 測試改進方案以上對存在的問題進行了分析，我們需要找到自己的弱項在那里，那么從現(xiàn)在看來，我們現(xiàn)在測試隊伍沒有建立，沒有形成相應(yīng)的體制。主要表現(xiàn)在一下幾個方面：測試工作需要回饋回顧一，測試案例執(zhí)行跟蹤和統(tǒng)計不明確。問題：如果測試案例不進行跟蹤，無法證明或者檢測我們案例設(shè)計的好壞，無法改進工作方法或者改善我們的思路，所以需要通過這里把自身問題看清楚，這樣有利于工作的開展。 在我們?nèi)粘５纳钪?，存在這一種現(xiàn)象，因為這種現(xiàn)象導(dǎo)致了測試一些列的發(fā)展。大家普遍認為，測試的含金量不高，導(dǎo)致了測試工作就是一些不愿意做開發(fā)或者沒有能力做開發(fā)的人來做，其二，他們對測試設(shè)計的測試案例從不認真的審查，認為就那么回事情。出現(xiàn)這種問題的愿意是由于開發(fā)還沒有清楚的認識到測試是一個服務(wù)部門，是為他們服務(wù)的，從私利的角度來講，我們拋開項目的關(guān)系，測試的主要工作是為了幫助開發(fā)將自己寫的代碼更實用一些，讓市場更認可一些，讓開發(fā)人員的成就感強一些。如果大家都從這個角度考慮問題，那就可能緩解或者解決上面的第二個問題。 關(guān)于測試含金量不高的說法，我不贊成這個說法，在目前國內(nèi)的大環(huán)境下，測試是這樣的，但是它在朝自己預(yù)想的發(fā)展。而開發(fā)的發(fā)展除了新的語言在發(fā)展以外，思想或者體系我們能增加或者能設(shè)想的空間已經(jīng)不多了，而對于測試是一個全新的行業(yè)，他發(fā)展首先需要支持，需要理解，我相信國內(nèi)測試在5~10以后，發(fā)展更加迅猛。因為就算是現(xiàn)在很小的軟件企業(yè)，已經(jīng)開始重視測試了?；仡櫠?，測試需要和開發(fā)有共同語言 當你開心或者興奮的發(fā)現(xiàn)問題以后，你能告訴我這個問題發(fā)生的原因嗎？當你發(fā)現(xiàn)問題以后，你能告訴我問題可能在那個環(huán)節(jié)發(fā)生的？你能告訴我類似于此類問題可能在那里還會發(fā)生。 所以，當你進行測試的時候，渴望測試人員完全了解被測試對象的架構(gòu)，然后針對此類軟件需要補充基礎(chǔ)知識，把自己補充起來，不至于開發(fā)人員給你講任何事情，你不理解，或者很難理解，那么如果真的是這樣，我對你個人設(shè)計的測試案例會打一個問號。 靠自己的基礎(chǔ)知識，詳細拜讀設(shè)計稿件，從設(shè)計稿件中如果能發(fā)現(xiàn)問題或者風險，你就有長足的進步了。回顧三，補充測試案例 我相信大家都有這個體會，在設(shè)計案例的過程中，大家想到這里，想到那里，總之想的很詳細，但是在真正做測試工作的時候，總是發(fā)現(xiàn)一些bug與我們設(shè)計的測試案例無關(guān)。 怎么會發(fā)生這樣的事情呢？因為我們設(shè)計案例是寄予自己的經(jīng)驗和對軟件的理解去設(shè)計案例，勢必會造成這樣的局面?，F(xiàn)在我推進一種方法。就是在設(shè)計測試案例的時候，渴望每個人把自己負責的模塊劃個流程圖出來，包括所有的出口和入口，包括信息流怎么流轉(zhuǎn)的，如果把這張圖形能夠完全的劃出來，說明你的理解要深一步，那么設(shè)計的案例含金量會高。測試工作需要總結(jié)測試的總結(jié)機制沒有測試案例的執(zhí)行情況測試案例發(fā)現(xiàn)問題情況測試案例的冗余情況測試周期內(nèi)的曲線項目進展情況需要交流平臺和形式信息交流平臺和積累資源共享信息共享提高自己在開發(fā)中的信心，不要總是喊狼來了人和人之間需要溝通和認同，團體也一樣測試人員交流什么呢？ 在一個組織中，應(yīng)該讓所有的人熟悉每個模塊的設(shè)計思路和測試思想，讓每個設(shè)計的人告訴大家，宣講出來，這樣大家在看這塊的時候，就知道那里容易出問題，出了那些問題。如果進行測試是最有效的，如果設(shè)計案例能抓住問題的核心。在設(shè)計階段，如果把設(shè)計的案例給開發(fā)人員看看，能規(guī)避一些設(shè)計上的缺陷。 在應(yīng)該團體中大家都應(yīng)該有共享的概念，我個人推薦的學習方法，是偷，我別人學了很多年的思想精華部分，在很短的時間內(nèi)接受并吸收，這樣會提高整個團隊的素質(zhì)。如果每個人都在共享，那么每個人都在進步，所以需要交流，包括思想，包括方法等。采用的方法讓別人給服務(wù)說話，清楚認識自己讓開發(fā)人員說話，讓對應(yīng)開發(fā)人員給我們的測試案例提出相應(yīng)的意見，保證測試案例的覆蓋面，以把握重點。在整個開發(fā)過程中，由需求，開發(fā)，測試完整的團隊，準確的說還有市場部分，我們都把它歸結(jié)為需求的搜索和定義部分。那么在整個產(chǎn)品研發(fā)的過程中，各個部分需要完整的配合，否則整個產(chǎn)品都不能按時上市。作為為開發(fā)和需求服務(wù)的測試部分，應(yīng)該擺正自己的位置，我們是一個團隊中的一部分，是不可以缺少的一部分。人貴有自知，也難有自知。只有在認識自己的基礎(chǔ)上才能選擇好自己的生活道路。首先要認清自己的能力。人的能力可以有天壤之別，但只要不辜負自己這塊材料，也就可以問心無愧了。認識自己尤忌自大，這會使你為自己訂立高不可攀的奮斗目標，到頭來高不成、低不就。其次要認識自己的本性。心理學家把人分成六個類型：經(jīng)濟型、理論型、社會型、審美型、宗教型和權(quán)力型。要選擇一個適合自己本性的生活目標。看清楚了自己，就可以很好的改善，也能把自己的事情做好，同時呢，才能更好的服務(wù)。自己回頭看讓執(zhí)行測試案例的人員反饋給我們數(shù)據(jù)，說明案例的冗余情況，這樣會慢慢提高自己的設(shè)計水平。因為人們習慣于談成績，問題在成績中可以淡化，我不同意此觀點。其實在現(xiàn)實生活中，大家都經(jīng)歷了很多事情，都學會了總結(jié)，可是同樣的錯誤在現(xiàn)實中會多次出現(xiàn)，為什么呢？是因為回頭了多次，沒有總結(jié)，總結(jié)了沒有執(zhí)行，執(zhí)行了沒有改變方式，改變方式了但是沒有認真考慮，還是錯的。把自己犯的錯誤列舉出來，然后找出出現(xiàn)問題的真正原因，才是自己最大的進步。如果淡化錯誤，將來可能就會將成績磨滅掉，所以積累，回頭是工作中需要重視的問題。還有一種論點，說公司多么多么重視開發(fā)，不重視測試，我對這種論調(diào)積極反感，這只是個人感覺。為什么這么說呢？對公司來說，要靠項目和產(chǎn)品維持生存，對嗎？從這個方面來說開發(fā)重要，產(chǎn)品質(zhì)量不重要嗎？這個問題很多人問我，我回答說，重要，非常重要，那為什么測試的價值體現(xiàn)不出來呢？主要是兩個方面的原因，一個是公司引導(dǎo)不正確，各個部分的同事為這個項目負責，而不是開發(fā)為這個項目負責，其二呢，主要是因為我們是維護，而不是創(chuàng)造，如果你告訴老板，這個產(chǎn)品我們改變測試策略，能夠提高工作效率，這個產(chǎn)品可以提前2個月發(fā)布，而且我保證質(zhì)量。我相信你的價值也即體現(xiàn)出來了，如果不可以，說明還是沒有找到合適的方法。了解同類產(chǎn)品讓市場人員反饋同類產(chǎn)品的問題以及市場對我們產(chǎn)品的需求。測試過程是反映當前產(chǎn)品的質(zhì)量，為什么要研究競爭對手的產(chǎn)品呢？首先，測試中包含易用性測試，測試什么內(nèi)容呢？就是測試怎么好用，客戶是怎么用的，我們怎么設(shè)計更貼近用戶，那么不研究競爭對手，我們怎么可能占領(lǐng)上風。其次，了解競爭對手的產(chǎn)品，有利于測試工作捕捉重點，使得工作開展有利有節(jié)。可謂知己知彼，百戰(zhàn)不殆，所以在現(xiàn)在的市場競爭中，了解同類產(chǎn)品才可能發(fā)現(xiàn)對方的缺點，給以打擊，發(fā)現(xiàn)對方的優(yōu)點，快速學習，閉門造車必定失敗。提高自身素質(zhì)從程序的概念理解產(chǎn)品，這樣測試案例可以設(shè)計的比較有針對性。常言說得好，“識重于才”，而見識卻往往是生活閱歷造就的。對于一個初出茅廬的人，智者的指點是至關(guān)重要有時甚至是決定性的?；叵胛沂陙淼慕?jīng)歷，很多失敗其實是沒有人指點而造成的。要尋找一個精神上的導(dǎo)師，他可以是你的父母，也可以是其他師長。他閱歷豐富而又不拘泥于自己的老經(jīng)驗；他能在緊要關(guān)頭給予你原則上的指導(dǎo)和精神上的支持。有時候僅僅是他失敗的經(jīng)驗就會使你受益匪淺。如何提高程序能力耳濡目染讓開發(fā)或者設(shè)計人員在討論開發(fā)方案的時候參與旁聽，耳濡目染。其實這只是一種輔助的手段。電視劇《霍元甲》播出以后，得到大家的欣賞。原因是因為他本人身體虛弱，所以父親從小不讓練武功，而生長在那樣的環(huán)境中，他天天可以看到兄弟們在練功，招式已經(jīng)記憶在心理，但是苦在沒有練功的機會，他利用體力勞動的過程中，改變勞動方式，趁機練功，后來發(fā)展到獨創(chuàng)“迷綜拳”。程序設(shè)計和開發(fā)是一個硬功夫，也是一個長遠的事情，它是一個積累的過程，不能一蹴而就，需要苦心練，多些理解，多些思考。面對程序開發(fā)，不要有太多的壓力，因為程序開發(fā)就跟你學說話一樣，因為語言本身有很多通性，高級語言和低級語言本質(zhì)上差別不大，所以扎實的從基礎(chǔ)的東西學起，這樣才能完全的積累下來。計算機發(fā)展速度很快，各種概念，各種語言發(fā)展都很快，掌握實質(zhì)，不斷學習，才能把握。所以還是需要多看，多想，多練。自己練內(nèi)功從自身做起，了解程序架構(gòu)和開發(fā)模式，努力提高理解和產(chǎn)品的單元測試或者組件測試能力，這樣以來可以了解程序的很多算法，使得在產(chǎn)品的開發(fā)過程中就能把問題發(fā)現(xiàn)并且能夠得到及時的解決。其次能夠提高大家參與到項目的榮譽感，因為在測試本身是一個服務(wù)性的行業(yè)，那么服務(wù)行業(yè)的特點是不停的改變思路，改變服務(wù)模式，提高服務(wù)質(zhì)量，當服務(wù)做好了，那么在整個研發(fā)中就可以找到自己也是其中一個分子的感覺。其三，練好內(nèi)功，為自己將來提高工作效率，進行一些自動測試以及從程序架構(gòu)的概念上設(shè)計測試案例提供了技術(shù)保障。以上是自己練好內(nèi)功的用途。在過去社會中，有很多擂臺賽，目的是切磋技藝，弘揚中華武術(shù)，各個門派直接交流和學習的過程，為了在擂臺賽中取的很好的成績，我們需要努力練功，其次是多學本門派和其他門派的武功，或者自創(chuàng)武功，在擂臺上能夠發(fā)揮的淋漓盡致，因為武功的最高境界就是沒有招式，要達到這個境界，需要內(nèi)功深厚，避免走火入魔，需要毅力，需要創(chuàng)新。理論就是理論，無論在那里看到的理論都是一定的基礎(chǔ)的，因為所有的理論基礎(chǔ)需要一個證明此理論的平臺或者條件，所有一定要看，想，用?？磩e人是怎么用的，在什么情況下用的，用的目的是解決什么問題，在什么樣的環(huán)境下能夠做出來，需要什么樣的支撐；想自己現(xiàn)在目前是否有這個環(huán)境，就目前的環(huán)境能夠做什么，如果要搭建對方的環(huán)境需要多長時間，這個做法中存在什么不托的地方，有什么需要改進的地方；在自己工作的環(huán)節(jié)中找找看，看自己是否適合用這個東西，如果適合，怎么用，用到什么程度，如果非常認可別人的做法，需要衡量需要多少資源和時間，努力找自己的結(jié)合點。千萬不要再我們看到一個理論或者方法的時候就去推動它，或者原理實踐過一個什么思想就想在新的環(huán)境下實踐他，都是不可取的。好的事情或者好的做事方式他需要一些條件支撐，一旦硬套，就可能出現(xiàn)問題。實踐中檢驗嘗試做一些灰盒測試部分（目前暫時是想法，但是還不完善）?；液袦y試是界與白盒測試和黑盒測試之間的一種臨街狀態(tài)。測試發(fā)展測試在國內(nèi)還是處于摸索階段，在過去的發(fā)展階段，大家只是初步針對不同的軟件產(chǎn)生了不同的測試方式，但在操作方法，操作流程等方面還需要繼續(xù)摸索。對潛入式軟件來說，行業(yè)內(nèi)始終認為潛入式軟件是最難進行測試的，因為他需要很廣的知識面，需要對各個點的設(shè)計原理進行分析和測試。在目前國內(nèi)開發(fā)眼中的測試還沒有形成概念，我們需要不斷的改變形象，加深他們對測試的印象，以便我們獲取更多的幫助和協(xié)助。測試未來發(fā)展需要兩條腿走路，這樣能夠在各個環(huán)節(jié)保證產(chǎn)品的質(zhì)量。第一步，系統(tǒng)測試繼續(xù)練內(nèi)功，將案例設(shè)計的能力提高第二步，需要進行灰盒測試，對產(chǎn)品進行代碼級的測試第三步，需要進行部分白盒測試或者由開發(fā)人員進行執(zhí)行要達到一定的認同和發(fā)展,測試人員需要努力學習,打下扎實基礎(chǔ),這樣才能一步步的成功.如何提高測試 提高測試需要從幾個方面著手，其實只是自己的一些感覺，不一定就需要按部就班，需要找自己適合的點。 制定完備的測試計劃 清楚的認識測試計劃，測試計劃是一個文檔，能夠保證整個研發(fā)過程中順利執(zhí)行的一個指導(dǎo)性文檔，它描述了幾個方面的問題。描述了項目的目的描述了項目的開發(fā)周期描述了在測試中遇到的技術(shù)描述了測試案例的設(shè)計周期描述測試案例的執(zhí)行周期描述了測試過程中用到的工具或者技術(shù)描述了測試過程中用到的資源情況描述了測試過程中可能遇到的風險以及規(guī)避方法提高案例設(shè)計水平 明確了解現(xiàn)在目前流行切實用的幾種案例設(shè)計的方法，因為在不同的產(chǎn)品不同的要求有不同的設(shè)計手段，我們需要不斷的學習和總結(jié)，在為了測試領(lǐng)域中，許多新鮮的詞語都會出現(xiàn)。 這種方法類似與工業(yè)領(lǐng)域的隨即抽取統(tǒng)計分析法，但是工業(yè)性質(zhì)牽扯到損壞或者人為原因，統(tǒng)計出來存在這偏差，但是應(yīng)用與軟件方面，雖然存在著偏差，但是不可能象硬件那么偏差很高。 等效法 明確測試的目標，一般適合用到的范圍是，制定被測試的對象是在滿足某個條件的區(qū)間內(nèi)的所有的所有數(shù)據(jù)。案例設(shè)計方法：從其中區(qū)間數(shù)據(jù)段中選擇任意一個或者兩個數(shù)據(jù)，只要這個數(shù)據(jù)滿足了，那么其他的數(shù)據(jù)就是滿足的。我現(xiàn)在舉一些例子，來說明等效法在測試過程中如何應(yīng)用的。范例1：在登陸某系統(tǒng)需要驗證用戶名，要求是長度是最小是6位，最長是14位，名字中可以包含數(shù)字，但是不能以數(shù)字開頭，可以包含各種符號，不能包含中文。1、隨意字母組合成一個12位的姓名，測試是否可以通過驗證。2.、隨意生成一個長度12位的姓名，測試是否可以通過驗證3、測試以任意一個數(shù)字打頭12位的姓名，測試是否可以通過驗證4、測試姓名長度位12位且包含中文情況，測試是否可以通過驗證5、測試長度不滿足條件情況下，是否通過驗證6、如果長度不滿足，是以數(shù)字開頭的，提示信息驗證7、如果長度不滿足，姓名中包含中文的，提示信息驗證 ………….(注：)這個可能比較簡單，但是說明一個問題：為什么隨意生成一個12位姓名的,其實你選擇8位姓名長度或者10位姓名長度是一樣的，所以這種情況下考慮采用等效方法比較合適。范例2:有這么一個需求，要求選擇1~12之間進行調(diào)整，手機的背光就會隨著數(shù)值的變化而變化?？傮w的是數(shù)值越大越暗。以上需求是大家經(jīng)常可以看到的。測試案例設(shè)計：清晰記憶1的情況，然后隨意調(diào)整一個數(shù)值，因為要求是變化了，至于變化成什么樣子，變暗到什么程度才正確，沒有明確的指標數(shù)值，所以只需要記住臨街點1的情況，然后隨意調(diào)整一個數(shù)據(jù)，然后和當前調(diào)整后的數(shù)據(jù)進行比較。（注：）沒有明確的說明，只是含糊的結(jié)果，但是總體的結(jié)果是在變化，那么這個時候比較適合使用等效法。因果分析法 需要有一定的程序基礎(chǔ)，了解程序的架構(gòu)，就是當問題發(fā)生以后，能夠有效的補充相關(guān)的案例或者篩選相關(guān)的案例。因果分析的核心是從自己的理解去分析問題所在的真正原因。 范例1：刪除磁盤上某個文件失敗，分析原因：如果是管理員權(quán)限，那么可以隨意刪除，無論這個文件的屬性是只讀的還是存檔的，那么如果不能刪除磁盤文件，除非是壞道上的文件。分析完成以后，使得測試案例設(shè)計有針對性，而不是盲目的將所有的文件格式都去嘗試一次。 范例2：假設(shè)我們用Excel作一個計算，結(jié)果和我們用計算器計算的結(jié)果不同。 分析：Excel的計算函數(shù)單獨運算沒有錯誤，然后插入一行，結(jié)果錯誤了，說明插入行導(dǎo)致計算錯誤，那么插入一行怎么會引起函數(shù)計算錯誤呢？原因是由于插入行后，導(dǎo)致傳給計算函數(shù)的區(qū)域沒有更新，所以造成計算結(jié)果錯誤，那么這個Bug就很明確了。 范例3:假設(shè)我們平常在做講座的時候發(fā)現(xiàn)在某臺機器上就會死機。這是一種現(xiàn)象。 分析：為什么在這臺機器上死，在其他機器上不死。原因有兩個，第一個先找系統(tǒng)原因，是否是我們的產(chǎn)品在當前這個系統(tǒng)下有Bug,經(jīng)過驗證沒有，那問題出在那里？ 其實演示產(chǎn)品需要的是硬件的支持，那就是顯卡，如果顯卡內(nèi)存不夠大，可能導(dǎo)致某些演示文件死。（注）因果分析需要有廣泛的知識面，使得我們在分析的時候能夠拓寬面積，模糊的定位問題。范例4:用戶給我發(fā)送一個文件，打印的時候發(fā)現(xiàn)是亂碼。后來逼迫無奈，就讓用戶將這個文件傳真給我。這是現(xiàn)象。分析：為什么打印出現(xiàn)亂碼？問題基本定位，系統(tǒng)字庫不夠，系統(tǒng)下打印驅(qū)動問題，打印虛擬內(nèi)存問題，操作系統(tǒng)問題，軟件本身問題？最后問題經(jīng)過驗證，最終歸結(jié)為在此操作系統(tǒng)下，打印驅(qū)動程序有問題，使得文件不能正常打印。（注：問題需要先框定范圍，不要亂了套路。） 邏輯分析法 在邏輯分析方面，也需要有一定的程序理解能力。從程序邏輯和日常常識去判斷問題。邏輯分析法其實就一堆假設(shè)的羅列，推論出系列結(jié)果的假設(shè)，然后將假設(shè)反推翻，問題就可以暴露出來。無論那種方法都是通過表現(xiàn)去分析問題的實質(zhì)的。范例1:我們在做MP3播放器快進和快退測試中，要考慮的同步問題，就是我們液晶顯示屏上出現(xiàn)的歌詞進度，時間進度和我們耳朵聽到的進度不同。我們分析一下，為什么出現(xiàn)不同步現(xiàn)象，為什么其他的能同步，就某一個或者某幾個不能同步。 首先我們了解同步的算法：快進和快退是按照當前歌曲的數(shù)據(jù)流來計算應(yīng)該到那里，它是以當前歌曲的數(shù)據(jù)流為系數(shù)，然后進行的一些調(diào)整，那么出現(xiàn)不同步的原因是由于系數(shù)不同造成的，所以考慮到同步問題，我們需要找不同格式不同數(shù)據(jù)流的歌曲，這樣問題容易暴露，容易清楚的定位問題的真正原因。 范例2 我們來分析網(wǎng)絡(luò)游戲中的交易系統(tǒng)，就是在游戲兩個人進行物品和金錢的交易。 怎么設(shè)計這里的案例呢？我們先梳理一下交易的邏輯關(guān)系圖。A玩家A玩家B玩家請求交易 邊界數(shù)值分析法 在測試案例執(zhí)行的過程中，所有調(diào)節(jié)的數(shù)據(jù)都需要考慮到邊界數(shù)值的測試方法，這里我就不在贅述。但是需要注意，邊界數(shù)值的測試不是枚舉，只是抽樣的方法。逃避測試的誤區(qū) 市場需求引導(dǎo)產(chǎn)品質(zhì)量測試是為了驗證需求，保證產(chǎn)品質(zhì)量，無論如何你都不可能做成100%的測試，不可能做成NoErrors。所以我們針對不同的產(chǎn)品，不同的市場定位，確定不同的測試方針。 因為企業(yè)面對的是客戶，面對是企業(yè)長遠利益，那么我們不可能倉促的推出產(chǎn)品為了迎合市場，而是需要研究，調(diào)查市場的真正需求，把用戶所關(guān)心的功能提供給用戶，使得其更加完善，更加穩(wěn)定。 我們從企業(yè)來分析，首先任何一家企業(yè)要生存，必須需要市場空間的支撐，目的是為了盈利，我覺得沒有必要說的那么冠冕堂皇，這是事實，但是在把握產(chǎn)品質(zhì)量和市場需求的時候，我相信很多企業(yè)會選擇市場需求的，因為這是機會，是把握企業(yè)生存的機會，特別是對于發(fā)展性企業(yè)來說。（企業(yè)原因） 我們從開發(fā)來分析，因為在開發(fā)的過程中，由于軟件行業(yè)的高流動行和知識更新快的特點，風險加大，使得開發(fā)周期很難把握，這樣使得產(chǎn)品測試時間很難控制。因為開發(fā)的進度包括市場提出需求的技術(shù)風險都很難把握。（開發(fā)的原因） 我們從測試來分析，測試在很多企業(yè)中是沒有的，那么開發(fā)人員自己來做，如果有測試人員，那測試也是隨意性非常強，造成產(chǎn)品上市后預(yù)留很多無法預(yù)估的風險，為企業(yè)的形象蒙上了面紗（測試模式）合理利用2/8原則測試是列舉，不是枚舉，所以設(shè)計案例的時候全面是不可能的，那么需要靈活的運用2/8原則，使得測試重點清楚，容易控制。 基于產(chǎn)品在開發(fā)過程中的種種風險，我們在有限的人力和資源的情況下，合理的利用2/8原則，如何把握2/8原則？首先需要了解產(chǎn)品的特點，讓所有參與測試的人員能夠了解產(chǎn)品的特點，這樣使得工作具有針對性，至于產(chǎn)品的噱頭，我們可以進行充足的測試，因為只是我們的產(chǎn)品立足市場的點。 在時間有限的情況下，把常用的功能測試保證了，不要攤?cè)?，攤寬，這樣到最后都無法總計產(chǎn)品的質(zhì)量概念了。 以上這么說，是一種概況，在實際的工作中大家需要總結(jié)，把進度，時間，質(zhì)量等進行權(quán)衡，以保證產(chǎn)品的順利發(fā)布?；貧w測試的概念測試次數(shù)不是輪回，測試的不同次數(shù)不是輪回，而是為了驗證問題，那么什么時候適合安排一輪測試，需要定義標準，否則耗時耗力?；貧w測試是不可缺少的環(huán)節(jié)，在一個產(chǎn)品測試完成后，直接到用戶手頭的時候，需要千萬小心，需要進行一次徹底的回歸測試，這個時候包括所有的功能以及所有已經(jīng)修正的問題。避免版本出現(xiàn)問題。 其實在不同的資料中對回歸測試有不同的解釋，我就不在這里贅述。我想表明我的觀點是，依照不同的開發(fā)模式，回歸測試所在的時間段也不相同；當前的開發(fā)模式有瀑布型和迭代型，例如，在瀑布型的開發(fā)模式中，所有的測試活動（手工測試，系統(tǒng)測試，部分集成測試）都在最后進行的，而切所理解的回顧測試是為了保證在新的版本中測試修改后的問題，其實這個測試只是保證了其中一部分工作測試的概念測試不是為了驗證問題，而是為了發(fā)現(xiàn)以前設(shè)計中沒有發(fā)現(xiàn)的問題。自動測試只是測試的一種手段，目的是為了提高工作效率測試工具只是利用，不能依靠，因為工具本身沒有智能的判斷是否會有問題發(fā)生，自動測試不是利于測試工具，而是需要編寫或者利于測試平臺，編寫適合自己的測試工作進展。 如何調(diào)整團隊的作戰(zhàn)能力建議性質(zhì)：因為曾經(jīng)帶過四個團隊，而且這個經(jīng)驗最少在我身上是成功的。形式分析測試團隊，測試團隊在現(xiàn)在國內(nèi)來說在慢慢的得到重視，之所以原來不重視是因為整個行業(yè)處于摸索期，不知道采用什么方法，什么技術(shù)，作什么事情等的情況下，使得測試員好像是一些沒有能力人的集合（宣講，不聽的宣講）。目標計劃引導(dǎo)測試技術(shù)和未來發(fā)展規(guī)劃，因為任何人的發(fā)展需要目標，那么一個人的發(fā)展目標假如它和這個行業(yè)相關(guān)，那么它會付出一切，努力的工作，所以需要大家認可一個目標，并且讓大家認為是可行的，然后我們分步驟一步步的去實現(xiàn)它。讓他或者大家能夠看到自己所喜歡或者從事行業(yè)的發(fā)展方向。過過老師癮因為在做任何事情的時候，每個人都有自己的想法或者步驟，講出來就好，這就需要開始的時候我們以任務(wù)的形式下達，我相信，到后來大家愿意自己站出來講了，我告訴你原因。因為人本身有羞怯感，怕幾個方面，怕講錯，怕人多，怕提問。那么如果把這幾個問題都解決了，是否羞怯感就沒有了呢？如何解決個人怕的問題：引導(dǎo)，因為一個人如果不能把自己的想法和思路講出來，那么不可能把事情做的很好，其二，就是如果你把你的想法說出來，別人可能會指出你思路中走彎路的地方，對個人來說可以跳高工作效率，使得思路更加完善。其三，如果大家都把自己的思路說出來了，你不就節(jié)省的很多學習時間嗎，另外你想過沒有，當別人形成這個想法的時候，需要一定的積累，那是他的心血，這不就輕輕松松讓你學到了嗎？如果固步自封，那么你的思路有可能是錯的，有可能是對的，但是你的知識面就只能局限在你所考慮的范圍內(nèi)，對個人發(fā)展不利。定學習目標在軟件行業(yè)里面，要有發(fā)展，就需要不停的學習，不停的進步，不停的總結(jié)，才可能有長遠發(fā)展，所以需要定義在這個行業(yè)階段行的學習目標，讓人感覺這個行業(yè)現(xiàn)有的水平只是維持，要發(fā)展，需要學習。 在工作中學習的方法，除了自學以外，就是“偷”了，所謂偷，就是要學會問問題，把你想知道的東西刨根問底，當別人回答你問題的時候，他一定是用他知道的東西的精華來總結(jié)，那么這樣你在很短的時間內(nèi)，把他總結(jié)的精華全給你了。 在學習的過程中，需要學會總結(jié)，把能總結(jié)的都整理出來，第一是經(jīng)驗的積累，第二呢能夠做到分門別類，逐類旁通，使得相同或者類似的錯誤不要重范。興趣和愛好 一個人工作有兩種情況，第一中是真正的工作，完成就算完成了，自己也在不斷的學習，不斷的總結(jié)，但是缺乏激情。第二中是把工作當成自己的事業(yè)，渴望自己在這個方面成為權(quán)威或者說業(yè)界能夠說話的人，也是在不斷學習，不斷的總結(jié)，培養(yǎng)職業(yè)性，培養(yǎng)和引導(dǎo)大家的興趣和愛好，因為只有你了解了興趣和愛好，才能更融洽的調(diào)和整個工作組的氣氛，這對測試行業(yè)的領(lǐng)導(dǎo)者來說是個挑戰(zhàn)。歪曲理論推理 “測試人員是由于技術(shù)不過硬，才去做測試的。”針對這個觀點，我說說自己的看法。好，我給測試說幾句，測試水平不過硬成立，假設(shè)成立，那么這是相對的，相對開發(fā)來說的，而且這種論調(diào)都是從開發(fā)那里擴散或傳播出來的，測試在后期發(fā)現(xiàn)問題后，開發(fā)也許心理很痛苦，但是他不愿意暴露在臉上，使得有些問題越發(fā)變的嚴重，不得不修改。那么在產(chǎn)品后期暴露那么多問題，說明了什么呢？這么低水平的測試都能考慮到你程序設(shè)計的種種漏洞，那么說明了程序水平開發(fā)有待提高。在IT現(xiàn)在的行業(yè)中，開發(fā)的流程，模式，以及各種約定成俗的東西越來越多，而且相對穩(wěn)定，而測試是一個全新的行業(yè)，它需要大家摸索支持，需要大家共同建立起來。 其實，在原來的開發(fā)模式中，商家為了適應(yīng)市場，為了保證利潤的最大化，為了使得產(chǎn)品能夠順利的適應(yīng)市場，那么采用各種方法，使得產(chǎn)品質(zhì)量的定位淡薄，而現(xiàn)在隨著人們的要求越來越高，商家的意識越來越強，各個公司或者組織渴望成立測試部門，保證產(chǎn)品的質(zhì)量，使得測試這個行業(yè)在最近幾年才發(fā)展起來。正確理解自動測試 首先，自動化測試是測試行業(yè)是技術(shù)，但是不是說用了自動化測試了就能發(fā)現(xiàn)更多的問題,它只是提高了工作效率而已. 自動化的概念是人們在工業(yè)生產(chǎn)的過程中，為了提高工作效率，不斷的對操作方法或者技術(shù)或者工具進行改進，減少人們普遍的手工勞動，節(jié)省時間和成本。 而軟件行業(yè)的自動化測試同樣也有節(jié)約成本，提高效率的需求。所以所有的改進需要考慮到成本的問題。 自動化測試的大前提:產(chǎn)品本身特征具有長期可維護性產(chǎn)品本身非緊迫的大項目產(chǎn)品結(jié)構(gòu)相對復(fù)雜資源投入相對充裕 那么作為成本，需要從幾個方面去考慮，第一實現(xiàn)成本，第二，人力成本，第三，新技術(shù)的風險，第四，節(jié)省的成本，第五，被自動化的功能是否需要大量的手工勞動。 所以我們理解自動化一定從成本的概念上考慮，最少從自動化測試概念的起步應(yīng)該從這個方面考慮。那么自動化測試的重點就在于他節(jié)省人力，節(jié)省時間，得到的數(shù)據(jù)更精確些，而且操作的可重復(fù)性和Bug的可重現(xiàn)性更強一些。 下面我就對自動化測試做一個詳細的解釋，跟大家分享。1.簡介本文關(guān)注于一個實施自動化測試框架的組織的主要方面和影響。本文的意圖是提供一些能夠成功的實施自動化測試的指導(dǎo)方針。2.測試自動化的神話有很多關(guān)于自動化測試的神話。其中的一些是真實的，而其他的一些是不正確的設(shè)想，這些不正確的設(shè)想會嚴重的威脅到實施自動化測試的成功。2.1.我們在時間上是緊迫的－項目已經(jīng)落后了－讓我們使用自動化測試吧！這種情況將不能成為現(xiàn)實。實際上，正確的思想應(yīng)該是－我們時間急迫－我們決不應(yīng)該使用自動化測試。如果項目已經(jīng)陷入到了麻煩之中，不建議實施自動化的功能測試。項目很可能因為需要大量的測試框架的準備和實施會被托跨。我餓建議將重點放在以下的事情上：優(yōu)化測試的過程。調(diào)查并建議在目前工作基礎(chǔ)上的測試方法和過程。建議借鑒RUP的相關(guān)思想和過程。引進或者使單元/組件測試正式化。這是我們能夠快速獲得受益的很好的方法。如果正式的組件測試被使用，我建議可以使用RationalPurifyPlus進行單元或者組件測試。根據(jù)我的經(jīng)驗盡早的使用RationalPurifyPlus是非常值得的。在一個引入和RationalPurifyPlus的項目中，通常會在組件的級別得到百分之三十的性能提升。僅僅在項目團隊能夠?qū)ο铝袉栴}的回答是"Yes"時：項目能夠被適當?shù)耐蒲?。存在能夠通過實施自動化測試被達到的精確的目標。項目具備建立適當?shù)臏y試框架的必要條件。那么，你可以在一個時間緊迫的項目中適當?shù)膶嵤y試自動化。但是根據(jù)經(jīng)驗這種情況是很難發(fā)生的。總而言之，我只能說"對不起，銀彈根本不存在"。2.2.測試自動化就是捕獲和回放在過去的日子中，自動化的測試工具只是被看作是一種捕獲和回放的工具。當前這個神話仍然在很多測試人員的思想中。而事實上自動化測試已經(jīng)遠不止捕獲和回放這么簡單了。按照成熟度自動化的測試可以被劃分為5個級別。2.2.1.級別1：捕獲和回放這是使用自動化測試的最低的級別，同時這并不是自動化測試最有用的使用方式。優(yōu)點：自動化的測試腳本能夠被自動的生成，而不需要有任何的編程知識。缺點：你會擁有大量的測試腳本，同時當需求胡子和應(yīng)用發(fā)生變化時相應(yīng)的測試腳本也必須被重新錄制。用法：當測試的系統(tǒng)不會發(fā)生變化時－小規(guī)模的自動化。2.2.2.級別2：捕獲、編輯和回放在這個級別中，你使用自動化的測試工具來捕獲你想要測試的功能。將測試腳本中的任何寫死的測試數(shù)據(jù)，比如名字、帳號等等，從測試腳本的代碼中完全刪除，并將他們轉(zhuǎn)換成為變量。優(yōu)點：測試腳本開始變得更加的完善和靈活，并且可以大大的減少腳本的數(shù)量和維護的

工作。缺點：需要一定的編知識。頻繁的變化可能會引起"意大利面條式的代碼"，并且變更和維護幾乎是不可能的。用法：當進行回歸測試時，被測試的應(yīng)用有很小的變化，比如僅僅是針對計算的代碼變

化，但是沒有關(guān)于GUI界面的變化。你能夠使用這種技術(shù)通過快速的編制一些測試腳本以檢驗?zāi)愕南敕▉硖剿髂愕念A(yù)定的測試設(shè)計。當我在沒有任何象需求或者設(shè)計模型這樣的文檔的情況下第一次操作一個產(chǎn)品時和我需要獲得一系列內(nèi)部構(gòu)建版本的穩(wěn)定性的第一印象時，我使用過這種技術(shù)。通常如果適當?shù)能浖渲霉芾恚⊿CM）與良好的內(nèi)建設(shè)計相結(jié)合時，使用級別2的技術(shù)已經(jīng)足夠了。2.2.3.級別3：編程和回放這個級別是面對多個構(gòu)建版本的有效使用測試自動化的第一個級別。你需要在實際的投資開始顯現(xiàn)之前確保團隊和客戶對項目的安全感。如果沒有對測試自動化工具的適當?shù)呐嘤枩y試人員將不具備到達這個級別的能力。在自動化測試工具中的所有測試功能都必須被很好的理解，并且要掌握測試腳本語言的知識。好處：你確定了測試腳本的設(shè)計。適當?shù)脑O(shè)計是必要的。編碼的習慣必須是適當?shù)?。使用與開發(fā)中相同的編碼習慣是非常好的。這將開始搭建起測試和開發(fā)之間的橋梁。在項目的早期就可以開始自動化的測試。你能夠在項目的早期就開始進行測試腳本的設(shè)計。與開發(fā)人員交并調(diào)查他們認為可能會存在問題的區(qū)域。確保了開發(fā)人員關(guān)注在獲得能夠被測試的方案上。缺點：要求測試人員具有很好的軟件技能，包括設(shè)計、開發(fā)等。用法：大規(guī)模的測試套件被開發(fā)、執(zhí)行和維護的專業(yè)自動化測試。級別3使你能夠使用自動化測試并構(gòu)建不同的回歸測試（重用已有的自動化測試

用例）。根據(jù)我的經(jīng)驗在看到更多切實的回報之前，為了達到這個級別，有大量的工作和影響項目的活動必須被做。因此快速的建立和證明自動化測試的價值是至關(guān)重要的。找到乏味的測試（例如，邊緣測試和特定的功能測試用例是首先進行自動化測試的良好候選者）。首先創(chuàng)建少量的能夠測試一些基本功能（比如，登陸和創(chuàng)建用戶等）的測自動化測試用例。2.2.4.級別4：數(shù)據(jù)驅(qū)動的測試對于自動化測試來說這是一個專業(yè)的測試級別。你現(xiàn)在要利用測試工具提供的所有的測試功能。你擁有一個強大的測試框架，這個測試框架是基于能夠使你根據(jù)被測試系統(tǒng)的變化快速創(chuàng)建一個測試腳本的測試功能庫的。維護的成本相對是比較低的。你在你的測試中會使用到大量真實的數(shù)據(jù)。優(yōu)點：你能夠維護和使用良好的并且有效的模擬真實生活中數(shù)據(jù)的測試數(shù)據(jù)。缺點：軟件開發(fā)的技能是基礎(chǔ)，并且需要訪問相關(guān)的測試數(shù)據(jù)。用法：大規(guī)模的測試套件被開發(fā)、執(zhí)行和維護的專業(yè)自動化測試。級別4要求一些非常良好的測試數(shù)據(jù)。一個測試人員必須要花費一些時間來識別在哪里收集數(shù)據(jù)和收集哪些數(shù)據(jù)。使用現(xiàn)實生活中的數(shù)據(jù)是最基本的以從測試中得到完全的回報。使用適當?shù)臄?shù)據(jù)將為你提供通常僅僅在項目的后期才會發(fā)現(xiàn)的或者是有客戶發(fā)現(xiàn)的錯誤的能力?，F(xiàn)在你能夠通過使用現(xiàn)實的數(shù)據(jù)開運行大量的測試。2.2.5.級別5：使用動作詞的測試自動化這是自動化測試的最高級別。主要的思想是將測試用例從測試工具中分離出來。這個級別要求有一個具有高技能測試人員測小的團隊，這些測試人員能夠?qū)y試工具的非常深層次的知識與他們具備的較深的編程能力結(jié)合起來。這個團隊負責在測試工具中生成并維護測試的功能性，能夠使測試工具從外部的來源，比如excel表或者數(shù)據(jù)庫中執(zhí)行測試用例。這種測試概念最初是由CMG開發(fā)的。與CMG方案相比，其他的可能的開放源碼的方案有被CarlNagle和SASInstitute開發(fā)的DDE。使用DDE的概念，關(guān)注點是當在Excel表中創(chuàng)建測試用例的時候，放置使用包括被使用的特定動作詞語的一些類型的模板。執(zhí)行的過程是從Excel表中讀取測試用例，并將測試用例轉(zhuǎn)換成為測試工具能夠理解的形式，然后使用不同的測試功能來執(zhí)行測試。這個概念變得越來越流，因為測試與用例一起使用是非常有用的。優(yōu)點：測試用例的設(shè)計被從測試工具中分離了出來－關(guān)注在設(shè)計良好的測試用例上。允許快速的測試用例的執(zhí)行和基于用例的更好的估計。缺點：需要一個具有工具技能和開發(fā)技能的測試團隊，以提供并維護測試工程（框架）。用法：專業(yè)的測試自動化將技能的使用最優(yōu)化的結(jié)合起來如果工具不具備使用內(nèi)建的對象映射的可能性，那么這個方案對于消除與GUI相關(guān)的大部分維護成本是優(yōu)秀的。在一些組織中已經(jīng)創(chuàng)建了這種方案，并且他們其中的一些已經(jīng)實現(xiàn)了高度的自動化（60%），并且他們都得到了巨大的回報。如果測試框架是適當?shù)模覀兡軌蚴褂胑xcel來生成實際的測試用例。這個級別對于那些按照正規(guī)基礎(chǔ)使用用例的組織或者項目來說是非常優(yōu)秀的。有多少測試用的估計是被需要的，并且當用例適當時需要做的工作也是非常簡單的。你可以集中時間來生成第一個包含被需要的"對象映射"的測試用例（主流程）。依靠被測試應(yīng)用的復(fù)雜程度，通常這會花費大約半天到一天的時間。后續(xù)的被需要的每一個測試用例大概會花費15到20分鐘的時間，因為通常多數(shù)的測試用例可以復(fù)制已有的測試用例，并對其進行必要的修改，通常這種修改是有限的。動作詞語框架能夠通過使用用例使緊密的并行測試用例的開發(fā)變得可能。2.3.我們不需要培訓！我們所有的人都在某一些方面具有一定的經(jīng)驗，我們沒有時間能夠花費在使用新工具的培訓上。當一個對自動化工具還不是很熟悉的組織或者項目團隊開始實施自動化測試時，培訓和指導(dǎo)是至關(guān)重要的。如果我們允許組織或者項目團隊在沒有關(guān)于應(yīng)該如何做的任何知識的情況下實施自動化的測試，那將肯定會以失敗告終。用于實施自動化測試方案的預(yù)算會被超出，測試會被延誤并且更壞的情況是自動化測試將被放棄。組織和項目團隊需要盡量避免一些認識上的缺陷，尤其是自動化測試的維護成本和當測試人員嘗試和確認工具如何工作時產(chǎn)生的挫敗感。你需要確保你的測試過程是適當?shù)模绻麥y試過程是不合理的，引入自動化測試只會給軟件組織或者項目團隊帶來更大的混亂。因此，我建議希望實施自動化測試方案的組織或者項目團隊應(yīng)該在實施之前建立"訓練營"，并將重點放在培訓測試團隊能夠很好的利用一個原型的項目上。為第一個原型項目制定一個實施計劃，下面包括原型項目的最小化的描述：當先狀態(tài)我們希望實現(xiàn)什么－建立成功的因素期待的回報（第一次自動化測試工作被期望驗證什么）找到一個"簡單的"測試的痛處并盡力的通過自動化測試解決它，這可以被作為在同一時間上使測試運行在多個平臺上的樣例說明被需要的資源和時間一開始你就要大聲的說出成功的信心－讓人們了解你所展示的進展。這將吸引更多的關(guān)注和資源。2.4.我們必須100%的自動化從管理的角度來說，100%的自動化目標只是一個從理論上可能達到的，但是實際上達到100%的自動化的代價是十分昂貴的。一個40-60%的利用自動化的程度已經(jīng)是非常好的了。達到這個級別以上將增加測試相關(guān)的維護成本。由于對每一個構(gòu)建版本的需求變化的復(fù)雜度，你將花費更多的時間在變更測試用例上以使他們能夠正確的運行。在這種情況下，通過告知管理層100%的自動化目標是相當昂貴的來確立一個合理的期望值才是明智之舉。對于決定自動化一個測試用例的一般規(guī)則是這個測試用例必須被運行4次以上。這個數(shù)字是基于用戶對測試工具有良好的技能并且有一個良好的測試框架的。如果情況不是這樣的化，整個數(shù)字能夠是10-20次或者更高。一個例子，在一個項目中測試人員花費和兩周的時間將手工測試的23天的任務(wù)轉(zhuǎn)換成了自動化測試的用例。在完成使，項目能夠在4個小時在多個平臺上運行相同數(shù)量的測試用例。2.5.測試框架測試框架對于產(chǎn)生成功的測試自動化的適當基礎(chǔ)是重要的。很多考慮必須被解決以使測試自動化更加有效地被使用。重點必須在：維護成本維護成本是成功的使用自動化測試的最重要的問題之一。維護成本直接聯(lián)系到前面已經(jīng)提到過的自動化測試的成熟度。組織或者項目必須至少要在成熟度的3級使用高度的測試庫才能使維護和更新測試功能變得容易。測試數(shù)據(jù)什么樣類型的數(shù)據(jù)將被使用？要為每一個測試用例生成測試數(shù)據(jù)還是使用在被測試應(yīng)用中已有的數(shù)據(jù)。在很多的情況下一個測試數(shù)據(jù)被創(chuàng)建了，刪除他們是不可能的?？蓽y試性自動化測試方案能夠有效的測試嗎？例如，被適當命名的對象（不僅僅是索引Id）。一個簡單的例子是所有的對話框都有相同的＃id和相同的標題，所不同的僅僅是顯示的文字信息。當測試應(yīng)該覆蓋多種語言的方案時，對話框的測試就是一個挑戰(zhàn)。測試人員的技能被包括在自動化測試的創(chuàng)建中的人員應(yīng)該具有什么樣的技能呢？如果他們具有良好的開發(fā)背景，那么成熟度3級是足夠了。如果他們有很少的或者根本沒有開發(fā)的經(jīng)驗，我們被迫使找到或者培訓一個自動化測試專家的小組，并直接到達成熟度5級，在成熟度5級測試的創(chuàng)建與實際的測試執(zhí)行被分離開。一個好的構(gòu)建過程自動化測試的引入在"構(gòu)建團隊"上加入了一些約束。為了實現(xiàn)自動化測試的高利用率（回歸測試），要求具有一個高的構(gòu)建頻率。每周僅僅運行自動化的測試不是好的自動化測試的使用率。將回歸測試增加到每天一次將幫助快速的發(fā)現(xiàn)新的問題并使開發(fā)人員更加容易的發(fā)現(xiàn)問題的根源，因為對測試的反饋時間是比較短的（開發(fā)人員能夠記住他們昨天做了什么）。所有權(quán)不同的測試庫的所有權(quán)的定義是重要的。一個好的方案會將測試庫的組織劃分為三個級別：級別1－全局的這個一個通常的級別。被存儲在這個級別的測試功能能夠被所有的項目訪問。通用的和通常的功能象登陸、創(chuàng)建一個用戶都是這個級別很好的候選者。級別2－項目在這個級別的測試功能是與特定的測試項目相關(guān)的，但是通常在項目中有用的比一定在項目外是有用的。通常級別2是級別1的功能的提供者。級別3－腳本功能被直接關(guān)聯(lián)到特定的測試腳本。I在這個級別中，通常一個測試功能的第一個版本是被開發(fā)的。在新的測試腳本的創(chuàng)建期間已有測試功能的重用性被發(fā)現(xiàn)，并被移到了級別2中。在這個級別上盡量最小化功能的數(shù)量，因為它將增加維護工作量。還有很多有關(guān)測試框架的問題，但是這里所提及的是一些基本的要被解決的問題。3.在哪里使用自動化測試有很多的情況下使用自動化的測試可以降低測試成本。我將盡量的突出在自動化測試中的不同的測試技術(shù)技術(shù)描述備注單元測試/組件測試這個測試工作通常是開發(fā)人員的職責，很多不同的方法能夠被使用，比如"測試先行"，它是一個測試框架，開發(fā)人員在編寫代碼前編寫不同的單元測試。當測試通過時，代碼也被完成了。通過使用正式的單元測試，不僅能夠幫助開發(fā)人員產(chǎn)出更加穩(wěn)定的代碼而且能夠是軟件的整體質(zhì)量更加的好。冒煙測試冒煙測試是一般驗證別測試系統(tǒng)的功能性測試用例的集合。冒煙測試背后的思想是確?；A(chǔ)是可以工作的，以便"大的"測試工作能夠開始。在構(gòu)建過程能夠確保構(gòu)建已經(jīng)為測試準備好時，冒煙測試通常是自動化的運行。功能/集成測試這里測試的工作關(guān)注在驗證在不同的組件之間的集成上。這些類型的測試通常是被測試系統(tǒng)的更加復(fù)雜測試的基礎(chǔ)，大量的邊緣測試被合并以制造出不同的錯誤處理測試。系統(tǒng)測試－用例測試這種測試是通過執(zhí)行用戶場景模擬真實用戶使用系統(tǒng)以證明系統(tǒng)具有被期望的功能的測試。這里不需要進行自動化的測試。安裝測試、安全性測試通常是有手工完成的，因為系統(tǒng)的環(huán)境是恒定不變的?；貧w測試回歸測試實際上是重復(fù)已經(jīng)存在的測試。通常如果是手工完成的化，這種測試只在項目的結(jié)尾執(zhí)行執(zhí)行一到兩次。這里完全有潛力應(yīng)用自動化的測試。你能夠在每次構(gòu)建完成后執(zhí)行自動化的回歸測試，以驗證被測試系統(tǒng)的改變是否影響了系統(tǒng)的其他功能。性能測試性能測試包括以下不同測試形式：-負載測試-壓力測試-并發(fā)測試-

如果沒有自動化的測試工具，你將不能執(zhí)行通過模擬用戶的負載實現(xiàn)的高密集度的性能測試。4.什么時候使用自動化測試我對什么時候應(yīng)該使用自動化測試和什么時候應(yīng)該使用手工測試進行了一個概要的總結(jié)：使用自動化測試使用手工測試項目沒有嚴格的時間壓力具有良好定義的測試策略和測試計劃你直到要測試什么

你知道什么時候測試對于自動化測試你擁有一個能夠被識別的測試框架和候選者能夠確保多個測試運行的構(gòu)建策略多平臺環(huán)境需要被測試你擁有運行測試的硬件你擁有關(guān)注在自動化過程上的資源

被測試系統(tǒng)是可自動化測試的

沒有適當?shù)臏y試過程沒有一個測試什么，什么時候測試的清晰的藍圖在一個項目中，你是一個新人，并且還不是完全的理解方案的功能性和或者設(shè)計你或者整個項目在時間的壓力下在團隊中沒有資源或者具有自動化測試技能的人沒有硬件如果你正在從事自動化測試，那么一定要記住要關(guān)注將自動化測試與手工測試結(jié)合起來使用。首先，對于自動化測試率的目標是10/90（10%的自動化測試和90%的手工測試）。當這些目標都實現(xiàn)了，可以將自動化測試的使用率提高。記住創(chuàng)建自動化測試的測試用例要比創(chuàng)建手工測試的測試用例花費更多的時間。不要將你所有的測試時間都用在自動化的測試用例上。同時也要記住在測試期間對每一個被發(fā)現(xiàn)的錯誤都要花費一定的時間去處理。5.自動化測試的好處如果你正在你的組織中引入自動化測試，記住有很多不同的方面被包含了進了。今天在測試工作如何被進行上有很多不同的視圖。為了能夠成功的實施自動化測試你應(yīng)該提出這些問題：測試覆蓋什么？－我們沒有覆蓋什么？由于遺漏的測試我們沒有發(fā)現(xiàn)的"bug"會帶來什么樣的成本？由于不好的測試，破壞已有功能性的成本是多少？如果"瑣碎的"測試被每天的運行，對于你的項目意味著什么？如果我們能夠每天向開發(fā)人員提供他們最近代碼變更相關(guān)的反饋，對項目有怎樣的影響？這些問題都能夠被自動化測試滿足。你必須從自動化測試成熟度的級別1或者級別2開始，并開始測量結(jié)果。根據(jù)我的經(jīng)驗快速的向開發(fā)人員反饋并每天運行測試對于向自動化測試成熟度的級別4或者級別5是非常有好處的。自動化測試有以下的貢獻：降低風險－你知道你測試了什么和沒測試什么測試能在項目的早期開始并隨著時間一直擴展快速的反饋－自動化測試用例能夠隨時的運行在多個平臺上的測試能夠同時進行更好的估計－你能夠?qū)y試進度和被使用的時間有更好的了解優(yōu)秀人員的集中－你能夠得到一個專家的團隊，并將他們的知識傳播給其他的項目喜悅-你和你的團隊正獲得著成功測試工具介紹下面我介紹市面上相對比較廣泛的測試軟件，Rational中的Robot和MI公司的WinRunner的具體的用法。 Robot，俗稱機器人。它有幾個特點，第一，Robot它的語法相對簡單，是一種類似于VB的語法，所以上手快；第二，Robot的腳本組織結(jié)構(gòu)類似于C的結(jié)構(gòu)，相對容易理解；第三，Robot運行環(huán)境和可參數(shù)化，所以容易維護；第四，要求的機器配置相對較低；第五，Rantional系統(tǒng)集成的很多產(chǎn)品很優(yōu)秀，而且適合面很廣；第六，相對價格比較低廉。 WinRunner的功能相對Robot相對來說有一下幾個特點。WinRunner的語法結(jié)構(gòu)是類似于C的語法，理解相對容易；WinRunner的腳本組織形式是以目錄的形式組織的，所以相對來說比較好管理；WinRunner支持當前市面上的很多系統(tǒng)；可以隨時Update檢查點的內(nèi)容，使得腳本的維護量減少機器配置相對要求高些；集成了很多優(yōu)秀的組件。下面我就嘗試寫一個Robot的腳本。題目：請檢查各種我們規(guī)定的字符是否過濾掉了，如果那些詞語沒有過濾掉請記錄下來。我們先看測試這個功能的邏輯關(guān)系圖應(yīng)該如下：我們創(chuàng)建的測試案例：準備很多需要過濾的詞語我們創(chuàng)建的測試案例：準備很多需要過濾的詞語程序處理模塊輸出處理結(jié)果T_FilterWord打開過濾詞文件T_OpenTestFile測試腳本：FunctionT_OpenTestFile(Filenameasstring)asinteger{ 。。。。。。。。。。。。。}FuncitonT_FilterWord(getwordasstring)asinteger{。。。。。。。。。。。。}以上是兩個SBL文件，相當于C中的函數(shù)實體那么我們要建立一個SBH，相當于C中的頭文件，紅色的部分類似于一個類庫，我們把相關(guān)的或者具有相似屬性的操作或者函數(shù)定義在同一個類庫中。DeclareFunctionT_OpenTestFileBasiclibT_FileOpertion(filenameasstring)asintegerDeclareFunctionT_FilterWordBasiclibT_FileOpertion(getwordasstring)asinteger我們現(xiàn)在建立一個腳本文件REC＃includeT_FileOpertion.sbhMain(){。。。。。。。}在此腳本中就可以調(diào)用上面那兩個函數(shù)了。在以后的測試中，我們只需要維護過濾詞文件庫就可以了。這樣提高了工作效率，保證了測試的正常進行。 下面我就舉個例子，來嘗試用WinRunner的使用方法，其實例子相對很簡單，主要是想告訴大家這種語言腳本的組織方法是怎么樣的？ 測試工具在實際工作中的應(yīng)用 現(xiàn)在在測試行業(yè)說的最多的有兩個問題，第一個問題是測試的待遇和地位，第二個問題是自動化問題。我這里不談測試的地位，只談自動化測試。如何做好自動化測試？這里給出幾個分析方法，第一，被測試產(chǎn)品是否有延續(xù)性？第二，被測試產(chǎn)品的維護頻繁度？第三，被測試產(chǎn)品自動化的難度如何？ 其次，如何選擇自動化工具，選擇容易上手的，測試腳本和測試數(shù)據(jù)容易維護的，價格低廉的。 正確的理解測試工具需要我們?nèi)ヒ龑?dǎo)，我們應(yīng)該清楚的知道那些應(yīng)該自動化，那么能自動化，那些自動化程度會更高等。 工作中的自動化測試的幾中方法 數(shù)據(jù)驅(qū)動法 數(shù)據(jù)驅(qū)動是測試中最常用的一種方法，它是在不修改測試程序的情況下或者稍微修改測試程序的情況下，不段的增加測試案例來進行自動測試的一種方法。舉一個具體的例子：例如我們檢查登陸驗證（用戶名稱）， 如果我們采用自動化測試，我們只需要在測試配置文件中增加或者刪除修改配置文件就可以達到測試的效果了。測試程序測試程序測試配置文件被測試程序輸出反饋結(jié)果，實際處理結(jié)果預(yù)期處理結(jié)果只要將兩個文件進行比較，就可以得到被測試程序的處理能力和結(jié)果了。 樁驅(qū)動樁驅(qū)動也是一種常見的測試方法。這種測試方法是把某個模塊假設(shè)是正確的，然后把這個模塊作為主核心，然后測試他傳出的參數(shù)和數(shù)據(jù)給其他模塊來處理，