自动化测试思想

 

自动化测试的实质是为了快速、高效地发现和预防回归缺陷 

自动化测试(特别是基于UI的自动化测试)不是万能的,也不是测试的全部,更不是没有成本的

从本质上讲,非UI测试和UI测试,是互为补充的,根据其成本和特性的不同,在实际工程应用中也应该领会运用。其基本原则:非UI自动化测试用例为主,UI自动测试为必要的补充,考虑成本因素,UI自动测试可以被手动测试所取代

 

http://blog.csdn.net/quicknet/archive/2010/11/24/6032674.aspx

 

---------------------------------------------------------------------------------------------------------------

  

自动化测试消亡的原因及应对措施

 

什么原因会导致自动化测试的退化和过早消亡?

  1、未提前通知的软件变更:当我们已经积累了大量的自动化脚本,而且脚本中存在大量的被引用测试包,当发生的变更隐藏在某个或某些个被引用测试包的时候,测试人员并没有得到应得的提前通知,而是在发现自动化测试失效的时候才发现问题的严重性,随之带来的失效诊断、问题修复、脚本维护上的时间打断了我们目前的测试进程,为了不过多影响软件发布,项目组不得不采取手动替代的方案让大家继续测试,自动化测试被迫搁置一边;

  2、软件重构:当产品进入市场,由于性能或其他问题并不被客户看好的时候,我们会考虑到软件的大规模重构,由此带来的未知的界面和业务变更会使得我们前期积累的大批量自动化测试脚本无法复用,除了一些文档、方法、策略,其他都成了明日黄花,同时,开发语言、开发工具、平台的变更同样会导致这类问题;

  3、关键自动化测试人员的离职:当一些测试策略、文档、规范一直存放于一个或些个自动化测试人员的脑海、未被公布的测试机的某个路径下的时候,关键自动化测试人员的离职也会导致自动化测试的停滞不前、日益退化;

 

如何应对与避免?

  1、软件架构与设计阶段就应当考虑到自动化测试:软件测试并不仅仅是软件测试工程师自己的事情,需要架构师、需求人员、系统工程师、开发人员的协助,比如,在软件被开发出来之前就可以在软件原型上进行自动化测试设计、脚本编制等,这就要求原型开发人员、需求人员的大力支持,需求文档尽量精确详细,尽量避免变更,软件开发过程中,及时对原型进行维护等;

  2、时刻考虑到维护:安排专门的自动化脚本维护工程师在特定的时间对脚本进行及时维护,而不是在发现测试大量失效的情况下再亡羊补牢;

  3、不要集权:自动化测试策略、自动化测试文档、资料等不要集中在一个人手中,要有特定的机器存放,自动化测试进行过程中积累的各种经验和教训要及时付诸文档,或者及时沟通与培训;

  4、摆脱被动:自动化测试不要做软件开发的附属物,而是要驱动和指引软件开发,当发现问题时决不手软,比如软件性能问题,不要到软件开发后期再考虑到性能测试,时刻积累数据,发现问题及时通知,而不是到了一定程度,忍无可忍时再去通知,当软件不得不进行重构时,发愁的不仅是开发,还有测试。

  5、规范:有严格的自动化脚本编写规范、每个里程碑的自动化测试目标明确、每个里程碑的测试策略明确、脚本编制人、编制日期、测试功能点、期望结果等要清晰可辨,这些都是为了脚本的易维护性而考虑的;

 

---------------------------------------------------------------------------------------------------------------

 

 

软件测试自动化十大求生法则

Surviving the Top Ten Challenges of Software Test Automation

1. Buying the wrong tool
2. Inadequate test team organization
3. Lack of management support
4. Incomplete coverage of test types
5. Inadequate tool training
6. Lack of tool ownership and acceptance

7. Lack of a basic test process or understanding of what to test
8. Script maintenance and configuration management issues
9. Lack of tool compatibility and interoperability
10. Lack of tool availability

 

参考:

http://www.cqaa.org/data/documents/May%202004.pdf

 

 

 

 

---------------------------------------------------------------------------------------------------------------

 

 

影响自动化测试成败的因素

Following factors effects on test automation :

1    Automation Framework    Availability    High

