Automate Everything

Archive for the ‘自动化测试’ Category

我们有时候需要做一些很耗时间的操作，比如到网络上拿一些数据或者对很多数据进行运算处理，如果是在单线程的程序中，这些运算就会阻塞UI线程，现象就是UI不能响应用户的任何操作，不会刷新。这个时候用户很可能以为程序已经死掉，从而造成很差的用户体验。
解决方法：将很耗时间的运算和处理放在单独的一个线程中进行，UI操作不会受到影响，用户还可以进行其它操作（如果UI中有些操作依赖于当前的的处理，我们可以先将它灰掉，在处理线程结束后再使其可用。更好的是在UI的线程中放一个进度条，来告诉用户当前的处理进度）

在C#中做多线程的处理非常简单：
只需要用代理(Delegate)和跟代理相关的两个函数：
1. BeginInvoke  这个方法将代理指向的方法在一个单独的线程中调用
   使用方法：
     a. 声明一个代理的对象
     b. 用这个代理对象调用BeginInvoke方法         

2. Control.Invoke 这个方法在当前UI的线程空间内调用代理所指向的方法
    使用方法：
      a. 声明一个代理对象
      b. 调用控件的Invoke方法(一般在WinForm程序中，可以调用this.Invoke方法)，将代理对象作为参数传递过去

看代码：

   1: private delegate void LoadPhotosDelegate(SearchParam param);

   2: private void LoadPhotosFromFlickr(SearchParam param)

   3: {

   4:     UpdateUIDelegate updateUI = new UpdateUIDelegate(this.UpdataUI);

   5:     this.Invoke(updateUI);

   6: }

   7:  

   8: private delegate void UpdateUIDelegate();

   9: private void UpdataUI()

  10: {

  11:     //进行UI的更新操作，比如更新进度条，显示图片等

  12: }

  13:  

  14: private void SearchPhoto(SearchParam param)

  15: {

  16:     LoadPhotosDelegate loadPhotos = new LoadPhotosDelegate(LoadPhotosFromFlickr);

  17:     loadPhotos.BeginInvoke(param, null, null);

  18: }

上一篇讲了在自动化测试中如果控件不能识别，我们最后的办法是模拟鼠标键盘，这一篇就讲如何来做。

首先我先讲在C#中怎么做，至于在C++或者脚本中怎么做，留在后边来讲

对C#来说，键盘的模拟比较简单，在.Net Framework中System.Windows.Forms.SendKeys这个类

鼠标呢，看下边代码：

   1: [DllImport(“user32″)]

   2: public static extern void mouse_event(int dwFlags, int dx, int dy, int dwData, int dwExtraInfo);

   3: 

   4: [Flags]

   5: public enum MouseEventFlags

   6: {

   7:     Move = 0×0001,

   8:     LeftDown = 0×0002,

   9:     LeftUp = 0×0004,

  10:     RightDown = 0×0008,

  11:     RightUp = 0×0010,

  12:     MiddleDown = 0×0020,

  13:     MiddleUp = 0×0040,

  14:     Wheel = 0×0800,

  15:     Absolute = 0×8000

  16: }

  17: 

  18: void PixelsToAbsCoors(double x, double y, ref double xOut, ref double yOut)

  19: {

  20:     //points are based on current screen size setting   

  21:     xOut = x * 65536 / Screen.PrimaryScreen.Bounds.Width + 0.5;

  22:     yOut = y * 65536 / Screen.PrimaryScreen.Bounds.Height + 0.5;

  23: }

  24: public void Move(double x, double y)

  25: {

  26:     PixelsToAbsCoors(x, y, ref x, ref y);

  27:     mouse_event((int)(MouseEventFlags.Move | MouseEventFlags.Absolute), (int)x, (int)y, 0, 0);

  28: }

  29: public void Click(double x, double y)

  30: {

  31:     Move(x, y);

  32:     PixelsToAbsCoors(x, y, ref x, ref y);

  33:     mouse_event((int)(MouseEventFlags.LeftDown | MouseEventFlags.Absolute), (int)x, (int)y, 0, 0);

  34:     mouse_event((int)(MouseEventFlags.LeftUp | MouseEventFlags.Absolute), (int)x, (int)y, 0, 0);

  35: }

