Software Testing_軟體測驗基礎知識

你好，我是阿Ken
開學新加了軟體測驗這門課，故因此特意整理出一個新專欄，
參考學校有關教材并進行整理和刪減，屬于課程相關筆記，重點以考試考點為主，其次為簡單了解軟體測驗，

人總歸不能活的太矯情
希望在一塌糊涂的時候你也能鼓勵自己堅持下去
悲喜自渡，他人難悟

1.1_軟體測驗背景

軟體缺陷給我們的生產和生活造成了大量的損失，這些慘痛的教訓時刻警醒著世人要更加重視軟體測驗，不斷提高軟體的質量，

1.1.1_軟體故障案例

1.1.2 _軟體缺陷定義

軟體缺陷，即計算機軟體或程式中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷，
缺陷的存在會導致軟體產品在某種程度上不能滿足用戶的需要，IEEE729- 1983對缺陷有一個標準的定義:從產品內部看，缺陷是軟體產品開發或維護程序中存在的錯誤、毛病等各種問題;從產品外部看，缺陷是系統所需要實作的某種功能的失效或違背，

對于軟體缺陷的定義，通常有以下5項規則描述，如符合任意一項，便稱為“軟體缺陷”，

(1)軟體未達到產品說明書中已標明的功能，

(2)軟體出現了產品說明書中指明不會出現的錯誤，

(3)軟體未達到產品說明書中雖未指出但應達到的目標，

(4)軟體功能超出了產品說明書中指明的范圍，

(5)軟體測驗人員認為軟體難以理解，不易使用、運行速度緩慢，或者最終用戶認為該軟體使用效果不佳，

1.2_軟體開發程序

1.2.1_軟體產品的組成

1. 軟體產品需要各種開發投入
2. 客戶需求
3. 產品說明書
4. 進度表
5. 軟體設計檔案
6. 測驗檔案

1.2.2_軟體專案組成員

軟體專案的開發需要大量人員的團結協作，下面的清單列出了主要人員及其職責，

①專案管理員、程式管理員或者監制人:始終驅動整個專案，負責撰寫產品說明書、管理進度，進行重大決策和取舍，

②設計師或者系統工程師:是軟體小組的技術專家，設計整個系統架構或軟體構思，③程式員、開發人員或者代碼制作者:設計、撰寫并修復軟體中的缺陷，

④測驗員或者質量評判員:負責找出并報告軟體產品的問題，

⑤技術作者、用戶手冊、用戶培訓專員、手冊編號人員或者文案專員:編制軟體產品附帶的檔案和聯機檔案，

⑥軟體管理員或者制作人員：負責把程式員撰寫的全部檔案資料合成一個軟體包，

1.2.3_軟體開發模式

從最初構思到公開發行軟體產品的程序稱為軟體開發模式，

1. 快速原型模型
   快速原型模型允許在需求分析階段，對軟體的需求進行初步的非完全的分析和定義，

2. 增量模型
   采用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟體的一個可分布的“增量”，

3. 原型模型
   原型模型也稱樣品模型，它采用逐步求精的方法完善模型，

4. 噴泉模型
   噴泉模型是以用戶需求為動力，以物件為驅動的模型，不要用于面向物件技術的軟體開發專案，

5. 螺旋模型
   螺旋模型適合用于需求經常變化的專案，適用于大型復雜的系統，

6. 瀑布模型
   從本質來講，瀑布模型是一個軟體開發架構重復應用的模型，其核心思想是按工序交問題化簡，將功能的實作與設計分開，便于分工協作，即采用結構化的分析與設計方法，將邏輯實作與物理實作分開，

1.3_軟體測驗基本理論

1.3.1_軟體測驗的基本概念

1. 軟體測驗的定義
   軟體測驗就是使用人工或者自動化工具按照測驗方案和流程對產品進行測驗的程序，
   有時需要撰寫不同的測驗工具，設計和維護測驗系統，對測驗方案可能出現的問題進行分析和評估，執行測驗用例后，需要跟蹤故障，以確保開發的產品適合用戶的需求，
   _
   軟體測驗是幫助識別開發完成(中間或最終的版本)的計算機軟體(整體或部分)的正確度、完全度和質量的軟體程序，是SQA ( Sofware Quality Assurance)的重要子域，

