测试分析
一．定位bug的重要性：
1. 可以确认发现的问题是不是真的问题。很多时候，我们找到了问题的原因，也许发现这根本不是bug。原因明确，误报就会降低。
2. 找到bug产生原因后，可以明确地指个某个开发，提高缺陷的修复速度。
3. 降低缺陷率。会让我们自己对bug有一个较全面的认识，也有助于我们后续对bug进行分析归类，根据bug分析，有针对性地未雨绸缪，进而提升产品质量，降低缺陷。
二. 问题定位技巧：
用户层面问题 -> Web页面/软件界面 -> 中间件 -> 后端服务 -> 数据库
1. 用户层面问题：指的是用户自己的环境问题或者操作问题，比如环境不通，或者操作不正确。
2. 在Web页面进行正常操作时，也可能会发现问题。这类问题一般通过观察以及利用一些常识可以发现，比如样式问题。Web页面操作后，比如发出一个请求，可能会进入中间件这个层面。我这里说的中间件是广义上的，比如LVS、CDN、各种缓存服务器等等。
3. 服务会转发到我们真正的后端服务层，web服务器、应用服务器比如nginx、tomcat会收到请求。如果发现内存溢出，那么就可能会定位到是tomcat配置的问题；如果请求返回404，也可能是nginx配置不当。
4. 数据库层面的：可能少某个字段，或者字段值为空等等，这些可能在设计数据库时就埋下了错误的种子，导致程序调用数据库错误的数据产生bug，这一类问题不算普遍，但也是最容易忽视的一种情况，有时候从数据库入手定位bug说不定还能发现数据库的设计缺陷呢。
5.网络层面的：通常这种都是网络情况较差的时候产生的，比如手机的移动网络信号不好，又或是公司网络不稳定，导致js/css未加载完全或者请求超时等等，这种问题其实非程序bug造成的，可以不用提交bug，也不用让开发毫无头绪的去查代码的问题。当然如果可以的话也可以当优化建议提给开发，让他优化代码，比如压缩js/css，增加超时时间，超时后的重试机制。
三．关于测试人员定位问题：
1. 碰到问题先别忙定位，首先记录操作步骤，并且确认能复现。然后排除是，网络不通，以及操作姿势不正确等等。还有一类问题就是脏数据，我们有时候会遇到服务端报错误，查看日志后，报空指针，那么很有可能就是数据库中关联表的数据被人为删掉导致的。还有的问题是由于工具的影响导致的，所以发现问题别慌，确认不是自己的问题再说。
2. 4xx状态码一般表示是客户端问题（当然也有可能是服务器端配置问题），比如发生了401，那么要看下是否带了正确的身份验证信息；发生了403则要看下是否有权限访问；404则要看下对应的URL是否真实存在。而5xx一般表示服务端问题。比如发生了500错误，则表明是服务器内部错误，这个时候要配合服务器log进行定位；发生了502则可能是服务器挂了导致的；发生503可能是由于网络过载导致的；发生504则可能是程序执行时间过长导致超时。
3. 看服务器日志，如果发生5xx问题，或者检查后端接口执行的sql是否正确，我们最常见的排查方法就是去看服务器日志比如tomcat日志，开发人员一般会打出关键信息和报错信息，从而找到问题所在。测试人员要养成看日志的习惯。
4. 有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档（如果没有的话，就直接抛出这个问题）。如果和需求文档不符，那么就要看下谁改合理，是前端改，还是服务端改，或者两者都得改。这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档的bug，然后再去协调PM，敦促FE或者RD进行修改。
5. 当然，我们在发现问题或者定位到问题原因后，一定要进行一步，就是再次确认问题。所谓确认问题，就是弄清楚问题是否每次都发生，还是概率事件，或者是工具相关的问题（比如换个浏览器是否依然出现？如果换个浏览器不出现的话，很可能就是前端的兼容性问题）。比如翻页控件，我们待测的系统有很多页面都有翻页控件，那么就要看下是否每个页面都会出现这个问题，进而报bug时进行统一说明，也更加方便开发人员批量处理，防止漏改。