我们知道，在做自动化测试时，总会碰到一些自动化测试工具不能识别的控件，比如WPF控件、用户自己绘制的控件、以及一些复杂的组合控件等。当自动化工具对这些控件无能为力的时候，我们怎么办？
这个时候是最考察自动化测试人员能力的时候，因为能解决多少这种问题，决定了你能够自动化多少Testcase。
解决这种问题的方法我认为大概有一下几种：
1. 如果是因为自动化测试工具的限制，比如对于WinForm的控件，有些自动化工具就不能识别，碰到这种情况，最好是看这个工具有没有扩展可以用，比如Silktest的.Net Framework扩展。如果不行，那只能换自动化测试工具了。所以这个凸显出在做自动化测试以前，选择自动化测试工具的重要性。
2. 如果是因为控件比较复杂，自动化工具可以识别，但是无法操作。这时我们可以通过Window API以及消息的方式来做，比如自己去调Window API来操作窗口，或者请开发实现一下消息的接口来给自动化工具调用等
3. 跟开发沟通，让他们的控件支持IAccessible接口，然后我们通过MSAA来操作（如果是WPF控件，则需要实现UIAutomation定义的一些接口）。不过一般情况下，除了微软这样对软件的Accessible要求很高的公司，其它公司很少会花费时间来实现这个接口……。 另外扯一句，产品的Accessible的程度，实质上决定了一个公司能对产品做自动化测试的程度。
4. 如果以上方法都不行，那只有最后一个双刃剑可以用了，就是鼠标键盘模拟。理论上来说，只要用户可以操作的东西，只要有界面，就可以通过鼠标键盘模拟来实现（君不见N多游戏外挂的键盘鼠标模拟大法）。就如双刃剑一样，这种做法是杀敌一千，自损八百。因为鼠标键盘模拟非常依赖于当前激活的窗口以及光标位置和焦点位置，而且同步起来很困难。这也造成了后期维护成本很高。

总之，碰到界面控件不能操作的问题我们需要开动我们的思维，能绕过去的尽量绕过去；能不通过界面操作就可以做的，一定不通过界面；实在绕不过去的，就找一个最稳定的方式去做；最后还没有办法就用鼠标键盘模拟吧，总比没法做强……

这个列表是我自己日常工作中会用到的一些工具，主要包含几类：UI自动化工具、系统脚本工具、脚本语言环境

UI自动化工具：
• Silktest这个是我现在主要用的自动化工具，SilkTest是比较完备的一个面向对象的自动化测试解决方案，包括UI的识别、UI控制、UI状态验证、错误状态恢复、脚本录制、验证点录制、数据驱动测试等
• AutoIt3AutoIt3作为免费的自动化工具，很多功能还不是很完善，但是优点是非常轻量，而且语法类似VB，还有很多程序库可以用，学起来也比较容易。我现在主要用AutoIt来做自动的安装和配置。
  系统脚本工具：
• PowerShellPowerShell作为微软的脚本环境，功能当然是毋庸置疑，面向对象的操作和支持.Net Framework对象，用来进行系统配置和一些环境设置的脚本，当然最主要的对WMI的操作也很方便。
• PowerGUIPowerGUI只是PowerShell的编辑器，我大概用了一下，还是挺好用的
  脚本语言环境：
• Python解释性的脚本语言相对来说还是有很多优势的，而且Python的方便自然不用我多做解释了，平常主要拿它来做一些自动化脚本和安装的部署工作，以及进行结果的分析
  其它：
• Notepad++
• Visual Studio

转载自：http://peking2toronto.spaces.live.com/Blog/cns!A975CAF18FBB985B!416.entry

