测试 ASP.NET webforms 应用程序

Testing ASP.NET webforms applications(测试 ASP.NET webforms 应用程序)

本文介绍了测试 ASP.NET webforms 应用程序的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果你在我的位置上,你有一个大型的 WebForms 应用程序,它已经升级到这个无法维护的东西.当您添加新功能并且您需要一种廉价的、可维护的方式来进行某种自动化测试时,事情就会破裂.

If you're in my position you have a big WebForms applications which have escalated to this unmaintainable thing. Things break when you add new features and you need an inexpensive maintainable way to do some kind of automated testing.

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

Now, from my understanding, the right thing to do would be to try building an abstraction layout of the page and user control model present in ASP.NET WebForms however, seeing as it would require a major investment in an existing application it is not an option.

我正在尽可能地尝试和推动类似 REST 的开发,因为它具有一些不错的特性.在执行此操作时,我编写了一个简单的蜘蛛机器人,它会抓取它可以找到并尝试的所有 URL,只需获取它们即可.这使我能够快速找到导致问题的错误数据,并避免让我的最终用户点击损坏的内容,但是,这当然还不够.

I'm trying and pushing for a REST-like development as much as possible because it has some nice properties. And while doing this I've written a simple spider bot that crawls all URLs it can find and tries, simply getting them. This allowed my to quickly find bad data that was causing problems and avoid having my end-users clicking on broken things, however, this is of course not enough.

我继续研究我的爬虫,它被开发成一个简单的 REST 客户端,它尝试不同的输入组合,寻找可能的错误或崩溃.仅进行详尽的搜索(因为它了解 ASP.NET WebForms 应用程序层)更智能,我在这里的目标是基本上探索 Web 应用程序的状态,希望在我们的用户之前找到所有极端情况.

I continued work on my crawler and it's developed into a simple REST client that tries different input combination, looking for a probable bug or crash. It's more intelligent that just an exhaustive search (because it knows about the ASP.NET WebForms application layer) and my goal here is to basically explore the state of the web application, hoping to hit all the corner cases before our users.

有没有人做过类似的事情?

Does anyone have any experience doing something similar?

另外,为了您测试大师.这完全是在浪费时间,还是我真的可以说一下这里的质量?从我的角度来看,它似乎达到了一个甜蜜点,因为它将尝试潜在的最终用户通过浏览器进行的操作.

Also, for you test gurus out there. Is this a complete waste of time, or will I be able to actually say something about the quality here? From my perspective it seems to hit a sweet spot in that it will try things a potential end user would though a browser.

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

As I said before, we're stuck in a bad place. And we need a simple way out of it, right now.

我们尝试过像 Selenium 这样的东西,但它需要大量额外的工作,而且我们一直在改变,不可能为 50 个不同的应用程序维护多个 selenium 测试套件.

We've tried things like Selenium, but it mandates a lot of extra work and we change things all the time, it's just no possible to maintain multiple selenium test suits for 50 different applications.

推荐答案

在所有要实施的测试类型中,单元测试是最容易并且最有可能产生结果的,因为它的错误更少,代码更易于维护.在处理自动化集成测试之前先解决这个问题

Of all the types of testing to implement, unit testing is both the easiest and the most likely to yield results, in terms of less bugs and more maintainable code. Get that worked out before you deal with automated integration testing

  1. 选择一个 IOC 容器 - 我个人喜欢 Ninject
  2. 找到一个方便的地方将服务"类注入到您的页面中(基本页面类的构造器或覆盖加载页面的模块,无论对您有用)
  3. 选择一个单元测试框架,如果你没有自动构建,那就设置一个;包括在该构建中运行一整套单元测试
  4. 每次接近 aspx.cs 文件中的一段逻辑时,看看是否无法将其隔离在服务中并围绕它进行单元测试
  5. 看看 MVP 模式是否适合您 - 我们发现它在提高可测试性的同时降低了生产力(两者都做了很多),但它适用于某些人
  6. 了解如何将您的应用缓慢迁移到 MVC,如有必要,一次一个页面
  1. Pick an IOC Container - I like Ninject for this personally
  2. Find a convenient place to inject "service" classes into your Page (the consturctor of a base Page class or override the module that loads pages, whatever works for you)
  3. Pick a unit test framework and if you don't have an automated build then set one up; include running a full suite of unit tests in that build
  4. Every time you go near a piece of logic in an aspx.cs file, see if you can't isolate it in a service and wrap unit tests around it
  5. Take a look at whether the MVP Pattern would be good for you - we found it decreased productivity as much as it increased testability (it did both a lot), but it works for some people
  6. See about slowly migrating your app over to MVC, a page at a time if necessary

请记住,您不会在一夜之间解决此问题,因为您没有时间.只要不断提高测试覆盖率,随着时间的推移,您就会看到好处.

And remember, you are not going to fix this problem overnight, you don't have time. Just keep improving test coverage and you'll see the benefits over time.

这篇关于测试 ASP.NET webforms 应用程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!

本文标题为:测试 ASP.NET webforms 应用程序

基础教程推荐