通常情况下 Bug 分为四个类型，分别是功能、性能、安全和专项质量。功能级别关注于业务流程是否正确。性能级别关注于业务流程是否顺畅。安全方面判断是否存在漏洞，是否符合安全标准与规范。专项质量通常关注于用户体验 UX、兼容性、稳定性和可靠性。
为什么需要掌握bug定位
软件测试人员的首要任务就是发现 Bug ，发现之后提交 Bug 给开发人员进行修复。掌握 Bug 定位可以在提交 Bug 时追加更多有用信息，方便研发更快解决问题。通过分析 Bug 的形成原因，更有效率的进行溯源并建立特征进行批量追踪。
bug表现层
- 条件：测试数据；
- 过程：测试步骤；
- 结果：测试结果。
技术架构层次
软件从技术架构层次分析一般分为三层，即视图层 View、控制层 Controller 和模型层 Model。而 web 和 app 在具体的层次关注的技术方向也是不同的，具体如下：
- 视图层 View：
- web：UI HTML CSS；
- app：activity view；
- 控制层 Controller
- web：chrome、devtool；
- app：dalvik art objectc-runtime；
- 模型层 Model：
- 模型的传递方式：http tcp rpc 串口；
- 模型的形式：json xml binary；
- 模型定义：schema。
MVC三层分析法
Bug 的定位往往也会依照软件技术架构层次采用 MVC 三层分析方法，分析 View 层、Controller 层和 Model 层的运行平台、应用调试机制和链路。
View 层常见的问题是 UI（User Interface）用户界面和 UE（User Experience）用户体验。目前常采用人工测试和自动化测试，通过人工校验为主自动化校验为辅的方式检验界面交互的准确性以及用户体验感受。此外利用 UI 的 Diff 对比分析界面变化，定位更深层次的问题。
Controller 层通过平台自主提供的日志（log）以及应用程序本身提供的应用调试日志（debug trace hook profile）分析代码层次的逻辑问题。
Model 层根据运行平台的 log、app 调试机制以及链路来具体分析问题。
web bug 分析方法
界面展示主要依赖于 html、css、js，可以使用 chrome 开发者工具的 elements 和 style 两个板块来分析，elenments 可以展示具体控件，控件格式通过 style 来确定，由此来判断是否是样式、布局或输出方面的问题。
界面展示是 javascript 根据操作流程对代码进行修改的结果，底层逻辑的错误在 console 板块会展示出详细的出错信息。而 source 模块可以对错误进行定位通过 debug 分析问题的上下文，找到代码问题的根源所在。
基于运行平台的 log，例如 chrome 的 network 模块分析请求方式和数据的具体情况。链路分析使用代理工具 proxy，常用的有 fiddler、charles 和 mitmproxy 以及网络层的嗅探，常用的有 tcpdump 和 wireshark。
app bug 分析方法
app 的 UI 界面交互和 UX/UE 用户体验目前常用的是人工校验的方式，以自动化作为辅助工具以及 UI Diff 的方式分析，尝试发现界面中存在的问题，其中人工测试能够发现未知特征的 bug，自动化测试可以断言常用功能是否正常，通过 UI Diff 可以发现界面结构细节的问题。
通过 logcat 分析 app runtime 日志。
根据平台本身提供的 log 或者运行平台的调试工具，利用应用的日志分析以及建立追踪模式分析链路的问题，通过代理抓包 charles、fiddler、mitmproxy 或者嗅探抓包，wireshark、tcpdump 的方式分析链路。
安卓提供的工具，对 app 交互发生的网络请求进行中间过程的分析。
当工具本身不可调试时，可以使用代理工具分析。
通过 tcpdump 抓包，导入 wireshark 进行分析。
性能 bug 分析方法
H5的性能问题通常对网页加载的过程进行分析，通过 w3c 定义的 performance api 对每个阶段发生的问题进行统计，需要各个浏览器支持对性能方面的分析。
分析应用运行时代码的具体时间。
总结
定位 Bug 首先要明确 Bug 问题的现象和复现步骤，通过分层分析关键过程的数据与问题特征，积累 Bug 特征与问题根源特征，丰富测试经验，提高 Bug 发现的能力。
