隨著VUCA（易變性、不確定性、複雜性、模糊性）時代的到來與網際網路的高速發展，質量保障人員面臨著前所未有的挑戰。

測試崗位的職責越來越細化，測試人員的工作邊界也越來越模糊，研發、測試和運維角色都在推動 DevOps 和 TestOps 的發展。

在和測試同行交流的過程中 , 我們發現很多人非常焦慮，找不清發展的方向，尤其是工作四五年之後一直還在做系統測試的人，就更為焦慮。

2017 年年末，作者所在的京東質量團隊在進行年終總結時欣喜地發現，自團隊從測試到測試開發轉型這一年來，整體測試水平得到了大幅度提升 , 測試人員在研發團隊中的影響力也進一步擴大。

從系統測試工程師逐漸轉型升級為測試開發工程師，轉型過程中的艱辛不言而喻，在轉型中除了技能的提高之外，更多的是獲得了一種自信

。

 

掃碼購書哦

本書不僅展示京東質量團隊從測試到測試開發的心路歷程，更是整個過程中從思想準備到實踐努力再到成功推進的思考和總結。

本書適合有一定工作經驗的測試人員閱讀，對從測試轉型測試開發的人員具有指導意義。本書同樣適合測試經理、測試總監和測試架構師閱讀。書中的例子和故事均為團隊轉型中遇到的真實案例。我們歷經各種辛酸才能走出一條路，希望本書能給讀者一些啟發和幫助。

軟體測試

首先要明確一個概念，“質量”是整個團隊的責任而不是僅僅靠團隊測試人員就能夠明顯改善的。測試的目的是什麼？測試不是要證明系統或者軟體沒有問題，恰恰相反，而是要證明其存在問題。

通過測試可以發現缺陷，但不能保證軟體或者系統的缺陷全部被找到。在有限的時間和資源條件下，想要進行完全的測試，找出軟體或者系統所有的缺陷，使之達到完美，是不可能的。

此外，測試也是有成本的，越到測試後期，，為發現缺陷所付出的代價就會越大，因此要根據測試錯誤的概率及軟體的可靠性要求， 確定停止測試的最佳時間，不能無限地測試下去。除此之外，所有的測試都應追溯到使用者需求，這是因為軟體或者系統的最終目的是滿足使用者需求。

1.1.1 什麼是軟體測試

1983 年，Bill Hetzel  在《軟體測試完全指南》一書中指出：“測試是以評價一個程式或者系統屬性為目標的任何一種活動， 測試是對軟體質量的度量。”Bill Hetzel 的定義至今仍被引用。

1991 年，軟體產品質量評價國際標準 ISO 9126 定義的“軟體質量”是：軟體滿足規定或潛在使用者需求特性的總和。

1999 年，軟體產品評價國際標準ISO 14598 對“軟體質量”的定義是： 軟體特性的總和，軟體滿足規定或潛在使用者需求的能力。

2001 年，軟體產品質量國際標準ISO 9126 定義的“軟體質量”包括內部質量、外部質量和使用質量 3 個部分， 也就是說，“軟體滿足規定或潛在使用者需求的能力”要根據軟體在內部、外部和使用中的表現來衡量。

《軟體評測師教程》（柳純錄主編，清華大學出版社）這本軟體評測師考試輔導書對軟體測試和質量保證做了詳細的區分和描述：測試工程師的一項重要任務是提高軟體質量，但不等於說測試工程師就是軟體質量保證人員，因為測試只是質量保證工作中的一個環節。

測試工程師並不生產質量，質量的生產者還是開發工程師。質量保證和軟體測試是軟體質量工程中兩個不同層面的工作。

質量保證：質量保證的主要工作是通過預防、檢查與改進來保證軟體質量。

QA 基於“全面質量管理”和“過程改進”原理開展質量保證工作。雖然在 QA 的活動中也有一些測試活動，但其所關注的是軟體質量的檢查與測量。QA 的工作是對軟體生命週期的管理，以及驗證軟體是否滿足規定質量和使用者需求的過程，因此主要著眼於軟體開發活動中的過程、步驟和產物，而不是對軟體進行剖析以找出問題或評估。

