Smoke Test And Ad hoc Test

Smoke Test(冒烟测试)

  1. 定义
    冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略,是对软件基本功能进行确认验证的手段,并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试,执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过,则不必做进一步的测试。进行冒烟测试之前需要确定冒烟测试的用例集,对用例集要求覆盖软件的基本功能。

    冒烟测试可以手动执行,也可以自动化执行。稳定的系统适合自动化冒烟测试,集成过程中的系统适合手工冒烟测试,因为冒烟测试内容在动态变化,变化中的自动化脚本维护工作量比较大。

  2. 分类
    冒烟测试的对象是每一个新编译的需要正式测试的软件版本。通过冒烟测试,在软件代码正式编译并交付测试之前,先尽量消除其表面的错误,减少后期测试的负担。冒烟测试的执行者是版本编译人员。因此可以说,冒烟测试是预测试。在实际的软件测试工作中,冒烟测试在软件研发的不同阶段有所不同。大体可以分为三类:
    (1)形成集成测试版本以前:验证各个单元能够成功执行,并保证测试版本能够顺利集成;
    (2)形成集成测试版本:以保证新的或者更改过的代码不破坏集成版本的完成性和稳定性;
    (3)后期预测试缺陷的修正:针对每个缺陷所做的缺陷修正都要先在干净的链接环境中进行冒烟测试,测试通过后才能更新相关软件版本。

  3. 意义
    冒烟测试,在软件生命周期中所占有的时间比例较低,同时具有注重通过性轻细节的特点,因此经常被开发、测试人员所忽视。事实上,冒烟测试是软件测试过程中一个不可或缺的节点,一个好的冒烟测试过程,对于软件测试效率的提升具有重要意义。
    (1)冒烟测试是对软件质量的总体检验。
    通过冒烟测试,能够快速确认软件是否具备测试准入条件,避免出现正式测试阶段全面开展后甚至到测试中后期才才发现阻塞型缺陷等严重影响测试进度浪费人力物力的情况。
    (2)冒烟测试是测试人员对测试流程的熟悉。
    通过冒烟测试,测试人员可以迅速熟悉测试总体流程,这一方面有助于测试人员准确制定测试时间计划,合理安排工作进度;另一方面也有助于测试人员提前做好相关设备、数据的准备,为正式测试的开展奠定基础。

  4. 冒烟测试执行是需要注意的事项

    冒烟测试执行,与正式测试的区别在于二者侧重点不同,冒烟测试关注的是阻塞型缺陷,包括但不限于流程不通、主要功能未实现等,而正式测试则属于全面、细致的测试,需要尽可能的发现全部缺陷并按其严重性进行区分。冒烟测试过程中,需要注意的是:
    1、开发协同
    冒烟测试阶段有几个特点,一是该阶段软件可能存在较多缺陷,特别是阻塞型缺陷,测试工作随时可能陷入停滞状态;二是该阶段测试人员对软件的流程、功能等熟悉程度较低,难免会出现找不到合适的测试方法甚至是找不到功能模块的情况从而延迟测试进度;三是该阶段的时间一般仅占整个软件生命周期的极小部分,这就需要开发人员实时响应,尽快解决各类问题。因此,在冒烟测试阶段,测试人员与开发人员的协同工作十分重要。
    2、注重效率
    冒烟测试应以效率为先,尽量缩短测试时间提高测试效率。要在关注主流程、重点功能的前提下,抓关键缺陷验数据准备,对于诸如页面不美观、用户体验不佳等缺陷可在冒烟阶段有选择的予以过滤。例如:测试系统登录,关注点应针对用户名、密码、校验码的输入及提交完成,对于非法字符的校验、登录框是否美观、错误提示是否准确等均属于次要关注点,不纳入冒烟测试范围。
    3、评估用例
    冒烟测试过程同时也是对测试用例进行评估的一个过程,要充分利用这一阶段,对前期形成的测试案例进行检验,及时对案例进行补充、删减和修订,使案例更贴合实际,更具有可执行。

Ad hoc Test(随机测试)

  1. 定义
    软件测试即为了发现程序中的错误而执行程序的过程。软件测试是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness)、完全度(completeness)和质量(quality)的软件过程;是SQA(softwarequalityassurance)的重要子域。软件测试主要工作内容是验证(verification)和确认(validation)。下面分别给出其概念:
    验证
    验证(verification)是保证软件正确地实现了一些特定功能的一系列活动,即保证软件做了你所期望的事情(Do it right)。确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程;程序正确性的形式证明,即采用形式理论证明程序符号设一计规约规定的过程;评市、审查、测试、检查、审计等各类活动,或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
    确认
    确认(validation)是一系列的活动和过程,目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do the right thing)静态确认,不在计算机上实际执行程序,通过人工或程序分析来证明软件的正确性;
    动态确认,通过执行程序做分析,测试程序的动态行为,以证实软件是否存在问题。
    软件测试的对象不仅仅是程序测试,软件测试应该包括整个软件开发期问各个阶段所产生的文档,如需求规格说明、概要设计文档、详细设计文档,当然软件测试的主要对象还是源程序。

  2. 随机测试的缺点
    (1)测试往往不太真实;
    (2)不能达到一定的覆盖率;
    (3)许多测试都是冗余的;
    (4)需要使用同样的随机数种子才能重建测试

  3. 基本原则
    (1)应把“尽早和不断地进行软件测试”作为软件开发者的座右铭,实践证明单元测试能够尽早发现问题,减少后期测试的错误量。可以采用Junit和Jtest来辅助进行单元测试。
    (2)测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。
    (3)应当避免由程序员检查自己的程序。(指后期系统测试阶段,不包括单元测试)
    (4)测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的,临界的,可能引起问题的输入条件。
    (5)充分注意测试中的群集现象。经验表明,测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。
    (6)严格执行测试计划,排除测试的随意性。测试计划应包括:所测软件的功能,输入和输出,测试内容,各项测试的进度安排,资源要求,测试资料,测试工具,测试用例的选择,测试的控制方法和过程,系统的配置方式,跟踪规则,调试规则,以及回归测试的规定等等以及评价标准。
    (7)应当对每一个测试结果做全面的检查。
    (8)妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值