qileilove

　　一、自動化測試用例應用

　　手工測試用例是針對手工測試人員，自動化測試用 例是針對自動化測試框架，前者是手工測試用例人員應用手工方式進行用例解析，后者是應用腳本技術進行用例解析，兩者最大的各自特點在于，前者具有較好的異 常處理能力，而且能夠基于測試用例，制造各種不同的邏輯判斷，而且人工測試步步跟蹤，能夠細致的定位問題。而后者是完全按照測試用例的方式測試，而且異常 處理能力不強，往往一個自動化測試用例運行完畢后，報一堆錯誤，對于測試人員來定位錯誤是一個難點，這樣往往發(fā)現(xiàn)的問題很少。所以，根據(jù)其各自的特點，需 要將兩者有很好的定位：手工測試是在軟件版本前幾輪測試的重點，目的是驗證功能，發(fā)現(xiàn)問題；自動化測試是應用在后幾輪版本，保證軟件版本模塊修改或者添加 新功能后，沒有影響開始的功能模塊（因為軟件中，各模塊之間的接口以及類、函數(shù)方法等的互相引用，也是容易出問題的地方）。

　　二、自動化測試用例設計發(fā)展

　　1、自動化測試用例設計發(fā)展前期

　　記得，當時的自動化測試開展是針對測試設備設計一套測試環(huán)境系統(tǒng)，用于自動化例行測試，根據(jù)此，專門撰寫了一套自動化測試用例，并轉化成自動化測試腳本。之后整套系統(tǒng)都失敗了，失敗原因包括：

　 　a、系統(tǒng)太過于龐大，測試用例也過于繁瑣，每次測試運行下來，測試結果都夾雜著一大堆各種錯誤，有可能是產品問題，有可能是腳本問題，也有可能是用例問 題，這樣下來，測試人員每次運行一遍都要面對大量的問題，維護的幾次就放棄了，問題越來越多，根本沒辦法去定位，這樣反而浪費了大量的成本和時間。

　　b、搭建的一套測試環(huán)境系統(tǒng)，各個產品功能模塊都互相聯(lián)系在一起，都互相有影響，容易造成問題。

　　c、更重要的是，由于是單獨搭建的一套測試環(huán)境系統(tǒng)，其自動化測試用例與手工測試用例沒有太大關系，這樣就造成了其自動化測試很難對手工測試進行輔助。

　　2、自動化測試用例設計發(fā)展前中期

　 　這時，自動化測試用例來源于手工測試用例，首先，自動化測試根據(jù)手工測試用例進行轉換而來（舉個例子：CLI測試時，自動化測試用例是根據(jù)手工測試用例 的步驟，將其需要輸入的CLI命令和回顯進行填寫），之后，自動化測試腳本人員根據(jù)其自動化測試翻譯為腳本。這樣做的好處就是手工測試用例與自動化測試用 例的結合，保證了自動化測試的明確性，后期的改進還包括

　　a、將自動化測試用例根據(jù)手工測試用例進行了分層，把一些共性功能和全局變量抽象到了更上一層，保證復用性和降低維護性。

　　b、設計的自動化測試框架的管理。

　　經(jīng)過一段時間之后，問題還是很大，主要問題在于

　 　1）前期為了追求自動化測試覆蓋率，往往忽視了自動化測試用例的質量，大家想想，出產一個自動化測試項目，得經(jīng)過手工測試用例—自動化測試用例—自動化 測試腳本三個階段，而自動化測試用例是手工測試人員來撰寫，因為其懂業(yè)務；自動化測試腳本是由專門的自動化測試人員撰寫，但是這導致了一個項目出產的周期 長（需要經(jīng)過兩個階段，而且還要反復調試），而且由于經(jīng)過了兩個階段，所以伴隨問題也多了，特別是接口這方面，往往由于兩者的溝通和認知問題，使得自動化 測試項目的發(fā)布后還隱藏大量問題，往往使測試人員疲于調試和維護。

　　3、自動化測試用例設計發(fā)展中期

　　在這個過程中，最好的是測試人員能夠根據(jù)自動化測試框架與平臺來自行進行測試腳本的設計，往往在前幾輪的測試中，手工測試人員就能在手工測試的同時將自動化測試腳本設計了出來

　　a、錄制就是這樣一種思想，測試人員在測試過程中，本身就是在測試過程中，將測試人員的測試過程進行了記錄，所以，我的想法一直是，錄制的方向是沒錯的。

　　b、而針對CLI測試，也可以制作了這么一個錄制工具，就是模擬制作一個超級終端，測試人員應用其進行手工測試，其工具自動記錄其命令行操作， 而且手工測試人員能進行回顯的需要匹配的某一個字段進行選擇，然后在后臺根據(jù)模板，自動生成一個自動化腳本，之后測試人員自行進行維護即可，這樣可以縮減 環(huán)節(jié)，降低出錯幾率和維護問題。

　　c、當然，要做到這一步，一個強大的自動化測試框架和平臺是其支撐，我曾經(jīng)做過一個基于GUI的自動化測試框架，部門里面也動員過一次試用，每 個產品線都出了一兩個人進行腳本開發(fā)，測試人員往往對腳本開發(fā)沒什么太大興致，更多的是一種好奇，而且調試工作大多是我做的，整整10多個產品線，調試了 我大部分時間，因此其難點本身不是在于腳本的開發(fā)，因為當時測試人員開發(fā)出這些腳本是很快的事情，其真正難點在其測試人員的調試和維護方面，而且測試人員 往往疲于去進行這方面，他們在乎的是測試和業(yè)務本身，要協(xié)調這方面的沖突是一件很難的事情，需要不斷思考和總結吧。

　　4、自動化測試用例設計發(fā)展中后期

　　留一個中后期，現(xiàn)在的自動化測試用例設計發(fā)展還是很淺，還需要一個長遠的發(fā)展過程，中后期發(fā)展成什么形式，因為見識有限，所以請大家積極猜想啦。希望能給我?guī)硪恍┮娮R和想法。

　　三、一些感想

　　下面感想僅我個人之言：自動化測試就本身而言，其實技術方面的前瞻性是需要的，但是自動化測試確實是一個長期的過程，對自動化測試的定位很重 要，然后是一系列的細節(jié)問題，每一個問題都是需要值得重視的問題；定位、細節(jié)、技術真的都是缺一不可啊，而且還要把握這么一個平衡，想到自己以前注重需 求，后到注重技術，后又因為技術懷疑需求，最后又回歸到認識需求，短短時間，總有變化，現(xiàn)在想想，三者，技術是基礎，需要不斷學習，但卻不能看的太遠而忽 略了現(xiàn)在的最重要的需求，在實現(xiàn)現(xiàn)在需求的同時，不斷步步跟進，進行探索。自動化測試還真是一個“步步驚心”的過程啊。