A Good framework makes your scripting, debugging and maintenance easier. Do understand that framework needs continuous updating across the script development.

2    Application    Repeat functionality    High

It is quite easier to automate in case the functionality repeats across the application (Recommend to use keyword driven in such cases, as you do not end up in writing more action/verification based methods). If NOT, then the effort of building libraries and/or scripts is more linear in nature.

3    Project    Test Scope    High

If the complexity of application as well as the test scope is complex in nature, then it would consume huge efforts to automate each test case.

4    Test tool    Support to AUT    Medium

The test tool to be used may not support some application functionality and may cause overhead. You may find it more difficult to get started with open source scripting and/or tools.

5    Scripter    Skill    Medium

This costs project. The right skill packages of the scripter are very essential for any good test automation. If the customer NOT willing to provide the leverage on the estimate for this factor, do NOT forget to add the learning curve cost to the overall time.
6    Application    Custom Objects    Medium

The number of custom objects in the automation scope matters as it becomes overhead for the test automation team to built and maintain the libraries for them.
7    Application    Type (Web/ Client-Server / Mainframe)    Medium

For web application, any commercial test tool has amazing utilities and support. Otherwise, there are good possibilities that you need to spend huge effort in building libraries.
8    Application    Developed Language & Medium    Low

It matters as selected test tool does not support specific verification checkpoints.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

 

参考:

factors-that-affects-test-automation

http://www.automationdioxide.com/2010/02/factors-that-affects-test-automation/#more-104

 

-------------------------------------------------------------------------------------------

 

 

自动化测试需要循序渐进

It's tempting to just grab the first test case you see and start automating it. Resist that. Instead, look for those tests that are most time consuming, or most prone to human error. Automate those first, and then look for other tests.

 

参考:

Waterfall Test Automation – Be Nimble without Being “Agile”

 

-------------------------------------------------------------------------------------------

 

 

是否需要QTP?

Are you sure you want to use QTP?

http://mercuryquicktestprofessional.blogspot.com/2006/11/are-you-sure-you-want-to-use-qtp.html


More often than not, I have seen people going for test automation just because they want to go for this exciting buzzword. It is generally realized in the very end that automation has not given intended returns.I would suggest that before even thinking of Automation a thorough study of your application/system/module should be performed.

The following types of test cases are preferred (but not limited to) choice for automation:

 

Tests that need to run for every build.
Tests that use multiple data values for same action.
Identical tests that need to be executed using different browsers

The following types are not considered to be the good candidates for automation:


Test Cases that will only be executed once.
Test Cases used for Ad-hoc/random Testing.
Test Cases that are infrequently selected for execution.
Test Cases that will require manual intervention ie a task not possible to automate.
The most imp. one--based on the intuition and knowledge of application. Eg. if you find that you cannot escape from manual intervention.


Above all the effort required to develop and maintain the automated scripts should be weighed against the resources (no of hours, budget) that task would take while manual execution. The amount of changes the application undergoes from one build to another should also be taken into account while choosing for test automation.

If an app undergoes drastic changes that means most time will be exhausted in maintaining the scripts. These apps are then considered bad choice for automation.
Considering the above points Return On Investment (ROI) should be calculated and this should be the single most important criterion while going for Test Automation.

 

-------------------------------------------------------------------------------------------

 

 

清楚认识自动化测试的优缺点

 

  Automaton 测试的优点

  1.   通过手工测试无法做到覆盖所有代码路径。
  2.   简单的功能性测试用例在每一轮测试中都不能少,而且具有一定的机械性、重复性,工作量往往较大。
  3.   许多死锁、资源冲突、多线程等有关的错误,通过手工测试很难捕捉到。
  4.   进行系统压力、性能测试时,需要模拟大量数据或大量并发用户等各种应用场合时,很难通过于工测试来进行。
  5.   进行系统可靠性测试时,需要模拟系统长时间运行,以验证系统能否稳定运行,这也是手工测试无法模拟的。
  6.   如果有大量(几千)的测试用例,需要在短时间内(1天)完成,手工测试几乎不可能做到。

  Automation 测试的缺点

  1.   功能测试,自动化不能取代手工测试,手工测试比自动测试发现的缺陷更多
  2.   测试自动化不能提高有效性
  3.   软件开发语言模型将制约自动化工具,自动化测试的普遍应用存在局限
  4.   工具本身并无想象力,不能主动发现缺陷
  5.   一种测试工具不完全适用于所有测试,要划分覆盖区域
  6.   自动测试不一定减轻工作量,要有专门的测试小组专门负责此事
  7.   测试进度可能不一定缩短
  8.   如果项目还在开发阶段,脚本维护成本高

 

