本文探讨了测试人员在发现应用程序问题时理解日志的重要性。即使测试人员不负责修复问题，掌握日志阅读技巧也能帮助他们更准确地定位问题所在，减少与开发人员之间的沟通成本。
在项目中，我们常常会看到有这么一个现象。当测试人员发现了应用程序的问题，就会把开发人员叫过来。
开发人员就会说“你的日志放在哪里了？”拿到日志以后就看有什么错误日志，从而判断问题所在。
在这个情况下，人们就会感觉到，一旦发现了问题，下一步就是开发人员去定位并修正问题。跟测试人员基本没有什么关系了。
那么，测试人员既然不修正问题，还需不要要能看懂日志，需不需要知道问题处在应用程序实现（implementation）上的哪个地方呢？
我个人认为，还是需要的。如果这个日志包含的是有意义的信息的话。
通常好的日志会告诉你有error, error的内容是什么。测试人员不需要知道具体哪行代码出了问题，但是要知道大概哪一块。 比如说以下是一个客户服务系统的日志：
ERROR .System.ServiceModel.EndpointNotFoundException: The connection attempt lasted for a time span of 00:00:00.9375060. TCP error code 10061: No connection could be made because the target machine actively refused it 10.18.3.1:9000. ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 10.18.3.1:9000
在客户端给出的错误是无法连接服务端。但是通过这个日志，我们就可以尝试去telnet一下，是不是端口打开了，这个定位就比较容易。假设不看这个日志，估计还得好一会才能意识到时这个问题。毕竟连不上服务器的可能性很多啊，是不是网络在物理上没有接好，是不是客户服务版本出了不匹配还是服务端没有启动。这些都不好说。而且要是抓瞎了，估计又要把dev叫过来。都是看日志，如果都能看懂，就省事儿多了。
开发人员就会说“你的日志放在哪里了？”拿到日志以后就看有什么错误日志，从而判断问题所在。
在这个情况下，人们就会感觉到，一旦发现了问题，下一步就是开发人员去定位并修正问题。跟测试人员基本没有什么关系了。
那么，测试人员既然不修正问题，还需不要要能看懂日志，需不需要知道问题处在应用程序实现（implementation）上的哪个地方呢？
我个人认为，还是需要的。如果这个日志包含的是有意义的信息的话。
通常好的日志会告诉你有error, error的内容是什么。测试人员不需要知道具体哪行代码出了问题，但是要知道大概哪一块。 比如说以下是一个客户服务系统的日志：
ERROR .System.ServiceModel.EndpointNotFoundException: The connection attempt lasted for a time span of 00:00:00.9375060. TCP error code 10061: No connection could be made because the target machine actively refused it 10.18.3.1:9000. ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 10.18.3.1:9000
在客户端给出的错误是无法连接服务端。但是通过这个日志，我们就可以尝试去telnet一下，是不是端口打开了，这个定位就比较容易。假设不看这个日志，估计还得好一会才能意识到时这个问题。毕竟连不上服务器的可能性很多啊，是不是网络在物理上没有接好，是不是客户服务版本出了不匹配还是服务端没有启动。这些都不好说。而且要是抓瞎了，估计又要把dev叫过来。都是看日志，如果都能看懂，就省事儿多了。
扫一扫
4854
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
