1、Smoke Test
Smoke Test被认为是最先由微软提出的概念,与微软一直提倡的每日构建(build)有密切联系。词语源自硬件行业,可以类比新电路板的基本功能检查(即新电路板焊好之后先进行通电检查,如果存在设计缺陷,电路板可能会因为短路而冒烟)。有的公司也称其为版本健康检查(Build Sanity Check)。
在软件行业,冒烟测试描述的是将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程,即用来确定更改后的代码会按照预期进行并且不会破坏整个版本的稳定性。冒烟测试可以经济有效地确定和修复软件缺陷。实施为:测试人员在正式测试之前先跑一下主流程,没问题了在进行其他测试工作。
(关于冒烟测试)就是开发人员在个人版本的软件上执行目前的冒烟测试项目,确定新的程序代码不出故障。
——《微软项目求生法则》第14章“构建过程”
冒烟测试的对象是每个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,执行者是版本的编译人员。不通过时需要重新编译,到成功为止。
准备
测试经理和项目经理等相关人员从测试用例库中选定重要的测试用例,标记为冒烟测试用例。或者单独编写。
1、主流程和主功能的确认
要求测试人员在测试开始前跟开发人员确认需求和重要的流程、功能,最好将功能点和流程以及预期结果和开发人员说明清楚。冒烟测试不要求测试结果像正式测试阶段那么准确,但是也需要列一个指标来衡量测试是否通过。)
2、预计时间
根据列出的功能点和开发人员代码质量的可信度,评估冒烟测试在不同环境下可能花费的最长和最短时间,列到测试计划中。
3、数据的准备
在测试前,透彻的了解主要功能对应表的存储结构,准备好需要的数据。冒烟测试开始后,不会因为这些工作浪费时间。
执行
测试人员严格按照前期的约定去校验主流程,全部校验完和开发人员报告情况,不能放过一个主要的测试功能点。
总结
通常测试组在执行完冒烟测试,会回复本次冒烟测试结果,接受本次版本或者拒绝本次版本。如果拒绝本次版本,需要附录失败的原因和详细缺陷的描述。
时间方面,冒烟测试如果延误,要分析这段时间会不会对正式测试的时间有影响,如果有较大的影响需要和开发人员及时沟通补救方法,比如提高开发人员修复BUG的效率,测试时间顺延等。
2、Ad hoc Test
在软件测试中除了根据测试样例和测试说明书进行测试外,还需要进行随机测试(Ad-hoc testing),主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段,是保证测试覆盖完整性的有效 方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外,对于软件更新和新增加的功 能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug,进行再次测试,可以结合回归测试 (Regression testing)一起进行。
理论上,每一个被测软件版本都需要执行随机测试,尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉,执行随机测试越容易。只有不断的积累测试经验,包括具体的测试执行和对缺陷跟踪记录的分析,不断总结,才能提高。