雖然測試與開發過程緊密相關，但軟體測試關心的不是過程的活動，重點要對過程的產物及開發出的軟體進行剖析。測試人員要“執行”軟體，對過程的產物— 開發文件和原始碼進行走查，執行軟體，以找出問題，提升質量。

測試人員必須假設軟體存在潛在的問題，測試中所進行的操作是為了找出更多的問題，而不僅僅是為了驗證每一件事是正確的。對測試中發現的問題進行分析、追蹤與迴歸測試也是軟體測試的重要工作，因此軟體測試是保證軟體質量的一個重要環節。

在 20 世紀 90 年代，隨著測試工具的盛行，測試工程師逐漸意識到通過強化工具來解決問題的重要性，工具思維在測試工程師的心裡已經變成了思考問題的重要方式，但是這裡的工具思維是指使用工具的思維，還沒有出現創造工具的思維。

軟體測試是一項旨在保障軟體質量的服務，軟體測試只能證明一個軟體存在缺陷，卻不能證明一個軟體沒有缺陷。

隨著生命週期成熟度的提升，以及持續整合乃至開發運維的變遷，軟體測試不僅旨在保證軟體的質量，保證軟體質量、提高交付頻率變成了相輔相成的目標。保證軟體的質量是基礎目的，提高交付頻率是根本目的。

軟體測試是為了尋找軟體的缺陷和錯誤，提高軟體的質量和交付頻率，因此所有軟體測試都應該可以溯源到使用者需求，無論是使用者明確的顯性需求，還是一些系統安全、系統相容、效能等的隱性需求。

1.1.2 業務測試

如今，人們通過網路可以方便地購買各種各樣的物品，除了實物之外，還有各種虛擬物品，如飛機票、火車票和電影票等。與此同時，人們還可以很方便通過網路繳納生活中所需要的各種費用，如手機充值，繳納電費和水費等。

從物品的查詢，到使用者支付成功，最後到使用者收到物品（或者充值面值的篩選， 充值成功），這一系列流程都屬於電子商務的一個具體業務，那麼如何進行業務測試呢？筆者所在團隊主要從事電商網站的虛擬業務的功能測試，下面就筆者所在團隊的工作內容展開詳細介紹。

業務測試的側重點在業務流程上，在基本功能點都已合格的基礎上，準備並組合多種測試資料，驅動或輔助在各種約束條件下的業務流程測試，確定最終輸出的結果是否符合預期。

業務測試多數要結合實際業務邏輯，黑盒、白盒、灰盒這些測試方法都可以用來輔助測試。業務測試並不能單單滿足於功能實現，更要站在真實使用者使用的角度提出問題、給出建議，從而優化程式。

如何開展業務測試呢？測試前置在行業內越來越多地被提及，在功能測試中， 測試也應做到前置，不能等到系統全部提測了再介入測試。

1．需求測試

越早發現缺陷，修復缺陷的成本就越低，那麼缺陷最早能在什麼時候被發現呢？ 毫無疑問，在需求最早提出的時候。當一個需求被提出時，測試人員不能認為提出的需求是完全正確、沒有問題的，需要對需求設計的正確性、合理性及實施性進行測試，儘早發現需求中的問題並跟進解決。

在需求階段發現問題的修復成本很低，也是在源頭保證質量的有效手段。需求測試如圖 1-1 所示。

圖 1-1需求測試圖

2．設計測試

需求測試結束，問題得到解決，需求被確定下來後，就進入了設計階段。此階段分成兩部分：一是開發人員進入設計階段，二是測試人員進入設計階段。

開發人員的設計階段不在此處討論。除包含常規的測試計劃、測試用例和測試準備等工作外，測試人員的設計應同時包含對系統的設計。

