在生产代码/服务器上运行测试
我在单元测试/自动化测试方面相对缺乏经验，所以如果这个问题没有任何意义，请原谅。
我当前正在处理的代码库耦合如此紧密，以至于我需要重构大部分代码才能对其运行单元测试，所以我阅读了一些帖子并发现了 Selenium，我认为它确实是一个很酷的程序。
我的客户希望在我们的生产服务器上每十分钟运行一次特定的自动化测试，以确保我们的网站正常运行，并且某些功能/方面正常运行。
我从来没有真正考虑过对生产服务器运行测试，因为这会给站点增加额外的压力。 我一直认为您会针对临时服务器运行所有测试，如果这些测试有效，那么只要托管提供商没有遇到问题，您就可以假设生产站点正在运行。
您对在实际生产服务器上测试生产代码有什么想法吗？
非常感谢大家！
I'm relatively inexperienced when it comes to Unit Testing/Automated Testing, so pardon the question if it doesn't make any sense.
The current code base I'm working on is so tightly coupled that I'll need to refactor most of the code before ever being able to run unit tests on it, so I read some posts and discovered Selenium, which I think is a really cool program.
My client would like specific automated tests to run every ten minutes on our production server to ensure that our site is operational, and that certain features/aspects are running normally.
I've never really thought to run tests against a production server because you're adding additional stress to the site. I always thought you would run all tests against a staging server, and if those work, you can just assume the prouction site is operational as long as the hosting provider doesn't experience an issue.
Any thoughts on your end on testing production code on the actual production server?
Thanks a lot guys!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您将硒脚本视为“监视”而不是“测试”，也许会有帮助？ 我希望每个主要网站都进行某种形式的监控，即使只是定期 PING，或者经常加载主页。 虽然这种方式可能走得太远，但总体上不要害怕这个概念。 那么这种监控/测试会给您和您的客户带来哪些好处呢？
不知何故，并不是世界上所有最好的测试都可以预测用户会做的奇怪的事情，无论是有意的还是通过纯粹的数字力量（如果打字机上的 100 万只猴子可以写哈姆雷特，想象一下几百个点击快乐的用户可以做什么对站点执行 Ping 操作可以告诉您它是否已启动，但如果表已损坏并且报告现在失败，则无法告诉您，这一切都是因为用户输入了带有变音符号的值。
虽然您的站点可能在登台服务器上表现良好，但可能会开始降级 。如果您正在监控这些硒测试的性能，您可以领先于缓慢的投诉。 当然，正如您提到的，请确保您的监控也不会造成问题！ 您可能必须说服您的客户，某些测试适合每 X 分钟运行一次，而其他测试只应每天凌晨 3 点运行一次。
如果您最终对实时站点进行紧急更改，您会更加有信心知道测试正在运行以确保一切正常。
Maybe it would help if you thought of the selenium scripts as "monitoring" instead of "testing"? I would hope that every major web site out there has some kind of monitoring going on, even if it's just a periodic PING, or loading the homepage every so often. While it is possible to take this way too far, don't be afraid of the concept in general. So what might some of the benefits of this monitoring/testing to you and your client?
Somehow not all the best testing in the world can predict the odd things users will do, either intentionally or by sheer force of numbers (if 1 million monkeys on typewriters can write Hamlet, imagine what a few hundred click happy users can do? Pinging a site can tell you if it's up, but not if a table is corrupted and a report is now failing, all because a user typed in a value with a umlaut in it.
While your site might perform great on the staging servers, maybe it will start to degrade over time. If you are monitoring the performance of those selenium tests, you can stay ahead of slowness complaints. Of course as you mentioned, be sure your monitoring isn't causing problems either! You may have to convince your client that certain test are appropriate to run every X minutes, and others should only be run once a day, at 3am.
If you end up making an emergency change to the live site, you'll be more confident knowing that tests are running to make sure everything is ok.
我很长时间以来一直在类似的生产服务器上工作。 根据我的经验，我可以说，总是最好在阶段环境中测试我们的更改/补丁，然后将其部署在生产服务器中。 这是因为，除了数据量之外，登台环境和生产环境都是相似的。
如果确实需要，安装代码/补丁后，可以在生产服务器上运行一些测试。 但不建议/好方法始终在生产服务器上运行测试。
I have worked on similar production servers from long time. From my experience, i can say is that, Always it is better to test our change changes/patches in Stage environment and just deploy it, in production servers. This is because, both Staging and Production environments are alike, except the volume of data.
If really required, it would be ok, to run few tests on Production servers, once the code/patch is installed. But it is not recommended/good way to run the tests always on the production server.
我的建议是每晚将生产数据库影子到临时/测试环境，并每晚在那里运行单元测试。 客户建议的方法有助于确保引入系统的新数据不会导致系统内出现异常，但我不同意在生产中这样做。
在临时环境中运行它将使您能够在新数据流入系统时评估功能，而无需使用生产环境作为测试台。
[编辑] 为了确保站点正常运行，您可以编写一个简单的程序，每 10 分钟对其执行一次 ping 操作，而不是针对它运行整个测试套件。
My suggestion would be to shadow the production database down to a staging/test environment on a nightly basis and run your unit tests there nightly. The approach suggested by the client would be good for making sure that new data introduced into the system didn't cause exceptions within the system, but i do not agree with doing this in production.
Running it in a staging environment would give you the ability to evaluate features as new data flows into the system without using the production environment as a test bed.
[edit] to make sure the site is up, you could write a simple program which pings it every 10 minutes rather than running your whole test suite against it.
运行自动化测试所需的生产环境会发生什么变化？ 我了解您可能需要监控和警报以确保服务器正常运行。
What will change in production environment that you would need to run automated tests? I understand that you may need monitoring and alerts to make sure the servers are up and running.
无论选择什么，无论是监控还是测试类型的解决方案，您首先应该为客户做的事情就是警告他们。 正如您所提到的，在生产中进行测试几乎从来都不是一个好主意。 一旦他们意识到危险并且没有其他合乎逻辑的选择，就仔细构建非常简单的测试。 分层应用它们并严格监控它们，以确保它们不会对应用程序造成任何问题。
Whatever the choice, whether it be a monitoring or testing type solution, the thing that you should be doing first and foremost for your client is warning them. As you have alluded to, testing in production is almost never a good idea. Once they are aware of the dangers and if there are no other logical choices, carefully construct very minimal tests. Apply them in layers and monitor them religiously to make sure that they aren't causing any problems to the app.
我同意 Peter 的观点，这听起来更像是监控而不是测试。 我认为这是一个很小的区别，但很重要。 如果客户的要求与服务水平协议相关，那么他们的要求听起来并不太奇怪。
此外，如果服务提供商没有遇到任何问题，则认为网站正常运行可能并不安全。 如果网站被请求淹没怎么办？ 或者也许在测试中运行良好的 SQL 开始导致较大的生产数据库出现问题（超时、阻塞等）？
I agree with Peter that this sounds more like monitoring than testing. A small distinction but an important one I think. If the client's requirements relate to Service Level Agreements then their requests do not sound too outlandish.
Also, it may not be safe to assume that if the service provider is not experiencing any issues that the site is functioning properly. What if the site becomes swamped with requests? Or perhaps SQL that runs fine in test starts causing issues (timeouts, blocking etc.) with a larger production database?