目錄

• • • 1.什么是軟件測試
    • 2.軟件測試與軟件研發的區別
    • 3.優秀的測試人員所具體的素質（為什么要做軟件測試）
    • 4.軟件測試目的和原則
    • 5.什么是需求
    • 6.什么是BUG
    • 7.測試用例的概念
    • 8.軟件的生命周期
    • 9.軟件開發模型
    • 10.軟件測試模型
    • 11.軟件測試的生命周期（流程）
    • 12.如何描述一個BUG
    • 13.發生沖突如何處理

1.什么是軟件測試

軟件測試就是為了驗證軟件是否符合用戶的需求

2.軟件測試與軟件研發的區別

1.測試與調試的區別

①目的不同
測試的任務是發現程序中的缺陷；
調試的任務是定位并解決程序中的問題。
②參與角色不同
測試主要是由測試人員和開發人員來執行，黑盒測試主要由測試人員完成、單元/集成測試主要是由開發人員執行。調試由開發人員完成。
③執行的階段不同
測試貫穿整個軟件開發生命周期，調試一般在開發階段。

軟件測試與研發的區別

①難易程度 ：開發廣度小，專業度高。測試廣度大，專業度低
②薪水 ：中小企業總體比研發低，自動化等專業測試領域和研發基本無差距。大廠研發測試基本無差別
③發展前景 ：自動化測試、安全測試等領域發展前景和研發基本一致。
④繁忙程度： 一般比研發輕松，但敏捷模式下差距不大，產品發布前壓力比較大
⑤技能要求 ：測試要求更廣泛：業務能力，設計和架構分析能力，測試手段和工具使用，用戶模型分析和理 解，編程能力

3.優秀的測試人員所具體的素質（為什么要做軟件測試）

思維模式 逆向思維：開發蓋房子，測試拆房子。不走尋常路。 發散性思維：探求多項答案

興趣

性格特征：好奇心、成就感、敏感、不浮躁、善于懷疑、批判性思維

能力 快速學習能力、溝通能力、文字能力、開發能力

責任感和壓力

4.軟件測試目的和原則

目的：驗證軟件有沒有問題
原則：以客戶為中心，遵循軟件測試的規范，流程，標準和要求

5.什么是需求

滿足用戶的期望或規定的文檔（合同、規范、標準）所需要的的條件和權限
包括用戶需求和軟件需求
●軟件需求從用戶需求轉化而來
●用戶需求轉換為軟件需求的核心是溝通

6.什么是BUG

1.正式文檔存在且合理，軟件的功能和文檔不相符，叫做軟件缺陷
2.不存在文檔時，用戶的需求存在且合理，程序沒有滿足用戶的需求稱之為軟件缺陷（BUG）

7.測試用例的概念

向被測試系統發起的一組操作集合，包含測試環境、測試數據，操作步驟，預期結果，標題、功能米快、前提條件、重要性。

8.軟件的生命周期

需求分析，計劃、設計、編碼、測試、運行維護

9.軟件開發模型

1.瀑布模型

優點： 強調開發的階段性； 強調早期計劃及需求調查； 強調產品測試。
缺點： 前期的缺陷到后期才有可能比發現，不能適應需求的變化
適用場景：需求比較穩定的項目

2.螺旋模型

優點：強調風險的把握

缺點：風險各項要求較高，對人員，資金，時間的投入較大

適用場景：前期需求不明顯，風險大，項目龐大的需求

3.增量模型，迭代模型
場景：一個系統，開發A B C D四個業務模塊，兩周時間

增量模型：第一周：完成A B模塊； 第二周：完成C D模塊
迭代模型：第一周：完成四個模塊的基礎功能；
第二周：補充完成復雜的業務功能

4.敏捷開發模型
①價值觀

個體與交互重于過程和工具
可用的軟件重于完備的文檔
客戶協作重于合同談判
響應變化重于遵循計劃

②scrum（敏捷開發方法）

scrum將產品的開發分解為若干個小sprint(迭代)，其周期從1周到4周不等，但不會超過4周。參與的團隊成員一般是5到9人。每期迭代要完成的user story是固定的。每次迭代會產生一定的交付

③角色

PO（產品經理）：product owner負責整理user story(用戶故事)，定義其商業價值，對其進行排序，制定發布計劃，對產品負責。
SM（項目經理）：scrum master負責召開各種會議，協調項目，為研發團隊服務。
ST（研發團隊) :scrum Team由不同技能的成員組成，通過緊密協同，完成每一次迭代的目標，交付產品。

