编写测试自动化框架：使用什么模式？
我正在编写一个测试自动化框架，其中涉及自动测试具有 200 个屏幕的基于 Winforms 和 WPF 的应用程序。自动化框架应该执行控件单击和屏幕操作，就像测试人员通过手动单击屏幕上的控件来测试案例一样。
仅当发生以下情况之一时，框架才能更改：
- 添加新屏幕和功能。
- 现有屏幕已修改（UI）。
- 现有的屏幕功能被修改。例如，将 ListView 更改为 GridView 以在单击按钮时显示数据。
- 业务规则的变化。
我对模式很陌生，正在学习。根据这些要求，有人可以告诉我哪些模式可能证明最有用（如果有的话）是编写这个框架？
I am writing a Test Automation Framework that involves automating testing a Winforms and WPF based application having 200 screens. The Automation Framework should do the control clicks and screen actions just as a tester would do to test a case by manually clicking the controls on the screens.
The Framework can change only when one of the following happens:
- New screens and functionalities are added.
- Existing screens are modified (UI).
- Existing screen functionalities are modified. For example, changing a ListView to a GridView to show data on a button click.
- Changes in business rules.
I am new to patterns, and am learning. Based on these requirements, can someone please tell me what patterns may prove most useful (if at all) is writing this fraemwork?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在尝试列出所需的所有模式之前，您应该为应用程序设计更高级别的体系结构。仅从描述来看，我猜您需要某种“表单解析”或“组件映射”，它们将被传递给“参与者”，该“参与者”将执行与组件相关的操作（例如单击、插入文本）。最后，表格被提交到试镜系统。这显然是我的做法，可能还有更好的方法。
Before you attempt to list all the patterns you need, you should design a higher level architecture for the application. Just from the description I guess you would need some sort of "form parsing" or "component mapping" which will be passed to an "actor" which will carry out actions associated with the components (e.g. click, insert text). At the end the form is submitted to the audition system. This is obviously my way of doing it, probably there is a better way.
上面的 Snowbear 是正确的......一些细节会有所帮助。但很明显，您将使用 Command 和 装饰器模式，当然。
请记住 - 模式是战场战术，而不是法律。它们需要进行调整以适应战场。当我学习它们时，我必须克服使用它们时墨守成规的倾向。
Snowbear is correct above...some specifics would help. But it seems pretty obvious that you'd be using the Command and Decorator patterns, for sure.
Just keep in mind - patterns are battlefield tactics, not laws. They need to be adjusted to fit the battlefield. I had to overcome a tendency to be legalistic about using them when I learned them.
我不确定您是否会接受这个答案，但这里是：
不要编写框架。努力寻找和试验现有的测试工具。 WPF UI 测试与 WinForms 测试有很大不同。模式是您最不需要担心的。
编辑看看这些帖子：
I am not sure you will accept this as an answer but here goes:
Don't write a framework. Put effort in finding and experimenting with existing testing tools. WPF UI testing is very different from WinForms testing. Patterns are the least of your worries.
EDIT Have a look at these posts: