寫在前面

在準備測試開發新人手冊之前，采訪了一些剛入職的小伙伴：你入職后最大的困惑是什么，想看到什么樣的新人手冊？有位同學的回答很能體現大家的心路歷程，入職后每天都給自己靈魂三問：我是誰？（我的工作角色是做什么的），我在哪兒？（測試開發在大團隊中的位置），我該做什么？（如何開展工作）。這版新人手冊希望能回答到這些問題，讓新人同學能尋找到答案，快速融入。

測試開發新人手冊分為3部分。

1、基礎篇 – 如何開始你的第一個測試項目

2、進階篇 – 做專業的測試

3、思考篇 – 穩定性保障&測試技術創新

1. 基礎篇 – 如何開始你的第一個測試項目

1.1 我是誰？- 認識你的角色

測試開發工程師，可以從兩方面理解：思想和方法。測試最重要的是思想，技術是實現方法。作為測試開發工程師則需要具備測試的思想善用技術手段完成質量保障工作。我們可以通過接下來的介紹幫助大家再深入理解什么是質量，什么是測試？如何用技術手段實現測試？

1.1.1什么是質量？

質量的定義因領域不同定義有很多說法，軟件領域的質量是指在特定的使用條件下產品滿足明示的和隱含的需求所明確具備能力的全部固有特性（內在特性），體現了產品滿足產品要求的程度（外部表現），是產品的質量屬性。

從概念分析對應到我們實際的測試工作，包括的三個要素：產品（我們的被測對象）、特性集合（需要采用哪些測試類型）、需求（覆蓋的測試場景）。

1.1.2 什么是測試？

一個經典的問題：做測試的目的是什么？為了發現問題？為了質量？還是為了業務價值保障？這是個大家需要經常問自己的問題，我們技術質量做的一切活動目的，一定是為了保障業務交付。測試要打造發現問題的能力，同樣也需要有打造高穩定性的能力。需要對每次發現的問題都剖析如何能避免問題再次發生或更早階段識別，同時對遺漏的問題都深入思考剖析為什么沒能提前發現。圍繞這樣的目的作為我們工作的方向。

1.1.3 準備工作環境 – 工欲善其事，必先利其器

1.1.3.1 不同工作環境介紹

環境是測試工作中非常消耗時間且難以管理的部分，環境區分的目的和方式，一定程度也體現了大家目前的測試流程和規范，接下來我們會介紹環境是如何分層，如何管理，如何準入準出。

【第一步：理解環境】

實際上，環境的名稱只是一種形式，關鍵在于不同的環境之間存在一些代碼、數據、服務之間的差異。以接入的數據源來說，項目/日常環境的數據庫與預發/生產環境的數據庫肯定不一樣，這樣測試使用的數據就不會污染線上數據；預發環境/灰度環境會與生產環境共用一套數據庫，以便在預發環境下測試新的功能也能較真實地反映線上的情況。還有一些差異在于使用者的不同，比如預發和灰度環境都使用的是生產環境的一套數據庫，但灰度環境的使用者是一小部分的外部用戶（客戶），而預發環境的使用者一般都是內部人員（開發/測試）。

【養成測試發布好習慣】

優秀的我有著

優秀的習慣

未經過項目環境測試的變更我絕不直接部署日常

未經過日常測試通過的變更我絕不直接上預發

未經過本地/項目環境編譯啟動成功的變更我絕不直接部署日常和預發

【第二步，各個環境區分】

• 項目環境

項目環境也可理解為開發環境和聯調環境，顧名思義，開發同學開發時使用的環境，每位開發同學在自己的dev分支上編碼，和其他代碼是完全分離的。多項目環境可以關聯在一起形成項目制的開發和資源聯調。項目環境數據庫和日常環境是一套。

• 日常環境

日常環境是主要測試環境，開發完成自測通過后提交代碼，日常環境會（merge）所有提交到日常的分支，融合的時候可能會存在沖突，有沖突就需要排除沖突。測試同學主要的工作環境為日常環境。

