軟件測試基礎

一惠勒、 軟件缺陷的概述

1赚抡、什么是軟件缺陷

軟件缺陷就是軟件產(chǎn)品中所存在的問題，最終表現(xiàn)為用戶所需要的功能沒有完全實現(xiàn)纠屋，不能滿足或不能全部滿足用戶的需求涂臣。

IEEE(電氣電子工程師協(xié)會)對軟件缺陷有一個**標準的定義**：

從**產(chǎn)品內(nèi)部**看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤售担、誤差等各種問題赁遗。

從**外部**看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背族铆。

2岩四、軟件缺陷的類型

（1）軟件未實現(xiàn)產(chǎn)品說明書要求的功能。

（2）軟件出現(xiàn)了產(chǎn)品說明書不應該出現(xiàn)的錯誤哥攘。

（3）軟件實現(xiàn)了產(chǎn)品說明書未提到的功能剖煌。

（4）軟件未實現(xiàn)產(chǎn)品說明書雖未明確提及但應該實現(xiàn)的功能。

（5）軟件難以理解逝淹、不易使用耕姊、運行緩慢——從測試員的角度看——最終用戶會認為不好。

3栅葡、軟件缺陷的案例

（1）千年蟲問題（產(chǎn)生約1974年）

（2）愛國者導彈防御系統(tǒng)（1991年）

（3）英特爾奔騰浮點除法缺陷（1994年）

（4）“沖擊波”病毒（2003年）

（5）諾基亞手機平臺缺陷（2008年）

4茉兰、軟件缺陷的產(chǎn)生原因

• 需求不明確
• 軟件結構復雜
• 開發(fā)人員水平有限
• 項目期限短
• 使用新技術
• 其他原因

5、軟件缺陷的分類

軟件缺陷的分類

6欣簇、軟件缺陷的處理流程

每個公司的軟件缺陷處理流程不盡相同规脸，但是它們遵循的最基本流程是一樣的，都要經(jīng)過提交熊咽、分配莫鸭、確認、處理横殴、復測被因、關閉等環(huán)節(jié)。

軟件缺陷的處理流程

• 提交：測試人員發(fā)現(xiàn)缺陷之后，將缺陷提交給測試組長氏身。
• 分配：測試組長接收到測試組員提交的缺陷之后，將其移交給開發(fā)人員惑畴。
• 確認：開發(fā)人員接收到移交的缺陷之后蛋欣，會與團隊甚至測試人員一起商議，確定該缺陷是否是一個缺陷如贷。
• 拒絕：如果經(jīng)過商議之后陷虎，缺陷不是一個真正的缺陷則拒絕處理，關閉缺陷杠袱。如果經(jīng)過商議之后尚猿，確定其是一個真正的缺陷，則可以根據(jù)缺陷的嚴重程度或優(yōu)先級等立即處理或延期處理楣富。
• 復測：開發(fā)人員修改好缺陷之后凿掂，測試人員重新進行測試（復測），檢測缺陷是否確實已經(jīng)修改纹蝴。如果未被正確修改庄萎，則重新提交缺陷。
• 關閉：測試人員重新測試之后塘安，如果缺陷已經(jīng)被正確修改糠涛，則將缺陷關閉，整個缺陷處理完成兼犯。

7忍捡、多學一招：缺陷報告（由測試人員完成）

測試人員在提交軟件測試時都會按照公司規(guī)定的模板（Word、Excel切黔、缺陷管理軟件等）將缺陷的詳細情況記錄下來生成缺陷報告砸脊，每個公司的缺陷報告模板并不相同，但一般都會包括缺陷的編號绕娘、類型脓规、嚴重程度、優(yōu)先級险领、測試環(huán)境等侨舆，有時還會有測試人員的建議。

8绢陌、常見軟件缺陷管理工具

（1）Bugzilla

• Bugzilla是Mozilla公司提供的一款免費的軟件缺陷管理工具挨下。
• Bugzilla能夠建立一個完整的缺陷跟蹤體系，包括缺陷跟蹤脐湾、記錄臭笆、缺陷報告、處理解決情況等。
• 使用Bugzilla管理軟件缺陷時愁铺，測試人員可以在Bugzilla上提交缺陷報告鹰霍，Bugzilla會將缺陷轉給相應的開發(fā)者，開發(fā)者可以使用Bugzilla做一個工作表茵乱，標明要做的事情的優(yōu)先級茂洒、時間安排和跟蹤記錄。

