軟件測試的各種方法介紹

1、研發(fā)過程中軟件測試的方法匯總一、 動態(tài)測試的幾個環(huán)節(jié)：動態(tài)測試，英文是Moment Testing。動態(tài)測試是指通過運(yùn)行軟件來檢驗(yàn)軟件的動態(tài)行為和運(yùn)行結(jié)果的正確性。根據(jù)動態(tài)測試在軟件開發(fā)過程中所處的階段和作用，動態(tài)測試可分為如下幾個步驟：單元測試集成測試冒煙測試系統(tǒng)測試回歸測試驗(yàn)收測試1. 單元測試單元測試，英文是Unit Testing。單元測試是最微小規(guī)模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做，因?yàn)樗枰纼?nèi)部程序設(shè)計和編碼的細(xì)節(jié)知識。這個工作不容易做好，除非應(yīng)用系統(tǒng)有一個設(shè)計很好的體系結(jié)構(gòu); 還可能需要開發(fā)測試驅(qū)動器模塊或測試套具。2. 集成測試集成測試，英文是I

2、ntegration Testing。集成測試是指一個應(yīng)用系統(tǒng)的各個部件的聯(lián)合測試，以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊、獨(dú)立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。這種類型的測試尤其與客戶服務(wù)器和分布式系統(tǒng)有關(guān)。一般集成測試以前，單元測試需要完成。集成測試是單元測試的邏輯擴(kuò)展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實(shí)方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。

3、此外，如果程序由多個進(jìn)程組成，應(yīng)該成對測試它們，而不是同時測試所有進(jìn)程。集成測試識別組合單元時出現(xiàn)的問題。通過使用要求在組合單元前測試每個單元，并確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發(fā)現(xiàn)的任何錯誤很可能與單元之間的接口有關(guān)。這種方法將可能發(fā)生的情況數(shù)量減少到更簡單的分析級別3. 冒煙測試冒煙測試，英文是Smoke testing。冒煙測試的名稱可以理解為該種測試耗時短，僅用一袋煙功夫足夠了。也有人認(rèn)為是形象地類比新電路板基本功能檢查。任何新電路板焊好后，先通電檢查，如果存在設(shè)計缺陷，電路板可能會短路，板子冒煙了。冒煙測試的對象是新編譯的每一個需要正式測試的軟件版本，目的是確

4、認(rèn)軟件基本功能正常，可以進(jìn)行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編譯人員。4. 系統(tǒng)測試系統(tǒng)測試，英文是System Testing。系統(tǒng)測試是基于系統(tǒng)整體需求說明書的黑盒類測試，應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進(jìn)行的測試，目的是驗(yàn)證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不相符合或與之矛盾的地方。系統(tǒng)測試的對象不僅僅包括需要測試的產(chǎn)品系統(tǒng)的軟件，還要包含軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各種依賴的資源結(jié)合起來，在系統(tǒng)實(shí)際運(yùn)行環(huán)境下來進(jìn)行測試。5. 回歸測試回歸測試，英文是Regression testing

5、。回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。理論上，軟件產(chǎn)生新版本，都需要進(jìn)行回歸測試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯誤是否在新軟件版本上再次出現(xiàn)。根據(jù)修復(fù)好了的缺陷再重新進(jìn)行測試?；貧w測試的目的在于驗(yàn)證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新測試。通常確定所需的再測試的范圍時是比較困難的，特別當(dāng)臨近產(chǎn)品發(fā)布日期時。因?yàn)闉榱诵拚橙毕輹r必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗(yàn)證修好的缺陷時不僅要服從缺陷原來出現(xiàn)時的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應(yīng)當(dāng)鼓勵對所有回歸測試用例進(jìn)行自

