软件测试之如何进行问题定位

最近收到多个用户反馈“打字发信息的时候会发一半出去还有一部分没有发出去”。看到这个用户反馈，小编开始着手复现问题，今天给大家分享一下复现问题过程。在本次问题定位主要使用以下的流程：文章源自玩技e族-https://www.playezu.com/23031.html

文章源自玩技e族-https://www.playezu.com/23031.html

确认问题现象，搜集用户反馈，分析用户环境，包括系统、机型、应用、操作等。通过和有问题的用户沟通，发现此问题95%的用户均在iOS13系统、微信中出现问题。文章源自玩技e族-https://www.playezu.com/23031.html

文章源自玩技e族-https://www.playezu.com/23031.html

 文章源自玩技e族-https://www.playezu.com/23031.html

1）  选择和用户环境相似的设备，iPhoneXS Max（13.3系统）文章源自玩技e族-https://www.playezu.com/23031.html

2）  选择和用户出现问题相同的应用，微信最新版本文章源自玩技e族-https://www.playezu.com/23031.html

3）  拿到用户出现问题的截屏和视频，同时与用户沟通对步骤进行确认，发现操作路径主要是上屏后点发送就出现了此问题。

4）  当知道用户出现问题的路径后就需要去确认影响因素，尽量能够稳定复现此问题，例如内存占用，CPU消耗，打字速度等。这里经过验证发现当打字速度过快时就出现了用户描述的情况。如下图：想发送“嘻嘻嘻嘻嘻嘻”，结果只发送出去“嘻嘻嘻”，输入框中还残留“嘻嘻嘻”。

复现问题后，开始定位问题原因，缩小问题范围。关于定位问题方法，可供参考如下：

1）梳理代码逻辑，增加log点，通过复现问题，寻找问题点；

2）二分法定位，把程序逻辑一点点注释掉，看看会不会出问题，类似二分查找的方法，逐步缩小问题的范围；

3）制作工具，针对某些bug编写一些调试辅助工具。比如，我们之前收到用户崩溃log，崩溃栈显示在退格的时候，但是人工不能复现，所以针对这个问题，我们开发一个工具，随机打字上屏候选后退格，退格次数随机，并将每次操作进行记录。通过这个工具复现了退格问题，通过记录的输入log，也找到了必现步骤。

这次，我们采用的主要是二分法去对问题进行精准定位，发现是两个线程交互时的问题，那此时就是对这两个线程段的代码进行log验证，经过验证我们最终发现问题是出“在上屏过内核”这个步骤。正常情况如下图1，出问题的情况为图2

由于内核处理和上屏为两个线程，因此在上屏时如果内核后处理完，则此时就会出现，用户发送只发了一半内容，另一半还在发送框内。

由于已经知道问题的根本原因了，因此就需要开发和测试同学一起去进行改动方案确定，这里由于我们代码中内核线程运行为顺序执行。因此改动只需要将发送添加到内核动作中即可。即下图所示：

上述问题是找到原因，并且已经修复了。这个事情就结束了吗？其实并没有，我们要思考下，线程的问题主要有哪些类型？主线程和内核线程之间可能还存在哪些问题？我们怎么能尽早发现这样的线程问题？

为什么要提出这些问题呢，其实思考这些问题目的是，我们要从“单一”问题解决转变到“一类”的问题解决，这样才能更好的预防类似问题重复出现。