如果选定了要自动化的目标，--通常来说是一个data-driven的case集合，下一步就是要考虑如何实现的问题。

首先从软件架构来说，自动化测试项目不算复杂，对于大多数情况，一个自动化测试项目的实现由三个主要部分构成

• 自动化测试框架
• TA testcase
• Library

自动化测试框架

测试框架提供了testcase的管理，测试任务的管理，测试报告的生成等内容。取决于自动化测试项目的大小，可以从提供最简单的testcase管理和运行的小框架，到基于数据库，包含内容丰富的报表的大框架。

可以看到，测试框架提供的功能和具体的testcase无关。所以，寻找/提供一个通用的测试框架是可能的，用这个框架来管理某一个产品所有的自动化测试用例。

Test Automation TestCase

自动化测试用例(TA testcase)包含了实现测试逻辑的代码。

在实现测试用例的时候，有一个技巧。那就是自动化测试用例的抽象层次和datadriven testcase的抽象层次保持一致。首先试图用关键词加相应的数据来描述一个testcase，然后在testcase里提供一个能够解释这些关键词和数据的“解释器”。

在实现测试用例的时候，我个人的经验是要尽量维持testcase这一层的代码比较“薄”。最好只有描述了测试逻辑本身的代码，减少访问实际的底层设施的代码。这样的好处

    1）是提高了底层代码的通用性，

    2）是在测试逻辑不变的情况下，访问GUI的代码在未来变化的可能性比较大，把访问GUI的代码放在Library层，可以维持testcase代码的稳定性

Library

library提供了访问测试产品本身，或者其他一些基础设施的API，比如访问DB，remote server, etc.

自动化测试，从哪里开始？

对于刚开始做自动化测试的新手，一个很大的烦恼就是如何开始的问题。面对心中澎湃的激情和老板殷切的希望，很容易陷入两个极端。

第一个极端是“over design”，就是试图在一个framework里解决所有的问题。这样的后果一是framework必然要引入更多的抽象层导致framework变得复杂而丑陋，第二个是前期工作量非常大，可能很长时间连一个可以跑的demo都拿不出来。

另一个极端是不讲设计，没有任何framework，一个script就是一个case。这样快倒是快，但很多重复的代码分布在各个script里完成类似的功能，后期维护简直就是灾难。。

这里问题的核心是，你如何来界定一个自动化测试程序的范围呢？一个程序解决所有case不行，一个case一个程序也不行。你必须要确定一个自动化测试程序要解决的范围。在这个范围里，既能设计一个framework能兼容所有的testcase，取得最大的代码重用效果，又不至于把framework搞成一个复杂难懂的怪物。

其实这里有一个很简单好用又有效的方法。那就是根据“数据驱动”的testcase来定义你的自动化测试程序。如果你发现了一套testcase可以用，或者已经用，数据驱动的形式定义的，那么就把它作为你自动化的对象。

说这个方法简单好用是因为它一点也不复杂，testcase是已经现成设计好的，不用花心思来决定“留”和“舍“那些testcase的问题。说它有效是因为

1）  一套testcase既然能设计成使用数据驱动的形式，那么他们必然有类似的测试逻辑。因此framework也不会很复杂，那么做出来第一个能跑demo也相应会比较快。

2）  第二个好处是有大量的testcase能自动化起来。因为有类似的测试逻辑，如果自动化了1个case，那么剩下的9个case差别相当小。自动化10个case显然比自动化1个case更能获得老板的认可。。。

3）  第三个好处是，一般来说越是核心的功能，测试越彻底，那么数据驱动集也会越大。如果你首先挑上这样的一套testcase，那么自动化程序的价值也相应的更大。

(这还是以前写的一篇发牢骚的文章)

印象很深,以前在webex的时候,这里的VP特别强调"沟通",几乎每次会议都会强调两三次. 不过他说的"沟通"是从管理角度来说的. 希望大家对某个制度,目标,任务能达成共同的认识.