• 預發環境

預發環境和日常環境一樣是把其他開發同學部署到日常機器上的代碼和你要發布到日常的代碼融合起來（merge）一起測試。但預發環境區別于日常環境最大的點是，預發環境和生產環境是同一套數據庫。而且相對日常，預發的數據更加接近真實的線上數據。預發環境和生產環境的訪問域不同。所以預發環境更多使用在驗收測試和最后發布前的checklist觀察，不作為測試的主要環境。

• 灰度環境

灰度環境其實就是小范圍的生產環境，是一套有隔離策略的生產環境分組。是通過真實流量結合環境策略能夠在全量發布前再進行一輪驗證，因為都是真實流量，灰度如果出現問題，影響的已經是真實用戶，但因流量帶來的損失可控。（愛玩游戲的同學可以把它理解為游戲內側、體驗服等）

• 生產環境

即線上環境，在權限和發布管理上非常嚴格。包括DB的寫操作都需要多級審批流，發布變更也有嚴格的窗口管控，在流程上也要求了變更必須經過日常 – 預發 – 灰度之后才允許合并到線上。

• 自定義環境

1.2 我在哪兒？- 修煉測試基本功

熟悉了環境，做好了工作準備，可以開始第一個項目了嗎？如果你已經了解軟件質量屬性，也掌握了常用的測試方法，熟悉測試流程，那么恭喜你，可以開始你的測試工作了，如果還沒有，下面的章節可以找到答案。

1.2.1 認識軟件質量

1.2.1.1 軟件產品質量屬性

這一章會從軟件質量的基本概念出發，以標準化（ISO/IEC25010）的軟件定義，介紹軟件產品質量模型和使用質量模型。里面的內容都可以在《GBT25000.10-2016系統與軟件工程系統與軟件質量要求和評價(SQuaRE)第10部分系統與軟件質量模型》中找到詳細解釋，這里主要列出我們測試工作中常用且必須關注的質量特性以及實際場景中如何運用。

系統/軟件產品質量屬性有8個特性:功能性、性能效率、兼容性、易用性、可靠性、信息安全性、維護性和可移植性。其中功能性，性能效率，可靠性、易用性（人工差錯防御）是我們著重需要關注的質量特性，也是導致線上90%故障的主要因素。

產品質量特性說明和理解：

• 功能性 – 在指定條件下使用時,產品或系統提供滿足明確和隱含要求的功能的程度。包括功能完備性、功能正確性、功能適合性、功能性的依從性。

從定義上來理解，功能性并不止滿足“明確”的要求，還有很多“隱含”的質量特性。我們在做功能測試的時候，“明確” “隱含”需求一起覆蓋才是完整的測試場景。我們在工作中如何能前置讓隱含的需求明確，是質量同學的一項重要能力，這個過程包括在需求前期跟PD的明確，比如需求文檔里描述了想要實現的功能，但沒有寫明對性能和用戶體驗的要求，測試同學就是需要在評審階段就對焦明確，這樣在TC設計，測試策略以及后面業務方驗收測試中才能充分被覆蓋到。還是一個基本原則，問題越前置被識別并解決，是成本最低的做法。

• 性能效率 – 性能效率的評估與在指定條件下所使用的資源量有關。包括時間特性、資源利用率、容量、性能效率的依從性。

實際工作中，我們基礎架構的彈性能力，常態化壓測能力、大促的全鏈路壓測等都是這一質量屬性的測試體現。后面在測試進階能力中，會有專門篇幅介紹性能測試和全鏈路壓測的內容。

• 可靠性 – 系統、產品或組件在指定條件下、指定時間內執行指定功能的程度。包括成熟性、可用性、容錯性、易恢復性、可靠性的依從性。

