軟體測試的基本流程
軟體測試是一種實際輸出與預期輸出間的稽核或者比較過程。軟體測試其實是有一些基本流程的。那你知道是怎麼樣的嗎?下面將由小編告訴大家，僅供大家參考!
軟體測試雖然是軟體生存週期的一個獨立階段，但測試工作卻滲透到從分析、設計直到程式設計的各個階段中，如測試計劃的編寫從分析和設計階段就開始了，而具體的測試工作隨程式設計工作的不斷深入也在進行中。在實際工作中，測試環節可分為明顯的、同等重要的幾個階段：即需求測試、單元測試、整合測試***又稱組裝測試***和系統測試。
測試工作中的第六個階段是驗收測試階段，驗收測試無論在規模上或性質上都和系統測試很相似，它們的根本區別在於：前者是內部的，而後者則是受“客戶”控制的。
軟體測試的目的
簡單地說，就是替使用者預先使用或者體驗軟體，測試的最終目的是確保最終交給使用者的產品功能符合使用者的需求，把儘可能多的問題在產品交給使用者之前發現並改正。
具體要達到如下目標：
***1***確保產品完成了它所承諾或公佈的功能，並且所有使用者可以訪問到的功能都有明確的書面說明------在某種意義上與ISO9001是同一種思想。
產品缺少明確的書面文件，是廠商一種短期行為的表現，也是一種不負責任的表現。所謂短期行為，是指缺少明確的書面文件既不利於產品最後的順利交付，容易與使用者發生矛盾，影響廠商的聲譽和將來與使用者的合作關係;同時也不利於產品的後期維護，也使廠商支出超額的使用者培訓和技術支援費用。從長期利益看，這是很不划算的。
當然，書面文件的編寫和維護工作對於使用快速原型法***RAD***開發的專案是最為重要的、最為困難，也是最容易被忽略的。
最後，書面文件的不健全甚至不正確，也是測試工作中遇到的最大和最頭痛的問題，它的直接後果是測試效率低下、測試目標不明確、測試範圍不充分，從而導致最終測試的作用不能充分發揮、測試效果不理想。
***2***確保產品滿足效能和效率的要求。使用起來系統執行效率低***效能低***、或使用者介面不友好、使用者操作不方便***效率低***的產品不能說是一個有競爭力的產品。
使用者最關心的不是你的技術有多先進、功能有多強大，而是他能從這些技術、這些功能中得到多少好處。也就是說，使用者關心的是他能從中取出多少，而不是你已經放進去多少。
***3***確保產品是健壯的和適應使用者環境的。健壯性即穩定性，是產品質量的基本要求，尤其對於一個用於事務關鍵或時間關鍵的工作環境中。
軟體測試的原則
***1***應當把“儘早地和不斷地進行軟體測試”作為軟體開發者的座右銘。
由於原始問題的複雜性，軟體的複雜性和抽象性，軟體開發各個階段工作的多樣性，以及參加開發各種層次人員之間工作的配合關係等因素，使得開發的每個環節都可能產生錯誤。所以不應把軟體測試僅僅看作是軟體開發的一個獨立階段，而應當把它貫穿到軟體開發的各個階段中。堅持在軟體開發的各個階段的技術評審，這樣才能在開發過程中儘早發現和預防錯誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟體質量。
***2***測試用例應由測試輸入資料和與之對應的預期輸出結果這兩部分組成。
測試以前應當根據測試的要求選擇在測試過程中使用的測試用例***Test case***。測試用例主要用來檢驗程式設計師編制的程式，因此不但需要測試的輸入資料，而且需要針對這些輸入資料的預期輸出結果。如果對測試輸入資料沒有給出預期的程式輸出結果，那麼就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。
***3***程式設計師應避免檢查自己的程式。
測試工作需要嚴格的作風，客觀的態度和冷靜的情緒。人們常由於各種原因具有一種不願否定自己工作的心理，認為揭露自己程式中的問題總不是一件愉快的事。這一心理狀態就成為測試自己程式的障礙。另外，程式設計師對軟體規格說明理解錯誤而引入的錯誤則更難發現。如果由別人來測試程式設計師編寫的程式，可能會更客觀，更有效，並更容易取得成功。要注意的是，這點不能與程式的除錯***debuging***相混淆。除錯由程式設計師自己來做可能更有效。
***4***在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。
合理的輸入條件是指能驗證程式正確的輸入條件，而不合理的輸入條件是指異常的，臨界的，可能引起問題異變的輸入條件。在測試程式時，人們常常傾向於過多地考慮合法的和期望的輸入條件，以檢查程式是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟體在投入執行以後，使用者的使用往往不遵循事先的約定，使用了一些意外的輸入，如使用者在鍵盤上按錯了鍵或打入了非法的命令。如果開發的軟體遇到這種情況時不能做出適當的反應，給出相應的資訊，那麼就容易產生故障，輕則給出錯誤的結果，重則導致軟體失效。因此，軟體系統處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸入條件測試程式時，往往比用合理的輸入條件進行測試能發現更多的錯誤。
***5***充分注意測試中的群集現象。
測試時不要以為找到了幾個錯誤問題就已解決，不需繼續測試了。經驗表明，測試後程序中殘存的錯誤數目與該程式中已發現的錯誤數目或檢錯率成正比。根據這個規律，應當對錯誤群集的程式段進行重點測試，以提高測試投資的效益。
在所測程式段中，若發現錯誤數目多，則殘存錯誤數目也比較多。這種錯誤群集性現象，已為許多程式的測試實踐所證實。例如美國IBM公司的0s/370作業系統中，47 9/6的錯誤僅與該系統的4%的程式模組有關。這種現象對測試基於不同的立場，存在著兩種完全不同的測試目的。從使用者的角度出發，普遍希望通過軟體測試暴露軟體中隱藏的錯誤和缺陷，以考慮是否可以接受該產品。而從軟體開發者的角度出發，則希望測試成為表明軟體產品中不存在錯誤的過程，驗證該軟體已正確地實現了使用者的要求，確立人們對軟體質量的信心。因此，他們會選擇那些導致程式失效概率小的測試用例，迴避那些易於暴露程式錯誤的測試用例。同時，也不會著意去檢測、排除程式中可能包含的副作用。
顯然，這樣的測試對完善和提高軟體質量毫無價值。因為在程式中往往存在著許多預料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環境下才可能暴露出來。如果不把著眼點放在儘可能查詢錯誤這樣一個基礎上，這些隱藏的錯誤和缺陷就查不出來，會遺留到執行階段中去。如果站在使用者的角度，替他們設想，就應當把測試活動的目標對準揭露程式中存在的錯誤。在選取測試用例時，考慮那些易於發現程式錯誤的資料。
***6***嚴格執行測試計劃，排除測試的隨意性。
測試計劃應包括：所測軟體的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方式和過程，系統組裝方式，跟蹤規程，除錯規程，以及迴歸測試的規定等以及評價標準。
***7***應當對每一個測試結果做全面檢查。
這是一條最明顯的原則，但常常被忽視。有些錯誤的徵兆在輸出實測結果時已經明顯地出現了，但是如果不仔細地全面地檢查測試結果，就會使這些錯誤被遺漏掉。所以必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住徵候，暴露錯誤。
***8***妥善儲存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。
很有用。如果發現某一程式模組似乎比其他程式模組有更多的錯誤傾向時，則應當花費較多的時間和代價測試這個程式模組。