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

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

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

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