2. 測驗原則
   （1）軟體開發人員及程式員應當避免測驗自己的程式，自己軟體的測驗要別人來進行反而更有效，
   （2）應盡早和不斷地進行軟體測驗，
   （3）對測驗用例要有正確的態度，在設計測驗用例時，不僅要考慮合理的輸入條件，更要注意不合理的測驗條件，
   （4）人以群分，物以類聚，充分注意20—80原則，不要以為發現幾個錯誤并且解決這些問題后，就不需要進行測驗了，
   （5）嚴格執行測驗計劃，排除測驗的隨意性，
   （6）應當對每一個測驗結果進行全面檢查，
   （7）妥善保存測驗計劃、測驗用例、測驗報告和最終分析報告，以備回歸測驗及維護之用，

3. 測驗目標
   _
   軟體測驗的目的決定了如何去組織測驗，如果測驗的目的是為了盡可能多地找出錯誤，那么測驗就應該直接針對軟體比較復雜的部分或是以前出錯比較多的位置進行，如果測驗目的是為了給最終用戶提供具有一定可信度的質量評價，那么測驗就應該直接針對在實際應用中會經常用到的商業假設，
   _
   不同的機構會有不同的測驗目的;相同的機構也可能有不同測驗目的，可能是測驗不同區城或是對同一區域的不同層次的測驗，

1.3.2_軟體測驗的基本技術

1. 軟體測驗的基本方法
   _
   對于軟體測驗技術，可以從不同的角度加以分類:
   _
   從是否需要執行被測軟體的角度，可分為靜態測驗和動態測驗:
   _
   從測驗是否針對系統的內部結構和具體實作算的角度來看，可分為白盒測驗和黑盒測驗
   _
   (1)黑盒測驗
   _
   黑盒測驗也稱功能測驗或資料驅動測驗，它是在已知產品所應具有的功能的前提下，通過測驗來檢測每個功能是否都能正常使用，
   在測驗時，把程式看作一個不能打開的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，測驗者在程式介面進行測驗，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入資料而產生正確的輸出資訊，并且保持外部資訊(如資料庫或檔案)的完整性，黑盒測驗方法主要有等價類劃分法、邊界值分析法、因果圖法、錯誤推測法等，主要用于軟體確認測驗，
   _
   “黑盒”法著眼于程式外部結構，不考慮內部邏輯結構，針對軟體界面和軟體功能進行測驗，“黑盒” 法是窮舉輸入測驗，只有把所有可能的輸入都作為測驗情況使用，才能以這種方法查出程式中所有的錯誤，實際上測驗情況有無有多個，人們不僅要測驗所有合法的輸入，面且還要對那些不合法但是可能的輸入進行測驗，
   _
   (2)白盒測驗
   _
   白盒測驗也稱結構測驗或邏輯驅動測驗，它是在已知產品內部作業程序的前提下，可通過測驗來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測驗程式，檢驗程式中的每條通路是否都能按預定要求正確作業，而不顧它的功能，白盒測驗的主要方法有邏輯覆寫法、基本路徑法等，主要用于軟體驗證，
   “白盒”法全面了解程式內部邏輯結構、對所有邏輯路徑進行測驗，“白盒”法是窮舉路徑測驗，在使用這一方案時， 測驗者必須檢查程式的內部結構，從檢查程式的邏輯著手，得出測驗資料，貫穿程式的獨立路徑數是天文數字，但即使每條路徑都測驗了仍然可能有錯誤，第一，窮舉路徑測驗絕不能查出程式違反了設計規范，即程式本身就是個錯誤的程式;第二，窮舉路徑測驗不可能查出程式中因遺漏路徑而出的錯;第三，窮舉路徑測驗可能發現不了一些與資料相關的錯誤，

2. 軟體測驗的復雜性與經濟性
   人們常常以為開發一個程式是困難的，測驗一個程式則比較容易，這其實是種誤解，

3. 測驗程序及組織
   首先，測驗人員要仔細閱讀有關資料，做好測驗前的準備作業，
   測驗程序分成幾個階段：
   1代碼會審
   2單元測驗（集中檢查軟體設計的最小單位–模塊上）
   3集成測驗（將模塊按照設計要求組裝起來同時進行測驗）
   4確認測驗（目的是向未來的用戶表明系統能夠像預定要求那樣作業）
   5系統測驗（軟體開發完成后，最侄訓要與系統中其他部分配套運行）

1.4_軟體質量 與質量模型

1.4.1_軟體質量的定義

軟體質量:即國際化標準組織ISO ISOIEO9126 中將軟體質量定義為反映軟體產品滿足規定需求和潛在需求能力的特征和特征的總和，

MJ. Fisher 將軟體質量定義為所有描述計算機軟體優秀程度的特性的組合，也就是說，為了滿足軟體的各項精確定義的功能、性能要求，符合檔案化的開發標準，需要相應地給出或設計一些質量特性及其組合，要得到高質量的軟體產品，就必須滿足這些質量特性，

