标签：
加入新员工训练营的有开发也有测试，大家的coding水平参差不齐。
我发现一个问题，就是当面对一个新学的语言时，我们这期训练营里除了我以外所有的测试人员甚至一些开发人员都不会读代码，不知道怎么去读，或者虽然读了，却一知半解，毫无效率。
首先分享一下我读代码的方法供从手工测试转自动化测试的同学们参考（可能各人思维模式不同，仅供参考）：
我读代码时的思维方式属于一级一级严密的逻辑思维，所以一旦我的逻辑链中间断掉，我就不能理解这些代码。
一句话总结：先跑起来，再调试，理解原理，掌握细节。
第一步，看有没有文档。遗憾的是通常要么么有，要么不全。但通常我们能找到一些参考资料，可能来自某些文档也可能来自某些人。
在开始之前先收集所有可利用的资源，这个习惯在这次训练营里成功让我从scrum master处得到了一个“可以不看的需求文档”和对于整个工具架构的大致介绍。
后来我发现这个“可以不看的需求文档”在我的编码过程中起到了巨大作用， 并且令我惊讶的是，除了我以外，其他人竟然在没有这个文档的情况下硬看代码，于是他们虽然可以看懂一部分代码，但却无法完全把这个工具转化成“和自己写的一样”的内化知识。
第二步，看有没有单元测试。有单元测试的，那么就可以执行单元测试。看看结果。看看测了哪些东西。有很多人不知道单元测试框架，实际上，不管你用java，c，c++，python，ruby，还是随便什么语言，据我所知绝大部分语言都有自己的单元测试框架，或者叫单元测试执行器。这些名字通常叫xxxUnit的东西，全都是一样的原理。随便学一个，其他都一样掌握了。如果你是测试人员，建议你至少掌握一钟单元测试执行器，比如java语言的testNG。有这个基础的人才能搞自动化测试，不要等老师来教你，教比学麻烦多了。
第三步，找独立模块。比方说我们的中间件测试工具里，对消息的编码解码部分调用了第三方库来做。而对第三方库的调用和一些数据结构的准备，就是一个相对独立的模块。并且我发现这个独立的模块还有自己独立的单元测试。所以这就是我阅读代码的突破口。
第四步，从突破口调试代码。我从编码解码的单元测试文件里开始单步执行他的单元测试，于是我看到了整个代码执行的全过程，消息是如何从一段英文转化成指定数据格式的对象，再以怎样的方式定义消息头设置消息长度，传怎样的数据给第三方库，以及最后编码的结果如何去验证。这一步对后续工作的意义重大。
第五步，看核心模块。我们这个工具的核心模块是消息收发的模拟器。可以把他理解成单元测试里的桩的概念（stub）或者驱动（driver），也有人喜欢说这是类似于mock的东西。
这个核心模块做了几件事：
1，建立socket连接，等待客户端连接他。
2，使用多线程，支持复数的客户端连接。
3，和客户端之间进行消息收发。调用了我前面看到的消息编码解码独立模块，把消息封装好，然后通过socket连接把消息发送出去和接收回来。
4，建立消息队列，把和复数客户端的通信的消息序列分别存放。
5，即时处理需要立刻回复的消息。
6，生成一些需要自动生成的消息字段。
7，定时发送一些类似于心跳消息的东西给客户端，以及处理对方发过来的这种消息。
第六步，从总的单元测试开始，一个一个单步调试。
第七步，为了证明我完全读懂了，我自己画了一个结构图：
整个工具我划成4个模块，
1.消息编码解码
2.模拟器及其相关api封装，调用消息编码解码模块来发送消息
3.robot关键字，调用模拟器提供的api发送用户想发的消息
4.单元测试
并且对每个模块内部的逻辑，画了详细流程图，从哪个类到哪个类，了解清楚单元测试的执行中每一步骤的流程和消息是怎么组装、怎么编码、怎么发送、怎么接受回复的。
全部读完，我一共用了越24小时，也就是3天（每天8小时）。至此整个测试工具不说了如指掌，也已经掌握得八九不离十了。再看我们要做的任务，我的感觉只有两个字：简单。
此时我们的其他成员（已读了5+3=8天这些代码）仍在埋头苦读，最令我不解的是，在我之前，没有人尝试去执行单元测试，也没有人去问训练营的导师这个测试代码可不可以执行。
有开发人员能读懂核心模块，但每个人都在重复读，没有形成合力。至于测试人员则都根本不知道在读什么东西。
于是我提议大家把自己读的东西开会分享，让完全不知道在读什么东西的人也能对代码有一定了解。
标签：
原文地址：http://www.cnblogs.com/sdet/p/4233023.html