很多人理解的自动化就是把手工测试case用脚本和工具转变成自动化测试。也就是说把手工测试的每一个步骤用脚本来模拟，从而执行test case。那么自动化的所有问题就归结于，如何用工具和脚本来转化手工操作步骤了。还有很多非常senior的，但是不会coding的手工测试工程师强调case的design能力是如何如何重要，自动化相对来说不是那么重要。我这里可以肯定的说，没有好的编程功底，你也不可能涉及出非常好的test case, 自动化的开发也不应该是仅仅把手工操作用脚本来模拟，而是应该大幅度的改变test case，使得能够用最好的方式来进行自动化。那些手工测试人员所谓的设计case的重要性，和他们设计case的高水平，实际上只是在他们的知识范围之内产生的观点。下边我用一个小例子来说明，编程能力在自动化过程中起的作用到底有多大。基本上来讲，有多强的开发水平，就有多强的自动化设计，实现水平。自动化开发和产品的开发实际上都是一样的，都是有需求，你来实现。当然，不同水平的人，实现起来的效果是千差万别的。这也就是为什么开发有高手，有低手，自动化测试的开发也同样有低手，有高手。自动化测试水平没有上限，你要学会发挥自己的无穷潜力。

不多说了，现在说一下我们要自动化什么问题。我们有两个计算机帐号，A和B。我们需要用B帐号进行系统的设置，也就是测试的准备工作，然后用A帐号来进行测试。下边来说一下不同水平的人是如何进行自动化的。

1. 手工测试人员

• Log on B
• Configure
• Log out
• Log on A
• Test

2. 初级自动化人员（直接把手工case转成自动化）

• Set autologon B
• Set autorun
• Record test status: 0
• Logout
• Check status

if(status==0)
{
    Configure
    Set autologon A
    Record test status:1
    Logout
}

if(status==1)
{
    Test
}

这个级别的人，需要懂得脚本编程，需要懂得系统设置，autologon and autorun。

3. 有一定经验的自动化人员（改变手工测试case以利于自动化的更简单，可靠的实现）

• 不需要log out and log on

• 利用Windows命令Runas

• 用高级语言调用Runas

• 利用重定向来输入Password

这个级别的人，需要懂得高级语言，重定向，Windows系统命令Runas

4. 中级自动化人员（具有更丰富的开发经验，可以用程序代替UI和系统命令）

• 不需要Runas命令
• 利用.NET的Process对象
• 用B的身份生成一个Process来进行配置工作

这个级别的人，要比较熟悉高级语言，比较熟悉高级语言的类库，懂得操作系统的内核基本概念

5. 高级自动化人员（精通高级语言，精通操作系统内核）

• 不需要多生成一个进程
• 用本线程impersonate用户B
• 利用.NET WindowsIdentity 对象
• 必须要调用Windows API，LogonUser

这个级别的人，要精通C/C++和Java，C#等高级语言，精通Windows内核的知识和Windows API

从以上的例子可以看到，针对同一个test case，不同的测试人员，从手工到高级自动化，由于自己知识面的原因，会设计出非常不同的case出来。越高级的自动化越灵活，稳定，可靠，也更需要掌握更多的开发和内核的知识。因此，我们看到很多人在强烈的否定自动化，你先看看他到底在哪个层次中。越下边层次的自动化人员，由于技术的原因，碰到的问题会越多，能解决的问题却越少，因此对自动化的抱怨也就越大了。这些都是可以理解的，不过以此来否定自动化，我觉得还是不太应该，毕竟自己技术还不过关。

转载自：http://peking2toronto.spaces.live.com/Blog/cns!A975CAF18FBB985B!384.entry

最近总是有一些网友问我一个问题“现在有机会转开发，应不应该转?”。我想我也需要单独发表一篇文章来表达一下自己的看法了。我会从一个新入行的测试人员一直往上发展大概会是一个怎样的情况入手，来表达我的观点“开发技术是测试人员发展的基础，也是测试人员发展的归宿”。当然了，我现在表达的是测试人员一直往上发展，如果你已经对自己的发展感到很满意了，则不在这里的讨论范畴。（相信会有不少这样的人来提出自己的疑义）

