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

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