现在在AR,manager也在强调"沟通",这里说的是QA和Dev的沟通.比如在file一个bug之前,和dev沟通一下,看是不是duplicated bug,或者有没有异议.

这种沟通我看是不应该提倡的.

首先来说,沟通是需要成本的,那就是时间.A去找B,B会丢下手里的工作来处理,导致A和B的工作都不连贯.一个人工作最有效率的也就一两个小时,打断后重新回到先前的工作需要时间.

第二, 一个组织,最有效率的是, 每个人都只干他本质的那一部分工作.沟通显然不应该是QA/Dev的本质工作.沟通是为了消除歧义,达成共识.但有没有更好的方式来达到这个目标呢?那就是通过一套良好的问题处理机制.

比 如关于duplicated defect的问题.这点是很难避免的.因为已经抱的bug成千上万,一个QA不可能也没有必要熟悉所有的bug.怎么办,首先是报出来.一般来说Dev 会更清楚是不是已知的问题.然后Dev把bug的状态转违duplicated. 根本不用耽误大家的时间.

有些问题是QA和DEv对一个bug 有不同的意见.  这个时候两个人据理力争是没有任何意义的, 因为这个问题根本就不是他们能解决的.  是不是一个bug应该有更上一层的人,比如manager来确定.  所以, 把defect标记为Need Confirm,Manager就会处理这样的问题.

我个人的认为是QA和DEV没有必要互相串门"沟通"是否一个bug真的是一个bug.  当然前提是有一个很好的defect管理系统.DEv,QA,Manager三者在这个系统下各尽其责,实现最高效率的工作

Have your manager or HR told you directly or indirectly that your performance has problem? That really is a bad news, which I hope will never happen to me. But if it unfortunately happened, please take it very seriously as you were being viewed as unqualified to your position.

Maybe things are not going that bad. Let’s say there is an interview you are to participate. Of course, you want to win out from all the competitors, so it will definitely help if you know how HR evaluates a candidate.

Both stories are leading to one same question. What are the key factors that affect people’s performance?

I had thought into this question, and from my experiences in software testing I got to a conclusion that there are 3 factors: attitude, knowledge and skill. To my surprise, I found by chance that the 3 factors are commonly used by HR to analyze people performance as well.

Attitude

Attitude is everything.

Basically, software testing is not a job only genius can apply for, nor only Doctor or Master. So with a right attitude in work, very possibly the performance will never be a problem of you. Try answering questions below.

1.         Do you show your passion in work?

2.         Are you self-motivated most of the time?

3.         What’s your reaction when meeting with problems?

4.         Do you run a case at the N time with same patience as the first time you see it?

5.         …

The saying “Attitude is everything” cannot be emphasized too much for a QA engineer, especially for juniors.

Knowledge

Better you understand a product, better you can test it.

Try to understand the feature and technologies related to the feature before you start testing it. This not only benefits your current testing, but also benefits your career as your knowledge base is hence strengthened and enlarged.

In terms of personal knowledge base, I think the key point is you have to form. a habit of documenting any valuable thing into somewhere you can easily look up later, and with your own words. A wiki system is the best tool you can leverage.

Skill

In my opinion, for software testing, skills are not essential, that means it’s better to have them so that you can do faster, but if you haven’t, you can still get your job done. For example, scripting skill can reduce the time creating 1000 files significantly, but if you don’t know it, you can still get it done with copy+paste.

To me, the main part of QA engineer’s skill set is utilizing tools. Shell is a great tool you can utilize if you are doing testing under linux/unix. Mastering an advanced editor, Vim, Emacs or UE, sometimes may speed up the operation 10 times over with only pool Notepad. Believe me, any time you think a tool should be invented to release you out from a boring work, the exact tool must have been invented out there. All you need to do is to find it.

As a hard working engineer, have you ever raised a question that why your manager earns so much more money than you? It seems it is individual engineers who deliver all the valuable things, they coding, they testing, they listening to customers’ complains and so on.