介紹到這裡，肯定有讀者會有疑問：開發人員已經在進行系統設計，測試人員再進行系統設計是不是多此一舉？測試人員的設計會不會得到認同？

其實， 測試人員的設計要求不同於開發人員的設計要求，不對具體形式做要求，此處測試人員進行系統設計的意義在於讓測試人員對即將被測的系統有一個自己獨立的思考過程，只有測試人員自己也對需求進行相應的獨立的系統設計，才能找到開發人員設計的問題，將測試工作前置，降低缺陷修復的成本。

設計測試應注重檢查系統設計的 3 個特性，如圖 1-2 所示。

必要性：每處設計要有目的，要為滿足需求而設計，不能存在無謂的設計。

正確性：檢查每處設計是否正確、合理，是否能夠實現想要實現的功能。

最優性：檢查每處設計是否為相對簡單、高效的設計。

圖 1-2 設計測試圖

3．過程測試

過程測試是功能測試的重點，也是集中發現缺陷的階段。在系統測試開始之前， 測試人員需要完成測試資料的準備，以及測試計劃、測試用例的設計，並經過專案組成員評審通過。評審過程有兩個目的：一是彌補測試設計中遺漏的地方，二是專案組成員達成共識，認可測試設計以避免後期不必要的麻煩。

在過程測試的實施過程中，筆者所在團隊採用了分層測試、外部解耦、流程模擬等手段保證系統質量，如圖 1-3 所示。

圖 1-3 過程測試圖

（1）分層測試

分層測試強調測試的層次感。讀者可能有過這種感覺，有層次感的麵包比一般的麵包口感更好。筆者所在部門基於分層測試的思想將整個被測系統按照資料層、API 層、UI 層進行分割，這樣做的優勢是什麼呢？

測試提前介入是所有專案都提倡的，目的是把問題攔截在前期，降低問題修復成本。

分層測試不依賴於完整系統，可以通過直接呼叫底層介面進行測試，這樣就不需要等到整個系統開發完成才能測試。

其實，分層測試的思想和自底向上的系統開發模式是不謀而合的。

分層測試同時能夠體現出精準性：我們都知道，離問題產生的地方越近，就越容易觸發問題。

分層測試的切入點就是層與層之間的介面，從機制上更接近出問題的地方， 因此更容易命中目標，也能直接或間接地降低修復成本。

分層測試如圖 1-4 所示。

圖 1-4分層測試

資料層測試：資料層測試首先對資料庫中的原始資料及聚合資料的準確性進行驗證，如精度、數量、儲存有無丟失等，在保證這一層質量後進入下一層測試。

API 層測試：首先需要強調，API 層測試也是功能測試的一部分。通過介面呼叫驗證伺服器返回的資料是否準確，伺服器端可能會將資料進行運算並返回。通過 API 層驗證保證資料傳輸的準確性，保證介面層通過測試後進入下一層測試。

UI  層測試：通過覆蓋系統所有邏輯路徑保證資料展示層的正確。

（2）外部解耦

外部依賴有時是阻礙測試進度的一個主要原因，但是一個系統的執行往往離不開外部系統的依賴，如網路環境、訊息依賴和資料依賴等。

測試過程中如何降低系統間的耦合度是高效進行測試的關鍵。

作者所在部門通過 MQ（訊息佇列）訊息自動傳送元件模擬外部依賴訊息，可以解決訊息依賴問題，降低耦合度。

該工具適用於筆者所在部門的整個業務，如利用該工具模擬機票業務出退票訊息， 成功擺脫訊息依賴，使測試效率及準確性大大提升。

（3）流程模擬

在系統測試過程中，往往有些極端情景或流程很難模擬，或者由於測試環境、資料量不足等原因導致無法進行模擬的情況。然而，這些情景或流程有時又非常重要， 這就造成測試覆蓋不全的情況發生。

筆者所在部門從穿線測試理論得到靈感，對流程主資訊進行標記追蹤，根據不同情況將流程引導至設定的極端情況中，覆蓋極端情況，驗證系統處理能力，很好地解決了這一難題。