（2）禪道

• 禪道是一款優(yōu)秀的國產(chǎn)項目管理軟件瓶竭，它集產(chǎn)品管理督勺、項目管理、質量管理斤贰、缺陷管理智哀、文檔管理、組織管理和事務管理于一體荧恍，是一款功能完備的項目管理軟件瓷叫，完美地覆蓋了項目管理的核心流程。
• 禪道分為專業(yè)和開源兩個版本块饺，專業(yè)版是收費軟件赞辩，開源版是免費軟件，<u>對于日常的項目管理授艰，開源版本已經(jīng)足夠使用</u>辨嗽。

（3）JIRA

• JIRA是Atlassian公司開發(fā)的項目與實務跟蹤工具，被廣泛用于缺陷跟蹤淮腾、客戶實務糟需、需求收集、流程審批谷朝、任務跟蹤洲押、項目跟蹤和敏捷管理等工作領域。JIRA配置靈活圆凰、功能全面杈帐、部署簡單、擴展豐富专钉、易用性好挑童，是目前比較流行的基于Java架構的管理工具。
• JIRA軟件有兩個認可度很高的特色：第一個是Atlassian公司對該開源項目實行免費提供<u>缺陷跟蹤服務</u>跃须；第二個是用戶在購買JIRA軟件同時將源代碼也購置進來站叼，方便做二次開發(fā)。

9菇民、修復軟件缺陷的成本

軟件開發(fā)過程是使用軟件工程的方法尽楔，在整個過程中投储，都有可能出現(xiàn)各種各樣的軟件缺陷。隨著開發(fā)時間的推移阔馋，軟件缺陷修復成本呈倍數(shù)的增長玛荞。假如早在進行分析時發(fā)現(xiàn)相關功能缺失，立即補上就可以了呕寝，可以說付出的代價小得幾乎忽略不計冲泥。如果在發(fā)布時發(fā)現(xiàn)缺失某個功能，那么此時加上一個功能壁涎，相當于重新開發(fā)一樣，這時的修補費用可以說高了許多志秃。因此<u>要盡早進行測試</u>怔球。

二、 軟件的概述

1浮还、軟件生命周期

先來了解軟件生命周期的全過程：

軟件生命周期的全過程

下面對軟件生命周期各個過程進行逐一解析：

（1）問題定義：由軟件開發(fā)方與需求方共同討論竟坛，主要確定軟件的開發(fā)目標及其可行性。

（2）需求分析：對軟件需求進行更深入的分析钧舌，劃分出軟件需要實現(xiàn)的功能模塊担汤，并制作成文檔。（需求分析說明書）

（3）軟件設計：在需求分析結果的基礎上洼冻，對整個軟件系統(tǒng)進行設計崭歧，包括系統(tǒng)框架設計、數(shù)據(jù)庫設計等撞牢。（概要設計率碾、詳細設計）

（4）軟件開發(fā)：在軟件設計的基礎上，選擇一種編程語言進行開發(fā)屋彪。

（5）軟件測試：軟件開發(fā)完成后對軟件進行測試所宰，以查找軟件設計與軟件開發(fā)過程中存在的問題并加以修正。

（6）軟件維護：軟件投入使用之后畜挥，可能無法滿足用戶的使用需求仔粥，此時就需要對軟件進行維護升級以延續(xù)軟件的使用壽命。軟件維護是軟件生命周期中持續(xù)時間最長的階段蟹但。

2躯泰、開發(fā)過程中的角色

（1）高級經(jīng)理：參與項目過程中各個關鍵環(huán)節(jié)的活動，關注產(chǎn)品開發(fā)的進度矮湘，對風險控制斟冕、資源提供做出決策。

（2）產(chǎn)品經(jīng)理（項目經(jīng)理）：作為客戶方和公司內(nèi)部交流的紐帶缅阳，對項目過程進行監(jiān)控磕蛇，對項目的進度景描、質量負責。

（3）開發(fā)經(jīng)理：是具體開發(fā)過程的領導者秀撇，必需由熟悉業(yè)務和開發(fā)技術的專家擔任超棺；職責是界定需求，確定適當?shù)募夹g架構和體系呵燕，保證軟件產(chǎn)品按照設計的標準開發(fā)棠绘。