版權聲明：本文出自 散步的SUN 的51Testing軟件測試博客：http://www.51testing.com/?382641

eclipse中配置SVN 1.先安裝一個Subclipse，地址：http://subclipse.tigris.org/ 2.可以通過Eclipse的Update Site安裝方式：http://subclipse.tigris.org/update_1.4.x或者下載下來之后，解壓縮復制到Eclipse目 錄即可。

    3.啟動程序后在Eclipse配置項的Team里面就會多出SVN，就可以進行配置了。

第一步：eclipse->window->open Perspective->other

第二步：配置svn資源
新建一個svn資源庫，finish

 第三步：檢出項目http://www.svn8.com

 

      4.想要提交一個項目，對項目點擊右鍵Team——Share project就可以將項目導入SVN了

ECLIPSE中SVN客戶端(subclipse)的安裝和配置

2009-04-16 06:35

   subclipse是Eclipse的SVN插件，通過subclipse在Eclipse中就對SVN進行管理（提交、更新、合并、切換分支等等）。這篇文章介紹的就是如何安裝和配置subclipse。
安裝
   訪問網(wǎng)頁 http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA 選擇你對應的Eclipse的插件下載地址（Eclipse update site URL）。之后就是簡單地調用Eclipose的插件安裝程序了。
  

配置SVN庫
   插件安裝完成以后，重啟Eclipse，選擇Open SVN Perspective
      

在SVN Perspective中你就可以配置需要使用的SVN資源庫了。

SVN資源添加完畢以后，你就可以通過Eclipse瀏覽資源庫了。

建立工程

通過選擇你想Checkout的SVN路徑點擊右鍵，在彈出的菜單中選擇“Checkout”檢出，依據(jù)Eclipse的提示你就可以將Checkout的內容作為Eclipse的項目了。

恭喜大家通過以上步驟完成了Eclipse中SVN插件(subclipse)的安裝以及通過subclipse 建立了Eclipse項目，下面這個步驟是在Eclipse中設置subclipse相關的快捷方式以提高大家使用subclipse的效率。

快捷方式設置   
   在Eclipse中可以對常用的subclipse功能設置快捷方式以提高大家的工作效率。點擊Eclipse->Windows->Preferences->Gerneral->Keys，大家看到如下一個頁面。
  

在這個窗口中對Category進行排序，找到SVN對用的功能項（提交、更新等功能一應俱全）。選中你想要設置快捷方式的功能項，并在對應的Binding輸入框中鍵入你想要的快捷方式，以上圖為例，我將更新功能的快捷方式設置成了Alt+U

總結
以上就ECLIPSE中SVN客戶端(subclipse)的安裝和配置的全過程了，?？吹奖疚牡耐瑢W操作順利。

　　并發(fā)性能測試的種類取決于并發(fā)性能測試工具監(jiān)控的對象，以QALoad自動化負載測試工具為例。軟 件針對各種測試目標提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、 Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrīpt等不同的監(jiān)控對象，支持Windows和UNIX測試環(huán)境。

　　最關鍵的仍然是測試過程中對監(jiān)控對象的靈活應用，例如目前三層結構的運行模式廣泛使用，對中間件的并發(fā)性能測試作為問題被提到議事日程上來，許多系統(tǒng)都采用了國產中間件，選擇Java scrīpt監(jiān)控對象，手工編寫腳本，可以達到測試目的。

　　采用自動化負載測試工具執(zhí)行的并發(fā)性能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例制定，測試環(huán)境準備，測試腳本錄制、編寫與調試，腳本分配、回放配置與加載策略，測試執(zhí)行跟蹤，結果分析與定位問題所在，測試報告與測試評估。

　　并發(fā)性能測試監(jiān)控的對象不同，測試的主要指標也不相同，主要的測試指標包括交易處理性能指標和 UNIX資源監(jiān)控。其中，交易處理性能指標包括交易結果、每分鐘交易數(shù)、交易響應時間（Min：最小服務器響應時間；Mean：平均服務器響應時 間；Max：最大服務器響應時間；StdDev：事務處理服務器響應的偏差，值越大，偏差越大；Median：中值響應時間；90％：90％事務處理的服 務器響應時間）、虛擬并發(fā)用戶數(shù)。

　　性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測 試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指 標的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。

　　一、概述

　　性能測試在軟件的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟件評測中心將性能測 試概括為三個方面：應用在客戶端性能的測試、應用在網(wǎng)絡上性能的測試和應用在服務器端性能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統(tǒng)性 能全面的分析和瓶頸的預測。

　　·應用在客戶端性能的測試

　　應用在客戶端性能測試的目的是考察客戶端應用的性能，測試的入口是客戶端。它主要包括并發(fā)性能測試、疲勞強度測試、大數(shù)據(jù)量測試和速度測試等，其中并發(fā)性能測試是重點。

　　并發(fā)性能測試是重點

　　并發(fā)性能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到系統(tǒng)的瓶頸或者不能接收 的性能點，通過綜合分析交易執(zhí)行指標和資源監(jiān)控指標來確定系統(tǒng)并發(fā)性能的過程。負載測試（Load Testing）是確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)組成部分的相應輸出項，例如通過量、響應時間、CPU負載、內存使 用等來決定系統(tǒng)的性能。負載測試是一個分析軟件應用程序和支撐架構、模擬真實環(huán)境的使用，從而來確定能夠接收的性能過程。壓力測試（Stress Testing）是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。

　　并發(fā)性能測試的目的主要體現(xiàn)在三個方面：以真實的業(yè)務為依據(jù)，選擇有代表性的、關鍵的業(yè)務操作設計 測試案例，以評價系統(tǒng)的當前性能；當擴展應用程序的功能或者新的應用程序將要被部署時，負載測試會幫助確定系統(tǒng)是否還能夠處理期望的用戶負載，以預測系統(tǒng) 的未來性能；通過模擬成百上千個用戶，重復執(zhí)行和運行測試，可以確認性能瓶頸并優(yōu)化和調整應用，目的在于尋找到瓶頸問題。

　　當一家企業(yè)自己組織力量或委托軟件公司代為開發(fā)一套應用系統(tǒng)的時候，尤其是以后在生產環(huán)境中實際使 用起來，用戶往往會產生疑問，這套系統(tǒng)能不能承受大量的并發(fā)用戶同時訪問? 這類問題最常見于采用聯(lián)機事務處理(OLTP)方式數(shù)據(jù)庫應用、Web瀏覽和視頻點播等系統(tǒng)。這種問題的解決要借助于科學的軟件測試手段和先進的測試工 具。

　　舉例說明：電信計費軟件

