软件测试基础知识
目錄
- 1.什么是軟件測(cè)試
- 2.軟件測(cè)試與軟件研發(fā)的區(qū)別
- 3.優(yōu)秀的測(cè)試人員所具體的素質(zhì)（為什么要做軟件測(cè)試）
- 4.軟件測(cè)試目的和原則
- 5.什么是需求
- 6.什么是BUG
- 7.測(cè)試用例的概念
- 8.軟件的生命周期
- 9.軟件開(kāi)發(fā)模型
- 10.軟件測(cè)試模型
- 11.軟件測(cè)試的生命周期（流程）
- 12.如何描述一個(gè)BUG
- 13.發(fā)生沖突如何處理
1.什么是軟件測(cè)試
軟件測(cè)試就是為了驗(yàn)證軟件是否符合用戶的需求
2.軟件測(cè)試與軟件研發(fā)的區(qū)別
1.測(cè)試與調(diào)試的區(qū)別
①目的不同
測(cè)試的任務(wù)是發(fā)現(xiàn)程序中的缺陷；
調(diào)試的任務(wù)是定位并解決程序中的問(wèn)題。
②參與角色不同
測(cè)試主要是由測(cè)試人員和開(kāi)發(fā)人員來(lái)執(zhí)行，黑盒測(cè)試主要由測(cè)試人員完成、單元/集成測(cè)試主要是由開(kāi)發(fā)人員執(zhí)行。調(diào)試由開(kāi)發(fā)人員完成。
③執(zhí)行的階段不同
測(cè)試貫穿整個(gè)軟件開(kāi)發(fā)生命周期，調(diào)試一般在開(kāi)發(fā)階段。
軟件測(cè)試與研發(fā)的區(qū)別
①難易程度 ：開(kāi)發(fā)廣度小，專業(yè)度高。測(cè)試廣度大，專業(yè)度低
②薪水 ：中小企業(yè)總體比研發(fā)低，自動(dòng)化等專業(yè)測(cè)試領(lǐng)域和研發(fā)基本無(wú)差距。大廠研發(fā)測(cè)試基本無(wú)差別
③發(fā)展前景 ：自動(dòng)化測(cè)試、安全測(cè)試等領(lǐng)域發(fā)展前景和研發(fā)基本一致。
④繁忙程度： 一般比研發(fā)輕松，但敏捷模式下差距不大，產(chǎn)品發(fā)布前壓力比較大
⑤技能要求 ：測(cè)試要求更廣泛：業(yè)務(wù)能力，設(shè)計(jì)和架構(gòu)分析能力，測(cè)試手段和工具使用，用戶模型分析和理 解，編程能力
3.優(yōu)秀的測(cè)試人員所具體的素質(zhì)（為什么要做軟件測(cè)試）
4.軟件測(cè)試目的和原則
目的：驗(yàn)證軟件有沒(méi)有問(wèn)題
原則：以客戶為中心，遵循軟件測(cè)試的規(guī)范，流程，標(biāo)準(zhǔn)和要求
5.什么是需求
滿足用戶的期望或規(guī)定的文檔（合同、規(guī)范、標(biāo)準(zhǔn)）所需要的的條件和權(quán)限
包括用戶需求和軟件需求
●軟件需求從用戶需求轉(zhuǎn)化而來(lái)
●用戶需求轉(zhuǎn)換為軟件需求的核心是溝通
6.什么是BUG
1.正式文檔存在且合理，軟件的功能和文檔不相符，叫做軟件缺陷
2.不存在文檔時(shí)，用戶的需求存在且合理，程序沒(méi)有滿足用戶的需求稱之為軟件缺陷（BUG）
7.測(cè)試用例的概念
向被測(cè)試系統(tǒng)發(fā)起的一組操作集合，包含測(cè)試環(huán)境、測(cè)試數(shù)據(jù)，操作步驟，預(yù)期結(jié)果，標(biāo)題、功能米快、前提條件、重要性。
8.軟件的生命周期
需求分析，計(jì)劃、設(shè)計(jì)、編碼、測(cè)試、運(yùn)行維護(hù)
9.軟件開(kāi)發(fā)模型
1.瀑布模型
優(yōu)點(diǎn)： 強(qiáng)調(diào)開(kāi)發(fā)的階段性； 強(qiáng)調(diào)早期計(jì)劃及需求調(diào)查； 強(qiáng)調(diào)產(chǎn)品測(cè)試。
缺點(diǎn)： 前期的缺陷到后期才有可能比發(fā)現(xiàn)，不能適應(yīng)需求的變化
適用場(chǎng)景：需求比較穩(wěn)定的項(xiàng)目
2.螺旋模型
優(yōu)點(diǎn)：強(qiáng)調(diào)風(fēng)險(xiǎn)的把握
缺點(diǎn)：風(fēng)險(xiǎn)各項(xiàng)要求較高，對(duì)人員，資金，時(shí)間的投入較大
適用場(chǎng)景：前期需求不明顯，風(fēng)險(xiǎn)大，項(xiàng)目龐大的需求
3.增量模型，迭代模型
場(chǎng)景：一個(gè)系統(tǒng)，開(kāi)發(fā)A B C D四個(gè)業(yè)務(wù)模塊，兩周時(shí)間
增量模型：第一周：完成A B模塊； 第二周：完成C D模塊
迭代模型：第一周：完成四個(gè)模塊的基礎(chǔ)功能；
第二周：補(bǔ)充完成復(fù)雜的業(yè)務(wù)功能
4.敏捷開(kāi)發(fā)模型
①價(jià)值觀
個(gè)體與交互重于過(guò)程和工具
可用的軟件重于完備的文檔
客戶協(xié)作重于合同談判
響應(yīng)變化重于遵循計(jì)劃
②scrum（敏捷開(kāi)發(fā)方法）
scrum將產(chǎn)品的開(kāi)發(fā)分解為若干個(gè)小sprint(迭代)，其周期從1周到4周不等，但不會(huì)超過(guò)4周。參與的團(tuán)隊(duì)成員一般是5到9人。每期迭代要完成的user story是固定的。每次迭代會(huì)產(chǎn)生一定的交付
③角色
PO（產(chǎn)品經(jīng)理）：product owner負(fù)責(zé)整理user story(用戶故事)，定義其商業(yè)價(jià)值，對(duì)其進(jìn)行排序，制定發(fā)布計(jì)劃，對(duì)產(chǎn)品負(fù)責(zé)。
SM（項(xiàng)目經(jīng)理）：scrum master負(fù)責(zé)召開(kāi)各種會(huì)議，協(xié)調(diào)項(xiàng)目，為研發(fā)團(tuán)隊(duì)服務(wù)。
ST（研發(fā)團(tuán)隊(duì)) :scrum Team由不同技能的成員組成，通過(guò)緊密協(xié)同，完成每一次迭代的目標(biāo)，交付產(chǎn)品。
④流程
<1> 產(chǎn)品負(fù)責(zé)人負(fù)責(zé)整理user story，形成左側(cè)的product backlog。
<2>發(fā)布計(jì)劃會(huì)議：product owner負(fù)責(zé)講解userstory，對(duì)其進(jìn)行估算和排序，發(fā)布計(jì)劃會(huì)議的產(chǎn)出就是制定出 這一期迭代要完成的story列表，sprint backlog。
<3>迭代計(jì)劃會(huì)議：項(xiàng)目團(tuán)隊(duì)對(duì)每一個(gè)story進(jìn)行任務(wù)分解，分解的標(biāo)準(zhǔn)是完成該story的所有任務(wù)，每個(gè)任務(wù)都有 明確的負(fù)責(zé)人，并完成工時(shí)的初估計(jì)。
<4>每日例會(huì)：每天scrum master召集站立會(huì)議，團(tuán)隊(duì)成員回答昨天做了什么今天計(jì)劃做什么，有什么問(wèn)題。
<5> 演示會(huì)議：迭代結(jié)束之后，召開(kāi)演示會(huì)議，相關(guān)人員都受邀參加，團(tuán)隊(duì)負(fù)責(zé)向大家展示本次迭代取得的成果。期間大家的反饋記錄下來(lái)，由po整理，形成新的story。
<6>回顧會(huì)議：項(xiàng)目團(tuán)隊(duì)對(duì)本期迭代進(jìn)行總結(jié)，發(fā)現(xiàn)不足，制定改進(jìn)計(jì)劃，下一次迭代繼續(xù)改進(jìn)，已達(dá)到持續(xù)改 進(jìn)的效果
⑤敏捷中的測(cè)試
特點(diǎn)：輕文檔，輕流程、重目標(biāo)，重產(chǎn)出，擁抱變化
削弱測(cè)試用力的作用，進(jìn)行探索性測(cè)試（思維導(dǎo)圖）
10.軟件測(cè)試模型
①V模型
優(yōu)點(diǎn)：后期測(cè)試的每一個(gè)階段對(duì)應(yīng)前期開(kāi)發(fā)的階段，有明確的依據(jù)
缺點(diǎn)：測(cè)試在編碼之后，導(dǎo)致缺陷的風(fēng)險(xiǎn)在后期才會(huì)被發(fā)現(xiàn)
②W模型
特點(diǎn);測(cè)試的對(duì)象不僅僅是程序，還有需求設(shè)計(jì)等
優(yōu)點(diǎn)：有利于項(xiàng)目前期的問(wèn)題及時(shí)發(fā)現(xiàn)，避免造成后期開(kāi)發(fā)完成才發(fā)現(xiàn)前期的問(wèn)題
缺點(diǎn)：階段性較強(qiáng)，不適用于敏捷開(kāi)發(fā)
11.軟件測(cè)試的生命周期（流程）
需求分析→測(cè)試計(jì)劃→ 測(cè)試設(shè)計(jì)、測(cè)試開(kāi)發(fā)→ 測(cè)試執(zhí)行→ 測(cè)試評(píng)估
12.如何描述一個(gè)BUG
<1>版本號(hào)、測(cè)試環(huán)境、操作步驟、預(yù)期結(jié)果、實(shí)際結(jié)果
<2>BUG級(jí)別：崩潰、嚴(yán)重、一般、次要
1、Blocker（崩潰）：
阻礙開(kāi)發(fā)或測(cè)試工作的問(wèn)題；造成系統(tǒng)崩潰、死機(jī)、死循環(huán)，導(dǎo)致數(shù)據(jù)庫(kù)數(shù)據(jù)丟失，與數(shù)據(jù)庫(kù)連接錯(cuò)誤，主要功能
喪失，基本模塊缺失等問(wèn)題。如：代碼錯(cuò)誤、死循環(huán)、數(shù)據(jù)庫(kù)發(fā)生死鎖、重要的一級(jí)菜單功能不能使用等（該問(wèn)題
在測(cè)試中較少出現(xiàn)，一旦出現(xiàn)應(yīng)立即中止當(dāng)前版本測(cè)試）。
2、Critical（嚴(yán)重）：
系統(tǒng)主要功能部分喪失、數(shù)據(jù)庫(kù)保存調(diào)用錯(cuò)誤、用戶數(shù)據(jù)丟失，一級(jí)功能菜單不能使用但是不影響其他功能的測(cè)
試。功能設(shè)計(jì)與需求嚴(yán)重不符，模塊無(wú)法啟動(dòng)或調(diào)用，程序重啟、自動(dòng)退出，關(guān)聯(lián)程序間調(diào)用沖突，安全問(wèn)題、穩(wěn)
定性等。如：軟件中數(shù)據(jù)保存后數(shù)據(jù)庫(kù)中顯示錯(cuò)誤，用戶所要求的功能缺失，程序接口錯(cuò)誤，數(shù)值計(jì)算統(tǒng)計(jì)錯(cuò)誤等
（該等級(jí)問(wèn)題出現(xiàn)在不影響其他功能測(cè)試的情況下可以繼續(xù)該版本測(cè)試）。
3、Major（一般）：
功能沒(méi)有完全實(shí)現(xiàn)但是不影響使用，功能菜單存在缺陷但不會(huì)影響系統(tǒng)穩(wěn)定性。如：操作時(shí)間長(zhǎng)、查詢時(shí)間長(zhǎng)、格
式錯(cuò)誤、邊界條件錯(cuò)誤，刪除沒(méi)有確認(rèn)框、數(shù)據(jù)庫(kù)表中字段過(guò)多等(該問(wèn)題實(shí)際測(cè)試中存在最多）
4、Minor（次要）：
界面、性能缺陷，建議類問(wèn)題，不影響操作功能的執(zhí)行，可以優(yōu)化性能的方案等。如：錯(cuò)別字、界面格式不規(guī)范，
頁(yè)面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語(yǔ)丟失，文字排列不整齊，光標(biāo)位置不正確，用戶體驗(yàn)感受
不好，可以優(yōu)化性能的方案等（此類問(wèn)題在測(cè)試初期較多，優(yōu)先程度較低；在測(cè)試后期出現(xiàn)較少，應(yīng)及時(shí)處理）
<3>BUG生命周期
● New:新發(fā)現(xiàn)的Bug，未經(jīng)評(píng)審決定是否指派給開(kāi)發(fā)人員進(jìn)行修改。
● Open：確認(rèn)是Bug，并且認(rèn)為需要進(jìn)行修改，指派給相應(yīng)的開(kāi)發(fā)人員。
● Fixed:開(kāi)發(fā)人員進(jìn)行修改后標(biāo)識(shí)成修改狀態(tài)，有待測(cè)試人員的回歸測(cè)試驗(yàn)證。
● Rejected：如果認(rèn)為不是Bug，則拒絕修改。
● Delay:如果認(rèn)為暫時(shí)不需要修改或暫時(shí)不能修改，則延后修改。
● Closed：修改狀態(tài)的Bug經(jīng)測(cè)試人員的回歸測(cè)斌驗(yàn)證通過(guò)，則關(guān)閉Bug。
● Reopen：如果經(jīng)驗(yàn)證Bug仍然存在，則需要重新打開(kāi)Bug，開(kāi)發(fā)人員重新修改。
無(wú)效的bug：open->closed open-rejected-closed
13.發(fā)生沖突如何處理
①檢查BUG描述是否清楚
②站在用戶的角度說(shuō)服開(kāi)發(fā)人員
③BUG定級(jí)要有理有據(jù)
④不斷提升自己的技能水平
⑤評(píng)審BUG
總結(jié)
- 上一篇： 一篇文章带你搞懂前端面试技巧及进阶路线
- 下一篇： 随时随地能写代码， vscode.dev