标签：bug

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的时候，你说，在哪里？一定是你访问的姿势不对，不信你试试

哈哈

这次neatpic重新修正了一些BUG，但代码还没有整理，因此暂时不放出下载，等代码整理好后再放出来。
目前测试地址为：http://neatstudio.com/neatpic/
修正：
1、支持中文文件名、目录名（怀疑所有的文件系统都是ansi方式读取而不是UTF8，不能确认）
2、文件名、路径隐藏（采用?file=imagexxxxxxxx）之类的方式，因为只显示缩略图，所以读上几十个缩略图的代价应该还是可以忍受的。

其他没有什么特别的更新，可能也会BUG被改出来，敬请测试

有几次遇到这个bug了。不过。说来也不算太大的BUG
重现：发表博客，选择附件。
OK，你发现附件选错了，然后删除，重选附件，并插入内容，这时候应该是 localfile=2 了。

这时候发表后，你会发现附件并没有被正确的在内容中替换。而是当成附件了。

让我们重试一下吧：
[localfile=2]

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

昨天说的是限制的BUG，今天说的是评论的BUG
好象sablog最近屡屡被人强暴？
论坛里也有N多人在感叹被攻击

目前有几种解决方法
1、关闭评论（模版里删除相应的代码，同时，在post.php的第211行把if($_POST['action'] == 'addcomment') { 改成其他的）

2、等待官方的解决方案

3、考虑换验证码程序？

4、禁止用户注册

5、如果实在受不了。。。换wp或者其他的吧

——————————————————————————————————————————

当然也有其他的，只是目前不想说。

一次误操作，发现了sablog的一个小BUG，或许这个BUG平时 很多人遇不到吧。

由于最近一些评论实在太多，我就加了IP限制，不过，我并没有加上*来做IP段的限制，我都是一个IP一个IP添加的。为了添加方便，我直接在最后的IP后面加了一个“,”，结果导致我自己也不能评论了。提示我，我的IP在屏蔽列表内。

看来这就是SA的一个小BUG了，没有把为空的数据过滤掉，

PHP的函数：array_filter，就可以了啦。HOHO

不过，平时确实感觉不出来。。。勉强算个BUG吧。

但我想还有一些垃圾评论的关键字，如果也用了这个，那。恐怕别人也回复或者评论不了了。。。

BTW：刚解禁，就发现后台有了几条来自同一IP的垃圾评论。唉。。。

(再BTW:好象最近SA被人攻破了？官方论坛上很多人在抱怨了。。。看来如果Sa不解决这个问题，就要被人BS了。。。如果一个月内不解决。恐怕我也会考虑换wp了)

原文来自：http://www.phpv.net/html/1653.html
作者是：扶凯

内容如下：
注意,经测试,本情况发生在少量配置有问题的服务器上.一般正式版apache无此问题.

一般的网站都会开放rar附件上传,并可能会保留原来文件名称,这从而可能导致一个很严重的问题,xxx.php.rar文件会被Apache当作php文件来执行, 造成极大的安全隐患 .

如何测试? 将你的某个php程序文件后缀名修改成 xxx.php.rar , 这时测试一下, 还是按照PHP文件解析执行,Apache并不会认为这是一个rar文件, 这是为什么呢?

原 来,每遇到一种后双重后缀名(如xxx.php.rar)的文件,Apache都会去conf/mime.types 文件中检查最后一个后缀, 如果最后一个后缀并没有在mime.types文件中定义, 则使用前一个后缀来解释 , 因为在默认情况下,rar并未在mime.types中定义, 故Apache会使用php后缀来解释文件, 这就是漏洞的原因所在.

由此类推,如果使用xxx.jsp.ppp.rar 则会认为是jsp文件, 如果修改成xxx.shtml.rar ,则会识别成shtml文件.

a.php.c.d.e.rar 也是会被当成PHP文件解释的!
想想,不知道有多少网站存在这个问题?

那么针对网络管理员,如何杜绝这个隐患 ?
1.修改mime.types文件,在最后面加一条:
application/rar rar
然后重新启动Apache,即可.

针对WEB管理员及WEB程序开发者,如何更安全?
1.只允许上传指定后缀名的文件,当然,要禁止掉rar格式文件上传.(但这条往往行不通,一般的网站都需要上传rar文件)
2.对上传后的文件进行强制重命名, 强制使用最后一个扩展名,如原始文件名为xxx.php.rar ,上传后强制重命名为 20080912.rar即可避免这个隐患.

早期版本的phpcms 2007, discuz, ecshop都存在这个漏洞, 或许你的网站被挂马,就是因此引起.

上面的文章是转的，我测试了一下,还真这样,不过修改mime.types是没有用的.

需要在http.conf中加入下面这些内容

AddType application/rar .rar
AddType application/x-compressed .rar
AddType application/x-rar .rar
AddType application/x-rar-compressed .rar
AddType application/x-rar-compressed; application/x-compressed .rar
AddType compressed/rar; application/x-rar-compressed .rar

这样就不会出问题了，测试过了，加我上面这些是没有问题的。

听闻有这样的漏洞，不管怎么样，都放上来，与大家一起分享一下，同时也请你自己检测一下自己的apache，如果你用的虚拟主机有这样的漏洞，那么也尽早通知他们一声，与人方便与己方便。
我自己没有测试过，所以不知道是否存在这个漏洞。

PHP版本一直在更新，同样我们的代码也会随着服务器上的PHP版本的更新而不得不进行更改，但每次PHP的更新，几乎只是显示fix了多少多少BUG，但究竟会在版本升级的时候带来哪些问题，自己一点也不清楚 。

其实翻开PHP的手册，你也能找到这些，现在方便了，到我的博客上下载乔楚编译的最新的手册，翻开左侧树的最后一个节点：Appendices，找到：

展开这三个节点，你会看到在版本更新的时候，PHP的核心加了哪些方法，去除了哪些函数（事实上这很重要，或许在你以前的项目里一直在采用XXX方法，但新版本去掉了，很可能你的程序就不能再运行了。。。）

当然你更应该看的是：Changes in reference handling，这里面介绍的是一些老的代码写法和应用在新的代码里会出错的例子，如果你的代码里沿用了这些旧的方法，那么，你先考虑一下升级的代价吧。

刚才打开google reader的时候，突然看到一篇文章，让俺大吃一惊呀。详细内容如下：

请谨慎注意这一微软SQLBug
刚来博客园，有什么不对，需要改进的地方，欢迎各位同道指出来，谢谢。
今天在使用数据库时出现意外操作,将一张表的数据删除了。仔细查看SQL语句，发现问题。将问题类推到Northwind中。我们使用两个表,Employees和Products
SQL语句如下:
select * from Products where CategoryID in (select CategoryID from Employees)
不看表结构是看不出什么问题的，不清楚的看一下表结构。执行上面的SQL语句,你将能看到所有的产品记录。
当你执行上面语句的"select CategoryID from Employees",将会提示一个错误提示:
消息 207，级别 16，状态 3，第 1 行
列名 'CategoryID' 无效。
表Employees中根本就没有CategoryID列,而微软忽略了括号中的错误,执行前面的语句。如果是应用在删除，更新，那后果将是不可现象的。我曾为此付出了代价。
这个应该就是微软SQL的BUG吧,我们需要特别注意。
在SQL2000企业管理器,SQL2000的查询分析器,SQL2005的Management Studio Express中均有此Bug。

然后有人回复为：

我在Sql2000上测试，确实有这个问题。

有意思的问题，在我的management studio里面查询，也会有这个问题，要好好地研究一下。

Microsoft SQL Server Management Studio 9.00.1399.00
有楼主说的问题！
确实应该注意一下。

看了表结构才知道，Employees 表里面没有 CategoryID字段。为什么不报错呢。错误被吃掉了。

select * from Products where CategoryID in (select CategoryID from Employees)

select * from Products where CategoryID in (select EmployeeID from Employees)

我比较了一下这两个语句的执行计划，不完全一样。建议lz分析一下执行计划。
因为我还不能完全看懂执行计划。只能看出来两个执行计划是不一样的。呵呵。

联想起以前写CRUD之类的东西时候，在过滤条件时，自动将空值直接unset掉，然后再拼成SQL，后来被BOBBY严厉批评了一下，确实，查询的时候感觉不出有什么问题，可如果是在UPDATE或者是DELETE的时候呢？本来是有条件的，可突然被unset掉成为没有条件了，那岂不是很恐怖？

借这个机会再次提醒自己，细心、周全、小心