6、動化測試。6. 接受測試接受測試，英文是Accept Testing。接受測試是基于客戶或最終用戶的規(guī)格書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。一般從功能、用戶界面、性能、業(yè)務(wù)關(guān)聯(lián)性進(jìn)行測試。二、 按測試者對內(nèi)部的知曉或者程度分類：1. 白盒測試白盒測試，英文是White Box Testing。又稱結(jié)構(gòu)測試或者邏輯驅(qū)動測試。白盒測試是把測試對象看作一個打開的盒子。利用白盒測試法進(jìn)行動態(tài)測試時，需要測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程，不需測試軟件產(chǎn)品的功能。白盒測試法的覆蓋標(biāo)準(zhǔn)有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆

7、蓋、條件組合覆蓋和路徑覆蓋。白盒測試是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗(yàn)證。白盒測試常用工具有：Jtest、VcSmith、Jcontract、C+ Test、CodeWizard、logiscope。2. 黑盒測試黑盒測試，英文是Black Box Testing。又稱功能測試或者數(shù)據(jù)驅(qū)動測試。黑盒測試是根據(jù)軟件的規(guī)格對軟件進(jìn)行的測試，這類測試不考慮軟件內(nèi)部的運(yùn)作原理，因此軟件對用戶來說就像一個

8、黑盒子。軟件測試人員以用戶的角度，通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在的缺陷，而不關(guān)心程序具體如何實(shí)現(xiàn)的一種軟件測試方法。黑盒測試常用工具有：AutoRunner、winrunner、loadrunner。三、 從思維的方向分：1. 正向測試：2. 逆向測試：逆向測試/反向測試/負(fù)面測試的英文是Negative Testing，測試瞄準(zhǔn)于使系統(tǒng)不能工作。負(fù)面測試與正面測試的比較：負(fù)面測試（Negative testing）是相對于正面測試（Positive testing）而言的。它們也是測試設(shè)計時的兩個非常重要的劃分。簡單點(diǎn)說，正面測試就是測試系統(tǒng)是否完成了它應(yīng)該完成的工作；而

9、負(fù)面測試就是測試系統(tǒng)是否不執(zhí)行它不應(yīng)該完成的操作。形象一點(diǎn)，正面測試就象一個畢恭畢敬的小學(xué)生，老師叫我做什么，我就做什么；而負(fù)面測試就象一個調(diào)皮搗蛋的孩子，你叫我這樣做，我偏不這樣做，而且和你對著干。開發(fā)人員也是最討厭修改此類bug的。四、 從測試的內(nèi)容分：1. 接口測試接口測試的英文是interface testing，接口測試測試系統(tǒng)組件間接口的一種測試。接口測試的好處：由于接口測試代碼本身就是用junit（當(dāng)然接口的類型不同，不一定是Junit來實(shí)現(xiàn)）來實(shí)現(xiàn)的，是屬于自動化測試的范疇，因此必定也包含自動化測試所固有的優(yōu)勢。1） 提高測試質(zhì)量軟件開發(fā)的過程是一個持續(xù)集成和改進(jìn)的過程，而每一

10、次的改進(jìn)都可能引進(jìn)新bug,因此當(dāng)軟件的一部，或者全部修改時，都需要對軟件產(chǎn)品重新進(jìn)行測試。其目的是要驗(yàn)證修改后的產(chǎn)品是符合需求的，而當(dāng)沒有自動化測試代碼時，往往會由于各種各樣的原因，回歸不充分，導(dǎo)致bug遺漏。2） 提高測試效率軟件系統(tǒng)的規(guī)模越來越大，功能點(diǎn)越來越多，開發(fā)人員的自測或者測試人員的人工測試非常耗時和繁瑣，勢必導(dǎo)致測試效率的低下，而自動化測試正好解決這些耗時繁瑣的任務(wù)，在對外接口功能不變的情況下，達(dá)到了一次編寫，永久使用的效果。3） 提高測試覆蓋通過手工測試很難測試到一些更深層次的異常和安全的問題，通過一些輔助的一些測試工具，能分析出代碼的覆蓋率，通過覆蓋率的提高來提高測試的深度