（4）設計師：軟件藍圖設計者，可以分需求分析師再扭、架構設計師氧苍、業(yè)務設計師三種》悍叮基本活動包括：需求分析让虐、架構設計和功能設計，按照規(guī)范編寫相應的文檔罢荡。

（5）測試經(jīng)理：測試活動的領導者赡突，是公司內(nèi)部認定的產(chǎn)品質量責任人。責任是計劃和組織測試人員對目標產(chǎn)品進行測試区赵，發(fā)現(xiàn)bug惭缰、跟蹤bug直到解決bug；計劃和組織用戶培訓工作笼才。

（6）開發(fā)人員：根據(jù)設計師的設計成果進行具體編碼工作漱受，對自己的代碼進行基本的單元測試。

（7）測試人員：根據(jù)測試經(jīng)理的計劃和測試總體方案對目標產(chǎn)品進行測試骡送，編寫測試用例和測試代碼拜效，發(fā)現(xiàn)和跟蹤bug；編寫用戶手冊各谚；進行用戶培訓和教育紧憾。

（8）項目實施人員：針對工程性質的項目必需的人員配置，負責軟件系統(tǒng)安裝配置昌渤、系統(tǒng)割接赴穗、運行期間的維護工作。

3膀息、軟件開發(fā)模型

（1）瀑布模型

• 優(yōu)點：檢查點清晰般眉，分工明確，有利于大型軟件軟件開發(fā)人員的組織管理及工具的使用與研究潜支，可以提高開發(fā)的效率甸赃。
• 缺點：嚴格按照線性執(zhí)行，增加了開發(fā)風險冗酿；要求必須有產(chǎn)出結果埠对，增加了開發(fā)工作量络断。那么，對于現(xiàn)代軟件项玛，各階段之間的關系很少是線性貌笨，瀑布模型已經(jīng)不適合現(xiàn)代軟件開發(fā)。

瀑布模型

（2）快速原型模型

• 優(yōu)點：克服了需求不明確帶來的風險襟沮，適用于不能預先確定需求的軟件項目锥惋。
• 缺點：原型設計較難；不利于開發(fā)人員對產(chǎn)品的擴展开伏。

快速原型模型

（3）迭代模型

• 優(yōu)點：適應客戶需求變更膀跌；降低了開發(fā)成本和風險。
• 缺點：增加了集成失敗風險固灵；容易退化為“邊做邊改”模式淹父，失去對整個項目的控制。

迭代模型

（4）螺旋模型

• 優(yōu)點：強調(diào)了風險分析怎虫，有助于將軟件質量融入開發(fā)中；小分段構建大型軟件困介，易于計算成本大审；客戶參與，保證項目可控性座哩。
• 缺點：構建過程太過繁瑣徒扶，不適合小型項目。

螺旋模型

（5）敏捷模型

• 定義：敏捷模型以用戶的需求進化為核心根穷，采用迭代姜骡、循序漸進的方法進行軟件開發(fā)遵蚜。

• 特點：

  • 項目被拆分成多個子項目局装，迭代完成副渴，每個迭代都要經(jīng)過測試播赁。
  • 快速響應需求變更彤叉，在修改過程中棚饵，軟件一直處于可用狀態(tài)辆苔。
  • 不斷對產(chǎn)品進行細微楼镐、漸進式地改進喷橙，每次改進一小部分啥么，如果可行再逐步擴大改進范圍。
  • 開發(fā)未動贰逾，測試先行悬荣。
  • 注重“人”的作用。

• 優(yōu)點：及時響應客戶需求變更疙剑，不斷適應新的趨勢氯迂。

• 缺點：管理相對混亂践叠，不適合大型項目。

PS 以上內(nèi)容是對軟件開發(fā)模型的簡要概括囚戚，如需了解軟件開發(fā)模型的詳細內(nèi)容酵熙，請前往軟件工程和過程模型

4、軟件質量概述

（1）定義：軟件質量是指軟件產(chǎn)品滿足基本需求及隱式需求的程度驰坊。軟件產(chǎn)品滿足基本需求是指其能滿足軟件開發(fā)時所規(guī)定需求的特性匾二；其次是軟件產(chǎn)品滿足隱式需求的程度。

