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

本期導游戲軟件的測試方法簡述簡單介紹了游戲軟件的測試方法，決玩家所遇問題的預測工作，同時也是不斷 [詳見P3.]微軟公司軟件接收測試過程一個公司業(yè)務過程的應用軟件對它的經(jīng)營效率起了關鍵性的作用。然而，1995年之前，微軟沒有一個正式的、連續(xù)的、面向企業(yè)的適當步驟，來確保它內(nèi)部的應用軟件按照一系列統(tǒng)一的公司標準開發(fā)。今天……[P4.]自動化測試成功的關鍵.在本文中，我們要討論為什么進行測試，尤其是自動化測試，是必需的。然后，介紹制定計劃的概念：為什么制定計劃是如此的重要……[詳見P7.]性能測試指標介紹TPC-作為一家非 性機構(gòu)事務處理性能 （TPC）負責定義諸如TPC-C、TPC-H和TPC-W基準測試之類的事務處理與數(shù)據(jù)庫性能基準測試我們細致地研究JUint框架并思索如何來構(gòu)造它…… [詳見P11.]對Web服務進行壓力Web服務處于分布式計算的位置，它們之間的交互通常很難測試。分布式開發(fā)、大型的開發(fā)者團隊以及對代碼日益組件化的期望都有可能使Web服務的開發(fā)變得越來越容易隱藏錯誤…… [詳見P16.] 強化測試用例在測試活動的作用本文的目的不是將軟件測試流程優(yōu)化的話題闡述的面面俱到，而是從管理角度談談測試用例在測試活動中的重要性，以及測試用例管理……[P19.] 高手過招的樂趣—測試用例預演投稿主編：審閱：協(xié)作：高手過招，手中無需用劍，只要輕描淡寫地以口代手，三兩句話便投稿主編：審閱：協(xié)作：一、游戲軟件的測試方法簡測試的定義如果個義，覺得：試作，決家遇題預工，同時也是不斷調(diào)試平衡的一個長期觀察任務。無論在什么時間段，功能實現(xiàn)、內(nèi)測、公測等。測試都應該是分硬件與軟件兩部分測試。硬性問題硬件的BUG部分是指會引起不能讓游戲流程進行的BUG。死機、畫面出錯等硬性問題。這種問題只要按照一定流程進行游戲，就會發(fā)生。但對一些會不斷增加服務器負擔的高級BUG，應該不會短期測試出來。而對這種在有計算機就出現(xiàn)的問題，現(xiàn)在的游戲在制作過程中都有可自動記錄問題的LOG功能，所出現(xiàn)的BUG大多會被程序部門解決掉。部分的LOG功能可保留到正式客戶端，以收集因為升級客戶端，而不斷產(chǎn)生的新問題。這里應該不會在討論范圍內(nèi)吧。軟性問題而軟件的邏輯部分大多會在后期進行，比如公測。是各種功能的數(shù)值調(diào)整。主要為游戲的世界定義一個平衡。除了初級的數(shù)值設定外，內(nèi)部測試人員很少有能把一個功能測試千萬遍的。于是有可能產(chǎn)生出貓耍的團轉(zhuǎn)，這種經(jīng)典的寓言故事。策劃及相關測試人員注重的應該是這部分的測試原理及方法。而這部分問題的測試，同硬性問題一樣，需要一定流程及要求。而具體流程只有根據(jù)具體游戲來決定，大多是將問題存放，并將理由歸納。但有幾點是不變的。平衡的目標而如何讓各種設定不偏離，明確世界背景及制定等級概念應該是首要的。尤其在一些角色等系統(tǒng)十分復雜的情況下。那種ADD的規(guī)則，可由主角的5~種基礎屬性影響到數(shù)十種戰(zhàn)斗、非戰(zhàn)斗技能。還可根據(jù)各種物品來休整這些數(shù)值。而無論如何。他們都有個明確的等級觀念。從弱到普通，再到強，甚至到最強的龍。這是因為他們知道一個人，最強也不能強過龍。這樣就給自己定下上限目標。所以，測試時首先不要去看玩家可選擇的等等是否足夠多。都會獲得什么強大的技能、體力等等。先了解到里，各個種族之間的關系、職業(yè)的互補、各個角色的互相的關系，在整個世界中是什么位置，是否夠合理、讓常人可以現(xiàn)實中的邏輯去衡量，這個角色在游戲是否合理。之后才需要針對每個種族、每類職業(yè)、每個角色的平衡。最后到一個一個角色的測試。有人會說這是前期策劃制定討論的部分，沒錯，因為測試從這里就已經(jīng)在策劃的頭腦中開始了。在這里定義的過程，正好與現(xiàn)實世界中相反?，F(xiàn)實世界是總結(jié)出整體的平衡，劃分等級測試時同樣要明確問題的嚴重等級，一個數(shù)值影響的事物越多，那他的嚴重等級越高?，F(xiàn)在的MMRPG整個屬性結(jié)構(gòu)，基本都類似樹形結(jié)構(gòu)，之間也有著一些交錯的枝葉。力量等最基本的角色屬性，為根。這類屬性會影響到的其他屬性，最終到達游戲的勝負，任務的完成等等。而這些屬性的等級自然也就十分明確。根為最高，最低。而修整樹木不會從根開始。力，礎性，結(jié)中對敏，影理。同樣也影響著可拿的。但如果這個人力過高。那是誰的原因？是，還是角色的力量。需要修改那一個？那些角色的基礎屬性是最不能隨便修改的。因此，還是吧。實在不行在從由屬性的其他部分著手，如技能的熟練度等。越基礎的部分，越大，也最容易出錯。角色的基礎屬性測試的根源，同樣也是最不能隨便更改的一類。更不應該因為某個問題而被指明要求更改。而添加刪除任何一個屬性，更會讓之前的測試工作有2/3付之一炬，也許。而對于各種，基本可以與角色測試分開。在角色屬性有數(shù)十條的游戲中，更不會容易出現(xiàn)大的問題。盡量在自己的范圍內(nèi)修正。不要妄想在其他級別動手，更別想在比自己之前高的級別里動手腳。而在這些屬性里面同樣還各種屬性，就需要根據(jù)具體游戲進行劃分測試。雖然這里以屬性距離，但任務也同樣如此，相互關連的任務網(wǎng)同樣十分重要。只不過之前變化較屬性掠少。玩家是否付出與獲得成正比現(xiàn)實世界中，沒有可能可用捷徑獲得某一種事物、，只有拼搏。游戲世界里是否也是？獲得一個強大技能之前，給角色的鍛煉是否足夠。讓他足夠珍惜這一種技能或物品。這是游戲中較為關鍵的一部分，多體現(xiàn)在任務上。時間、精力的消耗，是否足夠讓玩家獲得物品時有足夠的滿足感。以及對得起測試人員的勞動。記錄、調(diào)整，總結(jié)軟性問題應該同硬性問題一樣擁有足夠多的文檔資料來記錄，同時也方便對以往數(shù)值的效果再思考。這也應該是所有文檔資料應該具備的，記錄每次關鍵更新的工作。調(diào)整方面SidMeier，每一次調(diào)整都要多一些。這樣可以看到數(shù)值中的巨大差別，從中找到合適的數(shù)值。這幾乎是知道SidMeier的人都知道的一句話（大意相似，具體內(nèi)容沒辦法記起來，慚愧）很多時候，測試時會直接將測試的內(nèi)容按自己的想法修改。即便記錄下來也是只要改好就好。其實很多時候這些修改都有一定規(guī)律，一些修正往往是沒改變?nèi)魏问虑椤６嘁恍r間去探討大家是否按照原來制定的目標去修正，會更合理的利用剩下的時間測試。同樣，全部結(jié)束后的總結(jié)也會讓下次制作時避免出現(xiàn)需要大量修正慧靈科技依托測試時代資源，推出面向?qū)嵺`的軟件測慧靈科技依托測試時代資源，推出面向?qū)嵺`的軟件測試專業(yè)課程，由國內(nèi)著名軟件企業(yè)的一線技術(shù)專家主講，為您的企業(yè)解決實踐中的關鍵問題。如果您培訓的目的不是拿一個 ，而是想學習軟件測試的最佳實踐，那我們會是您一個不錯的選擇。登陸公 二、微軟公司軟件接收測試過來自：一個公司業(yè)務過程的應用軟件對它的經(jīng)營效率起了關鍵性的作用。然而，1995年之前，微軟沒有一個正式的、連續(xù)的、面向企業(yè)的適當步驟，來確保它內(nèi)部的應用軟件按照一系列統(tǒng)一的公司標準開發(fā)。今天，微軟小組的軟件接收測試過程確保證關鍵任務的應用軟件能在公司的硬件設施上高效地運行，與嚴格的操作標準一致。這些標準建立起來是為了最優(yōu)化應用軟件的運行和集成，減少來自上面的行政管理。卓越的產(chǎn)品對公司的成功非常重要；一支有動力的銷售力量也是成功關鍵。但是，如果一個公司二者兼具，但業(yè)務過程上的應用程序與它的產(chǎn)品實力、銷售力量、不相適應，該公司的發(fā)展速度仍然會漸漸變慢。這些應用程序幫助管理企業(yè)內(nèi)部最次的工作，如對報告系統(tǒng)的指令和融資、幫助桌面呼叫系統(tǒng)等所有這些內(nèi)部開發(fā)的用于支持創(chuàng)新性的、競爭性的商業(yè)實踐的應用軟件。為了保證它的業(yè)務過程上的應用軟件能夠提供最良好的運行、最小程度的上級管理，微軟公司依賴于它的小組的軟件接收測試過程。這個過程保證所有內(nèi)部開發(fā)的、為公司環(huán)境使用而設計的應用軟件都是按照一系列正規(guī)的、以公司為基礎的標準來建造和測試的。這些標準定義了一個應用軟件是如何與其他的軟件互相作用，它如何使用公司的數(shù)據(jù)庫，它是如何被建造在世界范圍內(nèi)的網(wǎng)絡上最優(yōu)化地運行。結(jié)果，內(nèi)部應用軟件開發(fā)商能夠改進開發(fā)周期，微軟數(shù)據(jù)中心的經(jīng)理能比從前更有效地運行和這些內(nèi)部應用軟件。從195年開始幫助微軟減少內(nèi)部開發(fā)和費用每年超過兩百萬。它還幫助微軟建立了一個更加化和強有力的軟件環(huán)標準的要求"我們從1995年的七月開始開發(fā)SAT(軟件接收測試)過程"格瑞吉·吉斯維茲說，他是微軟組中SAT小組的經(jīng)理。"在那之前，內(nèi)部開發(fā)的業(yè)務過程應用軟件是直接到數(shù)據(jù)中心和直接掛到國際網(wǎng)上的--簡而言之，它是自己進入微軟的產(chǎn)品環(huán)境中去的--沒有任何一種運行標準，也沒有任何一種正式的軟件接收過程。"當開發(fā)商在這些應用軟件被投放市場之前對它進行常規(guī)性的功能測試的時候，這種功能測試并不能保證此應用軟件在微軟的公司范圍內(nèi)的產(chǎn)品環(huán)境中工作得很好。在1995年之前，微軟的業(yè)務過程上的應用軟件開發(fā)商所的一個最基本的問題是，缺乏關于如何為開發(fā)業(yè)務過程應用軟件來最優(yōu)化微軟的產(chǎn)品環(huán)境的的信息庫。這些應用軟件的開發(fā)在單個經(jīng)營單元小組內(nèi)進行，公司沒有集中的工程或開發(fā)小組，單個BUIT開發(fā)小組很少知道其它BUIT小組的開發(fā)商在做什么。并且，沒有一個小組和微軟公司內(nèi)負責運行公司的網(wǎng)絡與數(shù)據(jù)庫系統(tǒng)的組織直接掛結(jié)果，當這些應用軟件最后被掛到公司的網(wǎng)絡上去，并開始和公司的數(shù)據(jù)庫與其它應用軟件互相作用的時候，他們并不總能象期望的那樣工作。一些應用軟件在網(wǎng)絡上工作地很差，一些不能與它們的整體融合，還有一些要占用準備進入的服務器和數(shù)據(jù)庫的所有資源。開發(fā)商不得不極其費力地降低這些波動性，或者重新修改這些應用軟件，直到它們能連續(xù)、可靠地運行。信息、指令以及合法性的唯一資源為了開發(fā)系列正式的指導性原則，以利于優(yōu)化微軟公司業(yè)務過程的應用軟件的開發(fā)，為了讓這些指導性原則在整個BUIT中趨于嚴格的一致,為了給全公司的開發(fā)者、經(jīng)營單元經(jīng)理和執(zhí)行者提供關于開發(fā)中的業(yè)務過程上應用軟件的單一的信息源，ITG創(chuàng)建了一套正規(guī)的程序。在微軟執(zhí)行者的支持下，SAT小組與管理公司數(shù)據(jù)中心和公司網(wǎng)絡的組織密切合作，去創(chuàng)建一套業(yè)務過程應用軟件的正式標準。這些標準現(xiàn)在為內(nèi)部應用開發(fā)提供了最好的實踐指導，使微軟的開發(fā)者能為硬件設計應用軟件，在系統(tǒng)軟件上運行，并且數(shù)據(jù)庫管理系統(tǒng)在微軟的產(chǎn)品環(huán)境中工作得更好。微軟的SAT過程在SAT過程的最開始，內(nèi)部應用軟件開發(fā)SAT的局域網(wǎng)工具登記他們的開發(fā)計劃。登記提醒SAT小組一個新的軟件開始進行，由此產(chǎn)生一系列會議，把開發(fā)者們、SAT小組成員，和真正管理產(chǎn)品環(huán)境中的小組成員召集到一起。局域網(wǎng)工具提供給開發(fā)者一套版本的微軟運行標準文件，其中呈列了最近的硬件、網(wǎng)絡、操作系統(tǒng)、業(yè)務過程應用軟件數(shù)據(jù)庫管理的標準，使這些信息通過SAT在微軟局域網(wǎng)上的站點發(fā)布，在程序開發(fā)過程中，開發(fā)者不斷向SAT的工具數(shù)據(jù)庫添加新信息：安裝手冊、使用和指南、非標準化的模板的文字稿（保證使用者有足夠的信息支持程序。SAT小組和開發(fā)者一起工作，建立一個確保企業(yè)質(zhì)量（EQA）的測試以確信程序符合微軟操作標準，能夠在微軟產(chǎn)品環(huán)境中正常運行。EQA測試計劃和日程被列入SAT工具數(shù)據(jù)庫，并成為永久部分，這樣在后來的設計和運行出現(xiàn)問題后可以進行參考。工程支持于質(zhì)量保證測試新的LOB程序?qū)嶋H測試之前，SAT組和BUIT開發(fā)者密切合作來確保大家在合作中能從對方的經(jīng)驗獲益。微軟公司企業(yè)程序服務部總經(jīng)理BobLunn說："SAT工程小組的每個人從BUIT隊伍中獲得了經(jīng)驗和知識，然后把這些知識化為最優(yōu)秀的實踐，使所有的BUIT成員都可使用。這樣，有助于調(diào)整大家一起開發(fā)程序。"微軟企業(yè)數(shù)據(jù)管理主管TimThiers說："我可以給你一個特殊的例子，當遇到了廣域網(wǎng)（WAN）中用戶的運行問題時,微軟公司使重的基于客戶-服務器的程序跟蹤意外情況。SAT組中的工程組就能在程序上進行重點測試，在微軟終端服務器上診斷它能否通過廣域網(wǎng)解決問題。如果我們使用終端服務器來支持程序，他們就可以提供功能上定量精細的幫助。""在意外程序的一項關鍵功能上，SAT工程組證明：對在通常微軟帶寬為X、延遲率為Y的輔助環(huán)境的通常用戶,當使用終端服務器時，功能調(diào)用的行為將導致z%性能增加。他們能告訴我，反應時間從多少秒到多少秒--反正是一些很難記住的數(shù)字--這樣就有足夠的信息進行成本-收益決策，確定采取什么樣的技術(shù)。"除了為了提供測試支持來開發(fā)最佳程序設置，在微軟新產(chǎn)品環(huán)境下運行時,SAT組中的工程組還可以幫助測試LOB程序性能。作為微軟產(chǎn)品銷售的SAT過程的部分，微軟最大的銷售收入和庫存數(shù)據(jù)軟件，SAT工程組要測試它在MSSQL7.0環(huán)境下的性能。這不僅使開發(fā)者可以提前預見并克服它與新數(shù)據(jù)庫系統(tǒng)合作時的性能問題，還為MSSQL7.0找到了企業(yè)環(huán)境的實驗臺。AlanPerkins是SAT組的高級系統(tǒng)分析員，他說"這有助于SQL服務器開發(fā)組在發(fā)布產(chǎn)品之前強化其功能。他們帶來改進型版本，要我們對現(xiàn)有版本進行針對測試。測試后，我們反饋回結(jié)果：哪些查詢快，哪些慢，什么時候發(fā)生飽和，諸如此類的問題。"Gicewicz補充說，"這些反饋對SQL服務器7.0起了積極影響。版本響應MSSales查詢的速度比前期版本提高了65%。"除了開發(fā)過程中的咨詢作用、確保SAT過程最終成功外，SAT小組使LOB新程序通過了正常的EQA測試。Gicewicz說"在軟件產(chǎn)品真正降生前，它要先獲得SAT準生證。這意味著我們已經(jīng)成功安裝，該軟件可以躋身于模擬的產(chǎn)品環(huán)境，通過了真實條件的測試。"作為測試過程的一部分，SAT組應用廣域網(wǎng)模擬和一套內(nèi)置的第工具來擬微軟企業(yè)產(chǎn)品環(huán)境。這些工具包括NetworkMonitor和PerformanceMonitor（用于WindowsNTServer操作系統(tǒng)），RadView公司的WebLoad、Optimal公司的ApplicationExpert以及兩種內(nèi)部開發(fā)的工具（用來管理和測試SQL服務器。當成千的用戶在Intranet上同時點擊應用程序時，這些工具可以模擬服務器的行為，可以通過廣域網(wǎng)模擬網(wǎng)絡連接來測試程序的表現(xiàn)，甚至可以模擬眾多用戶同時查詢數(shù)據(jù)庫的情況。另外，EQA過程檢驗程序是否符合微軟操作--以確保它與為LOB程序已建立的引導相匹配。推出最好的產(chǎn)品微軟公司有大約250個企業(yè)系統(tǒng)，ST過程是為加強它們的穩(wěn)定性、可靠性、可度量性設計的，為遍布世界各地的決策者提供有用和高效的信息管理工具。如何把優(yōu)化程序做得最好，如何在軟件進入產(chǎn)品環(huán)境前徹底測試--這些知識被集合在一起，為微軟公司每年節(jié)約200萬（自1995年開始。這一過程也縮短了LOB程序返工的時間（目的是優(yōu)化其性能，使之能在微軟產(chǎn)品環(huán)境正常工作。返工時間從196年起下降了3%。微軟公司從SAT過程中了另外的切實的、可度量的、本質(zhì)固有的利益。質(zhì)保測試過程提供了機會，從中可以發(fā)現(xiàn)和改正程序中的缺陷，避免了在演示和發(fā)布后引起問題。Gicewicz闡述說，通過EQA測試后的IT基礎設施效率更高。對程序不熟悉的人要進行安裝測試，這樣可以促使開發(fā)者注意到并解決一些安裝問題--如果是由熟悉程序的人來安裝，他們可能對這些問題意識不到。最后，通過對所有內(nèi)部LOB程序開發(fā)的鞏固和調(diào)整，SAT過程對微軟公司的所有人起了促進作用：如果微軟的雇員想得到關于提供商業(yè)支持的程序時,它提供了一個單一答案庫。格瑞吉·吉斯維茲說："如果你是CIO或行政主管，你就想知道在微軟公司到底有多少這樣的LOB程序。很簡單，在微軟主頁上就能見到答案。你還可能希望了解關于程序框架的不同觀點--比如，共有多少種金融信息管理系統(tǒng)。你可以深入鉆研SAT數(shù)據(jù)來發(fā)現(xiàn)按商業(yè)功能分類的程序。在以前，你對微軟的LOB現(xiàn)在，容易多了！"優(yōu)異的產(chǎn)品、充滿激勵的銷售、一整套的協(xié)調(diào)的LOB程序（已經(jīng)針對企業(yè)優(yōu)化，并且經(jīng)過了SAT的嚴格測試）--這一切，使微軟公司的市場表現(xiàn)卓越不凡。三、自動化測試成功的關鍵在本文中，我們要討論為什么進試，尤其是自動化測試，是必需的。然后，我們將介紹制定計劃的概念：為什么制定計劃是如此的重要？在隨后的文章中，分解測試計劃中的不同因素，并且研究如何進行制定計劃的過程才能最大程度地增加成功的機會?，F(xiàn)代客戶端/服務器應用程序是非常復雜的，因此測試也就成為開發(fā)過程中關鍵的并且至關重要的一部分?，F(xiàn)在，沒有人會考慮（或者承認）不對自己開發(fā)的軟件進試工作。但是，研究和調(diào)查表明，在軟件開發(fā)過程中，制定測試計劃卻常常是優(yōu)先級較低的工作項目。而且，更加糟糕的是，計劃往往沒有被執(zhí)行，或者即使執(zhí)行了，也進行的不很完整、不很準確，或者沒有持續(xù)進行。假設我們都贊成測試是必要的，那么我們接下來必須回答這些問題：我們?nèi)绾芜M試？實際上都包括哪些內(nèi)容？我們?nèi)绾伪ＷC已經(jīng)進行了有效的工作，并且真正地改善了應用程序的質(zhì)量？答案很簡單：制定計劃。本文將評審在軟件生命周期中制定測試計劃的作用，以及有效制定測試計劃的有關概念。在本文中，我們要討論為什么進試，尤其是自動化測試，是必需的。然后，介紹制定計劃的概念：為什么制定計劃是如此的重要？在隨后的文章中，分解測試計劃中的不同因素，并且研究如何進行制定計劃的過程才能最大程度地增加成功的機會。為什么花費精力制定計劃？現(xiàn)在看來，沒有怎么制定測試計劃而造成的比以前更加明顯了。失敗的案例有很多--看看報紙或者雜志就知道了。還有一些明顯的低質(zhì)量軟件的案例，它們包AT&T－一個軟件交換系統(tǒng)，系統(tǒng)造成了幾乎24小時的長距離通信中斷。僅僅修改了一行源代碼就解決了問題。Denvor機場--軟件的缺陷延誤了機場的開放幾乎長達9個月之久，據(jù)估算，每天花費大概$500,000。Ashton-Tate--在80年代，Ashton-Tate的DBASE軟件是基于PC的數(shù)據(jù)庫應用程序的實際標準。版本中的缺陷導致了利潤的減少，最終造成了Ashton-Tate（和DBASE）的轉(zhuǎn)讓。Ashton-Tate最后被Borland（擁有極具競爭力的數(shù)據(jù)庫管理應用程序，Paradox）收購。關鍵的，也是很明顯的。這里有一些低質(zhì)量軟件的更加共同的癥狀：生產(chǎn)力損失系統(tǒng)性能；沒有滿足用戶需求--無法銷售；用戶挫折感強迫用戶以不直觀的方式執(zhí)行任務；循環(huán)工作；沒有滿足預期目標；存在用戶操作錯誤與理解錯誤；數(shù)據(jù)丟２.客戶端/服務器應用程序到底有什么差別？客戶端/服務器應用程序為質(zhì)量保證專家?guī)砹瞬煌?，下面是一些比較重要的內(nèi)容：快速應用程序開發(fā)大多數(shù)的客戶端/服務器應用程序都使用快速程序開發(fā)（RAD）方法學進行開發(fā)。測試人員必須"努力跟上"這些較短的開發(fā)周期。早些時候，非客戶端/服務器應用程序常常使用18-24個月就完成了整個的開發(fā)過程和初始部署。現(xiàn)在，使用RAD，應用程序的發(fā)布需要經(jīng)過多次部署或者"塊"。每個塊都基于以前的版本，并且包括改善、修改和修理。每個塊都需要多次創(chuàng)建或者迭代的原型。每個塊都需要進試，并且在3-6個月的更短時間內(nèi)完成?？蛻舳?服務器架構(gòu)當前的客戶端/服務器應用程序都需要很多的軟件組件結(jié)合起來以實現(xiàn)功能，包括客戶端應用程序、工作站操作系統(tǒng)、網(wǎng)絡和數(shù)據(jù)庫管理系統(tǒng)。常常也包括其他的組件，例如為實現(xiàn)正確執(zhí)行而包含的附加源代碼的DLL（動態(tài)連接庫、事務處理器或者應用程序與數(shù)據(jù)庫管理服務。軟件的每個附加"層"都在客戶端/服務器架構(gòu)中增加了額外的復雜度（并且需要進試。多種類型的測試另外，測試客戶端/服務器應用程序也需要使用許多不同類型的測試方法，例如，功能測試、用戶界面、性能測試以及配置測試。這些測試都針對一個或幾個測試目標。為了防止測試迂回不前或者嘗試同時測試所有內(nèi)容，每種測試必須制定仔細的計劃。當您進行自動化測試時，這一點尤其正確。數(shù)對于我們執(zhí)行的每種類型的測試，都必須使用數(shù)據(jù)。數(shù)據(jù)對于測試的執(zhí)行和成功完成來說是至關重要的，因為要使用數(shù)據(jù)識別最初的應用程序數(shù)據(jù)狀態(tài)（，并且調(diào)用或者引出特定的事件或者操作。而且也要使用數(shù)據(jù)來驗證測試事件或者操作是否運行正常！制定測試計劃的其他原因如前所述，現(xiàn)代的應用程序與以前開發(fā)的應用程序相比具有很大的不同?？蛻舳?服務器技術(shù)加強了我們開發(fā)與部署以任務關鍵型的企業(yè)系統(tǒng)的能力，而且花費的周期更短，提供的功能更加強大?？蛻舳?服務器應用程序也為開發(fā)人員與終端用戶提供了大量的選擇和控制。但是使用這些好處的同時，也需要加強測試。測試自動化逐漸地，測試軟件必須使用測試自動化工具和技術(shù)，以滿足具有性的日程安排。但是，單單使用工具還不足夠，成功的測試自動化需要制定測試計劃。在沒有進行計劃的條件下，實施測試自動化只會帶來自動化的。使用測試自動化工具，我們可以管理并且識別過程中造成的因素，同時管理項目費用（例如"未被文檔化的特性/變更"。測試自動化是使軟件測試人員跟上開發(fā)人員腳步的惟一方式，軟件測試人員可以像測試早先構(gòu)建版本那樣，充滿信心地、可靠地測試新構(gòu)建的版本。但是測試常常為測試人員帶來，他們必須最有效地、生產(chǎn)力極高地使用時間，進行工作。測試自動化引入了一種新型的資源需求--測試開發(fā)。手工測試需要進試設計，以識別測試的內(nèi)容和方式，但是由于沒有使用工具，所以也沒有必要開發(fā)任何的測試或過程，僅僅來調(diào)試一下系統(tǒng)，然后使用鍵盤就可以了！如果對于每個要進行的測試，需要使用的資源僅僅是鍵盤，那么就可以看出，您并沒有有效地利用時間。測試開發(fā)是一種新技術(shù)，在設計完成之后，需要使用工具并且創(chuàng)建測試過程。作為一種有效的方式，可以使用三名不同的技術(shù)員，并確保將的資源用于設計與制定計劃任務上，而將中級資源（或外界資源）用于開發(fā)與執(zhí)行。這樣可以增強職員所需的能力，并且共享資源，同時也不會對項目計劃產(chǎn)生什么影響。缺陷管理與分析缺陷是肯定會被發(fā)現(xiàn)的。這是進試的結(jié)果，或者說是目的，所以須對缺陷的生命周期進行識別和溝通，同時分析結(jié)果以確保缺陷已被有效地并且高效地處理。制定測試計劃能夠確保缺陷管理與分析是一筆面向整個項目的寶貴資產(chǎn)，而不會帶來阻礙。如果您還沒有配備缺陷管理系統(tǒng)和過程，或者已具有但是工作得不是很理想，那么制定測試計劃就會給您帶來創(chuàng)建（或者修正）它的機會。制定測試計劃也可以識別應該使用什么樣的度量方法。制定測試計劃可以處理您所度量軟件質(zhì)量程度的問題。它也可以處理如何度量與溝通缺陷密度或缺陷趨勢的問題。風險分析制定測試計劃提供了進行風險評估的機會。風險與不利因素對于組織來說是就一場噩夢，但是它們也是可以被控制的。不過首先必須對其進行分析。風險分析有助于制定測試工作的優(yōu)先級，并且關注所進行的工作，確保測試內(nèi)容的正確性，以正確的順序解決正確的問題。（所謂正確，是以組織的風險與可接收度為基礎的。）對于每個項目來說，都要進行風險評估并將其用于識別潛在的風險或者未發(fā)現(xiàn)缺陷帶來的影響。風險應該用來評估缺陷對于直接終端用戶、數(shù)據(jù)或者其他終端用戶和應用程序帶來的影響。這些數(shù)據(jù)可以用來建立測試優(yōu)先級，并且評估所有約束，例如面市時間、預算或者費用，或者質(zhì)量問題。風險評估還應該包括對于現(xiàn)有標準、指南和需求的評審。其目的就是為了分析這三種文檔，判斷它們對于項目是否恰當，并且由此進行實施或者修正。評審任何可能影響或者對項目帶來沖擊的外界因素也是很重要的。這些影響可以包括特定用戶請求、規(guī)范的需求、或者市場條件，這其中的任何一項都可以變更風險或者優(yōu)先級的評估結(jié)果。過程改善制定測試計劃就是為測試過程制定文檔。為測試制定計劃不僅僅為文檔化并且溝通測試工作提供機會，也可以評審測試工作的有效性。您曾聽到過以下嗎"我知道你已經(jīng)說了需要三個月的時間進試，但是你只有兩個改善產(chǎn)品質(zhì)量（具有較少的軟件缺陷）需要對產(chǎn)品開發(fā)過程進行持續(xù)的完善工作。之，可以從幾個理由來說明制定良好計劃的自動化測試的必要性。首先，不進試的組織會大大增加出現(xiàn)重大系統(tǒng)故障的可能，帶來延遲，花費巨資進行修復，而且還可能潛在地帶來對于客戶信心無法修補的破壞。其次，現(xiàn)代客戶端/服務器應用程序的本質(zhì)允許快速地開發(fā)出復雜度很高的系統(tǒng)，該系統(tǒng)完全無法使用傳統(tǒng)的手工方法進行正確的測試。最后，制定計劃的目的就是為了管理不斷增加的測試過程，分析并且已被發(fā)現(xiàn)的缺陷，執(zhí)行關鍵性風險分析，并且持續(xù)改善測試與開發(fā)過程。您是否對軟件測試的整體規(guī)劃一直比較您是否對軟件測試的整體規(guī)劃一直比較模糊？您是否覺得軟件測試工作技術(shù)含量不高，不知道如何提高自己？您是否發(fā)覺測試用例的復用率非常低而且檢索困難？您是否覺得測試工作不太容易規(guī)劃，總是不如預期？您是否覺得性能測試很重要但是不知道如何組織和實施有效的性能測試？您是否非常想知道大型的企業(yè)級系統(tǒng)是如何進行性能規(guī)劃的？您是否想知道流行的測試工具的使用方法？ TPC-

