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

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

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

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