Forum Discussion
AlexeyKryuchkov
13 years agoSmartBear Alumni (Retired)
Hi Steven,
Thank you for loads of feedback! Here are our answers:
1. This is the expected restriction. If a page is expected to be loaded for more than 100 s, we recommend that you avoid using the QoS criteria in tests.
2. What do you mean by "globally"? Do you mean the scenario or project level? IAC, if LoadComplete was configured to treat 302 responses as OK, it would fail to point out real mistakes in the log. Can you share a use case for such a setting?
3. I have registered your request in our DB as a suggestion.
4 and 5. Could you please give us a use case for excluding such requests from scenarios?
6. Do you think that renaming the button to "Finish and edit one more parameter" will be OK? Or, do you have some other vision?
7. I'm not sure how to reproduce the issue. Can you give me more details along with images that will demonstrate the steps to reproduce it?
8. To accomplish such tasks, we recommend recording these test "modules" as individual scenarios. After that, such scenarios can be executed as one complex scenario.
9. We do not have plans to implement built-in browsers in LoadComplete, because it will toughen up system requirements and reduce the amount of virtual users that can be simulated on one machine.
10. I have registered this request as another suggestion in our DB.
11. You're right - it depends on the browser. From LoadComplete's side, you can try deleting the requests, or mark 404 responses as OK in the Expected HTTP Responses table.
12. Does this problem persist on Beta 2? If it does, can you share the steps to reproduce it along with your test project? Please note that you can [url=http://smartbear.com/support/message/?prod=LoadComplete]submit[/rul] an individual support case.
13. Let's continue the discussion in the approriate thread.
14. Again, could you please share a use case?
15. Please make sure that getting SSL-related errors persists on LoadComplete 2.50 Beta 2 - some related issues have been fixed there.
Thank you for loads of feedback! Here are our answers:
1. This is the expected restriction. If a page is expected to be loaded for more than 100 s, we recommend that you avoid using the QoS criteria in tests.
2. What do you mean by "globally"? Do you mean the scenario or project level? IAC, if LoadComplete was configured to treat 302 responses as OK, it would fail to point out real mistakes in the log. Can you share a use case for such a setting?
3. I have registered your request in our DB as a suggestion.
4 and 5. Could you please give us a use case for excluding such requests from scenarios?
6. Do you think that renaming the button to "Finish and edit one more parameter" will be OK? Or, do you have some other vision?
7. I'm not sure how to reproduce the issue. Can you give me more details along with images that will demonstrate the steps to reproduce it?
8. To accomplish such tasks, we recommend recording these test "modules" as individual scenarios. After that, such scenarios can be executed as one complex scenario.
9. We do not have plans to implement built-in browsers in LoadComplete, because it will toughen up system requirements and reduce the amount of virtual users that can be simulated on one machine.
10. I have registered this request as another suggestion in our DB.
11. You're right - it depends on the browser. From LoadComplete's side, you can try deleting the requests, or mark 404 responses as OK in the Expected HTTP Responses table.
12. Does this problem persist on Beta 2? If it does, can you share the steps to reproduce it along with your test project? Please note that you can [url=http://smartbear.com/support/message/?prod=LoadComplete]submit[/rul] an individual support case.
13. Let's continue the discussion in the approriate thread.
14. Again, could you please share a use case?
15. Please make sure that getting SSL-related errors persists on LoadComplete 2.50 Beta 2 - some related issues have been fixed there.
Related Content
- 8 years ago
- 8 years ago
- 8 years ago
- 8 years ago
Recent Discussions
- 3 years ago
- 3 years ago
- 4 years ago