/********************2016年5月4日 更新********************************/
知乎：如何专业地进行黑盒测试？
之前遇到过有些黑盒测试人员，感觉他们测试发现问题后，不分轻重缓急，也不知道分析。比如，发现产品与设计图在某个按钮上颜色有出入就提 Bug，有些问题明显是同一个问题引起的，不去发现根本原因，却一直提表面现象。也有黑盒测试人员跟我说过，测试人员发现任何问题都会判定是 Bug。请问：
1. 专业的黑盒测试是如何将发现的问题归类的？Bug、Feature、Enhancement 等。或者说有这些分类吗，还是只是分一下紧急程度和重要程度？
2. 描述中这个黑盒测试人员的观点是普遍思想吗？怎么形成的？
紫姑娘：
1.对问题的分类好像没有特别的界限。我做的就是黑盒测试。bug的分类有很多，有一些比较容易判断是哪个类别的还好，但是大部分都不知道如何让划分。我在公司划分bug类别的时候就是这样，很疑惑，因为都不知道界限在哪里。一般都只是评判一下bug的严重等级
2.描述中这个黑盒测试人员的观点是普遍思想吗？怎么形成的？
首先是很多公司虽说有测试部门，但是对此并不怎么重视。拿我目前所在公司来说，测试的地位很低。每次我们测试的时间都很少，一个是研发部门不喜欢我们长时间的测试，其次是我们测试部门自己也不希望测试人员测试时间长，长时间测试就会觉得你在偷懒。
其次，测试时间短，但是要求尽可能多的找出bug。所以每遇到一个bug的时候就赶紧提交进行下一项测试继续找bug。
最后，有时候找出来了bug的一些规律或者说原因，能重现的是最好的，大多数bug都是不稳定的，重现难度大。重现难度大的时候，只是说比较耗时间，研发人员就会觉得你总结了这个原因导致他们往那方面探索结果没有找到原因，浪费了他们的时间，就会要求说不要测试人员找bug的原因，提交bug表述清楚就行了。但是有时候研发人员对有的问题又难以解决的时候，又觉得测试人员应该找到bug的原因。所以很无奈的
/***************************************************************/
根据是否知道源代码分为:
黑盒测试（不知道源代码）只关心程序的过程和结果，白盒测试（知道）根据源代码写测试用例
根据测试的粒度：
方法测试（function test）,单元测试（unit test）,集成测试（intergration test）
根据测试的次数：
冒烟测试（smoke test）,压力测试（pressure test）
谷歌工程师在android系统里面引入了一个猴子（monkey）,cmd进入adb的android shell界面，adb shell
monkey 1000 猴子对手机乱点1000次
monkey -p 包名 1000 猴子对该程序点1000次