从你刚入行开始，你面前基本上是有两条路可以发展。一是技术，二是管理。先说管理，很多人做了很短的时间就走向了管理，team lead，甚至manager。他们的工作已经很少用到技术了，更多的是学习和运用管理的知识。这样的人不在少数，我当时做测试3个月一转正就是team lead了，老板也非常希望我专注在管理方面。可是下一步怎么办？一般出现这种情况的都是在中小公司，而不是大而正规的外企．下一步你的发展会由于技术不够扎实而出现了瓶颈．第一，你不可能回头去搞技术了，因为你管理的地位，工资都高于技术人员，而且还有年龄的问题，这些因素造成了你只能继续管理。第二，如果你想跳槽到大的外企搞管理，可能性几乎为零，因为你没有大外企的经验又没有出众的技术。第三，如果你想在本公司或类似公司往上爬，比如做director,很可惜，这些公司往往不配备test director的职位，并且其他director的职位也很难由一个做测试的人来承担。（可能会有特例，但是应该很少）。因此，刚入行不久，没有扎实的技术沉淀，就走向了管理，很快就会发展到头了。

再说技术，我们知道测试的最高title就是SDET和SET了。实际上都是一个东西，微软叫SDET,Google叫SET。说白了，这种职位本质上就是开发，只不过不是产品的开发，而是测试的开发。需要很强的开发背景。因此，一个普通测试人员想要得到这种工作机会，开发的经验是必不可少的。另外，微软，Google这种最top的公司，基本上已经没有STE, SQAE这种职位了。而我们大多数人做的测试工作恰好正是这种职位。顶尖大公司的这种职位都外包了。因此，你想通过普通的STE, SQAE这种职位进入顶尖公司，可能性基本为零。因此，如果从技术上来讲发展，无论从title上还是公司上往往上走，开发的功夫都是必须的。

因为我说的是一直往上发展，因此到了SDET后怎么发展？基本上三条路，第一管理，第二开发，第三继续测试。先说管理，你从技术上一路走过来再走向管理跟前面讲到的那种管理是天壤之别了。首先，你已经是在顶尖公司了，其次，你已经具备了高深的技术水准了。放眼望去，整个测试行业还能有几个适合你的位子呢？还能有多少人能跟你相提并论呢？这条路可以lead->manager->director->vp->senior vp往上发展。那么发展到了最后还怎么发展呢？这个时候，我估计应该年纪很大了吧？钱很多了吧？享受生活吧。

再说转开发，因为SDET具备了比较强的开发水平（比一般公司的开发人员的水平要高），因此可以比较容易的转向开发。转向开发之后就属于开发的发展之路了，就不多说了。

最后说继续测试，一直以来都有个疑惑，为什么我从来没见过senior SDET？本来SDET可以向senior, principle这条路走下去。我以前也想过自己发展成test architect。可是，为什么没见过？依我现在的感觉来说，测试的技术很快就学到头了，开发的技术由于一直是在做测试程序，而不是真正的产品，因此提高的程度也受到了很大的限制。因此，在技术上来讲，一直工作下去就会维持在一种不是很高技术水平的状态。这种状态达不到senior的要求。这也是为什么周围很多SDET不知道工作了多少年，还是SDET。目前来看，想发展的话，维持在SDET不算现实。必须走向管理，或者转向开发了。这也是为什么director在回答我的问题“我在测试方面应该怎么发展？”。回答竟然是“短期来看要学好Ｃ，长期来看还是Ｃ，转向开发”。根本就没有提到测试。

以上是我自己的分析与理解。

大概几个发展路径

1.QA->management

2.QA->SDET->management

3.QA->SDET->Dev

当然还有其他的可能，比如

4.Dev->QA……

5.QA->Dev……

6.QA->Dev->SDET……

7.Dev->SDET……

8.SDET……

我想大家可以分析一下自己以前的发展之路，看看以后应该如何发展？当然了，如果自己已经满意了就算了。我的发展之路是这样的

Dev->QA->Management->SDET->(Lead/Dev/Senior if possible)

总而言之，在整个的发展路径中，如果你缺少Dev,都会限制你更好的往上发展。还有就是发展的高低，一要看title,二要看公司。很多小公司的manager可能根本都进不了大公司。很多大公司的普通员工一旦跳槽到小公司很容易就能升职。比如一个朋友在国内做了６年的外包经理，面试大公司总是失败，因为技术不行。还有朋友在顶尖公司只是SDET,跳到盛大就是director.

这里我想破除很多测试人员的一个幻想，我强调的一点是“不懂开发的测试没有太大的前途”。