　　眾所周知，每月20日左右是市話交費的高峰期，全市幾千個收費網(wǎng)點同時啟動。收費過程一般分為兩 步，首先要根據(jù)用戶提出的電話號碼來查詢出其當月產生費用，然后收取現(xiàn)金并將此用戶修改為已交費狀態(tài)。一個用戶看起來簡單的兩個步驟，但當成百上千的終 端，同時執(zhí)行這樣的操作時，情況就大不一樣了，如此眾多的交易同時發(fā)生，對應用程序本身、操作系統(tǒng)、中心數(shù)據(jù)庫服務器、中間件服務器、網(wǎng)絡設備的承受力都 是一個嚴峻的考驗。決策者不可能在發(fā)生問題后才考慮系統(tǒng)的承受力， 預見軟件的并發(fā)承受力， 這是在軟件測試階段就應該解決的問題。

　　目前，大多數(shù)公司企業(yè)需要支持成百上千名用戶，各類應用環(huán)境以及由不同供應商提供的元件組裝起來的復雜產品，難以預知的用戶負載和愈來愈復雜的應用程序，使公司擔憂會發(fā)生投放性能差、用戶遭受反應慢、系統(tǒng)失靈等問題。其結果就是導致公司收益的損失。

　　如何模擬實際情況呢? 找若干臺電腦和同樣數(shù)目的操作人員在同一時刻進行操作，然后拿秒表記錄下反應時間？這樣的手工作坊式的測試方法不切實際，且無法捕捉程序內部變化情況，這樣就需要壓力測試工具的輔助。

　　測試的基本策略是自動負載測試，通過在一臺或幾臺PC機上模擬成百或上千的虛擬用戶同時執(zhí)行業(yè)務的 情景，對應用程序進行測試，同時記錄下每一事務處理的時間、中間件服務器峰值數(shù)據(jù)、數(shù)據(jù)庫狀態(tài)等。通過可重復的、真實的測試能夠徹底地度量應用的可擴展性 和性能，確定問題所在以及優(yōu)化系統(tǒng)性能。預先知道了系統(tǒng)的承受力，就為最終用戶規(guī)劃整個運行環(huán)境的配置提供了有力的依據(jù)。

　　并發(fā)性能測試前的準備工作

　　測試環(huán)境：配置測試環(huán)境是測試實施的一個重要階段，測試環(huán)境的適合與否會嚴重影響測試結果的真實性 和正確性。測試環(huán)境包括硬件環(huán)境和軟件環(huán)境，硬件環(huán)境指測試必需的服務器、客戶端、網(wǎng)絡連接設備以及打印機/掃描儀等輔助硬件設備所構成的環(huán)境；軟件環(huán)境 指被測軟件運行時的操作系統(tǒng)、數(shù)據(jù)庫及其他應用軟件構成的環(huán)境。

　　一個充分準備好的測試環(huán)境有三個優(yōu)點：一個穩(wěn)定、可重復的測試環(huán)境，能夠保證測試結果的正確；保證達到測試執(zhí)行的技術需求；保證得到正確的、可重復的以及易理解的測試結果。

　　測試工具：并發(fā)性能測試是在客戶端執(zhí)行的黑盒測試，一般不采用手工方式，而是利用工具采用自動化方 式進行。目前，成熟的并發(fā)性能測試工具有很多，選擇的依據(jù)主要是測試需求和性能價格比。著名的并發(fā)性能測試工具有QALoad、LoadRunner、 Benchmark Factory和Webstress等。這些測試工具都是自動化負載測試工具，通過可重復的、真實的測試，能夠徹底地度量應用的可擴展性和性能，可以在整 個開發(fā)生命周期、跨越多種平臺、自動執(zhí)行測試任務，可以模擬成百上千的用戶并發(fā)執(zhí)行關鍵業(yè)務而完成對應用程序的測試。

　　測試數(shù)據(jù)：在初始的測試環(huán)境中需要輸入一些適當?shù)臏y試數(shù)據(jù)，目的是識別數(shù)據(jù)狀態(tài)并且驗證用于測試的 測試案例，在正式的測試開始以前對測試案例進行調試，將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環(huán)節(jié)時，非常有必要進行數(shù)據(jù)狀態(tài)的備份。制造 初始數(shù)據(jù)意味著將合適的數(shù)據(jù)存儲下來，需要的時候恢復它，初始數(shù)據(jù)提供了一個基線用來評估測試執(zhí)行的結果。

　　在測試正式執(zhí)行時，還需要準備業(yè)務測試數(shù)據(jù)，比如測試并發(fā)查詢業(yè)務，那么要求對應的數(shù)據(jù)庫和表中有相當?shù)臄?shù)據(jù)量以及數(shù)據(jù)的種類應能覆蓋全部業(yè)務。

　　模擬真實環(huán)境測試，有些軟件，特別是面向大眾的商品化軟件，在測試時常常需要考察在真實環(huán)境中的表現(xiàn)。如測試殺毒軟件的掃描速度時，硬盤上布置的不同類型文件的比例要盡量接近真實環(huán)境，這樣測試出來的數(shù)據(jù)才有實際意義。

　　并發(fā)性能測試的種類與指標

　　并發(fā)性能測試的種類取決于并發(fā)性能測試工具監(jiān)控的對象，以QALoad自動化負載測試工具為例。軟 件針對各種測試目標提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、 Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrīpt等不同的監(jiān)控對象，支持Windows和UNIX測試環(huán)境。

　　最關鍵的仍然是測試過程中對監(jiān)控對象的靈活應用，例如目前三層結構的運行模式廣泛使用，對中間件的并發(fā)性能測試作為問題被提到議事日程上來，許多系統(tǒng)都采用了國產中間件，選擇Java scrīpt監(jiān)控對象，手工編寫腳本，可以達到測試目的。

　 　最近在Weinberg（對，還是他，可見我讀書多么慢）的《becoming a technical leader》書中看到一段話，提到他對于培訓的一點心得，他對于成功與否的判斷標準是受眾在其后對于這個領域的關注度是提高了還是下降了。我也希望在我 們這個系列的課程結束之后，大家對于這一塊有了更多的認識和了解，也愿意去更深入的學習和實踐。總之，希望會有一些幫助。

　 　昨晚上完第一次overview的課后坐地鐵回家，碰到一位來上課的同事，他對于我在課上提到的和性能測試相關的幾個觀念有一些印象?？磥恚啙嵉臍w納 是有助于傳播的，可能比一堆的checklist更容易讓人記住和獲取一些新的想法。這里也整理一下發(fā)出來供大家參考。

　　1. 精確和模糊

　　這是困擾很多性能測試人員的一個問題。因為基本上性能測試都需要得到一個精確的量化的結果，比如：

　　a. 系統(tǒng)可以支持10，000個并發(fā)連接

　　b. 每秒鐘可以處理80封電子郵件

　　c. 可以支持3000人同時瀏覽網(wǎng)頁

　　......

　　類似的數(shù)據(jù)可能出現(xiàn)在需求中，也可能出現(xiàn)在測試的結果里面。使得我們認為，相比功能測試或者穩(wěn)定性測試而言，性能測試是一種要求精確的測試。

