我測了啊，我真測了！ | IDCF

來源：圓小豆的美夢工場

作者：于曉南?

• 對測試人員來講，什么事情比較尷尬？——線上出問題。

• 再尷尬一點兒呢？——沒測到，線上出問題。

• 最尷尬呢？——明明測到了，線上還是出問題。

場景1：沒測到，生產(chǎn)環(huán)境出問題

意料之內(nèi)情理之中，這太正常了。沒測到出了問題不該驚訝，沒出問題才該燒香。此時不應(yīng)指責(zé)出問題，而應(yīng)思考沒測到的原因是什么。第一反應(yīng)是測試人員遺漏了，好像也沒更多原因。但當(dāng)我們把視角切換到真實研發(fā)過程中，就會發(fā)現(xiàn)沒測到的原因實在太多了！

• 沒考慮到，測試漏測了

這真是測試的鍋，測試人員確實應(yīng)該全面理解業(yè)務(wù)，設(shè)計高效覆蓋的用例集。但在功能設(shè)計時如有良好規(guī)劃，可以減少沒想到造成的漏測。

• 考慮到了，但還是沒測

一般是時間緊任務(wù)急，來不及測，但又沒向團(tuán)隊暴露風(fēng)險。多半也是測試的失職。

• 不可抗力必須上線，來不及測

大家清楚地知道風(fēng)險，但遇到不可抗力，如法律法規(guī)等，無法完成全部測試就必須上線，這種情況我們且上且觀察，共同承擔(dān)風(fēng)險，并充分思考線上事故的緊急預(yù)案。

• 流程問題，未經(jīng)測試就上線

開發(fā)自己上線了功能，沒經(jīng)過測試人員測試，也沒有充分自測。這種鬼故事在過去的職業(yè)生涯中我至少見過5次。還是不能寄希望于人的專業(yè)性，應(yīng)更多依賴于可控可追溯的流程體系來保證。

• 大家認(rèn)同不需要測，直接上

比如修改文案，或做簡單的圖片替換等。越是認(rèn)為沒問題的，往往越出幺蛾子。就好比我們埋頭苦干往往沒人看，剛要劃水，抬頭就是老板清靜如水的目光。軟件就跟成精了一樣，分分鐘教你做人，質(zhì)量工作真是一絲都不能倦怠。

• 所有人都沒想到，就沒測

之前的一個項目上，既有常規(guī)功能的迭代上線，又有特殊功能只迭代不上線，為了好區(qū)分，我們?yōu)椴簧暇€的功能做了開關(guān)，其實代碼都上去了，只是Feature沒打開。一次規(guī)模稍大的常規(guī)上線部署完成后，按照慣例驗證生產(chǎn)環(huán)境，測試人員驚訝地發(fā)現(xiàn)本該關(guān)著的功能被打開了，不該出現(xiàn)的功能出現(xiàn)了。于是連忙把開關(guān)關(guān)掉，并排查原因，發(fā)現(xiàn)是有一個數(shù)據(jù)庫腳本把開關(guān)數(shù)據(jù)導(dǎo)到生產(chǎn)環(huán)境了。從此以后，每次上線我們都會檢查所有Feature Toggle的狀態(tài)。

以上列舉了一些原因，可能還有其他更多原因。不管什么原因沒測到，終究還是讓缺陷逃逸到生產(chǎn)了。但只要我們找到?jīng)]測到的原因，有針對性地改進(jìn)，還是比較容易避免這類問題的。

場景2：明明測了，生產(chǎn)環(huán)境還出問題

常在河邊走哪有不濕鞋，測了還出事兒，這才是該懷疑人生的場景。這種情況往往問題也不好排查，通常是先趕緊排查問題，一定時間窗內(nèi)找不到問題或無法快速解決，哪怕先回滾呢，事后我們再仔細(xì)復(fù)盤。測了還出事兒其實并不少見，原因也同樣有很多。

• 以為測了，其實沒測

由于測試人員對業(yè)務(wù)理解不夠充分，或者測試設(shè)計能力不足，以為已經(jīng)充分測試了，但其實遺漏了比較關(guān)鍵的測試用例。這類問題可以直接等同于場景1中的某種情況。

• 環(huán)境差異性

由于生產(chǎn)環(huán)境和測試環(huán)境的差異性導(dǎo)致測試結(jié)果的失效。不妨腦洞一下，都有哪些因素造成了環(huán)境差異？比如軟件配置上的差異：數(shù)據(jù)庫賬戶、接口配置、服務(wù)和端口、第三方插件、集成服務(wù)、不同的應(yīng)用渠道等……或者其他硬件上的差異。這種情況下可能并不是被測軟件本身的缺陷，但由于環(huán)境差異性導(dǎo)致了測試環(huán)境通過的用例，在生產(chǎn)環(huán)境下得到了不同的結(jié)果。

• 數(shù)據(jù)差異性

