易栈网-膘叔

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

以下内容来自于淘宝QA的博客，看到的时候自己也很惊讶，感悟于以前的同事，在发现BUG的时候是多么的冷静自若（非并QA，而是某些开发人员），就差再对比一下淘宝的QA，发现差距是多大。

企业越大，就越是会遇到一些问题，当企业还在扩张和发展的时候，部分会员对一些BUG还能够容忍，但是当企业发展到一定规模的时候，会员对于自身所应该拥有的权利就会提到台面上来了。毕竟我花了钱，当然应该享受一些权利，而并不是一直在尽义务。如何能更好的为用户服务才是以后互联网公司要走的路啊。

当然下面的内容我也不知道是否是事实，但我还是很感动。

内容如下：

不说啥了，直接上原文：
两篇文章的地址分别为：http://rdc.taobao.com/blog/qa/?p=857

http://rdc.taobao.com/blog/qa/?p=882

什么是xss漏洞

XSS又叫CSS英文缩写为Cross Site Script
中文意思为跨站脚本攻击
具体内容指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，
嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的.

xss的漏洞危害

• 获取用户cookie
• 修改页面信息
• 浏览器劫持
• 与其他漏洞结合（如：csrf漏洞）
• 其他

xss漏洞实例演示

• 略（在这里放貌似不太合适）

xss漏洞是如何产生的

以下Velocity模板VM中常见的代码

• <span>$!productName</span>
• <script>var from = ‘$!rundata.Parameters.getString(’from’)';</script>

对于第一种类型的代码我们可以输入变量为

<iframe src=http://hacker.com></iframe>

第一种类型的代码将变为

<span><iframe src=http://hacker.com></iframe></span>

对于第二种类型的代码我们可以输入变量为

‘;hackerFunction(document.cookie);’

第二种类型的代码将变为

<script>var from = ”;hackerFunction(document.cookie);”; </script>

以上两种类型的代码都轻易的被植入了恶意的脚本，也就是说产生了传说中的xss漏洞。

xss漏洞如何预防

1. 对于非富文本针对入参进行转义

可通过escapeHtml和JavaScript进行转义。

转义过后上面的代码将会变成

<span>&ltiframe&nbspsrc&equalshttp&colon&sol&solhacker&periodcom&gt&lt&soliframe&gt</span>

转义后用户输入的恶意脚本代码就不会被执行从而达到了预防和修复的目的。

2. 对于富文本入参进行过滤

略。

总结

本篇简要介绍了什么是xss漏洞，xss漏洞在代码中是如何产生的，简单介绍了如何去预防和修复xss漏洞。

黑盒手动测试

• 有输入框的页面测试

               对于非富文本在输入框中输入特殊字符 <”tiehua ‘> 提交

               在提交后的页面查看源代码根据关键字tiehua查找源代码中的tiehua前后的<”>’是否已经被转义成

               &lt&quot&gt&apos 如果未被转义说明这个输入框存在xss漏洞的嫌疑（提交bug）。

               对于富文本输入框输入<img onerror=”alert(123)” src=http://xxx.com>提交页面

               如果页面有出现排版问题或者js错误说明这个输入框存在xss漏洞的嫌疑（提交bug）。

• 页面链接参数的测试

             链接带参数的如：

             http://mall.taobao.com/?ad_id=&am_id=&cm_id=&pm_id=

            该链接包含了4个参数，对于这种的测试方法和输入框测试方法一样只不过把参数当成你的输入框进行

            提交。如：

            http://mall.taobao.com/?ad_id=<”tiehua’>&am_id=&cm_id=&pm_id=

           另：可能大家会说光这点不足以说服开发修改bug，很可惜本文旨在说明如何找到xss漏洞并不是说明

           如何利用xss漏洞，感兴趣的看情况线下交流呵呵。

黑盒工具测试

         推荐工具

• Paros(免费)
• Acunetix.Web.Vulnerability.Scanner (商业工具)     

白盒代码扫描测试

         在上一篇中我们讲到了xss漏洞产生的代码原因和解决方法如：

          <span>$!productName</span>

         此类的非富文本代码我们可以强制要求规范为：

         <span> $!stringEscapeUtil.escapeHtml ($!productName)</span>

         对于富文本的我们可以强制要求代码规范为通过过滤层过滤。

         根据以上的两条规则，我们可以从白盒代码上去进行静态扫描代码是否按照规范编写来预防和筛选xss漏洞。