<dd id="dbjz6"><noscript id="dbjz6"></noscript></dd>
    <th id="dbjz6"></th>
      1. <dd id="dbjz6"></dd>
        1. 像用戶一樣測試,別掉鏈子

          掉鏈子”是一句俗語,比喻在關鍵時刻出故障,或者重要的事情本該做好卻沒做好。

          “掉鏈子”的說法來自于自行車:在騎行過程中,鏈條通過鏈輪傳送,帶動車輪滾滾向前。當鏈條從鏈輪上脫落,就無法進行傳動,失去了對車輪的控制,腳蹬子就會空轉,自行車就會失去向前的動力。假設這種情況發生在關鍵時刻,要趕時間或者正在過馬路,就會讓人格外惱火。

          像用戶一樣測試,別掉鏈子

          回到軟件場景,關鍵時刻掉鏈子,就好比上線后遇到重大缺陷,需要緊急熱更或回滾。造成的后果也很類似,那改進的措施會不會也類似呢?我們一起來看一下。

          掉鏈子的四個后果

          功能失效:自行車失去動力無法向前,需要上鏈子才能繼續

          → 軟件功能失效

          影響心情:我不只一次看到一邊上鏈子一邊氣急敗壞的場景

          → 降低用戶體驗

          耽誤工夫:趕時間的情況下,上鏈子可能造成延誤

          → 功能延期使用,造成業務損失

          安全問題:要是正在加速猛蹬的時候突然掉鏈子,輕則腿抻一下,勁大了沒準能掉下去

          → 軟件安全:隱私、匿名、盜號等

          掉鏈子的原因

          路況不好,過于顛簸 

          → 基礎設施較差,運維磕磕絆絆

          負重過大,導致后輪不正或變形 

          → 一次上線范圍過大,團隊不堪重負

          鏈條和輪盤不在一條直線 

          → 團隊內耗,一盤散沙

          鏈子松了

          → 需求膨脹,開發點數膨脹

          缺油

          → 再衰三竭,缺乏士氣

          可能的修復方式

          避免顛簸路段

          → 改造基礎設施,提升運維效率

          避免過度負重

          → 留有一定的緩沖區,用于需求估點不準或緊急問題修復

          調整鏈條和輪盤至同一水平線上

          → 建立積極、公開透明的團隊文化

          緊鏈條,或者把鏈子反過來,外圈換到里圈用

          → 控制膨脹,協調資源

          上油

          → 團隊激勵

          假設我現在遇到一個團隊(還真遇到過),擁有理想的基礎設施、理想的文化、理想的人,是不是就能保證不掉鏈子呢?可能在一定程度上會降低掉鏈子的頻率,但確實保證不了不出問題,要不怎么說測試是門玄學呢。

          通常情況下,這類團隊質量內建做的相對較好,新開發的功能質量較高,測試能力也較強,能夠保證本次上線新開發的功能是完全正常的。但沒想到重大缺陷也是劍走偏鋒,你越是想不到,越是認為沒問題,越是穩定運行好幾年的功能,往往越容易在關鍵時刻掉鏈子,原因五花八門,有時候匪夷所思到想破頭都想不出來,完全無法預防,只能采取事后干預。

          排除掉那些不可預知的因素,還有兩個常見的原因,一是功能被我們破壞了,二是功能被其他人破壞了。這兩種情況都是可以通過上線前的回歸測試來預知問題的。

          回歸測試,顧名思義,得先有功能,也有針對功能的測試,然后才能回歸。每個團隊都有一些積累下來的回歸用例,我們把容易出問題的、涉及產品核心能力的、一旦出問題后影響慘重的功能,全部并入主流程回歸用例集。在產品初期,主流程回歸用例集的范圍可能不是很大,手工測試大概率能快速覆蓋掉。

          隨著產品功能的不斷完善,上線和運營的經驗不斷積累,主流程回歸用例集的范圍會不斷擴大,直到手工測試無法快速覆蓋,這時自動化測試就要發揮重大作用了。我們把越來越多的回歸用例用自動化方式來實現,并集成到持續集成流水線,設置一定的觸發機制,比如每天早上十點定時觸發,或者每次代碼提交均觸發,視需要而定。這樣在一定的觀察期內,一旦有歷史功能被破壞,我們就會在第一時間知道。

          有些場景下會被這個用例集叫做“常規回歸用例集”,或者“程序健壯性測試(Sanity Test)”,也有的團隊會以端到端自動化測試(E2E)的形式來進行回歸。名字并不重要,我們只需要知道,這都是回歸測試的范疇,只不過是實現的手段和范圍有所區別而已。

          像用戶一樣測試,別掉鏈子

          在進入迭代時,已有的主流程回歸用例集是回歸測試的輸入之一,輸入之二是本次迭代的回歸用例集,包括以下內容:在本次開發的新功能中,哪些可以納入常規回歸范圍的用例?亦或是本次修改影響到的功能范圍有哪些需要回歸?主流程回歸和本地迭代的回歸一起作為上線回歸用例集。

          確定了回歸范圍后,需要測試團隊以一定的頻率,多次進行回歸測試。每次的間隔最好留出一定的時間來定位和修復問題,并且在修復問題之后,統一進行下一輪的回歸測試。經過多輪回歸測試后,上線前能發現的缺陷就發現的差不多了,將這些缺陷進行評估,若符合要求,也一并納入回歸用例集,就像滾雪球一樣,把用例集滾大。

          然后我們就迎來了上線:上線部署完成后,也需要以線上允許的方式再次回歸一遍。

          回歸測試不是上線了就完了,上線后,如果有線上重大問題,或者以前的已有功能被破壞,測試也需要把這些缺陷進行評估,并補充至回歸用例集。

          回歸 · 三大原則

          • 凡變必測:一有變化必須測試,并評估變化范圍,進行相應的回歸測試。
          • 凡測必補:一有手工測試,不管是新功能還是修缺陷,必須進行評估,明確是否有必要補充進回歸測試用例集中。
          • 人機搭配:自動化測試最有效的場景就是回歸測試了,建議能自動化的用例都自動化掉,否則時間長了回歸起來人要崩潰的。

          可以說,遵循以上三條原則,基本能保證回歸測試的持續更新和持續有效。

          本文講的是回歸,為什么叫像用戶一樣測試呢?原因是,當我們在思考回歸測試的范圍時,需要具備用戶視角。假設我是用戶:我最希望使用的產品功能是什么?哪些功能給我帶來最大的價值,能幫助我帶來收益或節約時間?哪些功能有問題是我完全不能容忍的?哪些功能我并不常用?哪些功能可有可無?思考這些用戶視角的問題,有助于我們確定更精準的回歸測試用例集,最大程度的做到關鍵時刻不掉鏈子。

          不是有本講哲學的書叫《禪與摩托車維修藝術》嗎?本文的另一個標題就是《回歸測試與自行車修理并沒有藝術》。專業受限,文中提到的修車內容,希望各位修車老手不要介懷。

          再分享一個有意思的事,我感覺共享單車似乎很少掉鏈子,又怕是個人錯覺,于是便在小范圍內做了一個關于共享單車掉鏈子感受的調研,分享給大家:

          調研:大家“覺得”共享單車容易掉鏈子嗎?容易扣1,不容易扣2,不騎的請忽略。

          像用戶一樣測試,別掉鏈子

          由此想到一些有趣的點:部分年輕的小伙伴可能沒有除了共享單車以外、高頻使用其他自行車的需求,不像80后可能需要長距離騎行上學或通勤,所以無從對比掉鏈子的頻率。也有部分小伙伴開車或坐車通勤,并不騎車,僅有的幾次騎行不足以作為科學的統計數據支撐,所以我在調研里加上了強調主觀感受的詞語,所以無所謂品牌,你們“覺得”就好。

          戴上用戶的眼鏡,確實看到了很多作為測試看不到的東西,而這些東西竟有助于對測試的理解,實在是有趣。請借我一雙慧眼吧,讓我把這紛擾看的清楚、明白、真切。

          源自公眾號   圓小豆的美夢工場

          ?

          留言

          chinesemature老熟妇oldman