按照ANSI/IEEE Std 1061. 1992中的標準，軟體質量定義為:與軟體產品滿足需求所規定的和隱含的能力有關的特征或特性的全體，具體包括:

(1)軟體產品中所能滿足用戶給定需求的全部特性的集合;

(2)軟體具有所有的各種屬性組合的程度;

(3)用戶主觀得出的軟體是否滿足其綜合期望的程度;

(4)決定所用軟體在使用中將滿足其綜合期望程度的合成特性，

目前，對軟體質量特性有多種提法，但實際上是大同小異，ISOIEC 9126際標準中定義的軟體質量特性為以下6項:功能性、 可靠性、易使用性、 效率、可維護性和可移植性，

1.4.2_影響軟體質量的因素

軟體本身的特點和目前軟體開發模式的些缺陷，使軟體內部的質量問題有時不可能完全避免，

(1)軟體本身的特點， 軟體只有復雜性、 一致性、可變性和不可見性，

(2)開發環節多跟據傳統的瀑布模型，增加了成本，

(3)選擇支持工具，在軟體的整個開發程序中，能夠得到的開發工具或管理工具都十分有限，

(4)測驗的局限性，測驗只能在一定程度上把錯誤減少到最低限度，

1.4.3_軟體質量控制

1. 軟體質量控制的定義
   _
   在IEEE中對軟體質量控制的定義是:用以評價開發或生產的軟體產品質量的一系列活動，質量控制是質量管理的一部分， 是為保證每一件產品都滿足對它的需求而應用于整個開發周期中的一系列審查和測驗，
   _
   軟體質量控制是指監視專案的具體結果，以確定其是否符合相關的質量標準，并判斷如何杜絕造成不合格結果的根源，這就是說，軟體質量控制是以軟體質量為目的，以軟體質量評估為度量，以軟體質量控制為核心手段，高效地運作軟體開發的程序，
   _
   高質量的軟體離不開有效的管理和控制，J.M.Juran認為，質量控制是一個常規的程序，通過它度量實際的質量性能并與標準比較，當出現差異時采取行動，由此，Donald Refer給出軟體質量控制定義:軟體質量控制是系列的驗證活動，在軟體開發程序之中的任何一點進行評估開發的軟體產品是否在技術上符合該階段指定的規約，
   _
   由此，我們給出軟體質量管理的定義是:軟體質量管理是一系列的驗證活動，通過這些活動，我們可以判斷軟體開發各個階段是否符合既定的要求，對發生的軟體缺陷和軟體錯誤是否給出及時的修正和糾正，

2. 軟體質量管理方法
   _
   軟體的開發至今仍不能自動化地進行，而以人工開發方式為主，針對軟體的特點，對軟體的質量控制，更應該注重對軟體程序的控制，通過完善質量管理體系以適應軟體質量管理要求，

1.4.4_軟體質量評估的標準與度量

軟體質量p有與硬體不同的評價方法，根據軟體產品的特性，評估一個軟體的質量需要有一個評價標準、一個評價準則和一種度量，

1. 標準
   _
   軟體的質量標準就是軟體質量的6個特性，如下所述，
   _
   (1)功能性:
   指軟體所實作的功能滿足用戶需求的程度，
   _
   (2)可靠性:
   指在規定的時間和條件下，軟體所能維持其應有性能水平的程度，它除了反映軟體滿足用戶需求正常運行的程度，而且反映了在故障發生時能繼續運行的程度，
   _
   (3)易用性:
   指對于一個軟體， 用戶學習、操作時所做的努力程度，易用性反映了軟體與用戶的友善性，
   _
   (4)效率:
   指在指定的條件下，軟體實作某種功能所需要的計算機資源(CPU、記憶體、介面、外設等)時間的有效程度，效率反映了在完成功能要求時，有沒有浪費資源，
   _
   (5) 可維護性:
   指在一個運行的軟體中，為了滿足用戶需求、環境改變或軟體發生錯誤時，進行相應修改所做的努力程度，可維護性反映了在用戶需求、環境發生變化或軟體發生錯誤時，對軟體進行修改的容易程度，
   _
   (6)可移植性:
   指從一個計算機系統或環境移植到另一個計算機系統或環境的容易程度，可移植性反映了軟體在不同環境的適應程度，評價了軟體的質量，

2. 準則
   _
   對不同型別的軟體、軟體的各個開發階段，評價準則要進行不同的有機組合，方可反映出該軟體的質量要素，

3. 度量
   _
   在軟體開發不同的生命周期，對不同型別的軟體在每一個階段制定相應的評價內容，以實作軟體開發程序的質量控制，