　　但是，真的是這樣嗎？ 試著回答下面這個問題：

　　一輛汽車開100公里需要多少汽油？

　　直覺上你會說不同的車不一樣，對，這是好的開始，那好，就確定是某一臺確定的車，不僅是型號，就是門口的某一臺。

　　嗯，怎么樣？開始犯難了吧，特別是如果你是一個嚴謹?shù)娜恕Ｒ驗槟愕拇竽X開始快速列出下列條件：

　　1. 坐幾個人，帶多重的物品？

　　2. 路況如何，是高速還是擁擠的市區(qū)？

　　3. 天氣如何，溫度如何，要開空調嗎？

　　4. 駕駛習慣是怎樣的？

　　......

　　還有很多，越有經(jīng)驗的人可以列出越多，想想F1調整一下尾翼的角度就可以改變下壓力之類的事情。天哪，我要開一個長長的清單。

　　到現(xiàn)在，你還覺得性能測試是一個精確的測試嗎？也許問題出在有太多的前置條件，它們或大或小的影響著測試的結果。

　　所以呢，我們應該怎么辦？這是對很多新參與性能測試的人來說最難的問題，而不是那些看起來復雜的工具。大家常會問：我怎么知道該用什么樣的sample？

　　關于這些前置條件，或者我們稱之為假設（assumption），我把一些做法歸為三個階段。

　　Stage 1：做了假設卻不知道自己做了假設

　　比如前面提到的那個油耗的問題，有人的做法是我就開100公里看看，得出來是多少就是多少，比如9L。然后我就告訴別人這個車的100公里油耗就是9L。

　 　問題是這樣的結果對你是OK，因為你有切身的體驗，知道遇到的狀況，可是測試的報告是要給別人，甚至你都無法直接面對或者溝通的人參考。這就會很容易誤 導別人，即便這不是你的本意，而且你自己也確定你是真實的記錄了結果。這里的問題在于你并不清楚自己所做的假設，因為我們一直在做這樣的假設。

　　想想來杭州有半年了，也對目前主站的性能評測團隊工作模式有些許了解了，再加上以前在上家雇主也做過幾年自認還算很有技術含量的性能測試工作，我想我還算有點資格說的吧：）

　　性能測試說的裝B點兒，其實沒啥，就是和Response Time（或者說latency）、throughput（也可以說capacity）以及scalability打交道。弄懂了這三個要素，應該就算是一個合格的性能測試工程師了。

　　當然，我不會裝B，只是一介武夫，所以我接下來只想從偏技術層面聊聊我心目中真正的主站性能測試工程師是啥樣的：

　　1、大局觀。性能測試工程師一定要有系統(tǒng)化的思維，要站在整個系統(tǒng)測試的 角度看問題。一個優(yōu)秀的性能工程師必須要有相當?shù)闹R廣度。否則在測試期間，你必須依賴外界援助（比如DBA，Dev或OPS）來協(xié)助，效率不高，更關鍵 的是可能會被誤導，漏掉很多性能BUG。我常?？吹浇M里的童鞋們在壓測時一看到TPS降了，就死盯著應用，就著急的去分析線程或做CPU Profiling。找不到原因后有時問到我時，我習慣的第一句總是 你看過DB么？確認DB端正常么？看過壓測客戶端么？確認壓測端正常么？ 我個人意見：不要老憑經(jīng)驗，一有重復癥狀就思維定式；一定要堅持先從全局看問題，隔離到是應用層面、DB層面抑或是壓測客戶端層面后再進一步深入定位問 題。

　　2、技能深度。在性能測試工具方面有自己獨特的理解；同時也應該在操作系統(tǒng)、數(shù)據(jù)庫、應用程序等方向的配置管理與調優(yōu)方向上非常的熟悉。

　　3、敏感。這個一方面是天賦，一方面是經(jīng)驗積累吧， 很多隱蔽的性能問題確實是需要豐富的經(jīng)驗才能發(fā)現(xiàn)，極容易漏掉：）

　　4、興趣。其實這條才是最重要的^-^

　　如果說具體些通俗些，我眼里主站真正的性能工程師是這樣的：

　　1、熟悉Java（包括JVM內在機理）/c/c++。理由很簡單，主站大部分的外圍應用和中間件都是JAVA寫的，底層核心系統(tǒng)是c/c++寫的。

　　2、精通linux管理和shell編程。理由更簡單，我一直覺得，shell熟練與否非常大程度決定了一個工程師的工作效率。

　　3、對數(shù)據(jù)庫管理和性能優(yōu)化有自己的實踐和心得（數(shù)據(jù)庫永遠是個性能要點）

　　4、精通某一個性能測試工具。不止是使用，更包括原理，如何改造擴展。

　　5、熟悉linux kernel的實現(xiàn)（比如內存管理、文件系統(tǒng)、系統(tǒng)調用… ）。這條感觸在最近兩個月特別深，可能是受到褚霸、子團等大俠們的影響吧，如果不熟悉kernel，確實很難在底層系統(tǒng)的性能測試上有所真正建樹。其實這塊也算是整個質量保證部的技術短板吧，現(xiàn)在淘寶的linux內核組都是自測+他人review的形式，如果。。。^-^

　　6、了解常見硬件，特別是存儲相關。這塊主要是受國外Percona公司的Peter和Vadim影響，他們能成為世界公認的mysql性能專家，他們熟悉mysql源碼當然很重要，但也與他們那非常淵博的底層硬件知識是分不開的。

　　當然以上都是我個人意見，從我自己的角度出發(fā)看的問題。其實性能測試還有很多領域，比如前端性能測試這塊，我是小白，就不發(fā)表任何相關意見了^-^  但說到底，做性能這塊關鍵一是經(jīng)驗積累二是掌握相關底層技術

　　至今還記得百淘65期讓我最為難忘的細節(jié)，達人青云在分享他的牛P經(jīng)歷時總結到的：

　　● 結合優(yōu)勢，做別人做不了的

　　● 發(fā)現(xiàn)問題，做別人沒做過的

　　● 主動出擊，做別人不愛做的

　　希望自己能一直銘記這三句話，有天能成為一個真正的性能工程師

　　大多數(shù)Java開發(fā)人員都善于解決邏輯結構測試問題，比如如何建立測試預設環(huán)境、利用斷言？添加測試方法、用setup方法進行初始化等。然而，如果Java開發(fā)人員能更深入地了解如何設計功能測試集來有效地檢驗代碼是否正常運行，他們將獲得更多的益處。

　　這篇文章介紹了可以建立有效 JUnit功能測試集的策略。包括：

　　確定測試用例覆蓋所有程序行為。

　　確定代碼入口點：測試程序整體功能的主要代碼段。

　　匹配入口點與相應的測試用例。

