「软件测试基础」理论篇之软件测试概论
文章目錄
- 1. 軟件
- 1.1 軟件發展史
- 1.2 軟件生命周期
- 1.3 軟件缺陷
- 1.4 三種糾錯技術
- 2. 軟件過程
- 2.1 RUP
- 2.1.1 RUP各個階段
- 2.1.2 RUP核心工作流
- 2.2 敏捷開發
- 2.2.1 敏捷開發簡介
- 2.2.2 敏捷開發的特征
- 3. 軟件質量
- 3.1 概論
- 3.2 CMM/CMMI
- 3.2.1 CMM
- 3.2.2 CMMI
- 4 測試與開發的關系
1. 軟件
軟件是一系列按照特定順序組織的計算機數據和指令的集合。一般認為,軟件包括以下內容:
(1)運行時,能夠提供所要求功能和性能的指令或計算機程序集合。
(2)程序更夠妥善地處理信息的數據結構。
(3)描述程序功能需求以及程序如何操作和使用的文檔。
我們可以簡單理解為,軟件=程序+文檔。
1.1 軟件發展史
軟件的發展可以分為如下四個階段:
- 第一個階段(20世紀50年代初期至60年代中期),被稱為程序設計階段。此時軟件規模小、功能單一,而且只有程序,沒有文檔。
- 第二個階段(20世紀60年代中期至70年代末期),被稱為程序系統階段。這個階段已經出現了多道程序設計技術、多用戶系統、人機交互技術等,軟件廣泛應用,但軟件技術和管理水平相對落后,導致出現“軟件危機”。
- 第三個階段(20世紀70年代末期至80年代中期),被稱為軟件工程階段。這個階段以軟件產品化、序列化、工程化和標準化為特征的軟件產業發展起來,軟件開發有了可以遵循的軟件工程化的設計準則、方法和標準。
- 第四個階段(20世紀80年代中期至今),這個階段C/S體系結構,特別是Web技術和網絡分布式對象技術法飛速發展,導致軟件體系結構向更靈活的多層分布式結構演變,CORBA,EJB,COM/DCOM等三大分布式的對象模型技術相繼出現。
軟件工程研究的主要內容是:如何應用科學的理論和工程上的技術來指導軟件開發,進而達到以較少的投資獲得高質量軟件的最終目標。
(看到這句話,讓我有了一絲絲領悟:程序員也不能埋頭編碼,還是要懂點產品思維的好)
1.2 軟件生命周期
軟件生命周期具有如下六個階段:
(1)問題的定義和規劃
(2)需求分析
(3)軟件設計
(4)程序編碼
(5)軟件測試
(6)運行維護
其中,軟件維護是軟件生命周期中持續時間最長的階段。
1.3 軟件缺陷
軟件缺陷是指軟件系統或系統部件中那些導致系統或部件不能實現其功能的問題或差錯。通常認為,符合下面4個規則之一的就是軟件缺陷:
1.4 三種糾錯技術
糾錯之前需要先查明錯誤,而查錯工作量通常占整個糾錯的90%以上,下面三種是常用的查錯手段:
通過這種手段,我們可以查看到程序運行中過程量的值,以此來定位錯誤原因。這是我們寫一開始學編程時最常用的手段。
斷點可以使運行的程序在斷點處暫停下來,我們就可以通過觀察變量的值來分析程序運行的情況,進而快速找到錯誤所在。
一般是把代碼注釋掉,留下有可能出錯的地方,進而縮小錯誤的范圍;也或者把有可能出錯的部分取出來單獨運行。
2. 軟件過程
2.1 RUP
RUP(Rational Unified Process)譯為Rational統一過程,以統一建模語言(UML)描述軟件開發過程。
2.1.1 RUP各個階段
RUP中的軟件生命周在時間上被分解為4個順序的階段,分別是初始階段、細化階段、構建階段和交付階段。
2.1.2 RUP核心工作流
RUP共有9個核心工作流,分別為6個核心過程工作流和3個核心支持工作流。
1)商業建模
2)需求
3)分析設計
4)實施
5)測試
6)部署
7)配置和變更管理
8)項目管理
9)環境
PS:前6個為核心過程工作流,后3個為核心支持工作流。
2.2 敏捷開發
由于傳統的開發方法使程序員花費大量的時間在開發文檔的撰寫上,真正寫代碼的時間很少,而且過于依賴過程控制,導致開發過程管理復雜且低效。于是,敏捷過程就應運而生(時間在2001年)。
2.2.1 敏捷開發簡介
《敏捷宣言》的內容如下:
“通過開發軟件和幫助別人開發軟件,我們找到了一些更好的開發軟件的方式。通過這一工作,我們得出了這些價值:
- 個體和交互 勝過 過程和工具
- 可以工作的軟件 勝過 面面俱到的文檔
- 客戶合作 勝過 合同談判
- 相應變化 勝過 遵循計劃
也就是說,盡管右邊的項也很有價值,但我們認為左邊的項更有價值”
在這種價值觀的指導下,誕生了包括XP(極限編程)、FDD(功能驅動開發)等在內的開發過程。
2.2.2 敏捷開發的特征
敏捷開發主要有兩個主要特征:
(1)開發采用適應性方法,開發過程以代碼為核心,經過多次小型迭代逐步逼近實際需求,而文檔則作為交流工具的作用被弱化,作為管理監督的功能被取消。
(2)以人為本。程序員變成了開發的主體,所有的主要涉及策略的指定、開發方法的選擇、需求的確定都由層序員決定。
3. 軟件質量
3.1 概論
ANSI/IEEE Std 729——1983給的定義:“與軟件產品滿足規定的和隱含的需求的能力有關的特征或特征的全體”。
CMM對質量的定義:“①一個系統、組件或者過程符合特定需求的程度;②一個系統、組件或者過程符合客戶或用戶的要求或期望的程度。”
M.J.Fisher給的定義:“所有描述計算機軟件優秀程度的特性的組合。”
軟件質量框架是由“質量特性—質量子特性—度量因子”構成的 3 層模型。由于度量因子由使用單位自行決定,下圖就寫了質量特性和質量子特性:
3.2 CMM/CMMI
3.2.1 CMM
CMM是軟件過程改良和評估模型,由卡耐基—梅隆大學軟件工程研究院指定,也稱為SEI-CMM。
CMM為軟件企業的過程能力提供的階梯式進化框架如下表所示:
(CMM評估方法已經被停止,但模型還是存在的。)
3.2.2 CMMI
CMMI是SEI于2000年發布的CMM的新版本,它將各種能力成熟模型整合到同一框架中。其基本思想如下:
(1)解決軟件項目過程改進難度增大問題。
(2)實現軟件工程的并行與多學科組合。
(3)實現過程改進的最佳效益。
CMMI具有如下兩個功能:
- 軟件采購方法的改革;
- 從集成產品與過程的角度出發,包含健全的系統開發原則的過程改進。
4 測試與開發的關系
放三張圖來供自己參悟一下測試與開發的關系:
-
軟件測試與開發過程的關系
-
軟件測試與軟件開發的并行性
-
完整的軟件開發流程
從上面,我們可以知道,軟件測試不僅僅是測試我們編寫的程序,還要測試軟件過程中所編寫的文檔。同時,測試過程和開發過程是同步進行的,測試過程是對開發過程中階段性成果和最終產品進行驗證的過程,它們是相互依賴的關系。
本文為課堂以及自己看課本的筆記,里面的內容基本都摘自周元哲所著的「軟件測試基礎」,只為方便復習和分享,不作任何商業用途!
(為什么要那么麻煩?那要從一只蝙蝠說起……)
總結
以上是生活随笔為你收集整理的「软件测试基础」理论篇之软件测试概论的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 剑指Offer #10 矩形覆盖(问题分
- 下一篇: 剑指Offer #11 二进制中1的个数