頂級輔助之測試左移與測試右移
測試左移和測試右移。傳統(tǒng)測試流程
大家熟悉的測試工作是接到項目后參與需求評審，然后根據(jù)需求文檔寫用例和準(zhǔn)備腳本，等開發(fā)提測之后正式開始測試、提Bug、回歸，測試通過后就結(jié)束了，項目交給運(yùn)維上線，之后投入下一個項目繼續(xù)重復(fù)這樣的流程。
這樣的流程看似沒什么問題，但缺點是：
測試過程是在一定時間間隔內(nèi)發(fā)生的，測試人員必須等待產(chǎn)品完全構(gòu)建才能找到錯誤和故障。不可否認(rèn)，花費(fèi)的時間超過了可以商定的時間，等待代碼成為測試人員的瓶頸。
測試同學(xué)非常被動：當(dāng)需求質(zhì)量、開發(fā)質(zhì)量差的時候，你只能被動接受，結(jié)果就是你會經(jīng)歷漫長痛苦的測試過程以及因為質(zhì)量差而導(dǎo)致上線延期；
Bug的成本在后期是非常高的，需要花費(fèi)很多精力和時間去修復(fù)。甚至嚴(yán)重的情況是產(chǎn)品都不能按時發(fā)布，造成很大的損失。
有可能一個線上問題裸奔了幾個月，最后是業(yè)務(wù)方先發(fā)現(xiàn)才排查到是Bug導(dǎo)致，由于影響時間過長給公司造成的損失巨大，還被質(zhì)疑為什么這么明顯簡單的問題上線之后沒人發(fā)現(xiàn)。
不管是測試左移還是測試右移，都是為產(chǎn)品質(zhì)量服務(wù)。不要把提測認(rèn)為是測試活動的開始，上線是測試活動的結(jié)束，更不要認(rèn)為質(zhì)量只是測試同學(xué)需要關(guān)注的。
測試左移
測試左移的思想本質(zhì)是越早的發(fā)現(xiàn)不合理的地方，出問題的幾率就越低。測試左移的原則支持測試團(tuán)隊在軟件開發(fā)周期早期和所有干系人合作。因此他們能清晰地理解需求以及設(shè)計測試用例去幫助軟件“快速失敗”，促使團(tuán)隊更早的修改所有的bug。
參與和理解會使測試人員獲取產(chǎn)品完整的知識，徹底想清楚各種場景，根據(jù)軟件行為設(shè)計實時的場景，這些都會幫助團(tuán)隊在編碼完成之前識別出一些缺陷。
從不重視代碼質(zhì)量的第一天開始，就埋下了問題修復(fù)，定位的成本和修復(fù)問題再次引入問題的成本。
當(dāng)測試在周期的早期開始時，團(tuán)隊會更專注于質(zhì)量，并且“讓我們在第一時間獲得正確的編碼”前景。這有助于節(jié)省大量時間，并減少軟件開發(fā)團(tuán)隊必須為特定代碼執(zhí)行的迭代次數(shù)。因此需要提高質(zhì)量上限和質(zhì)量下限。
提高質(zhì)量上限：通過一系列活動，來避免問題或者本身就讓我們起步就變得很好的，一句話：良好的開始是成功的一半。
提高質(zhì)量下限：通過一系列的活動，讓我們的質(zhì)量成果得以保證。
測試左移，其實就是通過一系列的活動，能提高質(zhì)量的上限，縮短測試的周期，提高質(zhì)量的下限，這樣我們就可以在不斷提高下限的過程中，始終將質(zhì)量穩(wěn)定在一個水平線上，而和團(tuán)隊一起追求更高的目標(biāo)。
在團(tuán)隊的Devops開發(fā)下，對于測試左移進(jìn)行的操作：
編寫單元測試，通過單元測試提前進(jìn)行測試；
Code Review，通過代碼走讀發(fā)現(xiàn)一些基礎(chǔ)的問題；
參與需求評審，提出需求不清晰、不合理、遺漏等意見，了解開發(fā)的實現(xiàn)方式；
參與研發(fā)需求分解，協(xié)助梳理分解遺漏點；
參與概要、接口設(shè)計評審，協(xié)助梳理遺漏邏輯；
提早輸出測試導(dǎo)圖，開發(fā)編碼前進(jìn)行評審；
部分功能提測，提早開始測試；
自動化測試，用于回歸確保舊版本功能正確性；
對于測試左移，進(jìn)行了相應(yīng)的嘗試后，也發(fā)現(xiàn)了測試左移實踐的問題：
測試要求提供概要設(shè)計、接口文檔；
測試要求單元測試必須通過；
測試干預(yù)需求設(shè)計；
很多人都認(rèn)為是測試在要求完成一些沒必要的事情，測試在干預(yù)我的工作。
其實問題的矛盾點在于前面說過的一句話：不管是測試左移還是測試右移，都是為產(chǎn)品質(zhì)量服務(wù)。不要把提測認(rèn)為是測試活動的開始，上線是測試活動的結(jié)束，更不要認(rèn)為質(zhì)量只是測試人員需要關(guān)注的。對于測試左移的落實，最重要的就是全員質(zhì)量服務(wù)意識的培養(yǎng)。
對于測試左移其實我們還有很多東西要做，就好像前面說到的都是為產(chǎn)品質(zhì)量服務(wù)，那么在研發(fā)流程中的任何角色、人員都要為質(zhì)量服務(wù)。
了解和評估需求，發(fā)掘需求的不合理之處，提供針對性的建議，提高需求的質(zhì)量。
了解和評估產(chǎn)品設(shè)計方案，發(fā)現(xiàn)設(shè)計的漏洞，并及時反饋給產(chǎn)品人員，避免問題到了測試階段才暴露出來，影響產(chǎn)品按時發(fā)布。
了解產(chǎn)品的技術(shù)實現(xiàn)，通過查看開發(fā)文檔，接口文檔等，執(zhí)行靜態(tài)測試發(fā)掘問題，檢查代碼問題。
提高質(zhì)量上限：
健康的項目流程（合理并且嚴(yán)格遵守的項目流程）；
合理的需求分析（評估需求的質(zhì)量，分析需求的合理性以及完整性）；
出色的系統(tǒng)架構(gòu)；
充分利用靜態(tài)代碼掃描；
進(jìn)行研發(fā)標(biāo)準(zhǔn)的定義；
提高質(zhì)量下限：
健康的測試流程；
優(yōu)秀的測試用例；
合理的測試計劃；
合適的自動化；
適當(dāng)?shù)奶剿魇綔y試；
開發(fā)自測（TDD、BDD，測試提供更好的用例、技術(shù)支持）；
盡早的測試；
團(tuán)隊質(zhì)量意識的培養(yǎng)；
對于測試左移，也需要一個重要的基礎(chǔ)，工程習(xí)慣，SDLC成熟度，測試分層，持續(xù)集成，鏈路上延展發(fā)布的節(jié)奏，縱深上需要貼合業(yè)務(wù)的專精領(lǐng)域的深度探索，代碼掃描（規(guī)范，問題，安全，異常等），CR， 代碼提交行為分析，test double（mock ， fake， stub，dummy）， UT， 自動化，驗收測試等。左移需要工程效率具備不亞于研發(fā)的代碼能力。因此對于測試左移，可以圍繞質(zhì)量服務(wù)思想展開，參與人員則不僅僅局限于測試人員。
測試右移
左移是往測試之前的開發(fā)階段移，右移是往發(fā)布之后移。也就是產(chǎn)品上線了之后也可以進(jìn)行一些測試活動。當(dāng)然在生產(chǎn)環(huán)境直接做測試是不推薦的，但是我們可以在生產(chǎn)環(huán)境做監(jiān)控，監(jiān)控線上性能和可用率，一旦線上發(fā)生任何問題，盡快反應(yīng)，提前反應(yīng)，給用戶良好的體驗。技術(shù)人員要比業(yè)務(wù)方先發(fā)現(xiàn)問題，如果業(yè)務(wù)方已經(jīng)發(fā)現(xiàn)業(yè)務(wù)量明顯下降，說明問題已經(jīng)很嚴(yán)重了。
測試右移其實還可以理解為如果線上發(fā)生任何問題，我們有沒有能力第一時間發(fā)現(xiàn)問題并解決問題，并保證線上數(shù)據(jù)的一致性或盡可能少的影響線上用戶，以及并且實時獲取用戶反饋。
實踐起來也是存在問題，除了技術(shù)問題之外，還有例如：
線上監(jiān)控搭建后使用率不高；
線上問題反饋機(jī)制，業(yè)務(wù)人員不配合等等；
監(jiān)控指標(biāo)不合理，反而被認(rèn)為增加服務(wù)器負(fù)載；
測試右移的落實，除了質(zhì)量服務(wù)的培養(yǎng)，更加重要的反而可能是：完善的反饋、發(fā)現(xiàn)、定位，在監(jiān)控- 架構(gòu)完善后，怎么更好的與項目工作(流程)結(jié)合，不要讓其成為累贅。
對于測試右移，線上監(jiān)控可以是突破點：
閉環(huán)的線上問題反饋-檢查-解決-更新流程；
更便捷的日志查看、回傳服務(wù)；
豐富有效的log，便于問題的快速定位；
豐富的監(jiān)控指標(biāo)（例如業(yè)務(wù)異常點指標(biāo)）；
成本監(jiān)控（例如短信發(fā)送等）；
關(guān)鍵指標(biāo)每日監(jiān)控（服務(wù)器指標(biāo)）；
生產(chǎn)數(shù)據(jù)監(jiān)控（警報）（通過sql語句實現(xiàn)生產(chǎn)數(shù)據(jù)監(jiān)控，例如是否有多個訂單號一樣的訂單出現(xiàn)等）；
因此對于測試右移，可以圍繞問題反饋、發(fā)現(xiàn)、定位、監(jiān)控展開，參與人員則不僅僅局限于運(yùn)維人員。
軟件一經(jīng)發(fā)布，就要對線上日志監(jiān)控和預(yù)警。及早發(fā)現(xiàn)問題，及早修復(fù)，將損失降到最低。而不是等用戶反饋了，才去解決。如果等到用戶反饋問題，說明問題影響反饋已經(jīng)很大了。
測試上線及時驗證，有問題，開發(fā)快速回滾代碼
上線后開發(fā)監(jiān)控服務(wù)日志，日志報錯，代碼回滾
xdcs監(jiān)控服務(wù)流量，出現(xiàn)流量報警快速定位問題
關(guān)鍵指標(biāo)每日監(jiān)控（服務(wù)器指標(biāo)）
生產(chǎn)數(shù)據(jù)監(jiān)控（警報）
用戶反饋問題及時跟進(jìn)，針對缺陷，通知開發(fā)盡快解決，針對體驗，通知產(chǎn)品打磨細(xì)節(jié)，更好的服務(wù)用戶。
灰度發(fā)布，數(shù)據(jù)隔離，線上監(jiān)控，線上驗收。當(dāng)業(yè)務(wù)方由于環(huán)境等原因，有些功能必須在線上驗收。線上驗收的原則是盡可能的不要影響到原有功能和使用業(yè)務(wù)的用戶，這個就需要做好很好的隔離，所以從研發(fā)一開始的設(shè)計就從線上可測性角度就需要考慮到這一點，功能做好隔離，數(shù)據(jù)做好隔離，一旦出現(xiàn)問題，我們有相對應(yīng)的風(fēng)險預(yù)案，如何清除臟數(shù)據(jù)，如何將功能降級等，前期的設(shè)計都要考慮好，發(fā)布完成以后我們還需要考慮運(yùn)營層面的事情。
采集線上數(shù)據(jù)，包括業(yè)務(wù)數(shù)據(jù)和性能數(shù)據(jù)，建立一個健康的產(chǎn)品數(shù)據(jù)模型。業(yè)務(wù)數(shù)據(jù)可以通過數(shù)據(jù)挖掘，生成用戶畫像，有助于產(chǎn)品人員做出相應(yīng)的決策，包括改進(jìn)現(xiàn)有功能，開發(fā)新功能滿足用戶需求，砍掉某些不合適的功能等。性能數(shù)據(jù)，最直接的作用就是運(yùn)維人員做出相應(yīng)的硬件調(diào)整，包括硬件擴(kuò)容，整合閑置資源等。也可以給架構(gòu)師提供一些系統(tǒng)架構(gòu)設(shè)計上的調(diào)整。
總結(jié)
測試左移的落實，最重要的就是全員質(zhì)量服務(wù)意識的培養(yǎng)。測試右移的落實，除了質(zhì)量服務(wù)的培養(yǎng)，更加重要的是：完善的反饋、發(fā)現(xiàn)、定位問題，提升用戶體驗。相比較，測試左移的價值更高，盡早發(fā)現(xiàn)并解決問題，成本更低。
無論是測試左移還是測試右移，測試人員開始從質(zhì)量控制轉(zhuǎn)變成質(zhì)量保證，從被動發(fā)現(xiàn)軟件問題到主動提高軟件質(zhì)量，從團(tuán)隊的邊緣人物轉(zhuǎn)變成團(tuán)隊的活躍分子，這都值得為之踐行。
-------- THE END --------