　　根據(jù)初始化 /運行/檢查流程創(chuàng)建測試用例。

　　設計并利用運行時事件表進行測試。

　　我將結合Saxon（一個可以處理XPath、XQuery和XSLT 的XML工具）的源代碼來具體闡述這些策略。Saxon由約50000行Java代碼組成，它是開源的，代碼風格優(yōu)良，注釋文檔詳盡。

　　確定用例

　　功能測試有兩個相輔的目標：覆蓋率與粒度。為確保完整性，功能測試必須覆蓋程序提供的所有功能，且必須在各組件水平上分別進行測試。一個測試可以建立在另一個測試的基礎上，但任何測試都不能用來驗證兩項功能。

　　建立一個全面的功能測試集，第一步是列出程序可以實現(xiàn)的所有行為。這可以通過使用特定的用例模擬外部因素（程序使用者或其它軟組件）執(zhí)行系統(tǒng)內部的功能來實現(xiàn)。

　　一個典型的企業(yè)Java程序應該包含各種用戶所需的詳細文檔，包括用例說明、非功能性要求、測試用例說明、用戶界面設計文檔、模型、用戶個人信息以及其它各種人工生成的信息。一般來說簡單的應用程序只有一個簡單的說明文檔。

　　借助這些文檔，你可以快速確定需要測試的用例。每個測試用例都描述了應用程序可以執(zhí)行的一項功能。用規(guī)模相近的測試方案確定唯一的功能是一個好習慣，而較大的方案可以根據(jù)其檢驗的功能拆分為較小的方案。

　　有許多種建立用例模型的方法，其中最簡單的便是輸入/輸出匹配法。在Saxon的query類中，最簡單的用例是傳送一個查詢文件、一個查詢請求和一個輸出文件路徑。輸出文件若不存在，將根據(jù)要求創(chuàng)建，并在文件中顯示查詢結果。

　 　更復雜的用例可能需要輸入更多的信息或輸出更多的結果。然而，用例并不關心功能是如何在內部實現(xiàn)的。對它們來說，軟件就像是一個 “黑盒子”，只要運行正常，即使真正實現(xiàn)軟件功能的是盒子里的侏儒也無所謂。這是很重要的一點，因為輸入/輸出匹配用例很容易直接轉換為測試用例，使得復 雜的說明與簡單的測試吻合，確定該運行的功能正常運行，而不該運行的功能如預期一樣失效。

　　如果類相對比較簡單，或者已有列舉類所有功能的說明文檔，為指定入口點描述用例將很容易。如果不是這樣，或許就需要研究類可能有的所有行為（確定類的目的與用法）。如果你想知道所有調用代碼的地方，也可以從代碼中提取用例。

　　最可能的情況是，根據(jù)開發(fā)人員提供的類的一些基本說明文檔，可以完全確定這些類應有和不應有的行為?；诖?，設計一套準確的用例集。

　　轉換測試用例

　　每個測試用例都由兩部分組成：輸入和預期輸出。輸入部分包括所有創(chuàng)建變量或為變量賦值的測試用例語句。預期輸出部分則表明應該得到的輸出結果，它應該顯示斷言成立或“沒有異常”（不存在斷言語句時）這樣的信息。

　　基本的輸入/輸出模式是理解測試用例模型最簡單易用的辦法。它采用一般函數(shù)（傳遞參數(shù)，獲取返回值）和大多數(shù)用戶行為（按某個鍵實現(xiàn)某項功能）慣用的模式。然后，可以用該模式進行：

　　初始化：建立測試預設環(huán)境。代碼初始化可以在測試開始時進行或通過調用setUp()方法實現(xiàn)。

　　運行：調用被測試的代碼，記錄所有值得注意的輸出和數(shù)據(jù)。

　　檢查：使用斷言語句確保代碼正常運行。

　　每一步都可以根據(jù)需要進行增減。這里聲明的變量也可以簡單地通過調用方法來賦值。預期輸出的實現(xiàn)是由幾個步驟組成。如果成功得到預期輸出，有時可以省略檢查步驟。

　　雖然這個模式簡單且靈活可變，但是第二步必不可少。這個模板沒有告訴我們尋找要測試代碼的方法，也不能保證代碼以方便測試的方式運行。這是個需要認真考慮的問題。

　　功能測試

　　通過確定執(zhí)行程序功能的主要代碼段，可以將測試建立在一個更有效的環(huán)境下。由于這些類提供了從系統(tǒng)外部進行測試的途徑，所以也是代碼的入口點。

　　因此，功能測試的整體目標就是確定一組可以訪問系統(tǒng)功能的高層接口類。這些類的獨立性越高越好。畢竟，如果能將類從環(huán)境中分離出來，測試起來會更加容易。

　　確定作為入口點的代碼是一個簡單的過程。在代碼庫中，通常有幾個控制該庫所有功能的入口點。這些外部類作為客戶端代碼，與庫的中介對象將開發(fā)人員從復雜的代碼分析中解脫出來。這些便是應當首先對其方法進行測試的類。

　　比如，Saxon有一小組類作為邏輯入口點提供對庫的訪問。通過對外部類進行編碼操作，比如轉換、設置和查詢，客戶端代碼可以訪問庫的許多功能 類，而無需考慮類的接口問題，甚至無需擔心這些類是否存在。這些外部類用高層易用的接口提供一個簡單的方式對系統(tǒng)功能進行測試，這正是一個優(yōu)良的庫的特 征。

　　程序代碼中的各個功能模塊通常是各自獨立的。在某些代碼中，甚至可以認為這些模塊各自對應不同的、可通過大量外部類訪問的庫。這些類查找高層接口的邏輯位置。插件結構通常都采用這種設計模式：每個插件程序都有一個可以有效執(zhí)行內部代碼全部功能的簡單接口。

　　在一些非嚴格描述的系統(tǒng)中，通常有一個所有程序行為的中介點。在MVC架構中，這個中介類一般作為“控制器”，負責配置系統(tǒng)各部分的請求路由。整體系統(tǒng)的功能主要由這個控制器連接的類實現(xiàn)，因此，這些類是測試的主要對象。

　　比如在 Applet程序設計中，java.applet.Applet的派生類就是所有代碼的中心處理單元。根據(jù)代碼的分解程度，測試焦點可以放在Applet 子類或與其連接的類上。

　　連接各個模塊的代碼也是測試的主要對象。將應用程序請求轉換為數(shù)據(jù)庫查詢的類，以及有相似功能的適配類是其次應該考慮的測試對象。

　　各種基于MVC（模式-視圖-控制器）架構的組件可以用其它的測試框架（比如Junit的擴展）進行測試。例如，Struts的 action類就最好使用JUnit的擴展StrutsTestCase進行測試；服務器端的組件（如Servlets、JSP和EJB）最好用 Catus進行測試；而HttpUnit則是對Web應用程序進行黑盒測試的最好框架。本文討論的所有技術都可應用于這些框架環(huán)境下的測試。