4．使用者體驗

在保證系統邏輯功能正確的基礎上，還要對使用者體驗進行測試。由於電商網站的特點，使用者體驗非常重要，因此筆者所在公司對使用者體驗非常重視。

好的使用體驗不僅可以留住使用者，而且能夠提升購物轉換率，為公司帶來實際的效益。在實際專案中，使用者體驗可以從以下幾方面考慮。

（1）應用性

應用性要考慮是否符合使用者的實際應用場景，這就要求針對受眾使用者群體，考慮他們的年齡、學歷、技能和職業等因素，要具備通用性。

（2）易用性

易用性要檢查是否容易理解、是否容易學習、是否容易操作。例如，用詞一定要簡單和易理解，不能專業性太強，降低使用者的理解難度；操作要簡潔，不要過於煩瑣， 減少使用者的抵觸情緒，最好做到不需要使用者過多思考就可以直接操作。

（3）少選擇

給使用者的選擇要儘量少，即介面的選單、按鈕、選擇項越少越好，減少使用者的困惑。除此之外，還要在流程、規範上保證系統質量。

例如，測試固有流程規範保證每個環節結果真實，有據可依；異常流程緊急處理規範使工作高效進行；自動化程式碼編寫、執行規範使程式碼自動化、易維護、易執行；功能測試執行規範且嚴格執行， 做到對線上環境零影響，使專案合規率達到 100%。

5．介面測試

介面是電商網站與使用者互動最直接的層面。

介面的好壞決定了使用者對網站的第一印象。設計良好的介面能夠引導使用者自己完成相應的操作，起到嚮導的作用。介面如同人的面孔，具有吸引使用者的直接優勢。

設計合理的介面能給使用者帶來輕鬆愉悅的感受和成功的感覺。

相反，設計失敗的介面讓使用者有挫敗感，再實用強大的功能都可能在使用者的畏懼與放棄中“付諸東流”。

既然介面的好壞如此重要，那麼在測試過程中介面測試就變得不可或缺。在具體的工作中，介面測試應該關注哪些點呢？

介面測試如圖 1-5 所示。

圖 1-5介面測試圖

（1）導航測試

導航一般位於頁面頂部或側邊區域。導航的作用是連結站點內的各個頁面。導航測試可以從以下 4 個方面進行。

① 導航是否直觀？是否易於導航？

② 導航、連結、頁面的結構和風格是否一致？

③ 導航文字是否用詞準確？意義表達是否簡單和準確？

④ 連結的頁面是否準確？

（2）圖片測試

圖片測試包含圖片、動畫、邊框、顏色、字型、背景和按鈕等。圖片的測試可以從以下 3 個方面進行。

① 需要保證圖片有明確的用途，如廣告宣傳作用，不能存在沒有意義的圖片。

② 所有頁面中的字型和顏色及頁面的設計格式要保持一致。

③ 圖片的質量與大小也是需要關注的方面。

（3）內容測試

內容測試用於檢驗頁面資訊的準確性、正確性與相關性。內容測試可以從以下兩個方面進行。

① 驗證傳輸的資訊是可靠的。

② 驗證傳輸的資訊的語法和拼寫是否正確。

（4）展示測試

展示測試用於檢驗頁面展示的所有內容是否正確，大小是否合適，是否符合普適性行為習慣。展示測試可以從以下 4 個方面進行。

① 驗證提示語是否合理、正確。

② 驗證視窗調整大小後展示的內容是否正確。

③ 驗證本地化是否正確。

④ 驗證標題及檢查錯別字。

（5）合理性測試

合理性測試可以從以下 3 個方面進行。

① 驗證頁面佈局是否合理。

② 驗證各控制元件是否合理、是否可編輯。

③ 驗證提示頁面是否合理。

6．瀏覽器相容性測試

瀏覽器相容性是衡量一個系統是否成熟穩定的重要指標。某個功能在某一瀏覽器上的顯示和操作均正常，但是在另一個瀏覽器上的顯示就亂糟糟的，嚴重的可能導致功能異常。