-------------------------------------------------------------------------------------------

 

除非被测试的软件需要重复测试7次以上,否则没有做自动化测试的意义

 

The biggest barrier to test automation is remains the level of maintenance required to sustain it.

 

unless you will run a script a minimum of seven times, there will not be any payback from automation.

 

QA teams now have to accept that requirements can often change during and after each iteration, depending on the feedback from the ustomer. These changes in requirements are consequently reflected in the code and the tests that QA teams have to develop, which in turn can lead to a large amount of rework and script maintenance.

 

 

参考:

Throw Away Test Automation

http://www.origsoft.com/_assets/client/docs/pdf/whitepapers/throw_away_test_automation.pdf

 

------------------------------------------------------------------------------------------------

 

自动化测试的常见误解:

Find more bugs

Eliminate or reduce manual testers

 

自动化测试失败的通常原因:

Unrealistic expectations

Lack of planning

Lack of a process

 

参考:

http://www.benchmarkqa.com/pdf/papers_automation_myths.pdf 

 

 

-----------------------------------------------------------------------------------------------------------

 

自动化测试就像减肥

 

为什么大部分的测试仍然手工执行?工具太难用吗?是的,这确实是其中一个原因,但是仅仅如此吗?

Why is the majority of testing still performed manually? True, many tools are too hard to use and maintain, but is that the only reason?

 

最近我再一次被提醒说:购买测试自动化工具就像参加一个健康俱乐部。唯一减掉的是你的钱包的重量。一旦最初的欣喜过去后,你会意识到你原来要用这个工具!在健康俱乐部,那意味着花时间到那去,学习那些器械,然后消耗热量。你必须受尽煎熬,一个小时接着一个小时,一天又一天地。在你能看到结果前,你需要花上大量的时间。

 

而对于测试工具,你需要留出专门的时间来学习工具,在享受它带来的好处之前必须消耗大量的精力、付出努力。而且,就像我们家的角落的尘埃一样,测试工具的架子上也有很多。

 

参考:

http://blog.csdn.net/Testing_is_believing/archive/2007/12/18/1947604.aspx

Automation Works When You Do

http://www.softwaretestpro.com/Item/4750/Automation-Works-When-You-Do/Functional-Life-Cycle-Process-Quality-Assurance-Regression-Test-and-QA-Testing

 

-------------------------------------------------------------------------------------------------------

 

 

对测试工具进行测试!

 

"Testers get indignant when they realize that the quality tools purchased at a serious price are themselves full of bugs. Indeed, test tools are often buggier than comparable (but cheaper) development tools. Plan to test your tools and spend time finding workarounds for bugs."

                                                                        - Lessons Learned in Software Testingby Cem Kaner, James Bach and Bret Pettichord

 

参考:

Lesson 114 – Test tools are buggy

http://testautomationblog.com/2009/04/09/lesson-114-test-tools-are-buggy/

 

----------------------------------------------------------------------------------

 

 

 

录制回放不是一切

 

录制脚本往往看起来能很快地创建脚本,但是脚本创建只是自动化测试中很小的一部分而已。

In fact the actual script creation rarely takes more than 20-30% of the time you invest in automation.

 

 

参考:

Record/Playback Does Not Work…

http://testautomationblog.com/2009/03/16/record-playback-does-not-work/

 

----------------------------------------------------------------------------------------------------

 

 

探索性自动化测试

 

Exploratory Automated Testing is a method integrating Test Automation within the Exploratory Testing Session that enables the testers better bug reproduction, regression tests execution and evidence gathering. In addition, Exploratory Automated Testing is a cheaper way to enjoy the benefits of automation.

 

参考:

http://www.softwaretestpro.com/Item/4792/Exploratory-Automated-Testing---Download/Exploratory-Automation-Testing

 

 

