但是作为测试职员来说，只管你不能深入地去剖析问题，但是你能创造系统存在的问题，这点也是值得肯定的，以是连续加油
以是本日给大家分享的主题是："怎么快速定位bug，怎么编写测试用例"
定位问题的主要性
很多测试职员可能会说，我的职责便是找到bug，至于找缘故原由并修复，那是开拓的事情，关我什么事？
好，我的回答是，如果您只想做一个测试职员最基本最本分的事情，那么可以这么想。但是，如果您想要在测试乃至开拓的道路上长足发展，就要知其以是然。
那么，为什么定位问题如此主要？
1、可以明确一个问题是不是真的“bug”。很多时候，我们找到了问题的缘故原由，创造这根本不是bug。缘故原由明确，误报就会降落。比如我们团队的大梅同学，整年500个bug中没有一个无效的。
2、找到bug缘故原由后，可以明确地指给某个开拓，防止他们打太极推来推去，提高毛病的修复速率。
3、让开发职员能够佩服你，提升开拓对测试的信赖度。
4.自己在这个过程中能学到很多东西，有助于理解产品内部逻辑，对架构的理解，以及数据流是若何的走向。随着对业务架构逻辑的理解，反过来又会促进对问题的定位。
5.可以降落毛病率。这个可以说是最主要的。在bug系统中，我们会哀求开拓职员记录bug产生的缘故原由。只有我们自己对bug有一个较全面的认识，才会判别出开拓写的是不是真正的缘故原由，也才能有助于我们后续对bug进行剖析归类，根据bug剖析，有针对性地未雨绸缪，进而提升产品质量，降落毛病。
以是，定位问题很主要。
接下来我们就来磋商下有哪些定位问题的方法和技巧。
问题定位技巧
首先，定位问题有一个总的思路，而这个思路是和数据的走向同等的。大致是这样：
首先当系统涌现bug时，一定要将bug征象进行录制保留，保留征象是为了证明这个bug涌现过，如果bug是固定重现还好说，如果该bug无法重现，那么保存的截图都是你直接证据，要养成良好的保存现场的习气
提BUG这块，还是要表示出测试的专业性，标题简洁、问题环境标识清楚、问题详细描述清楚、系统缺点表象贴图、接口传参返参贴图、必要时贴做事器日志，总结来说不该少的bug标签一个不要少。
一. 小型产品，前后端一人统筹
一些小型程序，例如前后端都用node、php措辞开拓的，全体系统前后端是同一个开拓的时候，那么
二. 常规系统，多人开拓协同
前置：测试之前该测试职员对系统、业务、环境支配、开拓职员等较为熟习
在测试之前打开对应浏览器的F12直接开个新页签，或者利用抓包工具等，系统呈现出问题时，查看对应的要求、日志信息等我们才能去全面的定位是前端还是后端职员的问题，详细给大家先容以下几个常用方法
1. 剖析问题场景进行预判
先查看页面表象，根据问题表象判断问题可能涌现的缘故原由，进行缩小范围，并且准备好录制工具，录制问题
系统页面无法正常访问的提示5开头的找后端，4开头的先检讨要求地址或者对应的权限，进入系统页面正常打开，提示非常代码缺点的直接找后端
进入系统页面展示非常图片视频干系提示Flash等干系信息进行安装Flash如若还弗成找前端，界面UI展示兼容性缺点找前端
如若系统访问正常，进入操作页面，功能性报错信息，就进入下面环节，抓包查看对应要求体，看日志等
2. 关注要求体的状态码
4开头的状态码一样平常都是客户端（前端）的问题；例如常见的404确认下是否是要求的地址有错，403确认是否有权限访问，详细可百度
5开头的状态码一样平常都是做事端（后端）问题，例如常见的500，则表示是做事器内部缺点，503网络过载导致做事端延时，502做事器崩溃等，详细可百度
3.关注要求的入参与相应数据
通过访问报错的页面，加载缺点要求时我们通过F12进行剖析要求包，查看对应的入参以及相应数据
例如：要求入参缺点，那么该bug属于前真个缺点；入参标准可以根据前端页面的输入的内容或者选择的内容，进行核验，入参格式以及是否必填等可以对应接口文档去进行剖析或跟开拓确认
例如：要求未相应或者相应数据缺点，那么该bug就属于后真个缺点；一样平常是数据库查看报错，例如删了某个表查询报缺点空指针等
如果要求的入参或者相应数据都没问题，可以跟开拓反馈是不是浏览器解析的问题，可以换个浏览器测试
4. 查看日志
针对做事端类型的报错，我们可以进行登录日志平台或者做事器对应Log目录下查看打印出的日志
常用查看日志命令tail ,/error进行快速检索关键词接口名等干系内容
拿到对应的日志,将日志文件贴进bug单，指派给后端，提高专业性，测试职员也要养成看日志的习气，看着看着就懂了
5. 履历法则
在系统前端页面当遇见做事器配置干系报错的信息例如Nginx或者代码以及SQL干系的提示报错信息直接找后端处理，例如JAVA 、.PHP、SQL等非常报错
前端字符校验、格式校验、等，浏览器界面UI兼容性以及插件，或者APP、小程序类调用手机干系功能拍照、语音无法正常调用直接找前端
下面我们就来说说测试职员定位问题的N板斧。
1、让子弹飞一下子
碰到问题先别忙定位，首先请保存犯罪现场，并且确认能复现。然后打消QA的低级问题 。为什么要保存现场？如果往后复现不了，就证明不了问题的存在。有哪些QA的低级问题？常见的便是hosts不对，网络不通，以及操作姿势禁绝确等等。这个实在便是上文提到的用户层面问题，这里的用户便是QA职员。常常有QA职员创造问题后就赶紧叫开拓过来看，开拓这时候幽幽地说句“host对吗”，一看不对岂不是很尴尬。
还有一类问题便是脏数据，我们有时候会碰着做事端报500缺点，查看日志后，报空指针，那么很有可能便是数据库中关联表的数据被人为删掉导致的。还有的问题是由于工具的影响导致的，例如fiddler。以是创造问题您别慌，让子弹飞一会，确认不是自己的问题再说。
2、直不雅观查看页面表现
这个便是上文提到的对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时进行统一解释，也更加方便开拓职员批量处理，防止漏改。
初次怎么写用例
有很多朋友初次写用例，不知道从何下手，虽然有的公司给出了干系解释文档，但是写起来还是不能得心应手，编写用例方法有很多种：功能导向用例（边界值、等价类等等），用户导向用例（场景法），用户、功能相结合导向用例……
那么对付初次编写用例，该当若何高效率的编写用例？该当把稳点什么？
一、功能导向用例是按照系统须要达到的每一个功能，进行编写用例，这样的用例着重点在功能实现上，而没有考虑到每个功能之间的关联，因而虽然用例已经达到功能覆盖，却不一定达到逻辑覆盖，因而这种方法常日会和其他方法结合利用。功能导向用例是每个用例编写者前期最常用的方法。
二、用户导向用例是按照用户的习气，将用户利用系统的每个目的作为一个目标，以每个目标实现为基点设计测试用例，但是设计这一类用例，初写者，可能会产生很多困惑（下面写一下我第一次写的时候有哪些困惑，并针对这些困惑，后来采纳了若何的办理方案）
1、编写用例的第一步我该做什么？
理解系统，首先站在测试的角度深入理解系统的每个功能与系统业务逻辑，画出业务逻辑图（即：系统能做什么）。
其次站在用户的角度，列出用户利用系统的目的（即：用户利用这个别系，想干什么？）
2、若何确定用户目标？
不能确定用户目标，可能由2方面缘故原由造成:a>对系统不足熟习，b>不理解用户背景。对付第一点缘故原由，那是你自己的缘故原由，只有回过去头看文档了，对付第二点缘故原由，可以从‘系统能做什么’推算出‘用户可以做什么’然后再总结出‘用户可能想做什么’，当然这样做的条件是你对系统已非常熟习。
3.这个月我将做什么？
刚进入测试行业是若何总结的（利用测试管理工具进行总结）：
1）把测试管理工具中的毛病全部分类导出，总结一下哪些模块随意马虎产生哪些毛病，重点看一下自己没创造或没有考虑到的毛病。
2）如果说测试新人事情的第一层次是从实行用例开始，那么第二层次便是编写测试用例了。把测试管理工具中的用例详细看几遍，学习别人的用例编写方法和思想，空闲韶光可以自己试着编写，看自己编写的与别人编写的用例差距在哪，从而不断完善。主要解释；着重用例编写方法和思想的学习，而不要去世搬硬套。
3）进入一些测试论坛，把自己的困惑和履历和大家一起分享，在学习中，不断进步。
正所谓功夫在诗外，测试理论知识便是那么多，理论知识节制之后就要不断地参与到项目中来，一个一个项目的练习，磨炼自己的创造Bug的能力，就算随机测试，一个好的测试和一个坏的测试，他们创造问题的能力也是完备不同的。以上完备是个人的一点体悟，各位看官，看的时候也请多多指教。
希望本文对你有所帮助~~如果对软件测试、接口测试、自动化测试、口试履历互换感兴趣可以私聊我或关注"大众年夜众号“特斯汀软件测试”。免费领取最新软件测试大厂口试资料和Python自动化、接口、框架搭建学习资料！
技能大牛解惑答疑，同行一起互换。
