archonwang在回复我的“也说软件测试中的80-20定律”一文时提到了这样一个问题：

    如何估算剩余的bug数量，曾尝试过用80－20法则进行估算，不过精确度似乎不高，应该怎样计算比较合理？

    以前好像看过这方面的资料，但实际工作中没有尝试过，有点纸上谈兵的意思了，呵呵。下面就胡乱说点吧，希望能有点帮助。

    我们通过测试发现软件中的bug实际上可以看成对软件中存在的所有bug进行采样的一个过程，不同人的人采样出来的bug可能有区别，但所针对的bug群体是相同的。

    单纯从一个测试人员来看，仅根据他的采样是无法去判断到底还剩余多少bug的，要想比较好的估算bug的总数或者剩余的bug数，只能借助于多个测试人员的采样了。这里实际上就是常见的鱼塘法。

    鱼塘法是用来估算鱼塘中鱼的数量的：从鱼塘中捞上来比如100条鱼，为每条鱼都作上标记，表明这些鱼是曾经被捕捉过的，然后把这些鱼放回鱼塘中去，过一段时间后（主要是想让被捕到的鱼尽量均匀的分布到鱼塘中去），再补100条上来，检查有多少条是标记的，比如是50条，那么就可以估算出鱼塘中的鱼的总数为100*100/50=200条了。

    这种思路也可以借鉴到bug的估算中来：让两个测试人员A和B同时独立对同一被测对象进行测试，自己使用自己的思路和方法。测试结束后，A发现了m个bug，而B发现了n个bug，两人相同的bug有k个，那么总的bug数就可以估算成m*n/k了。

    当然这种思路有其前提条件：
    1、采样要足够多，也就是说发现的bug数不能太少，要和总的bug数具有可比性，否则这种基于采样的思路就行不通了；
    2、测试人员的水平要比较接近，不能相差太大，不然很容易出现，一个人发现的bug是另一个人的子集，那就没意思了；
    3、针对的被测对象一定要完全相同，不能有bug修复的过程，否则两个人所针对的样本空间就不一样了，那样这种思路也就失效了。

    在实际工作中想对所有的测试都进行这种成对的测试是不可能的，因此很多大的公司主要还是采用收集历史数据获得经验参数的方式来进行估算的，比如经过相当长时间数据的收集和整理，可以得到bug数/KLOC，这样要估算剩余的bug就比较简单了。

    而对于一些没有什么历史数据收集整理的公司，这种鱼塘法就能派上用场了。选择部分代码作为被测试对象，选择两个还算有点经验的测试人员（主要是为了保证采样不会太差），独立对这些代码进行测试，最后能估算出这些代码对应的总的bug数出来，然后除以代码行数，就得到了bug数/KLOC了，那这个参数就可以用于其它代码bug数的估算了。

PS：不知道archonwang是如何用80-20法则来进行估算的，呵呵。

1，
问题：没有被验证的输入
测试方法：

数据类型（字符串，整型，实数，等）
允许的字符集

最小和最大的长度
是否允许空输入
参数是否是必须的
重复是否允许
数值范围
特定的值（枚举型）
特定的模式（正则表达式）

2，
问题：有问题的访问控制

测试方法：

主要用于需要验证用户身份以及权限的页面，复制该页面的url地址，关闭该页面以后，查看是否可以直接进入该复制好的地址
例：从一个页面链到另一个页面的间隙可以看到URL地址
直接输入该地址，可以看到自己没有权限的页面信息，

3      错误的认证和会话管理

例：对Grid、Label、Tree view类的输入框未作验证，输入的内容会按照html语法解析出来


4，缓冲区溢出

没有加密关键数据

例：view－source：http地址可以查看源代码

在页面输入密码，页面显示的是 *****,  右键，查看源文件就可以看见刚才输入的密码，

5，拒绝服务

分析：攻击者可以从一个主机产生足够多的流量来耗尽狠多应用程序，最终使程序陷入瘫痪。需要做负载均衡来对付。


6，不安全的配置管理

分析：Config中的链接字符串以及用户信息，邮件，数据存储信息都需要加以保护

程序员应该作的： 配置所有的安全机制，关掉所有不使用的服务，设置角色权限帐号，使用日志和警报。

分析：用户使用缓冲区溢出来破坏web应用程序的栈，通过发送特别编写的代码到web程序中，攻击者可以让web应用程序来执行任意代码。

7，注入式漏洞。
例：一个验证用户登陆的页面，  

如果使用的sql语句为：  

Select *  from  table A where  username＝’’ + username+’’ and pass word …..

Sql 输入  ‘ or 1＝1 ――  就可以不输入任何password进行攻击

或者是半角状态下的用户名与密码均为：‘or’‘=’
  

8，不恰当的异常处理  

分析：程序在抛出异常的时候给出了比较详细的内部错误信息，暴露了不应该显示的执行细节，网站存在潜在漏洞，



9，不安全的存储

分析：帐号列表：系统不应该允许用户浏览到网站所有的帐号，如果必须要一个用户列表，推荐使用某种形式的假名（屏幕名）来指向实际的帐号。  

浏览器缓存：认证和会话数据不应该作为GET的一部分来发送，应该使用POST，

10        问题：跨站脚本（XSS）

分析：攻击者使用跨站脚本来发送恶意代码给没有发觉的用户，窃取他机器上的任意资料

测试方法：

•         HTML标签：<…>…</…>

•         转义字符：&(&)；<(<)；>(>)； (空格) ；

•         脚本语言：

      <script. language=‘javascript’>

       …Alert(‘’)

       </script>

•         特殊字符：‘  ’ <  >  /

•         最小和最大的长度

•         是否允许空输入