11、。4） 更好地重現(xiàn)軟件缺陷由于每次執(zhí)行都是相同的代碼，一旦代碼出錯，必定回歸出錯5） 更好定位錯誤由于接口測試是一種自下向上的測試，因此一量出錯，非常容易定位出錯，不向系統(tǒng)測試那樣了，一旦有Bug，需要幾層驗(yàn)證之后才能確定出錯位置6） 降低修改bug的成本接口測試基本和開發(fā)人員的編碼平行工作，因此發(fā)現(xiàn)問題會比系統(tǒng)測試早很多，因此減少了修改bug的成本。7） 增進(jìn)測試人員和開發(fā)人員之間的合作關(guān)系，測試工程師為了更好地開展工作，需要對開發(fā)技術(shù)有深入的理解和實(shí)踐，有了與開發(fā)工程師更多的交流。8） 降低了項(xiàng)目不能按時發(fā)布的風(fēng)險由于接口測試很早就介入，在提交給系統(tǒng)測試前對項(xiàng)目代碼的核心模塊已經(jīng)做了詳盡的

12、測試，必定加速系統(tǒng)測試的時間，由此來保證項(xiàng)目的按時發(fā)布。9）提升測試人員的技能。做接口測試必須了解開發(fā)人員的開發(fā)流程和一些開發(fā)技能，也需要了解測試工具的一些使用方法和一些測試思想，提升了測試人員的技術(shù)附加值，提高了自身的競爭力。10）促使項(xiàng)目開發(fā)過程的規(guī)范化要進(jìn)行接口，需要完善的文檔進(jìn)行保障，沒有測試文檔，接口測試將寸步難行，接口測試將增加開發(fā)過程規(guī)范化產(chǎn)出，而規(guī)范化產(chǎn)出也保證了項(xiàng)目質(zhì)量。2. 文檔測試：文檔測試的英文是documentation testing，測試關(guān)注于文檔的正確性。文檔測試有三大類分別是開發(fā)文件、用戶文件、管理文件。1. 開發(fā)文件：可行性研究報告、軟件需求說明書、數(shù)據(jù)要求

13、說明書、概要設(shè)計說明書、詳細(xì)設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、模塊開發(fā)卷宗。2.用戶文件：用戶手冊、操作手冊。3.管理文件：項(xiàng)目開發(fā)計劃、測試計劃、測試分析報告、開發(fā)進(jìn)度月報、項(xiàng)目開發(fā)總結(jié)報告。軟件測試中的文檔測試主要是對相關(guān)的設(shè)計報告和用戶使用說明進(jìn)行測試，對于設(shè)計報告主要是測試程序與設(shè)計報告中的設(shè)計思想是否一致；對于用戶使用說明進(jìn)行測試時，主要是測試用戶使用說明書中對程序操作方法的描述是否正確，重點(diǎn)是用戶使用說明中提到的操作例子要進(jìn)行測試，保證采用的例子能夠在程序中正確完成操作。一般來識,文檔是軟件的重要組成部分,因此文檔測試也是軟件測試的主要內(nèi)容。在軟件的整個生命周期中會出現(xiàn)很多文檔,通?？?/p>

14、以把文檔粗略地分為三類:開發(fā)文檔,管理文檔和用戶文檔。由于文檔與代碼不同,不能直接運(yùn)行,對于文檔的測試通常只能以文檔審查的方式進(jìn)行。對于管理文檔和審查通常歸屬于管理范疇,而不是軟件測試范疇,因?yàn)閷τ诠芾砦臋n審查的目的不是為了發(fā)現(xiàn)和消除用戶所看到的軟件中的缺陷,而是為了更好地管理軟件開發(fā)的過程。對于開發(fā)文檔,由于這些文檔本身體現(xiàn)了所在開發(fā)階段的軟件實(shí)際形態(tài),對于這些文檔的測試實(shí)際上是早期軟件測試的主要活動。用戶文檔是那些隨程序一起交付給用戶的文檔,它們實(shí)際上是交付給用戶的軟件的重要組成部分。對于這些文檔的測試是對最終軟件產(chǎn)品測試的一部分?；谠O(shè)計的測試的英文是design-based testi

