隨著網際網路進入開源的時代。市場上的各路產品就競爭進入了一個更加嚴峻的挑戰時代。各個產品各個理念像奇蹟一樣不斷的充斥著市場，分割著市場。人們的選擇性更多,要求越來越高。隨著資料不斷的增長，對於軟體處理這些龐大資料的整體性結構就給出了一定的挑戰。面對龐大的資料和複雜的結構，如何能夠保證產品的質量，降低在市場上的風險成了棘手的問題。產品質量存在的問題不外乎人和技術所產生的原因。

    對於人本身來講，人們的想法、看法、思想、能動性、學習性、認知力等等都會隨著時間的增加和環境的變化而改變，人們所經歷每一分每一秒都可能影響工作的主動性和積極性。年齡越大經驗越豐富，但是年齡本身也是一個容易產生問題的因素。隨著年齡的增長，人的主動性會隨著日益更新而更新，還是會隨著沉澱而變得懶散，這就要看個人本身對自己的要求是怎樣的。所有這些隱性的因素都滲透在人們每天的日常工作中。

   技術本來就是要靠人去實現的。軟體開發原本就是一個高技術含量的工作，需要技術人員時刻都要保持清醒的頭腦、縝密的思維和高度思考。但不幸的是，這些潛在的問題都在一點點影響著軟體的質量。如果說產品存在這樣那樣的缺陷，不如說人本身就先天存在這樣那樣的缺陷。在說技術吧，每個人跟每個人年齡不同、經驗不同、IQ不同等等都明顯的產生了差異。有編碼好的，有編碼差的。編出來的東西五花八門。在加上不同的架構不同的語言等等都在製造著無限的缺陷。

    因為缺陷的產生，便有了質量保證。產品在進入市場以前，這就是個關卡。也是最重要的部分。但是它只能是一個關口嗎？我覺得它可以是一個帶關卡的橋樑。因為它既可以做到給前方市場人員補給，給後方開發人員提供支援。

    如果我們仔細看看軟體開發的方法，會發現軟體開發由重量級開發不斷的在像輕量級演變。隨著開發時間的縮短和快速釋出，使得軟體質量在短期內很難得到保障。又因為輕量級的開發過程沒有對大量正式文件有過多的要求，這便隱形的提升了軟體後期潛在巨大的風險。

     通過以往的測試工作我們會發現，隨著軟體需求不斷的被大量快速更新，而文件又不充分的條件下。新加入的開發人員會出現無從入手的情況，因為沒有舊文件的指引，外加上因為開發時間縮短而產生的培訓不足的問題。我相信從開發人員對基本的設計都無從下手的時候，這一刻想法的產生就為缺陷的誕生奠定了基礎。在本來就時間有限的前提下，在加上文件的不健全，bug會容易呈現幾何數字的增長。

     如果在這種條件下，質量保證只是一個關卡的話。對於開發的開銷就會大大增加，因為改bug需要時間，需要金錢，當一個產品還在製造的過程中，市場上就已經出現了新的產品。無論是時間的增長開發的時間或是開發人員的增加，都無疑是加大成本d和市場快速競爭力的風險。尤其是在這個開源的時代。

      輕量級開發雖然帶來的一定的問題，但是它可以讓只有關卡的質量保證更加靈活到成為一個帶關卡的橋樑。使得測試工作達到輕量級優化。著名的輕量級開發方法極限程式設計（XP）。因為它的內層的過程是一個個基於測試驅動的開發（TestDrivenDevelopment）週期，諸如計劃和設計等外層的過程都是圍繞這些展開的。每個開發週期都有很多相應的單元測試（UnitTest）。剛開始，因為什麼都沒有實現，所以所有的單元測試都是失敗的；隨著一個個小的需求模組的完成，通過的單元測試也越來越多。通過這種方式，客戶和開發人員都很容易檢驗，是否履行了對客戶的承諾。XP提倡對於簡單的設計（SimpleDesign），就是用最簡單的方式，使得為每個簡單的需求寫出來的程式可以通過所有相關的單元測試。XP強調拋棄那種一攬子詳細設計方式（BigDesignUpFront），因為這種設計中有很多內容是你現在或最近都根本不需要的。XP還大力提倡設計走查（Review）、程式碼走查以及重構（Refectory），所有的這些過程其實也是優化設計的過程；在這些過程中不斷執行單元測試和功能測試，可以保證經過重整和優化後的系統仍然符合所有需求。

      而且這種以測試驅動開發的好處就是可以在推動開發的同時檢查程式碼的質量。因為XP就提倡在開始寫程式之前先寫單元測試。開發人員應該經常把開發好的模組整合到一起（ContinuousIntegration），每次整合後都要執行單元測試；做任何的程式碼走查和修改，都要執行單元測試；發現了BUG，就要增加相應的測試（因此XP方法不需要BUG資料庫）。

       除了測試驅動開發，還有通過cucumber來實現的以需求為基準的行為驅動開發（BDD）。行為驅動開發是測試驅動開發的進化，但關注的核心是設計。以定義系統的行為為主要工作，而對系統行為的描述則變成了測試標準。在行為驅動開發中，使用通用語言來定義系統行為。而通用語言，實際上是一個最小化的詞彙表。我們使用這些詞彙來書寫故事。選入詞彙表的詞彙必須具有準確無誤的表達能力和一致的含義。將需求變成一個個故事，逐條生成測試點，然後在通過這些測試點做進一步開發。

       從測試入手引導開發，這樣子不僅可以隨時跟蹤程式碼的狀況，也可以隨時掌握開發的進度和功能的覆蓋率。相對於開發出成品在進行功能的一個覆蓋率檢查來講更加有效率。也可以隨時隨地的讓開發能夠在工作的時候保持清醒的頭腦。

      單元測試無論是前端的頁面也好，還是後面的邏輯處理也好。每一個層都有相對應單元測試工具。例如：js 單元測試軟體可以有phantomjs來測試，html有html unit等等。如果每一層都能做好有效的單元測試，至少對程式碼的健壯性、後期程式碼的重構等等都會起到一定的效果。但是這就要求測試人員有很高的編碼功底，至少要有5-10年以上的開發經驗，也同時要熟悉軟體測試的基礎理論。測試如果能幫助開發做一些工作上的幫助，這樣就可以大大支援開發的工作和時間上的節省。這就實現了根本的有測試驅動的開發的價值和意義。在成本上也可以進行一定的節省。

       雖然單元測試很重要，但是我們也需要通過整合測試、效能測試、安全測試和功能測試這些測試對成型後的產品進行進一步檢查。整合測試、效能測試和安全測試都需要測試人員具有紮實的理論基礎和廣泛的知識基礎。

       功能測試是測試中最基本也是最常用的測試方法。UI的功能測試通常分為手動和自動兩種。手動是最接近使用者真實使用軟體的一種測試方法。而自動化是模擬手工來對ui進行測試的。無論這兩種測試使用哪一種，都會面臨一個問題，那就是投資回報率(return on investment，ROI)過低。

       尤其是對於敏捷開發流程來講。因為在進行手動測試之前要準備測試文件，準備文件需要時間，執行文件需要時間，在最初功能還不是很多的時候，這個時間可以充足，但是在隨著功能不斷的複雜化的時候，每一輪的迴歸測試都會隨著時間的增加而增加。對於手動測試來說這還算是好的，如果是自動化的話那就要崩潰了。因為軟體在最初的時候穩定性很差。無法把大量時間都用來寫測試指令碼。但是也不是沒有可以解決的辦法，可以通過badboy進行指令碼錄製，邊測試邊錄製指令碼。這些指令碼還可以與jmeter結合用於效能測試。在alpha測試階段，公司內部測試的時候。功能的手動測試可以結伴測試，幾個人一組模擬真實的使用者場景，通過不同平臺進行結伴測試。效率可以大大提升，出現問題相互之間可以一起討論，共同進步。

       對於一般的提供於企業內部使用的軟體來講，beta測試是通過終端使用者來測試的。但是如果是電子商務、即時通訊這樣的產品，很難要求使用者來測試。遊戲產品的話可以公測。這個時候我們就需要新的測試理念。

        在工作中，我總結出一種測試方法，叫做：“推廣式測試”。通過推廣產品的方式，與使用者一起互動找出產品重要的潛在的缺陷，很準確的知道市場上使用者的真實使用場景，第一時間得到反饋，能快速定位出軟體出現的嚴重錯誤和使用者對需求不滿意的地方，也可以很好的體現出公司的服務質量，不至於讓使用者覺得產品出了問題沒人受理的感覺。

       這種方式可以有效幫助企業的產品度過市場磨合期的風險期，大幅度的提升企業的產品在市場上後期需求改進的精準度。此測試方式將產品推廣出去，所以有效的控制了產品在市場中的競爭力。尤其是降低新產品新理念投放市場後在被客戶認可的過程中存在的風險和阻力。也很好的推動產品設計和開發的工作。通過這種測試我們可以發現當軟體存在某些缺陷，但無法在短暫的時間內通過技術來彌補的時候，可以找尋藉助其他媒介彌補這些缺陷。例如：百度問答，部落格使用說明書等等。

