10年过去了,但是软件测试自动化领域的改变并不大!

时间:2021-06-01 04:46:59

原文:

Automation Déjà Vu...Again!

Dion Johnson

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=14335&tth=DYN&tt=siteemail&iDyn=2

 

 

1997--Cem Kaner's "Improving the Maintainability of Automated Test Suites" white paper:
"When GUI-level regression automation is developed in Release N of the software, most of the benefits are realized during the testing and development of Release N+1."
1997
年,Cem Kaner说:“GUI层面的回归测试自动化的大部分价值会在第N+1次软件发布时体现。”


1999--Bret Pettichord's "Seven Steps to Test Automation Success" white paper:
"We need to run test automation projects just as we do our other software development projects."
1999
年,Bret Pettichord说:“我们需要把测试自动化项目像我们的软件开发项目一样看待。”


1999--Mark Fewster and Dorothy Graham's Software Test Automation book:
"If no thought is given to maintenance when tests are automated, updating an entire automated test suite can cost as much, if not more, than the cost of performing all the tests manually."
1999
年,Mark FewsterDorothy Graham说:“如果在实现测试自动化时,没有考虑到维护的问题,那么后面对于整个自动化测试套件进行更新维护时,将要消耗不小于手工执行所有测试所需的时间。”


2001—Dion Johnson's Designing an Automated Web Test Environment white paper:
"With many, getting an automation tool is like a kid getting a new toy—they jump right in and start playing. And the resulting test suite, much like a child's new toy, just doesn't last."

2001年,Dion Johnson说:“对于很多人来说,得到一款自动化化测试工具就像一个小孩子拿到一款新的玩具一样 他们会马上开始玩。而结果往往是用不了多久就会被抛弃。”

 

10年过去了,但是软件测试自动化领域的改变并不大!

我们仍然面对相同的问题:

We are still preoccupied with questions such as:

  • Is record and playback an effective automation approach? (录制和回放是不是一个有效的自动化方法)
  • Is 100 percent automation possible? (百分百的自动化是否可能?)
  • How do I calculate return on investment (ROI)? (我如何计算ROI?)
  • How early can test automation begin? (测试自动化可以多早就开始?)
  • Can test automation replace manual testing? (测试自动化能否替代手工测试?)

 

 

 

Detailed Calculations for Framework Selection
Below is a formula that I often use to help define the level of complexity an automated test framework should have:

AF = AN + VN + BN + TN + CN + EN + Ti + P + R 

 

 

  • AF = Automation Framework Definition
  • AN = Number of applications expected to be tested by your organization
  • VN = Number of versions/releases that each application is expected to have
  • BN = Number of builds/nature of application changes that each application build is expected to have
  • TN = Number of tests that you're expecting to automate for each application
  • CN = Number of configurations that an application may have to test
  • EN = Number of environments in which tests will be executed
  • Ti = Time period over which the tests will need to be maintained
  • P = Organizational process maturity
  • R = Resource technical level

 

How long should one expect to develop and maintain automated tests? There is a factor that is widely accepted among industry leaders that it will take three to ten times as long to automate a test as it does to execute it once manually.

业界标准:花在测试自动化的开发和维护时间是手工执行(一次)的3~10倍。

That means if it takes you one minute to execute a test manually once, it will probably take somewhere between three to ten minutes to automate that test. This is still a fairly broad range because there is no industry standard regarding the time it should take to maintain an automated test suite given a certain scope. We need to focus on further defining this information.

 

经历了三代的自动化测试框架:

  • Generation 1 (Linear) 第一代(线性的) —Framework that is composed of automated tests where all components that are executed by a given tests are mostly contained within that automated test
  • Generation 2 (Data-driven, Functional Decomposition) 第二代(数据驱动、功能分解的)—Framework that introduces more modularization, reuse of common components among several scripts, and greater separation of data from automation code
  • Generation 3 (Keyword, Model Based) 第三代(关键字、基于模型的)—Framework that adds a new level of abstraction that separates code logic from test logic, allowing automated tests to be built and maintained in a less technical way

第四代自动化测试框架:

building detailed manual test procedures that could be interpreted by an engine and therefore double as automated tests

 

The lack of growth in test automation largely is due to the fact that test automation has not been treated as a separate discipline from manual software testing. There hasn't been a separate body of knowledge or a comprehensive resource that focuses on automation processes and procedures, as opposed to just automation tools. We must correct this, so that we can move the discipline of test automation forward and stop the automation déjà vu that we've been stuck in.

 

déjà vu 可翻译为:幻觉