　　從用例到測試用例

　　每個入口點都必須與相應的用例匹配。某些情況下可以忽視這一步，因為類名的自記錄可以實現(xiàn)自動匹配，比如 Saxon中的轉換類可以實現(xiàn)XSL轉換，查詢類可以進行XQuery轉換。

　　其它情況則要復雜得多。通常用例描述的功能只能以橫切關注點的方式存在，不能用任何單獨的類進行例證。只有幾組類交互時或滿足一定條件時，才能觀察到功能行為。這種情況下，測試的初始化程序會比較長，或者可以用 setUp()方法提供需要的測試環(huán)境。

　　而調用代碼的運行程序應該盡可能地設計成一行，以減少與被測試代碼的關聯(lián)，這可以有效避免對邊緣效應與不穩(wěn)定實現(xiàn)細節(jié)的依賴。測試的檢查階段是 最復雜的，因為這個階段經(jīng)常需要添寫非測試用代碼。測試時可能需要對結果進行嚴格的分析以確保其符合要求。有時甚至需要將這個過程分為幾步來完成，以取得 測試可以識別的結果。在XSL轉換中，這兩種情況都是可能的，結果儲存在文件中，然后以XML格式讀入內存并進行準確性分析。

　　Saxon中有個相對簡單的例子。已有XML文件和XPath表達式的情況下，Saxon可以執(zhí)行表達式并返回匹配列表。Saxon中的XpathExample樣本類就是用來執(zhí)行這種任務的。基于以上分析，可以設計如下的測試流程：

　　兩次輸入的都是字符串常量，輸出的則是所匹配的列表，可以用來驗證匹配結果的正確性。這些工作都由一行代碼完成，這行代碼只是簡單地調用了被測試的方法。

　　另一種可能的情況是XPathEvaluator沒有調用createExpression()方法。因為表達式不存在，這時可能會顯示錯誤信息。

　　將輸入的源文件名和表達式保留在測試用例中不是個好習慣。某些項目（服務器名、用戶名和密碼等）不應該出現(xiàn)在測試文件中，它們應該可以根據(jù)情況 自由設置。并且，測試用例的設計應該方便測試驅動和測試數(shù)據(jù)的分離、測試驅動對大范圍數(shù)據(jù)的可重用性和測試數(shù)據(jù)對測試驅動的可重用性。另一方面，不要將一 個簡單的測試用例實現(xiàn)設計地過于復雜。一般來說，測試用例已經(jīng)說明了系統(tǒng)的大部分狀態(tài)，并可對其進行參數(shù)描述，所以無需在測試中進行過于詳細的參數(shù)描述。

　　許多代碼段可能出現(xiàn)在不止一個測試用例中。有經(jīng)驗的面向對象開發(fā)人員會嘗試對其進行重構并創(chuàng)建通用類和有效方法。有時候這樣做非常有用，比如登錄過程應該設計成所有測試用例可用的方法。 但是，不要過度設計測試，這些Java類僅僅是用來驗證應用程序的功能行為而已。

　　測試用例是脆弱的。比如，如果開發(fā)人員更改了testXPathEvaluation測試中輸入文件的位置，或者creatExpression方法簽名有所變動，測試腳本就會失效。

　　對于應用程序的測試用例實現(xiàn)來說，大量的重復性工作與改動是不可避免的。因此，可跟蹤性對于所有的測試用例都是至關緊要的。出現(xiàn)問題的時候，如果能為開發(fā)人員指出相應的測試用例說明和用例說明將有利于提高修正bug的速度。

　　因此，測試用例注釋中應標明原始說明文檔的引用位置。這可以是一個簡單的代碼注釋，也可以對每條測試都注釋相關用例和所測功能，這樣當測試出現(xiàn)問題時開發(fā)人員就會收到一條相關信息。因此，在代碼中加入?yún)⒖疾⒕S護可追蹤性是很重要的。

　　設計運行時事件表

　　要了解測試覆蓋的范圍，必須先了解所測試代碼如何運行，以及各種靜態(tài)類如何形成描述程序狀態(tài)的動態(tài)對象圖表。

　　有許多模擬這種行為的方法，包括Granovetter圖和物件互動圖。其基本思想是用圖形化的方式研究代碼以了解測試中涉及到的運行時部分。 這些技術都可用運行時事件表（Runtime Event Diagrams）來描述，因為這些圖表顯示了程序運行時發(fā)生的事件，而非理論上類可以控制的事件。這些圖表非常重要的原因包括：

　　首先，這些圖表便于從高層上理解代碼，并提供有用的說明文檔。這個文檔與代碼的內聯(lián)文檔不同。這些圖表顯示代碼的運行時表現(xiàn)，是產生代碼功能的地方，也易于對系統(tǒng)的了解；大多數(shù)設計模式和架構在用對象和參考表示時要比用類和域表示容易得多。

　　另外，這些圖表將測試執(zhí)行的代碼分類列表，并確定測試是否會受到將來對任意代碼改動的影響。如果開發(fā)人員確定測試A是建立在B、C和D的基礎上，她就可以確定如果對B、C或D做出改動就需要對A進行重新測試（確保向后兼容）。

　　以盡可能少的步驟模擬系統(tǒng)是個好方法。總的來說，實際調用與此無關，重要的是系統(tǒng)如何作為整體運作以獲得預期目標?？梢杂煤喕哪M系統(tǒng)實現(xiàn)這個目的，該系統(tǒng)只關心對象間的基本交互，并用自然語言描述交互中發(fā)生的事件。

　　做出運行時事件表后，就可以將其整合到類文檔中。需要注意的是，為表添加一些限制可使其對類的修改更有彈性。首先，一般不能使用方法名，因為它 們會隨時間發(fā)生變化。取而代之的是更易理解的自然語言描述。其次，這些圖表主要是關于系統(tǒng)中各部分的交互。這是高層架構上的設計方案，一般不會再做改動。 最后，圖表是建立在類型而非特定類的基礎上。只要基本類型不變，為維持交互協(xié)議的正常運行，這些圖表就不需要更新。

　　一旦圖表創(chuàng)建成功，可以在許多方面獲得應用。比如，一個圖表可以用來獲取系統(tǒng)如何運作，以及如何運用其交互部件實現(xiàn)功能的概覽。在某種程度上這是一種簡化了的UML語言，它只描述關系到整體功能的系統(tǒng)部件：實例及其類型、其它引用的實例，以及組件可以實現(xiàn)的功能。

　　這些圖表也可以用來分析系統(tǒng)的復雜性以及如何進行簡化。要確定簡化系統(tǒng)的方法，可以查找系統(tǒng)中使用過一到兩次的對象，并為其尋找其它可能更合適的位置。也可以查找重復的任務，將其封裝到方法或類中。