質量同學在評估方案時經常會出現這樣的靈魂拷問：怎樣設計測試場景保障線上不出問題、如何設計架構讓主流程不受阻塞、強弱依賴如何解耦、準備怎樣的預案讓問題發生時也能快速恢復等，都是對可靠性質量屬性的測試實踐，可靠性也是我們在設計評審中需要著重關注的特性。

• 易用性 – 在指定的使用周境中,產品或系統在有效性、效率和滿意度特性方面為了指定的目標可為指定用戶使用的程度。包括可辨識性、易學性、易操作性、人工差錯防御性、易訪問性、易用性的依從性。

易用性的另一個描述就是功能級別的用戶體驗（下一章會介紹使用級別的用戶體驗），我們新零售技術質量的愿景就是“做用戶體驗的捍衛者”，因此易用性是測試過程中很重要的一個覆蓋范圍。易用性里核心需關注的是人工差錯防御，我們有很多故障或線上問題都來自于人工操作或配置類錯誤，這都是人工差錯防御范圍。

• 兼容性 – 在共享相同的硬件或軟件環境的條件下,產品、系統或組件能夠與其他產品、系統或組件交換信息,和/或執行其所需的功能的程度。

包括共存性、互操作性、兼容性的依從性。兼容性測試在移動應用測試和跨平臺組件應用上需著重評估。

• 信息安全性 – 產品或系統保護信息和數據的程度,以使用戶、其他產品或系統具有與其授權類型和授權級別一致的數據訪問度。包括保密性、完整性、抗抵賴性、可核查性、真實性、信息安全的依從性。

這部分質量屬性直接對應安全性測試，已經是測試領域里獨立的一個重要方向。后面的進階篇會有詳細介紹。

• 可維護性 – 產品或系統能夠被預期的維護人員修改的有效性和效率的程度。包括模塊化、可重用性、易分析性、易修改性、易測試性、維護性依從性。可維護性更多體現在對設計方案的評估過程中。
• 可移植性 – 系統、產品或組件能夠從一種硬件、軟件、或者其他運行(或使用)環境遷移到另一種環境的有效性和效率的程度。包括適應性、易安裝性、易替換性、可移植性的依從性。遷移類項目和版本升級類變更需評估。

1.2.1.2 產品使用質量屬性

使用質量屬性是從用戶使用體驗的角度進行定義，質量同學作為用戶體驗的捍衛者，除了產品質量，使用質量也需要關注。它描述了產品(系統或軟件產品)對利益相關方造成的影響。它是由軟件、硬件和運行環境的質量,以及用戶、任務和社會環境的特性所決定的。所有這些因素均有利于系統的使用質量。

產品使用質量屬性說明：

• 有效性：用戶實現指定目標的準確性和完備性。
• 效率：與用戶實現目標的準確性和完備性相關的資源消耗。
• 滿意度：產品或系統在指定的使用周境中使用時,用戶的要求被滿足的程度。包括有用性：用戶對實用目標的實現感到滿意的程度,包括使用的結果和使用后產生的后果；可信性：用戶或者其他利益相關方對產品或系統將如預期地運行有信心的程度；愉悅性：用戶因個人要求被滿足而獲得愉悅感的程度；舒適性：用戶生理上感到舒適的程度。
• 抗風險：包括經濟風險緩解性：在預期的使用周境中,產品或系統在經濟現狀、高效運行、商業財產、信譽或其他資源方面緩解潛在風險的程度；健康和安全風險緩解性：在預期的使用周境中,產品或系統緩解人員潛在風險的程度；環境風險緩解性：在預期的使用周境中,產品或系統在財產或環境方面緩解潛在風險程度。
• 周境覆蓋：在指定的使用周境和超出最初設定需求的周境中,產品或系統在有效性、效率、抗風險和滿意度特性方面能夠被使用的程度。包括周境完備性：在所有指定的使用周境中,產品或系統在有效性、效率、抗風險和滿意度特性方面能夠被使用的程度；靈活性：在超出最初設定需求的周境中,產品或系統在有效性、效率、抗風險和滿意度特性方面能夠被使用的程度。

