做一个开发人员认可的测试人员(系列3)-也谈自动化测试框架[缓慢更新中]

crazypeter2005

AlexQin 发表于 2013-8-6 15:24
送你一辆比亚迪～

3Q

AlexQin

crazypeter2005 发表于 2013-8-6 15:33
3Q

np

crazypeter2005

    今天介绍下Nunit做的一个白盒自动化测试框架。
    某工业控制系统，流程超级复杂，输出随着输入不断变化。为提高交付质量，避免重复的人力劳动（其实也是因为环境受限，测试人员虽然不少，但是同一时间只能一个人上去测试。），我们和开发经理联合设计了该自动化测试框架。我们比客户预计的时间提前半个月高质量的完成了开发以及测试任务，收到客户表彰，有一点小小的Bonus。
     该框架大结构图如下：
   
    被测试的验证点全部都在数据库，所以我们把数据库的每个表做为Model的下层。Utility是完成必要的商业流程以及通用验证点的部分。Configuration是配置库的信息。而Test Data和Test Case是按照测试人员对需求的认识，一步步逐步覆盖到各种输入和输出的部分。
     
     如图所示的8张表，每张表都有需要验证的字段。
                 Utilities包括FTPFolder工具和Utilities工具。
     
     Configuration是读取app.config包括测试程序以及测试数据库的信息等等。
     
     这里是包含了7种测试的类型。
     
    数据文件按照测试的编号以及数据类型等约定的命名规则做好待用。
   
    整个框架展开入上图所示。
   
    因为开发是采用C#的，我们测试也随大流。这是做好的Project的截图。可以看到是和整个框架吻合的。
   
    这是一个最典型的Case的流程图：
1 测试数据Trigger Z0进入
2 拷贝该文件到FTP
3 高版本的Trigger文件进去
4 验证trigger的数目
5 验证trigger的内容


分为R G B 3个组，每个组搭配一个开发的和一个测试的。测试的熟悉商业逻辑，开发的熟悉框架和代码。2人一组来写测试的Case，2人评审后才能通过。可以看到引入了Agile的燃尽图。



开发人员写的函数列表，找了个实习生去天天更新维护，每天发给所有人。


这是测试的Case，也是做自动化的蓝本。0.1、0.2是我们内审的升级版本，1.0、1.1是给客户审查后的升级的版本。

附录测试Case的一段代码：

1. //********************************************************************************************************
   
2.         //  Case Name: OSIT067
   
3.         //  Author:     XXXA
   
4.         //  Reviewer:   XXXA, XXXB
   
5.         //  History:
   
6.         //  Execute Record:
   
7.         //  Step 3 To Do                  
   
8.         //
   
9.         //
   
10.         //********************************************************************************************************
    
11.         [Test]
    
12.         public void OSIT067()
    
