我理解的測試開發與實踐總結——新人篇

　　 一、我理解的測試開發

　　測試開發與開發、測試的關係

　　以前在沒有接觸測試開發這份工作之前，我總是在思考測試開發崗位到底要做什麼？測試開發和測試有什麼區別？測試開發是開發嗎？測試開發的價值在哪裡？一開始我直觀的認為測試開發=測試，直到真正在工作實踐中，我才慢慢了解到測試開發的崗位需要做什麼。

　　1.首先，從崗位名字看區別：先明確一下簡稱，由於這幾個崗位名字看著比較像，很多人都不知道這三者的區別與聯絡，軟體開發工程師（SWE ），測試開發工程師（SWT），測試工程師（TE）。

　　2.其次，從各方面能力上看區別，我的理解是：從程式碼能力要求上，軟體開發工程師>測試開發工程師>測試工程師；從掌握知識廣度要求上，測試開發工程師>軟體開發工程師>測試工程師，從工作溝通能力要求上，測試開發工程師>測試工程師>軟體開發工程師。

　　測試開發的分類

　　測試開發主要分為兩類：

　　一類是基於業務驅動型的測試開發。可以理解為業務測試工程師，只是具備了開發能力和質量改進思維，這類測開人員需要扎進業務中，主動挖掘業務過程中各個環節質量的薄弱點並且想辦法去解決，透過流程改進、開發出得心應手的工具，讓自己的測試工作能夠持續高效。

　　一類是基於框架平臺型的測試開發。這型別的測試開發，需要站在更高的緯度來看待產品的質量，他們會對整個研發過程或者某個大的專項去開發一些測試平臺、框架，並且將這些能力以服務的形態提供給各個業務線使用，以此來保障全域性內建質量。

　　不管是哪一類，測試開發崗位的核心仍然是“測試”，開發的目的是為了更好的服務測試，測開應該看重的是對測試的理解，以及在這個基礎上設計、能開發設計幫助測試人員或者開發、運維人員提高效率並解決實際業務問題的工具。

　　3）測試開發的本質

　　我作為一名業務驅動型的測試開發工程師，其實工作中主要還是圍繞著業務展開，我們所做的一切測試、開發的工作也都是為了測試提效，為了業務的質量保障。

　　其實我認為測試開發的本質應該是“懂開發的測試”，是為了更好的服務產品的“質量”。由於對於目前測試的工作要求，已經不是傳統的測試崗位所能勝任的了，我們除了簡單的操作層面的“測試”工作，還需要考慮到從測試設計到資料準備到風險控制以及研發效率提升等各個方面，我們需要將我們的工作上升到價值層面的“質量保障”，所以測試工作只是測試階段的質量保障手段之一，我們要做的是從產品的需求評審到交付上線整個週期的質量保證，除此之外我們還需要從效能提升、安全生產等各個方面來評估我們的工作質量。

　　我經常會陷入一個怪圈，作為一名業務型測試開發，我覺得我主要工作是放在業務的質量保障上，但是每到制定OKR、談到績效、價值等方面時，卻又主要用橫向的指標來作為測試人員價值的體現，我不理解為什麼是這樣，直到我看到一篇文章《業務型測試的職業發展和晉升路徑思考》，我才發現原來這是所有業務型測試在公司所面臨的的一個挑戰。

　　 二、測試和開發、產品的關係

　　在平時工作中，我們接觸到最多的角色就是開發和產品，那這三者的關係是如何？

　　從一個產品交付流水線來看，可能有的人會簡單地認為，產品、開發、測試是一個線性關係，產品評審完需求之後，開發進入開發過程，完成開發工作之後，測試開始進行測試，最後完成整個需求的上線。但是實際上，這三者之間其實是一個三角關係，產品在需求評審階段、開發在技術評審階段、測試在TC評審階段都需要這三者在場，站在自己的角色視角提出相關建議，更高質量地交付產品上線。　　

　　 三、測試開發需要具備的技能

　　1）業務理解能力

　　一切的測試都不能脫離業務，所以一開始進到一個組之後，首先要熟悉的就是業務，業務測試也是在我們工作中佔了大比重的，所以我們需要花日積月累的時間來鍛鍊自己的業務理解能力。

　　2) 測試能力

　　3）排查問題的能力

　　當我們發現bug之後，其實第一個要做的就是快速定位問題的原因，這也可以幫助開發更快的定位和解決問題，後面說的測試過程中需要做到什麼程度，也講了排查問題的能力的級別。比如，在發現一個bug後，可以先判斷是前端還是後端還是資料還是環境問題，透過介面返回、日誌排查、程式碼檢視許可權、具體定位到程式碼debug等各種方式進行問題的定位。

　　4）測試提效能力

　　除了手工測試，我們還需要利用自動化的方式提高測試效率，我們可以寫一些自動化的指令碼來減少測試帶來的重複性工作，也可以研發效能平臺來為質量保障作為基建支撐，效能工具就像是一把劍，可以帶著我們大大提升工作的效率。

　　5）安全生產的意識

