測試概述
軟體測試的目的，一方面是為了檢測出軟體中的Bug,另一方 面是為了檢驗軟體系統是否滿足需求。
然而，在傳統的軟體開發企業中，測試工作往往得不到技術人員的足夠重視。隨著Web應用的興起，特別是以微服務為代表的分布式系統的發展，傳統的測試技術也面臨著巨大的變革。
傳統的測試所面臨的問題
總結起來，傳統的測試工作主要面臨以下問題。
1.開發與測試對立
在傳統軟體公司組織結構裡面，開發與測試往往分屬不同部門，擔負不同的職責。開發人員為了實現功能需求，從而生產出代碼;測試人員則是為了查找出更多功能上的問題，迫使開發人員返工，從而對代碼進行修改。表面上看，好像是測試人員在給開發人員「找茬」，無法很好地相處，因此開發與測試的關係處於對立。
2.事後測試
按照傳統的開發流程,以敏捷開發模式為例，開發團隊在迭代過程結束過後，會發布一個版本，以提供給測試團隊進行測試。由於在開發過程中，迭代周期一般是以月計，因此從輸出一個迭代，
到這個迭代的功能完全測試完成，往往會經歷數周時間。也就是說，等到開發人員拿到測試團隊的測試報告時，報告裡面所反饋的問題，極有可能已經距離發現問題一個多月 了。別說讓開發人員去看一個月前的代碼，即便是開發人員自己在一個星期前寫的代碼，讓他們記憶起來也是挺困難的。
開發人員不得不花大量時間再去熟悉原有的代碼，以查找錯誤產生的根源。
所以說，對於測試工作而言，這種事後測試的流程，時間間隔得越久，修復問題的成本也就越高。
3.測試方法老舊
很多企業的測試方法往往比較老舊，無法適應當前軟體開發的大環境。很多企業測試職位仍然是屬於人力密集型的，即往往需要進行大量的手工測試。手工測試在整個測試過程中必不可少，但如果手工測試比重較大，往往會帶來極大的工作量，而且由於其機械重複性質，也大大限制了測試人員的水平。測試人員不得不處於這種低級別的重複工作中，無法發揮其才智，也就無法對企業的測試提出改進措施。
4.技術發生了巨大的變革
網際網路的發展急劇加速了當今計算機技術的變革。當今的軟體設計、開發和部署方式，也發生了很大的改變。隨著越來越多的公司從桌面應用轉向Web應用，很多風靡一時的測試書籍裡面所提及的測試方法和最佳實踐，在當前的網際網路環境下效率會大大下降，或者是毫無效果，甚至起了副作用。
5.測試工作被低估
大家都清楚測試的重要性，一款軟體要交付給用戶，必須要經過測試才能放心。但相對於開發工作而言，測試工作往往會被「看低一等」 ，畢竟在大多數人眼裡，開發工作是負責產出的，而測試往往只是默默地工作在背後。大多數技術人員也心存偏見，認為從事測試工作的人員，都是因為其技術水平不夠，才會選擇做測試職位。
6.發布緩慢
在傳統的開發過程中，版本的發布必須要經過版本的測試。由於傳統的測試工作採用了其事後測試的策略，修復問題的時間周期被拉長了，時間成本被加大了，最終導致產品發布的延遲。延期的發布又會導致需求無法得到客戶及時的確認，需求的變更也就無法得到提前實現，這樣，項目無疑就陷入了惡性循環的「泥潭」。
如何破解測試面臨的問題
針對上面所列的問題，解決的方法大致歸納為以下幾種。
1.開發與測試混合
在How Google Tests Sofiware-一文中，關於開發、測試及質量的關係，表述為:「質量不等於測試。當你把開發過程和測試放到一起，就像在攪拌機裡混合攪拌那樣，直到不能區分彼此的時候，你就得到了質量。
這意味著質量更像是一種預防行為， 而不是檢測。質量是開發過程的問題，而不是測試問題。
所以要保證軟體質量，必須讓開發和測試同時開展。開發一段代碼就 立刻測試這段代碼，完成更多的代碼就做更多的測試。
在Google公司有一個專門的職位，稱為「軟體測試開發工程師( Software Engineer inTest)」，簡稱SET。Google 認為，沒有人比實際寫代碼的人更適合做測試，所以將測試納入開發過程，成為開發中必不可少的一部分。當開發過程和測試一起聯合時，即是質量達成之時。
2.測試角色的轉變
在GTAC 2011大會上，James Whittaker和Alberto Savoia發表演講，稱為「Test is Dead (測試已死)」。當然，這裡所謂的「測試已死」並不是指測試人員或測試工作不需要了，而是指傳統的測試流程及測試組織架構要進行調整。測試的角色已然發生了轉變，新興的軟體測試工作也不再只是傳統的測試人員的職責了。
在Google,負責測試工作的部門稱為「工程生產力團隊」，他們推崇「You build it, you breakit, you fix it!"的理念，即自己的代碼所產生的Bug需要開發人員自己來負責。這樣，傳統的測試角色將會消失，取而代之的是開發人員測試和自動化測試。與依賴於手工測試人員相比，未來的軟體團隊將依賴內部全體員工測試、Beta 版大眾測試和早期用戶測試。
測試角色往往是租賃形式的，這樣就可以在各個項目組之間流動，而且測試角色並不承擔項目組主要的測試任務，只是給項目組提供測試方面的指導，測試工作由項目組自己來完成。這樣保證了測試角色人員比較少，並可以最大化地將測試技術在公司內部蔓延。
3.積極發布，及時得到反饋
在開發實踐中推崇持續集成和持續發布。持續集成和持續發布的成功實踐，有利於形成「需求開發集成測試部署」的可持續的反饋閉環，從而使需求分析、產品的用戶體驗及互動設計、開發、測試、運維等角色密切協作，減少了資源的浪費。
一些網際網路的產品，甚至打出了「永遠Beta版本」的口號，即產品在沒有完全定型時就直接上線交付給了用戶使用，通過用戶的反饋來持續對產品進行完善。特別是一些開源的 、社區驅動的產品，由於其功能需求往往來自真正的用戶、社區用戶及開發者,這些用戶對產品的建議往往會被項目組所採納，從而納入技術。比較有代表性的例子是Linux和GitHub。
4.增大自動化測試的比例
最大化自動測試的比例有利於減少企業的成本，同時也有利於測試效率的提升。
Google刻意保持測試人員的最少化，以此保障測試力量的最優化。最少化測試人員還能迫使開發人員在軟體的整個生命期間都參與到測試中，尤其是在項目的早期階段:測試基礎架構容易建立的時候。
如果測試能夠自動化進行，而不需要人類智慧判斷，那就應該以自動化的方式實現。當然有些手工測試仍然是無可避免的，如涉及用戶體驗、保留的數據是否包含隱私等。還有一些是探索性的測試，往往也依賴於手工測試。
5.合理安排測試的介入時機
測試工作應該及早介入，一般認為,測試應該在項目立項時介入，並伴隨整個項目的生命周期。
在需求分析出來以後，測試不止是對程序的測試，文檔測試也是同樣重要的。需求分析評審的時候,測試人員應該積極參與，因為所有的測試計劃和測試用例都會以客戶需求為準繩。需求不但是開發的工作依據，同時也是測試的工作依據。
測試的類型和範圍
在當今的網際網路開發模式中，雖然傳統的測試角色已經發生了巨大的變革，但就其測試工作而言，其本質並未改變，其目的都是檢驗軟體系統是否滿足需求，以及檢測軟體中是否存在Bug。下面就對常用的測試方案做下探討。
測試類型
圖4-1展示的是一個通用性的測試金字塔。
在這個測試金字塔中，從下向上形象地將測試分為不同的類型。
1.單元測試
單元測試是在軟體開發過程中要進行的最低級別的測試活動，軟體的獨立單元將在與程序的其他部分相隔離的情況下進行測試。
單元測試的範圍局限在服務內部，它是圍繞著- -組 相關聯的案例編寫的。例如，在C語言中，單元通常是指一-個函數; 在Java等面向對象的程式語言中,單元通常是指一個類。所謂的單元，就是指人為規定的最小的被測功能模塊。因為測試範圍小，所以執行速度很快。
單元測試用例往往由編寫模塊的開發人員來編寫。在TDD ( Test Driven Development, 測試驅動開發)的開發實踐中，開發人員在開發功能代碼之前，就需要先編寫單元測試用例代碼，測試代碼確定了需要編寫什麼樣的產品代碼。TDD在敏捷開發中被廣泛採用。
單元測試往往可以通過xUnit等框架來自動化進行測試。例如，在Java平臺中，JUnit 測試框( htt:nit.rg/ )已是用於單元測試的事實上的標準。
2.集成測試
集成測試主要用於測試各個模塊能否正確交互，並測試其作為子系統的交互性，以查看接口是否存在缺陷。
集成測試的目的在於，通過集成模塊檢查路徑暢通與否，來確認模塊與外部組件的交互情況。
集成測試可以結合CI (持續集成)的實踐，來快速找到外部組件間的邏輯回歸與斷裂，從而有助於評估各個單獨模塊中所含邏輯的正確性。
集成測試按照不同的項目類型，有時也細分為組件測試、契約測試等。例如，在微服務架構中,微服務中的組件測試是使用測試替代與內部API端點通過替換外部協作的組件，來實現對各個組件的獨立測試。組件測試提供給測試者- -個受控的測試環境，並幫助他們從消費者角度引導測試，允許綜合測試，提高測試的執行次數，並通過儘量減少可移動部件來降低整體構件的複雜性。組件測試也能確認微服務的網絡配置是否正確，以及是否能夠對網絡請求進行處理。而契約測試會測試外部服務的邊界，以查看服務調用的輸入/輸出，並測試該服務能否符合契約預期。
3.系統測試
系統測試用於測試集成系統運行的完整性，這裡面涉及應用系統的前端界面和後臺數據存儲。
該測試可能會涉及外部依賴資源，如資料庫、文件系統、網絡服務等。系統測試在一些面向服務的系統架構中被稱為「端到端測試」。因此在微服務測試方案中，端到端測試佔據了重要的角色。在微服務架構中有一些執行相同行為的可移動部件，端到端測試時需要找出覆蓋缺口，並確保在架構重構時業務功能不會受到影響。
由於系統測試是面向整個系統來進行測試的，因此測試的涉及面將更廣，所需要的測試時間也更長。.
測試範圍及比例
1.測試範圍
不同的測試類型，其對應的測試範圍也是不同的。單元測試所需要的測試範圍最小，意味著其隔離性更好，同時也能在最快的時間內得到測試結果。單元測試有助於及早發現程序的缺陷，降低修復的成本。系統測試涉及的測試範圍最廣，所需要的測試時間也最長。如果在系統測試階段發現缺陷，則修復該缺陷的成本自然也就越高。
在Google公司,對於測試的類型和範圍，一般按照規模劃分為小型測試、中型測試、大型測試，也就是平常理解的單元測試、集成測試、系統測試。
小型測試:小型測試是為了驗證一個代碼單元的功能，一般 與運行環境隔離。小型測試是所有測試類型裡範疇最小的。在預設的範疇內，小型測試可以提供更加全面的底層代碼覆蓋率。小型測試中外部的服務，如文件系統、網絡、資料庫等，必須通過mock或fake來實現。這樣可以減少被測試類所需要的依賴。小型測試可以擁有更加頻繁的執行頻率，並且可以很快發現問題並修復問題。
●中型測試:中型測試主要是用於驗證多個模塊之間的交互是否正常。一般情況下，在Google由SET來執行中型測試。對於中型測試，推薦使用mock來解決外部服務的依賴問題。有時出於性能考慮，在不能使用mock的場景下，也可以使用輕量級的fake。
大型測試:大型測試是在一個較高的層次 上運行的，以驗證系統作為一個整體是否工作正常。
2.測試比例
每種測試類型都有其優缺點，特別是系統測試，涉及的範圍很廣，花費的時間成本也很高。所以在實際的測試過程中，要合理安排各種測試類型的測試比例。正如測試金字塔所展示的，越是底層，所需要的測試數量將會越大。那麼每種測試類型需要佔用多大的比例呢?實際上，這裡並沒有一個具體的數字，按照經驗來說，順著金字塔從上往下，下面一層的測試數量要比上面一層的測試數量多出-一個數量級。
當然，這種比例也並非固定不變的。如果當前的測試比例存在問題，那麼就要及時調整並嘗試不同類型的測試比例，以符合自己項目的實際情況。
本篇給大家介紹的內容是如何破解測試所面臨的問題、測試的類型和範圍兩塊內容！
1.下篇內容給大家介紹如何進行微服務的測試;
2.覺得文章還不錯的朋友，可以轉發關注小編一下;
3.感謝大家的支持！！