【问题标题】:UI Testing Framework + Continuous Integration?UI测试框架+持续集成?
【发布时间】:2014-09-28 19:18:04
【问题描述】:

所以我有一个我继承的应用程序,我想围绕它构建一个自动化测试套件。该应用程序在设计时并未考虑可测试性,并且代码是一个“大泥球”。我的计划是使用 UI 自动化测试框架并在 UI 级别创建一套测试,直到我有足够的覆盖率,让我可以自信地开始重构并在代码中引入一些接缝以提高可测试性和设计。

这是一个 .Net WinForms 应用程序,我知道的两个框架是:

NUnitForms

Project White

根据我的阅读,这两个框架在尝试作为自动构建(持续集成)的一部分运行时都会出现问题,因为大多数 CI 产品作为 Windows 服务运行,并且如果 UI 使用模式对话框,应用程序将死于可怕的死亡。我使用 CruiseControl.Net 作为我的 CI 工具。

是否有人对解决此问题有任何建议?使用替代框架可能会使情况变得更好?

谢谢,

迪伦

【问题讨论】:

    标签: c# winforms unit-testing continuous-integration cruisecontrol.net


    【解决方案1】:
    【解决方案2】:

    您实际上可以通过控制台应用程序运行巡航控制,这样它就可以进行交互式桌面访问。如果服务器重启或崩溃,它不会自动恢复,但至少你可以做到。

    也就是说,大多数人采用自动化 UI 测试(winforms、wpf 或 web)的方法是通过构建服务器运行所有非交互式测试。一旦这些测试通过,他们就会将应用程序部署到测试环境,并针对新构建的代码版本手动触发测试运行。

    这使人们有机会重置测试环境(对于 UI 测试很重要),并检查新版本的应用程序是否正确构建以及所有单元测试是否通过。毕竟,如果您知道单元测试失败了,那么运行 UI 测试毫无意义。 :-)

    【讨论】:

    • 对,但在我的情况下,我没有任何其他测试。而且我创建的任何测试套件都绝对希望让它在自动化的基础上运行,否则我们冒着测试“腐烂”的风险,并且在它们破裂并且没有人看它们时变得无用......关于 cc 的好信息.net 控制台应用程序
    【解决方案3】:

    我还没试过,但是有来自微软的UI Automation Framework

    【讨论】:

    【解决方案4】:

    我们在控制台模式下运行持续集成验收测试,而不是作为登录的 Virtual PC 中的 Windows 服务。这对我们有用。

    【讨论】:

      【解决方案5】:

      看看this approachproject's wiki有详细信息。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2010-10-21
        • 2015-03-24
        • 2015-12-03
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多