软件定制网站建设,国外网站后台模板下载,网站设计制作简单实例,用win2008做网站Smoke test Ad hoc Test Smoke test 冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略#xff0c;是对软件基本功能进行确认验证的手段#xff0c;并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试#x… Smoke test Ad hoc Test Smoke test 冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略是对软件基本功能进行确认验证的手段并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过则不必做进一步的测试。进行冒烟测试之前需要确定冒烟测试的用例集对用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的门槛用例验证。 冒烟测试属于HLT(highleveltest)测试HLT通常指SDV(系统设计验证)/SIT(系统集成测试)/SVT(系统验证测试)等测试活动。HLT是站在系统的角度对整个版本进行测试测试对象是一个完整的产品而不是产品内部的模块常见的HLT测试包括系统测试和验收测试。 冒烟测试可以手动执行也可以自动化执行。稳定的系统适合自动化冒烟测试集成过程中的系统适合手工冒烟测试因为冒烟测试内容在动态变化变化中的自动化脚本维护工作量比较大。 [1] 冒烟测试smoke testing,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试就是开发人员在个人版本的软件上执行的冒烟测试项目确定新的程序代码不出故障。冒烟测试的名称可以理解为该种测试耗时短仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后先通电检查如果存在设计缺陷电路板可能会短路板子冒烟了。 Ad hoc Test在软件测试中除了根据测试用例和测试说明书进行功能测试外还需要进行随机测试(Ad-hoc testing)随机测试是没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行测试用例的重要补充手段是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug进行再次测试可以结合回归测试(Regressive testing)一起进行。
随机测试主要是对被测软件的一些重要功能进行复测也包括测试那些当前的测试用例没有覆盖到的部分。另外对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug进行再次测试可以结合回归测试(Regressive testing)一起进行。
理论上每一个被测软件版本都需要执行随机测试尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉执行随机测试越容易。只有不断的积累测试经验包括具体的测试执行和对缺陷跟踪记录的分析不断总结才能提高。
就拿PK网首页来说我们在测试所有链接是否正确的前提下这里的链接测试我们可以用Xenu Link Sleuth进行死链接检测随机挑选同类别的导航进行测试查看链接是否正确跳转。左侧导航是否能跳转到对应的频道。另外挑选几个置顶的新闻看图片是否取值正确。另外在视频栏可随机查看某一视频能否正常播放。
客户端随机测试思想
随机测试是根据测试者的经验随机的选取功能点对软件进行有针对性的测试。 这种测试没有用例的指导完全根据测试员自己的经验和相关知识来测试。
一、作随机测试之前的一些前提条件
1)熟悉产品的各项功能和产品的逻辑结果
2)熟悉测试用例
3)完整的执行过测试用例
4)熟悉在用例测试阶段所发现的缺陷和缺陷的分布情况
5)测试人员具备一定的测试经验对缺陷有敏锐的洞察力。
二、随机测试功能点的选取
1)根据用例测试阶段对产品的了解选取缺陷比较密集的功能模块。
在发现很多缺陷的地方一定可以发现更多的缺陷。我们在做随机测试的时候首先会先统计一下之前哪些模块被发现的缺陷最多那么接下来一定要重点的在那个模块里发掘一下缺陷。
2)根据发现的一次性缺陷或重现率比较低的缺陷涉及的功能点选取随即测试功能点。
缺陷产生的过程一定可以重现重现率比较低的缺陷是隐藏比较深的缺陷这些缺陷可能正是导致软件无法上线的原因。因此重现这些隐藏缺陷是十分重要的工作。
3)与开发人员沟通了解软件的缺陷。
首先可以了解到程序本身哪些地方最复杂最薄弱这些地方最容易发生什么错误其次可以了解程序员最容易在哪些地方犯哪些错误。前者通过对程序的熟悉可以比较好的掌握后者可以通过对缺陷的分析得到。
4)根据经验选取功能点。积累了一定的测试经验以后有时测试就是一种感觉。
5)随机选取功能点。经过上述四种情况对功能点进行筛选后剩下的功能点可以随机的选取。随机选取功能点只是在随机测试中选取功能点的一个方面更多的时候还是要有针对行的选取功能点。
三、功能点的随机测试
1)以测试用例为基础。
首先要明确随机测试是对功能点进行随机测试而不是随机测试功能点。因此每一个功能点都是测试对象依照测试用例可以有效地覆盖所有的功能点。
2)考虑操作前的状态
3)操作过程中的状态改变
4)考虑到其他功能对该功能点的影响
5)考虑该功能点直接对其他功能点的影响
6)考虑该功能点间接对其他功能点的影响
7)操作步骤地追踪。
在测试中常常会出现这样的情况进行一系列复杂的操作之后缺陷突然呈现在眼前。这个时候如果能清晰地描述出具体的操作过程对于缺陷的重现是十分有利的这也对最后的缺陷定位和简化缺陷的重现步骤提供了保障。交互性的模块追踪步骤主要考虑自己操作步骤地最终和对方操作步骤地追踪。有时缺陷的出现并不是完全是由自己的操作而发生的别人的操作也有可能导致缺陷只有综合自己和对方的操作才能是完整的过程追踪。 8)简化缺陷重现步骤。 寻找缺陷要准确定位开发和测试是一个整体时间是等量的时间不在你身上浪费就是在他身上浪费。如果测试人员每次发现的 8)简化缺陷重现步骤。
寻找缺陷要准确定位开发和测试是一个整体时间是等量的时间不在你身上浪费就是在他身上浪费。如果测试人员每次发现的缺陷 描述不清楚或者重现缺陷的过程非常复杂并且多个问题潜在的错误原因是一个虽然操作可能稍微有些变化。这样开发人员在重现缺陷 的时候他要调试跟踪判断很花费时间而且效率低。如果测试人员发现缺陷 的时候多尝试可以更加准确的定位缺陷 步骤和原因给开发人员最精确的步骤和准确的描述这样整个团队才能高效。简化缺陷重现的步骤主要体现在减少涉及的功能点的操作上。
9)测试经验的积累
经验是来之不易的东西我们需要在日常测试中不断的积少成多并且多和同行交换测试心得和测试经验丰富自己的测试手段和测试角度。经验在随机测试中可以帮助我们少走弯路让我们的目标更加明确更容易发现缺陷.
10)测试心态
做测试最重要的是心态这里说的心态一方面指的是测试人员对程序的看法。作为测试人员在拿到测试程序时一定要保持悲观的心态认定这个程序有很多缺陷和错误甚至认定这个程序很垃圾想像微软出来的程序都有很多缺陷那我们的程序也一定需要我们去狠狠的去发掘缺陷。不能因为这个模块已经被测试过好多遍或者这个这个模块非常小非常简单就忽略了对这个模块的测试。另一方面要有足够的耐心。首先在作随机测试之前比较明显的缺陷和操作步骤比较简单的缺陷已经基本上被找到随即测试主要是挖掘深层次的缺陷。相对用例测试操作步骤相对复杂因此随机测试可能会出现长时间找不到缺陷的情况如果心浮气躁可能放过对该模块的测试这时需要耐心的测试才能找到缺陷。
11)与程序员进行沟通
在和程序员沟通的过程中你可以知道很多你前所未知的东西例如功能的实现过程功能模块间的内在联系等你可以通过验证这些东西来发现未知的缺陷并且可以激发你运用更多的测试手段来测试。
12)一反三
首先通过以前发现的缺陷反映出可能出现的一类缺陷通过缺陷重现的步骤反映出一类操作可能会导致缺陷
13)突破测试思想上的束缚
测人人员的测试手段和测试角度往往是从别人那里得到的因此测试人员常常受到传统测试思想的束缚。挖掘更深层次的缺陷需要测试思想有所创新和升华这一点比较难做到需要更多的对测试方式和测试角度进行独立思考。
