通信测试一年来的感受

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。去年的今日我来报到。算是一个好日子吧。放到偶博客上去算了纪念。