如果您处于我的位置,您有一个大型 WebForms 应用程序,它已经升级为这种无法维护的东西。当您添加新功能并且您需要一种廉价的可维护方式来进行某种自动化测试时,事情就会发生变化。
现在,根据我的理解,正确的做法是尝试构建 ASP.NET WebForms 中存在的页面和用户控制模型的抽象布局,但是,鉴于这需要对现有应用程序进行大量投资,它不是一个选项。
我正在尽可能地尝试并插入类似 REST 的开发,因为它具有一些不错的属性。在执行此操作时,我编写了一个简单的蜘蛛机器人,它可以抓取它可以找到并尝试的所有 URL,只需获取它们即可。 这使我能够快速找到导致问题的不良数据,并避免让我的最终用户点击损坏的东西,但是,这当然是不够的。
我继续开发我的爬虫,它已经发展成为一个简单的 REST 客户端,可以尝试不同的输入组合,寻找可能的错误或崩溃。它比详尽搜索更智能(因为它了解 ASP.NET WebForms 应用程序层),我的目标是基本上探索 Web 应用程序的状态,希望在我们的用户之前找到所有的角落案例。
有没有人有做类似事情的经验?
此外,对于您来说,测试专家们也是如此。这完全是在浪费时间,还是我真的可以在这里谈谈质量?从我的角度来看,它似乎达到了一个最佳点,因为它会尝试潜在最终用户通过浏览器会做的事情。
正如我之前所说,我们陷入了困境。我们现在需要一种简单的解决方法。
我们已经尝试过像 Selenium 这样的东西,但它需要做很多额外的工作,而且我们一直在改变,不可能为 50 个不同的应用程序维护多个 selenium 测试套件。
最佳答案
在所有要实现的测试类型中,就错误更少和代码更易于维护而言,单元测试是最简单且最有可能产生结果的。在处理自动化集成测试之前解决这个问题
- 选择一个 IOC 容器 - 我喜欢 Ninject为此个人
- 找到一个方便的地方将“服务”类注入(inject)您的页面(基类的构造函数或覆盖加载页面的模块,无论对您有用)
- 选择一个单元测试框架,如果您没有自动构建,则设置一个;包括在该构建中运行一整套单元测试
- 每次你接近 aspx.cs 文件中的一段逻辑时,看看你是否可以将它隔离在一个服务中并围绕它进行单元测试
- 看看 MVP Pattern 是否对你有好处——我们发现它降低了生产力,同时增加了可测试性(两者都做了很多),但它对某些人有效
- 了解如何将您的应用缓慢迁移到 MVC,a page at a time if necessary
请记住,您不会在一夜之间解决这个问题,您没有时间。只要不断提高测试覆盖率,您就会随着时间的推移看到好处。
关于asp.net - 测试 ASP.NET webforms 应用程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2301659/