By Lisa Crispin
Tag: Automated Software Testing
Automation seems to be a big buzzword, but I hear it used in different contexts. In terms of testing, does automation simply mean any kind of testing that isn’t manual, such as unit tests? Or does it mean tools that record a user’s actions and then play them back?
Automation is a broad term that includes automating tests, automatingcontinuous integration
and deployment, and automating all types of repetitive tasks to improve reliability and free up time for activities that require human skills and critical thinking.
Even within testing, automation applies to a broad spectrum of tests, tools and frameworks. Tests are used to drive coding, critique the finished code, and evaluate functional and extra-functional quality. It’s hard to learn how to automate tests, but when done properly, automated tests allow the team to deliver value to the business at frequent intervals, working at a sustainable pace. When you decide whether or not a particular test needs to be automated, you have to consider the cost of the test and the benefits it will provide over the long term.
One good way to understand test automation is to use Mike Cohn’s Test Automation Pyramid. Unit-level tests are the least expensive to write and maintain, and provide value to the team multiple times per day. Using them to drive coding in test-driven development (TDD) lets programmers think through and verify their code design. They have a high return on investment (ROI) and should form the solid base and largest part of our test automation triangle. Teams use the XUnit tools for this automation.
The next layer is tests that run at the API or service layer, behind the user interface. Teams new to test automation often know the least about this layer. This is where we can test the business logic and algorithms of our software at a reasonable cost. A few examples of frameworks and tools for this middle layer are FitNesse, Robot Framework, Cucumber, and Twist. The whole team needs to collaborate on these tests, which helps ensure customer requirements are understood and met.
At the top of the pyramid are GUI tests. Historically, these are the most expensive tests to write and maintain. A record and playback approach can be useful to learn how to use a test tool, but you should not use recorded scripts in a regression test suite. All automated tests need to be designed with the same attention and good practices as production code, and refactored often to keep them maintainable. Today there are many excellent GUI test tools that allow good design, using macros, classes and mixins to eliminate duplication. A few examples of popular web UI test tools and frameworks are Selenium, Watir, Canoo WebTest and TestComplete. GUI test tools can be combined with service-layer test frameworks to improve maintainability and result reporting. For example, Selenesse provides a way to drive Selenium commands from FitNesse test pages.
Another helpful taxonomy to help your team decide what tests to automate is Brian Marick’s Agile Testing quadrants. On the left side of the matrix are tests that support the team by helping them know what code to write. On the right side are tests that critique the product and learn whether it provides the right value to the business. On the top are customer-facing tests where the business articulates desired system behavior, and on the bottom are technology-facing tests that help the team verify extra-functional qualities such as performance and security.
Tag: Automated Software Testing
Automation seems to be a big buzzword, but I hear it used in different contexts. In terms of testing, does automation simply mean any kind of testing that isn’t manual, such as unit tests? Or does it mean tools that record a user’s actions and then play them back?
Automation is a broad term that includes automating tests, automatingcontinuous integration
and deployment, and automating all types of repetitive tasks to improve reliability and free up time for activities that require human skills and critical thinking.
Even within testing, automation applies to a broad spectrum of tests, tools and frameworks. Tests are used to drive coding, critique the finished code, and evaluate functional and extra-functional quality. It’s hard to learn how to automate tests, but when done properly, automated tests allow the team to deliver value to the business at frequent intervals, working at a sustainable pace. When you decide whether or not a particular test needs to be automated, you have to consider the cost of the test and the benefits it will provide over the long term.
One good way to understand test automation is to use Mike Cohn’s Test Automation Pyramid. Unit-level tests are the least expensive to write and maintain, and provide value to the team multiple times per day. Using them to drive coding in test-driven development (TDD) lets programmers think through and verify their code design. They have a high return on investment (ROI) and should form the solid base and largest part of our test automation triangle. Teams use the XUnit tools for this automation.
The next layer is tests that run at the API or service layer, behind the user interface. Teams new to test automation often know the least about this layer. This is where we can test the business logic and algorithms of our software at a reasonable cost. A few examples of frameworks and tools for this middle layer are FitNesse, Robot Framework, Cucumber, and Twist. The whole team needs to collaborate on these tests, which helps ensure customer requirements are understood and met.
At the top of the pyramid are GUI tests. Historically, these are the most expensive tests to write and maintain. A record and playback approach can be useful to learn how to use a test tool, but you should not use recorded scripts in a regression test suite. All automated tests need to be designed with the same attention and good practices as production code, and refactored often to keep them maintainable. Today there are many excellent GUI test tools that allow good design, using macros, classes and mixins to eliminate duplication. A few examples of popular web UI test tools and frameworks are Selenium, Watir, Canoo WebTest and TestComplete. GUI test tools can be combined with service-layer test frameworks to improve maintainability and result reporting. For example, Selenesse provides a way to drive Selenium commands from FitNesse test pages.
Another helpful taxonomy to help your team decide what tests to automate is Brian Marick’s Agile Testing quadrants. On the left side of the matrix are tests that support the team by helping them know what code to write. On the right side are tests that critique the product and learn whether it provides the right value to the business. On the top are customer-facing tests where the business articulates desired system behavior, and on the bottom are technology-facing tests that help the team verify extra-functional qualities such as performance and security.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-690502/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/11379785/viewspace-690502/
15万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