（2）軟件質量模型：ISO/IEC 9126:1991質量模型是最通用的一個評價軟件質量的國際標準拳芙，建立在MCCall和Boehm模型基礎之上察藐，主要描述了內(nèi)部質量、外部質量和使用質量舟扎。由6個特性和27個子特性組成分飞。

軟件質量模型圖如下：

軟件質量模型

對內(nèi)部質量、外部質量和使用質量進行逐一解析：

①內(nèi)部質量：針對內(nèi)部質量需求被測量和評價的質量睹限，可維護性譬猫、靈活性、可移植性羡疗、可重用性染服、可讀性、可測試性叨恨、可理解性柳刮。

②外部質量：使用外部度量在模擬環(huán)境中，用模擬數(shù)據(jù)測試時痒钝，所被測量和評價的質量秉颗，即在預定的系統(tǒng)環(huán)境中運行時可能達到的質量水平。正確性送矩、可用性蚕甥、效率、可靠性栋荸、完整性梢灭、適應性、精確性蒸其、堅固性敏释。

③使用質量：在規(guī)定的使用環(huán)境下，軟件產(chǎn)品使特定用戶在達到規(guī)定目標方面的能力摸袁。有效性钥顽、生產(chǎn)率、安全性靠汁、滿意程度等蜂大。

三闽铐、 軟件測試的概述

1、軟件測試的發(fā)展

軟件測試的發(fā)展也經(jīng)歷了一個漫長的過程奶浦，其發(fā)展過程可用下圖表示：

軟件測試的發(fā)展

2兄墅、軟件測試的定義

（1）1983年，IEEE給軟件測試的定義：

使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過程澳叉，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別隙咸。

（2）1990年，IEEE再次給出軟件測試的定義：

①在特定的條件下運行系統(tǒng)或構件成洗，觀察或記錄結果五督，對系統(tǒng)的某個方面做出評價；

②分析某個軟件項以發(fā)現(xiàn)現(xiàn)存的和要求的條件之差別并評價此軟件項的特性瓶殃。

總結：

• 以上的定義都有一定的片面性充包。不能只對系統(tǒng)程序進行測試，找出系統(tǒng)程序中的錯誤遥椿，而對分析基矮、設計等過程發(fā)生的錯誤視而不見。
• 軟件產(chǎn)品由文檔冠场、數(shù)據(jù)和程序組成家浇，那么軟件測試就是對<u>軟件開發(fā)過程中形成的文檔、數(shù)據(jù)以及程序進行相關的測試</u>慈鸠。

3、軟件測試的目的

• 對于軟件開發(fā)來說灌具，軟件測試通過找到的問題缺陷幫助開發(fā)人員找到開發(fā)過程中存在的問題青团，包括軟件開發(fā)的模式、工具咖楣、技術等方面存在的問題與不足督笆，預防下次缺陷的產(chǎn)生。
• 對于軟件測試來說诱贿，使用最少的人力娃肿、物力、時間等找到軟件中隱藏的缺陷珠十，保證軟件的質量料扰，也為以后軟件測試積累豐富的經(jīng)驗。
• 對于客戶需求來說焙蹭，軟件測試能夠檢驗軟件是否符合客戶需求晒杈，對軟件質量進行評估和度量，為客戶評審軟件提供有力的依據(jù)孔厉。

4拯钻、軟件測試的分類

（1）按照測試階段分類

• 單元測試：驗證軟件單元是否符合軟件需求與設計帖努，開發(fā)人員自測。
• 集成測試：將已經(jīng)測試過的軟件單元組合在一起測試它們之間的接口粪般，用于驗證軟件是否滿足設計需求拼余。
• 系統(tǒng)測試：將經(jīng)過測試的軟件在實際環(huán)境中運行，并與其他系統(tǒng)的成分（如數(shù)據(jù)庫亩歹、硬件和操作人員等）組合在一起進行測試匙监。
• 驗收測試：主要是對軟件產(chǎn)品說明進行驗證，逐行逐字的按照說明書的描述對軟件產(chǎn)品進行測試捆憎，確保其符合客戶的各項要求舅柜。

（2）按照測試技術分類

