通信測試一年來的感受

trace & trouble shooting 一點想法

   我們曾經或者正在參與這個或者那個項目；我們也曾經或者正在搭建很復雜的測試環境；不過我們一定有這樣的感受：從一個項目的起始到結束，搭建和維護測試環境總是我們永恒的工作內容。

而我們在搭建或者維護一個測試環境的時候，隨著網元的種類和數量的增加，其復雜的程度也就越高，一些不可控因素也就越多。復雜度提高了意味著搭建和維護的難度增加；不可控因素越多則意味著測試環境可能很脆弱。

像我這樣的經驗能力尚欠的測試人員常常疲于應付，不過如果向團隊里那些優秀的同事們看去，他們則顯得鎮定和自信，豐富的經驗固然是一方面，卓越的trace和問題定位的能力才是他們處變不驚的根本。而這種能力是建立在對各個系統，各個領域，各個網元的深入理解的基礎之上的，相信他們也是通過平時的學習，思考，總結，積累而成就的。

至今日我已進入公司一整年。一年來參與了幾個項目，有這樣一些感受，可能比較幼稚，希望能與大家一塊討論。

1、ant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">              trace 和 trouble shooting的先后

當我在測試sip-oneip-stratey的時候，需要在各種呼叫場景中來驗證one-sip策略，比如sipi，c4，cw，hold，tps，conf，sylantro。那個時候對各個網元不清楚，不知道sylantro是什么？也不知道media-sever，而且還剛剛接觸ears。所以在出現問題之后，我能做的就是去閱讀trace了，而且是精讀（水平高了才能略讀），這些特服動不動就是幾千行，但是沒辦法就是一遍一遍的去看，為了更方便閱讀這些trace，

寫一些小的腳本去掉消息中的心跳等無用消息（那個時候還不知道mgrep可以輕易實現這個功能），高亮顯示sip，h248，s12各個重要fmm和ears trace中的重要字段，添加注釋等。漸漸的，unix側的，s12上的，或者ears上大體的呼叫流程比較清楚了，能夠很快判斷出那個環節出了問題。比如一個sip三方通話，拍叉簧后聽不到hold-tone，對我來說，我應該關注拍叉簧這個動作發生時說產生的trace，然后我應該關住又沒有拍叉簧有沒有上報上來，sip消息中有沒有拍叉簧這個動作對應的特殊的invite消息，有沒有送到s12去處理，如果s12沒有釋放的話，有沒有發invite到meidia-server，media-sever最后是要給被保持的用戶送hold-tone的，所以media-server和sip，iad會有sdp交換的流程。

        對于ears也是如此。剛開始的階段，大家閱讀ears 的trace何等的艱澀，只能對照pcgui上每一個的值，一遍遍的去讀trace，去了解ears是如何進行路由數據的分析的，ears如何調用各個表的，各個表的作用是什么。一定的積累之后，多數情況，我們只需要看outgoing的值就可已判斷出問題了，譬如地址屬性不是我們所要的，號碼變換沒有實施，did值不對等。

        一個稚嫩的測試人員（我）常犯的錯誤就是，每每看到某個cause在某個網元的trace中出現之后，或者捎加分析之后，然后報給

相應的P.O,心理還得意：哈哈，問題沒有block我手上。最后的結果往往是丟人和恥笑。

        所以我覺得，當我們測試人員處于一個不了解的測試環境，不熟悉的網元的階段時，應該是先重視閱讀trace，然后才是定位問題。通過前者，測試人員對環境相當的了解之后，就可以做到選擇性的少量的必要的trace就可以迅速而準備的進行問題的定位了。

2、              trace skill 與 trouble shooting

       在對環境比較清楚，尤其在維護環境的階段，好的trace skill有助于提高我們的工作效率。這些skill很多，很小，主要體現在各種工具的使用上面。比如手機ct trace的時候，可以用mgrep濾除心跳，trace文件自動添加日期或者進程號以便管理；用trace-filt對setrace

分揀出我們所需要某個板子的一切信息；做好收集下來的尤其是一些

重要階段的trace的注釋，可以用來做對比，參考，跟蹤；tcpdump這個收trace的工具在處理sctp偶聯不活，以前基本的信令交互都可以看，當然如果側重于后者，可以用tcpdump收下包后交給ethreal去分析；ndebug 統計、過濾msu；至于s12側trace相關的工具也很多，建議參考覽海濤總結的文檔，里面總結了各個重要的fmm id，以前各種trace的方法。普通的trace比較簡潔，消息流程清晰，但消息的內容，除非你很熟悉的，大部分不清楚。Minitrace 每個消息體所攜帶的信息非常多，但整體凌亂，消息流程不清晰，好多新的消息也解不出來，只能通過hycon來收集。各有缺點。平時收普通trace就行了，除非你很想了解某個消息的內容；當然可以自己寫個腳本，