1.4.5_軟體度量的方法體系

1. 專案度量
   _
   專案度量是針對軟體開發專案的特定度量，

2. 規模度量
   _
   規模度量是估算軟體專案作業量、編制成本預算、策劃合理專案進度的基礎，

3. 成本度量
   _
   主要指軟體開發專案所需的財務性成本的估算，

4. 顧客滿意度度量

5. 軟體質量的生命周期及其度量

6. 程序度量
   _
   程序度量是對軟體開發程序的各個方面進行度量

以上內容應了解:
軟體缺陷的定義
原型法開發模式的優缺點
軟體測驗的幾大原則
軟體質量的六個特性
測驗的程序及組織

• 簡述原型法開發模式的優缺點
  原型模型的優點如下：
  _
  (1)開發人員和用戶在“原型” 上達成一致，這樣一來，可以減少設計中的錯誤和開發中的風險，也減少了對用戶培訓的時間，而提高了系統的實用、正確性以及用戶的滿意程度，
  _
  (2)縮短了開發周期，加快了工程進度，
  _
  (3)降低成本，
  _
  原型模型的缺點如下:
  _
  (1)當重新生產該產品時，難以讓用戶接收，給工程繼續開展帶來不利因素，
  _
  (2)不宜利用原型系統作為最終產品，采用原型模型開發系統，用戶和開發者必須達成一致，

• 簡述測驗的程序及組織
  當設計作業完成以后，就應該著手測驗的準備作業了，一般來講， 由一位對整個系統設計熟悉的設計人員撰寫測驗大綱，明確測驗的內容和測驗通過的準則，設計完整合理的測驗用例，以便系統實作后進行全面測驗，
  _
  在實作組將所開發的程式經驗證后，提交測驗組，由測驗負責人組織測驗，測驗一般可按下列方式組織：
  _
  (1)首先，測驗人員要仔細閱讀有關資料，包括規格說明、設計檔案、使用說明書及在設計程序中形成的測驗大綱、測驗內容及測驗的通過準則，全面熟悉系統，撰寫測驗計劃，設計測驗用例，作好測驗前的準備作業，
  _
  (2)為了保證測驗的質量，將測驗程序分成幾個階段，即:代碼審查、單元測驗、集成測驗、確認測驗和系統測驗，
  _
  (3)代碼會審，
  代碼會審是由組人通過閱讀、討論和爭議對程式進行靜態分析的程序，會審小組在充分司讀待審程式文本、控制流程圖及有關要求、規范等檔案基礎上，召開代碼會審會，程式員逐句講解程式的邏輯，并展開熱烈的討論甚至爭議，以揭示錯誤的關鍵所在，實踐表明，程式負在講解程序中能發現許多自己原來沒有發現的錯誤，而討論和爭議則進步促使了問題的暴露，
  _
  (4)單元測驗，
  單元測驗集中在檢查軟體設計的最小單位模塊上，通過測驗發現實作該模塊的實際功與定義該模塊的功能說明不符合的情況，以及編碼的錯誤，
  _
  (5)集成測驗，
  集成測驗是將模塊按照設計要求組裝起來同時進行測驗，主要目標是發現與介面有關的問題，如資料穿過介面時可能丟失;一個模塊與另一個模塊可能有由于疏忽的問題而造成有害影響;把子功能組合起來可能不產生預期的主功能;個別看起來是可以接受的誤差可能積累到不能接受的程度;全程資料結構可能有錯誤等，
  _
  (6)確認測驗，
  確認測驗的目的是向未來的用戶表明系統能夠像預定要求那樣作業，經集成測驗后，已經按照設計把所有的模塊組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性， 這就是確認測驗的任務，即軟體的功能和性能如同用戶所合理期待的那樣，
  _
  (7)系統測驗，
  軟體開發完成以后，最侄訓要與系統中其他部分配套運行，進行系統測驗，包括恢復測驗、安全測驗、強度測驗和性能測驗等，
  _
  經過上述的測驗程序對軟體進行測驗后，軟體基本滿足開發的要求，測驗宣告結束，經驗收后，將軟體提交用戶，

記得前幾年上高中的時候，有個同學在講臺上說過一句話，
“你沒有輸，你只不過是還沒有贏而已”
他本來成績好像還前三前五穩穩的，
甚至后來最差的時候都能十幾名，
但他最后是攥著一張雙一流的大學錄取通知書去的北京某校…
平凡很煩
但你不能煩
找到自己的節奏懂得迎難而上
有了自己的節奏堅持下去總歸是沒錯的

我是阿Ken
歡迎下次來訪