• 黑盒測試：把軟件（程序）當作一個有輸入與輸出的黑匣子，它把程序當作一個輸入域到輸出域的映射躲惰，只要輸入的數(shù)據(jù)能輸出預期的結果即可致份，不必關心程序內(nèi)部是怎么樣實現(xiàn)的。

黑盒測試

• 白盒測試：測試人員了解軟件程序的邏輯結構础拨、路徑與運行過程氮块，在測試時，按照程序的執(zhí)行路徑得出結果诡宗。白盒測試就是把軟件（程序）當作一個透明的盒子滔蝉，測試人員清楚的知道從輸入到輸出的每一步過程。

白盒測試

總結：

相對于黑盒測試來說塔沃，白盒測試對測試人員的要求會更高一點蝠引，它要求測試人員具有一定的編程能力，而且要熟悉各種腳本語言蛀柴。但是在軟件公司里螃概，黑盒測試與白盒測試并不是界限分明的，在測試一款軟件時往往是黑盒測試與白盒測試相結合對軟件進行完整全面的測試鸽疾。

（3）按照軟件質量特性分類

• 功能測試：測試軟件的功能<u>是否滿足客戶的需求</u>吊洼，包括準確性、易用性制肮、適合性冒窍、互操作性等。
• 性能測試：測試軟件的性能<u>是否滿足客戶的需求</u>豺鼻，性能測試包括負載測試综液、壓力測試、兼容性測試儒飒、可移植性測試和健壯性測試等意乓。

（4）按照自動化程度分類

• 手工測試：測試人員一條一條的執(zhí)行代碼完成測試工作。費時費力且很難保證測試效果。
• 自動化測試：借助腳本届良、自動化測試工具等完成相應的測試工作笆凌，它也需要人工的參與，但是它可以將要執(zhí)行的測試代碼或流程寫成腳本士葫，執(zhí)行腳本完成整個測試工作乞而。

（5）按照測試項目分類

• 界面類測試：驗證軟件界面<u>是否符合客戶需求</u>。
• 安全性測試：軟件遭受到沒有授權的內(nèi)部或外部用戶的攻擊或惡意破壞時如何進行處理慢显，是否能保證軟件與數(shù)據(jù)的安全爪模。
• 文檔測試：以需求分析、軟件設計荚藻、用戶手冊屋灌、安裝手冊為主，主要驗證文檔說明與實際軟件之間是否存在差異应狱。

（6）其他分類

• α測試：軟件上線之前進行的版本測試共郭。由開發(fā)人員和測試人員或者用戶協(xié)助進行測試。測試人員記錄使用過程中出現(xiàn)的錯誤與問題疾呻，整個測試過程是可控的除嘹。
• β測試：軟件上線之后進行的版本測試。由用戶在使用過程中發(fā)現(xiàn)錯誤與問題并進行記錄岸蜗，然后反饋給開發(fā)人員進行修復尉咕。
• 回歸測試：對修改后的程序重新進行測試，確認原有的缺陷已經(jīng)消除并且沒有引入新的缺陷璃岳，這個重新測試的過程就叫作回歸測試年缎。
• 隨機測試：沒有測試用例、檢查列表铃慷、腳本或指令的測試单芜，它主要是根據(jù)測試人員的經(jīng)驗對軟件進行功能和性能抽查。

四枚冗、 軟件測試與軟件開發(fā)的關系

軟件測試在軟件開發(fā)過程中占有重要的地位缓溅，在傳統(tǒng)的瀑布模型中蛇损，軟件測試只成為其階段性的一段工作——進行代碼的測試赁温。而現(xiàn)代軟件工程思想將軟件測試認為是貫穿整個軟件生命周期，并且是保證軟件質量的重要手段之一淤齐。

有些研究數(shù)據(jù)顯示股囊，在國外軟件開發(fā)的工作量中，軟件測試的工作量占有總工作量的40%左右更啄；軟件開發(fā)的總費用中軟件測試占有30%-50%稚疹。對于一些高科技開發(fā)系統(tǒng)，軟件測試占有的時間和費用可能更多更高祭务。

1内狗、軟件測試與軟件開發(fā)

軟件測試在項目各個階段的作用如下：

