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

解析軟件測試的認識誤區(qū)作者：本文選自：由于人們對于軟件質量的重視程度越來越高，就導致了測試在軟件開發(fā)中的地位越來越重要。測試是目前用來驗證軟件是否能夠完成所期望的功能的唯一有效的方法。在這一趨勢的引導下，現(xiàn)在很多軟件相關的公司都非常重視對于他們所開發(fā)的軟件的測試，甚至不惜花費巨資的測試工具，但是效果卻不一定理想。究其原因主要是存在著對于軟件測試的諸多誤解。本文試圖對一些比較普遍的關于測試的誤解測試在軟件開發(fā)過程中一直都是備受關注的，即使在傳統(tǒng)的軟件工程中，也有一個明確、獨立的測試階段。隨著軟件的頻頻出現(xiàn)以及人們對于軟件本質的進一步認識，測試的地位得到了前所未有的提高。測試已經(jīng)不僅僅局限于軟件開發(fā)中的一個階段，它已經(jīng)開始貫穿于整個軟件開發(fā)過程，人們已經(jīng)開始認識到：測試開始的時間越早，測試執(zhí)行的越頻繁，所帶來的整個軟件開發(fā)成本的下降就會越多。ExtremeProgramming更是把測試推到了極限的位置，一切軟件開發(fā)活動都要從首先編寫測試代碼開始。但是，相對于測試這個詞的流行程度而言，有關測試教育方面的工作做的還遠遠不夠，很多關于測試的文章都是針對某種測試工具使用方面的，而測試工具廠商也往往出于商業(yè)的目的對于測試工具的作用夸大其詞。這樣，很多的軟件從業(yè)者就很容易陷入一些誤區(qū)，導致了測試并沒有在他們所在的軟件開發(fā)項目中起到有效的作用。下面幾個小節(jié)將對于一些比較具有代表性的誤區(qū)進行剖析，并對于測試背后所蘊含的一些設計思考進行了闡述，希望能夠起到拋磚引玉的作用。誤區(qū)之一：使用了測試工具，就是進行了有效的測試這個誤區(qū)可以說是一種通病，幾乎每一個領域中的CASE工具剛剛出現(xiàn)時都會帶來這個問題，比如：如果一個軟件開發(fā)團隊在軟件的開發(fā)中使用了RationalRose工具來進行UML圖的繪制，他們可能就會聲稱他們采用了面向對象的方法，也不管他們的設計和代碼實際上是過程化。在測試領域中也一樣如此，一個軟件開發(fā)團隊往往認為只要自己使用了某種軟件測試工具，那么就應該可以獲取測試帶來的種種好處，這種想法當然是錯誤的。因為，要想對一個軟件或者模塊進行有效的測試，首先該軟件或者模塊應該是可測試的?？蓽y試性是反映軟件質量的一個內在屬性，不會因為你使用了某種測試工具進行了測試行為，就使得被測試的軟件具有了可測試性。如果被測試的軟件本身并不具備可測試性，那么使用多么昂貴的測試工具進試所能夠帶來的收益都是微乎其微的。巧的是，可測試性和好的軟件品質的其他方面有天然的關聯(lián)，一個具有可測試性的軟件必然是一個強內聚、弱耦合、接口明確、意圖明晰的軟件，而不可測試的軟件往往具有過強的耦合和的邏輯。關于可測試性方面的內容不在本文的論述范圍，請自行參見相關的文獻（本文所附的參考文獻中有關于可測試性的更深入的信息。要想真正獲取測試帶來的巨大好處，并且使得測試工具能夠發(fā)揮最大的效率，關鍵就是要使軟件本身具有很好的可測試性。這種能力的獲取是一個逐步的過程，是不可能一蹴而就的。最關鍵的一點就是要不斷實踐，不斷學些優(yōu)秀的經(jīng)驗，不斷的。要想獲取好的結果，就必須要付出努力，這是亙古不變的真理。ExtremeProgramming中的測試先行的實踐倒是一個很好的起點。對于測試工具的選擇，只要滿足需要并能夠自動運試用例就可以了。不要一味的追求復雜的功能和不必要的靈活性。對于大多數(shù)項目來說，一些非常著名的源碼開放的測試工具就足夠了，比如：Java方面的單元測試工具JUnit和C++方面的單元測試工具CppUnit。關于驗收測試方面，目前沒有比較好的滿足各方面需要通用的測試工具，不過使用腳本語言，循序漸進的自行開發(fā)一個適合自己的驗收測試工具也不是一件的事情，一句話：只有提高了自身團隊內在的素質，外在的工具才能夠發(fā)揮作用。誤區(qū)之二：存在太多的無法測試的東西在軟件開發(fā)領域，確實存在一些東西看起來要比另外一些東西難測試一些，但是遠非無法測試。并且在大多數(shù)的情況下，還是由于被測試的軟件本身在設計時沒有考慮到可測試性的問題。只不過這種不可測試性不是由于被測試的軟件內部的過緊耦合造成的，而是和外部某些很難測試的部分耦合過緊，從而表現(xiàn)出被測試的軟件本身很難測試。這些很難測試的部分比較常見的有：圖形界面、硬件、數(shù)據(jù)庫等。下面以圖形界面為例進行說明。如果一個軟件模塊必須要通過圖形界面才能夠觸發(fā)它的應用邏輯時，那么要對這個軟件模塊進試時就必須要使用圖形界面。但是圖形界面又是很難測試的看起來好像很難辦。讓我們換一個角度考慮一下，其實我們真正想要測試的是軟件模塊本身的應用邏輯，而不是圖形界面的觸發(fā)邏輯。如果我們在設計時能夠把被測試的軟件模塊本身進行很好的封裝，定義良好的服務提供接口，那么我們就完全可以通過軟件模塊本身提供的接口進試。這樣就可以繞過難以測試的圖形界面。造成上述軟件模塊很難測試的原因正是由于在設計時把軟件模塊本身的應用邏輯和圖形界面這兩個無關的邏輯耦合在了一起。把這兩個邏輯分離，不僅可以對該軟件模塊進行更容易、更有效的測試，而且也使得該軟件模塊具有了很好的可重用性和可移植性。那么對于不好測試的圖形界面，我們該怎么辦呢？原則很簡單，如果某種東西不好測試，那么就讓它做肯定不會出錯的事情，而把可能會出錯的邏輯剝離出來，放到一個可以測試的模塊中。對于圖形界面來說，就是僅僅保持一個很薄的圖形界面邏輯，它的工作就是把用戶的請求簡單的轉發(fā)給真正處理該請求的軟件模塊（一般稱之為ApplicationFacade。轉發(fā)邏輯足夠簡單以至于它肯定不會出錯，所以我們也無需對它進試。如果在進行軟件開發(fā)時能夠首先編寫測試代碼，那么就會迫使你從易使用性，易測試性的角度開考慮問題，從而你就會專注于軟件模塊的抽象和職責。這樣就會定義出清晰的、明確反映意圖的模塊接口來，另外，為了使得測試能夠進行，你就會主動把那些導致不好測試的耦合去掉。這樣的結果不僅僅是獲得了可測試性，并且也產生了更好的設計和系統(tǒng)架構。但是確實存在一些不好測試的東西并且很難只讓它執(zhí)行一些非常簡單的邏輯，比如嵌入式系統(tǒng)中的BSP（板級支持包。開發(fā)它們所使用的語言、環(huán)境以及它們本身的特性等決定了它們是很難測試的。這里說的難測試其實是一個測試代價問題，具體的說就是要付出的時間和努力。這就需要你在付出的代價和測試帶來的收益之間進行平衡。如果付出的代價所帶來的收益（更少的調試、、發(fā)布成本）是巨大的，那么付出的代價就是非常值得的。誤區(qū)之三：測試代碼可以隨意大家肯定知道測試代碼是不能隨意編寫的，并且在編寫測試代碼時也不是抱著一種隨意的態(tài)度，但是你編寫出來的測試代碼以及測試代碼運行的情況卻表現(xiàn)出了一種隨意性和無序性。因為你可能并沒有弄清楚測試的真正意圖所在。本人曾經(jīng)看到過有關驗收測試的這樣一個案例，驗收測試者使用昂貴的測試工具對一個具有圖形界面的軟件進試。測試的方法是通過編寫測試驅鼠標在圖形界面上隨機的點擊（事件的區(qū)域），然后等待著被測試軟件的。當然這種測試方法可以作為驗收測試的一個方面，但是決不是唯一的一個方面。還有更重要的內容被忽視了。測試的目的是用來檢驗軟件系統(tǒng)是否滿足了需求。所以，你的測試代碼一定要明確的表達出這一點來。就那上面的案例來說，如果測試者真正從用戶的需求出發(fā)，那么他寫出來的測試肯定不會是那樣的，而應該是每一個測試用例都清晰的刻畫了一項用戶的需求，然后檢驗系統(tǒng)是否實現(xiàn)了用戶期望的功能。這樣的測試才是有明確目的，才是最有效的測試。和把界面邏輯和應用邏輯，采用明確表現(xiàn)用戶需求測試用例進試相比，上面的測試方法不能不說是隨意了一點。在針對類進行的單元測試中，也經(jīng)常會看到一些錯誤的測試方法。很多的測試者往往針對類中的每個特定的實現(xiàn)細節(jié)進試。類中的特定的實現(xiàn)細節(jié)是很容易變化的，在快速的迭代式開發(fā)中更是如此。一旦你測試的類中的某個實現(xiàn)細節(jié)發(fā)生了變化，你原先的測試代碼就要進行相應的更改，否則就失去了意義。這種頻繁更改的代價是巨大的。類是一種抽象，它反映了更面的內聚性，它應該有明確的職責和定義良好的服務接口，它的職責和對外的接口相對于內部的實現(xiàn)細節(jié)來說要穩(wěn)定的多，并且我們要驗證的正是這個類是否具備了它的職責。因此，在對類進測試時，我們應該針對類的接口來驗證類是否實現(xiàn)了它的職責而不是其他。這樣寫出來的測試代碼要穩(wěn)定的多，也有效的多。細想一下，造成容易陷入針對實現(xiàn)細節(jié)測試的原因主要是由于先實現(xiàn)了類，然后才去進試。如果先實現(xiàn)了類的功能，然后在去對類進試，中就會不由自主的想去驗證已經(jīng)完成的類的某種實現(xiàn)細節(jié)。如果能夠在編寫實際類前，首先編寫針對該類的測試代碼，情況就會有很大的不同，因為這會迫使你從類的使用者的角度去考慮問題。結果就是會把關注點放在類的易用性上，放在類的職責上面，放在類提供服務的接口上面，而不是某種實現(xiàn)細節(jié)。總之，測試代碼的編寫應該從被測試的對象是否滿足需要的層面進行，而不是誤區(qū)之四：單元測試和驗收測試沒有什么區(qū)別和誤解之三一樣，可能很多人并不承認這一點。但是他們卻又不能比較清楚的說出二者的差別來。這樣，在他們進試代碼的編寫時就會比較迷茫。本小節(jié)結試圖給出一些區(qū)分單元測試和驗收測試的一些原則來。我們還以經(jīng)常用來和軟件進行類比的建筑為例，首先給大家一個感性的認識。單元測試可以類比為一個建筑的質檢人員對建筑進行的檢測，他關注的重點是建筑的內部結構、地基、框架以及墻壁是否垂直等。他的檢測是要保證建筑的各個部分試可以類比為建筑的使用者來對建筑進行的檢測。首先，他認為這個建筑是滿足規(guī)定的工程質量的，這是有建筑的質檢人員來保證的。使用者關注的重點是住在這個建筑的中的感受。他關心建筑的外觀是否美觀、各個房間的大小是否合適，窗戶的位置是否合適，是否能夠滿足家庭的需要等。這里，建筑的使用者執(zhí)行的就是驗收測試，他是從用戶的角度出發(fā)的。建筑的質檢人員執(zhí)行的就是單元測試，他是從構建者的角度出發(fā)的。正是這種角度的不同決定了單元測試和驗收測試之間的區(qū)別。它們是對系統(tǒng)的不同的方面進行的測試，二者是互相補充的。不管我們在系統(tǒng)的構建中使用了多么聰明的方法，不管我們的系統(tǒng)是多么的靈活，但是首先我們的產品必須是可用的，否則我們所做的就是浪費時間，從這一點上來說驗收測試要比單元測試顯得更加重要。還以上一小節(jié)給出的案例為例，案例中所使用的測試方法僅僅是從系統(tǒng)是否健壯的角度出發(fā)進行的，即使系統(tǒng)從不也不能證明那是一個可用的系統(tǒng)。因為測試根本就不是從用戶使用的角度出發(fā)的，測試者本應該和用戶一起來編寫驗收測試。單元測試保證我們把事情作對，而驗收測試則保證我們做正確的事情。關于單元測試和驗收測試之間的明確劃分，沒有一個通用的標準，只有通過自己的不斷實踐來增加這方面的經(jīng)驗。你進行的有關測試的實踐越多，你就會越清晰的感覺到單元測試和驗收測試之間的界限所在。下面給出一些指導原則，在你編寫測試代碼時可能會有幫助。如果一個單元測試要類的邊界，那么它可能應該是一個驗收測如果一個單元測試經(jīng)常要隨著用戶需求的變化而改變，那么它可能應該是一個驗收測試如果一個單元測試比它要測試的代碼本身要難以編寫，那么它可能應該是一個驗收測試結測試是用來保證軟件開發(fā)過程的高效性，以及保證開發(fā)出來的軟件產品的高質量和可用性的。軟件開發(fā)本身就是一件非常的事情，這也決定了有效的測試決不是簡單的依靠一些測試工具就可以進行的。在使用工具的同時，我們更要加強關于測試的培訓、教育，使大家對于測試首先有一個正確的認識。，我們才能夠更加有效、高效的使用工具，才能夠使測試真正起到它應有的作用。希望本文能夠對大家在進試方面的工作時有所幫助。參考文獻ExtremeProgrammingExplained:EmbraceChange，KentBeck，AgileSoftwareDevelopment,Principles,Patterns,andPractices，RobertC.Martin，2002TestDrivenDevelopment:ByExample，KentBeck，2002Refactoring:ImprovingtheDesignofExistingCode，MartinFowler,KentBeck，1999TestingThingsThatSeemHardtoTest，RobertS.Koss，2001關于作者，軟件工程師，主要在OO、GenericProgramming?？梢酝ㄟ^dhui@263.net聯(lián)系到作者。，軟件工程師，目前在一個大型通信公司從事數(shù)據(jù)的開發(fā)，主要在Java和數(shù)據(jù)庫?？梢酝ㄟ^dhui@263.net聯(lián)系到作者?；垤`科技依慧靈科技依托測試時代資源，推出面向實踐的軟件測試專業(yè)課程，由國內著名軟件企業(yè)的一線技術專家主講，為您的企業(yè)解決實踐中的關鍵問題。如果您培訓的目的不是拿一個 ，而是想學習軟件測試的最佳實踐，那我們會是您一個不錯的選擇。登陸公 關于測試人員何時介入項目小組?應該說這不是一篇文章，這應該屬于是一個討論的話題吧，無論觀點是否正確，希望大家能夠在里面可以自己的見解。尤其在這方面深有感觸的朋友。提起這個話題的原因是因為現(xiàn)在一個項目里面測試人員的介入是到開發(fā)后期階段——編碼工作完成之后介入的，我認為很不合理，所以提出這個問題。從大的方面來考慮的話，現(xiàn)在流程的測試模型有三種：V模型，W模型，H模型。而在這三種模型里面，無論哪一種模型，測試的介入都是在軟件開發(fā)過程的前期介入的。測試工作在這時介入，無論從哪方面考慮，都比我們直到開發(fā)過程的后期才介入更有好處。從成本方面來看：前期介入也許增加了測試人員的成本，但是相對于后期的投入和項目的風險方面，這個成本顯然遠遠小于后期的投入，前期發(fā)現(xiàn)的Bug的修改代價比后期的修改代價了，如果把成本投入跟介入時間進行比較的話，那么應該可以得到如下的結論：介入時間越早，成本投入越小，反之越大。在需求調研階段，設計階段，編碼階段，測試階段，產品出貨階段我們都會發(fā)現(xiàn) bug，但是處理bug的代價在這幾個階段卻是截然不同的，越往后代價越高。做過項目的人應該都有體會的。從項目風險來看：如果把編碼階段作為嶺的話，編碼階段之前的工作為前期工作，編碼階段包括編碼之后的工作為后期工作。一個問題在開發(fā)過程的前期被發(fā)現(xiàn)，則可以很大程度上降低項目的風險問題，如果在后期發(fā)現(xiàn)一個問題，將不可避免地要面對項目風險問題。很多時候一個項目最后實施大部分都是在后期發(fā)現(xiàn)的問題所致的。當然這不是實施失敗的全部因素。從其他方面來考慮，都是前期介入比后期介入的情況好的。但是目前所遇到的情況是：等需求調研完成之后測試人員一起進行需求整理，這個時候我覺得很迷糊的一點就是測試人員都沒有參加過需求調研，讓測試人員進行需求調研整理，那不是需要重復一次工作嗎？很多問題測試人員還是要去問進行調研的人的。我覺得效率不是很高。而且經(jīng)過中間的一道程序很多時候會發(fā)生一種曲解需求的現(xiàn)象。所以測試人員的介入從有些方面來說還是值得一個項目小組的考慮的，不能只是從投入成本來考慮，而且如果要從成本方面考慮的話那么請考慮整個項目周期的成本。項目風險是項目必須面對的一個問題，而在這個問題上最重要的一個環(huán)節(jié)就是測試人員來進行把關的，當然有的公司在測試人員之后還有QA來負責質量的。其實關于這個話題要詳細展開的話不是三言兩語就可以說完的。今天只是有感而發(fā)。更何況有時候很多公司的規(guī)定都是不一樣的。有時候有些流程不一定往日的經(jīng)驗就是很好的總結，該改新的時候還是需要動手術的。一成不變只能固步自封。墨守成規(guī)只能停滯不前。我希望我們的測試人員不只是在程序員寫好程序之后直接把程序交付我們，并且附上一些應該算不上的但是并不很完整的文檔就交付成功了，然后我們按照流程說明進行鍵盤輸入，鼠標點擊的動作。我希望我們能更早的介入到項目當中。了解，做到，同時也學到。不要當一個廉價的可有可無的角色。那是其實有時候覺得測試也可以進行分階段，比如需求調研時候了解需求，然后等開發(fā)人員進行設計時候我們對需求進行剖解，然后提交代碼之后再開始執(zhí)試，中間可以根據(jù)需求和設計做很多測試計劃，測試設計策略等方面的事情，主要包括測試計劃，測試用例的設計，產出，并且準備相關測試數(shù)據(jù)。然后主要的一點就是要對自己進行的項目測試有一個很可觀，比較全面的測試風險等的評估。以下是幾個的跟帖，供大家參考不為：程序開發(fā)人員進行的是創(chuàng)造代碼的活動，所以，很多初級程序員在寫代碼之前很明白自己在要做什么，該怎么做。但是，當開始寫代碼時，隨著時間的流逝，目的就不再那么清晰了，也偏離了原先自己的思路，只是顧全自己的部分邏輯，而對整體的業(yè)務邏輯不是很清楚。所以，為了保證程序員的正確航向，測試人員應該在程序員寫代碼前，先寫出測試用例，因為測試人員關心的是代碼運行的結果是否符合用戶的業(yè)務流程以及是否實現(xiàn)了預定的目標。相對來說，測試人員比開發(fā)人員更了解用戶對軟件的需求。因為測試是面向業(yè)務流程的，而軟件開發(fā)是按模塊分工的。所以，我們的做法是，在調研用戶需求的時候，首先寫出測試用例，用來規(guī)范程序開發(fā)人員的工作范圍，使他們能在正確的道前進而不會偏離用戶需求太遠。當用戶需求變化時，測試人員更改用例，開發(fā)人員修改代碼，以通過用例為準。周舟：提到介入階段，做了這么多項目我倒以為這不是該有很嚴格界定的，也確實真的很難界定，因為不論是需求，設計，不變的都在變，甚至上線應用之后，用戶認為不滿意，那也還得再變。所以依據(jù)需求分析，概要設計寫出來的測試用例也很難一成不變。所以只要需求，設計都要變，測試就是有風險的。就算一切都是安裝需求和設計寫出來的，但那些不是用戶最終要求，最終就這樣白忙活了一場。我以為測試不論什么時候介入，了解和理解用戶的最終需求是必須和萬無一失并適合中國國情的。當然若是需求分析和設計能夠很好的了解和理解需求，那測試的工作到是可以減輕許多，并風險也會小很多。只要測試“實現(xiàn)的功能是否正確”就行了，而不必費心于“系統(tǒng)是否實現(xiàn)了正確的功能”的測試。逐漸的行業(yè)背景知識竟也成了對測試人員的一種竟聘要求。eveet：To:周舟,"逐漸的行業(yè)背景知識竟也成了對測試人員的一種競聘要求。"這句話正在被越來越多的企業(yè)應用到，不僅僅是測試知識，相關的行業(yè)背景知識也是很重要的，需求很難被固定，用例總是在改動，這都是很正常的。思考了很久，也真的很難總結出真正的一個介入的分水嶺。還是活學活用吧，根據(jù)自己的實際，不要脫離科學的軌跡。您是否對軟件測試的整體規(guī)劃一直比較模糊您是否對軟件測試的整體規(guī)劃一直比較模糊？您是否覺得軟件測試工作技術含量不高，不知道如何提高自己？您是否發(fā)覺測試用例的復用率非常低而且檢索困難？您是否覺得測試工作不太容易規(guī)劃，總是不如預期？您是否覺得性能測試很重要但是不知道如何組織和實施有效的性能測試？您是否非常想知道大型的企業(yè)級系統(tǒng)是如何進行性能規(guī)劃的？您是否想知道流行的測試工具的使用方法？ WEB下的整體測隨著Internet的日益普及，現(xiàn)在基于B/S結構的大型應用越來越多，可如何對這些應用進試成為日益迫切的問題。有許多測試人員來信問我B/S的測試如何做，由于工作較繁忙，對大家問題也是頭痛醫(yī)頭腳痛醫(yī)腳，沒有對WEB的測試過程做一個整體的概述。希望通過本篇能夠讓大家了解大型Web應用是如何來進試的。B/S下的功能測試比較簡單，關鍵是如何做能測試。目前大多數(shù)的測試人員認為只要跑一些測試工具證明我的產品是可以達到性能的就ok了，為了證明而去測試是沒有任何價值的，關鍵是要發(fā)現(xiàn)產品性能上的缺陷，定位問題，解決問題，這才是測試要做的。首先我們從兩個方面分析如何進行WEB測試，從技術實現(xiàn)上來講一般的B/S結構，無論是.NET還是J2EE,都是多層構架，有界面層，業(yè)務邏輯層，數(shù)據(jù)層。而從測試的流程上來說，首先是發(fā)現(xiàn)問題，分析問題，定位問題，再由開發(fā)人員解決問題。那么B/S的結構的測試如何來做？如何發(fā)現(xiàn)問題是我首先要介紹的，在做WEB測試之前你需要一些資料，比如產品功能說明書，性能需求說明書，不一定很完善，但一定要有，明確測試目標，這是基本的，可是我往往看到的是已經(jīng)開始動手測了，但還不知自己的系統(tǒng)要達到的性能指標是什么。這里我簡單講一下測試的性能指標：通用指標（Web應用服務器、數(shù)據(jù)庫服務器必需測試項）ProcessorTime:指服務器CPU占用率，一般平均達到70%時，服務就接近飽MemoryAvailableMbyte:可用內存數(shù)，如果測試時發(fā)現(xiàn)內存有變化情況也要注意，如果是內存則比較嚴重；PhysicsdiskTime:物理磁盤讀寫時間情況；Web服務器指標：AvgRps:平均每秒鐘響應次數(shù)＝總請求時間/Avgtimetolastbyteperterstion（mstes）:平均每秒業(yè)務角本的迭代次數(shù)有人會把這兩者SuccessfulRoundsFailedRoundsSuccessfulHits：成功的點擊次數(shù)；FailedHitsHitsPerSecondSuccessfulHitsPerSecondFailedHitsPerSecondAttemptedConnections：嘗試數(shù)數(shù)據(jù)庫服務器指標：User0ConnectionsNumberofdeadlocksButterCachehit：數(shù)據(jù)庫Cache中情況上面的指標只是一些通用的指標,起到拋磚引玉的作用，對于不同的應用你還必需作相應的調整，比如程序使用的是.NET技術的，則必需加入一些針對性的測試指標。對于這些指標的詳細了解，你可以參考Windows 下面的SystemMonitor的幫助與LoadRunner、ACT的幫助。對于發(fā)現(xiàn)問題，指標的設置非常重要，它會幫你定性的發(fā)現(xiàn)一些錯誤。對于定性的壓力測試我就不做過多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各個工具有它的使用范圍，其中我各個認為LoadRunner 最全面，它提供了多種協(xié)議的支持，對復雜的壓力測試都可以勝任，WAS與ACT則對微軟的技術支持的比較好，其中WAS 支持分布式機群測試,ACT 則是與.NET 集成比較好，支持ViewState（.NET下控件緩存的支持）的測試，當時我用時，其它測試工具還不支持，現(xiàn)在應該支持了吧，呵呵。在這一階段測試你要不斷的跟據(jù)系數(shù)的測各個子系統(tǒng)的性能目標必需明確，主要是并發(fā)指標定一個閥值，同時設定一些與系統(tǒng)相關的測試參數(shù)，應用服務器，數(shù)據(jù)庫服務器都要有，對達不到閥值的與一些通用參數(shù)有問題的子系統(tǒng)進行深入分析。比如它的并發(fā)達不到你的要求，證明子系統(tǒng)性能有問題，或是數(shù)據(jù)庫用戶連接過高，程序沒有釋放用戶連接等等。這個我們要對子系統(tǒng)進行詳細測試，由于B/S結構下,的請求對性能的影響較大，所以我們對子系統(tǒng)測試時要分兩個部分進行，一、非程序部分，即等等;二、應用程序本身。通過事務或函數(shù)的分離，可以把這兩塊實現(xiàn)單獨的測試，具體做法參考各個工具的手冊，我這里就不做說明。對子系統(tǒng)的測試參數(shù)的設置要求則更高，它有助你后面精確的定位問題，比如對異常，死鎖，網(wǎng)絡流量等等前面沒有注意到的情況的增加，同時你要注意增加測試參數(shù)的收集對系統(tǒng)的性能影響比較大，所以一般不要超過10個，剛剛介紹的整體的性能測試指標也不要增加很多，這樣影響會小一點。最后在這一階段要說明的是數(shù)據(jù)庫的數(shù)據(jù)量會很大程度的影響性能，所以要根據(jù)前面的性能需求說明書向數(shù)據(jù)庫中模擬相應的數(shù)據(jù)量，來進試，這樣才有更高的可信度。上面所說的是對問題的發(fā)現(xiàn)，下面就是分析問題原因，這一步的要求比較高，一般由測試人員與程序員配合完成，當然如果你有相當?shù)拈_發(fā)經(jīng)驗，再做這方面的測試，就更為難得。下面我們說說如何精確定位問題，出現(xiàn)問題的可能性可能有很多種，大致分以下幾種，一、性能達不到目標；二、性能達到目標，但有一些其它的問題，比如異常，死鎖，緩存命中過低，網(wǎng)絡流量較大；三、服務器穩(wěn)定性的問題，比如內存泄漏……。要發(fā)現(xiàn)這些問題起馬的要求要有一款使用的比較稱心的性能分析與優(yōu)化工具，比如微軟的.NET下就有自己開發(fā)的工具，對Borland的Java開發(fā)工具中也有類似的工具，但我個人認為更好的工具是Rose下的Purify與f,主要是他對.net與java,C++都有支持，而且分析效果特別專業(yè)，我們先了解一下RationalPurif,RationalPurify能自動找出isualC/C++和Java代碼中與內存有關的錯誤，確保整個應用程序的質量和可靠性。在查找典型的isualC/C++程序中的傳統(tǒng)內存錯誤，以及Java，C#代碼中與內存收集相關的錯誤方面；Rationalty則是一款針對函數(shù)級的性能分析利器，使用它你可以從圖形化的界面中得到函數(shù)調用的時間，百分比與次數(shù)，以及子函數(shù)所占時間，使你可以更快的定位性能瓶頸。我們先說性能優(yōu)化與異常的處理，性能優(yōu)化有一個原則，即用時間比例最大的進行優(yōu)化，效果才最明顯，比個函數(shù)它的執(zhí)行時間為30秒，優(yōu)化了一百倍則執(zhí)行時間為0.3秒,提升了2.7秒，而如果它的執(zhí)行時間為03秒，優(yōu)化后為0.003秒，0.297秒，而且寫過程序的人都知道，后者性能優(yōu)化的代價更大。在性能優(yōu)化的過程中，一般是先數(shù)據(jù)庫，后程序，因為數(shù)據(jù)庫的優(yōu)化不需要修改程序，修改的風險很小。但如何才能確定是數(shù)據(jù)庫的問題，這就需要技巧，在使用ty時，你一路分析下去，大多數(shù)最終會發(fā)現(xiàn)，是數(shù)據(jù)庫查詢函數(shù)占用時間比較大，比如什么，SqlCd.ExecuteNoQuery等等數(shù)據(jù)庫執(zhí)行函數(shù),這時你就需要分析數(shù)據(jù)庫，呵呵。數(shù)據(jù)庫的分析原則是先索引，后過程，最后表結構視圖的優(yōu)化，索引的優(yōu)化是最簡單也是通常最有效的方法，如果合理的使用會帶來意想不到不到的效果。在這里我要給大家簡單的介紹一下我的最愛，SQLProfile,SQL查詢分析器，Precise,SQLProfile是一個SQL語句，可以程序流程使用的SQL語句與過程，結合查詢分析器對SQL的分析，可以對索引的優(yōu)化做出很好的判斷，但索引也不是萬能的，在增刪改較多的表，索引過多會引起這些操作的性能下降，所以判斷還是需要一定的經(jīng)驗。同時針對用戶使用頻度最高的SQL進行優(yōu)化也是最行之有效的，這時我則需要Precise，它可以觀測某一個較長時間內的SQL語句的執(zhí)行情況。數(shù)據(jù)庫優(yōu)化的潛能挖光后，如果還是達不到性能要求或是還有問題，則要從程序來進行優(yōu)化，這是程序員做的事，測試人員要做的，就是們，哪個函數(shù)執(zhí)行過多引起了性能下降，比如異常過多，某個循環(huán)過多，或是DCOM調用過多等等，但說服程序員也是一件不容易的事，你要在這一階段做的出色一定要有幾年的編程經(jīng)驗，并且要讓程序員感到聽你的性能會有提升，這是一件很不容易的事情哦。內存的分析，一般是一個長期分析的過程，要做好不容易，首先要有長期奮戰(zhàn)的準備，其次內存泄漏的分析最好是放在單元測試之中同步進行，而不是要等到最后再去發(fā)現(xiàn)問題，當然出了問題也只好面對，一般這類問題都是在服務器運行了很久才出來，一旦發(fā)現(xiàn)問題后，則需要定位問題，分析的原則采用子系統(tǒng)相互獨立運行，找到最小問題的系統(tǒng)集,或是借助內存分析工具觀察內存對象情況，初步定位問題，再用rfy進行運行時分析，通常++內存問題比較多，aa與.NET比較少，一般由C不合理引起。++的內存錯誤就比較多了，主要常見的有:1、ArrayBoundsRead(ABR)：數(shù)組越界讀2、ArrayBoundsWrite(ABW)：數(shù)組越界寫3、BeyondstackReadBSR)：堆棧越界讀4、FreeMemoryRead(FMR)：空閑內存讀5、InvalidpointerRead(IPR)：指針閱讀6、NullPointerRead(NPR)：空指針閱讀7、UninitializedMemoryRead(UMR)8、MemoryLeak注：如果需要的信息，可以參見Purify的幫助信息順便提一句，為什么我要說單元測試時做這個比較好，由于單元測試針對的是單能，這時結合單元測試案例做內存分析會更快的定位問題，同時由于問題較早的發(fā)現(xiàn)，則后期的風險則會減少，當然如果結合代碼覆蓋工具ureovage來做就更完美了，呵呵。完成此文，已經(jīng)是凌晨了，也算是回答了前一段時間提出要進行BS結構測試又無從下手的朋友的要求，在這里要向大家表達一下歉意，由于工作比較忙，難免對大家的來信有所疏漏，請大家原諒。此文的要求的讀者，對測試工具有所了解，希望進入更深測試的同仁，希望我的文章給大家?guī)韼椭?同時也借此文表達一些曾經(jīng)幫助過我的朋友與同事。注：本篇只是對B/S應用的測試過程作一個整體的描述，對某一個階段使用的工具只是作大概的介紹,你也可使用你比較熟悉的工具達到相同的目標。淺談ClearQuest建庫指運行前提

作者：Windows2000 服務器上已經(jīng)安裝RationalClearQuest 版Windows2000Server服務器上已經(jīng)安裝SQLServerWindows2000Server+SQLServer上建立空的數(shù)據(jù)庫先在SQLServer上建立一個空的數(shù)據(jù)庫，建庫時請注意給ClearQuest的主數(shù)據(jù)庫(SchemaRepository)數(shù)據(jù)文件分配至少50M的空間。如圖一所示：為ClearQuest主數(shù)據(jù)庫建立專門的用戶。注意：不要使用SA作為ClearQuest數(shù)據(jù)庫的Owner,這是因為當你將來要進行更新或遷移ClearQuest主數(shù)據(jù)庫時，ClearQuest將會向SQLServer請求一個空的數(shù)據(jù)庫。可是，如果以SA用戶登錄ClearQuest主數(shù)據(jù)庫時，因為SA可以到系統(tǒng)表，故在遷移或更新ClearQuest主數(shù)據(jù)庫時將不能夠繼續(xù)進行。建立ClearQuest專門的登錄用戶步驟可見圖二和圖三.ClearQuest用戶必須使用SQLServer的驗證，同時將默認的數(shù)據(jù)庫設置為ClearQuest.使用MaintenanceToolClearQuest的主數(shù)據(jù)庫ClearQuestMaintenanceTool,從菜單上選擇“Connection->New”來建立一個ClearQuest的主數(shù)據(jù)庫（schemarepository），即保存你定義的各種方案。如圖四:接下來我們需要在SQLServer2000服務器上建立ClearQuest服務器。當然如果你選擇ACCESS數(shù)據(jù)庫直接按回車即可。當你在Vendor:中選擇SQLServer后(見圖五)，將會出現(xiàn)有關與SQLServer服務器連接的信息設置。具體設置如圖六:可以通過右鍵改變CQ主數(shù)據(jù)庫名，我們可以將其命名為上次有個網(wǎng)友問我：“HTTP,當使用Read-OnlyUser我怎么也連接不到數(shù)據(jù)庫中”。當時我試了多種方法也仔細查過相關資料，只能通過其DBOwner才可連通。如果使用只有[讀]權限的用戶會失敗的，不知道其它人是如何解決此問題的？有人知道有勞通知大家。：）不過在使用過程中沒有較大的影響，如果是在2002.05以前的版本時，使用時會存在一些安全，因為必竟DBOwner的權限過大些。呵呵，事在人為嘛。接下來CQMaintenanceTool將會顯示建立CQ主數(shù)據(jù)庫的過程，按提示點擊確定即可。到此為止CQ的主數(shù)據(jù)庫即大功告成了。接下來進行如何在ClearQuestDesigner中建立各種方案(Schema)。4、使用CQDesigner建立各種方案(Schema)當你運行ClearQuestDesigner時，會出現(xiàn)請你選擇使用哪個CQ主數(shù)據(jù)庫，我們在這里選擇上面建立的:MyTest.在這里請注意，我們說明界面均是CQ2002.05版，以前的版本界面不是這樣的。如圖七:第一次運行ClearQuestDesigner時,請使用用戶為：Admin為：空，登陸進入到ClearQuestDesigner中.此處的用戶不同于主數(shù)據(jù)庫的用戶.Designer中的用戶是用來在使用你設計的方案時所需的用戶,由Designer自已的用戶管理器創(chuàng)建.并為其分配相關的數(shù)據(jù)庫權限.當你在Designer中建立數(shù)據(jù)庫時,前提是你必需在SQLServer上建立好一個空的數(shù)據(jù)庫,同時為此庫建立自已獨立的DBOwner.然后才可運行Designer進行建立方案.當進入CQDesigner后，首先彈出的窗體為CQ中向你提供的八個應用方案.你可以根據(jù)自已的應用情況選擇合適的方案，當然可以自已完全定制一個方案，關鍵是看你對CQ的了解程度。我建議先自已學習它提供的方案，然后自已動手定制一個完全符合自已的應用方案。因為CQ中提供的方案一般與Rational的其它產品結合較為緊密，許多功能我們暫時用不上，沒有必要花很大的力氣了解它，路要一步步走嘛。在此我們以CQ提供的”DefectTracking”方案為例，建立一個自已的方案步驟。如圖八：進入CQDesigner后，先取消圖八的窗體。然后在CQDesigner的主菜單上選擇”Database→NewDatabase”項。將出現(xiàn)如圖九所示窗體，即為建立方案庫的第一步。該窗體中的LogicalDatabaseNameCQDesigner管理各種方案而使用的一種邏輯庫，在CQDesigner中使用這些邏輯庫來進行方案的刪除，恢復刪除和更新.這里的邏輯庫并不是你在SQLServer建立的表。點擊[下一步]后,進入建立方案庫的第二步；將出現(xiàn)連接你已經(jīng)在連接數(shù)據(jù)庫的用戶必須是該空表的DBOwner/寫的用戶仍連接不成功。原因同上面我說的，待查。：（在最下的請選擇ProductionDatabase，它代表此方案用于實際應用，而并非專為測試方案----TestDatabase使用。有關測試方案庫我們會在以后再講。在圖十上點擊[下一步]將進入建立方案庫的第三步,即為方案定制超時設置。一般情況下可以為默認值。再點擊[下一步]為建立方案庫最后一步，在CQ提供的方案模板中選擇我們要創(chuàng)建的“DefectTracking”方案。如圖十一所示：最后點擊[完成]按鈕，拿一杯熱茶等著吧，如果一切順利將會出現(xiàn)”Databasewascreatedsuccessfully”框。恭喜你成功了!想進一步驗證，可以通過ClearQuest客戶端來進行，動行ClearQuset,在其出現(xiàn)的首個框中選擇你剛才建立的方案，使用管理員進入后便可進行其應用了。aonalaQuest功能很強大，以后有機會我們大家多交流，寫出更好的使用經(jīng)驗點滴，希望我這陋文能起到拋磚引玉的作用。同時也希望能與大家交流使用經(jīng)驗. 43《單元測試技術――Nunit3《測試管理――TD》2《自動測試工具――Robot2《自動測試工具――LoadRunner2關注性能：壓力負載壓力測試和負載測試

來源在性能列表中最常問的問題是：“是否有一種工具可以幫助我對J2EE應用程序進行壓力測試？”在回答這個問題之前，讓我們問一問自己：壓力測試是什么，為什么這些開發(fā)人員需要它？（我相信中相當一部分人曾經(jīng)遇到一定要在昨天完成測試這種感到壓力的情況，但是我們在這里說的不是這個）。壓力測試是為了發(fā)現(xiàn)在什么條件下您的應用程序的性能會變得不可接受。這通過改變應用程序的輸入以對應用程序施加越來越大的負載并測量在這些不同的輸入時性能的改變來實現(xiàn)的。這種操作也稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試——增加用戶數(shù)量以對應用程序進行壓力測試。對應用程序進行壓力測試最簡單的方法是手工改變輸入（客戶機數(shù)量、需求大小、請求的頻率、請求的混合程度，等等）并描繪性能的變化。對于一些應用程序，您需要做的就是這些。但是如果有許多輸入，或者需要在大的范圍內改變輸入，那么就可能需要一個自動化的工具。另外，在手工測試中，如果想在進行一些改變后重新測試應用程序，可能很難精確地重復一組測試。如果是讓多個用戶測試您的應用程序，那么幾乎不可能一致性地運行手工測試，除非您有很多失業(yè)的朋友，否則擴大測試應用程序的用戶數(shù)量是非常的。沒有一刀切的方案不幸的是，沒有一種通用的壓力測試工具，因為每一個應用程序所接受的輸入以及對它們進行處理的方式都是不同的。但是對于許多J2EE應用程序來說，從客戶機到達服務器的通信使用的是HTTP協(xié)議。幸運的是，有許多負載測試工具可以以一種可控制和重復的方式模擬HTTP上的用戶活動。它們包括免費工具如ApacheJMeter、TheGrinder以及PushToText，和相當昂貴的工具如MercuryAstraload。一般來說一分錢一分貨——工具越貴，它能做的事情就越多。為了了解它們的差別，我們運行一個線程的程序。每一個線程需要與服務器通信，可能使用 .URL類。這種方法使您得到基本的HTTP客戶機模擬，它可以執(zhí)行GET和PUT。每個線程需要做的就是發(fā)送HTTP請求、收集回復、等待一些時間（復。這一組行動可以相當容易地抽象到一個單獨的配置文件中。很快，您就得到一個基本的負載測試工具。您可能需要增加一些配置選項以確定運行多少個線程（模擬的客戶機）以及它們是同時開始還是慢慢增加負載。當然，您需要對與服務器的交互計時，因為這是您要測試的內容。如果這么簡單…那么，對于處理擴展的交互（即一個請求取決于上一個請求的結果）如何呢？對于處理 s如何呢？ s對于許多面向會話的J2EE系統(tǒng)是必不可少的。改變數(shù)據(jù)輸入呢？如果J2EE應用程序客戶機需要處理一些JavaScript以進入下一次通信呢？在收集了響應時間數(shù)據(jù)后，如何對它進行分析？其他類型的監(jiān)視，如CPU時間、網(wǎng)絡使用、堆大小、分頁活動或者數(shù)據(jù)庫活動呢？像這樣和其他的功能，如用于記錄瀏覽器會話并將它們加入到測試中的工具，是高端負載測試工具與基本工具的差別所在。如何為自己選擇正確的工具呢？當然，這取決于您的需要、您的計劃和您的預算。最重要的是，您需要使用可以正確地模擬您的應用程序要求的客戶瀏覽器功能的工具。具備了基本功能后，可以考慮工具的生產率。一般來說，包含的分析工具越多，可以記錄的性能數(shù)據(jù)類型越多，您可以達到的生產率就越高——您愿意付的錢也就越多。頂級的負載測試程序可以模擬多個瀏覽器，與大多數(shù)應用服務器集成，收集多個服務器主機的性能數(shù)據(jù)（包括操作系統(tǒng)、JVM和數(shù)據(jù)庫統(tǒng)計數(shù)字，生成可以在以后用高級的分析工具分析的數(shù)據(jù)集。另一方面，負載測試程序是免費的。在那些預算有限的日子里，“免費”的意義是不言自明的。圖1展示了免費的負載測試程序ApacheJMeter，它顯示了一個自動記錄的圖1.JMeter顯示一個自動記錄的我們已經(jīng)看過了壓力測試工具的基本功能，還適合增加什么附加功能呢？不同的負載測試工具的區(qū)別在什么地方呢？當然，您最主要的要求是這個工具必須可以模擬您的應用程序客戶機。如果您的應用程序使用一些不常見的瀏覽器功能組合或者其他非標準客戶機技術，那么就排除了相當一部分候選者。除此之外，還有其他功能使負載測試的生產率更高。對于決定適合于自己項目的負載測試工具，下面的列表是一個有用的出發(fā)點：模擬您的客戶機首要要求一定是負載測試程序能夠處理您的應用程序所使用的功能和協(xié)議。運行多個模擬的客戶機這是負載測試程序最基本的功能，它有助于確定哪些是負載測試程序以及哪些不是（一些框架試圖成負載測試程序?；瘓?zhí)行并能編輯如果不能編寫客戶機與服務器之間交互的，那么就不能處理除最簡單的客戶機之外的任務東西。編輯的能力是最基本的——小的改變不應該要求您重新生成。支持會話負載測試程序如果不支持會話或者 s，那么就不算是真正的負載測試程序，并且不能對大多數(shù)J2EE應用程序進行負載測試。可配置的用戶數(shù)量測試程序應該可以指定每個由多少個模擬用戶運行，包括隨時間改變模擬用戶的數(shù)量，因為許多負載測試應該從小的用戶數(shù)量開始，并慢慢增加到的用戶數(shù)量。報告成功、錯誤和失敗每一個都必須定義一個方法來識別成功的交互以及失敗和錯誤模式（錯誤完全不會有頁面返回，而失敗可能在頁面上得到錯誤的數(shù)據(jù)。頁面顯示如果負載測試程序可以檢查一些發(fā)送給模擬用戶的頁面，這會很有用，這樣您就可以確保測試工作是正確進行的。導出結果您常常希望可以用不同的工具來分析，這些工具包括電子表格和可以處理數(shù)據(jù)的自定義。雖然許多負載測試工具包括大量的分析功能，但是導出數(shù)據(jù)的能力使您在以任意的方式分析和編目數(shù)據(jù)方面具有更大的靈活性?？紤]時間真實世界的用戶不會在收到一頁后立即請求另一頁——一般在查看一頁和下一頁之間會有延遲。考慮時間這個標準術語表示在中加入延遲以更真實地模擬用戶行為。大多數(shù)負載測試程序支持根據(jù)統(tǒng)計分布隨機生成考慮時客戶機從列表中選擇數(shù)據(jù)用戶一般不會使用同樣的一組數(shù)據(jù)，每位用戶通常與服務器進行不同的交互。模擬用戶應該也這樣做，如果在交互的關鍵點，可以從一組數(shù)據(jù)中選擇數(shù)據(jù)，則可以更容易地的模擬用戶表現(xiàn)出使用不同數(shù)據(jù)的行為。從手工執(zhí)行的會話記錄相對于編寫，用瀏覽器手工運行會話并記錄這個會話然后再編輯會容易得多。一些應用程序大量使用JavaScript并且需要模擬客戶機支持它。不過，使用客戶端JavaScript可能會增加對測試系統(tǒng)上系統(tǒng)資源的需求。分析工具測量性能只是成功的一半。另一半是分析性能數(shù)據(jù)。誰能比編寫測試工具的人能更好地開發(fā)這種分析工具呢？是的，至少理論是這樣。無論如何，您的工具箱提供的分析工具越多，您就能做得越好。測量服務器端統(tǒng)計數(shù)字基本負載測試程序測量客戶機/服務器交互中基于客戶機的響應時間。如果同時收集其他統(tǒng)計數(shù)字，如CPU使用情況和頁面錯誤率就更好了。您得到的統(tǒng)計數(shù)字越多，您用負載測試系統(tǒng)可以做的就越多。如果有這種數(shù)據(jù)，那么就可以做一些有用的工作，如查看服務器負載上下文中的客戶機響應時間和吞吐量統(tǒng)計。結束語用任何一種工具可以完成的工作常常受到人的技能、知識和想像力的局限。在描述用負載測試工具查看什么內容的時候，我們也展示了使用這種工具的各種可能性。現(xiàn)在，您可以運用您的想像力去開拓的可能性。性能測試：軟件測試的重之作者：中國軟件評測中心性能測試在軟件的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟件評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網(wǎng)絡上性能的測試和應用在服務器端性能的測試。通常情況下，面有效、合理的結合，可以達到對系統(tǒng)性能全面的分析和瓶頸的預測。應用在客戶端性能的測試應用在客戶端性能測試的目的是客戶端應用的性能，測試的是客戶端。它主要包括并發(fā)性能測試、疲勞強度測試、大數(shù)據(jù)量測試和速度測試等，其中并發(fā)性能測試是重點。并發(fā)性能測試是重點并發(fā)性能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到系統(tǒng)的瓶頸或者不能接收的性能點，通過綜合分析交易執(zhí)行指標和資源指標來確定系統(tǒng)并發(fā)性能的過程。負載測試（LoadTesting）是確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)組成部分的相應輸出項，例如通過量、響應時間、CPU負載、內存使用等來決定系統(tǒng)的性能。負載測試是一個分析軟件應用程序和支撐架構、模擬真實環(huán)境的使用，從而來確定能夠接收的性能過程。壓力測試（StressTesting）是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。并發(fā)性能測試的目的主要體現(xiàn)在三個方面：以真實的業(yè)務為依據(jù)，選擇有代表性的、關鍵的業(yè)務操作設計測試案例，以評價系統(tǒng)的當前性能；當擴展應用程序的功能或者新的應用程序將要被部署時，負載測試會幫助確定系統(tǒng)是否還能夠處理期望的用戶負載，以預測系統(tǒng)的未來性能；通過模擬成百上千個用戶，重復執(zhí)行和運試，當一家企業(yè)自己組織力量或委托軟件公司代為開發(fā)一套應用系統(tǒng)的時候,尤其是以后在生產環(huán)境中實際使用起來用戶往往會產生疑問,這套系統(tǒng)能不能承受大量的并發(fā)用戶同時訪問?這類問題最常見于采用聯(lián)機事務處理(OLTP)方式數(shù)據(jù)庫應用、Web瀏覽和點播等系統(tǒng)。這種問題的解決要借助于科學的軟件測試和先進的測試工具。舉例說明：電信計費軟件眾所周知,每月20日左右是市話交費的期，全市幾千個網(wǎng)點同時啟動。過程一般分為兩步,首先要根據(jù)用戶來查詢出其當月產生費用,然后收取現(xiàn)金并將此用戶修改為已交費狀態(tài)。一個用戶看起來簡單的兩個步驟,但當成百上千的終端，同時執(zhí)行這樣的操作時，情況就大不一樣了,如此眾多的交易同時發(fā)生,對應用程序本身、操作系統(tǒng)、中心數(shù)據(jù)庫服務器、中間件服務器、網(wǎng)絡設備的承受力都是一個嚴峻的考驗。決策者不可能在發(fā)生問題后才考慮系統(tǒng)的承受力,預見軟件的并發(fā)承受力,這是在軟件測試階段就應該解決的問題。目前，大多數(shù)公司企業(yè)需要支持成百上千名用戶，各類應用環(huán)境以及由不同供應商提供的元件組裝起來的復雜產品，難以預知的用戶負載和愈來愈復雜的應用程序，使公司擔憂會發(fā)生投放性能差、用戶反應慢、系統(tǒng)失靈等問題。其結果就是導致公司收益的損失。如何模擬實際情況呢?找若干臺電腦和同樣數(shù)目的操作人員在同一時刻進行操作,然后拿秒表記錄下反應時間？這樣的手工作坊式的測試方法不切實際，且無法捕捉程序內部變化情況,這樣就需要壓力測試工具的輔助。測試的基本策略是自動負載測試，通過在一臺或幾臺PC機上模擬成百或上千的虛擬用戶同時執(zhí)行業(yè)務的情景，對應用程序進試，同時記錄下每一事務處理的時間、中間件服務器峰值數(shù)據(jù)、數(shù)據(jù)庫狀態(tài)等。通過可重復的、真實的測試能夠徹底地度量應用的可擴展性和性能，確定問題所在以及優(yōu)化系統(tǒng)性能。預先知道了系統(tǒng)的承受力,就為最終用戶規(guī)劃整個運行環(huán)境的配置提供了有力的依據(jù)。并發(fā)性能測試前的準備工作測試環(huán)境：配置測試環(huán)境是測試實施的一個重要階段，測試環(huán)境的適合與否會嚴重影響的真實性和正確性。測試環(huán)境包括硬件環(huán)境和軟件環(huán)境，硬件環(huán)境指測試必需的服務器、客戶端、網(wǎng)絡連接設備以及/掃描儀等輔助硬件設備所構成的環(huán)境；軟件環(huán)境指被測軟件運行時的操作系統(tǒng)、數(shù)據(jù)庫及其他應用軟件構成的環(huán)境。一個充分準備好的測試環(huán)境有三個優(yōu)點：一個穩(wěn)定、可重復的測試環(huán)境，能夠保證測試結果的正確；保證達到測試執(zhí)行的技術需求；保證得到正確的、可重復的以及易理解的。測試工具：并發(fā)性能測試是在客戶端執(zhí)行的黑盒測試，一般不采用手工方式，而是利用工具采用自動化方式進行。目前，成并發(fā)性能測試工具有很多，選擇的依據(jù)主要是測試需求和性能價格比。著名的并發(fā)性能測試工具有QALoad、LoadRunner、BenarkFactory和Webstress等。這些測試工具都是自動化負載測試工具，通過可重復的、真實的測試，能夠徹底地度量應用的可擴展性和性能，可以在整個開發(fā)生命周期、多種平臺、自動執(zhí)試任務，可以模擬成百上千的用戶并發(fā)執(zhí)行關鍵業(yè)務而完成對應用程序的測試。測試數(shù)據(jù)：在初始的測試環(huán)境中需要輸入一些適當?shù)臏y試數(shù)據(jù)，目的是識別數(shù)據(jù)狀態(tài)并且驗證用于測試的測試案例，在正式的測試開始以前對測試案例進行調試，將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環(huán)節(jié)時，非常有必要進行數(shù)據(jù)狀態(tài)的備份。制造初始數(shù)據(jù)意味著將合適的數(shù)據(jù)下來，需要的時候恢復它，初始數(shù)據(jù)提供了一個基線用來評估測試執(zhí)行的結果。求對應的數(shù)據(jù)庫和表中有相當?shù)臄?shù)據(jù)量以及數(shù)據(jù)的種類應能覆蓋全部業(yè)務。模擬真實環(huán)境測試，有些軟件，特別是面向大眾的商品化軟件在測試時常常需要在真實環(huán)境中的表現(xiàn)。如測試殺毒軟件的掃描速度時，硬盤上布置的不同類型文件的比例要盡量接近真實環(huán)境，這樣測試出來的數(shù)據(jù)才有實際意義。并發(fā)性能測試的種類與指標并發(fā)性能測試的種類取決于并發(fā)性能測試工具的對象，以QALoad自動化負 WinSock、WWW、JavaScript等不同的對象，支持Windows和UNIX測試環(huán)境。最關鍵的仍然是測試過程中對對象的靈活應用，例如目前三層結構的運行模式廣泛使用，對中間件的并發(fā)性能測試作為問題被提到議事日程上來，許多系統(tǒng)都采用了國產中間件，選擇JavaScript對象，手工編寫腳本，可以達到測試目的。采用自動化負載測試工具執(zhí)行的并發(fā)性能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例制定，測試環(huán)境準備，測試錄制、編寫與調試，腳本分配、回放配置與加載策略，測試執(zhí)行，結果分析與定位問題所在，測試報告與測試評估。并發(fā)性能測試的對象不同，測試的主要指標也不相同，主要的測試指標括交易處理性能指標和UNIX資源。其中，交易處理性能指標包括交易結果、每分鐘交易數(shù)、交易響應時間（Min：最小服務器響應時間；Mean：平均服務器響應時間；Max：最大服務器響應時間；StdDev：事務處理服務器響應的偏差，值越大，Median：中值響應時間；9090％事務處理的服務器響應時間、虛擬并發(fā)用戶數(shù)。應用實例：“多數(shù)據(jù)庫V1.0”性能測中國軟件評測中心（CSTC）根據(jù)技術局《多數(shù)據(jù)庫（一期）性能測試需求》和GB/T17544《軟件包質量要求和測試》的，使用工業(yè)標準級負載測試工具對使用的“多數(shù)據(jù)庫V1.0”進行了性能測試。性能測試的目的是模擬多用戶并發(fā) 多數(shù)據(jù)庫，執(zhí)行關鍵檢索業(yè)務，分析系統(tǒng)性能。性能測試的重點是針對系統(tǒng)并發(fā)壓力負載較大的主要檢索業(yè)務，進行并發(fā)測試和疲勞測試，系統(tǒng)采用B/S運行模式。并發(fā)測試設計了特定時間段內分別在中文庫、英文庫、庫中進行單檢索詞、多檢索詞以及變檢索式、混合檢索業(yè)務等并發(fā)測試案例。疲勞測試案例為在中文庫中并發(fā)用戶數(shù)200，進試周期約8小時的單檢索詞檢索。在進行并發(fā)和疲勞測試的同時，監(jiān)測的測試指標包括交易處理性能以及UNIX（Linux、Oracle、Apache資源等。測試結論：在機房測試環(huán)境和內網(wǎng)測試環(huán)境中，100M帶寬情況下，針對規(guī)定的各并發(fā)測試案例，系統(tǒng)能夠承受并發(fā)用戶數(shù)為200的負載壓力，最大交易數(shù)/分鐘達到78.73，運行基本穩(wěn)定，但隨著負載壓力增大，系統(tǒng)性能有所衰減。系統(tǒng)能夠承受200并發(fā)用戶數(shù)持續(xù)周期約8通過對系統(tǒng)UNIX（Linux、Oracle和Apache資源的，系統(tǒng)資源能夠滿當并發(fā)用戶數(shù)超過200時，到HTTP500、connect和超時錯誤，且Web服務器報內存溢出錯誤，系統(tǒng)應進一步提高性能，以支持更大并發(fā)用戶數(shù)。疲勞強度與大數(shù)據(jù)量測試疲勞測試是采用系統(tǒng)穩(wěn)定運行情況下能夠支持的最大并發(fā)用戶數(shù)，持續(xù)執(zhí)行一段時間業(yè)務，通過綜合分析交易執(zhí)行指標和資源指標來確定系統(tǒng)處理最大工作量強度性能的過程。疲勞強度測試可以采用工具自動化的方式進試，也可以手工編寫程序測試，其中后者占的比例較大。一般情況下以服務器能夠正常穩(wěn)定響應請求的最大并發(fā)用戶數(shù)進行一定時間的疲勞測試，獲取交易執(zhí)行指標數(shù)據(jù)和系統(tǒng)資源數(shù)據(jù)。如出現(xiàn)錯誤導致測試不能成功執(zhí)行，則及時調整測試指標，試是對當前系統(tǒng)性能的評估，用系統(tǒng)正常業(yè)務情況下并發(fā)用戶數(shù)為基礎，進行一定時間的疲勞測試。大數(shù)據(jù)量測試可以分為兩種類型：針對某些系統(tǒng)、傳輸、統(tǒng)計、查詢等業(yè)務進行大數(shù)據(jù)量的獨立數(shù)據(jù)量測試；與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數(shù)據(jù)量測試方案。大數(shù)據(jù)量測試的關鍵是測試數(shù)據(jù)的準備，可以依靠工具準備測試數(shù)據(jù)。速度測試目前主要是針對關鍵有速度要求的業(yè)務進行手工測速度，可以在多次測試的基礎上求平均值，可以和工具測得的響應時間等指標做對比分析。應用在網(wǎng)絡上性能的測試應用在網(wǎng)絡上性能的測試重點是利用成熟先進的自動化技術進行網(wǎng)絡應用性能、網(wǎng)絡應用性能分析和網(wǎng)絡預測。網(wǎng)絡應用性能分析網(wǎng)絡應用性能分析的目的是準確展示網(wǎng)絡帶寬、延遲、負載和TCP端口的變化是如何影響用戶的響應時間的。利用網(wǎng)絡應用性能分析工具，例如ApplicationExpert，能夠發(fā)現(xiàn)應用的瓶頸，我們可知應用在網(wǎng)絡上運行時在每個階段發(fā)生的應用行為，在應用線程級分析應用的問題?？梢越鉀Q多種問題：客戶端是否對數(shù)據(jù)庫服務器運行了不必要的請求？當服務器從客戶端接受了一個查詢，應用服務器是否花費了不可接受的時間聯(lián)系數(shù)據(jù)庫服務器？在投產前預測應用的響應時間；利用ApplicationExpert調整應用在廣域網(wǎng)上的性能；ApplicationExpert能夠讓你快速、容易地仿真應用性能，根據(jù)最終用戶在不同網(wǎng)絡配置環(huán)境下的響應時間，用戶可以根據(jù)自己的條件決定應用投產的網(wǎng)絡環(huán)境。網(wǎng)絡應用性能在系統(tǒng)試運行之后，需要及時準確地了解網(wǎng)絡上正在發(fā)生什么事情；什么應用在運行，如何運行；多少PC正在LAN或AN；哪些應用程序導致系統(tǒng)瓶頸或資源競爭，這時網(wǎng)絡應用性能以及網(wǎng)絡資源管理對系統(tǒng)的正常穩(wěn)定運行是非常關鍵的。利用網(wǎng)絡應用性能工具，可以達到事半功倍的效果，在這方面我們可以提供的工具是Networkantage。通俗地講，它主要用來分析關鍵應用程序的性能，定位問題的根源是在客戶端、服務器、應用程序還是網(wǎng)絡。在大多數(shù)情況下用戶較關心的問題還有哪些應用程序占用大量帶寬，哪些用戶產生了最大的網(wǎng)絡流量，這個工具同樣能滿足要求。網(wǎng)絡預測考慮到系統(tǒng)未來發(fā)展的擴展性，預測網(wǎng)絡流量的變化、網(wǎng)絡結構的變化對用戶系統(tǒng)的影響非常重要。根據(jù)規(guī)劃數(shù)據(jù)進行預測并及時提供網(wǎng)絡性能預測數(shù)據(jù)。我們利用網(wǎng)絡預測分析容量規(guī)劃工具PREDICTOR可以作到：設置服務水平、完成日網(wǎng)絡容量規(guī)劃、離線測試網(wǎng)絡、網(wǎng)絡失效和容量極限分析、完成日常故障診斷、預測網(wǎng)絡設備遷移和網(wǎng)絡設備升級對整個網(wǎng)絡的影響。從網(wǎng)絡管理軟件獲取網(wǎng)絡拓撲結構、從現(xiàn)有的流量軟件獲取流量信息（若沒有這類軟件可人工生成流量數(shù)據(jù)，這樣可以得到現(xiàn)有網(wǎng)絡的基本結構。在基本結構的基礎上，可根據(jù)網(wǎng)絡結構的變化、網(wǎng)絡流量的變化生成報告和圖表，說明這些變化是如何影響網(wǎng)絡性能的。PREDICTOR提供如下信息：根據(jù)預測的結果幫助用戶及時升級網(wǎng)絡，避免因關鍵設備超過利用閥值導致系統(tǒng)性能下降；哪個網(wǎng)絡設備需要升級，這樣可減少網(wǎng)絡延遲、避免網(wǎng)絡瓶頸；根據(jù)預測的結果避免不必要的網(wǎng)絡升級。應用在服務器上性能的測試對于應用在服務器上性能的測試，可以采用工具，也可以使用系統(tǒng)本身的監(jiān)控命令，例如Tuxedo中可以使用Top命令資源使用情況。實施測試的目的是實現(xiàn)服務器設備、服務器操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、應用在服務器上性能的全面。UNIX資源指標和描述指標描述平均負載系統(tǒng)正常狀態(tài)下，最后60秒同步進程的率在以太網(wǎng)上監(jiān)測到的每秒進程/線程交換率進程和線程之間每秒交換次數(shù)CPU利用率CPU占用率（％）磁盤交換率磁盤交換速率接收包錯誤率接收以太網(wǎng)數(shù)據(jù)包時每秒錯誤數(shù)包輸入率每秒輸入的以太網(wǎng)數(shù)據(jù)包數(shù)目中斷速率CPU每秒處理的中斷數(shù)輸出包錯誤率發(fā)送以太網(wǎng)數(shù)據(jù)包時每秒錯誤數(shù)包輸入率每秒輸出的以太網(wǎng)數(shù)據(jù)包數(shù)目讀入內存頁速率物理內存中每秒讀入內存頁的數(shù)目寫出內存頁速率每秒從物理內存中寫到頁文件中的內存頁數(shù)目或者從物理內存中刪掉的內存頁數(shù)目內存頁交換速率每秒寫入內存頁和從物理內存中讀出頁的個數(shù)進程入交換率交換區(qū)輸入的進程數(shù)目進程出交換率交換區(qū)輸出的進程數(shù)目CPU利用率系統(tǒng)的CPU占用率用戶CPU利用率用戶模式下的CPU占用率（％）磁盤阻塞磁盤每秒阻塞的字節(jié)數(shù)成功軟件測試管理的九大原則作者簡介許多測試管理者是從技術部門進到管理階層的。盡管他們有可能受過很多測試或軟件工程的培訓和指導，但他們還是很難經(jīng)常從失敗和錯誤中學到管理技巧。作為一個管理者，你有兩項基本工作：找出為你工作的最好的員工并且建立一個能夠使員工完成工作的環(huán)境（使他們最好地完成工作。這篇文章講述了一些我學過的關于這些管理工作的經(jīng)驗。第一．為工作雇傭最好的員工我遇到許多管理者，他們要雇傭的員工僅僅是他們上一個雇傭的。作為一個測試管理者，你必須對你需要什么人做出評估。假設現(xiàn)在你的部門滿是極好的探索型的測試員。如果你還要雇另一個探索型的測試員，也許比你現(xiàn)在的要好，但是他對你的空白領域有作用嗎？也許有，也許沒有。工作的最佳人選也許就是你現(xiàn)在這個小組里所沒有的類型。最佳人選或許并不“適合”你通常的工作方式。作為一個測試管理者，雇傭一個最佳的員工要用發(fā)展的雇傭策略，面試時要檢驗他是否符合這個策略。這可以讓你找到最適合這份工作的人員，他能夠完成必要的工作。第二.安排每周與你的每個小組成員在不被打擾的環(huán)境進行談最為一個測試經(jīng)理，主要工作之一就是定期的評定你的組織做了些什么并且是怎樣做的。你還要為你的員工做一個報告，關于充分了解他們正在做什么和他們是怎樣做的，以此來給做他們正式的和非正式的工作成績考核。如果你沒有了解到每個人的動態(tài)你就不應該對你的報告滿意。我定期地給我的小組成員每周在不被打擾的條件下做一對一的談（當我管理12個員工的時候，我安排在另外一周會見另一些人。周用30分鐘來和每個員工談談他們的工作：他們工作中的問題或是意見；他們是否需要幫助，他們的表現(xiàn)和他們達到目標的興奮。我一般安排一周的某天來進行一對一談話。我事先安排出和每個人的特定時間，接下來我親自會見他們每個人。如果我們不能把所有需要談到的細節(jié)都包括，我們會安排另外一個時間來繼續(xù)。許多管理者說他們沒有時間在一周會見每一個員工來談他們的工作。據(jù)我的經(jīng)驗，如果我不能安排時間和我的員工進行每周的談話，他們會來打擾我的工作，因為他們無論如何還是必須要來找我。如果你安排和你員工的談話，你必須減少計劃外的打擾（既有他們的也有你自己的，并且的了解他們在做什么。當你清楚你的小組正在做的，你才能更有效率地幫助他們明確優(yōu)先應該做的工作，重聚資源，重新計劃工程的部分，排除等等。第三.假定員工知道如何完成他們的工作的人員因為很多管理者起初做的是技術工作，他們知道他們的員工現(xiàn)在從事的工作。他們認為他們現(xiàn)在知道。如果你已經(jīng)管理了兩三年，你也許還沒有你的技術員工知道的多，尤其是怎么樣完成日常工作。你或者你的前任者雇傭你小組的員工。假設你雇傭這些人因為你認為他們能夠完成工作，如果你設想每個人都知道如何完成他們的工作，你將得到比假設他們都不知道怎么完成的更好的效果。即使有些員工在無論你設想是否都能成功完成工作，但是有些員工將會被你對他們的想法所影響工作。因為我知道我的員工都知道怎樣做他們的工作，我給他們分派任務。問他們是否需要幫助，然后留他們獨自完成（除非他們尋求幫助。我的意思并不是你不應該在他們工作的時候和他們說話，你只是不該打擾他。打擾可以分為幾種不同的形式：·,這將仍然不能使你對他們的要如果你每天都問，更糟的是每個鐘頭都問,他們是如何做的。這看起來就像對你員工進行微機管理，很惹人煩。畢竟,你沒有工作要做嗎？另外,他們會以為你認為他們不知道該如何完成工作。如果當他們沒有問你意見，你說“我會用這種方法”。這種予以打擊的幫助不會有用。.如果你不確定怎樣能知道你的員工是否勝任，和每一個小組成員商討尋求幫助的時機。每個人，包括你自己，應該選擇一個規(guī)則來知道他或她什么時候成為了一個令人討厭的家伙了。我的一個客戶有一個15分鐘。如果有人在某方面令人討厭持15當你分配工作時，問問你的員工是否明白該做什么，他或她是否有方法完成。確定工作進程，如果員工遇到麻煩，他應該主動找你尋求幫助，但是如果你堅決，你的員工將會把找你尋求幫助作為最后的解決方法。第四.對待你的員工要用他們能接受的方式,而不是你可以自己可以接受的方式“對待別人要用你愿意接受的方式”（己之不予，勿施于人）――這條黃金法則可能會對許多生活中的純的社交因素有效，但是并不是總對工作有用。有效率的管理者知道他的每一個員工需要怎樣的對待方式。當其他的人更樂意接受的信息。一些人去需要特定的任務和指示。一些因為解決新的，很棒的，復雜的問題而更有沖勁，但是還有一些只是對他們已經(jīng)知道如何去處理的問題而感另外，針對于不同的工作，我們都喜歡不同的認同方式。金錢不是表示認同的唯一方式，你可以用其他的方式來酬勞你的員工。有些人喜歡對他個人的感謝，有人樂意在公眾面前的認可，一些喜歡以M﹠M方式，或者是票，還有人希望有團隊的排隊來慶祝。記住無論什么的激勵你的方式都不一定能激勵你小組的每一個其他成員。和你的小組成員們通過討論來了解他們每個人對比較喜歡的予方式。創(chuàng)造一個好的工作環(huán)境第五重視結果而非時間許多認可建立在員工完成工作的時間上，而不是他們最后的成績上。但是，花費在工作上的時間不一定和創(chuàng)造性有必然的聯(lián)系。如果你真的想改善對創(chuàng)作性和工作效率的認可的話，不妨考慮保證你員工每周只工作40個小時。我常常聽到一種表示對員工的異議就是“你整整一天什么都做不出來?！奔僭O你自己處在一個巨大的前，考慮你可以做什么來解決的時候，你是不是取消了會議？你的小組成員能否安排他們的工作以至于能夠最大限度發(fā)揮創(chuàng)造性？當人們每周工作超過40個小時的時候，他們開始在工作的時候關心他們自己的事。他們花錢，他們給很久沒有聯(lián)系的人打，因為他們一直都在工作。一旦你創(chuàng)造了一個環(huán)境，讓員工在工作時間完成工作，開始鼓勵他們每周不要超過40小時，接著你就可以基于他們在40個小時能夠完成的工作量給他們酬勞。我總是發(fā)現(xiàn)這樣能夠提升創(chuàng)造力（因為員工不能在太疲勞的狀態(tài)下完成工作，這是因為他們在工作時不能關心自己。當你開始注意規(guī)律，不僅僅是時間，還包括更容易地給員工的表現(xiàn)給予精確的適度的評價。你的員工是否完成了他們的計劃和測試設計？當他們開發(fā)測試的時候，他們還要修訂那些他們需要的改進的部分？（如果你只是注意有多少測試可以使用，我可以重復地開展相同的測試）計劃每周工作40個小時，并且為你要在這段時間完成的工作付。第六.承認自己的錯誤每個人都會犯錯。他們會因為忘記開會而使客戶發(fā)怒。承認你犯錯是令人尷尬的。我們中的許多人認為對小組承認自己犯錯會失去尊嚴。如果你不是經(jīng)常犯錯，你承認錯誤的時候其實能夠贏得尊敬。如果你忘記一次會議，你為此道歉，其他的人會理解你并且最終原諒你。不管你做了什么，不要否認或故意忽略你的。故意忽略不會讓錯誤這只會讓錯誤成長為怪物。最近，有一個委托人在會上對他的員工大聲斥責。會后，他認識到他不應該那樣在小組會上那樣做。他只是想讓他們安心工作，等過幾天再道我建議在他們對他積累怒氣之前，應該用正確的方式和他的員工交談。他起初都是這樣對他說的：“在會后才對你感到生氣的。如果您能夠立即和我談談，我就不會把它們積累起來。但是現(xiàn)在已經(jīng)兩天過去了,我仍然對您感到生氣，事實上，我還更加惱火，我現(xiàn)在不能確信現(xiàn)在是否能相信您。我不介意你對我們大吼，但是我不能確定是否還會再這樣做。我的客戶不知道應該如何處理這種情況。他認為他的等待是正確的，但是卻讓問題變得更加嚴重。.他已經(jīng)決定再也不會犯這樣的錯誤了，而且會立刻和會員工交流。他的員工用了好幾個月來重新相信他，但是我的這位客戶的確通過承認過錯而增加了他的?，F(xiàn)在，他和他的員工對這件事可以當做是玩笑來說。他們說這是他的認知和能力的巨大轉折點。第七.決定承擔一個項目必須首先問你的組員是否有能力完成當你是一個下級的員工，你的對你說“我們是否可以在下個十月完成項目？”回答說“當然”會令人驚訝。但是，你的員工會因為你回我要考慮一而表示贊賞。即使你已經(jīng)在考慮這個問題，告訴了你