------------------------------------------------------------------------------------------

 

不要在bug满天飞的项目中进行自动化测试

 

"Do not automate buggy software."

 

参考:

http://testautomationblog.com/2009/05/13/failed-automation-projects/

 

 

----------------------------------------------------------------------------------------

 

 

 

自动化测试就像“油”

 

自动化测试就像“油”,如果由经验丰富的厨师来使用,则会让测试更快、更好、更强大

When applied by a skilled cook it makes tests faster, better, more powerful, and adds to the cooking that was already happening. It doesn't select ingredients for you or teach you to cook, but it can enhance what you are already doing.

参考:

Snake Oil or Substance? Test Automation

http://blog.testyredhead.com/2010/03/26/snake-oil-or-substance-test-automation.aspx

 

 

 

------------------------------------------------------------------------------------------

 

 

 

关键字框架不能解决所有自动化测试的问题

 

很多企业的测试人员缺乏或根本不具备编程能力,因此关键字框架似乎成为自动化测试框架的不二选择,“让不懂脚本编写的人也能做自动化测试!”

 

然而,事实如何呢?

 

While keyword-driven sounds wonderful, it is not a magical methodology that will solve all automation problems and cure world hunger. 

 

参考: 

http://testautomationblog.com/2010/05/16/keyword-driven-automated-testing/

 

----------------------------------------------------------------------------------------------

 

 

 

敏捷自动化测试

公式化的典型的自动化测试过程
1、 购买一个昂贵的GUI测试执行工具(例如 Rational、Mercury、Compuware等)
2、 定义很多测试用例
3、 招聘一个自动化测试组实现每个测试用例的自动化执行
4、 构建一个完整的测试库和框架
5、 不断地完善和修正
 
如果你的产品很容易测试并且变更不大的话,以上方式很适合。但是关于自动化测试,我们为什么想得那么狭窄?
 
尝试把自动化测试想成是“任何使用工具来支持测试”。敏捷自动化测试就是把敏捷开发的原则应用在测试自动化上。

 

参考:

http://blog.csdn.net/Testing_is_believing/archive/2007/09/02/1769330.aspx

 

 

------------------------------------------------------------------------------------------------------

 

 

是否要做自动化测试?

To Automate or Not to Automate? That is the Question!

Is automation always advantageous? When should one decide to automate test cases?

It is not always advantageous to automate test cases. There are times when manual testing may be more appropriate. For instance, if the application’s user interface will change considerably in the near future, then any automation would need to be rewritten. Also, sometimes there simply is not enough time to build test automation. For the short term, manual testing may be more effective. If an application has a very tight deadline, there is currently no test automation available, and it’s imperative that the testing get done within that time frame, then manual testing is the best solution.

However, automation has specific advantages for improving the long-term efficiency of a software team’s testing processes. Test automation supports:

  • Frequent regression testing
  • Rapid feedback to developers during the development process
  • Virtually unlimited iterations of test case execution
  • Customized reporting of application defects
  • Support for Agile and eXtreme development methodologies
  • Disciplined documentation of test cases
  • Finding defects missed by manual testing

 

摘自seleniumhq.org

http://seleniumhq.org/docs/01_introducing_selenium.html#to-automate-or-not-to-automate-that-is-the-question

 

 

-----------------------------------------------------------------------------------------

 

自动化测试不是一个人的事情,是一个团队的事情

我看到很多企业的测试人员在做自动化测试的时候都是一两个人在研究,或者是单兵作战,自己琢磨,甚至是一个人身兼多职,偶尔客串一下自动化测试,有很多人是半路出家,领导头脑一发热,就指派了一个人去做自动化测试,而这个人可能根本不知道如何开展自动化测试。可想而知,这样的自动化测试怎能顺利开展?!

自动化测试对人有一定的要求,并不是随便抓一个人就可以去做自动化测试的。自动化测试工程师需要有一个完整的自动化测试知识体系。

 

参考:

http://blog.csdn.net/broadview2006/archive/2010/06/30/5703818.aspx

 

 

 

posted on 2010-07-01 14:01  TIB  阅读(2858)  评论(1编辑  收藏  举报

导航