如何通过“在我的机器上运行”来排除故障 场景
很多时候，当你向开发人员报告错误时，他回来说“它可以在我的系统上运行”，尽管它是一个浏览器应用程序。 你如何解决这个问题？
It happens lot of the time that when you report a bug to a developer, he comes back saying "it works on my system" though its a browser app. How do you go about sorting that out ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
从培训/流程的角度来看：
培训您的团队，让他们知道“在我的机器上运行”并不是一种可以逃脱牢狱之灾的回应。
拥有自动构建服务器。
进行自动化测试部署。
您的开发人员必须知道“有效”被定义为“在测试服务器上有效”，而不仅仅是他们的机器。
从测试/调试的角度来看：
需要向开发人员显示导致错误发生的操作顺序。
您可能想要捕获显示错误的屏幕截图，或者可能需要捕获视频（使用 Camtasia 等工具）。 人们可能非常不善于描述他们在系统上执行的导致错误出现的操作顺序，因此您可以捕获有关错误以及如何复制自身的信息越多越好。
从开发/环境的角度来看：
如果确实存在一个错误在一个环境中出现，但在开发人员的环境中没有出现，那么请查明它是否在没有开发环境中出现，或者仅在您的一个开发人员的环境中出现。
从那时起，就是尝试减少两个环境之间的差异，以便您的开发人员可以在他的计算机上看到问题。
或者您可以采取其他方式并尝试在生产（非开发）环境中调试问题。
这些的实现细节因平台而异。
From a training/process point of view:
Train your team to know that "works on my machine" is not a get-out-of-jail-free response.
Have an automated build server.
Have an automated test deployment.
Your developers must know that "works" is defined as "works on the test server", not just their machine.
From a testing/debugging point of view:
The developer needs to be shown the sequence of actions that result in the bug happening.
You might want to capture screenshots showing the bug, or possibly a video capture (using tools such as Camtasia). People can be quite bad at describing the sequence of actions that they performed on a system that led to a bug showing itself, so the more information you can capture about the bug and how to replicate itself the better.
From a development/environment point of view:
If there is genuinely a bug that exhibits itself on one environment but not the developer's then find out if it exhibits itself on no development environments, or just your one developer's.
From thereon in it is a case of trying to reduce the differences between the two environments so that your developer can see the issue on his machine.
Or you can go the other way and attempt to debug the issue on the production (non-development) environment.
Implementation details of these vary by platform.
您需要向开发人员提供尽可能多的信息。 即使是您认为不相关的内容。
我已经数不清有多少次遇到问题，也无法重复，后来却发现了一条用户最初没有包含的信息，但却是解开谜题的关键。
您还需要不接受这个答案，并说“好吧，您的设置和我的设置之间一定有所不同，我们可以做些什么来解决这个问题”。
You need to give as much information to the developer as possible. Even stuff that you don't think is relevant.
I can't count the number of times I've had a problem reported and couldn't repeat it, only to find out later a piece of information that the user hadn't originally included but was the key to unlocking the puzzle.
You also need to not accept that answer and say "well something must be different between your set up and mine, what can we do to sort it out".
我们通过在本地开发之上建立一个在设置、硬件等方面尽可能接近生产系统的开发环境来解决这个问题。因此，几乎所有在生产环境中发生的问题都可以在生产环境中重现。即使它们无法在本地开发人员计算机上复制，也可以使用该开发系统。
We deal with that problem by having a development environment on top of the local development that is as close to the productive system as possible in terms of setup, hardware, etc. As a result almost all problems that occur in the production environment are reproducible on that development system even if they can't be reproduced on local developer machines.
这是我在团队中遇到的常见逃避现实的反驳。 我的回答通常是：“你知道，你的系统不是生产服务器，而这才是它需要工作的地方”。 换句话说，这个借口根本不可接受。
我还向他们指出了可能性
： 本地系统和服务器之间存在配置差异。
b. 该功能的某些依赖项不会在服务器上更新。
C。 他们还没有清除浏览器缓存。
d. 我在临时服务器上复制了该问题并向他们演示。
e. ……等等，视具体情况而定。
This is a common escapist retort that I encounter from teams. My response usually is: "You know, your system isn't the production server and that's where it needs to work". In other words, that excuse simply isn't acceptable.
I also indicate to them the possibilities:
a. There is a configuration difference between the local system and the server.
b. Certain dependencies of the functionality are not updated on the server.
c. They haven't cleared their browser cache.
d. I replicate the problem on the Staging server and demonstrate it to them.
e. ... and so on, depending on the case.
尝试尽可能地重新创建发现错误系统的用户：从服务器配置到计算机配置，包括浏览器和操作系统等。 在发布之前，您可能应该有几种不同的设置来测试您的应用程序。
Try to recreate the user that found the bug's system as much as possible: From server config to machine config including browser and OS and such. You should probably have several different setups on which to test your app before releasing.
IE Tester 是进行此类故障排除的好工具。 如果您需要测试大量浏览器，那么像 Virtual PC 这样的虚拟机是您最好的选择，这样您就可以在测试服务器上设置许多客户端。
IE Tester is a good tool for this kind of troubleshooting. If you need to test lots of browsers then virtual machines like Virtual PC are your best bet so you can have many client set-ups on your test server.
啊，是的……书中最古老的借口。
假设开发人员和测试人员都在同一台服务器上进行测试，我将尝试通过识别开发人员计算机和测试人员计算机之间的差异来隔离错误。 可能是一些小问题，例如 Flash 版本、浏览器差异或忘记清除浏览器缓存，
我还建议使用自动化测试框架并在专用测试服务器上测试应用程序。
ahh yes... the oldest excuse in the book.
Assuming that both the developer and the tester is testing on the same server I would try to isolate the bug by identifying what the difference is between the developers machine and the testers machine. Could be a something minor like flash version, browser differences or forgetting to clear your browser cache
I would also recommend using an automated testing framework and test apps on a dedicated test server.
作为最终用户，你能做的不多，但作为开发人员，你可以通过在系统中包含大量日志记录来避免很多这些问题 - 用户会想到的差异只是你已经测试过的简单事情，但是良好的日志记录可以让您准确地看到系统发生故障时发生的情况。 我发现了很多不可能以这种方式发生的错误。
Not much you can do as an end user, but as a developer you can avoid a lot of these issues by including a lot of logging in the system - The differences the user will think of will just be the simple things you have tested already, but good logging lets you see exactly what was happening when the system failed. I've found quite a few bugs that couldn't possibly happen that way.