Yet it’s not necessary that a manager should earn more money than an engineer, being a manager truly requires a set of totally different competencies/skills from being an engineer, and honestly speaking, this kind of competency/skill is not that easy to acquired and thus, may be worthy of the money.

I have had similar questions before, but had my mind changed after participating a training session called “transition to leader” today.

There is no another word than “brainwashing” better describing the impact of the training on my way to look at the manager role. Not going deep into many details, I would like to mention only one fact impressing me most in the session.

Charles Fan, general manager of EMC China COE, shared with us at the session beginning his thoughts about being a manager.

You should “让你的队员happy”, “代表你的team去争取利益”, “好的事情，让你的队员去领功，不好的事情，你要扛下来”, …

“As a manager, most of the time, you are not ordering your people, but serving your people” I concluded from his speech. This just reminders me of another saying made by Linda (HR manager) not long ago “A good manager should make his/her people succeed”

As an individual contributor, you deliver products with good quality on time, that’s wonderful. But no matter you are aware of or not, without manager’s efforts, like communicating with global team, coordinating with Dev team, planning the schedule, leveraging the team member capability, and so forth, your achievements are not going to happen.

One principle of manager is “to recognize your member”, I think this also works for engineer in “to recognize your manager”.

One day I had a chat with a Tech Support engineer, and she told me she was suffering a customer issue because the debug log was so ugly that she just cannot get meaningful information from it to identify the root cause. “The object I need is printed in only hex format but not human-readable string, hence to track an object are getting extremely difficult.” She complained.

“I filed a bug, because it significantly slows down the process of working out the final solution”

This conversation just shocks me a lot, in that it opens a new view to look at the duty of Quality Assurance. Previously, I think the work methods of software testing are just in two ways, one is testing with testcases and another, testing from customer’s view. I have never think of testing like a Tech Support.

One of the key characteristics of Tech Support working style. is the attempting to track an issue down will never stop until root cause is disclosed. Only by doing in this way, can Tech Support come out a reasonable explanation to customers, and then in turn figure out the final solution to the issue.

In testing activity, it’s a common case that QA will observe something unexpected but cannot easily get a fixed way to reproduce it. How to deal with this situation? It’s not safe to file a bug as chances are Dev cannot reproduce it. Sometimes, QA just let it go for various reasons, but which will never be reasonable for TS to do so, as Customers will not accept any of them at all.

It’s necessary for Software testing engineer to work in this way and master this kind of capability.

Firstly, some issues should be exposed in customer side now can be revealed in advance in testing phases, that’s absolutely good for any one.

Secondly, the product debugging mechanism could get sharpen as QA becomes its big user and will report all the inconveniences, so very likely in the above example the poor TS will enjoy addressing the problem.

Last but not least, a QA with positive attitude will see it’s also a chance to improve his competence in terms of problem resolving.

This Friday afternoon, I attended a care talk hosted by HR mgr. of EMC China COE, Linda Di(Her Blog).

Linda has a successful and colorful career path, in 10 years growing from Admin Assistant to HR mgr of China R&D center of a world-class company.

Others’ success story may not be copied but can be learned. In the talk, Linda shared with us not only some stories but also her feelings, her thoughts and her complains as well. Followings are those impressed me most.

1)      Influence leadership

People may have others working for him/her using influence other than authority, as long as others believe you are doing right thing and they can achieve their interests along. And of cause, in a condition of others can accept your style.

When she talked about influence leadership, I just recalled another note stressed by Robin Ren in his career talk a few months ago, that is “build up your reputation”. I think both notes referring to one point: you need to influence people around you, by showing your support, your capability and personality.

2)      Make something different

By making something different, you get a chance to show up yourself, and likely give people/mgr an impression that you are a dynamic, creative guy. But notice that this kind of difference should really bring positive effect.

3)      Make a success story every year.