15、ng，是根據(jù)軟件的構(gòu)架或詳細(xì)設(shè)計引出測試用例的一種方法。3. 安全測試：安全測試，英文是Security Testing。安全測試是測試系統(tǒng)在防止非授權(quán)的內(nèi)部或外部用戶的訪問或故意破壞等情況時怎么樣。這可能需要復(fù)雜的測試技術(shù)。安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如：想方設(shè)法截取或破譯口令；專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準(zhǔn)則是，使非法侵入的代價超過被保護(hù)信息的價值。此時非

16、法侵入者已無利可圖。五、 從性能上分：1. 性能測試性能測試，英文是Performance Testing。性能測試是在交替進(jìn)行負(fù)荷和強(qiáng)迫測試時常用的術(shù)語。理想的“性能測試”(和其他類型的測試)應(yīng)在需求文檔或質(zhì)量保證、測試計劃中定義。性能測試一般包括負(fù)載測試和壓力測試。通常驗(yàn)證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)?；蛘邎?zhí)行同樣任務(wù)時新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運(yùn)行程序時會不會流失(memory leak)。比如，驗(yàn)證程序保存一個巨大的文件新版本不比舊版本慢。2. 壓力測試壓力測試，英文是Stress Testing。和負(fù)載測試差不多。壓力測試是一種基本的

17、質(zhì)量保證行為，它是每個重要軟件測試工作的一部分。壓力測試的基本思路很簡單：不是在常規(guī)條件下運(yùn)行手動或自動測試，而是在計算機(jī)數(shù)量較少或系統(tǒng)資源匱乏的條件下運(yùn)行測試。通常要進(jìn)行壓力測試的資源包括內(nèi)部內(nèi)存、CPU 可用性、磁盤空間和網(wǎng)絡(luò)帶寬等。一般用并發(fā)來做壓力測試。3. 負(fù)載測試負(fù)載測試，英文是Load testing。負(fù)載測試是測試一個應(yīng)用在重負(fù)荷下的表現(xiàn)。例如測試一個 Web 站點(diǎn)在大量的負(fù)荷下，何時系統(tǒng)的響應(yīng)會退化或失敗，以發(fā)現(xiàn)設(shè)計上的錯誤或驗(yàn)證系統(tǒng)的負(fù)載能力。在這種測試中，將使測試對象承擔(dān)不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行的能力。負(fù)載測試的目標(biāo)

18、是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，負(fù)載測試還要評估性能特征，例如，響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的方面。4. 衰竭測試衰竭測試，英文是Failure Testing。衰竭測試是指軟件或環(huán)境的修復(fù)或更正后的“再測試”?？赡芎茈y確定需要多少遍再次測試。尤其在接近開發(fā)周期結(jié)束時。自動測試工具對這類測試尤其有用。5. 健全測試健全測試，英文是Sanity testing。健全測試是指一個初始化的測試工作，以決定一個新的軟件版本測試是否足以執(zhí)行下一步大的測試能力。例如，如果一個新版軟件每5分鐘與系統(tǒng)沖突，使系統(tǒng)陷于泥潭，說明該軟件不夠“健全”，目前不具備進(jìn)一步測試的

19、條件。六、 按區(qū)域劃分：1. 本地化測試本地化測試，英文是Localization testing。本地化就是將軟件版本語言進(jìn)行更改，比如將英文的windows改成中文的windows就是本地化。本地化測試的對象是軟件的本地化版本。本地化測試的目的是測試特定目標(biāo)區(qū)域設(shè)置的軟件本地化質(zhì)量。本地化測試的環(huán)境是在本地化的操作系統(tǒng)上安裝本地化的軟件。從測試方法上可以分為基本功能測試，安裝/卸載測試，當(dāng)?shù)貐^(qū)域的軟硬件兼容性測試。測試的內(nèi)容主要包括軟件本地化后的界面布局和軟件翻譯的語言質(zhì)量，包含軟件、文檔和聯(lián)機(jī)幫助等部分。本地化能力測試是指不需要重新設(shè)計或修改代碼，將程序的用戶界面翻譯成任何目標(biāo)語言的能力。為