由于測試數(shù)據(jù)的差異性導(dǎo)致的生產(chǎn)環(huán)境缺陷并不少見。在測試環(huán)境，測試人員選取典型的測試數(shù)據(jù)進(jìn)行測試，或許是批量生成的有一定規(guī)律的測試數(shù)據(jù)。這些數(shù)據(jù)可能用著順手每次都會被復(fù)用，也可能形成了針對特定業(yè)務(wù)的測試數(shù)據(jù)集。這是好事兒，但往往就像耐藥性一樣，這些被測軟件用習(xí)慣的數(shù)據(jù)不利于揭示新的或隱藏的缺陷。而在生產(chǎn)環(huán)境，由于用戶量大、操作不規(guī)范、真實業(yè)務(wù)的復(fù)雜性等原因，使得生產(chǎn)環(huán)境的數(shù)據(jù)更具備多樣性，這就給測試結(jié)果的準(zhǔn)確性帶來更大的挑戰(zhàn)。

• 用戶量級/業(yè)務(wù)量級差異性

這其實也是數(shù)據(jù)差異性的一種，單提出來是因為引發(fā)的缺陷不同，上一種情況引發(fā)的是特定測試用例的結(jié)果不準(zhǔn)確，或者說是普通的缺陷。而由于業(yè)務(wù)量級不同引發(fā)的往往是性能缺陷，高并發(fā)、大量堆積的業(yè)務(wù)數(shù)據(jù)造成服務(wù)中斷等，這些情況引發(fā)的缺陷往往業(yè)務(wù)影響更大，定位、修復(fù)和性能調(diào)優(yōu)的難度也更大。哪怕在測試環(huán)境進(jìn)行了充分的性能測試，也極有可能在生產(chǎn)環(huán)境并行大量其他業(yè)務(wù)的條件下，造成災(zāi)難般的性能缺陷。

• 其他集成問題

與集成方約定的上線時間、切換動作、兼容方式、集成驗證等，都有可能在測試環(huán)境和生產(chǎn)環(huán)境有所不同。因此，在上線后與集成方一起驗證集成功能的正確性非常必要。畢竟相比于自己的軟件缺陷，集成引起的缺陷可控性更差，修復(fù)周期也更長。應(yīng)盡早發(fā)現(xiàn)這類缺陷，以免造成更大的損失。

• 上線不完全

這就更詭異了，軟件功能完全沒問題，各種差異性也已排除或修復(fù)，但仍然可能因為發(fā)布問題死在線上。由于發(fā)布本身的復(fù)雜性、上線功能較多、服務(wù)間功能耦合、或是上線步驟繁瑣、手動操作過多等原因，都有可能引起上線不完整，一部分關(guān)鍵代碼沒有上線。這類問題好發(fā)現(xiàn)好排查，但著實惡心人，本不應(yīng)發(fā)生。

測試到底該解決什么問題？

先上結(jié)論，相比于發(fā)現(xiàn)更多缺陷，我認(rèn)為測試最應(yīng)該解決的問題是：（每個字都很重要）

排除?

用戶或客戶?

對軟件的預(yù)期?

和軟件真正的表現(xiàn)?

在生產(chǎn)環(huán)境上的?

差異

具體怎么做呢？可參考以下列舉逐步遞進(jìn)地完善實踐：

• 充分了解被測業(yè)務(wù)；

• 提升測試設(shè)計能力；

• 在測試環(huán)境，確保軟件業(yè)務(wù)功能沒問題；

• 充分思考環(huán)境差異性；

• 排除數(shù)據(jù)差異性，用多樣化的數(shù)據(jù)進(jìn)行測試；

• 排除或盡力約束集成方問題；

• 在預(yù)生產(chǎn)環(huán)境進(jìn)行完整的回歸測試和發(fā)布演練（在發(fā)布過程復(fù)雜或?qū)Πl(fā)布時間限制較嚴(yán)格時可選）；

• 對發(fā)布后可能出現(xiàn)的風(fēng)險進(jìn)行預(yù)判，確認(rèn)快速恢復(fù)機(jī)制；

• 采用自動化流程、發(fā)布預(yù)演等實踐，確保軟件完全發(fā)布；

• 完成上線后，立即對生產(chǎn)環(huán)境進(jìn)行允許的測試和檢驗；

• 投產(chǎn)使用后，持續(xù)監(jiān)控服務(wù)日志和業(yè)務(wù)數(shù)據(jù)。

本文就進(jìn)行到這兒了。大家遇到過哪些類似的“血淚故事”呢？歡迎分享和討論。

IDCF DevOps黑客馬拉松，獨創(chuàng)端到端DevOps體驗，精益創(chuàng)業(yè)+敏捷開發(fā)+DevOps流水線的完美結(jié)合，2021年僅有的3場公開課，數(shù)千人參與并一致五星推薦的金牌訓(xùn)練營，追求卓越的你一定不能錯過！

11月6-7日，深圳站，企業(yè)組隊參賽&個人參賽均可，一年等一回，錯過等一年，趕緊上車~??