• 項目規(guī)劃階段：負責從單元測試到系統(tǒng)測試的整個測試階段的監(jiān)控怪嫌。
• 需求分析階段：確定測試需求分析，即確定在項目中需要測試什么柳沙，同時制定系統(tǒng)測試計劃岩灭。
• 概要設計與詳細設計階段：制定單元測試計劃和集成測試計劃。
• 編碼階段：編寫相應的測試代碼和測試腳本赂鲤。
• 測試階段：執(zhí)行測試并提交相應的測試報告噪径。

軟件測試與軟件開發(fā)的關系如下圖所示：

軟件測試與軟件開發(fā)的關系

2、常見軟件測試模型

（1）V模型

• 優(yōu)點：將復雜的測試工作分成了目標明確的小階段完成数初，具有階段性找爱、順序性和依賴性，它既包含了對于源代碼的底層測試也包含了對于軟件需求的高層測試泡孩。
• 缺點：只能在編碼之后才能開始測試车摄，早期的需求分析等前期工作沒有涵蓋其中，因此它不能發(fā)現(xiàn)需求分析等早期的錯誤珍德，這為后期的系統(tǒng)測試练般、驗收測試埋下了隱患。

V模型流程圖如下：

V模型

（2）W模型

• 優(yōu)點：測試范圍不僅包括程序锈候，還包括需求分析薄料、軟件設計等前期工作，這樣有利于盡早全面的發(fā)現(xiàn)問題泵琳。
• 缺點：它將軟件開發(fā)過程分成需求摄职、設計、編碼获列、集成等一系列的串行活動谷市，無法支持迭代、自發(fā)性等需要變更調(diào)整的項目击孩。

W模型流程圖如下：

W模型

（3）H模型

• 設計原理：H模型的設計原理是將測試活動完全獨立了出來迫悠，形成一個完全獨立的流程，這個流程將測試準備活動和測試執(zhí)行活動清晰的體現(xiàn)出來巩梢。測試流程和其他工作流程是并發(fā)執(zhí)行的创泄，只要某一個工作流程的條件成熟就可以開始進行測試。

• 優(yōu)點：

  • 開發(fā)的H模型揭示了軟件測試除測試執(zhí)行外括蝠，還有很多工作鞠抑；
  • 軟件測試完全獨立，貫穿整個生命周期忌警，且與其他流程并發(fā)進行搁拙；
  • 軟件測試活動可以盡早準備、盡早執(zhí)行，具有很強的靈活性箕速；
  • 軟件測試可以根據(jù)被測物的不同而分層次酪碘、分階段、分次序的執(zhí)行盐茎，同時也是可以被迭代的婆跑。

• 缺點：

  • 管理型要求高：由于模型很靈活，必須要定義清晰的規(guī)則和管理制度庭呜，否則測試過程將非常難以管理和控制滑进；
  • 技能要求高：H模型要求能夠很好的定義每個迭代的規(guī)模，不能太大也不能太小募谎；
  • 測試就緒點分析困難：測試很多的時候扶关，你并不知道測試準備到什么時候是合適的，就緒點在哪里数冬，就緒點的標準是什么节槐，這就對后續(xù)的測試執(zhí)行的啟動帶來很大困難；
  • 對于整個項目組的人員要求非常高：在很好的規(guī)范制度下拐纱，大家都能高效的工作铜异，否則容易混亂。例如：你分了一個小的迭代秸架，但是因為人員技能不足揍庄，使得無法有效完成，那么整個項目就會受到很大的干擾东抹。

H模型流程圖如下：

H模型

（4）X模型

• 設計原理：X模型的設計原理是將程序分成多個片段反復迭代測試蚂子，然后將多個片段集成再進行迭代測試。
• 優(yōu)點：對單獨程序片段進行的相互分離的編碼和測試缭黔，保證了測試效果食茎。增加了探索測試，可以幫助測試人員發(fā)現(xiàn)計劃之外的軟件錯誤馏谨。
• 缺點：頻繁的集成會增加測試成本别渔；探索測試對測試人員要求更高。

X模型流程圖如下：

X模型

經(jīng)驗小結：

• v模型適用于中小企業(yè)惧互，w模型適用于中大型企業(yè)（因為人員要求高）哎媚，h模型人員要求非常高，很少有公司使用壹哺；
• 結合W模型與H模型進行工作抄伍，軟件各方面的測試內(nèi)容是以W模型為準艘刚，而測試周期管宵、測試計劃和進度是以H模型為指導。X模型更多是作為最終測試、熟練性測試的模板箩朴，例如岗喉，對一個業(yè)務的測試已經(jīng)有2年時間，則可以使用X模型進行模塊化的炸庞、探索性的方向測試钱床。

