浅谈冒烟测试与随机测试
软件测试的种类何其多也，每种测试都有其要达到的目的和实现手段。本文将介绍两种不太普遍的测试类型-冒烟测试与随机测试。冒烟测试
冒烟测试（smoke testing）,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。
冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
新版本的基本功能确认检查的测试，有的公司成为版本健康检查(Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查(Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查(Build Installing Check)。
随机测试
在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试(Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。
理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。
冒烟测试还靠谱~随机测试的话~没啥技术含量阿 另外随机测试后面说的好多都有问题啊~
比如"随机测试主要是对被测软件的一些重要功能进行复测"这句，谁敢对重要功能随机测的？还复测...都随机了啦怎么重复啊...而且你还让经验丰富的随机测...耍大刀呢？资源本来就紧~您还让老鸟玩随机~要我早辞职了... DBX，我不同意你的说法，随机测试确实有其存在的必要性。
我遇到过一个问题:测试手机时，在发送短信界面，点击拨号键，进入一个错误的界面。假如你按照规程或测试点去跑？你能保证能覆盖这样的情况？
每个测试员都有自身的极限，也就是自身测试的瓶颈。自己本身设计的测试点就不可能覆盖所有的故障。随机测试可以帮助你发现自己以前忽略的东西，完善自身测试点的设计。
不过我认为，在整个项目中，随机测试需要在版本稳定或故障具有减少趋势的版本中进行，毕竟功能测试才是整个系统稳定的主轴。 随机测试肯定有必要啊！ 非常受启发。
我接触到的测试项目，基本上在每个版本测试阶段都会进行随机测试。一是保证测试覆盖率，二是能够站在客户的角度，对软件产品进行检测。
页:
[1]
