大家都进来谈谈平时用的是什么测试工具来测试做完的ASP.NET网站(来者有分)
如题:
经常碰到网站是做好了,但不知道用什么工具来测试这个网站.
大家平时都用些什么软件来测试呢.网站的压力测试,网站的资源
释放情况(我就经常遇到数据库连接没关闭的情况.弄的连接数太多无法连上数据库).
网站安全测试啦..
呵呵..还有很多我都不知道...大家都来聊聊吧.
[解决办法]
vs2005的测试工具,不过不是特别好用
[解决办法]
vs2005可以进行web测试和压力测试.
[解决办法]
我觉得测试的问题是：手工做的太多了，官僚文档太多了，文档管理辅助工具太多了，而精当的自动化测试工具一个都没有，更没有人自己动手去开发（希望天上掉馅饼出现又好又便宜的工具）。
如果一个项目有500个测试用例，每天把它们完全（以随机顺序，并且由程序自动随机地生成崭新的输入数据）跑上100遍，即执行50000个不重复的测试，并不稀奇，因为大多数bug是在某段代码反复执行多次以后才发生的。
测试，就要以自动化测试为目标，手工测试为补充手段。
当我看到“可以实现100%的语句、条件、分支、路径覆盖”这样的宣传时，我的感觉很迟钝。实际上，如果手工发现过的问题全都可以被如上那样自动化回归，就是很棒、最高级的测试了。而那种“100%”宣传中的那些学究算法指标，我没有什么好感。大部分bug不是在数据覆盖时才出现了，而所谓语句覆盖等是费力不讨好。
其实在我的测试程序中，假设设计有1000个测试用例，我通常只记得其中几个的细节，980个以上都忘记了。但是每当我去吃饭、睡觉之前，我都会把它们执行，然后过会回来看结果。每当有BUG，首先要由问题的责任人来解决BUG，如果他不能迅速解决，大家都要停下手头工作来帮他解决。
很多人搞什么一堆“测试文档”？谁愿意更新、学习它们？他们像垃圾，可不像一般的设计文档那么吸引人。
如果仅仅为了尝鲜，做几个页面测试几个功能，然后念念不忘用这几个页面来证明达到了“web测试”目标了，我认为是噱头。那些发现不了什么问题的测试是不值得去欺骗自己的。如果做自动化测试，就应该这样，可以能用几百个测试页面来证明应用程的方方面面，此时才值得去把这种测试当作可以认真对待的东西。
[解决办法]
大部分bug不是在数据覆盖时才出现了，而所谓语句覆盖等是费力不讨好 --> 大部分bug都是在数据覆盖时才出现了，而所谓语句覆盖等是费力不讨好
[解决办法]
NUnit+ AspNunit插件.
[解决办法]
一般都用loadrunner
[解决办法]
对软件界面的分析和测试必须“从难点入手”，从软件的最经典画面入手，正像软件需求分析的入手点一样。如果挑几个最简单的交互，例如挑“登录界面”来证明你的测试“成功”了，这是噱头。
并且测试时需要充分估计出bug只有在哪些机制下才会出现，例如可能就有有经验的测试工程师估计出某个页面只有在某种交互流程、提交速度和数据下才能够测试出某种可能的bug。因此，这部分往往也离不开手工测试。
自动化测试应该尽可能发现更多的问题，因为只有自动化测试可以真正回归。没有几个自动化测试工具是可用的。
[解决办法]
那么多傻瓜啊，哈哈，我是其中一个~
[解决办法]
单元测试用nunite或者.net自带测试工具
页面功能用water或ruby测试, 都是开源免费的
[解决办法]
