初步瞭解軟體測試

菜菜也逆襲發表於2018-11-18

什麼是軟體測試

軟體測試的主要工作就是驗證軟體功能是否滿足使用者需求。

那麼軟體測試和軟體的除錯又沒什麼區別呢?

1.目的不同
軟體測試的目的測試找出和程式的缺陷,而軟體除錯過程是為了定位問題,並解決問題。
2.參與角色不同
軟體測試是由測試人員主要參與的,而軟體除錯是又開發人員完成的
3.執行階段不同
測試要貫穿整個軟體的開發生命週期,而除錯只在開發階段。

軟體測試又有哪些崗位呢

有軟體測試開發工程師SET,有測試工程師,有軟體開發工程師,WEB測試工程師,APP測試工程師,遊戲測試工程師,嵌入式測試工程師,等。

軟體測試的目的和原則

目的和概念描述類似,主要就是驗證軟體有還是沒有缺陷
原則:軟體測試是以客戶為中心的,要遵循軟體測試的規範,流程、標準和要求。

什麼是需求

1.使用者需求:籠統的使用者需要軟體實現的要求,實現什麼功能,滿足什麼要求等。
2.軟體需求:相比較以使用者需求,軟體需求更加具體(使用者需求通過溝通確定軟體需求),是將使用者需求拆分成更加具體的多個子需求。可以理解成要想實現使用者需求需要先滿足這些軟體需求。軟體需求的定義要求,可以滿足開發人員看了會寫程式碼,測試人員看了可以編寫測試用例。
綜上,需求就是要滿足使用者期望,符合正式文件規定的所應該具有的條件和權能,需求包含使用者需求和軟體需求。

什麼是bug缺陷

當有規格說明書,而且說明書正確的前提下,程式與規格說明的不一致、不匹配就是bug
當沒有規格說明書時,程式沒有實現終端使用者合理預期的功能要求,就是軟體bug。

什麼是測試用例

測試用例就是味蕾實施測試而向提供給測試系統的一組測試元素集合,包括測試環境,操作步驟,測試資料,預期結果等要素。

什麼是軟體的生命週期

從軟體被需要,設定需求分析,
到計劃軟體開發過程,
到設計軟體的要求
到具體的編碼
到測試
到執行維護
需求分析、計劃、設計、編碼、測試、執行維護

開發模型

開發模型有多種瀑布模型,螺旋模型,增量模型,迭代模型、敏捷模型等
1.瀑布模型
瀑布模型是較為傳統的開發模式,採用線性測試,一步接著一步走,強調開發階段,強調早期計劃和需求分析。強調測試。
但是所帶來的缺點、往往就是由於線性操作很多風險不足滯留到後期測試階段才顯露,因而失去了及早矯正錯誤的機會。所以瀑布模式不適應需求頻繁變更的情況。
2.螺旋模型-漸進式
螺旋模式強調風險分析,螺旋前進,適合規模龐大,複雜度高,風險大的專案。
3.增量模型
增量模式利用塊的概念,使用的是組塊建造的思想。就是一個模組一個模組的測試。這種開發模型,估計使用者反饋,使得小組以一種迴圈可預測的方式驅動產品開發。增量和迭代方式。因為不斷的對需求的調整,要求測試頻繁進行,並且與開發人員緊密合作。
4.迭代模型
相比較與增量模型,迭代模型強調的是先整體後細節的思想,是一個反覆求精,細化的過程。
5.敏捷模型
敏捷模型強調的是溝通,是一種輕文件,要求客戶參與,並且擁抱變化,樂於接收需求修改的開發模型。因為敏捷模型的迭代週期頻繁,所以對測試人員要求很高,而且因為擁抱變化,需要調整所以每天都會有例會哦。

敏捷模型scrum步驟

1.首先產品負責人(product owner)先將功能點整理成多個使用者故事(user story)
2.釋出產品會議 負責人講解使用者故事,對其進行評估排序。
3.迭代計劃會議 對每個使用者故事進行任務分解,確定每個任務的負責人。
4.每日例會 敏捷教練(scrum master)召集會議,總結今天,計劃明天,反應問題
5.演示會議 迭代結束後,展示迭代成果,反饋記錄由負責人整理成新的使用者故事
6.回顧會議 對一期的迭代總結,制定改進計劃,以達到持續改進的效果。

軟體測試模型

軟體測試V模型

在這裡插入圖片描述

1.單元和整合測試應檢測程式的執行是否滿足軟體設計的要求。
2.系統測試應檢測系統功能、效能的質量特性是否達到系統要求的指標。
3.驗收測試確定軟體的實現是否滿足使用者需要或合同的要求
V模型的缺陷:風險往往滯留到後期才暴露。修復代價大。
軟體測試W模型
在這裡插入圖片描述

缺點:依然是序列的,必須等程式碼編碼完成才能測試,不能滿足需求頻繁變更,不能適應敏捷開發模型。

配置管理軟體

SVN &GIT
配置管理是通過對在軟體生命週期不同的時間點上的軟體配置進行標識,並對這些被標識的軟體配置項的更改進行系統控制,從而達到保證軟體產品的完整性和可溯性的過程。

什麼是配置項
程式碼,文件,工具,程式都是配置項

軟體配置管理的應用

軟體開發過程中會產生大量軟體產品(包括文件、原始碼和資料等),這些產品之間存在著關聯關係。
同一軟體產品也會發生變更,從而產生許多版本。軟體開發小組必須清晰地知道會有哪些產品、這些產品會有哪些不同的形式和版本。開發小組必須清晰地知道如何將產品的變更通知給受影響的小組。如果不能有效地瞭解軟體產品及其變更,開發小組將很難組裝這些軟體產品,很難得到所需的軟體產品,先向上變更為版本再除錯。
優點:
(1)能夠對專案中的文件、程式碼等的變化進行有效管理。
(2)能夠方便地重現某個檔案的歷史版本。
(3)能夠重新編譯某個歷史版本,使維護工作變得容易。
(4)能夠使異地多團隊開發、並行開發成為現實。
(5)從公司級看,實行統一的配置管理流程可提高專案組間人員流動時的工作效率。

配置管理和軟體測試的關係

測試人員應該從配置庫取原始碼編譯後再測試,只有看到新的構建版本不再出現那個Bug,才能把缺陷庫中的Bug關閉。

軟體測試的生命週期

需求分析→測試計劃→測試設計、測試開發→測試執行→測試評估
1.需求階段 -測試人員瞭解需求、對需求進行分解,得出測試需求
2.計劃階段 -根據需求編寫測試計劃/測試方案
3.設計階段 -測試人員適當的瞭解設計,對於設計測試用例是很有幫助的,測試人員搭建測試用例框架,根據需求和設計編寫一部分測試用例
4.編碼階段 -測試人員一般是不需要編碼的,但已經編碼的模組,專業的白盒測試人員可以計劃執行單元測試,完善、細化測試用例以及調整測試計劃和方案。
5.測試階段 -測試階段是軟體測試人員最為重要的工作階段,根據測試用例和計劃執行測試,在執行的過程中記錄、管理缺陷,測試完成後編寫測試報告。
6.執行維護 -測試人員需要參與專案的實施工作。測試人員對專案產品的業務和操作非常瞭解,加上測試人員的溝通表達能力一般都比較強,所以測試人員可以參與使用者使用軟體的培訓,在試執行專案時收集問題並及時反饋給相關負責人。

相關文章