软件集成测试(IT)在项目中的实践和思考

前言: 在软件测试基本原则中一直强调要尽早测试,但是在实践层面真正落实的公司很少,大部分公司的做法还是围绕传统的黑盒测试来进行软件质量保证.在网上搜索集成测试多半以概念描述为主, 本文通过对实践项目的总结给出了一些IT测试的通用方法.

 

        这几日在对一个测试项目作项目总结,对于IT测试这块发现了一个很有意思的现象, 一方面对应于IT 的测试用例通过率非常的高(>90%), 另外一方面IT 发现的Bug数又急速增加.追本溯源,发现引起这一现象的直接原因来自以下两点:

(1) 开发人员进行了简单的架构设计之后就直接coding了,IT 测试人员依据这些code来反向设计并设计出IT 测试用例.这样的方式设计的测试用例往往只是重点关注了代码逻辑问题（Code error, Code missing）而忽视功能设计中存在的问题(Design error, Design Missing).

(2)IT 测试人员在测试过程中对功能理解的深入，并积极拓展测试思维，从而发现了周边更多的Bug。

 

以上的情况其实体现了现时很多开发团队的现状,无论在何种开发流程下----瀑布型,迭代型或者目前大行其道的敏捷更是这样,时间紧,任务重,根本没有时间来做详细的设计.

        对于软件测试而言,大多数的做法还是以传统的黑盒系统测试为主,事先根据需求规格定义来设计详细的测试用例,然后后期执行就可以了.但是对于IT测试来说对应的设计文档没有情况下就不能像系统测试那样先设计出各种测试用例然后执行.必须考虑一个更有效的IT测试流程和方法.

 

 对以后这类项目的实践思考（这类项目是指除了代码以外没有很多的文档可以参考的,尤其是设计文档的开发项目）

（1）积极沟通，要求完善和维护架构设计文档以及关键功能设计文档。实践表明，大部分的开发团队如果没有进过设计而直接coding的开发项目,往往会在几次重构后慢慢偏离原先的基础架构. 如果IT测试人员不理解项目的基础架构就很难开展行之有效的测试,所以维护一份基准的架构设计是非常重要的,这是有效沟通的基础.

（2）读代码，理解模块与模块间如何交互并实现功能.在这一步不强调一定要象传统的测试方式那样先写出大量的测试需求/测试用例,只需要写出功能的正常调用流程(Normalsequence).在设计normal sequence时重点关注以下几个问题:

    A.模块和模块接口间的调用是否符合架构上的设计？有很多时候代码会并不完全遵从架构的设计，比如跨层的调用等等。

    B.如果存在某个文件下public接口函数在sequence中被重复调用，有可能存在代码结构设计的缺陷。

（3）围绕normal sequence 测试（正常系，异常系）。

         A.第一步从功能的角度对Normal sequence 进行测试。现代的软件开发都是协同式开发，很多时候虽然代码完成了，但是功能并没有完全实现或者有部分的错误。在笔者所总结的项目有3%左右的bug属于这类。

         B. 围绕normal sequence，从abnormal data的角度去考虑基本流中的异常情况。通常情况下，开发人员在实现一个功能的时候都是一个很正向的思维，通俗的讲就是找到一条从起点到终点的路，路上的各种岔路都会被暂时忽略。即便是一个非常资深的开发工程师也不可能同时关注3条以上的处理路径，所以如果事先没有很好的设计，写代码过程中很难面面俱到的把所有的异常分支都考虑到，这也是IT测试中最容易发生bug的地方。笔者所参与的这个项目有60%以上的bug 属于这类。比如以下两个bug：

              Delete a device that is non-exist record in DB will causecrash(No.198)。

               Save the same device in DB at multi-times will cause error（No.151）。

      当你对着代码想象不出更多异常分支的情况下，你可以从Public的数组为空，指针为空，对象为空，事件为空等联系功能点启发更多地思考。

       C. 不同条件下normalsequence的测试。

          由于UI触发事件，同样的sequence 可能有不同的触发方式。对于比如open（）…close（）等sequence尤其需要验证在不同UI 启动方式下是否正常。很多时候往往会发生sequence错误导致crash等问题。

（4）围绕产品特性和开发平台及开发语言的测试思路

    笔者的项目是采用的C#开发基于.net 框架的一个视频管理系统，对于memory leak和稳定性测试时非常必要的。这时因为C# 利用垃圾回收机制来释放资源，但是并不是所有的资源会自动释放，比如文件句柄，rtsp链接，数据库连接等。另外由于GC不会立即释放，所以在反复操作时就可能因为内存不足而发生错误。

        鉴于这一点所以需要选择一些需要大量的资源开销，以及频繁进行内存申请和释放的normal sequence 进行反复的测试。

(5) 从整体架构的出发一些通用测试思路

    笔者的项目选用了SOA的架构思想，是否符合SOA的思想也是一条重要的测试思路，比如：同个网内可以存在两个一模一样的service吗?如果service坏了不会让client也坏掉。多个client去访问service不会让数据不一致等等。

 

       以上是对IT测试通用思路的一些总结，当然不同的项目还有很多方面需要注意的，还需要根据项目实际做一些调整。