如何快速定位bug和编写测试用例？ -全讯平台

02.问题定位技巧

首先，定位问题有一个总的思路，而这个思路是和数据的走向一致的。大致是这样：文章源自玩技e族-https://www.playezu.com/166419.html

首先当系统出现bug时，一定要将bug现象进行录制保留，保留现象是为了证明这个bug出现过，如果bug是固定重现还好说，如果该bug无法重现，那么保存的截图都是你直接证据，要养成良好的保存现场的习惯

提bug这块，还是要体现出测试的专业性，标题简洁、问题环境标识清楚、问题详细描述清楚、系统错误表象贴图、接口传参返参贴图、必要时贴服务器日志，总结来说不该少的bug标签一个不要少

一.小型产品，前后端一人统筹

一些小型程序，例如前后端都用node、php语言开发的，整个系统前后端是同一个开发的时候，那么小编可以自信的给你说，系统出现问题时，bug大胆的提，往猝死的提，责任人错不了！

二.常规系统，多人开发协同

前置：测试之前该测试人员对系统、业务、环境部署、开发人员等较为熟悉

在测试之前打开对应浏览器的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、小程序类调用手机相关功能拍照、语音无法正常调用直接找前端

有很多朋友初次写用例，不知道从何下手，虽然有的公司给出了相关说明文档，但是写起来还是不能得心应手，编写用例方法有很多种：功能导向用例（边界值、等价类等等），用户导向用例（场景法），用户、功能相结合导向用例……文章源自玩技e族-https://www.playezu.com/166419.html

那么对于初次编写用例，应该怎样高效率的编写用例？应该注意点什么？文章源自玩技e族-https://www.playezu.com/166419.html

一、功能导向用例是按照系统需要达到的每一个功能，进行编写用例，这样的用例着重点在功能实现上，而没有考虑到每个功能之间的关联，因而虽然用例已经达到功能覆盖，却不一定达到逻辑覆盖，因而这种方法通常会和其他方法结合使用。功能导向用例是每个用例编写者前期最常用的方法。文章源自玩技e族-https://www.playezu.com/166419.html

二、用户导向用例是按照用户的习惯，将用户使用系统的每个目的作为一个目标，以每个目标实现为基点设计测试用例，但是设计这一类用例，初写者，可能会产生很多困惑（下面写一下我第一次写的时候有哪些困惑，并针对这些困惑，后来采取了怎样的全讯足球网的解决方案）文章源自玩技e族-https://www.playezu.com/166419.html

1、编写用例的第一步我该做什么？

理解系统，首先站在测试的角度深入理解系统的每个功能与系统业务逻辑，画出业务逻辑图（即：系统能做什么）。文章源自玩技e族-https://www.playezu.com/166419.html

其次站在用户的角度，列出用户使用系统的目的（即：用户使用这个系统，想干什么？）文章源自玩技e族-https://www.playezu.com/166419.html

2、怎样确定用户目标？

不能确定用户目标，可能由2方面原因造成:a>对系统不够熟悉，b>不了解用户背景。对于第一点原因，那是你自己的原因，只有回过去头看文档了，对于第二点原因，可以从‘系统能做什么’推算出‘用户可以做什么’然后再总结出‘用户可能想做什么’，当然这样做的前提是你对系统已非常熟悉。文章源自玩技e族-https://www.playezu.com/166419.html

3.这个月我将做什么？

刚进入测试行业是怎样总结的（利用测试管理工具进行总结）：文章源自玩技e族-https://www.playezu.com/166419.html

1）把测试管理工具中的缺陷全部分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷。文章源自玩技e族-https://www.playezu.com/166419.html

2）如果说测试新人工作的第一层次是从执行用例开始，那么第二层次就是编写测试用例了。把测试管理工具中的用例详细看几遍，学习别人的用例编写方法和思想，空闲时间可以自己试着编写，看自己编写的与别人编写的用例差距在哪，从而不断完善。重要说明；着重用例编写方法和思想的学习，而不要死搬硬套。文章源自玩技e族-https://www.playezu.com/166419.html

3）进入一些测试论坛，把自己的困惑和经验和大家一起分享，在学习中，不断进步。文章源自玩技e族-https://www.playezu.com/166419.html

总结：

正所谓功夫在诗外，测试理论知识就是那么多，理论知识掌握之后就要不断的参与到项目中来，一个一个项目的练习，锻炼自己的发现bug的能力，就算随机测试，一个好的测试和一个坏的测试，他们发现问题的能力也是完全不同的。以上完全是个人的一点体悟，各位看官，看的时候也请多多指教。文章源自玩技e族-https://www.playezu.com/166419.html