MBUnit测试矩阵优化——自动化ui测试中的性能问题
我们目前使用 MBUnit 进行单元测试和 UI 测试。对于 UI 测试，测试矩阵轴的设置成本相当高（登录、浏览器实例、导航到页面等）。为了避免为每个测试用例设置这些，我们部分依赖 AssemblyFixture 来管理其中的一些。
然而，由于无法过滤掉某些不适用于某些组合的情况，因此我们不可能真正使用这种优化。所以目前我们正在为每个测试用例做一些设置，效率非常低。
我们可以将 if 语句放入测试代码中来检查组合是否正确，但我们也不希望这样做。它污染了测试代码。
你们是如何进行此类优化的？或者测试矩阵管理？在另一个测试框架中是否有更好的实践？
We're currently using MBUnit for both unit testing and UI testing. For UI testing setup cost for test matrix axes are pretty high (login, browser instance, navigate to page etc). In order to avoid setting up these for each test case we are partly relying on AssemblyFixture to manage some of them.
However because it's not possible to filter out certain cases where they are not applicable to certain combination, it's not possible for us to really use such optimization. So currently we are doing some of the setup per test-case, horribly inefficient.
We could put if statements inside test code to check for correct combinations but we don't desire that either. It pollutes test code.
How do you guys do such optimizations? or test matrix management? Is there a better practice, in another testing framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
直到最近，我一直将 UI 自动化视为黑盒测试，其中我的 UI 测试针对完全独立的网站或应用程序进行驱动。因此，测试在正常执行的约束下运行，并受到许多环境开销问题的影响。
我最近采用了“浅层”和“深层”UI 测试的概念，其中每组测试都在优化的配置下运行，以缓解环境差异并加快速度。例如，登录控制器被替换为一种避免 OAuth 登录开销的机制，并使用固定用户名进行硬编码。产品目录跳过数据库查找，并使用一些固定项目进行硬编码。电子商务后端被替换为执行基于信用卡和金额接受/拒绝交易的快速操作。
在“浅层”配置下，我可以针对 UI 逻辑执行“深度”测试。当我切换到“深度”配置时，它类似于生产，我可以对完全集成的组件（例如登录、产品目录、搜索等）执行“浅层”测试。
需要混合使用测试策略。
Until recently, I've always thought of UI Automation as black box testing where my UI tests drive against a fully stand alone web site or application. As a result, the tests run under the constraint of normal execution and are subject to a host of environment overhead issues.
I've recently adopted the notion of "shallow" and "deep" UI tests where each set of tests run under an optimized configuration to ease environmental differences and speed things up. For example, the login controller is swapped out with a mechanism that avoids OAuth login overhead and is hard coded with fixed usernames. The product catalog skips database lookup and is hard coded with a few fixed items. The ecommerce backend is swapped out to perform speedy operations that accept/reject transactions based on credit card and amount.
Under a "shallow" configuration I can perform "deep" testing against the UI logic. When I switch to a "deep" configuration, it resembles production and I can perform "shallow" testing of fully integrated components such as login, product catalog, search, etc.
A mix of testing strategies is required.
可能是 ui-test-automation-best-practices< /a> 文章对你有帮助。它有一些示例，说明如何通过最小化登录和上下文更改来提高自动化 ui 测试的性能。
May be the ui-test-automation-best-practices article is helpful for you. It has some examples how to improve performance of automating ui testing by minimizig logins and context changes.