不管你是因為興趣想轉軟件測試，還是因為高薪選擇軟件測試，小編在這里就跟大家說說，軟件測試零基礎可以學嗎？ 一、想要零基礎學好軟件測試，當然需要對測試有一個良好的認知。 1、什么是軟件測試? 軟件測 ...
|
理論上，在測試資源許可并且確有必要的前提下，測試的使命將是驗證和確認待開發(fā)的軟件及其中間產品滿足需求矩陣各個需求項。(注意：為了簡化討論，這里筆者沒有把需求的驗證與確認納入進來，實際上這部分工作也是軟件測試工作的重要組成部分。詳細論述請參閱拙文《試論軟件測試學科架構建設》)然而，幾乎沒有幾個公司或開發(fā)團隊能夠提供這類測試所需的諸多的資源，此時，一種可行的策略是將待測試的軟件需求項按照優(yōu)先關系進行排序，以幫助測試經理決策在既定資源的情況下，應該如何統(tǒng)籌安排測試工作。 軟件需求項是測試需求分析的起點，這一點在工程實踐中并不絕對。對于不同階段的測試(這里主要指單元測試、集成測試、系統(tǒng)測試和驗收測試，暫不考慮驗證技術和需求設計確認)，測試需求開發(fā)所涉及的工作內容和方法都會略有差異。例如，如果是一個驗收測試，那么，除了個別的需求需要做進一步明確外，幾乎可以將測試需求等同于用戶需求和業(yè)務需求(由于該類測試是以客戶為主體，因此并不需要向下追溯到軟件需求);又如，如果是系統(tǒng)測試，除了需要對不具備可測試性的軟件需求項進一步開發(fā)外，幾乎可以對軟件需求和測試需求不做區(qū)分。再如，如果是集成測試，測試需求應該從概要設計規(guī)格說明中導出。如果尚不存在概要設計規(guī)格說明，就需要從軟件需求規(guī)格說明出發(fā)，與軟件設計人員協(xié)同工作，具體定出構成系統(tǒng)的各個模塊、子系統(tǒng)、分系統(tǒng)的功能、性能、約束性條件以及相互接口關系。根據協(xié)同工作的結果，開發(fā)出對應的測試需求。最后，如果是單元測試，測試需求應該從詳細設計規(guī)格說明中導出。如果項目不存在概要設計規(guī)格說明，就需要從概要設計規(guī)格說明出發(fā)，與軟件設計人員明確每個模塊內部的對象屬性與方法以及對象與對象間的通信關系。根據此結果，進一步開發(fā)相應的測試需求。相應地，上一節(jié)所說的對軟件需求項進行優(yōu)先關系排序在實踐中要變通地理解為對測試需求項進行優(yōu)先關系排序。 哪些測試需求項應該先測，哪些可以延后，那些是可以并行等，都需要在測試需求開發(fā)階段一并分析清楚。除了對軟件需求項、測試需求項做優(yōu)先關系排序、對不具備可測試性或不確定的需求進一步細化、明確化之外，測試需求開發(fā)階段的工作還包括分析各測試需求項之間可能的時間關系排序。 讀者朋友可能會問，對于整周期的開發(fā)項目，以上論述是否意味著測試需求開發(fā)的依據文檔是否要根據測試所處的階段而不斷調整呢?是的，筆者認為這也是完全必要的。我們不能指望軟件需求項能夠描述清楚集成或單元測試階段的測試需求。 測試需求的開發(fā)總是有賴于相應層次的軟件規(guī)格說明書(只有在開發(fā)團隊不能提供的情況下才確有必要循著“詳細設計規(guī)格說明->概要設計規(guī)格說明->軟件需求規(guī)格說明->用戶需求規(guī)格說明->項目章程、合同、項目建議書、工作說明書等”的順序往前追溯)。通常相關依據文檔的可測試性越好，測試需求開發(fā)所需要的工作量越少。 三、零基礎如何學好軟件測試，不懂測試方法怎能事半功倍? 1、從測試設計方法分類 Black box黑盒測試：把軟件系統(tǒng)當作一個“黑箱”，無法了解或使用系統(tǒng)的內部結構及知識。從軟件的行為，而不是內部結構出發(fā)來設計測試. White box白盒測試：設計者可以看到軟件系統(tǒng)的內部結構，并且使用軟件的內部知識來指導測試數據及方法的選擇。 Gray box. 灰盒測試：介于黑盒和白盒之間 總結： 實際工作中，對系統(tǒng)的了解越多越好。目前大多數的測試人員都是做黑盒測試，很少有做白盒測試的。 因為白盒測試對軟件測試人員的要求非常高，需要有很多編程經驗。做.NET程序的白盒測試你要能看得懂.NET代碼。做JAVA程序的測試，需要你能看懂JAVA的代碼。 如果你都能看懂了，你還會做測試么 2、從測試是手動還是自動上分類 Manual Test 手動測試：測試人員用鼠標去手動測試 (測試GUI) Automation 自動化測試：用程序測試程序 (測試API) 對于項目來說， 手動測試和自動化測試同等重要，都是保障軟件質量的方法。 目前大部分的項目組都是手動測試和自動化測試相結合。因為很多測試無法做成自動化，很多復雜的業(yè)務邏輯也很難自動化， 所以自動化測試無法取代手動測試。 對于軟件測試人員個人發(fā)展來說， 做自動化測試是個挑戰(zhàn)，也是測試人員發(fā)展的一個方向， 需要測試人員學習大量的開發(fā)知識(開發(fā)的知識真是學無止境啊)。 從長遠角度來看，自動化測試肯定是越來越吃香的。 而手動測試比較適合剛工作不久的人，手動測試最大的缺點就是技術含量低，單調乏味，容易廢人。 總的來說，手工測試勝在測試業(yè)務邏輯，而自動化測試勝在測試底層架構。 如果被測試的程序可測試性比較好， 很有必要做成自動化測試。 能做自動化的盡量做成自動化， 下面這些情形是可以做自動化的： 1) 測試存儲過程。 例如用C#去測試存儲過程 2)測試Web servies. 例如： 用SoupUI工具，或者C#,Java 去測試Web servies。 3)界面和業(yè)務邏輯分離的系統(tǒng)，比如，MVC，MVP架構， 或者WPF 程序。 可以用測試腳本去測試這些程序的API。 3、從測試的目的分類 功能測試 測試的范圍從小到大，從內到外， 從程序開發(fā)人員(單元測試)到測試人員，到一般用戶Alpha/Beta測試 Unit Test 單元測試：在最低的功能/參數上驗證程序的準確性,比如測試一個函數的正確性(開發(fā)人員做的) Functional Test 功能測試：驗證模塊的功能 (測試人員做的) Integration Test 集成測試：驗證幾個互相有依賴關系的模塊的功能 (測試人員做的) Scenario Test 場景測試：驗證幾個模塊是否能完成一個用戶場景 (測試人員做的) System Test 系統(tǒng)測試：對于整個系統(tǒng)功能的測試 (測試人員做的) Alpha 測試：軟件測試人員在真實用戶環(huán)境中對軟件進行全面的測試 (測試人員做的) Beta 測試：真實的用戶在真實的用戶環(huán)境中進行的測試, 也叫公測 (最終用戶做的) 非功能測試 一個軟件除了基本功能之外，還有很多功能之外的特性，這些叫“Quality of Service requirement”服務質量需求。沒有軟件的功能，這些特性都無從表現出來，因此，我們要在軟件開發(fā)的適當階段-基本功能完成后做這些測試。 Stress test 壓力測試：驗證軟件在超過負載設計的情況下仍能返回正確的結果，沒有崩潰 Load test 負載測試：測試軟件在負載情況下能否正常工作 Performance test性能測試：測試軟件的效能，是否提供滿意的服務質量 Accessibility test：軟件輔助功能測試-測試軟件是否向殘疾用戶提供足夠的輔助功能 Localization/Globalization：本地化/全球化測試 Compatibility Test：兼容性測試 Configuration Test：配置測試-測試軟件在各種配置下能否正常工作 Usability Test：可用性測試 –測試軟件是否好用 Security Test：軟件安全性測試 性能測試 性能測試要求測試人員熟練性能測試工具，比如QTP, LoadRunner, Jmeter。 Visual Studio也提供了很多性能測試的工具. 要求測試人員對低層協(xié)議非常理解和編寫腳本 性能測試非常有技術含量， 很有發(fā)展前途， 是軟件測試人員的一個職業(yè)發(fā)展方向4、按測試的時機和作用分類 在開發(fā)軟件的過程中，不少測試起著“烽火臺”的作用，它們告訴我們軟件開發(fā)的流程是否暢通。 Smoke Test：“冒煙”–如果測試不通過，則不能進行下一步工作 Build Verification Test(BVT)：驗證構建是否通過基本測試。 Acceptance Test：驗收測試，為了全面考核某功能/特性而做的測試 BVT測試是一種Smoke Test, 指Build生成好之后，自動運行的自動化測試腳本來檢查這個Build的基本功能。 如果BVT測試失敗了，需要開發(fā)人員馬上修改，重新生成Buil 5、按測試測策略分類 Regression Test 回歸測試：對一個新的版本，重新運行以往的測試用例，看看新版本和已知的版本相比是否有退化 (regression) Ad hoc Test 探索性測試：隨機進行的，探索性的測試。 Santiy Test：粗略的測試， 只需要執(zhí)行部分的測試用例 Regression Test 回歸測試： 對軟件測試人員來說就是重復測試，所以回歸測試最好是自動化的，否則測試人員就要一遍又一遍地重復測試。 1)開發(fā)人員做些小改動，就需要測試人員做回歸測試。確?，F有的功能沒有被破壞; 2)Bug Fix 也需要回歸測試，確保新的代碼修復了Fix, 也確保現有的功能沒有被破壞; 3) 項目后期，需要做一個完整回歸測試， 確保所有的功能都是好的。 四、零基礎如何學好軟件測試?我們都知道盲區(qū)這個概念，當然它在軟件測試中也是存在的，那么我們該如何避免這些測試盲區(qū)呢? 1、充分理解軟件需求 需求方面的如果理解有誤或者分析遺漏，那么將對軟件功能測試很難全面覆蓋?；竟δ軠y試有遺漏的話，那是不可饒恕的，所以在測試前以及測試過程中要多注意軟件需求文檔、產品規(guī)格書，尤其是沒有文檔化的規(guī)格更改、需求變動，這都是很容易出現誤測或漏測的。這在項目進程中需要項目成員之間加強信息溝通。 2、制定一份完善的測試方案 測試方案包括的內容比較多，這里我們主要指測試用例，測試前需要制定一套完善的測試用例，完善指我們的測試用例至少要覆蓋所有軟件需求，同時對于邊界測試、中斷測試、性能測試都要涵蓋。測試用例編寫很簡單，但編寫高質量的測試用例真的不容易，至少，讓我稱之為高質量的不多。測試方案應該要經過評審的，至少要和開發(fā)人員一起有針對性地討論下測試內容、重點和需求。 3、多采取交叉測試 也就是同一項目組的不同測試模塊的測試人員互換模塊，相互測試。由于每個人的測試角度、思維方式等都不太一樣，所以這種互測是發(fā)現更多問題的一個有效途徑。事實證明，這種效果非常棒! 4、多學習同類產品的bug庫 同類產品的bug庫對于測試人員而言，是個非常好的資源，測試人員從那里可以了解更多產品容易出問題的地方，甚至很多問題本產品上就潛在著，還未被發(fā)現。 5、多溝通、交流 每一階段，項目測試組長都應該組織小組測試人員多多交流，分析、總結下測試中遇到的問題，由于是一些概率性以及容易被忽略的問題，單個測試人員測試時可能遇到，但并不以為意，這樣，通過討論、交流，能夠加強測試人員對問題的印象，在接下來測試中加強薄弱環(huán)節(jié)的測試。 6、加強相關產品知識學習 尤其是一些技術原理上的東西，只有深入了解了，測試上才能更加發(fā)現更多原來力所難及的問題，如協(xié)議層的問題。 7、經常測試、充分測試 測試上有個原則：及早測試、經常測試、充分測試。要發(fā)現更多的問題、減少測試盲區(qū)，多測是少不了的。 其實，更廣義地理解，測試盲區(qū)還涉及到測試軟件質量目標和針對性問題，測試還要注意把握一個度和量，我們要知道軟件在生命周期內的質量目標是什么。過猶不及，將大量時間浪費在測試一些用戶永遠無法涉及到或者無關輕重的地方，這都是很盲目的! 五、零基礎如何學好軟件測試?我們了解了測試定義、流程、方法、盲區(qū)之后，我們還需要能寫出一份完美的測試報告： 我們要認識到軟件測試報告遠非一種形式，更多是一個測試活動的總結，項目是否結項的重要參考和依據。因此本文指導一些才從業(yè)不久的朋友怎么編寫一份高質量的測試報告。 1、要有明確結論 縱觀一些軟件測試報告，可能測試人員基于規(guī)避自己的責任，或者迫于軟件開發(fā)經理的壓力，導致在報告中盡寫一些模棱兩可的結論。這樣的測試報告是沒有任何作用的，更多體現了測試團隊的懦弱和無能。一個有效的測試報告，關鍵是有一個建立在真實測試數據上，客觀、公正的明確結論。公司領導把質量交付給你，是希望你能保證公司的軟件質量，如果結論都閃爍其詞，你讓公司怎么相信、支持測試團隊。 2、每一條結論都是建立在事實、數據上 前面已經提到，測試報告中最重要的就是要有明確的結論。有可能是一組數據，也有可能是一句話。這些結論不管以何種形式展現出來，有個重要的原則：每條結論必須建立在事實、數據上。測試結論不能依照少量的不可靠的數據進行推測，更不能憑空捏造。否則，整個測試報告就真正淪為了一個形式，可能還會因此導致一些未知的負面后果。 3、測試報告中結果應盡可能圖文結合方式展現出來 測試報告的讀者往往是項目經理，或者公司高層，更有甚者為軟件買單客戶。所以測試報告應盡可能以直觀的形式展現出來。比如數據最好以列表的形式展現出來，測試迭代情況最好以折線圖展現出來，并在圖表下配以文字說明。這樣的測試報告不僅僅是賞心悅目，更讓高層見到了測試團隊的專業(yè)性，從而更容易獲得認可。 4、測試報告中，必須客觀填寫，但可以在結尾給予一定的建議 測試報告中很關鍵的一點就是，必須客觀真實的反應軟件測試的質量檢測結果。所以在報告中，應該排除過多的個人因素，客觀的去填寫結果、說明和報告。但是，如果你有一些想法和建議，也可以在報告結論之后進行附加說明。我一直認為測試人員除了發(fā)現缺陷，還有一些具有創(chuàng)造性的東西。 下面說下一個標準測試報告應該包含的內容信息： 1)概述，包括本次測試的目的，測試的背景介紹。 2)測試環(huán)境，包括測試軟硬件環(huán)境及配置，以及測試環(huán)境的網絡拓撲圖 3)測試的一些參考資料 4)測試參與人員，以及投入的時間情況說明 5)測試的進度情況，包括計劃進度和實際進度 6)測試情況介紹，包括測試的內容項說明。如功能測試具體的測試項，測試通過情況;性能測試的測試項，測試通過情況等 7)缺陷的統(tǒng)計和分析，包括迭代次數，缺陷的分布情況，缺陷的覆蓋情況，缺陷的發(fā)展趨勢等 8)本次測試的結論 9)測試人員就本次測試的一些建議 六、零基礎學好軟件測試是為了增加我們自身的一種技能、為了明天的一份高薪工作，學以致用，我們也應該在這里了解一下軟件測試工程師日常的工作是什么? 日常的工作流程一般是這樣的(以一個版本迭代為周期): 評審新需求，記錄關鍵點–>編寫測試點(用例)–>測試之前向開發(fā)了解部分實現–>執(zhí)行測試(翻閱代碼，查看主邏輯走向<可選>)–>提交BUG–>回歸BUG(查看BUG代碼改動)–>新需求的性能評估(可選)–>發(fā)布前的系統(tǒng)測試(結合自動化)–>發(fā)布–>自動化用例的補充(可選)–>業(yè)務邏輯總結歸總–>休息 在一天工作的八個小時中，有位資深軟件測試工程師是這樣安排的：30%的時間用于評審用例維護等準備以及后期工作;20%的時間用于執(zhí)行測試用例，BUG回歸;50%的時間用于自動化和新技術學習，引入!不知道你的一天會怎么安排呢? 零基礎如何學好軟件測試，小編只是給你提供的是一個思路，需要在這些概況內容的基礎上去深入了解、鉆研，比如文中有提到測試需求，那么你還需要拓展如何收集需求、如何定位需求等內容;文中提到黑盒測試，那么你還需要拓展什么是黑盒測試、黑盒測試的特點優(yōu)勢是什么、在什么情況下使用以及如何使用黑盒測試等內容。如果你覺得自己沒有很強的毅力，但你還想快速上手軟件測試，那么你來啄木鳥學院吧，金牌講師手把手帶你入門，讓你零基礎學好軟件測試，給自己3個月，給自己一次逆襲的機會! |
分享本篇文章給更多人:
2020-05-27
2020-02-24
2020-05-27
2022-12-05
2020-05-27
請發(fā)表評論