　　然而，最重要的是圖表在測試中的應用。通過對系統(tǒng)狀態(tài)的總結，圖表可以幫助解決系統(tǒng)中出現(xiàn)的問題。出現(xiàn)問題時，圖表中的信息便可用作參考。因為 只需要將系統(tǒng)目前狀態(tài)與預期狀態(tài)作比較即可，這樣確定問題產生的原因也就變得比較簡單了。對小組件的改動不應該影響整體架構，因此可以通過對照運行時事件 表以保證系統(tǒng)仍然正常運行。并且，當有重要組件發(fā)生變動時，可以用運行時事件表對照系統(tǒng)當前狀態(tài)以獲取系統(tǒng)修正方案。由于將系統(tǒng)作為整體和對預期功能的描 述，運行時事件表也可以看作是一種結構化的單元測試。如果系統(tǒng)有變動，可以更容易地做出修正以維持系統(tǒng)的正常功能。

　　如果經(jīng)常因細節(jié)問題影響對全局的把握，就應該使用圖表。其高層本質可以用來分析軟件的設計模式，就像反模式一樣。還有許多其它用途，并且當運行時事件表、測試用例說明和用例說明沒有描述所需的細節(jié)時，它還提供了直接進行代碼分析的路線圖。

　　利用功能測試進行回歸測試

　　最后，為回報你在功能測試上做出的努力，配置一個與自動生成的程序相應的自動化測試程序。這個程序不只從功能上測試代碼，還可以同時進行常規(guī)的 回歸測試?，F(xiàn)在大多開發(fā)項目都建立在龐大的代碼庫基礎上，如果不能對代碼庫進行充分測試，開發(fā)團隊將無從決定對程序的修正是否會破壞現(xiàn)有的功能，結果就是 很難對這種代碼進行擴展或優(yōu)化。與此相反，如果開發(fā)人員可以在全面的功能測試基礎上進行回歸測試，優(yōu)化或擴展代碼時就不必擔心可能會引發(fā)不可預料的問題。 畢竟，沒有比做完回歸測試后發(fā)現(xiàn)一切正常更令人心情愉快的事了。

　　個人認為，寫TC沒有固定的模式，也沒有唯一的答案，每個人的方式不同，習慣不同，TC中的如何分類歸納也就自然不相同。但目標是一致的，基本目標是覆蓋需求、無盲區(qū)；加強目標是加深測試點，完善用戶友好性等。

　　下面分享下我寫TC的幾種思路。

　　第一種思路——先對象，后流程

　　面向對象是在平常入門學習中 首先接觸到的概念，它不僅僅存在于代碼的編寫中，更存在于我們的工作方式和方法中。首先分析需求中涉及到哪些對象，比如頁面是一個對象，對它加以細化，頁 面大對象可能又分為新增頁面，修改頁面，刪除頁面和查詢頁面等，或者從功能上劃分為賣家頁面、小二頁面等。分析完后再層層細化，比如新增頁面包含的哪些文 本的輸入框，單選/多選項、日歷控件，以及它們之間操作的優(yōu)先級，錯誤提示的優(yōu)先級等等，再洗化到各個控件本身的限制檢查，如單行文本最長和最短的校驗長 度是多少，非法字符校驗等。

　　當所有對象類信息完成后，再考慮這些對象之間的流程關系，比如對用戶身份審核的操作必須建立在用戶身份信息 已創(chuàng)建之后，或者信息被修改后。不光是需要校驗正常的操作流程，還需要花大精力放在異常流程的操作上，比如用戶在填寫信息時，突然中斷了操作，這樣的情況 通過什么樣的流程去處理。因此這里的流程，應該是包括正常流、異常流及擴展流（需求中未涉及，但測試人員基于用戶友好或者性能方面考慮需要加入的流程）。

　　回過頭想一想，我們說，把面向對象的思想帶入TC，那面向對象又體現(xiàn)在什么地方呢，難道僅僅是分類么？NO！

　 　我們是不是經(jīng)常會在寫TC中碰到這樣的問題，比如某些項目中，進行查看和修改時，發(fā)現(xiàn)自己看到的是相同的頁面，也就是可能在做不同操作流程的時候發(fā)現(xiàn)到 達了相同的一個出口，那對于這N個流程是否需要寫N個平行的TC，是否可以把某部分寫成公共模塊以提高效率，避免冗余呢。

　　第一種思路可 能會有同學覺得很麻煩，很容易復雜化，確實是的，因為大家平常做項目或日常時，至少是有頁面或者頁面大概的原形，如果需求是很模糊的，又或者客戶也不知道 具體是要做成什么樣的，同時客戶又希望能快速立項的情況下，可以使用這種方式，其實在這樣的過程中，測試人員無形中擔當了架構的角色，并且能幫助開發(fā)完善 產品。

　　第二種思路——先流程，再對象

　　這種思路，要求是頁面設計到位，至少是大概的原形具有，然后對著原形寫TC。

　 　從打開的第一個頁面開始層層深入寫，比如首先是用戶登陸，然后是主展示頁面，再可能是搜索寶貝等，先把流程正常流程建立好，然后將這些流程細化，如用戶 登陸是否采用彈出窗口，窗口的位置、大小，窗口中的表單項是否完整，如是不是缺少驗證碼項，再考慮某一項的校驗，如用戶名是否為單行文本，長度限制多少， 非法字符限制，是否為必填項（不填是否有提示）等。

　　使用這種思路的時候，切記至少要包含幾類信息：頁面總體展示、表單項完整性、表單項正確性、表單項可操作性（獨立操作和組合操作）、表單項非法校驗、及當前頁面的其他跳轉出口（如點擊“登陸”，在用戶輸入的信息正確的情況下，應跳轉到主展示頁面）。

　　這種思路可能使用的同學比較多，至少我是經(jīng)常用的。這里實際上還是把頁面當成了大對象，當出現(xiàn)多類頁面跳轉到相同頁面上去的時候，這個相同頁面就可以作為公共部分來使用了。

　　記得在學校里學習這些原理的時候，對它的用法感悟不深刻，出來工作以后發(fā)現(xiàn)，其實很多思想就穿插在平時的應用中，所以有一句話很欣賞：解決問題，思路很重要，技術在其次。

　　以上是對于寫TC思路的一些個人看法，有不足之處還請大家指正。

　　一直在做功能測試工作，負責過三四個不大不小的項目的功能測試工作，卻很少靜下心來總結工作中的得失。

　 　很多不了解測試的人，認為功能測試不過就是拿鼠標點來點去，沒有什么技術含量，隨便招個應屆畢業(yè)生就能干的工作。我也曾經(jīng)認為功能測試沒什么前途，現(xiàn)在 看來覺得自己太浮躁了。功能測試的門檻可能比較低，做測試工作的人大多都是從功能測試開始，但要做好功能測試卻不容易，需要學習的知識還很多，比如操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡。下面主要結合工作實踐談談我對功能測試的一點總結。