作者所在團隊的業務面向的幾乎都是大眾使用者群體。同時，使用者使用的瀏覽器多種多樣，如果出現相容性問題，那麼使用者對業務的好感度就會降低， 這樣會造成使用者流失，進而損失公司的利益，因此，瀏覽器相容性測試是需要我們加大力度關注的，那麼如何才能充分測試瀏覽器相容性呢？

首先，要了解什麼是相容性問題。瀏覽器相容性問題又稱為網頁相容性問題或網站相容性問題，是指網頁在各種瀏覽器上的顯示效果可能不一致而產生瀏覽器和網頁間的相容問題。

那麼為什麼會出現瀏覽器相容性問題？

因為不同瀏覽器使用的核心及所支援的 HTML（標準通用標記語言下的一個應用）等網頁語言標準不同， 並且使用者客戶端的環境不同（如解析度不同），因而顯示效果不理想。

其次，要了解當前哪些瀏覽器是主流的，要覆蓋主要的瀏覽器核心。作者所在團隊對目前主流的 14 款瀏覽器進行了相容性測試，並對瀏覽器的不同版本進行了測試。

在測試過程中，需要對以下介面功能進行相容性測試。

1）業務與功能結合的非同步互動。

2）功能按鈕（增加、刪除、修改、查詢、匯入、匯出、超連結和清空）等。

3）日期和時間控制元件、搜尋控制元件。

4）有特殊功能的圖示。

1.1.3 自動化測試和測試開發

隨著被測系統越來越複雜，規模越來越龐大，測試的工作量也越來越大，這必然會暴露出人和測試生命週期的衝突。為了更加快速、有效、可靠地對軟體進行測試， 提高被測系統的質量，測試工具和工具思維就必然會被引入測試工作中，自動化測試也自然而然地被提上日程。

隨著IT 從業領域的不斷深入和複雜化， 職位細分也越來越複雜，一開始集開發、測試、運維、DBA 等一系列工作於一身的軟體“英雄”，現在已經細分到開發工程師、測試工程師、運維工程師、測試開發工程師、開發運維工程師和測試運維工程師等職位， 如圖 1-6 所示。

圖 1-6職位細分趨勢

軟體工程師是從事軟體開發相關工作人員的統稱。它是一個廣義的概念，包括軟體設計人員、軟體架構人員、軟體工程管理人員、程式設計師等一系列崗位，工作內容都與軟體開發生產相關。軟體工程師的技術要求是比較全面的，除了基礎的程式語言、資料庫技術等，還有諸如 JavaScript、AJAX、Hibernate、Spring 等前沿技術。

 

運維工程師負責維護並確保整個服務的高可用性，同時通過不斷優化系統架構、提升部署效率、優化資源利用率、提高整體的 ROI（Return On Investment）。運維工程師面對的最大挑戰之一是大規模叢集的管理問題，既要管理好幾十萬臺伺服器上的服務，又要保證服務的高可用性。

質量保障（QA）工程師不僅要理解產品的功能要求，還負責對其進行測試，檢 查軟體有沒有缺陷，測試軟體是否滿足穩定性、安全性和易操作性要求，以及寫出相應的測試規範和測試用例。

簡而言之，質量保障工程師在一家軟體企業中擔當的是“質量管理”角色，他負責及時發現軟體問題並及時督促更正，確保產品的正常運作。

隨著細分領域的不斷髮展，出現了同時承擔開發和測試工作的角色—測試開發工程師，同時承擔開發和運維交叉工作的角色—開發運維工程師，同時承擔測試和運維工作的角色—測試運維工程師。由於 3 個角色交叉的工作在現在的大型專案中不太容易出現，因此，如果有這部分工作，那麼只需要一個“超人”一樣的角色來完成。

分層自動化測試這個概念最近曝光度比較高。傳統的自動化測試更關注產品 UI 層的自動化測試，而分層自動化測試倡導產品的不同層次（階段）都需要自動化測試， 如圖 1-7 所示。​