　　如果把效能平臺比做是一把劍，安全生產我覺得就像是一個盾，我們可以透過監控、故障演練、預案、快恢等各種方式來進行我們的業務質量保障工作，保證整個產品不出問題，或者出了問題能夠風險最小化。

　　7）善於搜尋的能力

　　公司內部的知識庫如：ATA、語雀、釘釘文件，外面的如：GitHub、CSDN、知乎等等都給了我們很多可以學習的空間，但是由於知識的龐雜，我們還需要有善於搜尋和發現適合自己的知識和工具的能力。

　　8）owner意識

　　對於自己負責的工作要具備owner意識，其實這需要很強烈的責任心和積極主動的精神，比如作為一個專案owner，需要有把控全域性的能力，還要有懂得如何劃分和安排任務的能力，還有協調溝通的能力，還要有推動專案進展的能力，還要有預期和拿結果的能力，哈哈，說實話有點難，但是我覺得這是作為一個阿里人需要具備的。

　　 四、我們在測試過程中需要做到什麼程度

　　其實從問題的生命週期來看，可以分為：發現問題->定位問題->解決問題->預防問題

　　級別1：發現問題，提出bug讓開發去定位產生問題的原因；

　　級別2：定位問題，知道出現問題的原因是什麼，這個需要去查資料庫、日誌甚至程式碼來定位問題。在提bug的時候，給開發一些可能的建議，幫助開發定位到問題，這本身是測試價值的一種體現。

　　級別3：解決問題，如果測試能夠解決問題，那就沒開發什麼事了，或者說能夠更好的去協助開發去解決bug。

　　級別4：預防問題，解決問題後需要有能夠預防此類問題產生的策略，更好的進行質量保障

　　其實在工作過程中，我們經常是處於級別2的一個狀態，不過定位問題也是考驗技術和對系統的熟悉程度的，如果能精準定位到問題原因所在，也能減少開發排查問題的工作量。

　　 五、我們需要具備的素質

　　工作了一年之久，在平時工作中也總結了一下，我覺得作為一名測試開發同學，應該是最好需要具備以下幾個素質吧：

　　1）溝通能力

　　測試需要和大量的人打交道，需要很強的溝通能力，如果講不清楚，那麼工作就無法進行，而交流過程中，我們首先要組織好語言和邏輯，其次是要客觀的反饋事情的真相。這個對我有點社恐的人來說其實一直是一個比較有挑戰性且有趣的工作，其實一個好的人際交往的能力對工作效率也會有很大的提升。

　　2）細心、耐心

　　測試是輔助研發定位錯誤，幫助研發快速完成開發工作，所以我們需要非常細心去發現一些細小的錯誤。對於有的測試過程可能是反覆枯燥的，這個需要很大的耐心。尤其是業務型測試，我們經常同樣的操作步驟需要重複很多次，這也是為什麼大家想用自動化來解放雙手。

　　3）邏輯思維、分析問題

　　遇到問題，測試需要快速分析定位問題，並且能夠復現，理清楚邏輯給到研發，儘量減少研發定位bug和反覆修改的工作，這其實意味著我們需要對產品有著非常強的熟悉程度，這樣才能更快速精準的定位問題所在。

　　4）快速學習

　　測試學的東西比較廣泛，需要掌握的知識和技能也非常多，所以擁有快速學習的能力是至關重要的，否則就很容易被淘汰，不過好在公司有很多的知識庫以及技術味濃的ATA，這其實對於一個新人來說，是一個很好的學習機會，不過有時候東西太多，也要慧眼斟酌一下。

　　5）責任心

　　測試的工作是要保證產品上線的質量，所以需要很強的責任心，這個我覺得每個崗位的工作者都需要有這樣的素質，就不用多說了。

　　6）團隊協助

　　測試工作會與各個人員打交道，在做好本職工作的同時，應該積極並且有意識的關注專案的進度和組內情況，要有大局觀，團隊利益至上，要願意共享個人經驗，同時也善於從同事那裡進行學習，團隊協作能力也是測試需要具備的基本素養。

　　7）文件編寫

　　優秀的文件沉澱可以給自己也給後人帶來福利，我一直很喜歡做文件沉澱，原因是我覺得好記性不如爛筆頭（是我記性不好），有時候以文字的方式記錄下來可以提醒到自己，也可以鍛鍊自己的總結能力，當別人有需要的時候也可以分享給別人，真是一舉三得呀～

　　 六、測試工作流程及關注點有哪些

　　首先我們應該在需求評審階段就需進行介入，並且在每個工作階段，測試都需要有相應的關注點和輸入輸出，接下來總結一下我平時工作的測試工作流程和每個階段測試需要做的事情吧～

　　1. 需求評審階段【關注】

　　測試人員需要進行需求分析，熟悉技術實現方案、設計是否涵蓋了業務需求、存在的風險，為測試分析和測試用例設計提供輸入。

　　主要關注點：架構合理性、風險評估、測試策略（手工測試or自動化測試or其它）。