　 　功能測試最重要的是理解業(yè)務和需求。知道系統(tǒng)要實現(xiàn)什么功能，業(yè)務流程是怎樣的，然后就可以根據(jù)需求編寫測試計劃和測試用例了。測試書籍上介紹常用的編 寫測試用例的方法有：等價類、邊界值、因果圖、判定表等，在實際工作中，我使用較多的有等價類、邊界值、場景法和錯誤猜測法。在這里需要提一點，將測試用 例按測試目的進行分類，比如用戶界面、功能點、業(yè)務場景等，會讓測試用例的結構看起來更清晰，執(zhí)行測試用例的效率也更高。

　　要做好功能測 試，還需要對整個系統(tǒng)的數(shù)據(jù)庫結構比較清楚，每個功能點涉及哪些數(shù)據(jù)表，對數(shù)據(jù)的操作方式是怎樣的。這樣就不單從前臺頁面來進行測試，通過對數(shù)據(jù)庫中數(shù)據(jù) 的驗證，可以發(fā)現(xiàn)隱藏的一些bug。比如庫表沒有進行關聯(lián)刪除，從前臺頁面是看不出來的，但實際可能導致程序出現(xiàn)問題。對一些比較復雜的組合查詢或數(shù)據(jù)排 序，也可以自己編寫sql語句對結果進行驗證。

　　除此之外，了解程序的框架結構和一些開發(fā)知識也有助于更好地測試程序和定位錯誤。做完一個業(yè)務，可以通過系統(tǒng)日志來查看錯誤原因，結合數(shù)據(jù)庫結構，可以更好幫助開發(fā)人員定位錯誤。比如日志記錄執(zhí)行哪條sql語句出錯了，錯誤的原因是字段長度設置不夠。我在這方面做得不太好，現(xiàn)在在努力學習一些開發(fā)知識，期待在以后的工作能做得更好。

　 　最后，對bug的分析和總結有助于積累測試經(jīng)驗。比如哪種類型的bug數(shù)量多，哪些測試用例發(fā)現(xiàn)的bug較多，有助于測試用例的編寫和修改。在探索測試 時，發(fā)現(xiàn)bug的測試過程也要加入測試用例庫中。通過測試用例的累積，可以更好地了解系統(tǒng)常出現(xiàn)的錯誤，積累更多的測試經(jīng)驗。

　　使用黑盒測試方法的功能測試流程簡述如下:

　　1.確定參照體系，參照體系是軟件測試的判斷依據(jù)。對于不同的實現(xiàn)，需要參照體系明確正確的實現(xiàn)方式。功能測試中，參照體系的角色通常由需求規(guī)格說明書來擔當。在更為細致深入的測試中，還可引入系統(tǒng)設計文檔等。

　　2.用例編寫，測試用例是有條理、有組織的，對于測試行為的描述。測試用例描述了測試執(zhí)行時，執(zhí)行者所應進行的具體操作。測試用例應嚴格按照需求文檔進行編寫。

　 　3.測試執(zhí)行，測試者執(zhí)行測試時，應按照測試用例所描述的內容進行操作，并將產出的結果與測試用例中的描述進行對比，并判斷測試結果。若測試未通過，測 試者應將該步驟的測試結果判定為失敗，并提交缺陷給相應的開發(fā)人員，并在后續(xù)的測試中，追蹤該缺陷的修復情況，直至該缺陷被修復。

　　4.測試用例維護，測試用例不是一次性產品，應不斷進行調整與更新。一份維護良好的測試用例，不但可以大大加快后續(xù)回歸測試的速度，更可讓新入職的員工—不論測試還是開發(fā)，能夠更快、更方便的熟悉業(yè)務。

　 　比起需求文檔的錯綜復雜、面面俱到，經(jīng)過編寫人員的理解、提煉而成的測試用例，是一份需求文檔的精華摘要，閱讀的有效性更高。測試用例對于項目而言，是 一份非常寶貴的資料。整個黑盒測試過程看似簡單，但由于大部分程序難以做到與需求文檔嚴格一致，而需求文檔也無法做到對于程序的每個細節(jié)都進行詳細說明。

　　測試過程中，測試人員應當依據(jù)經(jīng)驗、常識等進行判斷，某個和測試用例描述的期望結果不完全一致的實際結果應判定為通過還是失敗。

　 　在測試執(zhí)行過程中，測試人員對于測試用例的態(tài)度應尊重但不迷信。雖然測試用例是經(jīng)過仔細編寫和詳細評審的，但錯誤依舊難免。因此，作為測試執(zhí)行者，不應 進行機械測試，而應多動腦，能夠站在用戶、設計人員的角度看問題，這樣不但可以發(fā)現(xiàn)一些測試用例中可能存在的問題，還能發(fā)現(xiàn)更多測試用例中沒有涵蓋到的缺 陷。

　　繼續(xù)深入闡述幾個測試用例編寫中需要遵循的原則，總結為如下五點:

　　1.正確性，正確性是測試用例編寫中的最基本原則。測試執(zhí)行時，測試者的操作是基于測試用例的。因此，一旦測試用例存在錯誤，將對測試者產生誤導，影響測試判斷的準確性，從而產生缺陷誤報或缺陷遺漏。

　　2.可讀性，前文對于這點已進行較為詳細的闡述。由于測試用例面對的讀者眾多，因此，一個優(yōu)秀的測試用例的最基本要求是能夠讓他人理解，不會因為表述上的問題產生歧義。

　　3.完整性，完整性是對正確性的補充。完整性要求測試用例能夠覆蓋到整個軟件項目的每個模塊、每個功能、每個細節(jié)。完整性缺失的測試用例，后果或比缺復雜工作流軟件自動化測試方法的研究第二章件測試理論，J技術基礎失正確性的測試用例更為嚴重。正確性的缺失影響的通常是一個功能點，而完整性的缺失則會影響整個模塊。

　　4.可執(zhí)行性，可執(zhí)行性是指用戶能夠按照測試用例中的測試步驟描述，進行測試的執(zhí)行。為此，步驟描述必須清晰完整，測試用例的拆分設計也必須思路清晰，結構合理。

　　5.一致性，一致性指依據(jù)測試用例的描述執(zhí)行測試時，操作與產出結果應是一致的。測試用例應減少操作者的主觀性，增加操作的確定性。這樣才‘能讓功能測試的結果更為客觀，讓后續(xù)的回歸測試結果更為精確。避免因為測試者的變更，導致測試結果的改變。

　　一個設計良好的測試用例應當符合以上五點。前兩點更多針對編寫者的編寫技術與細心程度，而后三點則更多與用例的設計方法有關，因此，后文對測試用例設計方法的論述中，將著重以后三點作為評定標準，比較設計方法的優(yōu)劣。