Unix下自动化测试实践

发表于：2007-11-07 16:32

作者：方耀来源：51Testing投稿

// 当resultNo的值不为0时，还需打印resultInfo信息，以供查问题
   int_start=str_inputLine.indexOf("ext:resultInfo");
   int_end=str_inputLine.indexOf("/ext:resultInfo");
   if(str_inputLine.indexOf("ext:resultInfo")>=0){
    if(str_inputLine.indexOf(">0<")<0){
     outlog.println(xml_file+" : "+str_inputLine.substring(int_start-1,int_end+16));
    }
   }
   outlog.println();

        }catch(IOException ex){
        ex.printStackTrace();
        outlog.println(xml_file + " : this file is failed!");
        outlog.println();
        }
    }

    // 同步拷贝文件流到字节输出流，并保证在拷贝过程中，这两个流不受其他线程影响
    public void copy(InputStream in, OutputStream out) throws IOException {

     synchronized (in) {
       synchronized (out) {
         byte[] buffer = new byte[256];
         while (true) {
           int bytesRead = in.read(buffer);
           if (bytesRead == -1) break;
           out.write(buffer, 0, bytesRead);
         }
       }
     }
    }

【举例3】
背景：
        系统M有一后台服务，是该系统的最前端模块，它负责接收并处理基于国际通用的X协议包。而该系统将处理多达200多种的业务组合，接收不同的业务包，处理返回的结果就不同。但有一点需要注意，对于同一个包，在基础数据不变的情况下，系统对它的处理返回结果也是不变的。
工作平台：
  OS：Solaris 9.0
  DB：Oracle
  Develop Language：C++

测试工作场景：
        构建不同业务包，用开源的客户端发送，然有用肉眼校验返回的结果是否正确；
测试困难分析：
        每次系统回归，都要对200多种业务进行发包回归测试，需要进行大量的手工劳动；
        现有的业务还在增加，也就是说，手工回归的工作量会继续慢慢增大；
需求分析：
        1、批量发送所有的业务包数据，并保存系统处理返回信息；
        2、可以用一次系统回归测试的正确结果做一个校验基准文件，以后每次回归，可以把当次测试的系统返回信息同基准文件进行比对；
工具实现步骤：
        1、对于需求1，由于这是后台发包，而且有开源的客户端，我们在Solaris 9.0服务器上编译一个客户端，然后用shell编写脚本，循环发包即可，但得事先把测试数据准备齐全和正确；
        2、对于需求2，就是对shell脚本的要求了，主要用到了head、perl、diff等命令；
        需要注意的是，这个脚本完成后，只需要对不断增加的业务测试数据进行维护即可；

部分代码：
  for i in $FILE_LIST
do
       while read LINE
        do
                ACCOUNT=`echo $LINE | awk -F@ '{print $1}'`
                FILE_NAME="$ACCOUNT"_"$i"
                ./radtest $LINE > $TEMP_DIR/$FILE_NAME
                ID=`head -1 $TEMP_DIR/$FILE_NAME | awk '{printf $5}'`
                IPPORT=`head -1 $TEMP_DIR/$FILE_NAME | awk '{printf $7}'`
                #sed 's/'"$ID"'/999/g' $TEMP_DIR/$FILE_NAME > $TEMP_DIR/$FILE_NAME.bak
                #rm $TEMP_DIR/$FILE_NAME
                #mv $TEMP_DIR/$FILE_NAME.bak $TEMP_DIR/$FILE_NAME
                perl -pi -e 's/id '"$ID"'/id 999/g' $TEMP_DIR/$FILE_NAME
                perl -pi -e 's/id='"$ID"'/id=999/g' $TEMP_DIR/$FILE_NAME
                perl -pi -e 's/'"$IPPORT"'/'"$IP":"$PORT"'/g' $TEMP_DIR/$FILE_NAME
                DIFF=`diff $TEMP_DIR/$FILE_NAME $TRUE_RESULT_DIR/$FILE_NAME | wc -w`
                if [ $DIFF -gt 0 ]
                then
                        printf "This account is error : $FILE_NAME\n" >> $RESULT
                        COUNT=$((COUNT+1))
                fi
        done < $DATA_DIR/$i
        LOOP=$((LOOP+1))
        printf "\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bProcess: $LOOP / $SUM"
done

【总结】
        当这些测试工具完成后，不言而喻，测试的工作就轻松、简单多了！而且，测试工具提供的详细的日志，给开发员的纠错提供了很好的帮助，大大的节省了开发和测试成本。
        上面的3个例子，都是笔者在工作中实践总结出来的，这里主要讲的是测试工具或脚本的产生过程和思路，设计到的技术也无非是大家耳熟能详的Java、JDBC、Shell等，由于商业原因，笔者不方便把工具全部共享出来。下面我们来分析一下这些测试工具共同点和不同点。
共同点：
        测试工作很难开展（外部条件未达到）或者是测试工作量巨大（而且是大量的纯手工有规律的劳动）；
        可以借助编程或者写shell脚本来实现自动化；
        选择开发工具时，尽量跟后台开发语言一致；
不同点：
        当涉及到数据库、协议等时，得用编程来实现自动化。而对于后台已经有客户端、操作命令等时，可以用shell来实现自动化。当然，涉及的方面较多时，可能既得编程，又得写shell脚本；
        不同的数据库、协议等，所使用的第三方jar是不同的。对于shell脚本也是一样，不同的平台，可能一些基本命令也不同，比如awk和nawk，等等；
        当然，这里的例子在众多的测试情况中，是微不足道的，但是只要我们养成一种良好的思考习惯，注意积累，我想我们的测试工作可能会越来越轻松，越来越快乐！
        如果有对其中部分知识点感兴趣的话，可以加我一起讨论（qq：16029687，msn：owen_fy@hotmail.com）。