軟件測試網(wǎng)學(xué)習(xí)教程-中文員

經(jīng)過大家的不懈努力，測試時代終于有了一份經(jīng)過大家的不懈努力，測試時代終于有了一份面向軟件測試專業(yè)人員的技術(shù)性期。眾所周知，在軟件開發(fā)過程中對軟件測試的誤解較大，多數(shù)公司將其作為軟件業(yè)中不重要的工作。產(chǎn)生這種誤解主要原因是由于這些公司對軟件開發(fā)過程認識不足造成。除此之外作為軟件測試人員也應(yīng)從自我做面向軟件測試專業(yè)人員的技術(shù)性期性的文章，通過測試時代網(wǎng)識、增強測試人員之間交流，同時也為廣大軟件測性的文章，通過測試時代網(wǎng)識、增強測試人員之間交流，同時也為廣大軟件測試人員提供一個信息發(fā)布的平臺，鼓勵大家在測試測試時代 上多發(fā)上和測上和測試時代 相結(jié)合，真正實現(xiàn)網(wǎng)上網(wǎng)互動，提高軟件測試人員的技能，進而推動整個軟件測試行業(yè)的發(fā)展。期總編：Http 期關(guān)于測試人員的角 突然就開始了這個角色的扮演：來跟大家介紹作為一個測試人員的角色定位，以及剛?cè)腴T需要了解的相關(guān)知識和心態(tài)方面的問題。說實話，感覺到很為難，有時候有些事情做起來感覺并不是很難，但是要把它轉(zhuǎn)化為文字的形式表達出來對我

欄 ERP方面的測試知識解：來說確實比較為難的。但是我還是很愿意去用 解：支拙筆來慢慢描述我對測試人員定位的一個理當一個人在一個漫長而坎坷的 走過人后，我相信他一定會有自己沉淀下來的東西。前段時間參加華東測試交流會時，聽到海松大哥解析測試人員如何定位自己的角色的時候就感觸很深，感覺自己