把譬如e3b中很多很有用的mbid，自動添加注釋，把minitrace里面有用的信息，甚至你自己想要添加的信息加進去就行了。比如你關心e3b與ears交互的情況，希望在e3btrace中很直觀的看出ears是怎么吃位的？在ears numbering那里吃了幾位（ears nly=no），destination

Digit prep那里吃了幾位？ears送出的did是多少，did是怎么吃位的。。。。。。那么你可以在e3b trace中對這些信息添加注釋，一目了然。這在對e3b和ears 問題定位時非常有用。

     還有這樣一種情況，也算是skill吧。在網元很多的時候，比如有個呼叫從n44的h248用戶到n35再到青島ims，n44與n35不是sipi，是普通的isup，話路經過兩個7510，然后在這個環境上打三方通話這些業務。華羅庚有個“二分法”，我們可以借用借用。當環境出現問題之后，先找中間n35，看它是否收到來自n44的iam消息，如果收到iam消息有沒有送給ears，或者n35是否收到來自ims的invite消息，如果收到了有沒有交給s12側繼續分析�？纯磫栴}在n35上還是左側抑或是右側�？傊�網元很多，收trace定位問題時注意規劃，優化方向的選擇。

       Trace skill太多了。每個人都有自己的skill。也是個慢慢積累的過程。

      3．Technology & trace and trouble shooting

         不知道technology用的準確不準備。我的感受是，尤其是trouble shooting 階段知識是最重要的，這是考驗我們測試人員的知識面的寬度和深度的階段。除了那些優秀的同事外，像我這樣的目前怕是較多的仍然是trace，了不起是locating。然后交給P.O了。Locate對了算他們的運氣，locate錯了，由他們自己去shooting好了。P。O要是忙得要死的時候，心里一定氣得要命。當我們不可能達到他們那個深度，但起碼達到測試崗位的要求。

      一些通信行業支撐性的知識，我的感受，自己還很缺失。干了多年的通信，說真的，我對ss7究竟有多深呢？大概可以應付夏雷面試時的選擇題罷了。當我需要在inet編消息，當我需要給流量發生器選擇合適的msu的時候，當我面對4條2m link 信息流量不均衡的時候，當我看到dnua消息的時候，其實都是7號領域的問題。有點偏題了。

     我覺得，為了更好的更好的掌握trace&trouble shooting之前，我們應該注意提高自己各個領域的知識。我們應該對h248協議非常清楚，它是如何定義網關的一些行為動作的，常用的包的類型。找不到資料就去找P。O妹妹請教，把它記下來。還有sip協議，結合平時收下的trace。Sigtran里的m3ua,m2pa。s12里的common call handling

對我們做mgc的人來說很重要。Ip領域的知識當然很重要了，考了ccna差不多夠用了。開源的東西也要學，因為我們交換機，sg這些設備都是使用linux平臺的，這個領域的知識對我們來說也是非常有用的。所幸現在資料網絡上太多了，只要想找一定能找到的。

      Technology 對提高trace和trouble shooting的能力應該是指數級的，我時常感到提高technology的艱難，可嘆少壯不努力，留作今日追啊。（想起來謝亞龍的詩了）不過每當在某個領域有所提高的話，

在閱讀trace和定位問題的時候，或者回顧以前碰到的問題的時候，就會有一點豁然開朗的感覺。

4、              心態、思維、信念和trace & trouble shooting

     記得以前曾經看過一篇同行寫過的文檔。他提出這樣的觀點（大概）：測試人員應該有一個信念，永遠不會存在完美的產品，只是還沒有找到它的bug而已，或者還沒有找到正確的思路和方向而已。這句話不是老江湖說不出來。想起這段時間做sg load test，每次出現壅塞，或者一打流量就會有gap出現時，就郁悶的要命。周國盛說得對，“要冷靜、耐心”。這應該是tester正確的心態吧。說到思維，應該是前者有點關系，心態不好的情況下，思維會混亂，然后就是毫無目的和策略的重復，或者敷衍了事。觀察其他出色的同事，他們的思維是那種很開放的，測試環境在最糟糕的情況下，他們會拿起筆，畫出示意圖，看看哪里有遺漏，哪里可以改善，出現這樣的莫名其妙的trace是怎么回事？如何簡化環境，盡可能排除影響的情況下，再去收相關的trace看看情況又是如何。維護測試環境的方法很多倒是和技術支持的思路差不多，其實的無非都是分析，排除，歸納的智慧。至于說

信念，應該是測試人員tester的職業生涯的高級階段了，希望吾生應有期。

      以上是我做測試形成的一些感受。比較混亂，最糟的是沒有

結合具體的案例。還好郵件里要求不高，可以寫感受的。

       今天是9.4。去年的今日我來報到。算是一個好日子吧。放到偶博客上去算了紀念。