既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
这个就是上文提到的对Web页面的观察。不再赘述。
3.看状态码
4xx状态码一般表示是客户端问题（当然也有可能是服务器端配置问题），比如发生了401，那么要看下是否带了正确的身份验证信息；发生了403则要看下是否有权限访问；404则要看下对应的URL是否真实存在。
而5xx一般表示服务端问题。比如发生了500错误，则表明是服务器内部错误，这个时候要配合服务器log进行定位；发生了502则可能是服务器挂了导致的；发生503可能是由于网络过载导致的；发生504则可能是程序执行时间过长导致超时。
4.看服务器日志
如果发生5xx问题，或者检查后端接口执行的sql是否正确，我们最常见的排查方法就是去看服务器日志比如tomcat日志，开发人员一般会打出关键信息和报错信息，从而找到问题所在。
测试人员要养成看日志的习惯。并且，如果将来进行开发，也要养成打日志的习惯，否则发现问题真不知道到哪哭去。
5.接口的请求和返回以及js执行是否有报错
在第3点中我们说了状态码的问题，明确了4xx和5xx的问题所在。那么，如果接口返回了200，就一定正常吗？
假设有这么一种情况，要测试一个翻页控件，翻到第二页的时候，发现内容和第一页完全一样，接口请求返回的是200。这个时候你会怎么排查？
这个时候就要看前端发送的参数正不正常，后端返回的内容正不正常，即接口的请求和返回。
我们来看翻页控件的问题。我们看接口的请求（F12控制台查看网络请求或者抓包工具），一般根据开发的习惯，会有pn、ps参数，看看传值是否正确。如果请求参数不正确，那么就是前端的问题。
如果正确，那么就看response，看看返回的内容对不对，以此就知道到底是前端问题还是服务端问题。如果发现js执行报错了，那就是前端有问题，比如跨域问题。
请求URL不正确，是前端bug，传参不正确，是前端bug，响应内容不正确，则是后端bug。如果是响应内容不正确的后端问题，那就要继续深挖，是接口吐数据的时候出错了，还是数据库中的数据就错了，还是缓存中的数据错了（如果用到了缓存的话）。
经常见到后端开发人员有的负责接口，有的负责写入数据库，有的负责维护缓存，所以如果发现是后端的问题，可以更进一步确认下是哪块的问题。
6.看需求文档
有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档（如果没有的话，就直接抛出这个问题）。
如果和需求文档不符，那么就要看下谁改合理，是前端改，还是服务端改，或者两者都得改。
这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档的bug，然后再去协调PM，敦促FE或者RD进行修改。
在这点上，不得不说，有的开发做的比较好，他会有自己的思想，在开发的时候就能发现需求文档的错误，而有的开发则是无条件无脑执行。
7.后端生成页面问题
后端生成页面，最常见的就是类似于jsp、php、python的某些前后端不分离的框架，这种比较特殊，常见于单人开发的项目，这种项目的问题排查和其他项目总的思路也一样，只不过前后端bug的修改可能都是同一个人而已。
8.开发提供可测性支持
有时候，涉及到多方面合作，不太好测试的情况下，需要开发提供可测性支持。
比如，要查看接口给另一个接口发的请求是否正确，可以让开发打印出完整的请求log。还有一些逻辑开关、修改页面数据条数等，都属于可测性支持的范畴。
9.配置的问题
很多时候，bug不是代码问题，而是tomcat配置、nginx配置、jdbc配置等的问题。在这个层面上，测试人员最好能够了解下它们的各项配置，在发现问题后可能就会想到这方面的问题。
10.经验法则
太阳底下没有新鲜事，有经验的人早就遇到过相同的问题。高手往往能够一眼看穿表面现象内部的问题，然后直奔主题，迅速报告或者解决，留下别人在风中凌乱……
11.其他
常见的可能还有构建的问题，比如代码本身都没错，但是合并代码到主干后出问题了，常见的就是代码存在冲突时手动解决的时候。
所以我之前有一段时间喜欢问开发在合并代码时有没有冲突，如果有冲突，那是什么地方有冲突，就得重点对待了。
另外，定位到问题后，还要考虑下具体情况，根据开发人员的心态来决定要不要告诉他具体原因。
有的开发不够open，会觉得你抢了他的饭碗。而对于open的开发，你们会因此配合的更加默契。
当然，我们在发现问题或者定位到问题原因后，一定要进行一步，就是再次确认问题。
所谓确认问题，就是弄清楚问题是否每次都发生，还是概率事件，或者是工具相关的问题（比如换个浏览器是否依然出现？
如果换个浏览器不出现的话，很可能就是前端的兼容性问题）。比如翻页控件，我们待测的系统有很多页面都有翻页控件，那么就要看下是否每个页面都会出现这个问题，进而报bug时进行统一说明，也更加方便开发人员批量处理，防止漏改。
以上是对问题的初步定位。对问题的进一步分析可能是更加体现测试人员素质的，比如你发现了一个问题，通过白盒测试看他的代码，发现某一个分支的判断条件写错了，并且把这些告诉了开发，那么他一定会给你一个大大的赞，然后说上一句，小伙子靠谱，和你合作很愉快！
NO3.案例
下面介绍几个常见的问题并逐一分析下。
1、点击页面的某个“修改”按钮，页面弹窗提示“unforbidden”，但需求文档中显示应该提示“没有权限”，如何定位？
这个问题要看弹窗中的错误信息是谁发出的。如果点击修改按钮，前端发出了一个接口请求，而该接口的response中有“unforbidden”，那么说明前端的提示是后端返回的，那么就需要后端去修改。
否则就是前端写的提示。所以，有时候不能想当然地认为前端弹窗提示文案一定是前端的问题。具体问题具体分析。
2.修改某个表单中文本框内的文字并提交，跳转到结果列表页后发现该文本内容显示不全，该如何排查？
这个问题的可能性有很多，我们可能需要这样排查：首先查看下表单提交时，前端发送的请求中该文本内容是否正确，如果正确就再去数据库中查看记录，然后去看后端响应内容是否正确，然后去看前端渲染是否正确，以此来判断是前后端交互的哪个环节出了问题。
四、总结
可以发现，上面两个案例都没有定论，都是得具体问题具体分析。我们只要掌握了分析方法和思路，就能够找出来到底是哪里出了问题。
前端页面所看到的所有元素以及所有数据，要么是前端返回，要么是后端返回，有问题了，就看是谁生成的返回，前端返回的就去找前端，后端返回的就去找后端，谁的孩子惹麻烦了就去找谁，前后端就靠http来通信，所以要多F12，多观察前后端接口交互。
这只是经验总结，并非标准。bug千差万别，有时候需要一个一个分析。多修炼内功：对业务系统的掌握，测试方法以及开发技术。建设自己的bug知识库，多思考、多积累、多总结。
最后，请谨记：对于无法确定的问题或者目前功力难以定位的问题，要交给开发，不要死磕，浪费时间。如果冒烟测试都不通过，就不要浪费时间定位了，直接打回。优先解决项目进度问题，其次才是测试深度。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！**
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
4821
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