還有很多值得鉆研的地方，在測試領(lǐng)域，自己的很多認識還是很膚淺的。隨著公司規(guī)模逐漸擴大，測試人員也由以前的幾個人發(fā)展到現(xiàn)在的幾十人。隊伍的壯大是顯而易見的。然而很多剛進入門的同仁卻開始慢慢對做測試流露出迷茫的眼神，問其原因，很簡單，做測試學(xué)不到東西，整天就鼠標點點，鍵盤敲敲，很難學(xué)到真正的東西。聽了之后不由得露出理解的笑容，想當年我也是從這樣的境遇走過來的。剛進入公司的時候就讓做測試，經(jīng)歷了同樣的鼠標點點，鍵盤敲敲的經(jīng)歷。然而正是這樣的一些成長經(jīng)歷讓我在平淡中明白了很多道理，并且慢慢從因為工作而做測試轉(zhuǎn)化為因為而繼續(xù)做測試工作。做測試不僅僅是表面看到的這種敲敲點點現(xiàn)象的延續(xù)，還有更深層次的內(nèi)涵，是我們很多人還沒到達這個境界而已，所以看起來很枯燥。（我也沒達到這個境界，不過我知道自己做的工作并不是很枯燥的，呵呵。剛開始做測試的朋友很多都在做黑盒測試，而黑盒測試往往對代碼編寫能力要求不是很高，這樣給剛?cè)腴T的人就造成了一個測試人員不需要太多知識的誤解。然而，做測試往往需要很廣泛的知識。不僅僅只是專業(yè)上的，而且要了解很多開發(fā)人員不了解的東西，在一個系統(tǒng)里面開發(fā)人員可以只了解客戶需求，而我們的測試人員需要了解整個全局的東西。呵呵，感覺有點統(tǒng)籌全局的成就感。不過有時候相對于開發(fā)人員來說也的確是這樣的。開發(fā)人員可以不用太多了解用戶的需求，而我們卻需要能夠準確捕獲用戶的觀點，對很多細節(jié)需要非常注意。往往很多人在初入測試行業(yè)的時候非常熱衷于測試工具的學(xué)習(xí)以及使用，其實這并不是一個很系統(tǒng)的認知。知識的學(xué)習(xí)也是分階段的。測試這兩個字很表面來看很簡單，只是給程序挑錯誤，找出bug來，但是在整個軟件開發(fā)過程中我們該如何把測試跟開發(fā)結(jié)合起來有效地進行都需要經(jīng)過實踐來證明。而這些不是工具所能完成的。我們對整個測試流程方面的東西需要了解得很多很多，而工具只是需要了解的其中一部分而且是比較小的一部分知識而已。你所了解的不僅僅只是測試的表 面，你需要了解測試的流程，你需要了解如何用一個好的測試計劃來規(guī)劃我們的測試時間、測試范圍（有些公司把測試范圍的設(shè)計歸納在測試需求里面，但是很多公司都是在測試計劃里面），需要了解如何用一個好的測試用例來覆蓋整個測試范圍之內(nèi)的測試實施。了解如何保證所測試出來的bug是開發(fā)人員的問題而不是因為自己了解不夠?qū)е鲁霈F(xiàn)的問題。Bug分析報告之內(nèi)如何總結(jié)問題都是我們需要注意到的知識。對自己的測試時間也需要進行詳細規(guī)劃，盡量多地考慮進去各種可能。這樣才可以盡量減少相關(guān)的風(fēng)險。測試里面的知識學(xué)習(xí)可以分為以下三個階段來進行（這個階段只是自己的一種個人見解）：第一個階段須要讓做測試的人明白測試在整個軟件工程里面的重要性，了解測試的相關(guān)基礎(chǔ)知識，并且在了解這些知識的過程中逐漸挖掘出他對測試的。是很好的從事一項工作的一個重要條件。讓一個對測試絲毫不懂而且不感的人去直接去做測試，你不覺得是在耽誤別人的青春嗎？第二個階段 須對測試的流程的管理工作通過實際的軟件測試有個非常明確的認識。因為很多時候工作都是在團隊相互協(xié)調(diào)的情況下進行的，所以對于整個軟件開發(fā)流程以及開發(fā)流程當中的測試流程都需要很熟悉，這樣才可以更好的配合工作。當我們這些都很熟悉并且在工作當中應(yīng)用很流暢的時候，我們就可以對測試工具進行相對應(yīng)的學(xué)習(xí)。誠然，現(xiàn)在很多公司在招聘測試人員的時候總是要求了解自動化測試工具，實際上據(jù)了解，很多公司并不能真正用自動化測試。所以不要一進門就想著學(xué)習(xí)自動化測試工具，很多知識在你了解了其他知識之后學(xué)習(xí)效果跟用途可能會更好。在了解測試相關(guān)流程的同時 須擴充我們的其他相關(guān)知識，包括對我們的產(chǎn)品的客戶的需求的了解要比開發(fā)人員了解更全面，更深入。這樣才能保證我們的流程，我們的測試按照客觀的正確的方向前進，而不至于被開發(fā)人員的思想所牽引。呵呵。我喜歡做事主動而不是 的去執(zhí)行。到第三個階段我們可以跟區(qū)分專業(yè)一樣走自己喜歡的途徑：一方面可以繼續(xù)深入提高自己的測試的專業(yè)技能并且能夠真正從事自動化測試，成為技術(shù)領(lǐng)域里面的專家。另一方面我們可以慢慢趨于測試管理方面。上次在交流會上，海松大哥對測試人員的發(fā)展階段跟發(fā)展路徑規(guī)劃曾作出一個很形象的比喻來，我畫了一個粗略的流程，大家下面的發(fā)展圖（自下向上的發(fā)展趨勢）（當然并不是每個人都在這個曲線發(fā)展之內(nèi)）（直線的長度可以粗略的概括發(fā)展的不同時間長短從這個圖形我們大家也可以粗略的看出，對于初級測試工程師，這是兩個不同的發(fā)展方向，但是最終還是發(fā)展為一個終點（PM。從一個初級測試工程師晉升到一個高級測試工程師比較快，但是從一個初級測試工程師發(fā)展到一個TeamLeader所需要的時間相對比較長。而從一個高級測試工程師發(fā)展到一個資深測試工程師花費時間更長一點，到達資深測試工程師之后就可以很容易做到測試主管了，以后可以發(fā)展到PM。當然從初級測試人員到高級、資深測試人員在上面的圖中并不是表述為“曲線發(fā)展過程”的，很多時候行業(yè)經(jīng)驗、行業(yè)知識的累積等都很重要。而這點只有深入發(fā)展的人才會發(fā)現(xiàn)其重要性的。很多隨著時間的推移和經(jīng)驗的增長，一些沉淀下來的東西不是表現(xiàn)在字面上，別人就可以理解并領(lǐng)悟的。所以要有信心的同時我們做事還必須有耐心，羅馬非一日建成。相信明天就要緊緊把握今天。我們很多人在測試的時候感覺到不爽的另外一個比較大眾化的原因，可能就是對測試不感的同時知識層次不夠（建議接觸測試一年之后還對此不感興趣的朋友找找自己的原因，實在找不出來就早點看看別的比較好發(fā)展的行業(yè)吧。。因為自己知識層次的不夠，這樣往往感覺自己找出的bug在開發(fā)人員那里得不到很好的重視，感覺自己的勞動成果沒有得到相應(yīng)的尊重一樣。一個測試人員在跟開發(fā)人員打交道的時候往往會產(chǎn)生這么一個現(xiàn)象，隨著開發(fā)的進行，測試人員提交的bug越來越不被開發(fā)人員重視了，這里面除了開發(fā)人員比較忙碌的緣故之外，另外一個不容忽視的原因就是我們測試人員自身的知識不夠?qū)哟?，很多時候因為我們不了解需求，不了解相關(guān)專業(yè)知識而誤認為正確的東西是bug。任何一個領(lǐng)域里面的人都應(yīng)該有這樣的想法并且比較這個想法：那就是外行對內(nèi)行進行不正確的指點，這相當于對別人勞動成果的一種不負責任的否定。所以我們一定要加強我們自身的專業(yè)知識的學(xué)習(xí)。這個時候大家可能會問，那么一個真正的測試人員應(yīng)該具備哪些知識呢？在除了相關(guān)專業(yè)知識之外還有一些比較共性的知識需要我們大家了解，專業(yè)知識因為行業(yè)的不同所以有很多的不同之處，這兒不詳細介紹了，我從大眾化的方面來闡述下面幾個需要我們注意的地方，這也是作為一個測試人員應(yīng)該具備的基本素質(zhì)：1、我們需要具備很好的溝通能力：溝通是人類相互進步的一個重要標志，用在我們這個行業(yè)里面溝通也比較適用。我們的溝通往往不僅是跟開發(fā)人員的溝通，有時候也會跟我們的客戶進行溝通的。這是兩種不同類型的人，他們關(guān)心問題的側(cè)重點也不同。所以我們溝通時候需要掌握一定的技巧，這樣才能從客戶那兒得到比較準確的需求。有時候我們的工作會被開發(fā)人員認為是“破壞”性的工作，這樣就會引起我們跟開發(fā)人員的 ，所以當我們發(fā)現(xiàn)一個bug之后如何跟開發(fā)人員溝通也是一門藝術(shù)。很多時候我們不僅僅是把bug寫出來，也要很好地說給開發(fā)人員知道。從而達到我們彼此想要的一種結(jié)果。2、我們需要具備很好的自信心：很多時候開發(fā)人員會經(jīng)常認為測試人員的開發(fā)相關(guān)知識不如自己，所以會有一種輕視的態(tài)度，這個時候我們除了補充我們的專業(yè)知識之外還需要有很強的自信心。呵呵。如果允許他對我們說這說那，那么我認為我們的工作還沒開展就已經(jīng)處在十分不利的地步了， 會被他們牽鼻子走。這種現(xiàn)象很正常。而我卻屬于那種很討厭被別人牽著鼻子走的人。所以我知道 要很專業(yè)才能讓別人尊重自己的勞動成果并聽取自己的見解。當然這種自信心也是建立在心平氣和下的溝通，不是完全對立的。3、我們需要保持一種懷疑的精神（這點我很擅長，我經(jīng)常懷疑那些跟 經(jīng)質(zhì)。虧大了）我們會經(jīng)常碰到這樣一種情況，我們往往發(fā)現(xiàn)的bug交給開發(fā)人員時他們總是盡他們最大的努力解釋每個他們認為不是bug的bug。我們在他們解釋的同時必須要懷疑他們的觀點直到我們自己確認過之后。4、我們需要耐心和很好的 力：有時候往往一個bug需要我們很耐心的花費時間、精力去投入在上面，而且當我們再找到有些類似的bug的時候，要能從腦子里面找出來這些bug，這就需要我們有很好的 力。其實如果不具備這些條件了那么相關(guān)的文檔就是我們最好的查詢資料。我就是屬于這種類型的，很多時候總是翻閱以前的文檔。但是這樣也有一個好處，那就是在不斷的查詢過程中我們對文檔的修改，使文檔日臻完善，當然這種完善也是相對的。5、我們需要一顆安靜的心：因為浮躁的人是找不出隱藏在深處的bug的，（所以我們的開發(fā)人員總是喜歡讓我測試他們的東西，因為我匯報的bug很少，這樣他們的績效就表現(xiàn)得很好啊。所以我總是挨批啊。不過現(xiàn)在學(xué)乖了，呵呵）所以當我們測試的時候我們應(yīng)該保持內(nèi)心的平靜，這樣我們才會保持很好的洞察力來找到那些隱藏很深的bug。而且也會抓到相關(guān)的重點的。這點是很重要的。否則你的測試跟 做也沒什么區(qū)別，根據(jù)業(yè)務(wù)流程，根據(jù)用戶需求，根據(jù)開發(fā)人員的思路一路跑下去，發(fā)現(xiàn)一些皮毛的bug。這不是一個好的測試人員應(yīng)該做的。我們在平靜當中才能保持自己的觀點不被別人左右。6、我們還需要能夠承受壓力并排遣壓力：無須質(zhì)疑，我們的工作承受著一定的壓力，當然這樣說有點片面，不過大體上應(yīng)該是這樣的。所以我們經(jīng)常承受著一定的壓力，客戶在催促，開發(fā)人員在delay，風(fēng)箱里面的老鼠兩頭受氣。所以我們要能夠承受壓力，包括外界的、工作上的壓力。并且因為壓力而導(dǎo)致的不好的情緒帶到工作當中。學(xué)會排遣這些壓力，保持一顆輕松的，平靜的心，然后全身心投入到我們的工作。上面的只是根據(jù)實際的一些經(jīng)驗以及曾經(jīng)看過的一些朋友的見解總結(jié)而來的，還有很多其他方面的知識但是我實在沒有時間了呵呵抱歉。以后有時候還可以繼續(xù)補充。只是想強調(diào)一點：測試的發(fā)展前景是非常好的這點從這幾年無論測試人員和測試環(huán)境的變化還是客戶對產(chǎn)品質(zhì)量的要求越來越高都可以看出的。還是上面說的那句老話：相信明天，有關(guān)黑盒測試、白盒測試和灰盒測試的 ]黑盒測試黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用于軟件確認測試?！昂诤小狈ㄖ塾诔绦蛲獠拷Y(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進試。白盒測試白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗證。“白盒”法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進 試?！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序 了設(shè)計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了—些與數(shù)據(jù)相關(guān)的錯誤?；液袦y試灰盒測試，確實是介于二者之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細、完整，只是通過一些表征性的現(xiàn)象、事件、標志來判斷內(nèi)部的運行狀態(tài)，有時候輸出是正確的，但內(nèi)部其實已經(jīng)錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法?；液袦y試結(jié)合了白盒測試盒黑盒測試的要素.它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價應(yīng)用軟件的設(shè)計?；液袦y試由方法和工具組成，這些方法和工具取材于應(yīng)用程序的內(nèi)部知識盒與之交互的環(huán)境，能夠用于黑盒測試以增強測試效率、錯誤發(fā)現(xiàn)和錯誤分析的效率?；液袦y試涉及輸入和輸出，但使用關(guān)于代碼和程序操作等通常在測試人員視野之外的信息設(shè)計測試。慧靈科技依托測試時代資源，推出面向?qū)嵺`的軟件測試專業(yè)課程，由國內(nèi)著名軟件企業(yè)的一線技術(shù)專家主講，為您的企業(yè)解決實踐中的關(guān)鍵問題。如果您培訓(xùn)的目的不是拿一個，而是想學(xué)習(xí)軟件測試的最佳實踐那我們會是您一個不錯的選擇。登陸公司： ]概念和定義不完全、不徹底是軟件測試的致命缺陷，任何程序只能進行少量而有限的測試。測試用例在此情況下產(chǎn)生，同時它也是軟件測試系統(tǒng)化、工程化的產(chǎn)物。而測試用例的設(shè)計一直是軟件測試工作的重點和難點，那么

：：什么是測試用例？為達到最佳的測試效果或高效 隱藏的錯誤而精心設(shè)計的少量測試數(shù)據(jù)，稱之為測試用例。我們不可能進行窮舉測試，為了節(jié)省時間和資源、提高測試效率，必須要從數(shù)量極大的可用測試數(shù)據(jù)中精心挑選出具有代表性或特殊性的測試數(shù)據(jù)來進行測試。怎樣的用例算是好用例？—個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。使用測試用例的好處在開始實施測試之前設(shè)計好測試用例，可以避免盲目測試并提高測試效率。測試用例的使用令軟件測試的實施重點突出、目的明確。在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。功能模塊的通用化和復(fù)用化使軟件易于開發(fā)，而相對于功能模塊的測試用例的通用化和復(fù)用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。設(shè)計測試用例的方法黑盒測試：等價類劃分法邊界值分析法錯誤推測法因果圖法白盒測試：邏輯覆蓋法基本路徑測試法測試用例的設(shè)計過程測試設(shè)計員（分析設(shè)計員）依據(jù)不同階段的測試計劃、設(shè)計模型和實施模型來設(shè)計該階段測試用例。測試設(shè)計員是具有豐富測試經(jīng)驗或具有軟件分析設(shè)計能力的高級測試工程師。如果沒有測試設(shè)計員，則可用分析設(shè)計員代替。針對白盒，還應(yīng)有驅(qū)動程序和樁模塊。測試點的確定ISO質(zhì)量體系：在概要設(shè)計或詳細設(shè)計中應(yīng)明確 每個單元模塊的測試要點、指標和方法。CMM質(zhì)量體系：在系統(tǒng)的用例模型描述中應(yīng)明確每個用例模型的優(yōu)先級及用例工作流程，每一個用例模型為一個測試點，用例模型中每一個測試需求至少應(yīng)有兩個測試用例。理解上的誤區(qū)測試用例應(yīng)由測試設(shè)計員或分析設(shè)計員來制定，而不是普通的測試員。測試點應(yīng)由分析設(shè)計員確立，與測試人員無關(guān)。測試工作展開于項目立項后，而不是代碼開發(fā)完成之后。測試對象不僅僅是源代碼，還包括需求分析、需求規(guī)格說明書、概要設(shè)計、概要設(shè)計說明書、詳細設(shè)計、詳細設(shè)計說明書、使用手冊等各階段的文檔。用例場景的定義用例場景是通過描述流經(jīng)用例的路徑來確定的過程，這個流經(jīng)過程要從用例開始到結(jié)束遍歷其中所有基本流和備選流。為什么引入用例場景現(xiàn)在的軟件幾乎都是由事件觸發(fā)來控制流程的，事件觸發(fā)時的情景便形成了場景，而同一事件不同的觸發(fā)順序和處理結(jié)果形成事件流。這種在軟件設(shè)計方面的思想也可被引入到軟件測試中，生動的描繪出事件觸發(fā)時的情景，有利于測試設(shè)計者設(shè)計測試用例，同時測試用例也更容易的得到理解和執(zhí)行。提出這種測試思想的是Rational公司，在RUP2000中文版當中有其詳盡的解釋和應(yīng)用，用例場景貫穿其中。用例場景例子下圖中經(jīng)過用例的每條不同路徑都反映了基本流和備選流，都用箭頭來表示?；玖饔弥焙诰€來表示，是經(jīng)過用例的最簡單的路徑。每個備選流自基本流開始，之后，備選流會在某個特定條件下執(zhí)行。備選流可能會重新加入基本流中（1和3），還可能于另一個備選流（備選流2），或者終止用例而不再重新加入某個流（備選流2和4）遵循上圖中每個經(jīng)過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結(jié)合起來，可以確定以下用例場景：場景1基本流場景2基本流備選流場景基本流備選流備選流場景基本流備選流場景基本流備選流備選流場景基本流備選流備選流備選流場景7基本流備選流4場景8基本流備選流3備選流注：為方便起見，場景5、6和8只描述了備選流3指示的循環(huán)執(zhí)行一次的情測試用例生成每個場景的測試用例是通過確定某個特定條件來完成的，這個特定條件將導(dǎo)致特定用例場景的執(zhí)行。測試用例例子假定上圖描述的用例對備選流3規(guī)定如下：“如果在上述步2‘輸入提款金額’中輸入的量超出當前帳戶余額，則出現(xiàn)此事件流。系統(tǒng)將顯示一則警告消息，之后重新加入基本流，再次執(zhí)行上述步驟2‘輸入提款金額’，此時銀行客戶可以輸入新的提款金額?！睋?jù)此，可以開始確定需要用來執(zhí)行備選流3的測試用例：測試用例場景預(yù)期結(jié)果本用例的開端是ATM本用例的開端是ATM處于準備就緒狀態(tài)?；玖鳒蕚涮峥?客戶將插入ATM機的讀卡機。驗 -ATM機 。帳戶代碼，并檢查它是否屬于可以接收的輸入PIN-ATM要求客戶輸入PIN碼（4位）驗證帳戶代碼和PIN-驗證帳戶代碼和PIN以確定該帳戶是否有效以及所輸入的PIN對該帳戶來說是否正確。對于此事件流，帳戶是有效的而且PIN對此帳戶來說正確無誤。ATMATM顯示在本機上可用的各種選項。在此事件流中，銀行客戶通常選擇“提款”。輸入金額-要從ATM中提取的金額。對于此事件流，客戶需選擇預(yù)設(shè)的金額（10 、20 、50 或100 權(quán)-ATM通過將卡ID、PIN、金額以及帳戶信息作為一筆交易發(fā)送給銀行系統(tǒng)來啟動驗證過程。對于此事件流，銀行系統(tǒng)處于聯(lián)機狀態(tài)，而且對 請求給予答復(fù)，批準完成提款過程，并且據(jù)此更新帳戶余額。TC場景步驟2-提款金額>帳戶余額在步驟2處重新加入基本流TC場景步驟2-提款金額<帳戶余額不執(zhí)行備選流3，執(zhí)行基本流TC場景步驟2-提款金額=帳戶余額不執(zhí)行備選流3，執(zhí)行基本流注：由于沒有提供其他信息，此簡單。實用舉例下面是一個由用例生成測試用例的更符合實際情況的示例。示例：ATM機器的主角和用例。下表包含了上圖中提款用例的基本流和某些備用流：返 被返還收據(jù)-打印收據(jù)并提供給客戶。ATM還相應(yīng)地更新內(nèi)部記錄。用例結(jié)束時ATM又回到準備就緒狀態(tài)。備選流1-銀行卡無效 在基本流步驟2中-驗證 ，如果卡是無效的，則卡被退回，同時會通知相關(guān)消息。備選流2-ATM內(nèi)沒有現(xiàn)

在基本流步驟5中-ATM選項，選項將無法使用。如果ATM內(nèi)沒有現(xiàn)金，則“提款”選流3-ATM內(nèi)現(xiàn)金不 在基本流步驟6中-輸入金額，如果ATM機內(nèi)金額少于請?zhí)崛〉慕痤~，則將顯示一則適當?shù)南?，并且在步驟6-輸入金額處重新加入基本流。選流4-PIN有 在基本流步驟4中-驗證帳戶和PIN，客戶有三次機會輸PIN。如果PIN輸入有誤，ATM將顯示適當?shù)南?；如果還存在輸入機會，則此事件流在步驟3-輸入PIN處重新加入基本流。如果最后一次嘗試輸入的PIN碼仍然錯誤，則該卡ATM機保留同時ATM返回到準備就緒狀態(tài)，本用例終止。選流5-帳戶不存 在基本流步驟4中-驗證帳戶和PIN，如果銀行系統(tǒng)返回的碼表明找不到該帳戶或 從該帳戶中提款，則ATM顯示適當?shù)南⒉⑶以诓襟E9-返回 處重新加入基本流。選流6-帳面金額不 在基本流步驟7-授權(quán)中，銀行系統(tǒng)返回代碼表明帳戶余少于在基本流步驟6-輸入金額內(nèi)輸入的金額，則ATM顯示適當?shù)南⒉⑶以诓襟E6-輸入金額處重新加入基本流。選流7-達到每日最大的提款金額

在基本流步驟7-中，銀行系統(tǒng)返回的代碼表明包括本提款請求在內(nèi)，客戶已經(jīng)或?qū)⒊^在24小時內(nèi)允許提取的最多金額，則ATM顯示適當?shù)南⒉⒃诓襟E6-輸入金額上重新加入基本流。選流x-記錄錯 如果在基本流步驟10-收據(jù)中，記錄無法更新，則ATM進銀行系統(tǒng)發(fā)送一條適當?shù)木瘓笮畔⒈砻鰽TM已經(jīng)暫停工作?？蛻艨呻S時決定終止交易（退出）。交易終止， 選流y-退出

退出。選流z- ATM包含大量的傳感器，用 各種功能，如電源檢測器不同的門和出 處的測壓器以及動作檢測器等。在任一時刻，如果某個傳感器被激活，則警報信號將發(fā)送給 而且ATM進入“安全模式”，在此模式下所有功能都暫停使用，直到采取適當?shù)闹貑?重新初始化的措施。第一次迭代中，第一次迭代中，根據(jù)迭代計劃，整個用例，只實施了下面的事件流：基本流-提取預(yù)設(shè)金額（備選流2ATM內(nèi)沒有現(xiàn)金備選流3ATM內(nèi)現(xiàn)金不足備選流4-PIN有誤、20美元、、）備選流5-帳戶不存在/帳戶類型有誤備選流6-帳面金額不足以從這個用例生成下列場景場景1-成功的提款基本流場景2-ATM內(nèi)沒有現(xiàn)金基本流備選流場景3-ATM內(nèi)現(xiàn)金不足基本流備選流場景4-PIN有誤（還有輸入機會基本流備選流場景5-PIN有誤（會基本流備選流場景6-帳戶不存在/帳戶類型有誤基本流備選流場景7-帳戶余額不足基本流備選流注：為方便起見，備選流3和6（場景3和7）內(nèi)的循環(huán)以及循環(huán)組合未納入上表。對于這7個場景中的每一個場景都需要確定測試用例?？梢圆捎镁仃嚮驔Q策表來確定和管理測試用例。下面顯示了一種通用格式，其中各行代表各個測試用例，而各列則代表測試用例的信息。本示例中，對于每個測試用例，存在一個測試用例ID、條件（或說明）、測試用例中涉及的所有數(shù)據(jù)元素（作為輸入或已經(jīng)存在于數(shù)據(jù)庫中）以及預(yù)期結(jié)果。通過從確定執(zhí)行用例場景所需的數(shù)據(jù)元素入手構(gòu)建矩陣。然后，對于每個場景，至少要確定包含執(zhí)行場景所需的適當條件的測試用例。例如，在下面的矩陣中，V（）用于表明這個條件必須是VALID（有效的）才可執(zhí)行基本流，而ITC（例）ID號場景/條件輸入TC（例）ID號場景/條件輸入的金（選擇的金額ATM內(nèi)的金額預(yù)期結(jié)果場景1-成功的提款VVVVV成功的提款。場景2-ATM內(nèi)沒有VVVVI提款選項不可用，用例結(jié)束場景3-ATM內(nèi)現(xiàn)金VVVVI本流步驟6-輸入金額場景4PIN有誤（有不止一次輸入機會IVVV本流步驟4，場景4PIN有誤（有一次輸入機會）IVVV本流步驟4，場景4PIN有誤（再有輸入機會）IVVV留，用例結(jié)束在上面的矩陣中，六個測試用例執(zhí)行了四個場景。對于基本流，上述測試用例CW1稱為正面測試用例。它一直沿著用例的基本流路徑執(zhí)行，未發(fā)生任何偏差?；玖鞯娜鏈y試必須包括測試用例，以確保只有在符合條件的情況下才執(zhí)行基本流。這些測試用例由CW2至6表示（陰影單元格表明這種條件下需要執(zhí)行備選流）。雖然CW2至6對于基本流而言都是測試用例，但它們相對于備選流2至4而言是正面測試用例。而且對于這些備選流中的每一個而言，至少存在一個負面測試用例（CW1-基本流）。每個場景只具有一個正面測試用例和測試用例是不充分的，場景4正是這樣的一個示例。要全面地測試場景4-PIN有誤，至少需要三個正面測試用例（以激活場景4）：輸入了錯誤的PIN，但仍存在輸入機會，此備選流重新加入基本流中的步驟-輸入PIN輸入了錯誤的PIN，而且不再有輸入機會，則此備選流將保留 用例。最后一次輸入時輸入了“正確”的PIN。備選流在步驟5-輸入金額處重新加入基本流。注：在上面的矩陣中，無需為條件（數(shù)據(jù)）輸入任何實際的值。以這種方式創(chuàng)建測試用例矩陣的一個優(yōu)點在于容易看到測試的是什么條件。由于只需要查看V和I（或此處采用的陰影單元格），這種方式還易于判斷是否已經(jīng)確定了充足的測試用例。從上表中可發(fā)現(xiàn)存在幾個條件不具備陰影單元格，這表明測試用例還不完全，如場景6-不存在的帳戶/帳戶類型有誤和場景7-帳戶余額不足就缺少測試用例。—旦確定了所有的測試用例，則應(yīng)對這些用例進行復(fù)審和驗證以確保其準確且適度，并取消多余或等效的測試用例。測試用例一經(jīng)認可，就可以確定實際數(shù)據(jù)值（在測試用例實施矩陣中）設(shè)定測試數(shù)據(jù)。TC（測試用例）ID號場景/條件輸入的金額或選擇的金額帳面金金額預(yù)期結(jié)果場景-成功的提款50.00成功的提款。帳戶余額被更新為450.00場景2-ATM內(nèi)沒有提款選項不可用，用例結(jié)束場景3-ATM內(nèi)現(xiàn)金警告消息，返回基本流步驟6-輸入金額場景4-PIN有誤（還有不止一次輸入機會）警告消息，返回基本流步驟4，輸入場景4-PIN有誤（還有一次輸入機會）警告消息，返回基本流步驟4，輸入場景4-PIN有誤（不再有輸入機會警告消息，卡予保留，用例結(jié)束以上測試用例只是在本次迭代中需要用來驗證提款用例的一部分測試用例。需要的其他測試用例包括：場景6-帳戶不存在/帳戶類型有誤：未找到帳戶或帳戶不可用場景6-帳戶不存在/帳戶類型有誤：從該帳戶中提款場景7-帳戶余額不足：請求的金額超出帳面金額在將來的迭代中，當實施其他事件流時，在下列情況下將需要測試用例：無效卡（所持卡為掛失卡、卡、非承兌銀行發(fā)卡、損壞等）法讀卡（讀卡機堵塞、脫機或出現(xiàn)故障）.帳戶已消戶、凍結(jié)或由于其他方面原因而無法使用.ATM內(nèi)的現(xiàn)金不足或不能提供所請求的金額（CW3CW3中只是一種幣值不足，而不是所有幣值都不足）.無法聯(lián)系銀行系統(tǒng)以獲得認可.銀行網(wǎng)絡(luò)離線或交易過程中斷電. ]Leveret現(xiàn)在大家在寫測試用例的時候每個人都有自己的特點，但是什么樣的一個測試用例才是一個比較好的用例，這是一個比較真實的現(xiàn)象，有這樣幾個問題大家可以交流一下自己的心得（如果愿意交流的朋友）：系統(tǒng)測試的用例要如何設(shè)計才能驗證需求？有時候不知道結(jié)果的情況下如何預(yù)測結(jié)果，測試用例應(yīng)該在不同的階段下實施的時候應(yīng)該是獨立的。一般在設(shè)計測試用例的時候要包括合理輸入，不合理輸入，預(yù)測結(jié)果，一般常用的測試用例的設(shè)計主要用到：等價類劃分，邊界值分析法，錯誤推測法，但是這些都是理論方面的概念，我們在實際設(shè)計當中往往并不是按照這些去做的。大家在設(shè)計測試用例的時候應(yīng)該都有自己的心得，如果愿意，可以把自己的觀點 出來大家來討論。Seanhe我感覺測試用例沒有什么好壞之分：）當初的那句話，能發(fā)現(xiàn)最多錯誤的，發(fā)現(xiàn)至今為止沒有發(fā)現(xiàn)的bug的用例就是好的用例，我認為是錯誤的。因為，測試不是解決問題，測試用例的好壞不是指單個的用例，而是用例的覆蓋度，單個用例再好，所有用例的覆蓋度不夠，那測試工作還是失敗的。所以測試的關(guān)鍵不是用例設(shè)計，而是測試范圍的圈定，使用的方法，用例的設(shè)計只是自然而然的事情。再說說一開始的用例怎么寫，開始肯定有很多不清楚所以用例中很多的內(nèi)容無法填寫，所以我們應(yīng)該默認用例的書寫是個迭代的過程，不同階段完成不同的內(nèi)容，執(zhí)行之前全部完成就可以了。Leveret用例的覆蓋率也應(yīng)該是從單個開始的，而且很多時候發(fā)現(xiàn)用例在很多輸入輸出方面的設(shè)計基本都是雷同的，至于測試范圍的圈定，在系統(tǒng)設(shè)計階段我們能考慮周全嗎？考慮的出發(fā)點呢？根據(jù)測試的類別來考慮還是根據(jù)需求方面呢？不過對你所說的用例的書寫的迭代過程比較贊同，我們一般測試正式開始之前會對用例有一個評審過程，明白了這個道理之后應(yīng)該會比較輕松的。對設(shè)計測試用例的來說。歡迎大家自己的觀點.Zhybing測試用例的好壞，主要看本測試用例是否滿足了測試內(nèi)容的要求，滿足了測試內(nèi)容要求的測試用例就是好的，不滿足測試內(nèi)容要求的測試用例就是不好的.Leveret:那測試內(nèi)容是在測試計劃里面反映的？按照你的說法。僅僅只是滿足測試內(nèi)容嗎？你是這么認為的？Jackei下面列舉了我的一些看法：對于有時候不知道結(jié)果的情況下如何預(yù)測結(jié)果”，個人覺得這個問題比較明確，如果需求無法明確，或者說需求不夠明確，則對于該需求的測試用例設(shè)計應(yīng)該推遲，并及時同需求人員進行交流，盡快將需求準確的定義下來。一般在系統(tǒng)測試階段考慮的測試方法是黑盒測試，這時對于測試用例的設(shè)計如何使用那幾種方法呢？個人認為可以先使用等價劃分的方法劃分出等價類，然后使用邊界分析法確定下測試數(shù)據(jù)，最后通過自己以往的廁所經(jīng)驗或者其他的經(jīng)驗來進行錯誤推測，增補一部分用例。對于這個問題，個人對于現(xiàn)在市面上的很多測試書籍都有的看法，很多書提到的一些用例設(shè)計的例子都是用windows計算器或者其他單純用幾個數(shù)字來作為例子——比如輸入域是0-100，讓你設(shè)計用例。很多時候我們在進行用例設(shè)計時看到的并不是很明顯的數(shù)字，這些東西都是隱含在業(yè)務(wù)規(guī)則中的，感覺我們現(xiàn)在很多初學(xué)測試的朋友這種分析業(yè)務(wù)規(guī)則的能力還是比較欠缺，看不到的測試需求。當然這些方法也就應(yīng)用的很有限了。對于“測試用例應(yīng)該在不同的階段下實施的時候應(yīng)該是獨立的”，我也比較贊成。個人認為關(guān)鍵要搞清楚測試用例的作用。作為開發(fā)過程，是先有需求人員進行需求的收集，然后是系統(tǒng)分析員對需求整理分析，形成用例或者軟件需求規(guī)格說明書，之后由系統(tǒng)架構(gòu)人員進行架構(gòu)設(shè)計，開發(fā)人員完成詳細設(shè)計和編碼工作——當然這也未必是一成不變的，但是大體的任務(wù)都是這么多。同樣，我們看一下RUP中對于測試工作的流程介紹，為什么要把測試設(shè)計同測試實現(xiàn)以及測試執(zhí)行明確的區(qū)分開來呢？因為測試工作現(xiàn)在同開發(fā)工作已經(jīng)越來越相似，包括測試需求的整理、測試用例的設(shè)計以及測試用例的實現(xiàn)。我們現(xiàn)在很多所在的公司可能從人力資源或者從公司的流程上無法保證完全按照這個規(guī)范來操作，但是我們可以從RUP中明確測試用例的作用。用例本身就是用來指導(dǎo)實現(xiàn)的，用例實現(xiàn)的時候可以是自動化也可以是手工操作的具體步驟。測試用例是可以同具體的應(yīng)用程序?qū)崿F(xiàn)完全獨立的，可以不受應(yīng)用程序具體實現(xiàn)變動的影響。至于為什么我將在下面說明。對于“很多時候發(fā)現(xiàn)用例在很多輸入輸出方面的設(shè)計基本都是雷同的”，我覺得這個就可以考慮測試用例的“復(fù)用”。其實雷同也是正常的。下面將闡述我個人對于測試用例設(shè)計工作的一些看法。我很贊成seanhe對于測試用例迭發(fā)的觀點，現(xiàn)實中我們也是這樣考慮的。測試用例不會平白無故的被設(shè)計出來，它是有目的和前提的。個人認為測試用例是用來指導(dǎo)具體測試實現(xiàn)的，包括自動化的實現(xiàn)和手工測試步驟的實現(xiàn)。對于測試用例對測試需求的覆蓋，個人認為不是測試用例編寫的目的，而是對測試工作的要求——是要求測試用例設(shè)計人員的階段性工作的結(jié)果必須符合一定的要求的。測試用例本身是無法保證覆蓋需求的。那么說到了測試需求，這里順便說說測試需求的確定。leveret也問到了這個問題——“至于測試范圍的圈定，在系統(tǒng)設(shè)計階段我們能考慮周全嗎？考慮的出發(fā)點呢？”個人認為測試范圍的圈定也就是測試需求的確定。對于一個產(chǎn)品來說，它的開發(fā)和測試都不是的，隨著開發(fā)版本的迭代，測試工作也將繼續(xù)進行下去，同時，我們對每個版本的測試范圍都是不同的。注意，這里有一個關(guān)鍵，也就是測試范圍圈定的出發(fā)點——軟件需求的確定。那么怎樣來明確軟件的需求呢？——版本。如果希望工作的進度和內(nèi)容可以明確的定義下來，就首先要考慮版本的確定——軟件需求的版本確定。通過軟件需求的版本控制，可以明確每個不同版本的產(chǎn)品中所實現(xiàn)的特性，哪些特性將在以后的版本中實現(xiàn)。這里重點提到的是對于需求也需要使用版本的概念來進行管理。既然某個版本的軟件需求已經(jīng)確定，那么接下來的開發(fā)工作就可以在這個需求版本劃定的范圍內(nèi)開展。在需求階段，軟件需求規(guī)格說明書和用例中對于軟件的描述、業(yè)務(wù)規(guī)則的描述就可以整理出我們最早的測試需求，這部分測試需求將完全來源于軟件需求，是當前階段測試工作的一個基礎(chǔ)。不過大家要看到，我們的測試工作從現(xiàn)在開始。這個時期我們有一個非常非常重要的工作，嘗試著進行需求文檔的檢查。這里，對于需求文檔的檢查主要是兩個方面：（1）檢查需求文檔描述的正確性，愚以為測試人員要對于真實的系統(tǒng)所涉及的業(yè)務(wù)非常熟悉，比如一個簡單的財務(wù)軟件，那么測試人員本身就要對會計工作熟悉，財務(wù)制度熟悉，在檢查需求文檔的時候不要所謂的“都是用戶真實的需求”，這里存在兩個問題，一是用戶是否真的能正確地描述自己的需求，二是需求人員是否真的能正確地理解需求。另外，還有一個用戶的需求是否符合行業(yè)規(guī)范的問題，如果不符合，那么是否要確認——這里存在一個隱患，用戶可能會在開發(fā)的后期突然要求他們自己要走行業(yè)規(guī)范，讓你的需求變動，所以要事先明確好。（2）檢查需求文檔描述的準確性。主要是考慮文檔中是否存在描述的模糊的地方，對于自己不清楚的問題一定要明確。這個時候是要保證需求的可測試性——我得意思是證需求是可以完全為測試工作服務(wù)的。再說的具體一點，要保證所有的軟件需求都是可以用某種方法來明確的判斷是否符合要求的。如果對于某個需求，無法獲得一個明確的判斷標準，則應(yīng)該請需求人員對需求進行修改或補充——一個缺乏準確定義的需求，我們可以認為開發(fā)人員也無法準確的實現(xiàn)或者實現(xiàn)一個錯誤的需求，如果在應(yīng)用程序交付測試時才發(fā)現(xiàn)這個問題，帶來的就因項目而異了。隨著開發(fā)工作的開展，開發(fā)部門的架構(gòu)設(shè)計以及詳細設(shè)計也將陸續(xù)提交，這時候，我們可以根據(jù)設(shè)計文檔來對原來的需求進行增補。注意，這里我們對于設(shè)計文檔中提到的內(nèi)容要有選擇的采用，只有符合軟件需求規(guī)格說明書或用例中已經(jīng)定義的部分才可以用來調(diào)整我們的測試需求。而同軟件需求不相符的部分，則需要同設(shè)計人員和需求人員一起討論，確定下以哪一個為準，然后調(diào)整測試需求。這部分工作其實已經(jīng)包含了對設(shè)計的檢查，繼續(xù)努力盡早的發(fā)現(xiàn)缺陷出現(xiàn)的征兆。在應(yīng)用程序交付后，測試部門開始執(zhí)試。這時很有可能通過一些我們根據(jù)測試需求設(shè)計的測試用例所沒有包含的方找到一些缺陷，那么，這部分方法我們也應(yīng)該整理到測試需求中。OK，相信說到這里，各位看客也應(yīng)該可以理解了我的觀點。對于一個持續(xù)發(fā)展的公司或者持續(xù)開發(fā)的產(chǎn)品，它的所有東西都是要不斷積累的。對于測試需求，不僅僅是在一個版本的開發(fā)過程中，在不同的階段進行迭代，在產(chǎn)品的整個生命周期中的不同版本間也是不斷迭代的。既然明確了測試需求，測試用例的考慮也就變成seanhe所說的那種自然而然的事情了。我們可以根據(jù)不同階段已經(jīng)確定下來的那些測試需求來進 試用例的設(shè)計，然后隨著開發(fā)過程的繼續(xù)，在測試需求增補或修改后不斷的調(diào)整測試用例。如果我們從產(chǎn)品的整個生命周期來看，就會發(fā)現(xiàn)其實根本沒有測試工作終結(jié)而測試需求和測試用例 結(jié)束的時候，因為一個版本的結(jié)束就是下一個版本的開始。從這個大的范圍來看，我們的測試需求和測試用例將 的不斷迭代下去。啊，今天心情好，比原來那個回復(fù)又多寫了很多，希望對所有的朋友多可以有些幫助。不過好像有些跑題，本來題目是“關(guān)于評價測試用例的好壞”，我還是要給出答案的：個人認為測試用例的好壞可以有幾個方面。第一，是否獨立于具體的實現(xiàn)；第二，是否可以比較方便的指導(dǎo)實現(xiàn)工作；第三，是否比較容易 而其他方面，個人認為則可以看做是“關(guān)于評價測試用例設(shè)計人員工作的好壞” 參考。如果朋友們希望就這些問題展開討論，可以發(fā) 到我的郵箱：jacke Jackei我又想到了一點評價測試用例好壞的因素：易用性：是否方便使用，比如是否可以隨便哪個人都可以拿來簡單的看看就知道如何根據(jù)用例進 試； 性：是否方便 ，特別是當需求或者設(shè)計發(fā)生變化的時候，是否付出較少的成本就可以完成 工作；有效性：是否可以保證一個用例在整個產(chǎn)品的一個相對較長的生命周期中可以反復(fù)使用，保證有效性。拋磚引玉，望大家繼續(xù)補充。您是否對軟件測試的整體規(guī)劃一直比較模糊？您是否覺得軟件測試工作技術(shù)含量不高，不知道如何提高自己？您是否發(fā)覺測試用例的復(fù)用率非常低而且檢索困難？您是否覺得測試工作不太容易規(guī)劃，總是不如預(yù)期？您是否覺得性能測試很重要但是不知道如何組織和實施有效的性能測試？您是否非常想知道大型的企業(yè)級系統(tǒng)是如何進行性能規(guī)劃的？您是否想知道流行的測試工具的使用方法？ 性能測試怎樣提高性能測試的效率和質(zhì)量 日新月異的今天，順應(yīng)世界經(jīng)濟一體化的潮流，中國軟件行業(yè)加強了與世界 溝通與交流，基于本身提高軟件質(zhì)量的迫切需要，在國外優(yōu)秀的軟件企業(yè)中被證明為提高軟件質(zhì)量行之有效的途徑，軟件測試開始越來越受國內(nèi)軟件行業(yè)重視。各種各樣的測試工具和測試理論，也都逐漸被我們所熟知。軟件測試也開始成為人們平時談?wù)摵途W(wǎng)上探討的熱點話題。在軟件測試倍受注目的情況下，身為一名軟件測試人員，如何高質(zhì)量的完成公司交給的測試任務(wù)，無疑是我們應(yīng)該考慮首要問題。從事軟件測試已近兩年，從剛開始的一臉茫然，到如今的手到擒來，期間也經(jīng)歷了很

欄 工作時間：3多曲折，總結(jié)這兩年來的經(jīng)念教訓(xùn)，我認為有必要就軟件性能測試這個話題和大家展開探討，與大家共同 軟件測試的得失，為提高我們的測試水平盡一分薄力。作為評價產(chǎn)品性能的重 ，性能測試在軟件測試工作中占 一直很大，要最終提供一份準確， 的測試報告，測試人員的努力工作自然不可或缺，但更重要的是測試人員清晰的工作思路，簡潔的測試流程和良好的測試方法。目前性能測試存在的問題總結(jié)以往進行的性能測試，雖然測試人員自始至終對測試工作都做到了認真負責，但測試報告出爐后，大家總覺得美中不足對測試結(jié)果都心存疑慮，尤其在那些時間跨度較長、針對不同的測試對象的性能對比測試中，或多或少都存在以下幾個方面的問題：測試準備不充分，測試目標不明確，測試計劃不詳細；缺乏測試以及針對測試對象的技術(shù)儲備；測試環(huán)境的穩(wěn)定性及前后一致性不足；測試數(shù)據(jù)精確性和代表性不足；測試描述不精練；下面，我們就剖析以上問題的同時，探討一下如何解決這些問題。性能測試準備這是一個經(jīng)常被測試人員忽略的環(huán)節(jié)，在接到測壓任務(wù)后，基于種種其它因素的考慮，測試人員往往急于進度，立即投入到具體的測試工作去了，測試、記錄、分析，忙的不亦樂乎，工作進行了一半才發(fā)現(xiàn)，或是硬件配置不符沒有做好測試準備惹的禍。那么我們應(yīng)該如何 能測試的準備工作呢 、需要分析，我們做測試也一樣。在拿到測試任務(wù)后，我們首要的任務(wù)就是分析測試任務(wù)，在開始測試前，我們至少要弄清以下幾個問題：要測試什么或測試的對象是誰？要測試什么問題或我們想要弄清楚或是論證的問題？哪些因素會影 需要怎樣的測試環(huán)境？應(yīng)該怎樣測試？只有在認真測試需求和仔細分析測試任務(wù)后，才有可能弄清以上一系例的問題，只有對測試任務(wù)非常清楚，測試目標極其明確的前提下，我們才可能制定出切實可行的測試計劃。明確測試目標,詳盡測試計劃在對測試需求充分了解的基礎(chǔ)上，制定盡可能詳細的測試計劃，對測試的實施是大有裨益的。測試計劃的制定，大多專業(yè)的測試書籍多有詳述，故本文不再鏊述。測試技術(shù)準備在目前的大環(huán)境下，要求測試人員在短時間撐握所有的軟、硬件知識是不太現(xiàn)實的，但平時測試人員應(yīng)抓緊對測試工具和測試理論的研究，在測試計劃中，應(yīng)給研究測試對象和測試工具分配充足的學(xué)習(xí)時間，只有在充分撐握測試工具，完全了解測試對象的前提下，我們才能夠?qū)嵤y試。建力在錯誤的認識上的測試，既使你再努力結(jié)果也是背道而馳，也很難證明問題，更不用說用這樣的測試報告去說服用戶。配置測試環(huán)境只有在充分認識測試測試對象的基礎(chǔ)上，我們才知道每一種測試對象，需要什么樣的配置，才有可能配置一種相對公平、合理的測試環(huán)境（這在性能對比測壓中尤其重要）考慮到其它因素，如網(wǎng)絡(luò)鎖、網(wǎng)速、顯示分辯率，數(shù)據(jù)庫權(quán)限、容量等對測試結(jié)果的影響。如條件允許，我們最好能配置幾組不同的測試環(huán)境。測試數(shù)據(jù)的獲取和處理在所有的測試中，測試數(shù)據(jù)的收集工作都是較為 的，GIS軟件更是如此，每一種軟件都有它的文件格式，有的軟件還有幾種格式。在這種情況下，我們只能把 格式的數(shù)據(jù)轉(zhuǎn)換成每一種被測試軟件自已的格式。同時，還應(yīng)對數(shù)據(jù)作一定的處理，如處理數(shù)據(jù)冗余，處理顯示風(fēng)格等。如在測試時會更新數(shù)據(jù)，操作前一定要備份數(shù)據(jù)。其外，還應(yīng)評估數(shù)據(jù)格式和數(shù)據(jù)量對測試的影響， 必要，應(yīng)準備多組數(shù)據(jù)。最后，一定要檢查測試數(shù)據(jù)的有效性，避免損壞數(shù)據(jù)對 的影響。如何開展性能測試測試前期的準備工作紛繁復(fù)雜，做好測試準備工作，已是完成了測試工作的一大半，但要產(chǎn)生一份具有說服力的測試報告，還應(yīng)正確把握測試的強度，保持測試的一致性，提高測試的精度。判斷軟件的好壞，要看軟件解決實際應(yīng)用的能力，只有在一定的測試強度下，才能測試出各種軟件資源的消耗率，軟件運行的速度，軟件的穩(wěn)定性。通過對比在不同的測試強度下，不同軟件每一個功能模塊解決實際問題的能力和軟件運行的效率，我們才可能判斷出不同軟件的每一個模塊的強弱，甚至于整個軟件的優(yōu)劣。性能測試開始后，所有參數(shù)的輸入都應(yīng)遵循統(tǒng)一的標準，無論是哪一個環(huán)節(jié)，哪怕是一點點偏差，都應(yīng)立即糾正，覺不能心存僥幸。要特別注意外部環(huán)境對的影響，如果在整個測試過程中，外部境不一致，如網(wǎng)速、機器內(nèi)存使用率不一樣，就有可能導(dǎo)制 與實際情況有出入。如何總結(jié)性能測試對測試的終結(jié)，實際就是對測試數(shù)據(jù)的分析和處理。我們測試工作做的再好，如最終到用戶手中的是一堆雜亂無章的數(shù)據(jù)，那也是美中不足。首先，我們最好從所有的測試數(shù)據(jù)中，篩選出具有代表意義的數(shù)據(jù)，做出統(tǒng)計圖，然后和開發(fā)人員一起，認真分析數(shù)據(jù)，找出軟件存在的問題，得出測試結(jié)論。大多數(shù)用戶，真正需要的就是科學(xué)、客觀的測試結(jié)論。結(jié)論各種軟件性能測試，范圍大小不同，強度高底有別，但只要本著認真、客觀，科學(xué)的工作態(tài)度，遵循本文論述的方法，做好測試工作是不難的。本篇文章主要談的是軟件性能測試方面的問題，相信對其它方面的軟件測試也有一定的借鑒作用。43《單元測試技術(shù)――Nunit3《測試管理――TD》2《自動測試工具――Robot2《自動測試工具――LoadRunner2上面是目前我們開發(fā)的課程，企業(yè)內(nèi)訓(xùn)可以直接們。如 ：Alan：Alan工作時間：6： ]Mail: 通過測試和其他形式的軟件質(zhì)量 活動而發(fā)現(xiàn)的偏差，統(tǒng)稱為軟件缺陷。我們通常說到的bug就是軟件缺陷的一種，是隱藏于代碼中的問題，它可以通過軟件測試，代碼的走查形式而加以發(fā)現(xiàn)。在本文中，我們現(xiàn)就bug來進行分析，為了表述方便稱為缺陷分析。這里提醒大家注意的是，缺陷的含義較廣，不同類型的缺陷需要用到不同的分析Mail: 什么是缺陷分析？缺陷分析本質(zhì)上是對缺陷中包含的信息項進行收集，匯總，分類之后使用統(tǒng)計方法（或者分析模型）得出分析結(jié)果。缺陷分析得出的結(jié)果可以用來度量（軟件）開發(fā)過程中各軟件階段中工作產(chǎn)品的質(zhì)量，了解缺陷集中的區(qū)域，明晰缺陷發(fā)展趨向。對于軟件過程的改進，軟件產(chǎn)品的發(fā)布來說具有十分重要的參考價值缺陷數(shù)據(jù)的收集在我們提交缺陷報告的時候，實際上就是在記錄一些必要的信息項。在不同的軟件生產(chǎn)企業(yè)中，需要記錄的信息項是大相徑庭的。以下是分析缺陷活動中必須收集的一些數(shù)據(jù)項目缺陷提交時需要收集的信息缺陷的嚴重等級缺陷所在的模塊缺陷發(fā)現(xiàn)的時間缺陷所在的版本號缺陷的發(fā)現(xiàn)者負責修改缺陷的工程師缺陷關(guān)閉時需要收集的信息缺陷關(guān)閉的時間關(guān)閉缺陷的版本修復(fù)缺陷而改動的代碼行數(shù)產(chǎn)生缺陷的根本原因（例如：需求，分析，編碼，軟/硬配置）分析點缺陷的發(fā)展趨勢缺陷的發(fā)展趨勢包括新發(fā)現(xiàn)缺陷數(shù)量增長趨勢和關(guān)閉缺陷數(shù)量的增長趨勢。對于軟件產(chǎn)品發(fā)布而言，發(fā)展趨勢圖是輔助決策的重要依據(jù)。一般來說，軟件發(fā)布的必要條件是新缺陷的數(shù)量增加呈下降趨勢，見下圖。CumOpenedCumBugs02004-4- 2004-4- 2004-4- 2004-4- 4-30Date在軟件過程中，缺陷發(fā)展趨勢圖有助于我們了解各版本中缺陷數(shù)量的分布。特別在回歸測試階段中，缺陷的分布可以直接反映本的質(zhì)量狀況。見下圖中各版本缺陷的分布狀況。缺陷的分布狀況缺陷分布狀況圖有兩種，第一種是缺陷按模塊的分布狀況，另外一種是缺陷按產(chǎn)生的根本原因的分布狀況。模塊分布圖SubsystemSubsystem50 Account Bug缺陷產(chǎn)生原因分布圖該分布圖是缺陷分析中最為重要的一張圖表，因為它可以直接反映出各軟件工程活動的質(zhì)量，為軟件過程的改進提供直接的參考數(shù)據(jù)。一般來說，缺陷產(chǎn)生的根本原因劃分的越細致，分析的結(jié)果就越精確。見下圖：

Bad

Functional

SystemBad但當我們發(fā)現(xiàn)需求中出現(xiàn)的缺陷比較多的時候，在未來的項目中我們可以通過需求評審，需求變更控制來減少該種缺陷的數(shù)量，以起到軟件質(zhì)量保證的目的。同樣如果我們發(fā)現(xiàn)軟件設(shè)計過程中產(chǎn)生的問題比較多，那么就可以通過加強軟件設(shè)計階段中的活動來保證設(shè)計的質(zhì)量。源代碼修改趨勢圖和模塊分布圖源代碼修改數(shù)量趨勢圖可以為回歸測試風(fēng)險分析和軟件發(fā)布提供參考。源代碼修改的數(shù)量越多，那么代碼產(chǎn)生的負作用的風(fēng)險就越大，為了規(guī)避風(fēng)險，回歸測試的強度就需要相應(yīng)的加強。同樣的道理，如果某一個產(chǎn)品的源代碼修改數(shù)量呈上升趨勢的話，那么它是不適合現(xiàn)在發(fā)布的。信息反饋1、本電子期的封面設(shè)計、版面設(shè)置有何建議？2、本電子期中各文章內(nèi)容的質(zhì)量如何？3、本電子期中您最喜歡的文章？4、你最希望在本電子期中看到哪方面的測試內(nèi)容？5、讀者個人信息簡錄：：從事測試工作年限：測試團隊人數(shù)：最關(guān)心的那種測試類別功能或性能或其它)：以何種方式知道測試時代的：感謝您花費寶貴的時間來填寫對本電子期的建議或意見，請將您的反饋信息發(fā)至 .cn。我們會認真對待每一封來信，并會衷心采納每一個有意義的建議。感謝大家對測試員電子期的支持與厚愛。歡迎投稿 稿件要求稿件要求含有標題、作者 及作者簡介(如：單位、個人愛好、聯(lián)系地址等可根據(jù)本人要求).屬于摘錄或拷 章，請注明文章出處及 作者。提倡大家多性文章.文 （不超過200字）（35個）正文,字體為宋體5號字.稿件格式為 Word格式， 在稿件中使用標題、分頁符等排版設(shè)置。加入我們測試行業(yè)的發(fā)展需要依托測試行業(yè)的同仁共同來推動，測試時代是一個開放的平臺，在這個平臺上需要的有志于測試行業(yè)的朋友共同來建設(shè)，在這個平臺上我們已經(jīng)籌建了測試Blog社區(qū)，測試員電子期，測試時代試交流會等一系