思维成就测试---探索式测试实践篇

 

      思维成就测试

                                ——探索式测试实践篇

 

【理论篇】

          探索式测试是一种软件测试手段，不是一种具体的软件测试技术（如等价类划分、边界值分析、组合测试等），它需要测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。怎么样在日常的测试流程中实施探索式测试，同时不与公司的流程相互冲突呢？SMART原则为探索式测试提供了一个很好的建议。

• Specific（具体的）：测试需要一个具体的目标。
• Measurable（可度量的）：有明确的度量可以评估目标是否达成。
• Achievable（可实现的）：当前的目标应该是可实现的。这潜在地要求将一个大的目标分解为多个小目标，每个小目标也是具体的、可度量的。此外，跟踪小目标的完成情况也提供了整体进度的可度量性。
• Relevant（相关的）：目标要切合当前语境，符合团队利益，且不忘企业愿景（vision）。
• Time-boxed（有时间限制的）：为每个目标设定一个合理的最后期限。这是帮助测试人员在固定的时间窗口（time window）中排除不相关干扰、专注工作。

【实战篇】

      下面引入几个代表性Backend Server Bug的发现过程来解释一下探索式测试的理论，以及如何在我们的日常测试中加入这个测试手段，提高发现bug 的效率

 

   《场景1》输入参数探索式测试 Bug  InValid Params Send to GSB DC Server Cause Server Crush with signal 11

        通过日常Review其他 QA测试发现InputValue Cause server  API出现异常行为的Bug ,引入对同类型问题的思考，输入参数会导致Server 提供的API产生异常，那么 其他应用类型的Server会有这种类似问题？Server 内部是怎么样的一个处理逻辑才会导致crush？

     那么先从自己负责的Server下手，通过静态扫描Code 发现”可疑code “

 

CmResult CMs××××××Gsb××××××RequestPdu::DecodeHeaderAfterType(CCmMessageBlock&aData)

{

                .......

                size_t nPos =strKey.find('^');//可疑code

                ......

}

         看来DEV 下一个逻辑用到了Decode代码解析出来的m_user.m_strUserId但是这个 值却是依赖于特殊字符’^’作为分隔符，看来我们测试的重点就是让解析的值出错，那么肯定会造成程序的出错，到底会出什么错呢？拭目以待了！接下来为了测试出这个logical ,需要design Case走进这个分支的代码，通过背景知识了解，这个Decode方法的输入参数CCmMessageBlock&aData，是通过另一个DC GSB 过来的。Case就可以写出来了，重点是在PrimaryDC 构造一个UserId带有多个’^’InputValue. 测试结果看到了这个Bug 大家应该知道了，通过探索式的测试方法构造InputValue，针对性的找到了这个隐藏的Bug,显然这种针对性的构造输入参数，比模糊式的测试发现的bug 效率会有一定提高。

        接下来我们来看一下开发如何Fix这个问题的，

CmResult CMs××××××Gsb××××××RequestPdu::DecodeHeaderAfterType(CCmMessageBlock&aData)

{

                .............................

                CmResult rv =CMs×××××Util::GetFromUniqueKey(strUniqueKey, strKey, strSubKey);//Fix method

               .................

                returnCM_OK;

}

          UniqueKey code logic简单在这里说明一下:  not use the specail char to generate theKey use the each selfkey and selfKey length 作为一个单元；显然这种编程风格非常的规范，特别是针对Server,这样企图通过输入参数破坏程序逻辑就变得很困难了。

         最后，通过对这个bug的学习，采用探索式的思想，需要对另外4个APP(××××××××) 进行统一）静态扫描code；发现***存在Null Key issues ,这里就不再累述了。

 

 

《场景2》线程安全性探索式测试Bug  Run Two MultiThreadTool with two ****.so 1000 thread cause crush

          首先熟悉线程安全性的概念：当对一个复杂对象进行某种操作时，从操作开始到操作结束，被操作的对象往往会经历若干非法的中间状态。调用一个函数（假设该函数是正确的）操作某对象常常 会使该对象暂时陷入不可用的状态（通常称为不稳定状态），等到操作完全结束，该对象才会重新回到完全可用的状态。如果其他线程企图访问一个处于不可用状态 的对象，该对象将不能正确响应从而产生无法预料的结果。

        那么QA怎么测试一个程序是否具备了线程的安全性呢？需要通过reviewcode? 显然这是一件很困难的事情，而且效率不一定会高。因为个人感觉多线程的编程本来就比一般的编程要难很多，需要注意的细节多很多。既然不能用白盒测试发现问题，那么怎么去测试呢？黑盒？

        下面是我在多线程测试中的一些探索，结合这个bug的发现过程和大家分享一下。***.so一个C++ NativeClient ,提供给Nginix ***Process 使用，考虑到这个NativeClient 可以启动多个连接，多个实例，那么对于测试者来说直接把这个 NativeClient 想象成一个黑色的盒子，测试预期是肯定这个“黑盒子“支持多线程。通过在这个NativeClient加上一层多线程的应用场景，通过多线程模式测试“黑盒子”的内部的线程安全性，看是否和QA预期结果一致。测试方案确定，用多线程测试多线程，这就需要QA写的多线程自身要具备线程安全性，才能正确达到测试的预期结果。

以下是我当时为了测试开发***.so写的一个C++ 多线程的测试程序。下面摘录控制线程的几个主要方法，相信大家都不会陌生。（线程实体就不再这里摘录了）

#include "pthread.h"

class Mutex

{

public:

    

     static void pthreadMutexInit(pthread_mutex_t* aMutex_t);

     static void pthreadCondInit(pthread_cond_t * aCond_t);

     static void pthreadCondWait(pthread_mutex_t * aMutex_t,pthread_cond_t * aCond_t);

     static void pthreadCondSignal(pthread_mutex_t * aMutex_t,pthread_cond_t * aCond_t);

     static void pthreadCondBroadcast(pthread_cond_t * aCond_t);

}

写好测试程序和makefile 文件，在linux 平台编译成了MultThreadTool 进行测试,通过测试发现 上述bug,

      接下来看一下 , 如何解决这个问题Put scheduleTimer,cancelTimer, onTimeout in sending thread instead of callback thread. 这样做的好处简化CallbackThread 要处理的逻辑，让网络线程处理这些异常的条件，比如刚刚由于TimeOut 导致的crush问题。通过这种测试方法，测试线程安全会更高效，在提高QA 测试技术的同时，也最大程度的提高发现这种线程安全性的肯能性。刚刚讲的只是由于线程安全的一个方面，用同样的方法实际上还测试了线程安全性典型的另一个bug,线程间抢占资源导致的死锁等等问题

 

 

 

[总结篇]

        这是个人探索式测试的第一次亲密接触，结合正开展的项目把理论变成了实践。最后总结一下 “探索式测试是一种软件测试手段，不是一种具体的软件测试技术，但是它需要多种测试技术手段的支持”希望这篇文章能帮助QA提高日常的工作效率,同时帮助DEV 减少同类型错误的二次发生。

文章获得《测试人》杂志评比第一名

被51Testing 转载http://www.51testing.com/html/08/n-809608.html