冒烟测试应该有多复杂？
因此，我们已经在当前项目上进行了日常构建已有好几个月了。 不过，与日常构建一起进行的冒烟测试并不是很复杂 - 我们在主类库上运行了一些 nUnit 测试（诚然，它并没有提供很好的代码覆盖率），并且我们确保可以编译并构建。 所讨论的应用程序是一个 ASP.NET 站点，它使用一些业务对象（其中包括 LINQ-to-SQL）。
我们是否应该运行更复杂的冒烟测试，特别是在 ASP.NET 站点上？ 就此而言，我们如何为 ASP.NET 站点开发冒烟测试？
So we've been running a daily build on our current project for a lot of months at this point. The smoke tests that goes along with that daily build isn't very complex, though - we run a few nUnit tests on our main class library (which, admittedly, doesn't offer great code coverage), and we make sure that things compile and build. The application in question is an ASP.NET site which consumes some business objects (which include LINQ-to-SQL).
Are there more complex smoke tests that we should be running, particularly on the ASP.NET sites? How would we develop a smoke test for an ASP.NET site, for that matter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除了单元测试之外，最好将站点启动到带有一些示例数据的临时服务器。 尽可能接近现场直播。 然后使用 HTTP 流量生成脚本来模拟用户流量和会话。 您可以在后端监控调试日志记录、异常和其他测试代码。 您还可以在此处进行性能测量。
就像您自己在浏览器中玩它的更激烈的迭代版本一样。
您可以通过定义（或通过检查）您的公共资源及其投入来做到这一点。 然后，脚本可以尝试引起验证问题、站点流的奇怪排列以及在实时设置中测试站点的整个上下文的其他问题。
如果测试不完整……从单元测试到“它是否能很好地处理真实数据和流量”，那么您最终将像无头鸡一样到处乱跑，修复错误。
As well as unit testing, it can be good to launch the site to a staging server with some example data. As close to live-like as possible. Then use a HTTP traffic generating script to simulate user traffic and sessions. You can monitor debug logging, exceptions and other testing code on the back-end. You can also take performance measurements here.
Much like a more intense, iterative version of playing with it in the browser yourself.
You can do this by defining (or through inspection) your public resources and their inputs. The scripts can then try and cause validation problems, odd permutations of site flow and other things that test the entire context of the site in a live setting.
If testing is not complete ... from unit testing through to "does it play nice with real data and traffic" then you are ultimately going to be running around like a headless chicken fixing bugs later.
冒烟测试本质上应该是肤浅的：它能编译吗？ 部署？ 欢迎页面加载了吗？ 也许加载一个测试页面，该页面对数据库进行查询以查看该连接是否也有效。 就是这样。
Smoke tests, by nature, should be superficial: Does it compile? Deploy? Does the welcome page load? Maybe load a test page which does a query against the database to see that this connection works, too. That's it.
您不应该进行冒烟测试。 您知道该术语的词源吗？ 在电子学中，“烟雾测试”是指打开电源并查看是否有烟雾冒出。
你应该做更全面的单元测试； 足以为您提供良好的代码覆盖率。 这是您在每次构建时都应该执行的操作。 您还应该尝试进行部署，并运行一些“安装验证测试”。
You should not be doing smoke tests. Are you aware of the etymology of that term? A "smoke test", in electronics, is when you turn on the power and see if any smoke comes out.
You should be doing more comprehensive unit tests; enough to give you good code coverage. This is what you should do on every build. You should also try to do a deployment, and run some "installation verification tests".