1.2.2 認識軟件測試

對軟件質量思考的不同角度，形成了不同的測試類型，不同類型對應不同的測試方法，而不同的測試方法針對不同的質量特性。要修煉更深更廣的測試覆蓋度，需要了解更多的測試方法用于設計測試用例。這類方法的介紹書籍非常多，下圖是一個質量特性對應測試方法的展示。實際項目中測試時間和資源往往有限，測試工程師就需要不斷的思高效的質量保障手段。下圖很多方法都已能通過工具或技術手段來完成，比如異常測試，故障輸入，冪等，灰度驗證等等。因此質量特性對應的方法更多只是一個范圍的參考，給測試同學一個基本原則，如何保障好這個特性，需要我們不斷的思考測試技術的突破來實現。

1.2.2.1 測試類型

根據測試方法不同的類型

• 黑盒測試 – 也稱功能測試或基于需求的測試，測試設計時把被測對象當成一個黑盒子，不關心盒子的內部結構，主要通過輸入/輸出數據驅動功能用例。這類測試中理論上的充分測試標準就是“窮舉輸入”，而窮舉肯定是不可能的，因此我們還需要其他的測試類型進行補充。
• 白盒測試 – 也稱為邏輯驅動測試，針對性較強，需要對代碼邏輯有了解。理論上的充分測試是所有的條件、語句、路徑組合都被覆蓋，對技術和成本都有一定要求。
• 灰盒測試 – 介于白盒與黑盒之間的測試方式，根據實際測試場景、資源、復雜度等情況進行結合，也是目前我們使用最多的測試類型。

每種測試類型都對應很多測試分析方法，后面進階篇也會針對各種測試方向進行深入介紹，這里不對基本概念和原理多做贅述。

1.2.2.2 軟件測試的基本原則

基本功修煉的最后，我們可以歸納出一系列重要的測試指導原則，可作為我們日常工作的提醒。原則大部分看上去顯而易見，淺顯易懂。但往往故障都發生在這些常見的場景中，用一位開發TL在某次故障復盤會上的話，給“修煉測試基本功”這一章做個結束語：故障中的一切問題看似天災人禍，實則人事不修。

1.3 我該做什么？- 測試工作流

1.3.1 研發過程中的測試工作

研發過程中測試可以做的事情很多，下面流程環節的介紹只列出了最主要的一些測試活動，可以作為一些基本參考，測試怎樣能介入的更深入，在團隊建立認可和存在感，拿到更好的質量保障結果，是需要在工作中不斷的思考實踐的，因此這一章雖然是介紹流程，但是實操中不限定角色，不限定階段，不限定方式，大家結合項目實際的時間資源、人力資源、質量要求做到最佳實踐就是可行的工作流。

1.3.1.1 需求設計階段測試做什么 – 測試計劃與需求評估

1.3.1.2 開發設計階段測試做什么 – 分析與設計

1.3.1.3 測試階段做什么 – 測試執行與策略實施

1.3.1.4 發布前后

1.3.2 測試工作規范&標準

1.3.2.1 通用版變更紅線V2.0

前面介紹環境和權限中提到過，線上變更是風險非常高的操作，90%的故障是變更引起，因此我們在測試過程中往往需要制定詳細嚴格的變更管控，變更風險防控三原則：可灰度，可監控，可回滾。

• 變更紅線定義( 示例）：

• 禁止封網期、非變更窗口期進行除緊急變更外的變更。
• 禁止未經測試驗證、未經預發、未經灰度的線上變更。
• 禁止一切未通過變更管理平臺申請或報備的變更操作，緊急故障處理，可事后補填申請。
• 禁止無影響面說明、操作步驟、驗證方案、應急預案的變更。應急預案（如回滾方案）必須具備可操作性。
• 禁止一切與變更方案計劃內容、線上問題排查無關的生產環境變更操作。