小概率的BUG要怎么查找，急！！！

[年轻的程序员小唐]

早上客户说在使用上位机软件对下位机写数据的时候会出现数据错误丢失的情况：对下位机信道写数据，总共十六个信道十六组数据，在无手动更改数据的情况下一直写，会有几台机器的数据不对，就是十六个信道里有一个信道的数据会跟写入的不一样，据说是在第二个第三个信道出现，300个出现十几个有这样的问题。
这样小概率出现而且不会中止程序的BUG我该怎么查找啊我都懵了，我已经测试了一百多次读写了还没遇到这个问题，求各位大神帮帮忙！！！

[极客诗人]

在通讯处打日志对比吧

[年轻的程序员小唐]

引用 7 楼 wanghui0380 的回复:

你先这样，你先问他。消息错误是这么样的错误，能带信道设计的下位机，我相信他的协议应该是有校验位的

所以你先问这个错误是，校验失败还是消息体错误。

正常情况我们对于这种东西，还是那套手段，双方对日志。 日志如果查不出错，或者各执一词（这种情况很常见，A说我发了，B说我就没收到，A说我发的是123，B就说我收的是345），对于这种我们说，既然说不清楚，那就找公证
用中间监控程序直接监控：

tcp的用Wireshark进行抓包监控

串口的用Bus Hound监控

有理没理用证据说话

是这样的，客户那边是说，第二三信道数据跟写入的不一样或者没有了，那我这个是1到16个信道写进去的，结果中间的某一个数据丢了我也很懵啊，而且这个BUG他也不会说是写频的时候失败了或者什么特殊情况中断了写或者异常导致这样的，这样程序被迫中止了，算是个可见的错误，我觉得还好找。
我用的是AccessPort来监控串口传输的数据，现在我好像也只能不断地读写等到问题出现了再去看串口传输的数据是不是有问题了

[nangongxiaobai]

在代码中加入查询机制，就是每次信道设置的命令发送完成后，读取返回值，通过返回值判断是否正确输入，然后弹出提示信息，方便定位，弹出提示后，查看对应的各个状态，找到根因。在下一版代码中，把提示信息换为重新发送设置命令，或者做reset动作后重新发送命令，从而保证完全设置正确。

[ManBOyyy]

我們都是這樣對上位機和下位機，給信號，或者下位機給了什麼信號，或者觸發了什麼，都會記錄日誌，如果有什麼問題，一查就明白了

[年轻的程序员小唐]

各位我又去测了一百次回来还是没有遇到客户所说的BUG，各位的意见都很有用有启发到我，虽然我短时间内没法做到加日志程序啥的功能。
我现在是在程序里加入了计数记录我读写频多少次，然后开着串口监控记录数据传输，然后就一边读写频一边对照数据
这方法很笨但是我暂时也没别的招了

[XBodhi.]

简单提几点 1.写代码要重逻辑，然后再优化 2.瀑布模式写逻辑，减少 条件分支 3.分段编写。每个方法不要超过2个功能。 4.合理用 TRY Catch 5.逐行调试。

[hustle0000]

找不到，仔细看看，理清逻辑

[@B! E]

三百分之十几，这几率很高了，可以作为常规问题处理。看你描述大概率是逻辑漏洞。这种数据流错误常规排查方法就是加检查点，按数据流向依次在每个处理单元加数据记录，然后在接收端加验证逻辑，检测到错误则记录该条数据编号，然后反查数据记录定位错误发生在哪个处理单元。然后继续分解该处理单元，加检查点记录数据，直到定位到问题点。运气好的话问题会发生在某固定单元，运气不好问题不是固定单元造成，而是与场景状态有关，那就要综合分析了。

[鱼听禅]

小概率bug复现，就增大事件频率。
写个循环，一直重复写数据，上位机进入发送的数据列表，同时通过监控软件检测下。下位机搞个串口将接收到的数据传出来保存。
到时候再对比数据分析。

[xiaoxiangqing]

最简单的办法，就是记录日志

[AQing阿清]

信道是什么东东？sp不是串口吗？

[赵4老师]

http://blog.csdn.net/zhao4zhong1/article/details/53078924 老司机找bug的十年心路历程

[kissgoodbye2012]

先排查硬件问题吧，比如电源电压是否在工作范围，是否稳定，然后有没有干扰源，最后才是软件问题。

[丁劲犇]

大量的日志是解决问题的好习惯！

[丁劲犇]

https://blog.csdn.net/goldenhawking/article/details/90245867 可以做个类似的日志装置

[amnoone]

据大神说，有种东西叫日志

[damao_94]

引用 1 楼 wanghui0380 的回复:

300 对十几个 这个概率不小了 这个概率不小，所以可以很快复现。双方记录日志，比对日志。 程序员的习惯是“不相信任何人，甚至不相信自己”--所以我们从不相信“客户说，下位机说”-----我们只相信机器说。所以双方拿出日志比对，当然物理通讯上有错也有，所以通讯协议才会有crc校验。不过300 对十几个这样的概率我不太相信是物理通讯错误

对头,总不能怀疑自己的代码吧

[年轻的程序员小唐]

引用 32 楼 走好每一步 的回复:

[quote=引用 楼主 weixin_44246797 的回复:]
早上客户说在使用上位机软件对下位机写数据的时候会出现数据错误丢失的情况：对下位机信道写数据，总共十六个信道十六组数据，在无手动更改数据的情况下一直写，会有几台机器的数据不对，就是十六个信道里有一个信道的数据会跟写入的不一样，据说是在第二个第三个信道出现，300个出现十几个有这样的问题。
这样小概率出现而且不会中止程序的BUG我该怎么查找啊我都懵了，我已经测试了一百多次读写了还没遇到这个问题，求各位大神帮帮忙！！！

代码问题，测试个100次读写没遇上问题不代表没问题。
有时间好好学下《windows核心编程》
[/quote]
谢谢推荐，正在努力的学习C#中，甚至想报个课程

[年轻的程序员小唐]

散装学习确实是遇到了才知道有这么个东西，既然知道了就要去好好学习一下，谢谢各位大佬们的帮忙

[走好每一步]

引用 楼主 weixin_44246797 的回复:

早上客户说在使用上位机软件对下位机写数据的时候会出现数据错误丢失的情况：对下位机信道写数据，总共十六个信道十六组数据，在无手动更改数据的情况下一直写，会有几台机器的数据不对，就是十六个信道里有一个信道的数据会跟写入的不一样，据说是在第二个第三个信道出现，300个出现十几个有这样的问题。 这样小概率出现而且不会中止程序的BUG我该怎么查找啊我都懵了，我已经测试了一百多次读写了还没遇到这个问题，求各位大神帮帮忙！！！

代码问题，测试个100次读写没遇上问题不代表没问题。 有时间好好学下《windows核心编程》