Submitted by gouki on 2015, August 13, 5:16 PM
BUG提醒工具其实有很多，比如可以在有BUG的时候发封邮件到你的常用邮箱，这样你的手机上（邮件APP）就会收到一条提醒。或者有短信SP通道的话，你也可以有类似处理。当然还有monolog，支持php-console插件，可以发送到你的chrome上面，我在这里再换个小方式，利用pubu.im这个IM工具（或者说。。。。说不出来）来做提醒
流程很简单
1、去pubu.im测试一个帐户。。这不用我多说吧
2、下载MAC客户端登录，自己添加自己为一个机器人，相当于自己和自己聊天，如果你的消息不算隐私，你可以直接用现成的：小布 这个通道
3、在聊天界面选择插件，点击更多，打开网页，添加“incoming”插件，生成一个URL，选择你刚才聊天组
4、根据提示信息在你的APP里写上一段测试代码，POST方式的，可以用curl/file_get_contents/Requests/guzzle等，工具实在太多，不想多说
5、测试通过后，可以尝试自己用set_error_handle，自己处理出错信息，在出错信息前进行判断：
if(debug_mode){ //send report }
6、你会发现 右上角弹了一个小窗，就是你刚才的测试标题！
----EOF---
就这样，你在工作的时候不需要打开手机，电脑上会直接有提醒哦~~~而且因为是聊天记录，你还可以往前翻，到底是什么BUG，嗯，再也不用客户端开发人员和你说，XXX接口出错了。。。因为他一出错你就收到，然后你就可以在他没有和你提的时候悄悄的改掉，等他提出来有BUG的时候，你说，在哪里？一定是你访问的姿势不对，不信你试试
哈哈
Tags: bug
PHP | 评论:1
| 阅读:21527
Submitted by gouki on 2010, July 16, 9:12 PM
这次neatpic重新修正了一些BUG，但代码还没有整理，因此暂时不放出下载，等代码整理好后再放出来。
目前测试地址为：http://neatstudio.com/neatpic/
修正：
1、支持中文文件名、目录名（怀疑所有的文件系统都是ansi方式读取而不是UTF8，不能确认）
2、文件名、路径隐藏（采用?file=imagexxxxxxxx）之类的方式，因为只显示缩略图，所以读上几十个缩略图的代价应该还是可以忍受的。
其他没有什么特别的更新，可能也会BUG被改出来，敬请测试
Tags: neatpic, bug
PHP | 评论:7
| 阅读:24362
Submitted by gouki on 2010, June 15, 8:43 AM
说实话，我不知道这是BUG还是新功能。【最后鉴定是浏览器的一个小BUG，不是typecho的BUG，但对于附件，我还是提出了我个人想法】
在0.8版本中，如果你选择新建一篇文章，同时选择添加一个附件。然后提交表单新增文章，重新打开后，你会发现文章并没有附件。打开数据库，发现文件已经上传，而且ID还在文件ID前面，只是parent_id就是0了。
然后再选择新建一篇文章，这个没有归档的附件就显示在新文章的附件列表里。不管是是否选择插入，反正这个附件已是属于这篇 新文章了。
在此，我猜测这应该算是一个BUG，程序开发人员考虑到了附件上传的不可靠性，所以选择了先上传图片，但是其实对于博客来说，文章应该是更重要的。所以，完全是可以等文章写完再上图片。而不是直接就把图片插入数据库，然后在更新的时候无法插入（wordpress对于未归档的图片，都可以通过插入媒体来进行重插入，而typecho没有插入媒体这个选项，因此，图片就处于永远无法插入的情况了）。
当然，这只是纯理论研究（通过查看数据库ID的顺序得知），真相需要查看代码方可了解。
------鉴定----
说明：上述过程在Firefox下产生（开启flash block情况，将本地路径加入whitelist后一切恢复正常），IE下一切正常。搜狗浏览器选择高速模式无法登录（兼容模式方可登录，不过兼容模式就是IE核心，因此未做测试）
因此最终结论为：程序插入附件的流程操作一切正常，只是偶尔在一些插件启用时造成未知错误而已。出现我这种情况，应该是flash的关系，是它没有返回正确值，导致表单在提交时，调用$this->attach($cid)方法时没有获取到附件情况。而新建文章的时候，对于parent为0的附件，好象程序会强制插入新文章，这一点不敢芶同。
在file_upload.php中就是这样写的：
PHP代码
- if ($cid) {
- Typecho_Widget::widget('Widget_Contents_Attachment_Related', 'parentId=' . $cid)->to($attachment);
- } else {
- Typecho_Widget::widget('Widget_Contents_Attachment_Unattached')->to($attachment);
- }
我还是觉得这种事情应该交由用户处理，而不是在新建文章的时候被强制插入。这种情况如果出现在多人协作的时候就会让人受不了了吧？因为他在执行Unattached的execute方法时，where条件中并没有userid。所以A上传的图片，极有可能会被B强制使用。（虽然机率不大，但，难保会出现这种情况。）
Tags: typecho, bug, 文章, attachment
PHP | 评论:1
| 阅读:25269
Submitted by gouki on 2010, June 10, 11:53 AM
有几次遇到这个bug了。不过。说来也不算太大的BUG
重现：发表博客，选择附件。
OK，你发现附件选错了，然后删除，重选附件，并插入内容，这时候应该是 localfile=2 了。
这时候发表后，你会发现附件并没有被正确的在内容中替换。而是当成附件了。
让我们重试一下吧：
[localfile=2]
图片附件(缩略图):
Tags: sablog, bug, 上传附件
PHP | 评论:1
| 阅读:19106
Submitted by gouki on 2010, January 2, 9:12 PM
BUG管理给开发人员带来了方便，但，如果你描述的不合理，或者无法让开发人员重现BUG，那么，你其实是在给开发人员带来困惑。。。
一般情况下，我们使用bugzilla来记录BUG，有时候也用 mantis，毕竟这两个都算是开源软件了。bugzilla被使用的更多，因为有很多IDE，都有插件支持，但对于开发人员来说，更重要的是BUG产生的情况，所以淘宝的QA TEAM 这样谈BUG描述时，我觉得有必要记录一下，以后也可以让同事看看，HOHO，可以报BUG更精确一点：
清楚准确的描述BUG，这是测试人员的必备的基础。但是针对各种问题，我们又如何使自己提交的BUG让开发人员看一遍就明白呢？我相信大部分人都会碰到以 下这种情况，我们提交上去的BUG在某些特定的环境下存在，这时候如果没有写清楚具体产生BUG的前提条件的话，BUG难以重现，这个时候开发就会说： “为什么我测试的时候没有出现这个问题呀，人品问题。：）”。还有就是开发经常说：“为什么在我的机器上没有出现这个问题呀？”。“这个BUG是什么意 思”等等问题，出现以上一些问题还是追究其根源：
1． 测试与开发理解需求有偏差
2． BUG的出现是有概率性的
3． BUG受环境影响
4． BUG在一定条件下存在
5． BUG受数据影响，数据量达到一定量时才存在。
6． 测试人员提交的BUG，描述不清楚，让开发人员不明白其意
为了尽量避免以上问题的出现，我们测试就要尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象等。下面讲一讲BUG的描述规则：
1．摘要主要用于指明Bug发生的地点、在什么条件下发生什么现象。
2．描述字段：
1）描述Bug发生的地点、所用账号类型、操作步骤、期望值、实际值， 如果Bug与浏览器相关，需尽量描述更多的环境参数，如操作系统等。
2) 一个Bug不会包含多个问题，会尽量单一化，便于跟踪处理及统计
3) 对于很难描述清楚的Bug需截屏作为附件上传，并在描述中写明参照附件。
4）尽量减少重现的步骤以达到用最少的步骤来重现问题；
5）不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。
6）不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。
7）在BUG提交前，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤。
8）测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
9）如有必要可以把产生结果的SQL语句放上去，不过需要开发人员在短时间内定位问题，否则测试人员不能保证数据的完整性。
10）如果是概率性的BUG，尽量重现BUG，找到BUG产生的条件，如果找不出BUG产生的原因必须写明BUG发生的概率大约是多少。
11）BUG如果在特定条件下产生的，必须写明BUG产生的条件和操作步聚。
对了，本文来源：http://rdc.taobao.com/blog/qa/?p=5168，作者是pingyan
Tags: bug, qa
Misc | 评论:0
| 阅读:18522