　　根據需求大小判斷是否測試人員測試還是開發自測（可根據情況判斷是否提供冒煙測試用例）

　　2. 設計測試用例【重點關注】

　　根據prd編寫測試用例、冒煙測試

　　編寫冒煙測試用例（看專案大小而定，如果專案改造比較大，或者是新專案，建議編寫，用例評審時提供給相關開發人員，冒煙測試用例透過後，正式提測）。

　　專案中測試同學需要給研發同學提供冒煙測試用例，且和前端同學達成一致，冒煙測試用例要求總用例的10%。

　　3. 測試用例評審【視需求大小而定】

　　時間在原定提測時間前1-2天，根據專案大小和時間決定是否需要該環節

　　輸出：用例評審會議紀要、修改版測試用例、冒煙測試用例(給開發)

　　4. 提測預演【視需求大小而定】

　　ps：正常來說是開發人員組織，如果他們忽略掉，測試人員可根據實際情況，要求進行提測預演，保障提測質量

　　規範：按照測試用例評審的冒煙測試用例由開發進行預演，若冒煙測試用例均透過，則測試接受測試，否則打回併發郵件說明冒煙測試不透過並預計下次提測時間

　　輸出：冒煙測試結果郵件（透過與否都需要發郵件，並給出預計釋出時間點、風險）

　　提測後第一時間投入測試，若預演未透過，要告知風險

　　5. 測試階段【重點關注】

　　測試階段需要提前準備好測試環境、測試用例、測試資料等；

　　測試過程中需要及時提交缺陷、跟進缺陷，bug一般採用aone進行管理，缺陷格式最好採用：【需求名稱】具體缺陷名稱，便於後續搜尋和歸類；

　　業務相關諮詢：PD+業務 ；產品樣式相關諮詢：產品+UED ；開發相關諮詢：前端+後端；

　　aone缺陷處理規範

　　1.缺陷修復後，開發同學需要fixed bug（研發）

　　2.缺陷修復後，需進行對應的缺陷修復驗證。（測試同學）

　　3.缺陷驗證透過，closed關閉缺陷前需對該缺陷對應的缺陷型別及缺陷原因進行歸類。（測試同學）

　　4.缺陷驗證不透過，可將該缺陷reopen後繼續提交開發處理。（測試同學）

　　6. 釋出預演【功能驗收（可多輪）】

　　測試人員提前預定會議室，發會議邀約給相關人員

　　會議記錄：預演過程中，要記錄會議摘要，哪些bug需要修復後上線，哪些bug後期再迭代（pd+業務評估）

　　7.釋出計劃

　　釋出計劃的編寫人員主要是開發和測試；

　　目的：編寫測試計劃，測試人員明確本次測試的重點和迴歸重點，開發人員明確釋出應用和釋出順利，避免漏發、釋出順序搞錯等原因造成線上bug，從而程式碼回退。

　　8. 正式釋出

　　跟蹤釋出情況，可要求開發在群裡同步釋出節奏，釋出完成後，第一時間線上驗證（釋出後，@pd+業務，他們可同時進行線上驗收）；

　　不同的業務可能有不同的釋出視窗期，需要注意是否在釋出視窗期，否則可能需要緊急審批；

　　由於很多線上問題都是由於變更導致的，所以再發布的時候格外注意是否有漏發的情況出現；

　　一般釋出過程中有灰度觀察期，這個期間可觀察線上流量是否有異常出現。

　　9.線上驗證

　　相關人員需要及時驗證線上結果，一般測試進行驗證，如果由於業務特點測試無法驗證則需要業務同學及時線上驗證，比如，我之前的業務都是測試進行線上迴歸，現在的業務特點由於資料安全等問題，則需要業務自己進行驗證。

　　我把它劃分了主要包括需求梳理、測試準備、測試過程、測試總結四個部分，每個階段的輸出都可以以文件的方式沉澱下來，可作為後續驗收和迴歸的一個參考。

　　 七、平時常用的一些小工具和測試技巧

　　1）一個簡單又好看的json格式化工具：

　　【JSON-handle外掛】　　

　　2）【其它線上json格式化網站】、

　　3）【阿里翻譯外掛】（哈哈，我是一個比較喜歡外掛而不喜歡切換tab頁的人）　　

　　4）【LightProxy】

　　可以本地mock後端返回的資料，直接透過請求名 file://檔案路徑的方式就可以mock資料，很方便。　　

　　還有一種方式：F12控制檯方式（改樣式）

　　在Chrome中任意一個網頁的標籤頁下按F12. 在下方彈出開發者工具皮膚.

　　1.然後點選Console控制檯選項卡

　　2.然後輸入: document.body.contentEditable = "true"

　　3.按下回車,現在你就可以任意編輯網頁了

　　4.當然編輯完後也可以關閉可編輯狀態

　　5）mac自帶截圖工具

　　可以錄屏，截圖，我有時候會把測試結果錄屏或者截圖下來給到業務方驗收

　　6）還有xmind：寫測試用例必備；mac便籤：平時記錄一些草稿亂七八糟的；其它一些常用chrome小外掛：