五、 軟件測試的原則

1埠居、軟件測試的原則

（1）測試應基于客戶需求

所有的測試工作都應該建立在滿足客戶需求的基礎上查牌，從客戶角度來看，最嚴重的錯誤就是軟件無法滿足要求滥壕。有時候纸颜，軟件產(chǎn)品的測試結果非常完美，但卻不是客戶最終想要的產(chǎn)品绎橘，那么軟件產(chǎn)品的開發(fā)就是失敗的胁孙，而測試工作也是沒有任何意義的。因此測試應依照客戶的需求配置環(huán)境并且按照客戶的使用習慣進行測試并評價結果称鳞。

（2）測試要盡早進行和不斷進行

軟件的錯誤存在于軟件生命周期的各個階段涮较，因此應該盡早開展測試工作，把軟件測試貫穿到軟件生命周期的各個階段中冈止，這樣測試人員能夠盡早地發(fā)現(xiàn)和預防錯誤狂票，降低錯誤修復的成本。盡早的開展測試工作有利于幫助測試人員了解軟件產(chǎn)品的需求和設計熙暴，從而預測測試的難度和風險苫亦，制定出完善的計劃和方案，提高測試的效率怨咪。

（3）窮舉測試是不可能的

由于時間和資源的限制屋剑，進行完全（各種輸入和輸出的全部組合）的測試是不可能的，測試人員可以根據(jù)測試的風險和優(yōu)先級等確定測試的關注點诗眨，從而控制測試的工作量唉匾，在測試成本、風險和收益之間求得平衡匠楚。

（4）遵循GoodEnough原則

GoodEnough原則是指測試的投入與產(chǎn)出要適當權衡巍膘，形成充分的質量評估過程，這個過程建立在測試花費的代價之上芋簿。測試不充分無法保證軟件產(chǎn)品的質量峡懈，但測試投入過多會造成資源的浪費。隨著測試資源投入的增加与斤，測試的產(chǎn)出也是增加的肪康，但當投入達到一定的比例后荚恶，測試的效果就不會明顯增強了。因此在測試時要根據(jù)實際要求和產(chǎn)品質量考慮測試的投入磷支，最好使測試投入與產(chǎn)出達到一個GoodEnough狀態(tài)谒撼。

（5）測試缺陷要符合“二八”定理

一般情況下，軟件80%的缺陷會集中在20%的模塊中雾狈，缺陷并不是平均分布的廓潜。因此在測試時，要抓住主要矛盾善榛，如果發(fā)現(xiàn)某些模塊比其他模塊具有更多的缺陷辩蛋，則要投入更多的人力、精力重點測試這些模塊以提高測試效率移盆。

（6）避免缺陷免疫

測試用例被反復使用堪澎，發(fā)現(xiàn)缺陷的能力就會越來越差；測試人員對軟件越熟悉越會忽略一些看起來比較小的問題味滞，發(fā)現(xiàn)缺陷的能力也越差樱蛤，這種現(xiàn)象被稱為軟件測試的“殺蟲劑”現(xiàn)象。它主要是由于測試人員沒有及時更新測試用例或者是對測試用例和測試對象過于熟悉剑鞍，形成了思維定勢昨凡。

六、 軟件測試的流程

1蚁署、軟件測試的基本流程

不同類型的軟件產(chǎn)品測試的方式和重點不一樣便脊，測試流程也會不一樣。同樣類型的軟件產(chǎn)品光戈，不同的公司所制定的測試流程也會不一樣哪痰。雖然不同軟件的詳細測試步驟不同，但它們所遵循的最基本的測試流程是一樣的久妆。

軟件測試的基本流程

（1）分析測試需求

測試人員在制定測試計劃之前需要先對軟件需求進行分析晌杰，以便對要開發(fā)的軟件產(chǎn)品有一個清晰的認識，從而明確測試對象及測試工作的范圍和測試重點筷弦。在分析需求時還可以獲取一些測試數(shù)據(jù)肋演，作為測試計劃的基本依據(jù)，為后續(xù)的測試打好基礎烂琴。

