Spi*_*iff 14 automated-tests qa continuous-deployment
我在过去几天一直在研究自动验收测试,了解BDD&JBehave,FitNesse&Slim,Selenium和WebDriver等.
我刚刚看到这个,他演示了如何使用FitNesse的编写和维护这样的测试视频由罗伯特C.马丁.接近尾声时,有人问这些测试是否会触及用户界面.Martin接着解释说,对UI的耦合验收测试成本很高,因为对UI的更改非常频繁.我还可以猜测,这些测试只能在UI开发之后编写,这将使测试人员按照定义落后于计划.
我不得不问:替代方案是什么？Martin似乎暗示测试应该是一个隐藏的层,它会操纵应用程序的业务层.我的理解是,这需要额外的工作,更不用说它会暴露一个新的API,需要在生产环境中保护一次.
可以通过应用程序服务访问业务层就足够了吗？
你有什么经验吗？
感谢分享!
Mat*_*ell 14
通过UI进行测试或直接点击业务层可以看作是两种不同类型的测试,具有不同的优点和缺点.
如果您正在直接测试UI,那么您正在测试用户看到的内容,并且您无需更改代码以便能够对其进行测试.但是,测试极端情况或系统如何对异常情况(例如异常)做出反应变得非常困难.正如罗伯特马丁所说的那样脆弱.如果您的界面发生变化,则需要更改测试.因此,通过UI进行测试取决于UI的成熟度.在项目的后期,UI更加稳定,因此通过UI进行测试更有意义.此外,通过UI测试一些内容很难或很复杂.
如果您正在测试业务层,则可以更轻松地测试角落条件,并且您不太容易在UI中进行更改.但是,正如您所说,软件必须以允许此类测试的方式编写.您甚至可能需要公开一个允许它的新接口,然后必须对其进行维护.根据我的经验,有时很难让开发人员支持这种界面.它被视为不如真实界面重要.但它总是可能的.这种界面需要开发人员的支持,否则你会冒着"不支持"的风险.
如果您没有外部接口,请尝试询问它.你永远不会知道,你或许可以说服他们这是个好主意.在项目开始时更容易.
如果您有外部接口,那么使用它来测试您的业务逻辑.
否则,您将不得不使用UI来测试这些东西.一种方法是使用UI进行烟雾测试,回答以下问题:该软件是否可测试？想想每次从dev获得构建时必须测试的常见事项.我可以登录,我可以退出,主页面是否出现,我可以做一个简单的订单吗？选择5或6个这样的东西,并构建一个自动测试套件来测试这些东西.使用这些测试作为指导,您可以通过UI实际测试多少功能,以及它的实用性.
然后,当您转到开发人员并要求外部接口时,可以将其用作参数.
小智 9
不幸的是你需要两者.通常,您会希望使用健身等方式自动执行业务层测试.避免使用UI基本上可以确保定义的业务规则始终有效.通过UI自动化可能需要更多的维护.但是在好的方面,因为大部分UI使用平台提供的机制(例如c#/ Winforms),只有在你完全被其他类型的测试(如业务层)覆盖时才会进行更改. .需要维护和更新自动化测试,但UI测试往往需要更多维护,并且随着时间的推移通常不太可靠.
| 归档时间： |
|
| 查看次数： |
5364 次 |
| 最近记录： |