如何判定自己遇到的问题是否为Bug？

既然来了，那就说明您在使用活字格过程中遇到了些问题；


本帖旨在告知各位格友：
如何判定自己遇到的问题是否为Bug；
以及如何按照规范发好Bug帖；

最终目的是为了帮助大家充分的利用好这条反馈通道，
以达到资源的合理配置，从而更高效的服务好各位格友。

相信大家在下决心准备发Bug帖前，是有过辛酸历程的：
首先，在使用中肯定是遇到了问题，
然后，经过一番努力尝试后问题仍未解决，
最终，在万般无奈下才走上了这条不归路。


1、那么当我们开始怀疑这是个bug后，该如何去准确判定确实是bug呢？

下面我将举几个具体到有些片面的例子，虽然不能涉及到方方面面，
但相信大家总归是能get到其中的含义，毕竟咱都是做系统的高智商人群嘛。

• 如果某一功能在老版本是好的，升级到新版本后，功能异常；
• 运行工程，触发某一功能后出现崩溃信息提醒框；
• 工程中的设置保存后，关闭工程后再打开工程，设置丢失；     
• 。。。。。。（等等）
  

如果遇见以上列举到的情况，以及类似情境，
那么您就完全可以挺胸抬头、自信昂扬的发Bug帖反馈问题了；



2.如果您内心打鼓，悬而不定，万分纠结这到底是不是个Bug？

那么您可以先以问题的形式在求助中心发帖，
我们会对求助中心帖子中的问题进行判别，
如果确定为Bug，
后续我们也会将该帖进行特殊标识（比如将帖子处理状态置为【保留处理】），
或者直接将帖子移入Bug反馈板块，


3.这时，也许会有格友疑虑：发在求助中心的bug帖会不会被遗漏处理呀？

这点您大可不必过度担心，
我们会对论坛中的所以板块的所有帖子，
保证在工作日的工作时间（9:00--17:30）内，当天问题进行当天回复，
我们的技术顾问会在论坛时刻巡帖，确保问题不被遗漏。


4、为何发帖需要您详细描述复现步骤并提供问题demo，重现Bug后才能修复？

曾经有不少格友在与我们交流时，发出过这样的疑惑：
“我就发个帖子，为啥还要我啰啰嗦嗦描述一大堆，还要我费劲自己做demo去复现，这样好麻烦啊！”
提出这样疑问的格友，也许是认为我们具备嗅探超能力，一不小心您的想法就被我们读取到了。
但骨感的现实是，你我皆是凡人。

我们非常能够理解您想尽快处理掉问题的焦急心情，
但问题再紧急，我们也需要先了解清楚您的问题背景，有了问题上下文我们才能准确理解您的痛点，

换句话说，我们越早理解清楚您的问题场景，那么您的问题处理速度也就越快，
这与“要想富，先修路”是一个道理。


那么如何能准确的了解您的问题场景，最好的形式就是：
详细的问题场景描述+问题复现demo，


当我们开发出一个功能后，
会经过：自动测试-->单元测试-->手动测试等多道工序，
来确保上市的功能趋于完美，

所以，到您手中后，如果仍然存在bug，
那么这就算是“九年义务教育的漏网之鱼”，
如果没有您特定的复现步骤，我们确实不太容易复现，


如果您只提供了问题描述，确没有复现demo，
退10000步讲，我们很幸运的也重现了您反馈的bug，
即使是这样，我们也不能保证修复后的效果就是您想要的，


举个例子：

张三（格友）有天摔倒了，说是路有问题，向有关部门反映，希望尽快将路修好，

李四（活字格）接到通知来修路，首先要对道路进行勘测，看到底是哪里的路有问题，

由于张三（格友）没有具体描述是如何摔倒的，
李四（活字格）为了解决问题，只能亲身人肉测试，

一番测试张三（格友）终于被路上的一个坑给闪倒了，
于是李四（活字格）兴高采烈的将坑补好，并拍着胸脯跟张三（格友）保证路修好了；
结果张三（格友）第二天又在原处摔倒了，并大骂李四（活字格）是个骗子，
原来，张三（格友）摔倒的原因是被路上的一块石头给绊倒的。

相信读过这个摔跟头的寓言故事后，各位格友也就明白了重现Bug的必要性，

而要想准确有效的重现Bug，就需要详细的问题场景描述+问题复现demo，
这其实是个环环相扣的过程。

如果您提的Bug，我们确认后，会及时告知您，
后期如果Bug修复，也会在帖子中跟帖告知您。


从我们的角度出发，您的Bug复现场景对我们来说弥足珍贵，
因为只有这样才能让产品更加完善、健壮；
从您的角度来讲，您的复现越清晰准确，Bug解决处理起来的速度也就会越快；
这是一个双赢的事情。


说一千道一万，我们的初心都是为了能更好的服务大家，让活字格越来越好；
最后，十分感谢大家对活字格的支持，以及对我们工作的理解。