VSTS 2008 负载测试,有什么好处吗?
我已经花了几周时间尝试使用这个工具来生成一些网络测试和负载测试。但每天它都会抛出一个奇怪的问题,我在文档中找不到任何内容。
示例:
- 在上下文错误中找不到隐藏变量(_lastfocus)。
- 今天,突然间它拒绝运行一些 webtest,这些 webtest 是我的负载测试运行中测试组合的一部分(与另一个负载测试运行良好)。
企业级工具是不是只有昂贵的工具才好? (如 loadrunner、silkperformer 等)。
I have already spent couple of weeks trying to use this tool to generate some webtest and load test. But every day it throws a weird problem for which I do not find anything in document.
examples:
- Hidden variables (_lastfocus) not found in the context error.
- Today, all of sudden it is now refusing to run some of the webtest which are part of the test mix in my load test run (is working fine with another load test).
Are enterprise level, expensive tools are only good? (like loadrunner, silkperformer etc).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
太棒了。一旦您了解了 WebForms 在请求和响应之间传输“html”的可怕方式,我发现它很棒。
It is great. Once you get your head around the terrible way that WebForms shuttle "html" between request and response I have found it to be great.
Visual Studio 的 Web 和负载测试功能实际上是针对开发人员而不是测试人员。我们有一位微软专家的演示,当我询问时他证实了这一点。
对于某些用途来说,它是简单明了的(例如,如果您可以仅使用 URL 列表进行测试,或者如果您的网站恰好可以使用记录和播放方法进行测试),但是如果您有一个更复杂的 Web 应用程序:
那么您就进入了为了一个充满伤害的世界。
内置的提取和验证功能相当弱,并且对动态测试(即在运行时决定要做什么)的支持是基本的而不是丰富的。 对于您将遇到的很多事情,或者在测试中想要做的事情,根本没有开箱即用的支持。他们对选择修复的错误非常挑剔和吝啬,这也无济于事。即使错误非常明显,如果不是崩溃,报告它似乎也没有什么意义。
话虽这么说,如果您具有编程技能,并且对 http、html、javascript 以及您的 Web 应用程序使用的任何其他特定 Web 技术有深入的了解,您可以做一些非常酷的事情,因为测试框架具有超可扩展性和广泛开放性无论您能想到什么 C# 魔法。但有时候,你真的感觉自己正在完成别人在你已经付费的产品上的工作。
缺少“隐藏字段”的问题似乎是整个网络上最常见的问题,并且在许多情况下没有简单的解决方法。当您进行测试记录时,Visual Studio 会记录页面中存在的所有隐藏字段。好吧,当您运行结果测试时,有各种各样的原因导致这些隐藏字段之一可能不再出现在页面中。也许录音错过了 ajax 请求;也许该页面使用 javascript 执行某些操作(而 VS 不运行 javascript);页面内容可能会因不同的用户帐户、之前的操作、一天中的时间或您无法控制的其他因素而存在细微的变化。如果您的网站或应用程序非常静态,则更容易测试。但如果它非常动态,那么你可能会面临严峻的挑战。
总结一下我的经验:在利用了三个很棒的第三方库,然后编写了自己的由 95 个类和大约 2700 行代码(包括非常丰富和强大的提取和验证规则)组成的支持库之后,我已经涵盖了大部分内容我以前遇到过的主要困难
但我可怜那个可怜的孤独测试人员,他被给予 VS 并被告知“编写一些负载测试”。
Visual Studio's web and load testing features are really targeted at developers rather than testers. We had a demo from a Microsoft expert and he confirmed this when I asked.
For some uses it is easy and straightforward (e.g. if you can test with just a list of URLs, or if your web site happens to be testable with a record-and-playback method), but if you have a more complex web app with:
then you are in for a world of hurt.
The builtin extraction and validation capabilities are quite weak, and there is basic rather than rich support for dynamic tests (i.e. deciding at runtime what to do). There simply isn't support out-of-the-box for a lot of things you'll encounter, or want to do within your test. It also doesn't help that they are really picky and stingy with what bugs they choose to fix. Even if a bug is glaringly obvious, if it's not a crash there seems little point in reporting it.
All that being said, if you have programming skills and solid understanding of http, html, javascript and whatever other particular web technologies your web app uses, you can do some pretty cool things, because the testing framework is super-extensible and wide-open to whatever C# wizardry you can conceive. But sometimes it really feels like you're finishing someone else's job on a product you already paid for.
The problem with missing "hidden fields" appears to be the single most common problem all over the web, and in many cases there isn't a simple fix. When you do a test recording, Visual Studio records all the hidden fields that were present in the page. Well, when you run the resulting test, there are all kinds of reasons why one of those hidden fields might no longer be in the page. Maybe the recording missed an ajax request; maybe the page does something with javascript (whereas VS does not run javascript); maybe there are subtle variations in the page content based on a different user account, or previous actions, or the time of day or perhaps other factors outside your control. If your website or app is very static, it is more easily testable. But if it is very dynamic then you may face a stiff challenge.
To summarize my experience: after taking advantage of three great third-party libraries and then writing my own support library consisting of 95 classes and some 2700 lines of code (including very rich and powerful extraction and validation rules), I have covered most of the major difficulties that I have previously stumbled over
But I pity the poor lone tester who is given VS and told to "write some load tests".