邏輯覆蓋、循環(huán)覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數(shù)據(jù)流分析
單元測試是對軟件基本組成單元進(jìn)行測試,
這里的基本單元不一定是指一個(gè)具體的函數(shù)
(
Function
或
Procedure
)
或一個(gè)類的方法,
“
單元
”
具有一些基本屬性,
如:
明確的功能、
規(guī)格定義,明確的接口定義,可清晰地與同一程序的其它單元?jiǎng)澐珠_來。
在純
C
語言的代碼中,為了操作方便期間,我們一般認(rèn)為一個(gè)函數(shù)就是一個(gè)單元。
1.2.2
單元測試的主要目的:
1.
驗(yàn)證代碼是與設(shè)計(jì)符合的
2.
跟蹤需求和設(shè)計(jì)的實(shí)現(xiàn)
3.
發(fā)現(xiàn)設(shè)計(jì)和需求中存在的錯(cuò)誤
4.
發(fā)現(xiàn)在編碼過程中引入的錯(cuò)誤
1.2.3
何時(shí)開展單元測試
一般地,
在編碼階段就應(yīng)開展單元測試,
邊寫程序邊測試是一個(gè)好習(xí)慣。
一個(gè)組織不要
孤立的劃分出編碼和單元測試兩個(gè)階段,也不要等代碼都寫完了才開始單元測試。
有時(shí)候需要將單元測試時(shí)間推后到集成階段,甚至系統(tǒng)完成階段。
單元測試可以分為計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行幾個(gè)階段。
“
計(jì)劃
”
是作好人和時(shí)間的安排。
“
設(shè)計(jì)
”
確定采用什么樣的測試方法,
達(dá)到一個(gè)什么樣的覆蓋率標(biāo)準(zhǔn)等。
“
實(shí)現(xiàn)
”
是設(shè)計(jì)生成各
個(gè)測試用例。
“
執(zhí)行
”
包括驅(qū)動(dòng)和樁函數(shù)的設(shè)計(jì)實(shí)現(xiàn),測試數(shù)據(jù)準(zhǔn)備,測試結(jié)果驗(yàn)證等等。
”。
你要在測試策略中很明確的提出你進(jìn)行測試時(shí)所使用的方法和步驟。 我看到過很多公司嚴(yán)格地按照一些測試策略模板來寫。
但是,其實(shí)不用模板,你也可以并且更高效地寫測試策略。下面是一些簡單的寫測試策略的技巧, 1)在測試策略中要包括產(chǎn)品的背景信息。
在測試策略文檔的第一段回答- stakeholder(項(xiàng)目利益相關(guān)者)為什么要開發(fā)這個(gè)產(chǎn)品?回答這個(gè)問題會(huì)幫助你更好更快地理解項(xiàng)目,并為所做的事情優(yōu)先級排序。 2)測試環(huán)境,它應(yīng)該包括你在那個(gè)操作系統(tǒng)平臺(tái)上做測試,系統(tǒng)是基于那些補(bǔ)丁和安全更新。
例如,一個(gè)測試環(huán)境可能必須包含Window XP SP2 3)列出你將要測試的所有重要特征。如果你認(rèn)為有些特征不屬于本次發(fā)布的一部分,那么就標(biāo)注“不會(huì)被測試的特征”。
4)寫下在此項(xiàng)目測試中將應(yīng)用到的測試方法。清楚的列出你將以那些類型的測試作為測試引導(dǎo)。
例如:功能測試,用戶交互界面測試,集成測試,壓力測試,安全測試等等。 5)回答以下問題:你如何進(jìn)行功能測試?手動(dòng)還是自動(dòng)化?測試工具是什么?你將執(zhí)行在測試管理工具中的所有測試用例嗎? 6)用什么作為測試錯(cuò)誤報(bào)告跟蹤工具?當(dāng)測試人員發(fā)現(xiàn)一個(gè)新的bug之后,流程應(yīng)該是什么? 7)測試進(jìn)入和結(jié)束的標(biāo)準(zhǔn)分別是什么? 8)如何去跟蹤測試進(jìn)度?什么度量可以用來記錄測試結(jié)束? 9)任務(wù)分布 – 定義每個(gè)組員的角色和職責(zé),包括測試組長,測試員,項(xiàng)目經(jīng)理等。
測試戰(zhàn)略將由開發(fā)人員review,確保測試的覆蓋率全面且沒有重疊處。測試經(jīng)理和部門經(jīng)理都要同意測試策略之后,測試工作才能展開。
測試小組的劃分及分工。 10)有哪些風(fēng)險(xiǎn)會(huì)阻礙測試的完成?例如,代碼的依賴性,測試工具的局限性等等。
要提前想到風(fēng)險(xiǎn)發(fā)生的解決辦法。 11)測試日程表- 每個(gè)測試計(jì)劃都應(yīng)該包含一個(gè)預(yù)估時(shí)間來估計(jì)完成測試所需要的時(shí)間。
這需要幾個(gè)階段:一,測試人員必須至少完成一次的執(zhí)行全部用例。二,如果一個(gè)錯(cuò)誤被測試人員發(fā)現(xiàn),開發(fā)人員將修復(fù)此錯(cuò)誤。
測試員重新測試此用例,直到其功能正確為止。最后,但很重要的一點(diǎn)是測試員必須對修改過的地方執(zhí)行回歸測試以保證開發(fā)人員在修復(fù)一個(gè)錯(cuò)誤的時(shí)候沒有引入另外的代碼錯(cuò)誤。
測試日程表要包含每個(gè)測試部分涉及的測試人員。時(shí)間往往很難估計(jì),因?yàn)闇y試中有很多不確定性的事情發(fā)生。
其中一個(gè)比較好的辦法是參照前一個(gè)發(fā)布來估計(jì)。 12)回歸測試的方法- 一個(gè)錯(cuò)誤被修復(fù)后,必須要保證產(chǎn)品功能按用例標(biāo)準(zhǔn)運(yùn)行。
回歸測試是為了在修復(fù)一個(gè)問題時(shí)不引入另外的錯(cuò)誤。因此相關(guān)的測試用例要在被執(zhí)行一次,從而確保沒有特殊的東西被引進(jìn)。
在這個(gè)階段,就要定義回歸測試的方法。有的公司講相關(guān)模塊的單元測試用例全部遍歷一遍,從而確保產(chǎn)品的質(zhì)量。
弄清楚這些問題,你就可以寫一個(gè)詳細(xì)的測試策略出來了。
軟件測試的方法根據(jù)軟件工程的組織和實(shí)現(xiàn)方式,有很大差別,有些是比較技術(shù)化的方法,有些則是工程方法,主要分為: 黑盒測試方法群:等價(jià)類劃分、邊界值、因果圖、基路徑法、專家測試法、smoking、場景測試等 白盒測試方法群:同行評審、需求審查、代碼審查、接口測試(調(diào)用測試和返回測試,需要結(jié)合等價(jià)類和因果圖方法)等。
當(dāng)在單元層面黑盒而在集成層面白盒時(shí),基本上兩類方法就會(huì)有結(jié)合了,就會(huì)出現(xiàn)習(xí)慣上說的灰盒測試(說實(shí)話,不做到純產(chǎn)品級開發(fā),基本上都是用的灰盒測試)。
軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件,包含了產(chǎn)品概述,測試策略,測試方法,測試區(qū)域,測試配置,測試周期,測試資源,風(fēng)險(xiǎn)分析等內(nèi)容;借助軟件測試計(jì)劃,參與測試的項(xiàng)目成員,可以明確測試任務(wù)和測試方法,保持測試實(shí)施過程的順暢溝通,跟蹤和控制測試進(jìn)度,應(yīng)對測試過程中的各種變更。
測試計(jì)劃和測試用例間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系,測試計(jì)劃主要從宏觀上規(guī)劃測試活動(dòng)的范圍,方法和資源配置;而測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。
測試計(jì)劃中,最重要的是測試策略和測試方法。
測試計(jì)劃工作的關(guān)鍵是
1. 明確測試的目標(biāo),增強(qiáng)測試計(jì)劃的實(shí)用性---測試計(jì)劃中的測試范圍必須高度覆蓋功能需求,測試方法必須切實(shí)可行,測試工具具有較高的實(shí)用性,便于使用,生成的測試結(jié)果直觀準(zhǔn)確。
2. 堅(jiān)持“5W”規(guī)則,明確內(nèi)容與過程
“5W”規(guī)則指:what,why,when,where,how;用例5w規(guī)則創(chuàng)建軟件測試計(jì)劃,可幫助測試團(tuán)隊(duì)理解測試目的(why),明確測試范圍和內(nèi)容(what),確定測試開始和結(jié)束日期(when),指出測試的方法和工具(what),給出測試文檔和軟件存放位置(where)3. 采用評審和更新機(jī)制,保證測試計(jì)劃滿足實(shí)際需求
測試策略描述測試工程的總體方法和目標(biāo)。
描述目前在進(jìn)行哪一階段的測試(單元測試、集成測試、系統(tǒng)測試)以及每個(gè)階段內(nèi)在進(jìn)行的測試種類(功能測試、性能測試、覆蓋測試等)。
測試策略的制定主要包含三個(gè)方面的內(nèi)容:
(1)確定測試過程要使用的測試技術(shù)和工具;
(2)制定測試啟動(dòng)、停止、完成標(biāo)準(zhǔn);
(3)進(jìn)行風(fēng)險(xiǎn)分析和應(yīng)對方案。例如測試與外部接口或者模擬物理損壞、安全性威脅。測試計(jì)劃最關(guān)鍵的一步就是將軟件分解成單元,按照需求編寫測試計(jì)劃。
擴(kuò)展資料。
測試英文名Test、Measure;中文拼音cè shì;由中文"測"與中文"試"兩個(gè)字組成的詞語。
是動(dòng)詞、名詞。
測試行為,一般發(fā)生于為檢測特定的目標(biāo)是否符合標(biāo)準(zhǔn)而采用專用的工具或者方法進(jìn)行驗(yàn)證,并最終得出特定的結(jié)果。
測試策略
Test Strategy;test policy;testing strategy
例句:
文章主要討論了編碼完成后的方法的測試和類的測試,并分別給出了測試策略。
This paper discusses both the method testing and the class testing after finishing the coding.
而后,測試策略也將必須遵循測試管理框架。
Following this, the testing strategy will also have to follow the test management framework.
有了決策表,我們就可以根據(jù)測試策略輕松的添加和刪除條件。
With a decision table, it is easy to add and remove conditions, depending on the test strategy.
軟件測試策略把軟件測試用例的設(shè)計(jì)方法集成到一系列已經(jīng)周密計(jì)劃過的步驟中去,從而使得軟件的開發(fā)得以成功的完成。
同樣重要的是,軟件測試策略為軟件開發(fā)人員、質(zhì)量保證組織、和客戶提供了一個(gè)路線圖——這個(gè)路線圖描述了測試的步驟,以及當(dāng)這些步驟在計(jì)劃和實(shí)施的過程中,需要多少工作量、時(shí)間、和資源。 因此,任何測試策略都必須和測試計(jì)劃、測試用例設(shè)計(jì)、測試執(zhí)行、還有測試結(jié)果數(shù)據(jù)的收集與分析結(jié)合在一起。
一種軟件測試策略應(yīng)當(dāng)具備足夠的靈活性,這樣在必要的時(shí)候它能夠有足夠的創(chuàng)造性和可塑性來應(yīng)付所有的大軟件系統(tǒng)。與此同時(shí),軟件測試策略還必須保證足夠的嚴(yán)格,這樣才能保證對項(xiàng)目的整個(gè)進(jìn)程進(jìn)行合理的計(jì)劃和跟蹤管理。
Shooman[SHO83]對這個(gè)問題進(jìn)行了探討: 在許多情況下,測試是一個(gè)獨(dú)立的過程,不同的測試類型的數(shù)量和不同的開發(fā)方法是一樣多。許多年以來,我們對付程序出錯(cuò)的唯一武器就是謹(jǐn)慎的設(shè)計(jì),以及程序員個(gè)人的智慧。
我們現(xiàn)在處于這樣的一個(gè)時(shí)代——現(xiàn)代設(shè)計(jì)技術(shù)(和正式的技術(shù)復(fù)審)正在幫助我們減少代碼中存在的初始錯(cuò)誤。 類似地,不同的測試方法正在開始聚合為有限的幾種方法和思想。
這些方法和思想就是我們所說的策略。在第16章中,我們已經(jīng)介紹了軟件測試技術(shù)①。
在本章中,我們將會(huì)把注意力放在軟件測試策略上。
聲明:本網(wǎng)站尊重并保護(hù)知識(shí)產(chǎn)權(quán),根據(jù)《信息網(wǎng)絡(luò)傳播權(quán)保護(hù)條例》,如果我們轉(zhuǎn)載的作品侵犯了您的權(quán)利,請?jiān)谝粋€(gè)月內(nèi)通知我們,我們會(huì)及時(shí)刪除。
蜀ICP備2020033479號(hào)-4 Copyright ? 2016 學(xué)習(xí)鳥. 頁面生成時(shí)間:2.836秒