我的第一个模块接口测试

通过近一个月的不断努力，今天终于把接手的第一个模块给结束了，虽然自己还是有点摸不着头脑，感觉好多东西乱乱的理不清，但毕竟是觉得该做的都做了。恩，怎么说呢，这个模块是我步入测试行业的第一位顾客，它让我从一个什么都不懂的门外汉逐渐了解了测试的意义，所以在收尾阶段总想着应该为它做点什么。

测试，这个对我来说陌生又熟悉的词汇，想想刚开始接触那会的心情，犹如一个天真的小女孩遇到了自己最喜爱的玩具，它让我对自己充满了信心，让我下定决心要好好干一番，虽然对它究竟是个什么一点都不了解，但是有时候就是这么奇怪，当你觉得自己要做的时候就觉得没有什么是做不到的。

回想一下这个模块的整个测试流程，不禁让我感到一阵心酸。

首先，在需求分析阶段我就卡了壳。唉，谁说每个项目都有详细需求说明的，对我来说，想要找到现成的需求真是太难了，当得知自己可以开始进行正式测试时的那份兴奋在我拿到第一手资料之后就再也不复存在了，资料显示的只有接口说明，参数定义以及返回值，其实这些东西都只是最基本的，想当初自己做开发的时候也是会注释说明的，只是单单就这些东西让我去搞测试还远远不够，但是又没有其他关于需求设计的东西。这种情况下只能靠自己了，因为这个模块涉及的全部是模拟windows下的一套消息机制函数，所以我尽量去理解windows下的那一套消息函数，尽量让自己从中搜取到有价值的需求。值得庆幸的是之前我有存档很多关于编程的资料，其中《VC++深入详解》这本书真是没少帮我忙啊，总是在最关键的时候派上用场。恩，最后呢，总算是没白费力气，终于大概了解了这套函数到底是怎么一回事，之所以说大概了解是因为windows下的消息机制其实真正研究起来简直是太复杂了，以我现有之力是不可能完全参透的，再说也没那个时间啊。

了解了需求之后我开始分析具体功能，而此时又遇到了另外一个问题，我对函数执行的具体流程还不甚了解呢，想想如果有一个流程图来标示这些函数之间的调用关系或者使用途径的话或许能让我更好的进行测试。因为函数不是自己写的，真心觉得流程这个东西如果不彻底了解函数是无法清楚的描述出来的。

有了前面这些铺垫接下来应该是对整个测试做一个方案性的文档，以记录此次测试中的所需所求。虽然这是我第一次写这种东西，也真心不知道该如何下手，但退缩似乎也不是我的强项，所以就只能硬着头皮往前冲了，还好最后没有头破血流，人还很完整，目的也达到了，也许并不是很理想，但终归是做了。

恩，接下来是重点了。因为是接口测试，所以接口参数是重点。通过分析几种设计测试用例的方法，觉得等价类划分和边界值足以来指导设计测试用例。有了目标就不会那么迷茫了，现在要做的就是对每个函数的接口划分等价类，虽然也是第一次设计，但是凭直觉我将自己能考虑到的情况都罗列了一下，虽然不确定一定能行得通（这个后面测试的时候就知道了），但既然想到了当然不能放过。然后根据对这些功能的分解又详细设计了测试用例，综合考虑了边界值、错误处理等情况。

对于一般的测试人员来说，到这一步基本上应该是执行测试了，但我却有更任道重远的任务（也许这也是我任务中永远逃不掉的一部分），写测试代码。唉，一想到这个就很纠结，虽然本是开发出身，但毕竟经验有限，写代码真不是我的强项。可是没有办法，遇到这种情况你只能往前，不能退后，因为一退你就输了，而且很惨。这个测试代码着实费了我不少功夫，虽然这个模块确实没什么难的，只是一个框架，但具体使用起来还真是要分分清楚。我由一开始的单线程无法执行到纠结了两天之后又改为多线程，再到各种设计，身心真是不知经历了多少痛苦轮回。

测试代码完成之后可以说是基本没什么技术性任务了，接下来就照着测试用例一步一步执行好了。本想着是这样，却没有考虑所有的前期工作都只是一个第一次接触测试的人做的，所以很多东西就无法执行，也就是说个别测试用例不足以拿来测试。经过我个人的反反复复，不断重修，终于在最后算是完成了功能方面的测试。

最后就是对这个模块中各函数进行一个小小的性能分析了，查看各函数执行时的效率如何。这算是整个流程中最简单的了，我通过前期准备的性能分析工具AQtime对每个函数的执行做了个统计分析，最后形成最终报告，也算是圆满结束。

总结来看，虽然模块不是很复杂，功能也易于理解，但对一个初入测试的人来说，从了解需求，画模块流程图，编写测试方案，对功能进行具体分解，设计测试用例，编写测试代码到最后的执行测试以及编写测试报告，真的觉得自己像是经历了一场惨烈的战斗，而且还是一个人的战斗，虽然目前来看自己还是有点迷茫，但终归是迈出了第一步，相信自己以后还会做的更好，最终攻克模块测试这一大难关，继续前驱直入测试的不同领域，加油！