软件测试基础篇
軟件測試的定義
- 證明軟件不存在錯誤的過程
- 證明程序能夠正確運(yùn)行的過程
- 驗證軟件功能是否滿足用戶需求的過程
軟件測試的定義隨著發(fā)展而不斷擴(kuò)展，但軟件測試最基本的活動就是找bug。
不同的定義只是說明了測試的目的以及如何來衡量測試是否成功。
軟件測試的發(fā)展
測試與調(diào)試的區(qū)別
- 目的不同
測試的任務(wù)是發(fā)現(xiàn)程序中的缺陷；調(diào)試的任務(wù)是定位并且解決程序中的問題。 - 參與角色不同
測試主要是由測試人員和開發(fā)人員來執(zhí)行，黑盒測試主要由測試人員完成、單元/集成測試主要是由開發(fā)人員執(zhí)行。調(diào)試由開發(fā)人員完成。 - 執(zhí)行的階段不同
測試貫穿整個軟件開發(fā)生命周期，調(diào)試一般在開發(fā)階段。
軟件測試的目的和原則
目的：驗證軟件有或沒有問題。
原則：以客戶為中心，遵循軟件測試的規(guī)范、流程、標(biāo)準(zhǔn)和要求。
通過分析錯誤產(chǎn)生的原因、階段及錯誤發(fā)生的趨勢。測試可以：
- 幫助項目管理者了解當(dāng)前軟件開發(fā)過程中的缺陷，以便及時糾錯、改進(jìn)。
- 幫助測試人員設(shè)計出有針對性的測試方法，改善測試的效率和有效性。
- 讓開發(fā)人員知道錯誤產(chǎn)生的重災(zāi)區(qū)，加強(qiáng)自測試。
- 讓客戶清楚我們可以向他們提交一份滿意的答卷。
根據(jù)測試的目的，測試可以分為兩類：
- 為了驗證程序能正常工作的測試；
- 為了驗證程序不能正常運(yùn)行的測試
測試用例
測試過程中可能會遇到以下問題：
- 不知道是否較全面的測試了所有功能
- 測試的覆蓋率無法衡量
- 對新版本的重復(fù)測試很難實施
- 存在大量冗余測試,影響測試效率
測試用例的產(chǎn)生就是為了解決上訴問題。
測試用例（Test Case）是為了實施測試而向被測試的系統(tǒng)提供的一組集合，這組集合包含：測試環(huán)境、操作步驟、測試數(shù)據(jù)、預(yù)期結(jié)果等要素。
開發(fā)模型和測試模型
瀑布模型（Waterfall Model）
瀑布模型在軟件工程中占有重要地位，是所有其他模型的基礎(chǔ)框架。
優(yōu)點：
- 強(qiáng)調(diào)開發(fā)的階段性；
- 強(qiáng)調(diào)早期計劃及需求調(diào)查；
- 強(qiáng)調(diào)產(chǎn)品測試。
缺點：
- 依賴于早期進(jìn)行的唯一一次需求調(diào)查，不能適應(yīng)需求的變化；
- 由于是單一流程，開發(fā)中的經(jīng)驗教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過程；
- 風(fēng)險往往在后期的測試階段才顯露，因而失去及早糾正的機(jī)會。在前期階段未發(fā)現(xiàn)的錯誤會傳遞并擴(kuò)散到后面的階段，而在后面階段發(fā)現(xiàn)這些錯誤時，可能已經(jīng)很難回頭再修正，從而導(dǎo)致項目的失敗。
- 可以運(yùn)行的產(chǎn)品很遲才能被看到。這會給項目帶來很大的風(fēng)險，尤其是集成的風(fēng)險。
在瀑布模型中，測試階段處于軟件實現(xiàn)后，這意味著必須在代碼完成后有足夠的時間預(yù)留給測試活動，否則將導(dǎo)致測試不充分，從而把缺陷直接遺留給用戶。
螺旋模型（Spiral Model）
一般在軟件開發(fā)初期階段需求不是很明確時，采用漸進(jìn)式的開發(fā)模式。螺旋模型是漸進(jìn)式開發(fā)模型的代表之一。
對于那些規(guī)模龐大、復(fù)雜度高、風(fēng)險大的項目螺旋模型尤其適合。
它不允許有一段獨立的測試時間和階段，測試必須跟隨開發(fā)的迭代而迭代。
優(yōu)點：
- 強(qiáng)調(diào)嚴(yán)格的全過程風(fēng)險管理。
- 強(qiáng)調(diào)各開發(fā)階段的質(zhì)量。
- 提供機(jī)會檢討項目是否有價值繼續(xù)下去。
缺點：
- 引入非常嚴(yán)格的風(fēng)險識別、風(fēng)險分析和風(fēng)險控制，這對風(fēng)險管理的技能水平提出了很高的要求。這需要人員、資金和時間的投入。
增量、迭代
- 增量開發(fā)能顯著降低項目風(fēng)險，結(jié)合軟件持續(xù)構(gòu)建機(jī)制，構(gòu)成了當(dāng)今流行的軟件工程最佳實踐之一。
- 增量開發(fā)模型，鼓勵用戶反饋，在每個迭代過程中，促使開發(fā)小組以一種循環(huán)的、可預(yù)測的方式驅(qū)動產(chǎn)品的開發(fā)。
- 在這種開發(fā)模式下，每一次的迭代都意味著可能有需求的更改、構(gòu)建出新的可執(zhí)行軟件版本，意味著測試需要頻繁進(jìn)行，測試人員需要與開發(fā)人員更加緊密地協(xié)作。
- 增量通常和迭代混為一談，但是其實兩者是有區(qū)別的。增量是逐塊建造的概念，而迭代是反復(fù)求精的概念。
敏捷
- 個體與交互重于過程和工具
- 可用的軟件重于完備的文檔
- 客戶協(xié)作重于合同談判
- 響應(yīng)變化重于遵循計劃
- 在每對比對中，后者并非全無價值，但更看重前者。
敏捷開發(fā)有很多種方式，其中scrum是比較流行的一種
scrum
scrum里面的角色和作用
scrum由product owner(產(chǎn)品經(jīng)理)、scrum master(項目經(jīng)理)和team(研發(fā)團(tuán)隊)組成。
- product owner負(fù)責(zé)整理user story(用戶故事)，定義其商業(yè)價值，對其進(jìn)行排序，制定發(fā)布計劃，對產(chǎn)品負(fù)責(zé)。
- scrum master 負(fù)責(zé)召開各種會議，協(xié)調(diào)項目，為研發(fā)團(tuán)隊服務(wù)。研發(fā)團(tuán)隊則由不同技能的成員組成，通過緊密協(xié)同，完成每一次迭代的目標(biāo)，交付產(chǎn)品。
迭代開發(fā)與瀑布不同，scrum將產(chǎn)品的開發(fā)分解為若干個小sprint(迭代)，其周期從1周到4周不等，但不會超過4周。參與的團(tuán)隊成員一般是5到9人。每期迭代要完成的user story是固定的。每次迭代會產(chǎn)生一定的交付。
scrum的基本流程
- 產(chǎn)品負(fù)責(zé)人負(fù)責(zé)整理user story，形成product backlog。
- 發(fā)布計劃會議：product owner負(fù)責(zé)講解user story，對其進(jìn)行估算和排序，發(fā)布計劃會議的產(chǎn)出就是制定出這一期迭代要完成的story列表，sprint backlog。
- 迭代計劃會議：項目團(tuán)隊對每一個story進(jìn)行任務(wù)分解，分解的標(biāo)準(zhǔn)是完成該story的所有任務(wù)，每個任務(wù)都有明確的負(fù)責(zé)人，并完成工時的初估計。
- 每日例會：每天scrum master召集站立會議，團(tuán)隊成員回答昨天做了什么今天計劃做什么，有什么問題。
- 演示會議：迭代結(jié)束之后，召開演示會議，相關(guān)人員都受邀參加，團(tuán)隊負(fù)責(zé)向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由po整理，形成新的story。
- 回顧會議：項目團(tuán)隊對本期迭代進(jìn)行總結(jié)，發(fā)現(xiàn)不足，制定改進(jìn)計劃，下一次迭代繼續(xù)改進(jìn)，已達(dá)到持續(xù)改進(jìn)的效果。
敏捷中的測試
挑戰(zhàn)1：輕文檔
挑戰(zhàn)2：快速迭代
- 測試工作的核心內(nèi)客是沒有變的，就是不斷地找Bug，只是要調(diào)整好自己的心態(tài)，一切以敏捷的原則為主。
- 測試人員不能依賴文檔，測試用例作用減弱，更多的采用思維導(dǎo)圖、探索性測試（強(qiáng)調(diào)自由度，設(shè)計和執(zhí)行同時執(zhí)行，根據(jù)測試結(jié)果不斷調(diào)整測試計劃）、自動化測試
- 敏捷講求合作，在敏捷項目組中，測試人員應(yīng)該更主動點，多向開發(fā)人員了解需求、討論設(shè)計、一起研究Bug出現(xiàn)的原因。
軟件測試v模型
V模型目的是改進(jìn)軟件開發(fā)的效率和效果，是瀑布模型的變種。
- 明確的標(biāo)注了測試過程中存在的不同類型的測試，清楚的描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。
- 單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；驗收測試確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求
- 局限性:僅僅把測試作為在編碼之后的一個階段，未在需求階段就進(jìn)入測試
軟件測試w模型
- W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗證和確認(rèn)活動。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。
- W模型特點：測試的對象不僅是程序，需求、設(shè)計等同樣要測試，測試與開發(fā)是同步進(jìn)行的
- W模型優(yōu)點：有利于盡早地全面的發(fā)現(xiàn)問題。
- 局限性：需求、設(shè)計、編碼等活動被視為串行的；測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。無法支持敏捷開發(fā)模式。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨的困境。
配置管理和軟件測試
配置管理
配置管理( Configuration Management)是通過對在軟件生命周期不同的時間點上的軟件配置進(jìn)行標(biāo)識，并對這些被標(biāo)識的軟件配置項的更改進(jìn)行系統(tǒng)控制，從而保證軟件產(chǎn)品的完整性和可溯性。
軟件配置管理的應(yīng)用
軟件開發(fā)過程中會產(chǎn)生大量軟件產(chǎn)品（包括文檔、源代碼和數(shù)據(jù)等），這些產(chǎn)品之間存在關(guān)聯(lián)關(guān)系。同一軟件產(chǎn)品也會發(fā)生變更，從而產(chǎn)生許多版本。軟件開發(fā)小組必須清晰地知道會有哪些產(chǎn)品、這些產(chǎn)品會有哪些不同的形式和版本。開發(fā)小組必須清晰地知道如何將產(chǎn)品的變更通知給受影響的小組。如果不能有效地了解軟件產(chǎn)品及其變更，開發(fā)小組將很難組裝這些軟件產(chǎn)品，很難得到所需的軟件產(chǎn)品。
實施軟件配置管理(SCM)的好處
- 對項目中的文檔、代碼等的變化進(jìn)行有效管理。
- 方便地重現(xiàn)某個文件的歷史版本。
- 能夠重新編譯某個歷史版本，使維護(hù)工作變得容易。
- 能夠使異地多團(tuán)隊開發(fā)、并行開發(fā)成為現(xiàn)實。
- 能夠提高項目組間人員流動時的工作效率。
配置管理與軟件測試
測試人員是SCM中的參與者。如果配置管理流程不規(guī)范，或者沒有遵循一定的配置管理流程進(jìn)行軟件測試活動，也可能導(dǎo)致很嚴(yán)重的后果。
假設(shè)開發(fā)人員修正了一個Bug，然后找測試人員討論，測試人員在開發(fā)人員的機(jī)器上重新測試了一下，發(fā)現(xiàn)Bug沒再出現(xiàn)了，修復(fù)了，這時候，如果測試人員把缺陷關(guān)閉了，則可能導(dǎo)致缺陷莫名其妙地在用戶那邊又出現(xiàn)了。其實，原因可能僅僅是開發(fā)人員把這個Bug修改的代碼沒有提交的到配置管理數(shù)據(jù)庫中。但是作為測試人員有沒有責(zé)任呢？當(dāng)然有，因為測試人員也沒有按照規(guī)范的配置管理流程執(zhí)行測試，測試人員應(yīng)該從配置庫取源代碼編譯后再測試，只有看到新的構(gòu)建版本不再出現(xiàn)那個Bug，才能把缺陷庫中的Bug關(guān)閉。
軟件測試的生命周期
軟件生命周期是指從軟件產(chǎn)品的設(shè)想開始到軟件不再使用而結(jié)束的時間。
如果把軟件看成是有生命的事物，那么軟件的生命周期可以分成6個階段，即需求分析、計劃、設(shè)計、編碼、測試、運(yùn)行維護(hù)。
軟件測試的生命周期：需求分析→測試計劃→測試設(shè)計、測試開發(fā)→測試執(zhí)行→測試評估
- 需求階段
測試人員了解需求、對需求進(jìn)行分解，得出測試需求 - 計劃階段
根據(jù)需求編寫測試計劃/測試方案 - 設(shè)計階段
測試人員搭建測試用例框架，根據(jù)需求和設(shè)計編寫一部分測試用例 - 編碼階段
測試人員一般是不需要編碼的，但已經(jīng)編碼的模塊，專業(yè)的白盒測試人員可以計劃執(zhí)行單元測試，完善、細(xì)化測試用例以及調(diào)整測試計劃和方案。 - 測試階段
測試人員根據(jù)測試用例和計劃執(zhí)行測試，在執(zhí)行的過程中記錄、管理缺陷，編寫測試報告。 - 運(yùn)行維護(hù)
測試人員需要參與項目的實施工作。參與用戶使用軟件的培訓(xùn)，在試運(yùn)行項目時收集問題并及時反饋給相關(guān)負(fù)責(zé)人。
bug
凡是實現(xiàn)效果和需求不相符的都可以認(rèn)為是BUG。
BUG的后果: 用戶流失, 績效血崩。
BUG的責(zé)任: 程序猿一定是第一背鍋俠，特定情況下, 測試才會分鍋。
BUG的處理: 生產(chǎn)環(huán)境上的問題,，要第一時間回滾,，再慢慢定位。
BUG的態(tài)度: 心存敬畏,，但是不要害怕。
第一個bug ：
1945年9月的某天，在一間老式建筑里，從窗外飛進(jìn)來一只飛蛾，此時Hopper正埋頭工作在一臺名為Mark Il的計算機(jī)前，并沒有注意到這只即將造就歷史事件的飛蛾。這臺計算機(jī)使用了大量的繼電器（電子機(jī)械裝置，那時還沒有使用晶體管）。突然，Mark II死機(jī)了。Hopper試了很多次還是不能啟動，他開始用各種方法查找問題，最后定位到了某個電路板的繼電器上。Hopper觀察這個繼電器，驚奇地發(fā)現(xiàn)一只飛蛾已經(jīng)被繼電器打死。Hopper小心地用鑷子將飛蛾夾出來，用透明膠布貼到“事件記錄本”中，寫上“第一個發(fā)現(xiàn)蟲子的實例”。Hopper的事件記錄本，連同那只飛蛾，現(xiàn)在都陳列在美國歷史博物館中。
軟件錯誤：程序與規(guī)格說明之前不匹配。
準(zhǔn)確的來說：當(dāng)且僅當(dāng)規(guī)格說明是存在的并且正確，程序與規(guī)格說明之間的不匹配才是錯誤。
當(dāng)沒有需求規(guī)格說明書時，判斷標(biāo)準(zhǔn)以最終用戶為準(zhǔn)，當(dāng)程序沒有實現(xiàn)其最終用戶合理預(yù)期的功能要求時，就是軟件錯誤。
描述一個bug
一個合格的bug描述應(yīng)該包括以下幾個部分：
- 發(fā)現(xiàn)問題的版本
開發(fā)人員要知道出現(xiàn)問題的版本，才能夠獲取對應(yīng)版本的代碼來重現(xiàn)故障。版本的標(biāo)識也有利于統(tǒng)計和分析每個版本的質(zhì)量。 - 問題出現(xiàn)的環(huán)境
環(huán)境分為硬件環(huán)境和軟件環(huán)境，如果是web項目，需要描述瀏覽器版本，客戶機(jī)操作系統(tǒng)等，如果是app項目，需要描述機(jī)型、分辨率、操作系統(tǒng)版本等。詳細(xì)的環(huán)境描述有利于故障的定位。 - 錯誤重現(xiàn)的步驟
描述問題重現(xiàn)的最短步驟。 - 預(yù)期行為的描述
要讓開發(fā)人員知道怎么樣才是正確的，尤其要以用戶的角度來描述程序的行為是怎樣的。如果是依據(jù)需求提出的故障，能寫明需求的來源是最好的。 - 錯誤行為的描述
描述錯誤的現(xiàn)象。crash等可以上傳log，UI問題可以有截圖。 - 其他某
些公司會有一些其他的要求，例如故障的分類：功能故障，界面故障，兼容性故障等。有些有優(yōu)先級的分類，嚴(yán)重影響測試需要開發(fā)人員優(yōu)先修改的，可以設(shè)置優(yōu)先級為高。 - 不要把多個bug放到一起
在無法確認(rèn)是同一段代碼造成的故障時，不要將bug放在一起提交。
bug的級別
阻礙開發(fā)或測試工作的問題；造成系統(tǒng)崩潰、死機(jī)、死循環(huán)，導(dǎo)致數(shù)據(jù)庫數(shù)據(jù)丟失，與數(shù)據(jù)庫連接錯誤，主要功能喪失，基本模塊缺失等問題。如：代碼錯誤、死循環(huán)、數(shù)據(jù)庫發(fā)生死鎖、重要的一級菜單功能不能使用等（該問題在測試中較少出現(xiàn)，一旦出現(xiàn)應(yīng)立即中止當(dāng)前版本測試）。
系統(tǒng)主要功能部分喪失、數(shù)據(jù)庫保存調(diào)用錯誤、用戶數(shù)據(jù)丟失，一級功能菜單不能使用但是不影響其他功能的測試。功能設(shè)計與需求嚴(yán)重不符，模塊無法啟動或調(diào)用，程序重啟、自動退出，關(guān)聯(lián)程序間調(diào)用沖突，安全問題、穩(wěn)定性等。如：軟件中數(shù)據(jù)保存后數(shù)據(jù)庫中顯示錯誤，用戶所要求的功能缺失，程序接口錯誤，數(shù)值計算統(tǒng)計錯誤等（該等級問題出現(xiàn)在不影響其他功能測試的情況下可以繼續(xù)該版本測試）。
功能沒有完全實現(xiàn)但是不影響使用，功能菜單存在缺陷但不會影響系統(tǒng)穩(wěn)定性。如：操作時間長、查詢時間長、格式錯誤、邊界條件錯誤，刪除沒有確認(rèn)框、數(shù)據(jù)庫表中字段過多等(該問題實際測試中存在最多）
界面、性能缺陷，建議類問題，不影響操作功能的執(zhí)行，可以優(yōu)化性能的方案等。如：錯別字、界面格式不規(guī)范，頁面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語丟失，文字排列不整齊，光標(biāo)位置不正確，用戶體驗感受不好，可以優(yōu)化性能的方案等（此類問題在測試初期較多，優(yōu)先程度較低；在測試后期出現(xiàn)較少，應(yīng)及時處理。
bug的生命周期
測試人員應(yīng)該跟蹤一個Bug的整個生命周期，從Open到Closed的所有狀態(tài)。
- New:新發(fā)現(xiàn)的Bug，未經(jīng)評審決定是否指派給開發(fā)人員進(jìn)行修改。
- Open：確認(rèn)是Bug，并且認(rèn)為需要進(jìn)行修改，指派給相應(yīng)的開發(fā)人員。
- Fixed:開發(fā)人員進(jìn)行修改后標(biāo)識成修改狀態(tài)，有待測試人員的回歸測試驗證
- Rejected：如果認(rèn)為不是Bug，則拒絕修改。
- Delay:如果認(rèn)為暫時不需要修改或暫時不能修改，則延后修改。
- Closed：修改狀態(tài)的Bug經(jīng)測試人員的回歸測斌驗證通過，則關(guān)閉Bug。
- Reopen：如果經(jīng)驗證Bug仍然存在，則需要重新打開Bug，開發(fā)人員重新修改。
- 無效的bug：open->closed open-rejected-closed
Bug的跟蹤以及狀態(tài)變應(yīng)該遵循一些基本原則：測試人員對每一個缺陷的修改必須重新取一個包含更改后的代碼的新版本進(jìn)行回歸測試，確保相同的問題不再出現(xiàn)，才能關(guān)閉缺陷。對于拒絕修改和延遲修改的Bug，需要經(jīng)過包含測試人員代表和開發(fā)人員代表、用戶方面的代表（或代表用戶角度的人）的評審。
總結(jié)
- 上一篇： 2022 年海峡两岸无线科学与技术会议
- 下一篇： 解决vue+php跨域问题