2020-10-25

2020-10-26 12:01:26

初始軟體測試——小白篇

前言
軟體測試是伴隨著軟體的產生而由來的,早期因為軟體規模比較小,複雜度比較低,早期開發人員將其進行叫作「偵錯」,目的是完成糾正軟體中已經知道的故障,將經行處理,早期都是開發人員在做,因軟體測試近幾年比較缺乏,對測試工作的人員專業要求越來越高,所以將其開發中分離,對測試更專業的人員來其進行測試,我們叫作軟體測試工程師。

1.什麼是軟體測試?
軟體測試不僅僅是對測試被測物件,軟體測試是一系列的活動,包括需求分析,提缺陷等!軟體測試證明軟體是否可用。是通過手工或自動化方式運程式來驗證軟體是否滿足需求,驗證實際結果和預期結果是否一致。

2.軟體測試的主要工作
①檢視程式碼、評審開發檔案
②進行測試設計、寫作測試檔案(測試計劃、測試方案、測試用例等)
③執行測試,發現軟體缺陷,提交缺陷報告, 並確認缺陷最終得到了修正
④通過測試度量軟體的品質

3,軟體測試生命週期
我們大家都知道任何東西實物都是有一定的生命期的,而我們軟體測試也不例外,也是有生命週期的,我們軟體的生命週期包括(計劃,需求分析,設計,編碼,測試,驗收,執行與維護)接下來我們對其進行解答!
一:計劃
定義:①確定軟體開發總目標
②給出軟體的功能、效能、可靠性以及介面等方面的設想
③研究完成該專案的可行性,探討問題解決方案
④對可供開發使用的資源、成本、可取得的效益和開發進度作出估計
⑤制定完成開發任務的實施計劃
人員:產品經理,運營,開發經理,需求分析師,大boss,專案經理
輸出:需求說明檔案/原型圖/RPD
二:需求分析
定義:對開發的軟體及其詳細的定義, 對開發的軟體各功能進行詳細分析,明確客戶需求
人員:產品經理,開發人員,測試人員,UI設計師
形式:會議
輸出:需求規格說明書(SRS)
三:設計
定義:①把需求規格說明書轉變成軟體結構和資料結構,形成系統架構
②概要設計說明書(HLD)設計階段把各項需求轉變成相應的體系架構
③詳細設計說明書(LLD)對概要設計說明進行詳細的說明
人員:架構師,程式設計師
輸出:概要設計說明書(HHL)&詳細設計說明書(LLD)
四:編碼
定義:把軟體設計轉換成計算機可以接受的程式,即寫成以某個程式 設計語言表示的源程式清單,使用RDBMS工具建立資料庫
人員:程式設計師
輸出:詳細設計說明書(LLD)
五:測試
定義:在軟體設計完成後將其進行嚴密的測試,以發現整個軟體的設計過程中存在的問題 並且糾正。軟體測試分為三個,單元測試,整合測試以及系統測試。
一:單元測試
①主要測試的是程式程式碼,為的是確保各個單元模快被正確的編譯------一般是有開發來做
②單元測試也叫作白盒測試
③測試時依據是詳細設計說明書
二:整合測試
①單元測試後,將其各個模組組和完整的體系,在整合測試主要是各個單元模快進行介面,資料是否正常
②單元測試也叫作灰盒測試
③測試是依據概要設計說明書
三:系統測試
①單元和整合做完後,我們對系統各個功能進行測試,以確保每個功能模快達需求規格說明書要求來以確保實際功能的正常使用。是依據測試人員編寫的測試用例進行測試。
②系統測試也叫作黑合測試和功能測試
③測試輸出主要依據需求規格說明書
六:驗收
①驗收分為正式驗收和非正式驗收
②使用者拿到軟體後,在使用現場,會根據需求規格說明書所有的要求現場做相應的驗收。以確保軟體達到符合效果------使用者測試驗收
七:執行與維護
①軟體維護也是整個生命週期中持續最長的階段,在軟體投入使用後,由於各方面的原因,軟體不能適應使用者需求,以及要延續軟體的使用壽命,就必須對其進行維護
②有運維人員來做
③上線,版本迭代,bug修復
4.軟體研發相關要素
①鐵三角:人員,過程,工具
②只有合適的人員藉助合適的工具經過合適的過程才能研發出高品質的軟體
③工具為人員和過程服務,起 輔助作用,起關鍵作用的是 人員和過程
5.軟體的品質

在這裡插入圖片描述

6.軟體模型
我們常見的軟體研發模型,分別是瀑布模型,增量模型,螺旋模型,迭代模型,敏捷模型,H模型,W模型,V模型,RUP流程以及IPD流程
一:瀑布模型
①嚴格遵循預先計劃的需求分析、設 計、編碼、整合、測試、維護的步 驟順序進行
②主要的問題:嚴格分級導致的自由度降低
開發成果輸出過晚,風險高
後期需求的變化難以調整,代價 高昂
二:W模型
①確定,驗證
②設計檔案和執行順序相反
③開發和測試並行
三:迭代模型
①迭代模型(iterative model)是由IBM公司提出的一種軟體開發 方法,該方法包括一系列的增量的步驟或迭代,每個迭代都包括很 多的開發活動(需求、分析、設計、實現等)
②實現軟體的每項功能反覆求精的過程,是從模糊到清晰的開發 過程。每次迭代是從功能的深度和細化程度來劃分的。 迭代模型最適合使用與前期需求不穩定,需求多變的專案
③缺點:週期長、成本高
④適合大專案、高風險專案,比如是太空梭的控制系統時,迭代 的成本比專案失敗的風險成本低得多,用這種方式明顯有優勢
四:敏捷模型
①人和互動重於過程和工具
②可以工作的軟體重於求全而完備的檔案
③客戶共同作業重於合同談判
④隨時應對變化重於循規蹈矩
⑤因此敏捷方法更適用於較小的隊伍,30,20,10人或者更少
⑥敏捷開發的核心原則:主張簡單,擁抱變化,遞增的變化,快速反應
7:軟體缺陷的由來
①軟體缺陷:既指靜態存在於軟體工作產品(檔案,程式碼中的錯誤,也指軟體執行時由於這些錯誤被 激發引起的和軟體產品預期屬性的偏離現象
②Bug:程式碼中的缺陷。有時也被泛指因軟體產品內部的缺陷引起的軟體產品最終執行時和預期屬性的偏離
③軟體錯誤、軟體缺陷,Bug在實際工作中可以認為一樣
8:缺陷的型別
①遺漏:規定的或預期的需求未體現在產品中(可能未將 規格說明全面實現,也可能需求分析階段就遺漏了需求)
②錯誤:未將規格說明正確實現(可能設計錯誤、也可能 編碼錯誤)
③額外的實現:規格說明並未規定的需求被納入產品,得 到實現
9。軟體測試何時介入?
①軟體測試分為三個階段:專案早期,專案中期,專案後期
②軟體測試介入越早越好,對軟體的品質越好