在這個測試過程當中，可以一點點的把功能寫成詳細的說明書。通過這個說明書將散亂的需求整理出來，而這份說明書不僅可以提供給開發人員用於對新員工的培養或者用於他們自己，也可以提供給銷售，隨時瞭解產品的最新進展，這便實現前方銷售補給。

         在功能測試前，都會面臨一個很大的問題，那就是需求文件的整理。在快速、複雜、無頭緒的需求文件面前我們如何有效的跟進，又能夠提高工作效率，不防試試xmind的思維導圖。橫掃一切煩惱，可以達到準確、快速、及時的需求更新、篩選、規劃。然後將現有定型的模組整理到測試用例中作為永久儲存。大幅度提升測試人員日工作效率。

         在功能測試的時候又想知道覆蓋率的情況，但又不想寫過多複雜的內容，可以使用以功能點為主的覆蓋率表。將每一個功能點出現的bug都能有效的整理出來，並且直觀的看到每個功能的情況都是如何。

         以上便是我通過閱讀大量書籍、查閱大量資料，學習、實踐、整理出來。有些東西也許看的不是很準確，理解也不是很透徹。但是也不是空穴來風，無從根據隨便講。一寸光陰一寸金，寸金難買寸光陰。你的一秒鐘失去便是他人一秒鐘的獲得。比爾蓋茨說的對“This is a fantastic time to join the business world,because business will change in the next ten years more than it has changed for the last fifity years.”

https://www.linkedin.com/pulse/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95%E8%B4%A8%E9%87%8F%E4%BF%9D%E8%AF%81%E4%B9%8B%E6%88%91%E8%A7%81-jin-song?trk=hp-feed-article-title-publish