四、性能測試指標介作為一家非性機構(gòu)，事務處理性能（TPC）負責定義諸如TPC-CTPC-H和TPC-W基準測試之類的事務處理與數(shù)據(jù)庫性能基準測試，并依據(jù)這些基準測試項目發(fā)布客觀性能數(shù)據(jù)。TPC基準測試采用極為嚴格的運行環(huán)境，并且必須在獨立審計機構(gòu)監(jiān)督下進行。成員包括大多數(shù)主要數(shù)據(jù)庫產(chǎn)品廠商以及服務器硬件系統(tǒng)供應商。相關企業(yè)參與TPC基準測試以期在規(guī)定運行環(huán)境中獲得客觀性能驗證，并通過應用測試過程中所使用的技術(shù)開發(fā)出更加強健且更具伸縮性的軟件產(chǎn)品及硬件設TPC-C是一種旨在衡量聯(lián)機事務處理（OLTP）統(tǒng)性能與可伸縮性的行業(yè)標準基準測試項目。這種基準測試項目將對包括查詢、更新及隊列式小批量事務在內(nèi)的廣泛數(shù)據(jù)庫功能進試。許多IT專業(yè)人員將TPC-C視為衡量“真實”O(jiān)LTP系統(tǒng)性能的有效指示器。TPC-C基準測試針對一種模擬訂單錄入與銷售環(huán)境測量每分鐘商業(yè)事務（tmC）吞吐量。特別值得一提的是，它將專門測量系統(tǒng)在同時執(zhí)行其它四種事務類型（如支付、訂單狀態(tài)更新、交付及級變更）時每分鐘所生成的新增訂單事務數(shù)量。獨立審計機構(gòu)將負責對基準進行，同時，TPC將出據(jù)一份全面徹底的測試報告。這份測試報告可以從TPCWeb站點()上獲得。tpmC定義:TPC-C的吞吐量，按有效TPC-C配置期間每分鐘處理的平均交易次數(shù)測量，至少要運行12分鐘。TPC-C規(guī)范概要TPC-C是專門針對聯(lián)機交易處理系統(tǒng)（OLTP系統(tǒng)）的，一般情況下我們也把這類系統(tǒng)稱為業(yè)務處理系統(tǒng)。TPC-C測試規(guī)范中模擬了一個比較復雜并具有代表意義的OLTP應用環(huán)境:假設有一個大型商品批發(fā)商，它擁有若干個分布在不同區(qū)域的商品庫；每個倉庫負責為10個銷售點供貨；每個銷售點為300010項產(chǎn)品;所有訂單中約1%的產(chǎn)品在其直接所屬的倉庫中沒有存貨，需要由其他區(qū)域的倉庫來供貨。該系統(tǒng)需要處理的交易為以下幾種：New-Order：客戶輸入一筆新的訂貨交易；Payment:更新客戶賬戶余額以反映其支付狀況;Delivery:發(fā)貨(模擬批處理交易);Order-Status:查詢客戶最近交易的狀態(tài)；Stock-Level:查詢倉庫庫存狀況，以便能夠及時補貨。對于前四種類型的交易，要求響應時間在5秒以內(nèi)；對于庫存狀況查詢交易，要求響應時間在20秒以內(nèi)。邏輯結(jié)構(gòu)圖：評測指標TPC-C測試規(guī)范經(jīng)過兩年的研制，于1992年7月發(fā)布。幾乎所有在OLTP市場提供軟硬件平臺的廠商都發(fā)布了相應的TPC-C，隨著計算機技術(shù)的不斷發(fā)展，這些也在不斷刷新。TPC-C的測試結(jié)果主要有兩個指標：流量指標(Throughput，簡稱按照TPC的定義，流量指標描述了系統(tǒng)在執(zhí)行PaymentOrder-status、Delivery、Stock-Level這四種交易的同時，每分鐘可以處理多少個New-Order交易。所有交易的響應時間必須滿足TPC-C測試規(guī)范的要求。流量指標值越大越好！性價比(Price/Performance，簡稱即測試系統(tǒng)價格（指在的報價）與流量指標的比值。性價比越小越好！結(jié)果發(fā)布各廠商的TPC-C都按TPC組織規(guī)定的兩種形式發(fā)布：概要(ExecutiveSummary)和詳細測試報告(FullDisclosureReport)。概要中描述了主要的測試指標、測試環(huán)境示意圖以及完整的系統(tǒng)配置與報價，而詳細測試報告中除了包含上述內(nèi)容外，還詳細說明了整個測試環(huán)境的設置與測試過程。P690tpmC測試值：76,389,839.00$/tpmC：美金報價：IBMDB2UDBAIX5LTUXEDO測試日期：2003.6.30P690TPC-C測試的配置：：1xeServerpSeries690with32x1.7GHzPOWER4+processorswith128MBL3cacheperMCM(totaloffourMCMs),512GBmemory前端：30xeServerpSeries630Model6E4eachwith4x1.0GHzPOWER4CPUswith32MBL3cache,16GBmemorySPECweb:SPECweb96:在SPECweb96基準測試程序上實現(xiàn)的每秒鐘超文本傳輸協(xié)議（HTTP）操作最多次數(shù)，響應時間無明顯。SPECweb99:接入數(shù)，網(wǎng)絡服務器可用預先確定的工作量支持的同時接入數(shù)。SPECweb99檢測設備模擬客戶通過慢Internet聯(lián)接，向網(wǎng)絡服務器發(fā)送HTTP工作量SPECweb99測試WebSPECweb99是由標準性能評估組織（SPEC）開發(fā)的Web服務器基準測試。它測量滿足特定吞吐量和客戶請求響應速率要求的WEB服務器的最大并發(fā)連接數(shù)量。并發(fā)連接的合計波特率在320Kbps到400Kbps范圍內(nèi)，則滿足相應規(guī)范。SPECweb99在一臺稱為主客戶端的機器上運行，這臺機器上包含有允許用戶加載特定負載請求的配置文件。主客戶端也要處理在客戶端和服務器或測試中的系統(tǒng)（SUT）之間的傳輸協(xié)調(diào)問題?？蛻舳送ㄟ^許多子進程／線程生成獨立HTTP請求流，仿真足夠的負載發(fā)送給SUT。圖二表示客戶端／服務器的層次關系。SPECweb99實驗環(huán)境在這個測試中，客戶端向測試中的服務器發(fā)送請求數(shù)據(jù)。測試規(guī)范要求客戶端和服務器之間的連接不能使用片段大小大于1460比特的TCP協(xié)議。因此，每一個客戶端1460比特或更少數(shù)據(jù)塊的響應。測試中使用兩種類型的負載量：靜態(tài)負載.靜態(tài)負載具有四種類型的文件。最小的文件的增幅為0.1KB，第二種文件類型的增幅為1KB，最后兩種類型的文件的增幅為10KB和100KB。每一個包含每種類型9個文件共36個文件。目標請求的文件類型在各類型中分散使用。在每一類中的9個文件中又進行二次分布。最終目標文件混合為：35％150％1014％100KB，101％1000KB，100動態(tài)負載.動態(tài)負載是基于和用戶。共有四種在SPECweb99中使用的請求內(nèi)容類型，分別是標準動態(tài)取操作、動態(tài)隨機取操作、動態(tài)發(fā)送操作和客戶圖形接口動態(tài)取操作。標準動態(tài)取操作和客戶圖形接口動態(tài)取操作表現(xiàn)web服務器的簡單輪轉(zhuǎn)特性。帶有輪轉(zhuǎn)的動態(tài)取操作追蹤用戶和用戶選擇，所以可以由不同的方式來定制。最終，動態(tài)發(fā)布實施一個用戶在相應的上。P690SPECweb99測試值21,000Web服務器：Zeus4.0AIX5LV5.1(64-測試日期：2001-10-測試配置：16x1.3GHzPOWER-4Processorsw/1440KBunifiedonchipL2cache,192GBmemory,32x32IBMGigabitEthernet-SXPCI32xGigabitEthernetnetwork(1Gigabit/sec),96xClients(4x375MHzPOWER3-II,RS/600044P-270),RequestedConnections=21000,MaxFilesetSize=67319.6MBP650SPECweb99測試值12,400Web服務器：Zeus4.1r3AIX5LV5.2(64-測試日期：2002-10-測試配置8x1.45GHzPOWER4+processorsw/1.5MB(I+D)unifiedonchipL2cache,32MBunifiedoffchip/SCML3cache,64GBmemory,8xGigabitEthernet-SXPCI-Xcontrollers,8xGigabitEthernetnetwork(1Gigabit/sec48xClients(6x668MHzRS64-IV,pSeries620ModelRequestedConnections=12400,MaxFilesetSize=39801.28MBp630SPECweb99測試值：6,895WebZeusAIX5LV5.2(64-測試日期：2003-2-測試配置：4x1450MHzPOWER4+Processorsw/1536KB(I+D)unifiedonchipL2cache,8MBunifiedoffchip)/SCML3cache,32GBmemory,4xGigabitEthernet-SXPCI-Xcontrollers,4xGigabitEthernetnetworks(1Gigabit/sec),24xClients(4x375MHzPOWER3-II,pSeries640ModelB80),RequestedConnections=6900,MaxFilesetSize=NotesBench:NotesBench是測試各種不同LotusNotes方面的驅(qū)動程序。目的是執(zhí)行自定義工作量教本中令，模擬客戶機的操作。NotesBench測試“僅測試郵件”和“測試郵件和數(shù)據(jù)庫”。所有已經(jīng)公布的IBM結(jié)果均為“僅測試郵件工作量”。p680NotesBench測試值150,197用戶數(shù)：108,000平均反應時間：0.584秒Domino5.06a操作系統(tǒng)：AIX4.3.3IBMeServerpSeries680(24*RS64IV/600MHz;96GBRAM,30五、對Web服務進行壓力測試作者：ChrisWeb服務處于分布式計算的位置，它們之間的交互通常很難測試。分布式開發(fā)、大型的開發(fā)者團隊以及對代碼日益組件化的期望都有可能使Web服務的開發(fā)變得越來越容易隱藏錯誤。這些類型的錯誤極難檢測出來。壓力測試是檢測這類代碼錯誤的一種有效方法，但是只有在壓力系統(tǒng)設計得比較有效的情況下才能發(fā)揮作用。本文將深入了解一下這種壓力系統(tǒng)的基本要求。測試方法傳統(tǒng)的測試方法包括某種形式的簡單單元測試，通常由開發(fā)人員執(zhí)行。設計這些測試需要了解軟件的內(nèi)部知識，并且這些測試幾乎總是針對產(chǎn)品的非常小的、特定的部分。這些類型的測試非常適合與其他代碼組件極少交互，甚至沒有交互的簡單Web服務。功能驗證（FuncionalVerifiation）也是一種測試過程，在這個過程中，對產(chǎn)品源代碼了解有限的設計者進試以確認產(chǎn)品或服務的功能。設計這種測試是為了證明這個功能符合某個規(guī)范。舉個例子，我的拍賣顯示的是輸入的正確出價嗎？我的保險經(jīng)紀人系統(tǒng)找到最便宜的報價了嗎？如果這些測試失敗，通常就意味著檢測到了產(chǎn)品的一個基本問題（這個問題通常是可以直接修復。這種測試也是適合簡單的Web服務，使您可以檢查服務是否能夠正確執(zhí)行它的各個功能。系統(tǒng)測試（SystemTest）通常是在功能驗證階段完成，驗證了功能后進行。它傾向于把整個系統(tǒng)作為一個整體來查找問題—弄清Web服務作為系統(tǒng)的一部分怎樣運作，以及Web服務相互之間如何交互。由于系統(tǒng)測試是在開發(fā)生命周期快結(jié)束時才進行，所以通常不能給它分配足夠的時間來完成。又因為緊張的日程安排以及開發(fā)的各個重要階段的后移，系統(tǒng)測試階段經(jīng)常被忽略，并且一些通常都可以發(fā)現(xiàn)的、少見的錯誤都不能被檢測到。即使發(fā)現(xiàn)了這種錯誤，這時也來不及確定錯誤的原因并設法修復它們了。因此，在查找代碼錯誤時，必需把系統(tǒng)測試應用設計得盡可能高效。系統(tǒng)測試通常由三部分組成，它們是：性能（Performance：這涉及到確定相關的產(chǎn)品統(tǒng)計數(shù)據(jù)的過程。例如：每秒有多少條消息？一個服務可同時接受多少個用戶？案例（Scenario：這是重新創(chuàng)建客戶所需的確切配置的過程。因此在案例中發(fā)現(xiàn)的任何問題都可以在客戶使用該產(chǎn)品之前被檢測出來。壓力（或稱工作負載平衡）：它與另兩個部分不同，因為它被設計為通過應用很大的工作負載來使軟件超負荷運轉(zhuǎn)。如果壓力測試通過對產(chǎn)品保持高強度的使用（但不超過性能統(tǒng)計數(shù)字確定的限制）的錯誤，而這些錯誤用上面提到的任何其他技術(shù)都是發(fā)現(xiàn)不了的（是最難修復的。從檢測代碼錯誤這方面來說，可以證明這三個系統(tǒng)測試組件中效率最高的是壓力測試部分。但由于這個過程經(jīng)常跟系統(tǒng)的其他要素或功能測試在一起，所以這個過程涉及到的方法還沒有被正確著手處理或?qū)崿F(xiàn)。壓力下的錯誤使用壓力測試，您有希望找到很多種用其他測試方法更難發(fā)現(xiàn)的錯誤。有兩種錯誤類型是：內(nèi)存泄漏（Memoryleak：一種極難檢測的現(xiàn)象。內(nèi)存泄漏經(jīng)常發(fā)生在已的產(chǎn)品中，原因很簡單，很難設計測試用例來檢測它們。使用簡單的功能測試，幾乎發(fā)現(xiàn)不了內(nèi)存泄漏問題，因為在產(chǎn)品完成之前測試沒對產(chǎn)品進行足夠多的使用。內(nèi)存泄漏通常要求操作要重復非常多的次數(shù)以使內(nèi)存消耗達到能引起注意的程度。盡管與其它編程語言（如C/C++）相比，Java程序更難引入內(nèi)存泄漏錯誤，但只要程序仍保持著對對象的，該對象仍有可能被實例化并且它占用的內(nèi)存不會被釋放。并發(fā)與同步（ConcurrencyandSynchronization）壓力測試在查找并發(fā)性問題上非常出眾，這是因為在任何一個測試生命周期中，它都應用了許多不同的代碼路徑和定時條件。一般的規(guī)則是，壓力測試運行的時間越長，涉及并應用的代碼路徑組合和定時條件就越多。當然，這也的確使得這些問題很難再現(xiàn)（5分鐘或5天后發(fā)生。死鎖、線程泄漏以及任何一般的同步問題通常只能在壓力測試階段被檢測出來。這些類型的問題很難通過執(zhí)行單元測試來發(fā)現(xiàn)。開發(fā)人員不會一直考慮他或代碼將與其他地方的代碼（在執(zhí)行單元測試時這些代碼可能還沒寫出來）進行交互。現(xiàn)有的壓力測試工具有許多聲稱能夠?qū)Ξa(chǎn)品進行壓力測試的可用工具目前正在開發(fā)中。被廣泛應用的是針對Web服務的那些工具。然而，這些工具中有許多只是簡單的HTML/SOAP生成器，它們模擬許多客戶機連接，并因此對Web服務器生成高負載（這對于查找Web服務器的問題很有用，但對于查找Web服務的問題就沒那么有用了。這些工具對基本的壓力測試比較有用，但它們經(jīng)常是僅僅擴展功能驗證階段來重復地執(zhí)行相同的功能任務。如果足夠的時間和資源可用，就可以通過創(chuàng)建定制構(gòu)建的壓力測試系統(tǒng)來實現(xiàn)更有效的測試。由于壓力系統(tǒng)的設計者通常對要測試的產(chǎn)品和Web服務有的了解，所以他們將能夠確保壓力系統(tǒng)可以用于哪些具體的代碼區(qū)域。設計壓力應用設計試圖對Web方式運行代碼。這些風格了功能驗證，目的是要弄清楚被測試的Web服務是不是不僅能做我們認為它能做的事，而且在被施加了某些高強度壓力的情況下仍然繼續(xù)正常運行。壓力測試必須對Web服務應用四個基本條件。許多已建立的壓力系統(tǒng)應用了這些條件。有效的壓力測試系統(tǒng)將應用以下這些關鍵條件：（Repetition：或許最明顯的且最容易理解的壓力條件就是測試的重復。換句話說，測試的重復就是一遍又一遍地執(zhí)行某個操作或功能，比如重復調(diào)用一個Web服務。功能驗證測試可以用來被弄清楚一個操作能否正常執(zhí)行。而壓力測試將確定一個操作能否正常執(zhí)行，并且能否繼續(xù)在每次執(zhí)行時都正常。這對于推斷一個產(chǎn)品是否適用于某種生產(chǎn)情況至關重要?？蛻敉ǔ貜褪褂卯a(chǎn)品，因此壓力測試應該在客戶之前發(fā)現(xiàn)代碼錯誤。許多最簡單的壓力系統(tǒng)只實現(xiàn)這一個條件，但簡單地擴展功能驗證測試來多次重復并不能構(gòu)成一個有效的壓力測試。當與下面的一些原則結(jié)合起來使用時，重復就可以發(fā)現(xiàn)許多隱蔽的代碼錯誤。并發(fā)（Concurrency：并發(fā)是同時執(zhí)行多個操作的行為。換句話說，就是在同一時間執(zhí)行多個測試，例如在同一個服務器上同時調(diào)用許多Web服務。這個原則不一定適用于所有的產(chǎn)品（比如無狀態(tài)服務，但是多數(shù)軟件都具有某個并為或多線程行為元素，這一點只能通過執(zhí)行多個代碼示例才能測出來。功能測試或單元測試幾乎不會與任何并發(fā)設計結(jié)合。壓力系統(tǒng)必須功能測試，要同時遍歷多條代碼路徑。至于怎么做到這一點取決于具體的產(chǎn)品。例如，一個Web服務壓力測試需要一次模擬多個客戶機。Web服務（或者任何多線程代碼）通常會多個線程實例間的一些共享數(shù)據(jù)。因額外方面的編程而增加的復雜性通常意味著代碼會具有許多因并發(fā)引起的錯誤。由于引入并發(fā)性意味著一個線程中的代碼有可能被其他線程中的代碼中斷，所以錯誤只在一個指令集以特定的順序（例如以特定的定時條件執(zhí)行時才會被發(fā)現(xiàn)。把這個原則與重復原則結(jié)合在一起，您可以應用許多代碼路徑和定時條件。量級（Magnitude壓力系統(tǒng)應該應用于產(chǎn)品的另一個條件考慮到了每個操作中的負載量。壓力測試可以重復執(zhí)行一個操作，但是操作自身也要盡量給產(chǎn)品增加負擔。例如，一個Web服務允許客戶機輸入一條消息，您可以通過模擬輸入超長消息的客戶機來使這個單獨的操作進行高強度的使用。換句話說就是，您增加了這個操作的量級。這個量級總是特定于應用的，但是可以通過查找產(chǎn)品的可被用戶計量和修改的值來確定它—例如，數(shù)據(jù)的大小、延遲的長度、數(shù)量的轉(zhuǎn)移、輸入速度以及輸入的變化等等。單獨的高強度操作自身可能發(fā)現(xiàn)不了代碼錯誤（僅能發(fā)現(xiàn)功能上的缺陷），但與其他壓力原則結(jié)合在一起時，您將可以增加發(fā)現(xiàn)問題的機會。隨化：最后一點，任何壓力系統(tǒng)都多多少少具有一些隨機性。如果您隨機使用前面的壓力原則中介紹的無數(shù)變化形式，您就能夠在每次測試運行時應用許多不同的代碼路徑。下面是幾個關于怎樣在測試生命周期內(nèi)改變測試的示例。使用重復時，在重新啟動或重新連接服務之前，您可以改變重復操作間的時間間隔、重復的次數(shù)，或者也可以改變被重復的Web服務的順序。使用并發(fā)，您可以改變一起執(zhí)行的Web服務、同一時間運行的Web服務數(shù)目，或者也可以改變關于是運行許多不同的服務還是運行許多同樣的實例的決定。量級或許是最容易更改的—每次重復測試時都可以更改應用程序中出現(xiàn)的變量（例如，發(fā)送各種大小的消息或數(shù)字輸入值。如果測試完全隨機的話，因為很難一致地重現(xiàn)壓力下的錯誤，所以一些系統(tǒng)使用基于一個固定隨機的隨化。這樣，用同一個，重現(xiàn)錯誤的機會就會更大。一個壓力測試通常會結(jié)合上述的所有原則，并且在允許的范圍內(nèi)盡可能長時間地運行。測試被允許的執(zhí)行時間越長，就可以遍歷越多的代碼路徑，并且發(fā)現(xiàn)的錯誤也越多。當然，一旦找到錯誤就必須診斷并修復它。由于一個代碼錯誤可以在壓力測試運行多日以后自己顯示出來，所以系統(tǒng)必須保證當出現(xiàn)錯誤時所有可用的調(diào)試信息都被生成—否則可能就必須花費同樣多的時間來重現(xiàn)這個錯誤。結(jié)束語 測試是軟件開發(fā)過程中至關重要的部分，并且一個重要的、經(jīng)常被曲解或忽略的部分是壓力測試。遵循上面詳細說明的原則，您就可以設計并實現(xiàn)有效的壓力測試系統(tǒng)，用來查找一些與您的代碼相關的、比較隱蔽的問題。無論是利用預先寫好的工具，還是創(chuàng)建一個完全的壓力系統(tǒng)，壓力測試都是用于查找Web服務（ 43《單元測試技術(shù)――Nunit3《測試管理――TD》2《自動測試工具――Robot2《自動測試工具――LoadRunner2六、強化測試用例在測試活動的作本文的目的不是將軟件測試流程優(yōu)化的話題闡述的面面俱到，而是從管理角度談談測試用例在測試活動中的重要性，以及測試用例管理流程的一些改進思路。常聞軟件測試者的如此抱怨：測試用例在實際中根本沒有起多大作用？測試人員在實際測試時都沒有按測試用例來執(zhí)行？測試執(zhí)行后沒有把需要更新的測試用例補充到用例庫中？當前國內(nèi)軟件企業(yè)測試流程不規(guī)范的原因分析：從事物的發(fā)展規(guī)律看，軟件測試行業(yè)在我國還是新興行業(yè)，目前還處于起步和探索期，雖然國外的業(yè)發(fā)展到了一定階段，但事實上他們也在不斷的否定自我并探索著更成方法、尋求著更有效的方案；而國內(nèi)的測試行業(yè)發(fā)展期不過10來年，所謂的測試管理流程不規(guī)范，也就情有可原了。從企業(yè)角度講，測試部門的整頓和加強，按照企業(yè)自身發(fā)展的優(yōu)先層次，還沒有被納入優(yōu)先解決的程度，開拓市場、簽訂定單才是首要問題，也是維系企業(yè)生存發(fā)展脈。當然國內(nèi)很多優(yōu)秀的大中型軟件公司的測試部門相對完善，如神州數(shù)碼、、聯(lián)想等，他們和大型軟件公司的合作，也從中汲取了寶貴的管理經(jīng)驗。還有一個普遍存在的問題。近幾年國內(nèi)軟件企業(yè)為了加強企業(yè)的競爭優(yōu)勢和名氣提升，通常大搞特搞ISO/CMM認證；筆者也很支持這么做，但更關注的是通過這些認證后的企業(yè)有多少真正按照那些規(guī)范、設計的標準在后續(xù)的測試或軟件開發(fā)管理工作中著手開展下去呢？社會上流傳著這樣的話：任何認中國，最后都免不了砸牌兒！筆者讀書時很多高校搞的MCSE認證，有培訓機構(gòu)明目張膽聲稱"百分百通過率"！當年也有專門此事。聽到這樣的話，我們都會寒心真心希望我們的軟件企業(yè)通過ISO/CMM后真正為企業(yè)的內(nèi)部軟件開發(fā)流程帶來一點新生的曙光。最后一個原因，是企業(yè)內(nèi)部測試管理人員和技術(shù)人員技能的不足，還有自身工作態(tài)度的不夠端正。有了再好的規(guī)范標準，沒人遵守不行！沒人實施不行！應該說，很多中小軟件企業(yè)的都或多或少的逐漸軟件測試的重要性和必要性，以及它的標準化、流程化的緊迫性，但也有很多的工程師、技術(shù)人員并不理會這套，常常在實際工作中投機取巧；也有很多測試管理人員后天的經(jīng)驗不足、技能不夠，對公司測試管理工作考慮，和開發(fā)工程師交流不充分，和上層反映不及時等等?？傊?，任何問題的出現(xiàn)都不是單方面的原因，從宏觀的社會形勢到微觀的企業(yè)個人，都有無可推卸的責任；正因為如此，解決問題也要對癥下藥，如何完善軟件測試流程，就要從小處出發(fā)；本文不可能將軟件測試流程優(yōu)化的話題闡述的面面俱到，因此只從管理角度談談測試用例在測試活動中的重要性，以及測試用例管理流程的一些改進思路。強化測試用例在測試活動的作測試用例在實際中沒有起多大作用,在實際測試時根本沒有按測試用例執(zhí)行，測試執(zhí)行后沒有把新的測試用例補充到用例庫中……為何如此？我們分析認為，根本原因是對測試用例重要性的認識不夠，測試流程不完善，針對測試用例的管理流程更不完善，從三個方面具體來說：測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的，是測試執(zhí)行環(huán)節(jié)的基本依據(jù)，如果這個依據(jù)不能足夠發(fā)揮它應起的作用，那是不是說這個依據(jù)不明確、依據(jù)設計的不合理呢？答案是肯定的！制定了完備有效的測試用例，為什么不按測試用例執(zhí)試呢？首先是因為企業(yè)沒有嚴格和良好的機制促使和保證測試執(zhí)行者這樣做；其次是個別測試人員投機取巧心理作祟的表現(xiàn)。測試用例設計得不可能天衣無縫，不可能完全滿足軟件需求的覆蓋要求，測試執(zhí)行過程里肯定會發(fā)現(xiàn)有些測試路徑或數(shù)據(jù)在用例里沒有體現(xiàn)，那么事后該將其補充到用例庫里，以方便他人和后續(xù)版本的測試；如果沒有這樣做，那么測試部門和每個測試員都難辭其疚，是該重新坐下來思考一下公司的測試用例管理規(guī)范和測試流程了。改進測試用例執(zhí)行過程那么究竟如何做，才能盡量避免上述問題呢？我們不妨從軟件開發(fā)周期的每個階段就把這些問題考慮進去，以便從初始就力爭將問題縮到最小，將其扼殺在萌芽階段，軟件需求分析階段，筆者從來認為測試人員從軟件生命周期的需求階段就開始介入。通常測試人員的測試工作開展在開發(fā)周期的末尾，如果前期不涉入，如何通曉整個系統(tǒng)的需求和架構(gòu)而對其充分測試呢？雖然該觀點被大多數(shù)所認可，但我知道依然有很多公司為了節(jié)省費用，不讓測試人員參與前期調(diào)研或制定需求，經(jīng)常的做法是等到系統(tǒng)開發(fā)完畢或?qū)⒔瓿?，跟測試經(jīng)理說一聲"這邊有個項目，你找?guī)讉€人來測試一下吧！"經(jīng)驗表明，這樣的做法實不可取。測試人員（指項目的測試和測試工程師）在需求階段的任務有：方法、原則等；更重要的是，對不可測或難以測試性問題要及時與客戶或項目經(jīng)理協(xié)調(diào)解決。全面了解系統(tǒng)需求，從客戶角度考慮軟件測試需要達到的驗證狀態(tài)，即何些功能點需重點測試、何些無需，以便將來制定測試計劃。推薦企業(yè)采用類似于IBMRationalRequisitepro（參考其官方說明：http /cn/software/rational/products/requisitepro/index.shtml）的需求管理工具來制定和管理軟件需求，同時需要測試人員的配合，保證對軟件測試環(huán)節(jié)的充分考慮。軟件分析設計階段，測試人員除制定測試計劃書等基本工作外，筆者認為還有一個相當必要的任務，那就是將系統(tǒng)的可測性到文檔，以備將來編寫測試用例。之所以要這么做，是因為考慮到很多企業(yè)編寫測試用例直接參考需求規(guī)格說明書或者分析流程圖，這樣跨度大，難度也大，是造成測試用例不完備、覆蓋范圍小的重要原因。如果公司采用類似于IBM Rational Rose（參考官方說明：http /cn/software/rational/products/rose/index.shtml的建模分析工具和 IBM Rational Rose XDE Developer（參考官方說明：http /cn/software/rational/products/xdedeveloper/index.shtml）的可視化設計開發(fā)環(huán)境，這個工作更好執(zhí)行；如果沒有，那么測試人員更有必要編寫一《軟件功能點測試描述書它是軟件的詳細測試分析文檔其主旨是將系統(tǒng)分析人員的開發(fā)分析文檔加工成以測試為角度的功能點分析文檔，重要的是描述對系統(tǒng)分解后每個功能點逐一的校驗描述，包括何種方法測試、何種數(shù)據(jù)測試、期望測試結(jié)果等這些信息都是描述性的無須具體數(shù)據(jù)它的作用是據(jù)此編寫測試用例以及測試執(zhí)行時的參考依據(jù)，基于它直接來源于需求，覆蓋當然最全，也最能貼近客戶要求。當然該文檔不是非要不可，筆者只是提倡一種原則，如果有類似的替代文檔或有工具可自動實現(xiàn)此功能，則會倍加受推崇！筆者之所以推薦IBMRational系列產(chǎn)品在軟件項目中的應用，是因為IBMRational倡導的RUP（RationalUnifiedProcess）方法論采用了用例驅(qū)動的原則。所謂用例驅(qū)動，是以體系結(jié)構(gòu)為中心，采用迭代、增量方式的開發(fā)過程；而其Rational工具系列正是將這一理念進行行為表述，是當前軟件工程領域一套無可比擬的強大工具集，從需求到測試，它都以用例為基本模型，全面貫穿軟件開發(fā)的每個環(huán)節(jié)。3）軟件開發(fā)階段，編寫測試用例。我不想從技術(shù)角度探討到底如何編寫功能強大、質(zhì)量優(yōu)秀的測試用例（可參考筆者主頁的"如何設計編寫軟件測試用例"），這里只想從管理角度和大家談談如何有效控制和增強測試用例在測試活動中的應用。應該遵守的原則是：首先，從覆蓋率來說，測試用例庫的用例要達到最大覆蓋軟件系統(tǒng)的功能點。按照我上述所言的方式，測試工程師從前期階段順次下來，編寫測試用例時，基本上就是將《軟件功能點測試描述書》中的每個功能點進行操作上的細化：一是從步驟上描述到達校驗點的方式，二是從內(nèi)容上描述以何種數(shù)據(jù)校驗功能點；如此可實現(xiàn)趨向最大需求覆蓋率。其次，從數(shù)量來講，筆者覺得很多公司的測試用例太少，甚至遠遠不能覆蓋系統(tǒng)需求，這也是很多測試人員在測試工作開展初期按照用例執(zhí)行、而后漸漸憑"意念"去執(zhí)試的原因。應該說測試用例的數(shù)量很難用數(shù)學模型來模擬，更沒辦法衡量，但憑借個人經(jīng)驗來說，一個多于半年開發(fā)周期（指從編碼開始直到提交客戶的時間段）的軟件系統(tǒng)，它的用例數(shù)量不要低于4000個，甚至！也許有人驚訝這一數(shù)字，不過了解IBM等大公司測試過程的會認為4000還是很少的數(shù)目。我們試想，對于一個中小型軟件系統(tǒng)，如果設計出5000個用例，那它的測試覆蓋率還怕不高么！再次，如此眾多測試用例的管理問題。是的，需要管理工具軟件！筆者從來都以word或excel來編寫測試用例：首先，格式上難于編寫--通常方式是企業(yè)自己設計表格模版，但編輯上始終存在不便，尤其對于一些共性內(nèi)容，如測試目標、測試環(huán)境、參考說明等，每次都要大量的、粘貼。其次難于管理--如果把幾千個文檔文件放在一個共享文件夾里，即便以子方式管理，但是每次查找一個特定用例，你的眼睛也必將飽受煎熬！更是難于執(zhí)行--莫非真要針對幾千個用例都是打開一個word-執(zhí)試-輸入測試結(jié)果-關閉word嗎？最重要的是，根本沒辦法追蹤測試結(jié)果--在本輪回歸測試輸入完，但是下一輪結(jié)果輸入到哪里？輸入了這些測試結(jié)果什么用？能方便的根據(jù)其結(jié)果統(tǒng)計軟件質(zhì)量嗎？還有，可以用它追蹤發(fā)現(xiàn)的軟件缺陷嗎？有辦法追蹤嗎？使用word等軟件編寫測試用例的種種不便大致如上但換個思路思考一下使用集成工具的種種優(yōu)勢便更加一見分曉。測試同業(yè)者們都了解的測試用例管理工具便是IBMRationalTestManager（查看官方說明： /cn/software/rational/products/testmanager/index.shtml），它是專業(yè)的測試用例管理和測試管理工具，其設計出發(fā)點就已經(jīng)考慮到了我們上述的種種困境，因此給予了良好的解決方案。以其為測試管理平臺，測試人團隊成員可以計劃、管理、組織、執(zhí)行、評詁以及報告等縱向測試活動，如果與IBMRational （查看官方說明： /cn/software/rational/products/clearquest/index.shtml）集成使用，還可即時軟件的需求變更，從而增強整個軟件團隊的橫向溝通與合作。而且，個人覺得測試行業(yè)的快速發(fā)展，必將帶來從每個環(huán)節(jié)都逐漸向自動化和標準化方向邁進，盡早適應這一趨勢，不僅提高了工作效率，也提高了企業(yè)的信譽和名譽。最后，一、是在測試管理工具中制定適合本公司的測試用例模版二、是用例模版里要有關鍵字索引，以方便按關鍵字分類查找，如測試方法（分手工自動兩種）三、是測試用例要有狀態(tài)，可根據(jù)用例執(zhí)行狀態(tài)索例（測試通過、測試失敗、測試中斷等）四、是執(zhí)行失敗的用例要到相應的缺陷報告，根據(jù)缺陷報告檢索測試用例的試圖更妙，可評估該缺陷影響范圍的大小五、是測試用例的修改，以及每個測試周期的運行都有日志記錄，以便后期追蹤和新員工參考軟件測試階段，測試劃分不同的測試階段（如集成測試、系統(tǒng)測試、回歸測試、性能測試等，再劃分不同的子測試周期（如前兩個星期做冒煙測試，測試方式是手工/自動，測試版本是**，測試環(huán)境是**，包括服務器端與客戶端等；接著做第一模塊功能測試；如此順次。），再為項目組測試人員分配測試用例（每個人負責幾塊區(qū)域的測試任務），測試人員則按照詳細的用例文檔去執(zhí)試，測試失敗則提交軟件缺陷報告。這里要遵循的幾個原則是：A）有健全且嚴格的體制保證測試執(zhí)行者嚴格按照測試用例執(zhí)試。這并不妨礙測試者創(chuàng)造力的發(fā)揮，因為前期用例的設計和編寫就是項目全體測試人員智慧的結(jié)晶！苦苦追尋眾多測試工程師加班加點辛苦工作的原因，其實大都發(fā)生這一階段；如此實施，即便沒有解決根本問題，也會大大提高測試執(zhí)行效率。B）對測試用例認識模糊或內(nèi)容遺漏的地方，可暫做記錄待后期解決，或經(jīng)測試與項目其他管理人員同意方可更新用例庫。測試每日負責本測試子周期或階段的測試用例執(zhí)行情況，以及每日提交的缺陷報告，根據(jù)執(zhí)行進展狀態(tài)以及缺陷數(shù)量或嚴重等級與項目或其他測試執(zhí)行者負責執(zhí)行自己區(qū)域的測試用例，還要負責該區(qū)域軟件缺陷的修改進展，根據(jù)其狀態(tài)不斷驗證軟件功能點。應該提及的是，大多數(shù)軟件公司都采用集成的缺陷管理工具來管理軟件缺陷，如MaonalClearQuet變更管理與缺陷管理工具等，這是值得稱頌的好跡象；這樣的集成工具都提供了清晰的報告模版及強大的追蹤功能，測試團隊的每一成員按照自己的角色和權(quán)限缺陷管理工具，并不斷軟件缺陷的狀態(tài)對于自動測試（包括自動化功能測試和性能、壓力測試，有一些特殊要點。本人的原則是自動化測試無須編寫測試用例，只要在編寫時將用例庫里適合或需要自動測試的用例的測試方法（不同工具可能名稱不同）設為自動即可，故而到此階段才提及自動化測試。自動化測試的實施方案有所不同，每款測試工具的使用和測試流程也不同，但都可以從在這一階段編寫測試，并運行自動測試。例如IBMRational Robot （參考官方說明http /cn/software/rational/products/robot/index.shtml）或XDEester（http /cn/software/rational/products/xde_tester/index.shtml，現(xiàn)更名為RationalFunctionalester。針對自動化測試原則，可參閱筆者的"自動化測試要點"譯文，這里要提的其他幾個基本原則是：二、是項目的自動化測試工作有專人負責，以保證工作質(zhì)量，他們可不參與日常測試；三、是確定自動化測試成員在項目中的角色，一般自動化測試成員隸屬于項目測試，同樣其工作狀態(tài)；四、是選擇最簡單、最重用的測試用例使用自動測試方法；五、是使用工具廠商提供的測試框架編寫，千萬別采用單純錄制-加校驗-回放的方式，以開發(fā)出健壯且重用性強的測試；六、是有專人更新，也有專人自動；七、是一般選擇的測試工具品牌和缺陷管理工具品牌是同一廠商，以方便不同類型缺陷的集中管理；八、是在多人協(xié)作開發(fā)測試、代碼量相對較大情況下，應考慮使用配置管理工具來管理測試腳本，IBMRationalClearCase（參考官方說明： /cn/software/rational/products/clearcase/index.shtml）是當前業(yè)界功能最強大的配置管理工具，可以將開發(fā)代碼和測試代碼都集中管理，進行高效的版本控制和工作空間管理，保證多人開發(fā)大量代碼的穩(wěn)定性。對于局域網(wǎng)范圍內(nèi)的開發(fā)工作，使用ClearCaseLT版足夠。由于不同公司開發(fā)產(chǎn)品的特殊性，也許需要特殊類型的測試，如安全測試、甚至代碼級單元測試等，這些內(nèi)容需要酌情考慮測試用例的編寫，以及測試的執(zhí)行。軟件驗收階段，除了提交軟件測試評估報告（各種類型的評估都應有報告）這些基本工作外，對于測試用例，此時要集中時間更新，更新整個測試周期中一切需要更新的內(nèi)容，以方便未來新版本的測試。即便您開發(fā)的是項目軟件--提交客戶后沒有新版本--那也需要后期，階段需要重新測試某功能點，然而用例如果確，碰巧又是一個新員工來做，那就死翹翹了退一步說，如果您公司的測試部門經(jīng)歷一次這樣重大的洗禮，有一個項目真正按照此原則實施一次，也必將對未來測試工作的開展發(fā)揮的作用、起到事半功倍的效果。其他說明：加強測試部門內(nèi)部人員的培訓教育很重要，包括工作技能與個人素質(zhì)兩方面，可通過國內(nèi)主要的培訓機構(gòu)，也可是工具廠商的直接培訓。應該說，很多測試新人對于測試用例的書寫還存在問題，更別提及測試用例的管理或執(zhí)行此可見，我們的測試工程師需要培訓的空間還很大。另外，筆者不贊成對人員的強制性管理，例如大張旗鼓整頓公司測試部門的管理，采取缺陷報告數(shù)和人員績效掛鉤、不按測試規(guī)范執(zhí)行就適當懲罰等；個人認為切不可急功近利，當，鼓勵+促進甚善然、甚妙哉！綜上所述，我們得出結(jié)論--測試用例在測試中沒起到應有的作用，是因為測試用例編寫質(zhì)量不高，覆蓋不夠，執(zhí)行不利；測試執(zhí)行時不遵循測試用例，執(zhí)行后不更新用例庫，是測試部門的整體工作流程不健全、不規(guī)范；至于如何解決，筆者提出了微薄建議，供業(yè)界朋友參考與交流。國內(nèi)軟件測試行業(yè)目前仍處在群雄逐鹿、百家的時期，蕓蕓紛說，不如從企業(yè)自身出發(fā)，確立最適合自我的測試管理解決方案，整頓自身的測試工作流程，那才是金玉良言的上上策！【作者簡介】網(wǎng)名Sink，本名張振興，是的一名測試工程師，擅長軟件功能測試和和自動化功能測試，也從事過白盒測試、性能測試與測試管理工作，BMatinal工具套件和RUP理論具有深入的了解和研究，年也積累了一定測試經(jīng)驗和測試思想，此給業(yè)界。七、高手過招的樂---測試用例預演：高手過招，手中無需用劍，只要輕描淡寫地以口代手，三兩句話便高下立判，勝的方法，用模擬的測試用例執(zhí)行發(fā)現(xiàn)程序中潛在的問題，竟有何神奇呢？請見內(nèi)文。武俠小說中的高手大抵有三個層次，第一個級別是“靜若處子，動如脫兔，身負成名絕技”的高手，印象中這一個級別的基本是或是性情豪爽的江湖俠客，這種人一旦遇到，打殺的場面最為宏偉，刀槍不絕，各出奇招，直到一方倒地或是被制；境界，這種高手若是過招，全不聞金戈，全無殺伐之意，輕描淡寫的以口代手，三兩句話便高下立判，贏的贏得痛快，輸?shù)妮數(shù)脼t灑，在武俠中看到此，常不免心潮澎湃，艷羨不已，巴不得自己也能有這個機會一嘗絕頂高手之間的這種至高默契?？上頌殚_發(fā)或是測試工程師，又出生在這個真實的世界，恐怕實在是不太會有機會這種所幸，我們雖不能飛進武俠小說嘗試這種生活，卻能在我們的測試工作中體會到這種樂趣。真耶？假耶？且與我一起，探究個究竟?；氐轿覀兊念}目“高手過招的樂趣——測試用例預演”，這里我要是一種可以讓你體會到高手過招樂趣的方法：“測試用例預演”。且慢試圖在頭腦中搜索你對這種方法的印象，因為這是我自創(chuàng)的名詞（申明：如果很不幸你通過其他途徑確實聽到或是見過這種描述，請一定告知本人，本人會慎重考慮，至少到目前為止，我還能有把握地說這是我首先命名和以正式文檔描述的法。之所以把這種算不上十分復雜的方法寫下來，是因為本人在實際的工作中發(fā)現(xiàn)該方法確實能起到比較大的作用，而且更重要的是，那種高手過招的感覺，很希望能和有高手夢的朋友能夠感受得到。測試用例預演是一種非正式的測試用例執(zhí)行方法，概括說來，這種方法是無需通過測試用例的真正執(zhí)行（靜態(tài)或是動態(tài)執(zhí)行），而只需要開發(fā)人員和測試人員之間的口頭交流，就能發(fā)現(xiàn)被測系統(tǒng)中存在的問題。設想一下，無需動手（測試執(zhí)行，通過以口代手（開發(fā)和測試人員之間的口頭交流（），這不是高手過招是什么？測試用例預演的一般步驟是測試工程師與開發(fā)工程師以某種方式坐在一起，進入交流狀態(tài)，這個過程中需要盡可能避免干擾，比較好的時機是坐在一起進餐的時候；不要偏離測試用例太遠，可以考慮一些在測試用例中沒有明確寫明的異常情況處理；的響應即可，不需要描述具體的實現(xiàn)方法；測試工程師仔細聆聽開發(fā)工程師的回答，需要對開發(fā)工程師的答復敏銳反應，不放過任何一個開發(fā)人員的遲疑，對拿的問題應該記錄并需要馬上驗證；雙方繼續(xù)預演直到預期的預演時間結(jié)束或是有一方感到疲倦；記錄預演過程中發(fā)現(xiàn)的問題到缺陷庫。只有一個：系統(tǒng)的缺陷，這點務必要牢記，以免弄錯了對手，傷了和氣。測試用例預演不是一種復雜的方法，但根據(jù)我的經(jīng)驗，要想在實際工作中應用這種方法并取得較好的效果，必須了解這種方法的適用范圍，遵循一定的使用方法，并需要注意一定的技巧。這里我以 FAQ的方式提供秘笈一部，各位請留意：Q：測試用例預演可以取代測試執(zhí)行嗎？A：這個問題是我捏造出來的，大概不會有人真的這么認為，不