敏捷开发中的测试金字塔(转)
2013-09-16 09:35
148 查看
最近一个爱尔兰的同事介绍了我们agile模式下的automation的工作机制,提到了测试金字塔的概念。值得推敲。
其中主要的思想就是,针对automation工作我们更多的focus点应该是Unit test,对于所有的UI Automation工作所在的级别比较高,但是我们更应该的注意的是所有的UI Cover的点其实都应该在Unit Test中Cover到的,如何UI 测试中出现了任何问题其实都可以追究到Unit Testing没有Cover到。体现了Unit Testing的重要性。
Unit Test应该做的比UI Automation和Service Automation做的更多。
如下是他的讲解:(http://martinfowler.com/bliki/TestPyramid.html)其实很值得一提。有种醍醐灌顶的感觉。。。
The test pyramid is a concept developed by Mike Cohn, described in his book Succeeding with Agile
![](http://www.assoc-amazon.com/e/ir?t=martinfowlerc-20&l=as2&o=1&a=0321601912)
. Its essential point is that you should have many more low-level unit tests than high level end-to-end tests running through a GUI.
![](http://martinfowler.com/bliki/images/testPyramid/pyramid.png)
For much of my career test automation meant tests that drove an application through its user-interface. Such tools would often provide the facility to record an interaction with the application and then allow you to play back that interaction, checking that the application returned the same results. Such an approach works well initially. It's easy to record tests, and the tests can be recorded by people with no knowledge of programming.
But this kind of approach quickly runs into trouble, becoming an ice-cream cone. Testing through the UI like this is slow, increasing build times. Often it requires installed licences for the test automation software, which means it can only be done on particular machines. Usually these cannot easily be run in a "headless" mode, monitored by scripts to put in a proper deployment pipeline.
Most importantly such tests are very brittle. An enhancement to the system can easily end up breaking lots of such tests, which then have to be re-recorded. You can reduce this problem by abandoning record-playback tools, but that makes the tests harder to write. [1] Even with good practices on writing them, end-to-end tests are more prone tonon-determinism problems, which can undermine trust in them. In short, tests that run end-to-end through the UI are: brittle, expensive to write, and time consuming to run. So the pyramid argues that you should do much more automated testing through unit tests than you should through traditional GUI based testing.
The pyramid also argues for an intermediate layer of tests that act through a service layer of an application, what I refer to asSubcutaneousTests. These can provide many of the advantages of end-to-end tests but avoid many of the complexities of dealing with UI frameworks. In web applications this would correspond to testing through an API layer while the top UI part of the pyramid would correspond to tests using something like Selenium or Sahi..
The test pyramid comes up a lot in Agile testing circles and while its core message is sound, there is much more to say about building a well-balanced test portfolio. In particular a common problem is that teams conflate the concepts of end-to-end tests, UI tests, and customer facing tests. These are all orthogonal characteristics. For example a rich javascript UI should have most of its UI behavior tested with javascript unit tests using something like Jasmine. A complex set of business rules could have tests captured in a customer-facing form, but run just on the relevant module much as unit tests are.
In particular I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing unit test. Thus whenever you fix a failing end-to-end test, you should be adding unit tests too.
其中主要的思想就是,针对automation工作我们更多的focus点应该是Unit test,对于所有的UI Automation工作所在的级别比较高,但是我们更应该的注意的是所有的UI Cover的点其实都应该在Unit Test中Cover到的,如何UI 测试中出现了任何问题其实都可以追究到Unit Testing没有Cover到。体现了Unit Testing的重要性。
Unit Test应该做的比UI Automation和Service Automation做的更多。
如下是他的讲解:(http://martinfowler.com/bliki/TestPyramid.html)其实很值得一提。有种醍醐灌顶的感觉。。。
The test pyramid is a concept developed by Mike Cohn, described in his book Succeeding with Agile
. Its essential point is that you should have many more low-level unit tests than high level end-to-end tests running through a GUI.
![](http://martinfowler.com/bliki/images/testPyramid/pyramid.png)
For much of my career test automation meant tests that drove an application through its user-interface. Such tools would often provide the facility to record an interaction with the application and then allow you to play back that interaction, checking that the application returned the same results. Such an approach works well initially. It's easy to record tests, and the tests can be recorded by people with no knowledge of programming.
But this kind of approach quickly runs into trouble, becoming an ice-cream cone. Testing through the UI like this is slow, increasing build times. Often it requires installed licences for the test automation software, which means it can only be done on particular machines. Usually these cannot easily be run in a "headless" mode, monitored by scripts to put in a proper deployment pipeline.
Most importantly such tests are very brittle. An enhancement to the system can easily end up breaking lots of such tests, which then have to be re-recorded. You can reduce this problem by abandoning record-playback tools, but that makes the tests harder to write. [1] Even with good practices on writing them, end-to-end tests are more prone tonon-determinism problems, which can undermine trust in them. In short, tests that run end-to-end through the UI are: brittle, expensive to write, and time consuming to run. So the pyramid argues that you should do much more automated testing through unit tests than you should through traditional GUI based testing.
The pyramid also argues for an intermediate layer of tests that act through a service layer of an application, what I refer to asSubcutaneousTests. These can provide many of the advantages of end-to-end tests but avoid many of the complexities of dealing with UI frameworks. In web applications this would correspond to testing through an API layer while the top UI part of the pyramid would correspond to tests using something like Selenium or Sahi..
The test pyramid comes up a lot in Agile testing circles and while its core message is sound, there is much more to say about building a well-balanced test portfolio. In particular a common problem is that teams conflate the concepts of end-to-end tests, UI tests, and customer facing tests. These are all orthogonal characteristics. For example a rich javascript UI should have most of its UI behavior tested with javascript unit tests using something like Jasmine. A complex set of business rules could have tests captured in a customer-facing form, but run just on the relevant module much as unit tests are.
In particular I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing unit test. Thus whenever you fix a failing end-to-end test, you should be adding unit tests too.
相关文章推荐
- php-前沿技术,PHP-GTK,桌面应用,测试驱动开发,DRY,REST,OOP,KISS,MVC,敏捷开发
- 敏捷开发 and 敏捷测试
- 敏捷开发团队管理系列之二:程序与测试团队I
- 产品开发中如何进行敏捷测试?
- 敏捷开发团队管理系列之四:程序与测试团队III
- 如何从架构和测试推动敏捷开发_课程大纲
- 测试管理--敏捷开发中的测试
- 软件测试-敏捷软件开发读书笔记
- 敏捷开发下测试可以怎么做?
- 有关敏捷开发的文章,NUnit,NDoc,测试
- 高效程序员的45个习惯 敏捷开发修炼之道 读书笔记 第七章 敏捷测试
- 敏捷开发团队管理系列之四:程序与测试团队III
- 敏捷开发中的软件测试
- 敏捷开发团队管理系列之四:程序与测试团队III
- 第Ⅰ部分 敏捷开发 第4章 测试
- 敏捷开发中测试角色的窘境
- 敏捷开发中,测试人员做哪些工作
- Visual Studio 2010开发与测试敏捷特性
- 敏捷开发中的测试