此外爹殊，分析測試需求也是對軟件需求進行測試，以發(fā)現(xiàn)軟件需求中不合理的地方奸绷。

被確定的測試需求必須是可核實的，測試需求必須有一個可觀察惰帽、可評測的結果。無法核實的需求就不是測試需求父虑。測試需求分析還要與客戶進行交流该酗，以澄清某些混淆，確保測試人員與客戶盡早地對項目達成共識士嚎。

（2）制定測試計劃

測試計劃一般要做好以下工作安排呜魄。

• 確定測試范圍：明確哪些對象是需要測試的，哪些對象不是需要測試的莱衩。
• 制定測試策略：測試策略是測試計劃中最重要的部分爵嗅，它將要測試的內(nèi)容劃分出不同的優(yōu)先級，并確定測試重點笨蚁。根據(jù)測試模塊的特點和測試類型（如功能測試睹晒、性能測試）選定測試環(huán)境和測試方法（如人工測試、自動化測試）括细。
• 安排測試資源：通過對測試難度伪很、時間、工作量等因素對測試資源合理安排奋单，包括人員分配锉试、工具配置等。
• 安排測試進度：根據(jù)軟件開發(fā)計劃览濒、產(chǎn)品的整體計劃來安排測試工作的進度呆盖，同時還要考慮各部分工作的變化。在安排工作進度時贷笛，最好在各項測試工作之間預留一個緩沖時間以應對計劃變更应又。
• 預估測試風險：羅列出測試工作過程中可能會出現(xiàn)的不確定因素，并制定應對策略乏苦。

（3）設計測試用例

• 測試用例（Test Case）指的是一套詳細的測試方案丁频，包括測試環(huán)境、測試步驟邑贴、測試數(shù)據(jù)和預期結果席里。不同的公司會有不同的測試用例模板，雖然它們在風格和樣式上有所不同拢驾，但本質上是一樣的奖磁，都包括了測試用例的基本要素。
• 測試用例編寫的原則是盡量以最少的測試用例達到最大測試覆蓋率繁疤。

（4）執(zhí)行測試

• 測試執(zhí)行就是按照測試用例執(zhí)行測試的過程咖为，這是測試人員最主要的活動階段秕狰。
• 在執(zhí)行測試時要根據(jù)測試用例的優(yōu)先級進行。
• 在執(zhí)行測試過程中躁染，測試人員要密切跟蹤測試過程鸣哀，記錄缺陷、形成報告等吞彤，這一階段是測試人員最重要的工作階段我衬。

（5）編寫測試報告

一份完整的測試報告必須要包含以下幾個要點。

• 引言：測試報告編寫目的饰恕、報告中出現(xiàn)的專業(yè)術語解釋及參考資料等挠羔。
• 測試概要：介紹項目背景、測試時間埋嵌、測試地點及測試人員等信息破加。
• 測試內(nèi)容及執(zhí)行情況：描述本次測試模塊的版本、測試類型雹嗦，使用的測試用例設計方法及測試通過覆蓋率范舀，依據(jù)測試的通過情況提供對測試執(zhí)行過程的評估結論，并給出測試執(zhí)行活動的改進建議了罪，以供后續(xù)測試執(zhí)行活動借鑒參考尿背。
• 缺陷統(tǒng)計與分析：統(tǒng)計本次測試所發(fā)現(xiàn)的缺陷數(shù)目献汗、類型等钧排，分析缺陷產(chǎn)生的原因給出規(guī)避措施等建議，同時還要記錄殘留缺陷與未解決問題兑徘。
• 測試結論與建議：從需求符合度吱七、功能正確性汽久、性能指標等多個維度對版本質量進行總體評價，給出具體明確的結論踊餐。

總結：測試報告的數(shù)據(jù)是真實的景醇，每一條結論的得出都要有評價依據(jù)，不能是主觀臆斷的吝岭。

下一篇文章講解黑盒測試和測試用例的基礎知識三痰。

七、結束語

關于軟件測試的基礎知識就講到這里啦窜管！如有不明白或有誤的地方歡迎私聊或加我微信指正~

• 公眾號：星期一研究室
• 微信：MondayLaboratory

創(chuàng)作不易散劫，如果這篇文章對你有用，記得點個 Star 哦~