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