定義
在規(guī)定的條件下對(duì)程序進(jìn)行操作循头，以發(fā)現(xiàn)程序錯(cuò)誤唠摹，衡量軟件質(zhì)量，并對(duì)其是否能滿足設(shè)計(jì)要求進(jìn)行評(píng)估的過(guò)程奉瘤。
測(cè)試就是發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程勾拉。
原則
保證測(cè)試的覆蓋度，但是窮舉測(cè)試是不可能的盗温。
所有的測(cè)試都應(yīng)該追溯到用戶藕赞。
越早測(cè)越好，測(cè)試過(guò)程與開發(fā)過(guò)程應(yīng)該是互相結(jié)合的卖局。
測(cè)試的規(guī)模 從小到大斧蜕，從單元測(cè)試到系統(tǒng)測(cè)試。
不能為了便于測(cè)試而擅自修改程序砚偶。
既應(yīng)該測(cè)試軟件能做什么批销，也應(yīng)該測(cè)試軟件不能做什么。
度量
測(cè)試覆蓋率
缺陷發(fā)現(xiàn)率
測(cè)試成功率（或者說(shuō)用例通過(guò)率）
測(cè)試做到什么程度并沒(méi)有一個(gè)固定答案染坯。只要滿足兩個(gè)顯式條件和一個(gè)隱含條件就要一直進(jìn)行均芽。
顯式條件：
項(xiàng)目風(fēng)險(xiǎn)
項(xiàng)目經(jīng)費(fèi)
隱含條件：
老板們從當(dāng)前的測(cè)試結(jié)果已經(jīng)獲得了足夠的信心,或者徹底摧毀了信心。只要他們還在猶豫咱就得繼續(xù)干活单鹿。
測(cè)試的原則
測(cè)試只是展示缺陷
測(cè)試只能表明缺陷存在,卻不能證明沒(méi)有缺陷掀宋。測(cè)試能降低未發(fā)現(xiàn)缺陷留存的概率,卻 不能證明軟件是絕對(duì)正確的。 正如某些數(shù)學(xué)命題,你可以窮舉 1-n,證明其正確,卻依然無(wú)法證明對(duì)于 n+1 仍然正確仲锄。
窮盡測(cè)試是不可能的
測(cè)試所有的輸入和條件組合是不可能的,除非是極其簡(jiǎn)單的情況劲妙。可以取而代之的是基 于風(fēng)險(xiǎn)和優(yōu)先級(jí)的測(cè)試儒喊。 當(dāng)不懂裝懂的老板要求你徹底測(cè)試一個(gè)軟件的時(shí)候,這是你反駁的最好支持,當(dāng)然要說(shuō) 的委婉一點(diǎn)镣奋。
早期測(cè)試
要較早發(fā)現(xiàn)缺陷,就要在軟件周期盡可能早的時(shí)候開始測(cè)試,而且要專注于已定義的測(cè) 試目標(biāo)。 盡早開始測(cè)試!這句話估計(jì)早就把大家的耳朵磨起繭了怀愧。為什么要早?因?yàn)樵皆绨l(fā)現(xiàn)問(wèn) 題,解決的代價(jià)就越小唆途。
缺陷簇生
要對(duì)缺陷發(fā)現(xiàn)率高的模塊投入更多的測(cè)試。少量的模塊往往隱藏了大部分的缺陷掸驱。 這不僅僅是所謂的物以類聚肛搬。缺陷發(fā)現(xiàn)率高的模塊往往于需求不清,設(shè)計(jì)不當(dāng),編碼復(fù) 雜度高等內(nèi)在原因關(guān)聯(lián),所以從風(fēng)險(xiǎn)的角度來(lái)看必然較高,多花些時(shí)間絕對(duì)值得。
殺蟲劑悖論
相同的測(cè)試再重復(fù)多次后就無(wú)法再找到缺陷了毕贼。要克服“殺蟲劑悖論”,測(cè)試用例要不斷評(píng)審修改,不斷添加新的和不同的測(cè)試,就有可能找到更多缺陷温赔。 隨著對(duì)系統(tǒng)的加深理解,必然會(huì)有更多的測(cè)試用例產(chǎn)生。另外缺陷本身也是新用例的很 好來(lái)源鬼癣。
測(cè)試是上下文相關(guān)的
測(cè)試在不同上下文環(huán)境中的執(zhí)行是不同的陶贼。比方說(shuō) 安全關(guān)鍵系統(tǒng) (safety critical system)和電子商務(wù)網(wǎng)站的測(cè)試方法就有很大不同啤贩。 這個(gè)原理相對(duì)難理解。這里其實(shí)強(qiáng)調(diào)的是不能用相同的態(tài)度和手段來(lái)測(cè)試不同類型的系 統(tǒng)拜秧。安全關(guān)鍵系統(tǒng)的概念要到高級(jí)大綱中才出現(xiàn),指的是對(duì)系統(tǒng)安全要求苛刻的系統(tǒng), 較之一般的電子商務(wù)系統(tǒng)的測(cè)試要求更為嚴(yán)苛痹屹。
無(wú)錯(cuò)謬論
假如建立的系統(tǒng)不穩(wěn)定或不能滿足用戶需要和期望,那么發(fā)現(xiàn)和修復(fù)缺陷就毫無(wú)幫助了。 缺陷數(shù)量往往用來(lái)評(píng)估某軟件的質(zhì)量,但要是系統(tǒng)本身背離了用戶要求,那就算缺陷再 少也沒(méi)用,因?yàn)闆](méi)有人會(huì)去用它枉氮。所以測(cè)試時(shí)要注意驗(yàn)證(verification)和確認(rèn)(validation)的區(qū)別志衍。需求規(guī)格說(shuō)明和其他文檔只是需求的不完全載體。文字說(shuō)明必然有遺漏和偏差, 而各人的理解更有可能出錯(cuò)聊替。要不斷通過(guò)各種途徑保證所生產(chǎn)的的確就是用戶需要的楼肪。 常用的方式就是邀請(qǐng)領(lǐng)域?qū)＜一蛴脩舯M可能多地參與到開發(fā)活動(dòng)來(lái),特別是需求評(píng)審和 演示(Demo)。
測(cè)試的標(biāo)準(zhǔn)
測(cè)試的標(biāo)準(zhǔn)是用戶的需求惹悄。
所有的軟件測(cè)試都應(yīng)該追溯用戶的需求春叫，測(cè)試人員要始終站在用戶的角度去看問(wèn)題、去判斷的軟件缺陷的影響泣港，系統(tǒng)最嚴(yán)重的錯(cuò)誤是那些導(dǎo)致程序無(wú)法滿足用戶需求的缺陷暂殖。
測(cè)試主要步驟
計(jì)劃與控制
分析與設(shè)計(jì)
實(shí)施與執(zhí)行
評(píng)估出口準(zhǔn)則和報(bào)告
測(cè)試結(jié)束活動(dòng)
測(cè)試流程
熟悉產(chǎn)品／項(xiàng)目
需求評(píng)審
測(cè)試需求
測(cè)試計(jì)劃
測(cè)試用例
預(yù)測(cè)試
第一輪測(cè)試
第二輪回歸測(cè)試
第三輪測(cè)試
測(cè)試報(bào)告
測(cè)試總結(jié)
為什么要避免測(cè)試自己的程序？
由于心理因素当纱，人們潛意識(shí)都不希望找到自己的錯(cuò)誤央星。基于這種思維定勢(shì)惫东，人們難于發(fā)現(xiàn)自己的錯(cuò)誤莉给。
軟件測(cè)試的要素
質(zhì)量：
軟件質(zhì)量是軟件測(cè)試的目標(biāo)，也是軟件測(cè)試工作的中心廉沮，一切從質(zhì)量出發(fā)颓遏，也就是一切從客戶需求出發(fā)。任何違背質(zhì)量的東西都是問(wèn)題滞时，測(cè)試就是要找出這些問(wèn)題叁幢。
人員：
人是決定的因素，測(cè)試人員的態(tài)度坪稽、素質(zhì)曼玩、能力決定著測(cè)試的效果，對(duì)測(cè)試產(chǎn)品的質(zhì)量也有很大的影響窒百。測(cè)試人員因素包括測(cè)試組織結(jié)構(gòu)黍判、角色和責(zé)任的定義。
技術(shù)：
軟件測(cè)試技術(shù)篙梢，包括方法顷帖、工具。
資源：
主要是指測(cè)試環(huán)境中所需要的硬件設(shè)備、網(wǎng)絡(luò)環(huán)境贬墩，甚至包括測(cè)試數(shù)據(jù)榴嗅。另外一個(gè)重要因素就是測(cè)試時(shí)間，時(shí)間也是測(cè)試的資源陶舞，但測(cè)試人員不能看做資源嗽测，每個(gè)人的能力千差萬(wàn)別，不同的測(cè)試人員擔(dān)任不同的角色肿孵，不能相互代替唠粥。這也是軟件圖書的經(jīng)典之作——《人件》的作者反對(duì)將人作為資源對(duì)待的原因。
流程：
從測(cè)試計(jì)劃和測(cè)試用例的創(chuàng)建颁井、評(píng)審到測(cè)試的執(zhí)行、報(bào)告蠢护，設(shè)定每個(gè)階段的進(jìn)出標(biāo)準(zhǔn)雅宾。
軟件質(zhì)量
軟件產(chǎn)品質(zhì)量評(píng)價(jià)國(guó)際標(biāo)準(zhǔn)ISO 14598 把軟件質(zhì)量定義為：軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力葵硕。上述定義反應(yīng)如下3個(gè)方面的問(wèn)題：
軟件需求是度量軟件質(zhì)量的標(biāo)準(zhǔn)眉抬；
軟件人員必須遵循軟件過(guò)程過(guò)程的規(guī)范；
如果軟件只是滿足規(guī)定的需求懈凹，而不能滿足可能存在的隱含需求蜀变，軟件質(zhì)量也不能保證。
軟件團(tuán)隊(duì)的責(zé)任
發(fā)現(xiàn)軟件程序介评、系統(tǒng)或產(chǎn)品中“所有”的問(wèn)題
盡早地發(fā)現(xiàn)問(wèn)題
督促和協(xié)助開發(fā)人員盡快地解決程序中的缺陷
幫助項(xiàng)目管理人員制定合理的開發(fā)計(jì)劃
對(duì)缺陷進(jìn)行跟蹤库北、分析和分類總結(jié)，以便讓項(xiàng)目的管理人員和相關(guān)的負(fù)責(zé)人員能夠及時(shí)们陆、清楚地了解產(chǎn)品當(dāng)前的質(zhì)量狀態(tài)
幫助改善開發(fā)流程寒瓦、調(diào)高產(chǎn)品開發(fā)效率
促進(jìn)程序編寫的規(guī)范性、易讀性坪仇、可維護(hù)性等
缺陷發(fā)現(xiàn)率
缺陷發(fā)現(xiàn)率DDP是另一個(gè)衡量測(cè)試工作效率的軟件質(zhì)量成本的指標(biāo)杂腰。
缺陷發(fā)現(xiàn)率
缺陷發(fā)現(xiàn)率DDP＝Bugs（tester）/ （Bugs（tester）+ Bugs（customer））
缺陷發(fā)現(xiàn)率越高，也就是測(cè)試者發(fā)現(xiàn)的錯(cuò)誤多椅文，發(fā)布后客戶發(fā)現(xiàn)的錯(cuò)誤就越少喂很，降低了外部故障不一致成本，達(dá)到節(jié)約總成本的目的皆刺，可獲得較高的測(cè)試投資回報(bào)率少辣。
測(cè)試分類
黑盒測(cè)試
又稱功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，是針對(duì)軟件的功能需求/實(shí)現(xiàn)進(jìn)行測(cè)試羡蛾，通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否符合需求毒坛，不考慮程序內(nèi)部的邏輯結(jié)構(gòu)。
方法：
功能劃分
等價(jià)類劃分
邊界值劃分
因果圖（魚骨圖）
錯(cuò)誤推測(cè)
白盒測(cè)試
白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，必須知道軟件內(nèi)部工作過(guò)程煎殷，通過(guò)測(cè)試來(lái)檢測(cè)軟件內(nèi)部是否按照需求屯伞、設(shè)計(jì)正常運(yùn)行。
方法：
對(duì)應(yīng)于程序的一些主要結(jié)構(gòu)：語(yǔ)句豪直、分支劣摇、邏輯路徑、變量弓乙；
語(yǔ)句覆蓋方法
分支覆蓋方法
邏輯覆蓋方法
單元測(cè)試
定義： 又稱模塊測(cè)試末融，是針對(duì)軟件設(shè)計(jì)的最小單位程序模塊進(jìn)行正確性檢查的測(cè)試工作；可以從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例暇韧，多個(gè)模塊測(cè)試可以平行地獨(dú)立進(jìn)行測(cè)試勾习；
目的：發(fā)現(xiàn)模塊內(nèi)部可能存在的差錯(cuò)；
內(nèi)容：模塊接口測(cè)試（數(shù)據(jù)流入流出）懈玻、局部數(shù)據(jù)結(jié)構(gòu)測(cè)試巧婶、路徑測(cè)試、錯(cuò)誤處理測(cè)試涂乌、邊界測(cè)試艺栈。
步驟：利用設(shè)計(jì)文檔設(shè)計(jì)測(cè)試用例；創(chuàng)建被測(cè)模塊的樁模塊或驅(qū)動(dòng)模塊湾盒；利用被測(cè)試模塊湿右、驅(qū)動(dòng)模塊和樁模塊來(lái)建立測(cè)試環(huán)境，進(jìn)行測(cè)試罚勾。
集成測(cè)試
定義：又稱組裝測(cè)試或聯(lián)合測(cè)試毅人，在單元測(cè)試的基礎(chǔ)上，將所有模塊按概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)進(jìn)行組裝尖殃。
目的：發(fā)現(xiàn)模塊連接中的接口可能存在的各種差錯(cuò)
內(nèi)容：
穿越模塊之間的數(shù)據(jù)是否會(huì)丟失堰塌；
一個(gè)模塊組裝后是否會(huì)對(duì)另一模塊或其他模塊存在影響
各個(gè)子功能組裝在一起是否會(huì)達(dá)到預(yù)期的父功能
全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問(wèn)題；
單個(gè)模塊的錯(cuò)誤累積起來(lái)是否會(huì)放在分衫。
組裝方法：包括一次性組裝方式涮阔、增殖式組裝方式兩種組裝方法
完成標(biāo)志：成功地執(zhí)行了測(cè)試計(jì)劃中規(guī)定的所有測(cè)試用例汛闸；修正了所發(fā)現(xiàn)的錯(cuò)誤；測(cè)試結(jié)果通過(guò)專門小組的評(píng)審
系統(tǒng)測(cè)試
目的：驗(yàn)證和確認(rèn)系統(tǒng)是否達(dá)到其原始目標(biāo)，而對(duì)集成的硬件和軟件系統(tǒng)進(jìn)行的測(cè)試
測(cè)試內(nèi)容：在真實(shí)或模擬系統(tǒng)運(yùn)行環(huán)境下涮拗，檢查完整的程序系統(tǒng)能否和系統(tǒng)（硬件設(shè)備媒抠、網(wǎng)絡(luò)善玫、系統(tǒng)軟件）正確配置工窍、連接，滿足用戶需求
驗(yàn)收測(cè)試
測(cè)試目的：在用戶環(huán)境中進(jìn)行測(cè)試壁畸，以確定系統(tǒng)和產(chǎn)品是否能夠滿足合同或用戶所規(guī)定的需求
測(cè)試內(nèi)容：根據(jù)任務(wù)書或合同贼急、供需雙方約定的驗(yàn)收依據(jù)文檔進(jìn)行對(duì)整個(gè)系統(tǒng)的測(cè)試與評(píng)審茅茂，確認(rèn)是否接收或拒絕系統(tǒng)
Alpha測(cè)試
屬于驗(yàn)證測(cè)試。模擬運(yùn)行太抓。由開發(fā)人員與測(cè)試的測(cè)試人員空闲。
Beta測(cè)試
屬于驗(yàn)收測(cè)試。由軟件的最終用戶在一個(gè)或多個(gè)用戶場(chǎng)所來(lái)進(jìn)行的走敌，開發(fā)者通常不在現(xiàn)場(chǎng)碴倾，用戶記錄測(cè)試中遇到的問(wèn)題并報(bào)告給開發(fā)者。
靜態(tài)測(cè)試
靜態(tài)測(cè)試又稱為靜態(tài)分析技術(shù)掉丽，不執(zhí)行被測(cè)試軟件跌榔，對(duì)需求分析說(shuō)明書、軟件設(shè)計(jì)說(shuō)明書捶障、源程序做結(jié)構(gòu)檢測(cè)僧须、流圖分析、符號(hào)執(zhí)行等找出軟件的錯(cuò)誤项炼。
動(dòng)態(tài)測(cè)試
通過(guò)輸入一組預(yù)先按照一定的測(cè)試準(zhǔn)則構(gòu)造的實(shí)例數(shù)據(jù)動(dòng)態(tài)運(yùn)行程序担平，而達(dá)到發(fā)現(xiàn)程序錯(cuò)誤的過(guò)程。
如何進(jìn)行單元測(cè)試
完成最小的軟件設(shè)計(jì)單元——模塊驗(yàn)證工作芥挣。
確保模塊的正確編碼
使用過(guò)程設(shè)計(jì)描述作為指南驱闷，對(duì)重要的控制路徑進(jìn)行測(cè)試以發(fā)現(xiàn)模塊內(nèi)錯(cuò)誤耻台。
通常情況下面向白盒的
對(duì)代碼風(fēng)格和規(guī)則空免、程序設(shè)計(jì)結(jié)構(gòu)、業(yè)務(wù)邏輯等進(jìn)行靜態(tài)測(cè)試盆耽，及早地發(fā)現(xiàn)和解決不易顯現(xiàn)的錯(cuò)誤蹋砚。
單元測(cè)試的內(nèi)容
接口測(cè)試
內(nèi)部數(shù)據(jù)結(jié)構(gòu)
全局?jǐn)?shù)據(jù)結(jié)構(gòu)
邊界
語(yǔ)句覆蓋，錯(cuò)誤路徑
自動(dòng)化測(cè)試
自動(dòng)化測(cè)試是把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過(guò)程摄杂。
在設(shè)計(jì)了測(cè)試用例并通過(guò)評(píng)審之后坝咐，由測(cè)試人員根據(jù)測(cè)試用例中描述的規(guī)程一步步執(zhí)行測(cè)試，得到實(shí)際結(jié)果與期望結(jié)果的比較析恢。在此過(guò)程中墨坚，為了節(jié)省人力、時(shí)間或硬件資源映挂，提高測(cè)試效率泽篮，便引入了自動(dòng)化測(cè)試的概念。
手工和自動(dòng)化
手工測(cè)試缺點(diǎn)在于測(cè)試工作量大柑船，重復(fù)多帽撑，回歸測(cè)試難以實(shí)現(xiàn)
自動(dòng)測(cè)試?yán)密浖y(cè)試工具自動(dòng)實(shí)現(xiàn)全部或部分測(cè)試工作：管理、設(shè)計(jì)鞍时、執(zhí)行和報(bào)告亏拉；節(jié)省大量的測(cè)試開銷扣蜻，并能夠完成一些手工測(cè)試無(wú)法實(shí)現(xiàn)的測(cè)試
手工完成測(cè)試的全部過(guò)程無(wú)法保證測(cè)試的科學(xué)性與嚴(yán)密性:
修改缺陷越多，回歸測(cè)試約困難
沒(méi)有人能向決策層提供精確的數(shù)據(jù)以度量當(dāng)前的工作進(jìn)度及工作效率
反復(fù)測(cè)試帶來(lái)的倦怠情緒及其他人為因素使得測(cè)試標(biāo)準(zhǔn)前后不一
測(cè)試花費(fèi)的時(shí)間越長(zhǎng)及塘，測(cè)試的嚴(yán)格性也就越低
自動(dòng)測(cè)試將測(cè)試人員從反復(fù)莽使、煩雜的測(cè)試執(zhí)行中解放出來(lái)，用更多的時(shí)間進(jìn)行測(cè)試設(shè)計(jì)和結(jié)果分析
軟件測(cè)試不可能全部自動(dòng)化
不能完成所有手工測(cè)試任務(wù)
無(wú)創(chuàng)造性磷蛹，且靈活性差吮旅，不能改進(jìn)測(cè)試的有效率
過(guò)程中可能會(huì)遇到很多想不到的問(wèn)題，尤其是在軟件不穩(wěn)定的情況下
測(cè)試腳本的維護(hù)高
測(cè)試用例設(shè)計(jì)原則
單個(gè)用例最小化原則
這條原則是所有這四條原則中的“老大“味咳，也是在工程中最容易被忘記和忽略的庇勃，它或多或少的都影響到其它幾條原則。
測(cè)試用例的覆蓋邊界定義更清晰槽驶，則測(cè)試結(jié)果對(duì)產(chǎn)品問(wèn)題的指向性更強(qiáng)责嚷。
測(cè)試用例間的耦合度最低，則彼此之間的干擾也就越低掂铐。
上述這些優(yōu)點(diǎn)所能帶來(lái)直接好處是罕拂，測(cè)試用例的調(diào)試、分析和維護(hù)成本最低全陨。每個(gè)測(cè)試用例應(yīng)該盡可能的簡(jiǎn)單爆班，只驗(yàn)證你所要驗(yàn)證的內(nèi)容。
測(cè)試用例替代產(chǎn)品文檔功能原則
通常我們會(huì)在開發(fā)的初期（Scrum每個(gè)Sprint的頭兩天）用Word文檔或者OneNote的記錄產(chǎn)品的需求辱姨、功能描述柿菩、以及當(dāng)前所能確定的任何細(xì)節(jié)等信息，勾勒將要實(shí)現(xiàn)功能的樣貌雨涛，便于團(tuán)隊(duì)進(jìn)行交流和細(xì)化枢舶，并在團(tuán)隊(duì)內(nèi)達(dá)成對(duì)產(chǎn)品功能共識(shí)。但隨著產(chǎn)品開發(fā)深入替久，團(tuán)隊(duì)會(huì)對(duì)產(chǎn)品的功能有更新的認(rèn)識(shí)凉泄，產(chǎn)品功能也會(huì)被更具體細(xì)化，在一個(gè)迭代或者Sprint結(jié)束的時(shí)候最終實(shí)現(xiàn)的功能很可能是A+蚯根。如此往復(fù)后众，在不斷傾聽和吸收用戶的反饋，多個(gè)迭代過(guò)后颅拦，原本被描述為A的功能很可能最終變?yōu)榱薢蒂誉。這是時(shí)候再去看看曾經(jīng)的Word文檔和OneNote頁(yè)面，它們?nèi)匀挥涗浀氖茿矩距。之所以會(huì)這樣 拗盒，是因?yàn)楹苌儆腥藭?huì)去以及能夠去不斷地去更新那些文檔，以準(zhǔn)確地反映出功能當(dāng)前準(zhǔn)確的狀態(tài)锥债。
單次投入成本和多次投入成本原則
成本永遠(yuǎn)是任何項(xiàng)目進(jìn)行決策時(shí)所要考慮的首要因素陡蝇，項(xiàng)目中的測(cè)試也是如此痊臭，對(duì)成本的考慮也應(yīng)該客觀和全面的體現(xiàn)在測(cè)試的設(shè)計(jì)、執(zhí)行和維護(hù)的整個(gè)階段中登夫。
測(cè)試中的成本按其時(shí)間跨度可以分為：?jiǎn)未瓮度氤杀竞投啻瓮度氤杀竟愠住＠纾壕帉憸y(cè)試用例可以看作是單次投入成本，因?yàn)榫帉憸y(cè)試用例一般是在測(cè)試的計(jì)劃階段進(jìn)行（Scrum每個(gè)Sprint的開始階段）的恼策，雖然后期會(huì)有小的改動(dòng)鸦致，但絕大多數(shù)是在一開始的設(shè)計(jì)階段就基本上成型了；
使測(cè)試結(jié)果分析和調(diào)試最簡(jiǎn)單化原則
這條原則實(shí)際上是單次投入成本和多次投入成本原則 – 針對(duì)自動(dòng)化測(cè)試用例的擴(kuò)展和延續(xù)涣楷。在編寫自動(dòng)化測(cè)試代碼時(shí)分唾，要重點(diǎn)考慮如何使得測(cè)試結(jié)果分析和測(cè)試調(diào)試更為簡(jiǎn)單，包括：用例日志狮斗、調(diào)試輔助信息輸出等绽乔。
測(cè)試用例方法
等價(jià)類劃分
等價(jià)類劃分
錯(cuò)誤推測(cè)
因果圖
判定表驅(qū)動(dòng)分析
正交實(shí)驗(yàn)設(shè)計(jì)
場(chǎng)景設(shè)計(jì)法
狀態(tài)轉(zhuǎn)換圖
測(cè)試用例內(nèi)容
測(cè)試用例主要包括用例編號(hào)、用例描述碳褒、前提條件折砸、輸入數(shù)據(jù)、測(cè)試步驟和期望結(jié)果6項(xiàng)關(guān)鍵內(nèi)容：
用例編號(hào)
用例的組織要方便測(cè)試人員執(zhí)行測(cè)試用例沙峻，應(yīng)設(shè)計(jì)一套良好的用例編號(hào)體系睦授。
用例描述
用例描述應(yīng)使用最精簡(jiǎn)的文字，描述出用例的全貌摔寨。讓測(cè)試人員不用看測(cè)試步驟去枷，只看這個(gè)描述就可以知道這個(gè)用例是描述哪個(gè)場(chǎng)景、哪個(gè)功能點(diǎn)祷肯。
前提條件
一個(gè)測(cè)試用例一般是針對(duì)一個(gè)特點(diǎn)的場(chǎng)景沉填，而需要測(cè)試的場(chǎng)景發(fā)生時(shí)通常會(huì)有一些鋪墊場(chǎng)景疗隶，即測(cè)試用例的前提佑笋，如軟硬件環(huán)境配置、權(quán)限設(shè)置斑鼻，數(shù)據(jù)準(zhǔn)備蒋纬。
輸入數(shù)據(jù)
一個(gè)測(cè)試用例可以有一個(gè)或多個(gè)輸入數(shù)據(jù)，也可以無(wú)輸入數(shù)據(jù)坚弱。
測(cè)試步驟
測(cè)試步驟是測(cè)試用例的主體蜀备，一個(gè)測(cè)試用例由一個(gè)或多個(gè)步驟組成，每個(gè)步驟之間有一定的前后關(guān)系荒叶。每個(gè)步驟必須表述詳細(xì)碾阁，描述清晰，用于規(guī)范些楣、嚴(yán)謹(jǐn)而又客觀脂凶，最基本的要求是能夠使其他人理解宪睹，并能正確的執(zhí)行編寫者希望的操作。
期望結(jié)果
期望結(jié)果是測(cè)試執(zhí)行對(duì)執(zhí)行結(jié)果進(jìn)行對(duì)比的標(biāo)尺蚕钦，是測(cè)試是否通過(guò)的判斷依據(jù)亭病。測(cè)試結(jié)果必須保證其正確性。
測(cè)試計(jì)劃
根據(jù)項(xiàng)目相關(guān)文檔嘶居，需要定義測(cè)試范圍罪帖、測(cè)試策略、人員分配邮屁、軟硬件配置整袁、進(jìn)度表以及測(cè)試過(guò)程每個(gè)階段需要達(dá)到的目標(biāo)。
查詢遺漏問(wèn)題的方法
說(shuō)明書是基礎(chǔ)和標(biāo)準(zhǔn)
測(cè)試的執(zhí)行佑吝，通常按測(cè)試用例來(lái)進(jìn)行葬项，但測(cè)試用例的設(shè)計(jì)編寫是依據(jù)產(chǎn)品規(guī)格說(shuō)明書、需求規(guī)格說(shuō)明書迹蛤、界面設(shè)計(jì)規(guī)范等民珍。寫測(cè)試用例時(shí)難免有考慮不到的地方，因此反復(fù)閱讀說(shuō)明文檔盗飒，也許會(huì)有一些新的思路和啟發(fā)嚷量。在項(xiàng)目后期，回歸測(cè)試階段逆趣，容易思維定勢(shì)蝶溶、疲憊，這是可以把這些文檔拿出來(lái)宣渗，再看一下功能點(diǎn)是否覆蓋抖所，覆蓋到的是不是和需求一致，沒(méi)有偏差痕囱。
相關(guān)變動(dòng)郵件田轧，討論記錄
變動(dòng)是一個(gè)項(xiàng)目過(guò)程中不可少的部分，而這些變動(dòng)鞍恢，通常是通過(guò)討論的方式定下來(lái)的傻粘，因此會(huì)有一些文檔記錄和郵件。反復(fù)閱讀這些郵件和文檔記錄帮掉，可以更深入的理解項(xiàng)目弦悉。
不定期閱讀別人的缺陷
每個(gè)人的思路、考慮的角度和操作習(xí)慣各不相同蟆炊，因此發(fā)現(xiàn)的問(wèn)題就會(huì)不一樣稽莉。多閱讀別人的缺陷可以拓寬思路，看多了涩搓，也會(huì)不自覺把多種思路集中到一起污秆，慢慢得應(yīng)用到測(cè)試實(shí)踐中了后室。
多和開發(fā)人員溝通
功能測(cè)試對(duì)測(cè)試人員來(lái)說(shuō)大多是黑盒測(cè)試，只有開發(fā)人員最清楚哪個(gè)函數(shù)調(diào)用哪個(gè)函數(shù)混狠、哪塊單元測(cè)試不夠充分岸霹、哪個(gè)邏輯結(jié)構(gòu)比較復(fù)雜，多和他們溝通将饺，可以知道哪里還需要多關(guān)注一下贡避。
有選擇的重新驗(yàn)證以前的缺陷
特別在回歸測(cè)試、驗(yàn)收測(cè)試階段予弧，除了驗(yàn)證前面發(fā)現(xiàn)的缺陷刮吧，還要重視那些與缺陷相關(guān)的模塊。一個(gè)底層參數(shù)的變動(dòng)掖蛤，可能會(huì)引起很多相關(guān)功能的問(wèn)題杀捻，繼而造成缺陷的遺漏。
關(guān)注變化
一段代碼的改動(dòng)蚓庭，需要開發(fā)人員和測(cè)試人員去識(shí)別致讥。開發(fā)人員知道改動(dòng)的地方會(huì)被哪些模塊調(diào)用或者會(huì)引起哪些模塊的變化，但由于時(shí)間緊器赞、任務(wù)重垢袱、很難做好單元測(cè)試，因此開發(fā)人員要通知測(cè)試人員需要關(guān)注的測(cè)試點(diǎn)港柜。
簡(jiǎn)單思維方式请契，一主線為主，減少大遺漏
一個(gè)項(xiàng)目的成功不是把缺陷全報(bào)出來(lái)夏醉，而是在有限的代價(jià)下達(dá)到預(yù)期的質(zhì)量爽锥。按計(jì)劃進(jìn)行的項(xiàng)目，主要功能的質(zhì)量在一定程度上決定了產(chǎn)品的好壞畔柔。在項(xiàng)目工期緊張時(shí)氯夷，全部走完所有測(cè)試用例是很難的，可以基本功能為主線释树，做好相關(guān)測(cè)試用例的執(zhí)行肠槽，保證不會(huì)發(fā)生大的質(zhì)量事故擎淤。
在測(cè)試后期奢啥，測(cè)試人員可能對(duì)質(zhì)量已經(jīng)很有信心，受思維和經(jīng)驗(yàn)的局限性嘴拢，可能僅限于此桩盲。若此時(shí)，在產(chǎn)品發(fā)布之前席吴，調(diào)動(dòng)其他組的員工參與限時(shí)測(cè)試并給予獎(jiǎng)勵(lì)赌结，必然能有效減少軟件缺陷帶來(lái)的風(fēng)險(xiǎn)捞蛋，提高產(chǎn)品質(zhì)量。
軟件缺陷（bug）
軟件缺陷是指系統(tǒng)或系統(tǒng)部件中那些導(dǎo)致系統(tǒng)或部件不能實(shí)現(xiàn)其應(yīng)有功能的缺陷柬姚。一般定義缺陷有以下5條原則：
軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書要求的功能拟杉。
軟件出現(xiàn)產(chǎn)品說(shuō)明書指明不應(yīng)該出現(xiàn)的錯(cuò)誤。
軟件實(shí)現(xiàn)了產(chǎn)品說(shuō)明書未說(shuō)明的功能量承。
軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書雖未明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)搬设。
軟件難以理解，不易使用撕捍，運(yùn)行速度慢拿穴，或者軟件測(cè)試員認(rèn)為最終用戶會(huì)認(rèn)為不好。
提交缺陷（bug）的要求
Bug描述的基本要求是分類準(zhǔn)確忧风、敘述簡(jiǎn)潔默色、步驟清楚、實(shí)際結(jié)果描述準(zhǔn)確狮腿、復(fù)雜問(wèn)題有據(jù)可查（截圖或其他形式的附件）腿宰。基本要求如下：
問(wèn)題描述一般格式：模塊或功能點(diǎn)=>測(cè)試步驟=>期望結(jié)果=>實(shí)際結(jié)果=>其他信息
單一：盡量一個(gè)bug只針對(duì)一個(gè)軟件缺陷
簡(jiǎn)潔：每個(gè)步驟盡量簡(jiǎn)單明了
再現(xiàn)：?jiǎn)栴}必須能在自己機(jī)器上重現(xiàn)方可上報(bào)（個(gè)別嚴(yán)重問(wèn)題重現(xiàn)不了也可上報(bào)缘厢，但必須標(biāo)明）
復(fù)雜問(wèn)題：附截圖補(bǔ)充說(shuō)明或直接通知指定的修改人酗失，截圖文件格式建議用JPG或GIF
報(bào)告中不允許使用抽象的詞語(yǔ)：“有錯(cuò)誤”，“有時(shí)候”之類的不確定語(yǔ)句昧绣。
作者：西邊人
微博：@西邊青年
公眾號(hào)：testpu