④流程

<1> 產品負責人負責整理user story，形成左側的product backlog。
<2>發布計劃會議：product owner負責講解userstory，對其進行估算和排序，發布計劃會議的產出就是制定出 這一期迭代要完成的story列表，sprint backlog。
<3>迭代計劃會議：項目團隊對每一個story進行任務分解，分解的標準是完成該story的所有任務，每個任務都有 明確的負責人，并完成工時的初估計。
<4>每日例會：每天scrum master召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題。
<5> 演示會議：迭代結束之后，召開演示會議，相關人員都受邀參加，團隊負責向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由po整理，形成新的story。
<6>回顧會議：項目團隊對本期迭代進行總結，發現不足，制定改進計劃，下一次迭代繼續改進，已達到持續改 進的效果

⑤敏捷中的測試

特點：輕文檔，輕流程、重目標，重產出，擁抱變化
削弱測試用力的作用，進行探索性測試（思維導圖）

10.軟件測試模型

①V模型

優點：后期測試的每一個階段對應前期開發的階段，有明確的依據
缺點：測試在編碼之后，導致缺陷的風險在后期才會被發現

②W模型

特點;測試的對象不僅僅是程序，還有需求設計等
優點：有利于項目前期的問題及時發現，避免造成后期開發完成才發現前期的問題
缺點：階段性較強，不適用于敏捷開發

11.軟件測試的生命周期（流程）

需求分析→測試計劃→ 測試設計、測試開發→ 測試執行→ 測試評估

12.如何描述一個BUG

<1>版本號、測試環境、操作步驟、預期結果、實際結果

<2>BUG級別：崩潰、嚴重、一般、次要
1、Blocker（崩潰）：
阻礙開發或測試工作的問題；造成系統崩潰、死機、死循環，導致數據庫數據丟失，與數據庫連接錯誤，主要功能
喪失，基本模塊缺失等問題。如：代碼錯誤、死循環、數據庫發生死鎖、重要的一級菜單功能不能使用等（該問題
在測試中較少出現，一旦出現應立即中止當前版本測試）。
2、Critical（嚴重）：
系統主要功能部分喪失、數據庫保存調用錯誤、用戶數據丟失，一級功能菜單不能使用但是不影響其他功能的測
試。功能設計與需求嚴重不符，模塊無法啟動或調用，程序重啟、自動退出，關聯程序間調用沖突，安全問題、穩
定性等。如：軟件中數據保存后數據庫中顯示錯誤，用戶所要求的功能缺失，程序接口錯誤，數值計算統計錯誤等
（該等級問題出現在不影響其他功能測試的情況下可以繼續該版本測試）。
3、Major（一般）：
功能沒有完全實現但是不影響使用，功能菜單存在缺陷但不會影響系統穩定性。如：操作時間長、查詢時間長、格
式錯誤、邊界條件錯誤，刪除沒有確認框、數據庫表中字段過多等(該問題實際測試中存在最多）
4、Minor（次要）：
界面、性能缺陷，建議類問題，不影響操作功能的執行，可以優化性能的方案等。如：錯別字、界面格式不規范，
頁面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語丟失，文字排列不整齊，光標位置不正確，用戶體驗感受
不好，可以優化性能的方案等（此類問題在測試初期較多，優先程度較低；在測試后期出現較少，應及時處理）

<3>BUG生命周期

● New:新發現的Bug，未經評審決定是否指派給開發人員進行修改。
● Open：確認是Bug，并且認為需要進行修改，指派給相應的開發人員。
● Fixed:開發人員進行修改后標識成修改狀態，有待測試人員的回歸測試驗證。
● Rejected：如果認為不是Bug，則拒絕修改。
● Delay:如果認為暫時不需要修改或暫時不能修改，則延后修改。
● Closed：修改狀態的Bug經測試人員的回歸測斌驗證通過，則關閉Bug。
● Reopen：如果經驗證Bug仍然存在，則需要重新打開Bug，開發人員重新修改。
無效的bug：open->closed open-rejected-closed

13.發生沖突如何處理

①檢查BUG描述是否清楚
②站在用戶的角度說服開發人員
③BUG定級要有理有據
④不斷提升自己的技能水平
⑤評審BUG

總結

以上是生活随笔為你收集整理的软件测试基础知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。