13.         {
    
14.             ////Part 1 ------------------Data initialization---------------------------------
    
15.             // Step 1. Data Initialize
    
16.             Utility.ClearData("68001238");
    
17.             String PlantIdFAI = Plant.GetPlantIdByPlantRPO("FAI");
    
18. 
    
19.             String PlantNameFAI = Plant.GetPlantNameByPlantId(PlantIdFAI);
    
20.             //1. Current plant FAI is a non-validation site
    
21.             //2. Current plant FAI doesn't include product line 0G.But has 0P
    
22.             //Validation.VerifyPlantIsValidationSite(false, PlantIdFAI);
    
23.             Utility.AddProductLine(PlantIdFAI, "0P");
    
24.             Utility.RemoveProductLine(PlantIdFAI, "0G");
    
25. 
    
26.             //There are Post-EVO DLS trigger records as below  
    
27.             //68001238,2,AB,12,0G,PPV.PPV01.FAI  2012.1.1
    
28.             //68001238,2,AC,13,0G,PPV.PPV01.|ALL| 2012.1.2
    
29.             Utility.CopyTriggerFile("AutoManual_Test\\PMR-OSIT.067\\PMR-OSIT.067.01-Trigger.txt", FtpFolder.CpfaTest);
    
30. 
    
31.             ////Part 2 -----------------------Verify-----------------------------------------
    
32.             //Step 1 Plant FAI tries to manually retrieve
    
33.             //       68001238 0P 12
    
34.             Utility.ManualRetrieve(PlantIdFAI, PlantNameFAI, "68001238", "0P", "12");
    
35. 
    
36.             //Step 1.A Nothing will be retrieved to Temp folder.
    
37.             Validation.VerifyPartExist(false, "68001238AB", 0);
    
38.             Validation.VerifyPartExist(false, "68001238AC", 0);
    
39.             //Step 1.B Nothing will be inserted in Temp_Part part for FAI.
    
40.             List<TempPart> tempParts1 = TempPart.GetParts("68001238");
    
41.             Validation.VerifyTempPartCount(tempParts1, 0);
    
42.             //Step 1.C 68001238 0P 12 is inserted in Temp_SERT for FAI.
    
43.             List<TempSert> tempSerts1 = TempSert.GetTempSerts("68001238");
    
44.             Validation.VerifyTempSertInfo(tempSerts1, "68001238", "0P", "12");
    
45.             //Step 1.D Nothing will goto DLS table
    
46.             List<DlsLookup> dlsLookups1 = DlsLookup.GetDlsLookupsByPlantID(PlantIdFAI, "68001238");
    
47.             Validation.VerifyDlsLookupCount(dlsLookups1, 0);
    
48.             //Step 1.E Nothing will be reconciled to FAI.
    
49.             Validation.VerifyIsPostExsitInReconcileList(false, PlantIdFAI, "68001238", "0P", "12", "AB");
    
50.             Validation.VerifyIsPostExsitInReconcileList(false, PlantIdFAI, "68001238", "0P", "13", "AC");
    
51. 
    
52.             Utility.ClearData("68001238");
    
53.             Utility.AddProductLine(PlantIdFAI, "0G");

复制代码

整个开发和测试走的Agile的模式，风险小且容易控制。

虽然客户几次变更其中的细节，但是我们因为每天晚上(12小时),能跑完一轮。所以还是能提前保质保量的完成了项目。
Nunit也是简单易用的白盒测试技术，只要组织合理，稍稍有代码基础的测试人员也能配合开发的一起写Case。
希望大家多多评价。

AlexQin

good job

tuds

我不认同这句话“关键字驱动过于复杂，难以维护。”看了一下你的框架其实很关键字驱动的框架没什么区别
    QQ登陆界面：
      点击UserNmae,输入UserName，清空UserName，点击密码，输入密码，清空密码，点击登陆 这就是7个Task。
  你的task对应关键字驱动里的keyword准确的说是step keyword
而一个Wizard就是
      1 输入用户名，2 输入密码， 3 点击登陆，这就是一个Wizard。Wizard不做验证，只是调用各个小的Task。Wizard调用后验证的结果在TaskCase里面调用。

你 的Wizard其实还是对应关键字里的keyword，不过是flow keyword

我们用的框架的结构分 testsuite-testcase-testflow-userkeyword-apikeyword

crazypeter2005

tuds 发表于 2013-10-13 14:00
我不认同这句话“关键字驱动过于复杂，难以维护。”看了一下你的框架其实很关键字驱动的框架没什么区别
   ...

欢迎不同的意见，框架其实不是一定那么严格区分的，界限其实很模糊。
在我理解的关键字驱动，动词，名词全部都是输入，框架中包含处理/区分动作的逻辑。
就拿这个QQ登陆来说
   输入  用户名
   输入  密码
   点击  登陆按钮
   输入和点击2个动作，都是作为关键输入，这样Case的组成完全就是Excel就能弄下来。

   而在我的框架中，输入和点击是各自独立的Task，所以严格来说还不是Excel那种就能弄下来的Case。
    实际上，如果我这个更进一步，能识别各种动词的话，也能改写关键字驱动。

AlexQin

good job

crazypeter2005

大家好，好久不见了。虽然Itpub没落了，不过我还是选择在这里默默的共享我接触的一些测试框架，希望能给测试的人一点启示。

下面言归正传。

-----------------------------------------------------------------华丽丽的分割线---------------------------------------------------------------------------------------------

Google亲儿子UI Automator不支持长按。面对新公司选型UI Automator我一面表示无语，一面还是得把长按功能给加上去。

完全从Java代码层面应该也行，不过时间和精力不允许。我找到一种Shell实现的办法。

要了解可以从Linux底层说起：

1 遥控器发射信号 -------------->2 Linux（Android）底层响应事件--------->3 安卓响应逻辑

如果能知道具体键值配对就能通过键盘去模拟操作了。

Android提供了2个命令可以给与我们很大的帮助：

1 getevent

从上面图我们可以看到/dev/input就是各种设备，其中的event4就是遥控器.

从上面的图我们来分析下OK按键的输入序列

黄色分为上下2组，2组见的区别就是1在上面表示按下，0在上面表示松开。

在安卓中，如果按下和松开间隔超过0.5秒就认为是长按。

所以看到上面的图中模拟的是一次按键事件。

来稍微看下该命令的参数

其中1个功能是查看时间：

看下间隔的时间，我猜测都是转换成了Java从1970开始的标准时间，但是差值是我们认定的秒数。

看下42 - 37 大致是5秒，这个就是长按了。

2 sendkeys

我们来看下如何模拟长按增加音量按键

/dev/input/event3: 0004 0004 000c00e9

/dev/input/event3: 0001 0073 00000001

/dev/input/event3: 0000 0000 00000000

/dev/input/event3: 0004 0004 000c00e9

/dev/input/event3: 0001 0073 00000000

/dev/input/event3: 0000 0000 00000000

adb shell sendevent /dev/input/event3 4 4 786665

adb shell sendevent /dev/input/event3 1 115 1

adb shell sendevent /dev/input/event3 0 0 0

adb shell sendevent /dev/input/event3 4 4 786665

adb shell sendevent /dev/input/event3 1 115 0

adb shell sendevent /dev/input/event3 0 0 0

上面的部分是从getevent得到的输入

将其中的数字从16进位切换为10进位，就是我们的输入串了。

请在命令行中执行下面的连续6个adb命令

同时观察TV界面，发生了什么？

电视按键音量的确变大了，说明sendevent 是可行的。

3 是用Win的批处理还是Android的sh?

电视音量按键从0一直增加到了100？？！！

为啥呢？我期待的应该是单击增加按键音量一次啊？

来看看相应机制：

主要时间花费在从Win到Android去了

如果我们转换思路：

直接把shell写到Android里面呢？

这时候我们就能很明显的发现一次只增加1个音量按键。

4 对休眠的支持

如果加上天生支持的休眠参数

现在就能完全支持长按了。

还可以拆分为多个脚本，组合执行。

看上图，可以分为root,普通用户，或者Win用户adb执行。

5 最后实现：

1 执行需要长按的测试用例之前从咱们的FTP服务器取下长按脚本

2 FTP取脚本的Java程序

需要特别指出的是，因为引入了第三方FTP的jar包

编译需要去修改特定的文件

修改了之后再Build Dex的时候会出现如下的增量dex过程

3 具体实现长按的脚本

会根据具体传入的动作来决定调用的脚本，按下的时间如果低于850会定义为850

4 长按的脚本

每个脚本都成对出现，一个为按下按键对应的值，另一个为松开按键对应的值。中间的长按的时间为上面函数传入的值，如果太小则定为850毫秒。

5 跑完脚本后需要去清理掉这些下载下来的脚本

总结一下现在的流程：

crazypeter2005

果然好冷清，算了，心安处即是我家....

AlexQin

干货妥妥的多