目前軟體測驗對提高軟體質量重要性的不斷提高,軟體測驗也不斷受到重視,
國內軟體測驗程序的不規范,重視開發和輕視測驗的現象依舊存在
因此,對于軟體測驗的重要性、測驗方法和測驗程序等方面都存在很多不恰當的認識
一起來了解一下:
誤區1:軟體開發完成后才進行測驗
在傳統的瀑布模型中,軟體專案主要有一下幾個階段組成:
用戶需求、需求分析、概要設計、詳細設計、編碼和實作、測驗以及運行維護,
由于軟體測驗僅處于運行維護階段之前,是軟體產品交付用戶使用之前保證軟體質量的重要手段,
因此人們一般認為,軟體測驗只是軟體編碼后的一個階段,
但隨著軟體測驗業的發展,人們越來越認識到:
軟體測驗不應只是軟體專案的收尾作業,而應該在軟體生命周期的每一階段中都包含測驗,
軟體測驗是貫穿于整個軟體開發生命周期的程序活動,包括軟體測驗計劃、軟體測驗需求分析、
軟體測驗用例設計、軟體測驗執行、軟體缺陷管理、
軟體測驗風險管理以及其他的一些軟體測驗相關的活動等等組成,
在軟體專案的每個階段,都需要進行不同目的和不同內容的測驗活動,
以保證各個階段作業產品輸出的正確性,軟體測驗的物件也不僅僅是軟體代碼,
還包括軟體需求檔案和設計檔案等其他所有的軟體作業產品,
軟體開發與軟體測驗之間應該是互動進行的,比如單元編碼之后需要進行單元測驗,模塊組合之后進行集成測驗,
如果等到軟體編碼結束之后才進行測驗,測驗的時間很有限,
很難達到測驗的覆寫率要求和測驗的質量要求,同時,假如在專案開發的后期,
發現一些軟體需求階段和概要設計階段的錯誤和問題,修改這些缺陷導致的成本將是非常高的,
有資料表明:平均而言,如果在需求階段修正一個錯誤的代價是1,
那么,在設計階段就是它的3-6倍,在編程階段是它的10倍,在內部測驗階段是它的20-40倍,
在外部測驗階段是它的30-70倍,而到了產品發布出去,這個數字就是40-1000倍,
修正錯誤的代價不是隨著時間線性增長的,而幾乎是呈指數增長的,
因此,應盡早地不斷地進行軟體測驗,發現錯誤并加以修正,而非軟體開發結束后才進行測驗,
誤區2:軟體發布后發現軟體問題,那是測驗人員的責任
許多人認為測驗人員需要對發布的軟體質量負責,假如軟體到用戶后,發現很多的問題,
那是測驗人員的錯和責任,這種認識誤區非常打擊測驗人員的積極性,
軟體中的缺陷可能來自軟體開發程序中的任何一個程序,而對于軟體測驗而言,
只能證明軟體存在缺陷,而不能保證軟體沒有錯誤,
通過軟體測驗,無法發現軟體中的所有錯誤和缺陷,
從軟體開發的角度看,軟體的高質量不是軟體測驗人員測出來的,
而是需要軟體生命周期的各個程序共同來保證的,出現軟體錯誤,
不能簡單地歸結為某一個人或某個團隊的責任,比如有些錯誤的產生可能不是技術原因,
可能來自于混亂的專案管理;或者客戶發現軟體某些功能并沒有按照原有需求來實作,換言之,
軟體沒有完成客戶想做的操作,諸如此類問題很可能是軟體設計人員理解需求錯誤致使設計不當所引起的,
軟體的質量,不僅僅只是測驗人員的事情,軟體專案參與的所有人員都應該關注軟體的質量,
軟體質量的提高,需要每個專案人員的努力,測驗只是提高軟體質量的一個重要環節,
質量保證應該貫穿于整個軟體開發生命周期的所有的開發活動、測驗活動、專案管理活動等,
同時,采用合適的開發和測驗程序,對改進軟體質量也能起到重要的作用,除了測驗活動外,
同時應該分析軟體專案的各個程序,從程序改進方面尋找產生錯誤的原因和改進的措施,
誤區3:測驗人員不需要具備很高的技能
不少軟體業人士認為軟體測驗行業對軟體測驗人員的技能要求不高,
認為測驗只是對照產品規格書操作軟體,發現軟體與規格說明不一致的地方,是沒有技術含量的作業,
這種觀點是錯誤的,或者至少是步恰當的,隨著軟體測驗行業的發展,
測驗不僅僅是運行軟體發現缺陷的一個程序,而是從專案早期,測驗人員就開始介入,
進行測驗需求分析、計劃測驗等,這要求測驗人員有很好的溝通能力、理解能力、
分析問題能力,同時還必須對產品開發技術有一定的了解,
隨著軟體工程學的發展和軟體專案管理經驗的提高,軟體測驗已經形成了一個獨立的技術學科,
演變成一個具有巨大市場需求的行業,軟體測驗技術不斷更新和完善,新工具、新流程、
新測驗設計方法都在不斷更新,需要掌握和學習很多測驗知識,所以,
具有編程經驗的程式員不一定是一名優秀的測驗人員,軟體測驗包括測驗技術和管理兩個方面,
完全掌握這兩個方面的內容,需要很多測驗實踐經驗和測驗理論知識,需要我們不斷的學習,
誤區4:測驗是測驗人員的作業,和開發人員無關
我們提倡軟體測驗盡早介入軟體專案,或者說我們提倡貫穿于整個軟體開發生命周期的測驗,
因此,在專案概念、需求和設計階段,軟體測驗就應該介入專案中去,
開發和測驗是相輔相成的程序,需要軟體測驗人員和程式員、
系統分析員等專案其他成員保持密切的聯系,需要更多的交流和協調,以便提高測驗效率,
在這些階段所發現的問題將有助于開發設計人員完善需求和設計,
在專案開發程序中,一般由開發人員針對模塊進行白盒測驗,這是早期的測驗,
后期對于測驗人員所發現的缺陷,開發人員應根據優先級來進行修復,針對開發人員的修改,
測驗人員還要進行再測驗和回歸測驗作業,因此,在整個專案程序當中,
測驗也不僅僅是測驗人員的事情,而是測驗人員和開發人員緊密合作的程序,
誤區5:由專案進度來決定測驗作業量
規范的測驗流程應該是一個整體的連續的程序,包括測驗計劃和控制、測驗分析和設計、
測驗實作和執行等階段,每一階段也應有各自的規程,而大多數人對測驗的理解往往是隨專案進度而
定,即離專案交付空余的時間多,就多做測驗;反之,則少做測驗,這樣很可能導致測驗時間緊張,
從而可能放棄其中的一些測驗,可能導致遺漏一些重要的缺陷,顯然這種做法存在非常大的風險,
測驗進度由專案開發進度來確定,這個觀念很大程度上是因為
“測驗是開發生命周期的一個階段”這個誤區造成的,實際上,我們一直強調,
測驗是貫穿于整個軟體開發生命周期的,在制訂軟體專案計劃的同時,
就需要規劃和制訂軟體測驗的計劃,測驗計劃的一個重要內容是確定測驗的進度
(也就是測驗時間和資源的安排),因此,測驗時間的多少,應該在專案早期根據專案的特點和風險
分析結果來確定,而不僅僅是決定于專案進度,
誤區6:軟體測驗是沒有前途的作業,只有開發人員是軟體高手
由于我國軟體整體開發能力比較低,軟體程序還不規范,
專案的成功往往靠個別開發人員的能力,他們負責總體設計和程式詳細設計,
認為軟體開發就是撰寫代碼,給人的印象往往是程式員是真正的牛人,具有很高的地位和待遇,
因此,在這種環境下,軟體測驗并不受重視,軟體測驗人員的地位和待遇自然就偏低了,
甚至軟體測驗變得可有可無,
隨著市場對軟體質量要求的不斷提高,軟體測驗將變得越來越重要,
相應的軟體測驗人員的地位和待遇將會逐漸提高,在微軟等軟體程序比較規范的大公司,
軟體測驗人員的數量和待遇與程式員沒有多大差別,優秀測驗人員的待遇甚至比程式員還要高,
軟體測驗將會成為一個具有很大發展前景的行業,軟體測驗大有前途,
市場需要更多具有豐富測驗技術和管理經驗的測驗人員,他們同樣是軟體專家,
誤區7:自動化測驗效率高,將取代軟體手工測驗
測驗自動化在某些情況下可以提高測驗的效率(比如完成重復的測驗配置、模擬大虛擬用戶等),
但是并不是所有的測驗都適合自動化,如程式需要處理的資料量不大、程式運行的次數不多、
或者測驗需要一些人的主觀判斷(如界面測驗)等,在這些情況下,
自動化測驗可能并不是很好的選擇,
同時,自動化測驗需要在前期投入大量的資源和作業量,同時需要維護的成本很高,包括環境的搭建、測驗腳本的設計、維護等,因此,要具體情況具體分析,不能盲目推崇測驗自動化,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/290855.html
標籤:其他
上一篇:軟體測驗崗:慘不忍睹的阿里三面,幸好做足了準備,已拿offer
下一篇:jedis的操作和使用