​圖 1-7分層自動化測試的示意圖

相信測試人員對圖1-7 所示的“金字塔”結構並不陌生，這也是產品開發不同層次所對應的測試。我們需要規範地進行單元測試，同樣需要相應的單元測試框架，如Java 的 JUnit、TestNG，C# 的 NUnit，Python 的 unittest、pytest 等，絕大多數主流語言都有其對應的單元測試框架。

介面測試對於測試新手來說不太容易理解。單元測試關注程式碼的實現邏輯，如一個if 分支或一個for 迴圈的實現，而整合、介面測試關注的是一個函式、類（方法） 所提供的介面是否可靠。

例如，如果要定義一個 add() 函式，用於計算兩個引數的和並返回結果，那麼需要呼叫 add() 方法並傳參，而後比較返回值是否為兩個引數相加之和。當然，介面測試也可以以 URL 的形式進行傳遞。

例如，通過 get 方式向伺服器傳送請求，那麼傳送的內容作為 URL 的一部分傳遞到伺服器端。但是，如果 WebService 技術對外提供一個公共介面，那麼需要通過 SoapUI 等工具對其進行測試。關於 UI 層的自動化測試，有些讀者可能非常熟悉，因為測試人員的大部分工作都是對 UI 層的功能進行測試。

例如，如果需要不斷重複對錶單提交、結果查詢等功能進行測試，那麼可以通過相應的自動化測試工具來模擬這些操作，從而避免重複的操作。UI 層的自動化測試工具非常多，目前比較主流的是 QTP、Watir 和Selenium 等。

為什麼要設計成一個金字塔結構，而不是長方形或倒三角形結構呢？

這是為了表示不同階段所投入自動化測試的比例。如果一個產品從來沒有進行單元測試與介面測試，只進行了 UI 層的自動化測試，那麼這是不科學的，很難從本質上保證產品的質量。

如果使用者企圖實現全面的 UI 層的自動化測試，那麼不但浪費了大量的人力和物力，而且最終獲得的收益可能會遠遠低於所支付的成本。因為越往上層，其維護成本越高，尤其是 UI 層的元素會時常發生改變。

所以，應該把更多的自動化測試放在單元測試與介面測試階段進行。

既然 UI 層的自動化測試這樣“勞民傷財”，那麼是否可以只進行單元測試與介面測試？

不可以。因為無論什麼樣的產品，最終呈現給使用者的是 UI 層，所以測試人員應該將更多的精力放在 UI 層上。

也正是因為測試人員需要在 UI 層投入大量的精力，所以才有必要通過自動化的方式幫助測試人員“部分解放”重複的勞動。

在自動化測試中，測試人員最怕的是變化，因為變化的直接結果是測試用例的執行失敗，這時就需要對自動化指令碼進行維護。減少失敗次數，以及降低維護成本， 對自動化測試的成敗至關重要。換個角度講，一個永遠都成功執行的自動化測試用例是沒有價值的。

到了這裡，讀者對自動化測試應該有了一定的瞭解。但是，可能有些讀者依然不知道如何下手和提高技術能力。

因此，現在開始介紹如何提高技術能力。從軟體測試入門，學習各種技術，然後晉升到一個比較好的職位，功能測試是這樣一個過程， 自動化測試同樣也是這樣的。

圖 1-8 給出了一個學習成長路線，也許不完全適合你， 但是希望對你有所幫助。​

​圖 1-8成長路線

測試開發的主要工作內容是完成和維護自動化測試相關的工作。自動化測試就是通過使用或者開發測試工具、測試框架、測試系統和測試平臺，按照測試工程業務測試的流程、計劃及預期對被測系統進行測試的過程。

自動化測試是軟體測試的一個重要組成部分，自動化測試和業務測試既不能相互完全替代，也不能完全相互分離。正確、合理地利用自動化測試手段，結合業務測試流程和執行，能夠提高測試效率和測試覆蓋率，從而保證軟體的質量，縮短開發週期，提高交付頻率，節省工期和人力成本。

