標籤: 暫無標籤

軟體測試就是利用測試工具按照測試方案和流程對產品進行功能和性能測試,甚至根據需要編寫不同的測試工具,設計和維護測試系統,對測試方案可能出現的問題進行分析和評估。

1 軟體測試 -概念

軟體測試軟體測試


  使用人工或者自動手段來運行或測試某個系統的過程,其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別.
  它是幫助識別開發完成(中間或最終的版本)的計算機軟體(整體或部分)的正確度(correctness)、完全度(completeness)和質量(quality)的軟體過程;是SQA(softwarequalityassurance)的重要子域。
  GrenfordJ.Myers曾對軟體測試的目的提出過以下觀點:
  (1)測試是為了發現程序中的錯誤而執行程序的過程;
  (2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案;
  (3)成功的測試是發現了至今為止尚未發現的錯誤的測試。
  然而,這種觀點指出測試是以查找錯誤為中心,而不是為了演示軟體的正確功能.但是只從字面意思理解,可能會產生誤導,認為發現錯誤是軟體測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上並非如此!
  (1)測試並不僅僅是為了找出錯誤.通過分析錯誤產生的原因和錯誤的發生趨勢,可以幫助項目管理者
  發現當前軟體開發過程中的缺陷,以便及時改進;
  (2)這種分析也能幫助測試人員設計出有針對性的測試方法,改善測試的效率和有效性;
  (3)沒有發現錯誤的測試也是有價值的,完整的測試是評定軟體質量的一種方法

2 軟體測試 -軟體測試的內容

  軟體測試主要工作內容是驗證(verification)和確認(validation),下面分別給出其概念:
  驗證(verification)是保證軟體正確地實現了一些特定功能的一系列活動,即保證軟體做了你所期望的事情。(Dotherightthing)
  1.確定軟體生存周期中的一個給定階段的產品是否達到前階段確立的需求的過程;
  2.程序正確性的形式證明,即採用形式理論證明程序符號設一計規約規定的過程;
  3.評市、審查、測試、檢查、審計等各類活動,或對某些項處理、服務或文件等是否和規定的需求相一致進行判斷和提出報告。
  確認(validation)是一系列的活動和過程,目的是想證實在一個給定的外部環境中軟體的邏輯正確性。即保證軟體以正確的方式來做了這個事件(Doitright)
  1.靜態確認,不在計算機上實際執行程序,通過人工或程序分析來證明軟體的正確性;
  2.動態確認,通過執行程序做分析,測試程序的動態行為,以證實軟體是否存在問題。
  軟體測試的對象不僅僅是程序測試,軟體測試應該包括整個軟體開發期問各個階段所產生的文檔,如需求規格說明、概要設計文檔、詳細設計文檔,當然軟體測試的主要對象還是源程序。
  從不同的角度出發,軟體測試可以劃分為不同的分類
  從是否關心軟體內部結構和具體實現的角度劃分
  A.白盒測試
  B.黑盒測試
  C.灰盒測試
  從是否執行程序的角度

  A.靜態測試
  B.動態測試。
  從軟體開發的過程按階段劃分有
  A.單元測試
  B.集成測試
  C.確認測試
  D.驗收測試
  E.系統測試
     

 軟體測試是軟體開發過程的重要組成部分,是用來確認一個程序的品質或性能是否符合開發之前所提出的一些要求。軟體測試就是在軟體投入運行前,對軟體需求分析、設計規格說明和編碼的最終複審,是軟體質量保證的關鍵步驟。軟體測試是為了發現錯誤而執行程序的過程。軟體測試在軟體生存期中橫跨兩個階段:通常在編寫出每一個模塊之後就對它做必要的測試(稱為單元測試)。編碼和單元測試屬於軟體生存期中的同一個階段。在結束這個階段后對軟體系統還要進行各種綜合測試,這是軟體生存期的另一個獨立階段,即測試階段。 

3 軟體測試 -目的

      軟體測試的目的,第一是確認軟體的質量,其一方面是確認軟體做了你所期望的事情(Do the right thing),另一方面是確認軟體以正確的方式來做了這個事件(Do it right)。

      第二是提供信息,比如提供給開發人員或程序經理的反饋信息,為風險評估所準備的信息。

      第三軟體測試不僅是在測試軟體產品的本身,而且還包括軟體開發的過程。如果一個軟體產品開發完成之後發現了很多問題,這說明此軟體開發過程很可能是有缺陷的。因此軟體測試的第三個目的是保證整個軟體開發過程是高質量的。

      軟體質量是由幾個方面來衡量的:一、在正確的時間用正確的的方法把一個工作做正確(Doing the right things right at the right time.)。二、符合一些應用標準的要求,比如不同國家的用戶不同的操作習慣和要求,項目工程中的可維護性、可測試性等要求。三、質量本身就是軟體達到了最開始所設定的要求,而代碼的優美或精巧的技巧並不代表軟體的高質量(Quality is defined as conformance to requirements, not as 「goodness」 or 「elegance」.)。四、質量也代表著它符合客戶的需要(Quality also means 「meet customer needs」.)。作為軟體測試這個行業,最重要的一件事就是從客戶的需求出發,從客戶的角度去看產品,客戶會怎麼去使用這個產品,使用過程中會遇到什麼樣的問題。只有這些問題都解決了,軟體產品的質量才可以說是上去了。

      測試人員在軟體開發過程中的任務:

      1、尋找Bug;
      2、避免軟體開發過程中的缺陷;
      3、衡量軟體的品質;
      4、關注用戶的需求。

      總的目標是:確保軟體的質量。

4 軟體測試 -測試工具

      Test Platform軟體測試平台,簡稱TP,是業界唯一的對軟體測試全過程進行支撐的軟體測試工具。   
       業界已有的軟體測試工具基本上都局限在測試執行階段,只能支撐測試執行階段的活動,而測試分析、測試設計、測試實現這三個前期階段的活動缺乏有效的測試工具支撐,直接影響了軟體測試的完整性和充分性,從而影響最終研發的軟體質量。David.yuan這樣說:企業使用了博為峰TP測試平台,整個軟體測試過程的 測試覆蓋率提高到前所未有的高度和廣度,可以極好的達成軟體在安全性、健壯性、穩定性和功能、性能方面的要求,即使是沒有很多年測試經驗的管理和測試人員,通過TP測試平台就可以完成智能化地管理、設計、分析、執行整個測試過程,達到一流測試管理專家所做到的效果。   
         1、TestPlatForm 簡稱TP,在業界首先將各種有效的缺陷分析模型引入到該軟體平台中,包括ODC分析、Gompertz分析、Rayleigh分析、四象限分析、缺陷注入分析、DRE/DRM等工程方法,幫助管理者建立軟體研發過程的質量基線、測試能力基線,並幫助管理者將項目實際缺陷、能力數據和基線數據進行對比分析,發現軟體過程中的改進點,判斷測試是否可以退出、軟體是否可以發布,並對軟體中殘留缺陷數進行預測;   
         2、TestPlatform 簡稱TP,建立了測試分析和設計的理論框架和一整套工程方法,能夠很好的支撐測試的輔助分析和設計;   
         3、TestPlatform 簡稱TP,建立「開發需求項->測試項->測試子項->測試用例->缺陷」的測試跟蹤關係,能夠及時的反應開發需求和設計的變更對測試的影響範圍,保證軟體的一致性和測試的充分性,從而保證軟體的質量;   
         4、TestPlatform 簡稱TP,能夠全面的管理軟體質量工作,具有高度的集成性,一款TestPlatform能夠完成多款其他各類的相關質量管理工具集成在一起才能完成的軟體質量管理工作。它集成了需求跟蹤、靜態測試、動態測試、測試人員管理、測試環境管理、測試計劃管理、測試用例管理、缺陷管理、缺陷分析等軟體質量相關的流程。   
AutoRunner是國內第一款自動化測試工具,可以用來完成功能測試、回歸測試、每日構建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調試功能的、支持IE測試和Windows native測試的自動化測試工具。   
       TestCenter是一款功能強大測試管理工具,它可以幫助您:實現測試用例的過程管理,對測試需求過程、測試用例設計過程、業務組件設計實現過程等整個測試過程進行管理。實現測試用例的標準化即每個測試人員都能夠理解並使用標準化后的測試用例,降低了測試用例對個人的依賴;提供測試用例復用,用例和腳本能夠被複用,以保護測試人員的資產;提供可伸縮的測試執行框架,提供自動測試支持;提供測試數據管理,幫助用戶同意管理測試數據,降低測試數據和測試腳本之間的耦合度。   
      TAR(Terminal AutoRunner)適用於VT100、VT220等標準的應用系統,支持命令行模式和窗口模式(使用Cursors編寫的應用程序),支持自動錄製腳本、所見即所得的資源和腳本編輯,穩定的自動同步功能。是目前國內最好的銀行業務測試工具.   
       LoadRunner 是一種預測系統行為和性能的工業標準級負載測試工具。通過以模擬上千萬用戶實施併發負載及實時性能監測的方式來確認和查找問題,LoadRunner 能夠對整個企業架構進行測試。通過使用LoadRunner , 企業能最大限度地縮短測試時間, 優化性能和加速應用系統的發布周期。目前企業的網路應用環境都必須支持大量用戶,網路體系架構中含各類應用環境且由不同供應商提供軟體和硬體產品。難以預知的用戶負載和愈來愈複雜的應用環境使公司時時擔心會發生用戶響應速度過慢, 系統崩潰等問題。這些都不可避免地導致公司收益的損失。  
       TestDirector是全球最大的軟體測試工具提供商Mercury Interactive公司生產的企業級測試管理工具,也是業界第一個基於Web的測試管理系統,它可以在您公司內部外部進行全球範圍內測試的管理。通過在一個整體的應用系統中集成了測試管理的各個部分,包括需求管理,測試計劃,測試執行以及錯誤跟蹤等功能,TestDirector極大地加速了測試過程。

 

 

5 軟體測試 -原則

      軟體測試從不同的角度出發會派生出兩種不同的測試原則,從用戶的角度出發,就是希望通過軟體測試能充分暴露軟體中存在的問題和缺陷,從而考慮是否可以接受該產品,從開發者的角度出發,就是希望測試能表明軟體產品不存在錯誤,已經正確地實現了用戶的需求,確立人們對軟體質量的信心。

      為了達到上述的原則,那麼需要注意以下幾點:
1.應當把「儘早和不斷的測試」作為開發者的座右銘
2.程序員應該避免檢查自己的程序,測試工作應該由獨立的專業的軟體測試機構來完。
3.設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件,特殊情況要製造極端狀態和意外狀態,比如網路異常中斷、電源斷電等情況。
4.一定要注意測試中的錯誤集中發生現象,這和程序員的編程水平和習慣有很大的關係。
5.對測試錯誤結果一定要有一個確認的過程,一般有A測試出來的錯誤,一定要有一個B來確認,嚴重的錯誤可以召開評審會進行討論和分析。
6.制定嚴格的測試計劃,並把測試時間安排的盡量寬鬆,不要希望在極短的時間內完成一個高水平的測試。
7.回歸測試的關聯性一定要引起充分的注意,修改一個錯誤而引起更多的錯誤出現的現象並不少見。
8.妥善保存一切測試過程文檔,意義是不言而喻的,測試的重現性往往要靠測試文檔。

  軟體測試並不等於程序測試。軟體測試應該貫穿整個軟體定義與開發整個期間。因此需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔,包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序,都應該是軟體測試的對象。

  在對需求理解與表達的正確性、設計與表達的正確性、實現的正確性以及運行的正確性的驗證中,任何一個環節發生了問題都可能在軟體測試中表現出來。  

6 軟體測試 -方法

軟體測試的基本方法
單元測試的基本方法
綜合測試的基本方法
確認測試的基本方法
系統測試的基本方法
軟體測試的基本方法

  軟體測試的方法和技術是多種多樣的。
  對於軟體測試技術,可以從不同的角度加以分類:

  從是否需要執行被測軟體的角度,可分為靜態測試和動態測試。
  從測試是否針對系統的內部結構和具體實現演算法的角度來看,可分為白盒測試和黑盒測試;

1、黑盒測試

  黑盒測試也稱功能測試或數據驅動測試,它是在已知產品所應具有的功能,通過測試來檢測每個功能是否都能正常使用,在測試時,把程序看作一個不能打開的黑盆子,在完全不考慮程序內部結構和內部特性的情況下,測試者在程序介面進行測試,它只檢查程序功能是否按照需求規格說明書的規定正常使用,程序是否能適當地接收輸入數鋸而產生正確的輸出信息,並且保持外部信息(如資料庫或文件)的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等,主要用於軟體確認測試。 「黑盒」法著眼於程序外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。「黑盒」法是窮舉輸入測試,只有把所有可能的輸入都作為測試情況使用,才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個,人們不僅要測試所有合法的輸入,而且還要對那些不合法但是可能的輸入進行測試。

2、白盒測試

  白盒測試也稱結構測試或邏輯驅動測試,它是知道產品內部工作過程,可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行,按照程序內部的結構測試程序,檢驗程序中的每條通路是否都有能按預定要求正確工作,而不顧它的功能,白盒測試的主要方法有邏輯驅動、基路測試等,主要用於軟體驗證。

  「白盒」法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。「白盒」法是窮舉路徑測試。在使用這一方案時,測試者必須檢查程序的內部結構,從檢查程序的邏輯著手,得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一,窮舉路徑測試決不能查出程序違反了設計規範,即程序本身是個錯誤的程序。第二,窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三,窮舉路徑測試可能發現不了一些與數據相關的錯誤。

3.ALAC(Act-like-a-customer)測試

  ALAC測試是一種基於客戶使用產品的知識開發出來的測試方法。ALAC測試是基於複雜的軟體產品有許多錯誤的原則。最大的受益者是用戶,缺陷查找和改正將針對那些客戶最容易遇到的錯誤。

7 軟體測試 -單元測試的基本方法

單元測試的對象是軟體設計的最小單位模塊。單元測試的依據是詳細設描述,單元測試應對模塊內所有重要的控制路徑設計測試用例,以便發現模塊內部的錯誤。單元測試多採用白盒測試技術,系統內多個模塊可以并行地進行測試。
單元測試任務

  單元測試任務包括:1 模塊介面測試;2 模塊局部數據結構測試;3 模塊邊界條件測試;4 模塊中所有獨立執行通路測試;5 模塊的各條錯誤處理通路測試。

  模塊介面測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下,其他測試才有意義。測試介面正確與否應該考慮下列因素:
   1 輸入的實際參數與形式參數的個數是否相同;
   2 輸入的實際參數與形式參數的屬性是否匹配;
   3 輸入的實際參數與形式參數的量綱是否一致;
   4 調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同;
   5 調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配;
   6調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致;
   7 調用預定義函數時所用參數的個數、屬性和次序是否正確;
   8 是否存在與當前入口點無關的參數引用;
   9 是否修改了只讀型參數;
   10 對全程變數的定義各模塊是否一致;
   11是否把某些約束作為參數傳遞。

  如果模塊內包括外部輸入輸出,還應該考慮下列因素:
   1 文件屬性是否正確;
   2 OPEN/Close語句是否正確;
   3 格式說明與輸入輸出語句是否匹配;
   4緩衝區大小與記錄長度是否匹配;
   5文件使用前是否已經打開;
   6是否處理了文件尾;
   7是否處理了輸入/輸出錯誤;
   8輸出信息中是否有文字性錯誤;

  檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源,應仔細設計測試用例,力求發現下面幾類錯誤:
   1 不合適或不相容的類型說明;
   2變數無初值;
   3變數初始化或省缺值有錯;
   4不正確的變數名(拼錯或不正確地截斷);
   5出現上溢、下溢和地址異常。

  除了局部數據結構外,如果可能,單元測試時還應該查清全局數據(例如FORTRAN的公用區)對模塊的影響。

  在模塊中應對每一條獨立執行路徑進行測試,單元測試的基本任務是保證模塊中每條語句至少執行一次。??的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括:
   1 誤解或用錯了算符優先順序;
   2混合類型運算;
   3變數初值錯;
   4精度不夠;
   5表達式符號錯。

  比較判斷與控制流常常緊密相關,測試用例還應致力於發現下列錯誤:
   1不同數據類型的對象之間進行比較;
   2錯誤地使用邏輯運算符或優先順序;
   3因計算機表示的局限性,期望理論上相等而實際上不相等的兩個量相等;
   4比較運算或變數出錯;
   5循環終止條件或不可能出現;
   6迭代發散時不能退出;
   7錯誤地修改了循環變數。

  一個好的設計應能預見各種出錯條件,並預設各種出錯處理通路,出錯處理通路同樣需要認真測試,測試應著重檢查下列問題:
   1輸出的出錯信息難以理解;
   2記錄的錯誤與實際遇到的錯誤不相符;
   3在程序自定義的出錯處理段運行之前,系統已介入;
   4異常處理不當;
   5錯誤陳述中未能提供足夠的定位出錯信息。

  邊界條件測試是單元測試中最後,也是最重要的一項任務。眾的周知,軟體經常在邊界上失效,採用邊界值分析技術,針對邊界值及其左、右設計測試用例,很有可能發現新的錯誤。

單元測試過程

  一般認為單元測試應緊接在編碼之後,當源程序編製完成並通過複審和編譯檢查,便可開始單元測試。測試用例的設計應與複審工作相結合,根據設計信息選取測試數據,將增大發現上述各類錯誤的可能性。在確定測試用例的同時,應給出期望結果。

  應為測試模塊開發一個驅動模塊(driver)和(或)若干個樁模塊(stub),下圖顯示了一般單元測試的環境。驅動模塊在大多數場合稱為「主程序」,它接收測試數據並將這些數據傳遞到被測試模塊,被測試模塊被調用后,「主程序」列印「進入-退出」消息。

  驅動模塊和樁模塊是測試使用的軟體,而不是軟體產品的組成部分,但它需要一定的開發費用。若驅動和樁模塊比較簡單,實際開銷相對低些。遺憾的是,僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務,這些模塊的單元測試只能採用下面討論的綜合測試方法。

  提高模塊的內聚度可簡化單元測試,如果每個模塊只能完成一個,所需測試用例數目將顯著減少,模塊中的錯誤也更容易發現。

8 軟體測試 -綜合測試的基本方法


   時常有這樣的情況發生,每個模塊都能單獨工作,但這些模塊集成在一起之後卻不能正常工作。主要原因是,模塊相互調用時介面會引入許多新問題。例如,數據經過介面可能丟失;一個模塊對另一模塊可能造成不應有的影響;幾個子功能組合起來不能實現主功能;誤差不斷積累達到不可接受的程度;全局數據結構出現錯誤,等等。綜合測試是組裝軟體的系統測試技術,按設計要求把通過單元測試的各個模塊組裝在一起之後,進行綜合測試以便發現與介面有關的各種錯誤。

  某設計人員習慣於把所有模塊按設計要求一次全部組裝起來,然後進行整體測試,這稱為非增量式集成。這種方法容易出現混亂。因為測試時可能發現一大堆錯誤,為每個錯誤定位和糾正非常困難,並且在改正一個錯誤的同時又可能引入新的錯誤,新舊錯誤混雜,更難斷定出錯的原因和位置。與之相反的是增量式集成方法,程序一段一段地擴展,測試的範圍一步一步地增大,錯誤易於定位和糾正,界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。

1 自頂向下集成

  自頂向下集成是構造程序結構的一種增量式方式,它從主控模塊開始,按照軟體的控制層次結構,以深度優先或廣度優先的策略,逐步把各個模塊集成在一起。深度優先策略首先是把主控制路徑上的模塊集成在一起,至於選擇哪一條路徑作為主控制路徑,這多少帶有隨意性,一般根據問題的特性確定。以下圖為例,若選擇了最左一條路徑,首先將模塊M1,M2,M5和M8集成在一起,再將M6集成起來,然後考慮中間和右邊的路徑。廣度優先策略則不然,它沿控制層次結構水平地向下移動。仍以下圖為例,它首先把M2、M3和M4與主控模塊集成在一起,再將M5和M6 和其他模塊集資集成起來。

  自頂向下綜合測試的具體步驟為:
   1 以主控模塊作為測試驅動模塊,把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代;
   2 依據所選的集成策略(深度優先或廣度優先),每次只替代一個樁模塊;
   3 每集成一個模塊立即測試一遍;
   4 只有每組測試完成後,才著手替換下一個樁模塊;
   5 為避免引入新錯誤,須不斷地進行回歸測試(即全部或部分地重複已做過的測試)。
 

   從第二步開始,循環執行上述步驟,直至整個程序結構構造完畢。下圖中,實線表示已部分完成的結構,若採用深度優先策略,下一步將用模塊M7替換樁模塊S7,當然M7本身可能又帶有樁模塊,隨後將被對應的實際模塊一一替代。

  自頂向下集成的優點在於能儘早地對程序的主要控制和決策機制進行檢驗,因此較早地發現錯誤。缺點是在測試較高層模塊時,低層處理採用樁模塊替代,不能反映真實情況,重要數據不能及時回送到上層模塊,因此測試並不充分。解決這個問題有幾種辦法,第一種是把某些測試推遲到用真實模塊替代樁模塊之後進行,第二種是開發能模擬真實模塊的樁模塊;第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法,使錯誤難於定位和糾正,並且失去了在組裝模塊時進行一些特定測試的可能性;第二種方法無疑要大大增加開銷;第三種方法比較切實可行,下面專門討論。

2自底向上集成

  自底向上測試是從「原子」模塊(即軟體結構最低層的模塊)開始組裝測試,因測試到較高層模塊時,所需的下層模塊功能均已具備,所以不再需要樁模塊。

  自底向上綜合測試的步驟分為:
   1 把低層模塊組織成實現某個子功能的模塊群(cluster);
   2 開發一個測試驅動模塊,控制測試數據的輸入和測試結果的輸出;
   3 對每個模塊群進行測試;
   4 刪除測試使用的驅動模塊,用較高層模塊把模塊群組織成為完成更大功能的新模塊群。

  從第一步開始循環執行上述各步驟,直至整個程序構造完畢。

  下圖說明了上述過程。首先「原子」模塊被分為三個模塊群,每個模塊群引入一個驅動模塊進行測試。因模塊群1、模塊群2中的模塊均隸屬於模塊Ma,因此在驅動模塊D1、D2去掉后,模塊群1與模塊群2直接與Ma介面,這時可對MaD3被去掉后,M3與模塊群3直接介面,可對Mb進行集成測試,最後Ma、Mb和 Mc全部集成在一起進行測試。

   自底向上集成方法不用樁模塊,測試用例的設計亦相對簡單,但缺點是程序最後一個模塊加入時才具有整體形象。它與自頂向綜合測試方法優缺點正好相反。因此,在測試軟體系統時,應根據軟體的特點和工程的進度,選用適當的測試策略,有時混和使用兩種策略更為有效,上層模塊用自頂向下的方法,下層模塊用自底向上的方法。

  此外,在綜合測試中尤其要注意關鍵模塊,所謂關鍵模塊一般都具有下述一或多個特徵:①對應幾條需求;②具有高層控制功能;③複雜、易出錯;④有特殊的性能要求。關鍵模塊應儘早測試,並反覆進行回歸測試。

確認測試的基本方法
   通過綜合測試之後,軟體已完全組裝起來,介面方面的錯誤也已排除,軟體測試的最後一步確認測試即可開始。確認測試應檢查軟體能否按合同要求進行工作,即是否滿足軟體需求說明書中的確認標準。

1. 確認測試標準

  實現軟體確認要通過一系列墨盒測試。確認測試同樣需要制訂測試計劃和過程,測試計劃應規定測試的種類和測試進度,測試過程則定義一些特殊的測試用例,旨在說明軟體與需求是否一致。無是計劃還是過程,都應該著重考慮軟體是否滿足合同規定的所有功能和性能,文檔資料是否完整、準確人機界面和其他方面(例如,可移植性、兼容性、錯誤恢復能力和可維護性等)是否令用戶滿意。

  確認測試的結果有兩種可能,一種是功能和性能指標滿足軟體需求說明的要求,用戶可以接受;另一種是軟體不滿足??這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正,因此必須與用戶協商,尋求一個妥善解決問題的方法。

2. 配置複審

  確認測試的另一個重要環節是配置複審。複審的目的在於保證軟體配置齊全、分類有序,並且包括軟體維護所必須的細節。

3. α、β測試

  事實上,軟體開發人員不可能完全預見用戶實際使用程序的情況。例如,用戶可能錯誤的理解命令,或提供一些奇怪的數據組合,亦可能對設計者自認明了的輸出信息迷惑不解,等等。因此,軟體是否真正滿足最終用戶的要求,應由用戶進行一系列「驗收測試」。驗收測試既可以是非正式的測試,也可以有計劃、有系統的測試。有時,驗收測試長達數周甚至數月,不斷暴露錯誤,導致開發延期。一個軟體產品,可能擁有眾多用戶,不可能由每個用戶驗收,此時多採用稱為α、β測試的過程,以期發現那些似乎只有最終用戶才能發現的問題。

  α測試是指軟體開發公司組織內部人員模擬各類用戶行對即將面市軟體產品(稱為α版本)進行測試,試圖發現錯誤並修正。α測試的關鍵在於儘可能逼真地模擬實際運行環境和用戶對軟體產品的操作並盡最大努力涵蓋所有可能的 用戶操作方式。經過α測試調整的軟體產品稱為β版本。緊隨其後的β測試是指軟體開發公司組織各方面的典型用戶在日常工作中實際使用β版本,並要求用戶報告異常情況、提出批評意見。然後軟體開發公司再對β版本進行改錯和完善。

9 軟體測試 -系統測試的基本方法

計算機軟體是基於計算機系統的一個重要組成部分,軟體開發完畢后應與系統中其它成分集成在一起,此時需要進行一系列系統集成和確認測試。對這些測試的詳細討論已超出軟體工程的範圍,這些測試也不可能僅由軟體開發人員完成。在系統測試之前,軟體工程師應完成下列工作:
   (1) 為測試軟體系統的輸入信息設計出錯處理通路;
   (2) 設計測試用例,模擬錯誤數據和軟體界面可能發生的錯誤,記錄測試結果,為系統測試提供經驗和幫助;
   (3) 參與系統測試的規劃和設計,保證軟體測試的合理性。

  系統測試應該由若干個不同測試組成,目的是充分運行系統,驗證系統各部件是否都能政黨工作並完成所賦予的任務。下面簡單討論幾類系統測試。

1、恢複測試

  恢複測試主要檢查系統的容錯能力。當系統出錯時,能否在指定時間間隔內修正錯誤並重新啟動系統。恢複測試首先要採用各種辦法強迫系統失敗,然後驗證系統是否能儘快恢復。對於自動恢復需驗證重新初始化(reinitialization)、檢查點(checkpointing mechanisms)、數據恢復(data recovery)和重新啟動 (restart)等機制的正確性;對於人工干預的恢復系統,還需估測平均修復時間,確定其是否在可接受的範圍內。

2、安全測試

  安全測試檢查系統對非法侵入的防範能力。安全測試期間,測試人員假扮非法入侵者,採用各種辦法試圖突破防線。例如,①想方設法截取或破譯口令;②專門定做軟體破壞系統的保護機制;③故意導致系統失敗,企圖趁恢復之機非法進入;④試圖通過瀏覽非保密數據,推導所需信息,等等。理論上講,只要有足夠的時間和資源,沒有不可進入的系統。因此系統安全設計的準則是,使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。

3、強度測試

  強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。例如,①當中斷的正常頻率為每秒一至兩個時,運行每秒產生十個中斷的測試用例;②定量地增長數據輸入率,檢查輸入子功能的反映能力;③運行需要最大存儲空間(或其他資源)的測試用例;④運行可能導致虛存操作系統崩潰或磁碟數據劇烈抖動的測試用例,等等。

4、 性能測試

  對於那些實時和嵌入式系統,軟體部分即使滿足功能要求,也未必能夠滿足性能要求,雖然從單元測試起,每一測試步驟都包含性能測試,但只有當系統真正集成之後,在真實環境中才能全面、可靠地測試運行性能系統性能測試是為了完成這一任務。性能測試有時與強度測試相結合,經常需要其他軟硬體的配套支持。

10 軟體測試 -類型

常見的軟體測試類型有:

      bvt (Build Verification Test)

      BVT是在所有開發工程師都已經檢入自己的代碼,項目組編譯生成當天的版本之後進行,主要目的是驗證最新生成的軟體版本在功能上是否完整,主要的軟體特性是否正確。如無大的問題,就可以進行相應的功能測試。BVT優點是時間短,驗證了軟體的基本功能。缺點是該種測試的覆蓋率很低。因為運行時間短,不可能把所有的情況都測試到。

      Scenario Tests(基於用戶實際應用場景的測試)

      在做BVT、功能測試的時候,可能測試主要集中在某個模塊,或比較分離的功能上。當用戶來使用這個應用程序的時候,各個模塊是作為一個整體來使用的,那麼在做測試的時候,就需要模仿用戶這樣一個真實的使用環境,即用戶會有哪些用法,會用這個應用程序做哪些事情,操作會是一個怎樣的流程。加了這些測試用例后,再與BVT、功能測試配合,就能使軟體整體都能符合用戶使用的要求。Scenario Tests優點是關注了用戶的需求,缺點是有時候難以真正模仿用戶真實的使用情況。

      smoke test

      在測試中發現問題,找到了一個Bug,然後開發人員會來修復這個Bug。這時想知道這次修復是否真的解決了程序的Bug,或者是否會對其它模塊造成影響,就需要針對此問題進行專門測試,這個過程就被稱為Smoke Test。在很多情況下,做Smoke Test是開發人員在試圖解決一個問題的時候,造成了其它功能模塊一系列的連鎖反應,原因可能是只集中考慮了一開始的那個問題,而忽略其它的問題,這就可能引起了新的Bug。Smoke Test優點是節省測試時間,防止build失敗。缺點是覆蓋率還是比較低。

      此外,Application Compatibility Test(兼容性測試),主要目的是為了兼容第三方軟體,確保第三方軟體能正常運行,用戶不受影響。Accessibility Test(軟體適用性測試),是確保軟體對於某些有殘疾的人士也能正常的使用,但優先順序比較低。其它的測試還有Functional Test(功能測試)、Security Test(安全性測試)、Stress Test(壓力測試)、Performance Test(性能測試)、regression test(回歸測試)、Setup/Upgrade Test(安?支持工具


      一些受軟體開發人員歡迎的軟體測試工具為軟體測試提供了強有力的支持。本文將介紹美國Rational公司的著名套裝軟體SQA和Pure Atria公司極具特色的Purify。

      SQA SuiteSQA直接支持對客戶/伺服器應用軟體的測試,它的一個重要特點是可以自動驅動被測程序的運行。SQA可以自動記錄和重放程序執行過程,從而實現了對測試進行"複查"的自動化。

      由於測試是一個需要反覆進行的過程,常常要數十次甚至數百次地重複。因此,這一特性大大地提高了軟體"再測試"(Re-Test)和"回歸測試"(Regression)的自動化程度,把測試人員從繁雜的、重複性的手工測試中解脫出來,從而顯著地提高軟體測試效率。

      除了這個最基本的自動錄放功能外,它還提供了一系列的輔助支持功能,比如,

  · 被錄製的程序執行過程可以被自動轉換成具有良好可讀性的高級語言程序,從而使這個測試驅動程序可以由測試人員根據測試需要進行必要的修改,甚至完全用手工方式編製。

  ·自動記錄和分析比較測試的執行結果。不論是簡單的正文方式的輸出結果,還是任意的圖表、聲音、動畫、圖形用戶界面(GUI)中的任一構件,都可以根據測試人員的指定被自動記錄在測試結果庫中,並可對兩次測試的結果自動地進行比較,指出其差異部分。此項功能無疑對"自動查找錯誤"很有幫助。

  ·調節和設定事件的發生時間和速度。

  ·基本的測試庫管理功能。

  此外,SQA還支持軟體測試人員進行以下工作:

  ·制定測試計劃和測試大綱,並將這些文檔按照自然的樹狀結構分層地管理起來,並據此控制和驅動整個測試過程。

  ·不僅能夠自動記錄各類測試結果,而且對其進行修改,從而使得測試人員可以在程序運行結果尚有許多錯誤的情況下,通過對所記錄下的結果做適當修正來獲得理想的"期望結果" ,為測試結果的自動比較奠定基礎。

  ·測試問題報告的記錄與管理。

      總之,SQA Suite提供了一個比較完整的測試平台,以支持軟體測試的各種基本活動,包括測試計劃與測試大綱的制定、回歸測試的自動化、測試結果的分析比較、軟體問題報告的生成與自動分發和控制等。對於許多應用軟體的開發無疑是個有力的測試支持工具。

      Purify是原PureAtria公司(現已經與美國Rational公司合併,改名為美國Rational公司)於90年代初率先推出的專門用於檢測程序中種種內存使用錯誤的軟體工具。幾乎所有使用過C語言開發軟體的程序員都會有這樣的體會,C語言中使用極為靈活的指針給程序員帶來了很大便利,但同時也製造了許多的麻煩。由於指針使用不當而引起的錯誤通常是最難發現的,同時也是最難定位的一類錯誤。而Purify對多種常見的內存使用錯誤的檢錯能力和準確的定位,受到廣大軟體開發人員的青睞。

      Purify可以自動識別出二十多種內存使用錯誤,包括

  ·未初始化的局部變數

  ·未申請的內存

  ·使用已釋放的內存

  ·數組越界

  ·內存丟失

  ·文件描述問題

  ·棧溢出問題

  ·棧結構邊界錯誤等

      在下面的例子中,暗藏著兩個內存使用錯誤。第一行為指針數組pp申請的空間尺寸不對。這類錯誤往往不易發現,因為在C語言中,一些"輕微"的內存越界可能被系統所容忍。但這往往是導致更嚴重錯誤的根源。例如,可能破壞其它數據區等。最後一行的錯誤是在釋放pp 之前沒有釋放賦予它的字元串空間,從而把它們"丟失"了。這類錯誤猶如慢性自殺,它會逐漸消耗掉內存,降低系統的運行效率,直到完全崩潰。而真正的問題在於,這些程序中的"惡性腫瘤"用常規的測試手段和調試工具是極難發現和加以定位的。Purify則在此充分顯示了它的強大功效,所到之處,即對所測試過的情況,上述各種常見的內存錯誤都可以被一一揭露出來,並且準確地指出錯誤的類型和位置。從而大大地提高了測試和糾錯的效率,提高了軟體的可靠性。

  …/"to get 10 words and print them out"/

  if(!(pp=(char**)malloc(10))){

  /*Size should be 10*sizeof(char*)*/

  printf("Out of memory.n");

  exit(-1);

  }

  for(i=0;i<10;i ){

  scanf("%s",buffer);

  if(!(pp【i】=(char*)malloc(strlen(buffer) 1))){

  print("Out of Memory. n");

  exit(-1);

  }

  strcpy(pp【i】,buffer);

  printf(pp【i】);

  }

  free(pp);"

  ………

      今年以來,原PureAtria公司陸續推出了其系列產品?/FONT>Pure,包括支持內存檢測的Purify ,支持路徑覆蓋的PureCoverage,支持多線程應用程序性能測試的quantify,以及用以提高測試期間連接編譯被測程序效率的PureLink等。Pure系列現已支持C、C 、FORTRAN語言,以及UNIX和Window NT等操作系統,如Sun OS、Solaris 2.3,HP-UX,Windows NT Server以及IBM A/ X等。

      結束語

      充分認識軟體測試的重要性和複雜性,合理地選擇測試方法,有效地組織測試人員和安排測試任務,並且盡量使用軟體測試工具增強軟體測試的自動化程度,無疑可以幫助軟體開發和測試人員大大提高測試效率和軟體的質量。

11 軟體測試 -基本過程

      軟體測試是一個極為複雜的過程。如圖一所示,一個規範化的軟體測試過程通常須包括以下基本的測試活動。

  ·擬定軟體測試計劃

  ·編製軟體測試大綱

  ·設計和生成測試用例

  ·實施測試

  ·生成軟體問題報告

      對整個測試過程進行有效的管理實際上,軟體測試過程與??早在需求分析階段即應開始制定,其它相關工作,包括測試大綱的制定、測試數據的生成、測試工具的選擇和開發等也應在測試階段之前進行。充分的準備工作可以有效地克服測試的盲目性,縮短測試周期,提高測試效率,並且起到測試文檔與開發文檔互查的作用。

      此外,軟體測試的實施階段是由一系列的測試周期(Test Cycle)組成的。在每個測試周期中,軟體測試工程師將依據預先編製好的測試大綱和準備好的測試用例,對被測軟體進行完整的測試。測試與糾錯通常是反覆交替進行的。當使用專業測試人員時,測試與糾錯甚至是平行進行的,從而壓縮總的開發時間。更重要的是,由於專業測試人員豐富的測試經驗、所採用的系統化的測試方法、全時的投入,特別是獨立於開發人員的思維,使得他們能夠更有效地發現許多單靠開發人員很難發現的錯誤和問題。

      軟體測試大綱是軟體測試的依據。它明確詳盡地規定了在測試中針對系統的每一項功能或特性所必須完成的基本測試項目和測試完成的標準。無論是自動測試還是手動測試,都必須滿足測試大綱的要求。

      一般而言,測試用例是指為實施一次測試而向被測系統提供的輸入數據、操作或各種環境設置。測試用例控制著軟體測試的執行過程,它是對測試大綱中每個測試項目的進一步實例化。已有許多著名的論著總結了設計測試用例的各種規則和策略。從工程實踐的角度講有幾條基本準則:

  1.測試用例的代表性:能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數據、操作和環境設置等;

  2.測試結果的可判定性:即測試執行結果的正確性是可判定的或可評估的;

  3.測試結果的可再現性:即對同樣的測試用例,系統的執行結果應當是相同的。

12 軟體測試 -制定成功的測試計劃


      「工欲善其事,必先利其器」。專業的測試必須以一個好的測試計劃作為基礎。儘管測試的每一個步驟都是獨立的,但是必定要有一個起到框架結構作用的測試計劃。測試的計劃應該作為測試的起始步驟和重要環節。一個測試計劃應包括:產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等等。

      產品基本情況調研:

      這部分應包括產品的一些基本情況介紹,例如:產品的運行平台和應用的領域,產品的特點和主要的功能模塊,產品的特點等。對於大的測試項目,還要包括測試的目的和側重點。

      具體的要點有:

      目的:重點描述如何使測試建立在客觀的基礎上,定義測試的策略,測試的配置, 粗略的估計測試大致需要的周期和最終測試報告遞交的時間。

      變更:說明有可能會導致測試計劃變更的事件。包括測試工具改進了,測試的環境改變了,或者是添加了新的功能。

      技術結構:可以藉助畫圖,將要測試的軟體劃分成幾個組成部分,規劃成一個適用於測試的完整的系統,包括數據是如何存儲的,如何傳遞的(數據流圖),每一個部分的測試是要達到什麼樣的目的。每一個部分是怎麼實現數據更新的。還有就是常規性的技術要求,比如運行平台、需要什麼樣的資料庫等等。

      產品規格:就是製造商和產品版本號的說明。

      測試範圍:簡單的描述如何搭建測試平台以及測試的潛在的風險。

      項目信息:說明要測試的項目的相關資料,如:用戶文檔,產品描述,主要功能的舉例說明。

      測試需求說明:

      這一部分要列出所有要測試的功能項。凡是沒有出現在這個清單里的功能項都排除在測試的範圍之外。萬一有一天你在一個沒有測試的部分里發現了一個問題,你應該很高興你有這個記錄在案的文檔,可以證明你測了什麼沒測什麼。具體要點有:

      功能的測試:理論上是測試是要覆蓋所有的功能項,例如:在資料庫中添加、編輯、刪除記錄等等,這會是一個浩大的工程,但是有利於測試的完整性。

      設計的測試:對於一些用戶界面、菜單的結構還有窗體的設計是否合理等的測試。

      整體考慮:這部分測試需求要考慮到數據流從軟體中的一個模塊流到另一個模塊的過程中的正確性。

      測試的策略和記錄:

      這是整個測試計劃的重點所在,要描述如何公正客觀地開展測試,要考慮:模塊、功能、整體、系統、版本、壓力、性能、配置和安裝等各個因素的影響。要儘可能的考慮到細節,越詳細越好,並製作測試記錄文檔的模板,為即將開始的測試做準備,測試記錄重要包括的部分具體說明如下:

      公正性聲明:要對測試的公正性、遵照的標準做一個說明,證明測試是客觀的,整體上,軟體功能要滿足需求,實現正確,和用戶文檔的描述保持一致。

      測試案例:描述測試案例是什麼樣的,採用了什麼工具,工具的來源是什麼,如何執行的,用了什麼樣的數據。測試的記錄中要為將來的回歸測試留有餘地,當然,也要考慮同時安裝的別的軟體對正在測試的軟體會造成的影響。

      特殊考慮:有的時候,針對一些外界環境的影響,要對軟體進行一些特殊方面的測試。

      經驗判斷:對以往的測試中,經常出現的問題加以考慮。

      設想:採取一些發散性的思維,往往能幫助你找的測試的新途徑。

      測試資源配置:

      項目資源計劃:制定一個項目資源計劃,包含的是每一個階段的任務、所需要的資源,當發生類似到了使用期限或者資源共享的事情的時候,要更新這個計劃。

      計劃表:

      測試的計劃表可以做成一個多個項目通用的形式,根據大致的時間估計來製作,操作流程要以軟體測試的常規周期作為參考,也可以是根據什麼時候應該測試哪一個模塊來制定。

      問題跟蹤報告:

      在測試的計劃階段,我們應該明確如何準備去做一個問題報告以及如何去界定一個問題的性質,問題報告要包括問題的發現者和修改者、問題發生的頻率、用了什麼樣的測試案例測出該問題的,以及明確問題產生時的測試環境。

      問題描述儘可能是定量的,分門別類的列舉,問題有幾種:

  1、嚴重問題:嚴重問題意味著功能不可用,或者是許可權限制方面的失誤等等,也可能是某個地方的改變造成了別的地方的問題。

  2、一般問題:功能沒有按設計要求實現或者是一些界面交互的實現不正確。

  3、建議問題:功能運行得不象要求的那麼快,或者不符合某些約定俗成的習慣,但不影響系統的性能,界面先是錯誤,格式不對,含義模糊混淆的提示信息等等。

      測試計劃的評審:

      又叫測試規範的評審,在測試真正實施開展之前必須要認真負責的檢查一遍,獲得整個測試部門人員的認同,包括部門的負責人的同意和簽字。

      結果:

      計劃並不是到這裡就結束了,在最後測試結果的評審中,必須要嚴格驗證計劃和實際的執行是不是有偏差,體現在最終報告的內容是否和測試的計劃保持一致,然後,就可以開始著手製作下一個測試計劃了。

13 軟體測試 -報告軟體測試錯誤的規範

       報告軟體測試錯誤的目的是為了保證修復錯誤的人員可以重複報告的錯誤,從而有利於分析錯誤產生的原因,定位錯誤,然後修正之。因此,報告軟體測試錯誤的基本要求是準確、簡潔、完整、規範。需要掌握的報告技術歸納如下。
   1. 描述 (Description),簡潔、準確,完整,揭示錯誤實質,記錄缺陷或錯誤出現的位置

  描述要準確反映錯誤的本質內容,簡短明了。為了便於在軟體錯誤管理資料庫中尋找制定的測試錯誤,包含錯誤發生時的用戶界面(UI)是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控制項的名稱。

  2. 明確指明錯誤類型:布局、翻譯、功能、雙位元組
根據錯誤的現象,總結判斷錯誤的類型。例如,即布局錯誤、翻譯錯誤、功能錯誤、雙位元組錯誤,這是最常見的缺陷或錯誤類型,其他形式的缺陷或錯誤也從屬於其中某種形式。

  3. 短行之間使用自動數字序號,使用相同的字體、字型大小、行間距

  短行之間使用自動數字序號,使用相同的字體、字型大小、行間距,可以保證各條記錄格式一致,做到規範專業。

  4. UI要加引號,可以單引號,推薦使用雙引號

  UI加引號,可以容易區分UI與普通文本,便於分辨、定位缺陷或錯誤。

  5. 每一個步驟盡量只記錄一個操作

  保證簡潔、條理井然,容易重複操作步驟。

  6. 確認步驟完整,準確,簡短

  保證快速準確的重複錯誤,「完整」即沒有缺漏,「準確」即步驟正確,「簡短」即沒有多餘的步驟。

  7. 根據缺陷或錯誤類型,選擇圖象捕捉的方式

  為了直觀的觀察缺陷或錯誤現象,通常需要附加缺陷或錯誤出現的界面,以點陣圖的形式作為附件附著在記錄的「附件」部分。為了節省空間,又能真實反映缺陷或錯誤本質,可以捕捉缺陷或錯誤產生時的全屏幕,活動窗口和局部區域。為了迅速定位、修正缺陷或錯誤位置,通常要求附加中英文對照圖。

  8. 附加必要的特殊文檔和個人建議和註解

  如果打開某個特殊的文檔而產生的缺陷或錯誤,則必須附加該文檔,從而可以迅速再現缺陷或錯誤。有時,為了使缺陷或錯誤修正者進一步明確缺陷或錯誤的表現,可以附加個人的修改建議或註解。

  9. 檢查拼寫和語法錯誤

  在提交每條缺陷或錯誤之前,檢查拼寫和語法,確保內容正確,正確的描述錯誤。

  10. 盡量使用業界慣用的表達術語和表達方法

  使用業界慣用的表達術語和表達方法,保證表達準確,體現專業化。

  11. 通用UI要統一、準確

  錯誤報告的UI要與測試的軟體UI保持一致,便於查找定位。

  12. 盡量使用短語和短句,避免複雜句型句式

  軟體錯誤管理資料庫的目的是便於定位錯誤,因此,要求客觀的描述操作步驟,不需要修飾性的辭彙和複雜的句型,增強可讀性。

  13. 每條錯誤報告只包括一個錯誤

  每條錯誤報告只包括一個錯誤,可以使錯誤修正者迅速定位一個錯誤,集中精力每次只修正一個錯誤。校驗者每次只校驗一個錯誤是否已經正確修正。

  以上概括了報告測試錯誤的規範要求,隨著軟體的測試要求不同,測試者經過長期測試,積累了相應的測試經驗,將會逐漸養成良好的專業習慣,不斷補充新的規範書寫要求。此外,經常閱讀、學習高級測試工程師的測試錯誤報告,結合自己以前的測試錯誤報告進行對比和思考,可以不斷提高技巧。  

14 軟體測試 -人員結構組成分析

      軟體測試工程師是軟體行業中一種即年輕又古老的職業,進入二十一世紀以來,隨著中國加入WTO以後,從事這項職業的人也越來越多。一個公司在組建一個測試隊伍的時候如何分配人員結構,從而使公司軟體測試工作水平得到提高,是大家比較關注的問題。本人依照自己的經驗提出自己的觀點:


我們首先來看一下測試人員的縱向結構
1,測試經理
測試經理主要負責測試隊伍的內部管理以及與其他外部人員,客戶的交流,詳細說來主要包括進度管理,風險管理,資金管理,人力資源管理,交流管理等等,測試經理需要具有項目經理的知識和技能。同時測試工作開始前項目經理需要書寫《測試計劃書》,測試結束需要書寫《測試總結報告》
2,測試文檔審核師
測試文檔審核師主要負責前置測試,包括在需求期與設計期間產生的文檔進行審核,比如《業務建模書》,《需求規格說明書》,《概要設計書》,《詳細設計書》等等。審核需要進行書寫審核報告。當文檔確定后,需要整理文檔報告,並且反映介紹給測試設計師。
3,測試設計師
測試設計師主要根據需求期與設計期間產生的文檔設計各個測試階段的測試用例。
(往往測試文檔審核師,測試設計師可以有相同的一組人來完成)
4, 測試工程師
測試工程師按照測試用例,來完成測試工作。


但是測試人員應該有哪些人來組成呢?也就是測試人員的橫向組成,讓我們再來討論討論:
1, 需要具有一定開發經驗的計算機專業人員
由於具有一定開發經驗的計算機專業人員即懂得計算機的基本理論,又有一定的開發經驗。所以對於軟體中哪裡容易出錯,哪裡不容易出錯他們了如指掌;他們可以分析程序的性能,軟體性能差是否是佔有內存空間太多,或者是佔有CPU時間太多引起的,還是其他原因,他們往往是專家。尤其是進行非功能測試的時候,他們可以更好的搭建系統測試平台。這種人員應該占測試隊伍中一半以上。
2, 需要具有本軟體業務經驗的人員
測試隊伍中需要有這樣的人員的目的在於,這些人員由於對業務非常熟悉,軟體質量的前提又是滿足用戶的需求。專業業務知識是計算機專業人員達不到的,所以這方面人才可以利用它們的業務知識和專業水平,參與系統需求期間的文當審核,可以發現軟體中存在的業務性錯誤。比如專業用語不準確,業務流程不規範等等,這種人才對於專業性比較強的軟體測試工作尤為重要,比如稅務,法律,藝術,CAD,CAM…
3, 只需要會操作計算機的人員
由於軟體一旦賣出去之後,使用軟體的人各種各樣,各種各樣的人帶來各種各樣的操作情況,請一大部分人員在軟體測試工作後期進行測試工作是十分重要的,他們往往會發現專業測試人員測試不出的東西和一些希奇古怪的錯誤。這就是軟體測試學中所謂的猴子測試法。
對於一個軟體公司來說,並不是說所有的測試隊伍都需要這三種人員,實際中可以一組人代替多個角色,但是要遵循以下原則:
1,對於業務不是很專業的軟體,具有一定開發經驗的計算機專業人員與具有本軟體業務經驗的人員可以合併;
2,只需要會操作計算機的人員,可以由公司行政人員來充當。

15 軟體測試 -現實和理想

   「從我在微軟工作的經歷來看,軟體測試絕對不是開發活動完成後的收尾工作,很多大型的開發項目,測試會佔據項目周期一半以上的時間。以IE4.0為例,代碼開發時間為6個月,而穩定程序花去了8個月的時間。」前微軟亞洲研究院博士、軟體測試專家陳宏剛談道。從投入的資金和人力物力來看,測試、使產品穩定和修改花去的時間可能佔到80%。
還處在嬰兒期

  軟體測試之所以發展相對緩慢,一個原因是做研究和做開發的人交流的機會相對少。只有做大型系統工程的人才會對測試提出較高的要求,重要性才能顯現出來,而做研究和教學的人沒有大型系統工程案例,所以造成了測試理論研究的發展缺乏充實的基礎材料。真正做大型系統開發的工程師,又沒有時間將第一手的測試經驗變成系統的理論。

  「在美國,佛羅里達州和華盛頓州分別有一所大學開設軟體測試課程,其他有正規課程的學校不是很多。軟體測試正停留在沒有學科系統、沒有系統教育的階段。雖然已經有學校開設了這門課程,但是使用的教學案例,多半是單機軟體,還談不上系統的理論。」陳宏剛博士介紹說。

  高素質的「雜牌軍」

  由於企業對測試人才有著迫切的需要,因此,只好自??品制定測試規範,開設一些課程,通過講座的形式對測試技術人員進行培訓,但是也還未形成系統的理論。

  即使在微軟,測試隊伍是典型的「雜牌軍」,沒有科班,沒有統一的專業,更多的是具有豐富的經驗和不同行業背景的員工,例如具有語言學、數學、物理學、計算機、工程、管理等學科等背景的員工。但是,這不是說隨便什麼人都可以做測試工作,陳宏剛工作過的那個試驗室,20個人中有7個博士。可見,雖然測試不是一個專門的學科,但是,這個部門對於一個成熟的軟體企業又是至關重要的部門。

  認識需再提高

  IBM和微軟公司屬於領先的大公司,對測試的認識也經歷了一個過程。開始的時候,也是開發人員兼職做測試,就像今天國內一些較小規模的軟體企業。但是,後來的結果表明,花在軟體修補上面的費用太高,以至於遠遠超出了所能夠允許的範圍。這個時候,增加測試隊伍的規模,提高測試隊伍的素質,提高測試隊伍的待遇和受重視的程度是更加划算的。

  還有一個問題是,很多工程師不願意做測試,認為是一種打下手的工作,沒有前途,這也是國內比較大軟體企業面臨的問題。所以,企業從上到下普遍自覺和不自覺地只重視技術,不重視質量,後果是產品在市場上競爭力不高,產品售後維護和服務費用偏高。

  巨大反差

  微軟的開發工程師與測試工程師的比例是1∶2,國內一般公司是6∶1。而且,致命的問題是沒有哪個機構專門培養測試工程師。這個矛盾提示我們,在中國不能等到實際的需求和人力資源矛盾十分尖銳的時候,再談培養問題;也不能等到產品質量成為產業阻礙的時候再來提高軟體業的測試水平。測試工作不能靠手工勞動來完成,更多的情況是要使用工具軟體和編寫測試程序來完成,培養全面的測試專業人才是項任重道遠的工作。

16 軟體測試 -軟體測試的新模型

       通常情況下,一個軟體模型說明的內容主要包括,在測試過程中你應該考慮到哪些問題,如何對測試進行計劃,測試要達到什麼目標,什麼時候開始,在測試中你要用到哪些信息資源。一個好的模型可以引導你對問題進行思考,而不好的模型則只能使你誤入歧途。

      這裡我要宣稱的是,目前的大多數軟體測試模型都是不好的模型。這是因為這些測試模型僅僅是軟體開發模型的一些裝飾和補充而已。

      人們一直在苦苦尋找軟體開發的模型,在創建了新的模型后,就把測試作為一個階段放在模型的後面部分。因此測試總被作為一種事後行為,測試總是被開發所驅動。總的來說,我們是在檢測他們的完成品。但是,作為事後處理的測試,其驅動方式是不正確的。實際上它顯而易見地和開發過程中各種行為之間有關,測試沒有起到應有的平衡作用。這樣的測試只是檢測了開發人員做了什麼,而並沒有檢測到他們是否按照規則做了什麼,這樣的做法割裂了本該緊密聯繫的行為,剩下的只有那些匆忙而草率的想法所帶來的傷害。

      而這樣做的結果就是效果很差的、效率很低的測試。效果很差的測試將導致很多bug沒有被發現,而效率很低的測試所浪費的是成本。

      在本文中,我要做2件事,其一,我要否定一個不好的模型,即V模型。我希望通過論述來表明,「單元測試」和「集成測試」這2個辭彙可以從我們的辭彙表中取消了。其二,我將描述一個更好的模型。不過首先我認為,要真正擁有一個充分合理的模型還為時尚早。我僅僅是描述了一些新模型應該符合的重要的要求。這些要求將在本文末尾處列舉。

      V模型有什麼問題呢?

      在本文中我要把V模型作為不好的模型的典型來進行分析。我選擇V模型作為分析的典型是因為V模型是最廣為人知的測試模型。

      最典型的V模型版本一般會在其開始部分對軟體開發過程進行描述,如下圖所示:

 

軟體測試 (圖1--V模型的各級開發階段)

      這是古老的瀑布模型。作為開發模型,它有很多問題,不過這裡不作討論。儘管它的各種狀態是我們接著要討論的大家最熟悉的V模型的基礎。我的批評意見同時也針對其它的裝飾在一些更好的開發模型之上的測試模型,例如螺旋模型【Boehm88】。

     在V模型中,測試過程被加在開發過程的後半部分,如下圖所示:

 

軟體測試 (圖2--V模型示意圖)

      單元測試所檢測的是,代碼的開發是否符合詳細設計的要求。集成測試所檢測的是,此前測試過的各組成部分是否能完好地結合到一起。系統測試所檢測的是,已集成在一起的產品是否符合系統規格說明書的要求。而驗收測試則檢測產品是否符合最終用戶的需求。

     對於測試設計,顯而易見的是,V模型的用戶往往會把執行測試與測試設計分開對待。在開發文檔準備就緒后,就可以開始進行相關的測試設計。如下圖所示,相應的測試設計覆蓋在了相關的開發過程之上:

 

軟體測試(圖3--將測試設計覆蓋了開發過程后的V模型) 

     V模型有著很吸引人的對稱外形,並且把很多人都帶入了歧途。本文將集中討論它在單元測試和集成測試中引起的問題。

      為了說明的方便,這裡專門製作了以下圖片,圖中包括一個單獨的單元,以及一個單元組,我稱之為子系統(subsystem)。

 

軟體測試(圖4--一個假想的子系統) 

      對於一個單元應該多大才最為合適的問題,已經有過很多的討論,究竟一個單元僅僅是一個函數,一個類,還是相關的類的集合?這些討論並不影響我在這裡所要闡述的觀點。我們權且認為一個單元就是一個具有最小程度的代碼塊,開發人員可以對進行獨立地討論。

     V模型認為人們首先應該對每一個單元進行測試。當子系統中所有的單元都已經測試完畢,它們將被集中到一起進行測試,以驗證它們是否可以構成一個可運行的整體。

      那麼,如何針對單元進行測試呢?我們會查看在詳細設計中對介面的定義,或者查看源代碼,或者同時對兩者進行查看,找出符合某些測試設計中的有關準則的輸入數據來進行輸入,然後檢查結果,看其是否正確。由於各單元一般來說不能獨立地運行,所以我們不得不另外設計樁模塊(Stub)和驅動模塊(Driver),如下圖所示。

 

軟體測試(圖5:單元及其外部的驅動模塊和樁模塊) 

        圖中的箭頭代表了測試的執行軌跡。這就是大多數人所說的「單元測試」。我認為這樣的方法有時候是一種不好的方法。

      同樣的輸入也可以有同一子系統中的其它單元來提供,這樣,其它的單元既扮演了樁模塊,又扮演了驅動模塊。如下圖所示:

軟體測試(圖6--子系統內部各單元間的測試執行軌跡)  

      到底選擇哪一種方法,這需要一種折衷和權衡。設計樁模塊和驅動模塊要付出多少代價?這些模塊如何進行維護?子系統是否會由此而掩蓋了一些故障?在整個子系統範圍內進行排錯的困難程度有多大?如果我們的測試直到集成測試時才真正開始,那麼一些bug可能較晚才被發現。由此造成的代價同設計樁模塊和驅動模塊的代價如何比較?等等。

     V模型沒有去考慮這些問題,當單元開發完成後就執行單元測試,而當自系統被集中在一起后就執行集成測試,僅此而已。令我奇怪和沮喪的是,人們從不去做一些權衡,他們已經受制於他們的模型。

      因此,一個有用的模型應該允許測試人員考慮節省並推遲測試的可能性。

      一個測試,如果要發現一個特定的單元中的bug,最好是在該單元保持獨立的情況下執行,並且在其外部輔以特定的樁模塊和驅動模塊。而另一種方法則是讓它作為子系統的一部分來進行測試,該測試的設計主要是為了發現集成的問題。由於一個子系統本身也需要樁模塊和驅動模塊來模擬該子系統和其它子系統的聯繫,因此,單元測試和集成測試可能被推遲到至少整個系統已經部分集成的時候。在這種情況下,測試者可能通過產品的外部介面同時進行單元測試、集成測試和系統測試,同樣的,其主要目的還是為了減少總體生命周期的成本,對測試成本和延期進行測試及由此造成延期發現bug的代價成本進行權衡。據此而言,「單元測試」、「集成測試」和「系統測試」的區別已經大大削弱了。其結果可參考下圖:

 

軟體測試 (圖7--新的方法:在部分階段延遲進行單元測試和集成測試)

        在上圖右邊的方塊中,最好要改成為「執行某些適當的測試並得到相應的結果」。

     圖中的左邊會怎樣?考慮一下系統測試設計,它的主要根據和信息來源是是規格說明。假設你知道有2個單元處在一個特定的子系統中,它們在運行時相互聯繫,並且要執行規格說明中的一個特定的聲明。為什麼不在該子系統被集成時立即對此規格說明中的聲明進行測試,就象是在設計完成後立即開始測試的設計一樣呢?如果該聲明的執行和子系統外的子系統沒有任何關係,為什麼還要等到整個系統完成以後再測試呢?難道越早發現bug成本越低不對嗎?

     在上一張圖片中,我們用了向上指的箭頭(更有效,但在時間上有延遲)。這裡還可以把箭頭往下指(在時間上提前):

 

軟體測試(圖8--新的方法:在不同階段上提前進行測試設計) 

     在這種情況下,左邊的方塊中最好被標記為:「在當前信息條件和情況下可以做的任何測試設計」。這樣,當測試設計得自於系統中某一個組件的描述時,模型必須允許這樣的測試在組件被裝配之前被執行。我必須承認我的圖片非常難看,這些箭頭指得到處都是,對此我有2點說明:

  1. 我們所討論的事情不是創造美,而是想要發現儘可能多的嚴重錯誤,同時儘可能地降低成本。

  2. 難看的部分原因也是因為必須按照某些次序來執行的結果,亦即開發人員先提供系統描述文檔,然後測試和這些文檔進行關聯。這些文檔就象是堅實的老橡樹,而測試設計則象是細細的枝條纏繞在樹上。如果我們採用不同的原理來進行組織,圖片可能就會變得好看些。但複雜性仍不可避免,因為我們要討論的問題本身就很複雜。

      V模型失敗的原因是它把系統開發過程劃分為具有固定邊界的不同階段,這使得人們很難跨過這些邊界來採集測試所需要的信息。有些測試應該執行得更早些,有些測試則需要延後進行。而且,它也阻礙了你從系統描述的不同階段中取得信息進行綜合。例如,某些組織有時執行這樣的做法,即對完成的工作進行簽署。這樣的規定也擴展到系統測試的設計。簽署表示已經過評估,該測試設計工作已經完成,除非對應的設計文檔改變,否則就不會被修訂。如果同這些測試相關的信息後來被重新挖掘和認識,例如,架構設計表明有些測試是多餘的,或者,詳細設計表明有一個內部的邊界可以和已存在的系統測試組合在一起進行測試的話,那麼實際上還需要繼續調整原來的系統測試設計。

      因此,模型必須允許利用不同來源的綜合信息進行個別的測試設計。另外,模型還應該允許在新的信息來源出現后重新進行測試的設計。

     一個不同的模型

     讓我們來看本文的第二項內容,一個不同的模型。

     很多時候人們把代碼移交給其他人,並且說:「希望你能接受和喜歡它。」這不僅發生在將整個項目放在一張光碟中交給客戶的時候,也發生在項目內部。

     例如,一個小組對另一個小組說:「我們已經完成了為COMM庫加入了對XML的支持。源代碼現在已經放在master庫中,可執行庫則已經加入到集成與創建的環境中。XARG小組的工作已經沒有什麼阻礙了,隨時去取吧。」

      某個程序員檢查了bug的修改並且發出郵件:「我已經修改了Bug列表中的那個Bug,很抱歉!」至此,早先受該問題影響的其它代碼就可以繼續處理了。

     在這些情況下,人們要把代碼移交給其它人,其中有可能會存在一些影響。測試人員需要干預這個過程。在移交之前,測試人員應執行這些代碼,發現其中的bug(影響),並且提出問題:「你確實要提交這些嗎?」由此,移交的內容可能會被延期,直到bug被修復好。

      儘管你還要做其它的各種測試,這項測試仍然是很基本的測試工作。如果你沒有做這樣的測試,就不能算是合格的測試人員。

      我們的測試模型必須包含這一重要的現實需要:針對代碼移交的測試。由此,測試模型應提示進行針對每一次代碼移交的測試。

      就讓我以支持XML的COMM庫作為例子。這裡存在著一個小組把代碼移交給XARG小組以進行項目的餘下部分。那麼誰會遭受影響?

      要將這些支持XML的代碼直接進行使用的XARG小組可能會立即受到影響;

      這可能會在稍後影響到市場人員,他們要在一個行業展示會議上為「合作夥伴發行」版本提供產品演示和宣傳,而XML支持是影響他們銷售的重要部分;

      還有,它可能損害採納我們的產品的合作夥伴。

      現在我們可以提出一些有趣的關於測試計劃的問題了。最簡單的可以做的事情是,在移交的時候立即執行XML支持的完整測試。(「完整」的含義是,為此設計儘可能多的測試)但也許一些XML特性並不是XARG小組所需要的,因此可以把它們放在合作夥伴版本封版(下圖中的「Partner Release」)的測試中去。這意味著可以把一些XML相關測試放到稍後的移交過程中去。或者基於其它理由,例如在近階段有其它的測試任務要執行。而XARG小組則要因XML中的bug修復而延遲一小段時間。

      我們的測試計劃所表示的進度可以通過在開發的時

 

軟體測試(圖9:添加在開發計劃之上的測試計劃)

      我們應嚴格地圍繞在XML支持的功能交接的時段里進行測試。測試設計和測試支持工作要早於測試執行。而另外的XML測試則要延遲到基於整個項目範圍的「代碼完成」(圖中的「Code Complete」里程碑),或者要等到全部的子系統被集中在一起,而且整個產品為了行業會議而在經過穩定化處理后創建了版本(圖中的「Partner Release」里程碑)。

      顯然,有兩項內容沒有包含在代碼完成里程碑中:

      還有大量其它的測試工作(包括設計、工具選用)。這些工作可能因為COMM以外的子系統的交接而延期。

      而且,還有用於完成里程碑中所規定的某些風險的測試,例如,可能還有一組用於運行市場人員的演示Demo腳本的測試,包括她可能在無意中引起的偏離。其目的是要避免這樣的情況,即當她站在1000人的觀眾面前時,她還僅僅是第一次以某種特定的順序來輸入數據。

      一些首次交接時進行的XML測試需要在代碼完成里程碑上再次執行。

      我的觀點是,測試計劃是由很多困難的決定所組成,這些決定包括人員組織安排、機器資源配置、測試設計的時間定位、測試支持代碼的數量、哪些測試要做自動化,等等。這些決定應根據單獨的交接中的內容信息來作出。如果僅有一次交接,那麼你可以更順利一些。測試計劃還應繼續考慮以下問題:

  1. 風險分析,誰會因此受到損害,以什麼方式?

  2. 選定一種測試途徑來定位特定的風險。

  3. 對測試設計和執行的周期和成本進行估計。

  4. 在項目進度上的特定位置,將計劃納入執行的行動:

  A. 開始對測試進行設計…

  B. … 同時設計和創建一些支持測試的代碼…

  C. … 在全部測試完成以前就執行部分的測試,因為可能存在不只一次的交接,在每一次交接的測試規劃中,可能存在一些潛在的複雜的相互影響。工作安排不得不進行一些調整以達到相互間的平衡。測試支持代碼和工具需要在各項任務中得到共享。你還必須考慮到在什麼程度上讓那些為早先的交接所設計的測試在以後重新執行,等等。

      這看起來很複雜。看上去似乎有太多的內容需要跟蹤,而且太多的內容可能被忽略。也許你認為我是在要求你要對每一次交接來執行IEEE 829 【IEEE98】中關於測試計劃的要求,然後把它們合併為一份貫穿整個項目的針對交接進行測試的測試計劃。

      是,也不是。思考問題總是要佔用時間的。太多的計劃可能會減少結果的產出。在有些時候,你需要做的是停止計劃並開始行動。例如,你無法思考並描述每一個bug修復,儘管bug修復也是一種交接。

      但是bug修復是實際工作中現實存在的問題。總體項目計劃中應該包含bug修復。需要強調的是,你應該有一個默認的bug修改處理的標準過程,該過程應包括運行於每一個提交的bug修復的驗證過程。你還需要努力地去思考問題。很多時候,各項驗證是被放在一起同時進行並完成的。

      比較現實地來說,一個模型應該允許一些機械式行為,例如,「不管是哪一個X類型的交接,都要執行下列操作」。同時我們鼓勵對特定的交接執行剛剛夠的檢查,對於風險越小的交接,就越可以採用機械式的測試行為。

      一個明確考慮到基本的測試現實的模型肯定會比忽略這些現實或者把你的工作複雜性完全抽象化的模型做得更好。文檔則是另一個例子。

      我還沒有提到需求及規格說明書,或者設計文檔。某個交接中產生的一系列變化會引起很多爭議。這些文檔所扮演的角色是什麼呢?它們常常是這麼被使用的:

 軟體測試

  (圖10:測試中對開發文檔的利用)

      文檔可以指導你在一個交接變化時如何作出反應。如果你有一份很好的需求文檔,它可能是產品所解決的問題的描述,儘管也許不是很直接。它可以幫助你對風險進行分析。一份好的規格說明應對系統的行為進行描述。這將幫助你把測試方法轉化為具體的測試。一份好的架構設計則可以幫助你理解變化可能引起的幾種不同的情況:系統的其它部分會受到怎樣的影響?什麼測試需要再次進行?

      我並不是經常能看到好的文檔。需求文檔常常象是市場銷售用的系統特性列表。規格說明書有時就象是在代碼完成後提交的用戶手冊文件。而設計文檔經常不存在。

      好了,通過針對交接所引起的變化的集中討論,我已把測試過程和軟體開發過程相對地分離開了。如果文檔中關於「XML支持功能加入到COMM」的描述很薄弱的話,我會盡自己所知來進行儘可能好的測試設計。然後,假如在項目後期,XML相關的用戶文檔出來了,我就可以對後來再次提交的交接增加相關的測試。假如市場需求改變了,她們經常會這麼做,我還會在此後增加或者去除一些測試。所有這一切看起來是這樣的:

 軟體測試

  (圖11--在文檔不完整的條件下進行測試,並在後期補充測試)

      這樣,雖然項目文檔總是不到位,而且經常延遲提交,測試的效果也因此常常被降低,我們還是要避免測試受到項目文檔的制約。

      頭腦靈活的測試人員並不過於相信文檔。畢竟,總是人在犯錯誤。那麼,難道不是人在寫這些文檔嗎?

      由於「正式的」文檔是很薄弱的,測試模型必須明確地鼓勵在測試過程中使用項目文檔之外的各種不同信息來源。

      測試人員必須和程序員、用戶、市場人員、技術作者以及任何的可能為實現更好測試提供線索的人進行交流。測試人員還應該努力把自己沉浸在某些技術所構建的氛圍中。例如,我希望測試人員在做XML測試工作時常去訪問W3組織的XML地址(http://www.w3.org/XML/)以及其它XML站點、郵件列表,甚至包括比較特別的 如Dave Winer的DaveNet/腳本新聞(http://www.scripting.com/)。這些資源並不是所謂的「輔助通道」,而是可以被列入計劃和進度日程的資源。

      另外,所執行的測試本身也是一種有用的信息的資源。好的測試人員會仔細閱讀bug報告,因為這些報告講授了系統所存在的薄弱之處。特別地,這些報告還暗示了一些正式的架構設計所沒有提供的架構上的策略。執行測試的行為應該產生一些新的測試想法。如果模型沒有考慮到這些,那麼它就是一個落後的模型。

      因此,測試模型應該包含反饋的循環,讓測試設計可以考慮到,在運行測試時還可以繼續發現到更多的測試內容。

      在我們的工作中,真正的複雜性來自於所有計劃的執行都處於一個不確定的、容易忽略的環境里。代碼並不是唯一在不斷變化的東西。而計劃日程也在改變。新的功能擴充會帶來新的里程碑。某些功能會從當前版本中去除。在開發過程中,所有人--市場人員、開發人員和測試人員,都會逐漸對諸如「產品究竟提供什麼」這樣的問題有越來越清晰的了解。在這些情形下,我們怎麼能說測試計劃的第一個版本會是完全正確的呢?

      因此,模型應該要求測試計劃人制定明確的規定,對已交接的交接內容,新的交接,以及交接內容的變更進行負責。

      總結

      V模型有以下致命的缺陷,其它模型實際上也與此相似:

  1. 忽略了這樣的事實情況,即軟體開發是由一系列的交接所組成,每一次交接內容都改變了前一次交接的行為。

  2. 依賴於開發文檔的存在,及文檔的精確性、完整性,並且沒有對時間進行限制。

  3. 認定一種測試的設計是依據某一個單獨的文檔,而不包括根據其前後階段的文檔的修改而作相應修改。

  4. 認定這些依賴於某個單獨文檔的測試一定要在一起執行。

      我大致描述了一個替代模型,但還不夠精細。它考慮到了代碼的交接和里程碑。對測試成本控制作了以下明確描述:

      測試設計的目標是定義好可能發現bug的測試輸入,而測試執行的目標是以各種方式加入這些數據,並檢驗結果,由此來降低整個生命周期的成本。

      我們的模型假設軟體產品總是不完美的,開發過程中有很多變更,而且對產品的測試也是一個不斷學習的過程。

      過去,我很少考慮到模型。表面上我一直還在用V模型。雖然我按此制訂計劃,但我總是還要花費很多額外的精力和時間來考慮模型中沒有提到的方面。換言之,模型造成了一些阻礙,因此我有必要對此進行研究。

      對一個新的模型來說,對模型所提出的要求必須非常明確,這就象業務需求對產品開發非常重要一樣。我希望自己對本文中所提倡的模型的要求的描述能夠和V模型中的描述一樣精確,並具有同樣的指導意義。

      理想的測試模型應該包括下列要求:

  1. 使測試對項目中的每一次代碼交接有所反應。

  2. 要求測試計劃人制定明確的規定,對已交接的交接內容,新的交接,以及交接內容的變更進行負責。

  3. 在測試設計中,除了使用項目文檔外,還應明確鼓勵使用其它各種信息,這些信息有不同來源。

  4. 事實上項目文檔總是不到位,而且經常延遲提交,測試的效果也因此常常被降低。但我們還是要盡量避免測試受到項目文檔的制約。

  5. 允許根據多種來源提供的綜合信息來設計一些獨立的測試。

  6. 讓測試被重新設計,以新的信息形式進行表現。

  7. 包含反饋的循環,讓測試設計可以考慮到,在運行測試時還可以繼續發現到更多的測試內容。

  8. 讓測試人員認識到,避免測試的延遲可以節省成本。

  9. 在組件被組裝到程序中去之前對組件的執行進行測試。

軟體測試的技術 :單元測試和集成測試:什麼是單元測試、單元測試的目標和任務、單元測試方法、調試與評估、什麼是集成測試、集成測試目標和任務、集成測試的模式與方法 

 軟體開發未來前景:

   隨著軟體產業的發展,軟體產品的質量控制與質量管理正逐漸成為軟體企業生存與發展的核心。幾乎每個大中型IT企業的軟體產品在發布前都需要大量的質量控制、測試和文檔工作,而這些工作必須依靠擁有嫻熟技術的專業軟體人才來完成。軟體測試工程師就是這樣的一個企業重頭角色。業內人士分析,該類職位的需求主要集中在沿海發達城市,其中北京和上海的需求量分別佔去33%和29%。民企需求量最大,佔19%,外商獨資歐美類企業需求排列第二,佔15%。然而,目前的現狀是:一方面企業對高質量的測試工程師需求量越來越大越大,另一方面國內原來對測試工程師的職業重視程度不夠,使許多人不了解測試工程師具體是從事什麼工作。這使得許多IT公司只能通過在實際工作中進行淘汰的方式對測試工程師進行篩選,因此國內在短期將出現測試工程師嚴重短缺的現象。根據對近期網路招聘IT人才情況的了解,許多正在招聘軟體測試工程師的企業。


軟體測試難學嗎?

好多人會問「沒有基礎適合參加軟體測試的培訓嗎?」「或者從高中到大學一直學的是文史類專業,學軟體測試能學會嗎」「不會開發語言能學的精通測試嗎?」等等此類問題,首先會語言對你做測試肯定是有好處的,但是不會語言絕非不能做測試了,在剛開始做測試的時候是很多都是黑盒/功能/性能測試,接觸代碼機會很小,另外對於測試人員的代碼能力要求:僅僅是能看懂代碼就可以了,無需精通。
 
其實真正決定你是否能在測試行業有大的一個發展最重要的一下三點:
 
l         工作主動性:工作態度如何,是評價一個測試人員最主要的方面,一個高水平的測試人員(指純技術能力)如果沒有一個好的工作態度,在測試團隊中有時候不但不能對測試工作 起到推動作用,有時候還起到阻礙作用,而一個願意工作的測試人員,哪怕他的技術水平不高,人也不聰明,但對自己的工作認真負責,你告訴他的事情,他都可以 認真去做,這個測試人員也會對測試工作起到很大的促進作用。這也是為什麼很多企業願意讓剛參加工作的人員做測試工作的一個主要原因。


l         認真,細心,不怕麻煩:不能不說的是,測試工作是一個煩瑣的工作,如果你不是認真、細心,不怕麻煩的人,建議你最好不要進入這個行業,否則,最後難受的肯定是你自己。有那麼一句話:細節決定成敗,這句話格外適用於測試人員。
l         學習能力強,善於總結:不斷的學習新技術,不斷總結在實際工作遇到的問題,解決的方法,並把他們整理歸納,是一個測試人員提高自己的技術水平的最好的方法。


    計算機專業畢業的學員和非計算機專業畢業的學員都必須參加入學測試。入學測試的主要目的在於考察學員的綜合基礎,判斷學員是否適合參加培訓,入學測試的內容包括計算機基礎、網路配置、資料庫、操作系統、計算機英語等相關知識,在正式開課以前入學測試可以隨時進行。 


所以說不必糾結與:沒有基礎能否學會?或者一些其他的問題而畏首畏腳瞻前顧後。重要的是你是否已經做好了學習的準備和以上三點總結的準備

上一篇[恐懼]    下一篇 [赤石脂散]

相關評論

同義詞:暫無同義詞