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