自動化測試涉及測試流程、測試體系、測試規範、測試方案、自動化的執行測試、自動化的測試環境治理等方面，既有技術的問題，又不僅僅有技術問題。自動化測試需要長期投入，涉及專門團隊建立、維護，以及發展自動化的流程、體系等內容。

自動化測試的優點如下。

（1）模擬人工測試流程，減少重複、機械的測試工作，讓機器執行固有流程， 提高可靠性。

（2）提高測試的精準度，提高測試執行範圍，針對海量引數進行測試，機器的執行效率會更高。

（3）更好地利用測試資源，將複雜、煩瑣的測試流程交由機器執行，可以讓測試人員有更多的精力去關注質量保證方面的問題。

（4）具有可重複性和測試一致性。

（5）提高測試用例的複用性。

另外，自動化測試不是測試效率提升的關鍵，它也存在不可避免的劣勢和侷限性。在如下場景中自動化測試並不適用。

（1）永遠不會再重複的測試流程。由於維護一套自動化測試指令碼或者流程需要投入很大的精力和成本，因此僅僅測試一次永遠不會再次出現的測試流程並不適合採用自動化測試。

（2）專案工期非常短的需求。由於準備一個新流程的測試指令碼的時間會遠遠大於業務測試執行時間，因此在工期並不充分的情況下，採用業務測試手段保障測試質量更直接、更迅速。
（3）UI 的易用性等測試並不適合自動化測試，因為 UI 設計的美化、互動是否符合人的固有習慣目前是機器無法評價的，還是需要業務測試人員直接參與。

（4）實際軟硬體結合場景。例如，需要無人機配送的測試，並不適合自動完成全部流程。

（5）任何技術都有侷限性，上面並沒有完全覆蓋自動化測試不適用的所有場景。測試開發工程師是一個交叉工作的角色。

與開發工程師相比，測試開發工程師除了要具備寫程式碼的能力，還需要掌握作業系統、資料庫、網路、軟體測試等相關領域的知識；與業務測試工程師相比，測試開發工程師擁有編寫測試指令碼、設計測試框架、搭建測試平臺、維護測試環境等技能，但是可能沒有業務測試工程師那種專業的業務知識背景。

測試開發工作，本質就是為了保證測試能夠正確且順利進行而做的工作。測試開發要服務於業務測試，測試開發不是脫離業務而單獨存在的。在軟體系統生命週期過程中，業務測試工程師和測試開發工程師是並存的，並不會彼此替代。虛擬平臺質量管理組也是由於工作需要，才逐漸地走上了轉型這條路。那麼，你為轉型做好準備了嗎？​

《京東質量團隊轉型實踐》

京東研發虛擬平臺  著

每天，上億級別使用者訪問的網際網路系統，各種應用在持續不斷地被測試和釋出，怎麼能夠保證這些系統可以安全、快速、大併發地被使用者使用是個極高的挑戰。本書結合京東質量團隊的日常實踐，以第一視角剖析了京東質量測試過程中成功應對的各種“坑”以及填“坑”的方式和技術，值得從業者很好地學習和借鑑。

本書揭示了大量的奇巧妙計，絕對100%實用且擴充套件性強，涉及測試流程、測試工具、測試用例、自動化測試框架、測試管理、持續整合等方面。使用這些技術，你可以把測試工作由瓶頸變成一個加速器，使得整個團隊都更加富有效率。

購書福利：10月30日~11月2日，京東圖書每滿199減100，更有跨店滿減優惠，掃碼購書哦。​

​長按二維碼，可以關注我們喲

每天與你分享IT好文。

在“非同步圖書”後臺回覆“關注”，即可免費獲得2000門線上視訊課程

非同步圖書福利送不停

邀請10名好友關注10天直接獲取非同步圖書一本（點選文字獲取活動詳情哦）

點選閱讀原文，購買《京東質量團隊轉型實踐》

閱讀原文