Imagine what you can say when you happen to get a chance to be asked by a very high level mgr about your wok in the company.

No matter how hard you work in each of the past 365 days, you just cannot tell him about that. All you need is an impressive success story, and then introduce it in 1~2 minutes.

4)      Manager’s responsibility is to make his people success

This is the key to a manager I believe, though I’m not a manager yet.

Rainfinity ATS无疑是一个成功的ATS。它值得学习的地方不在于它的编码，而在于针对ATS这种特定软件，设计师在设计时做出的一些正确的决定对于我具有启发作用。

总的来说，RainfinityATS是KISS的又一个例证。 Keep It Simple and Stupid(K.I.S.S)

1）  只关注系统最核心的功能。但对这个功能做非常充分的测试。RainfinityATS不想做瑞士军刀，而是只专注某一个功能的外科手术刀。设计任何ATS系统的时候我想都要把这个作为一个原则。如果测试的要求比较多，一个测试系统不能满足，那么宁愿另开炉灶，开发一个新的系统，也不要把所有的功能挤在一个系统里。

2）  强制要求一个特定的环境，而不是让自己聪明来适应环境。RainfinityATS的初始配置工作非常麻烦，因为很多东西都要为它准备好。但好处是一旦配置好了，就能稳定的运行。

3）  另外一个优点是充分利用了已有的工具，并且通过命令行和这些工具传递控制信息。这种方式是unix下面的惯用方式。它的好处是提高了模块间的独立性，相对于API调用。

即使如此，Rainfinity ATS里面还是有一些失败的设计。这些设计几乎在所有ATS系统中都可见。保持对这些失败之处的警惕对设计人员来说是很重要的。

1) 在错误的地方实现一个功能

比如action group。Action group的出发点是好的，把action集合起来，定义为一个named group，然后直接引用此group即可。但是action group的问题是

action group的功能非常简单，也就是一些action名字的集合。没有必要专门的一个类来处理。而且它导入间接性影响了理解testcase。也就是它的好处并不能抵消它带来的缺点。

实际上action group的概念是有意义的，但它放在了错误的层内。它完全可以在testcase的层次来处理，而不用在ATS的框架里面。

2）仅仅因为头脑发热而实现一个功能

RainfinityATS里面还有一些脚本，比如到bugzilla查询bug的脚本。看得出来费了很多精力来开发，但几乎很少使用。因为即使亲自动手做这样的工作也是非常简单的。如果没有迫切的需要人们都懒得学习新的东西，所以使用率不高也在情理之中了。所以开发脚本的时候，如果它的用户是team所有的成员，那么一定不要头脑发热就开发，而是充分了解team成员的需求，在大部分人都有强烈的需求的情况下再动手。特别是这个脚本具有下面的特点的时候。

1）  开发此脚本需要较大的投入

2）  开发此脚本需要对已有的系统做一定的修改

RainfinityATS是我见过最成功的自动化测试系统。我做出这个结论的依据是基于下面一个事实：

ATS有超过3k的testcase，部署在超过8个testbed上面。每一个testcycle，每一个testbed平均会运行超过2k的testcase。也就是16k 个testcase被运行。

如果只能用一个参数来恒量自动化测试系统成功与否，我相信，它一定是在一个testcycle中该自动化系统的testcase的运行个数。商业软件的成功体现在它卖出了多少copy，自动化测试软件的成功体现在它运行了多少次testcase。

为什么这样说呢？因为如果一个ATS在这一点上得高分，那么就表明了它在下面三个方面做得很好。这一个参数是下面三个参数的综合体现，这三个参数代表了Manager，Dev和QA对ATS系统的要求。

1）  testcase覆盖率。Manager要求覆盖率

2）  测试运行效率。Dev要求运行效率，因为他们的发布频率加快了。最好每天都能运行一遍。

3）  测试系统稳定性。QA喜欢运行稳定的系统，他们不想为跑测试过程中各种古怪的问题伤脑筋。