测试ASP.NET webforms应用程序

如果您处于我的位置,那么您将拥有一个大型的WebForms应用程序,这些应用程序已经升级为这种无法维护的东西.当您添加新功能并且需要一种廉价的可维护方式来进行某种自动化测试时,事情就会中断.

现在,根据我的理解,正确的做法是尝试构建ASP.NET WebForms中存在的页面和用户控件模型的抽象布局,但是,因为它需要在现有应用程序中进行大量投资,所以它不是选项.

我正在努力并尽可能地推动类似REST的开发,因为它有一些不错的属性.在这样做的过程中,我编写了一个简单的蜘蛛机器人,可以抓取它可以找到并尝试的所有URL,只需获取它们即可.这使我能够快速找到导致问题的错误数据并避免让我的最终用户点击破碎的东西,但是,这当然是不够的.

我继续处理我的爬虫,它被开发成一个简单的REST客户端,尝试不同的输入组合,寻找可能的错误或崩溃.它更加智能,只是一个详尽的搜索(因为它了解ASP.NET WebForms应用程序层),我的目标是基本上探索Web应用程序的状态,希望能够在我们的用户之前完成所有角落案例.

有没有人有类似的经历？

另外,为你测试大师.这是完全浪费时间,还是我能够在这里真正说出质量问题？从我的角度来看,它似乎达到了一个最佳点,因为它将尝试潜在的最终用户通过浏览器.

正如我之前所说,我们陷入了困境.我们现在需要一种简单的方法.

我们已经尝试过像Selenium这样的东西,但它要求进行大量的额外工作并且我们一直在改变事物,不可能为50种不同的应用程序维护多个硒测试套装.

在要实现的所有类型的测试中，就单元测试而言，以更少的错误和更可维护的代码来看，既是最容易的也是最有可能产生结果的。在进行自动化集成测试之前，先解决问题

选择一个IOC容器-我个人很喜欢Ninject

寻找一个方便的位置，将“服务”类注入您的Page（基Page类的构造器，或覆盖加载页面的模块，无论您使用什么方法）

选择一个单元测试框架，如果没有自动构建，则进行设置。包括在该版本中运行全套单元测试

每次您接近aspx.cs文件中的逻辑时，请查看是否无法将其隔离在服务中并在其周围包装单元测试

看一下MVP模式是否对您有好处-我们发现MVP模式降低了生产率，同时增加了可测试性（两者都做了很多），但是它对某些人有用

了解有关将您的应用缓慢迁移到MVC的信息，如有必要，一次查看一个页面

请记住，您不会在一夜之间解决此问题，因为您没有时间。只要不断提高测试覆盖率，您就会逐渐看到好处。