我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:516棋牌游戏中心 > 发控设备 >

常用的软件测试方法和工具

归档日期:10-14       文本归类:发控设备      文章编辑:爱尚语录

  可选中1个或多个下面的关键词,搜索相关资料。也可直接点“搜索资料”搜索整个问题。

  开源测试管理工具:Bugfree、Bugzilla、TestLink、mantis 开源功能自动化测试工具:Watir、Selenium、MaxQ、WebInject 开源性能自动化测试工具:Jmeter、OpenSTA、DBMonster、TPTEST、Web Application Load Simulator [TestDirector]:企业级测试管理工具,也是业界第一个基于Web的测试管理系统。 [Quality Center]:基于Web的测试管理工具,可以组织和管理应用程序测试流程的所有阶段,包括指定测试需求、计划测试、执行测试和跟踪缺陷。 [QuickTest Professional]:用于创建功能和回归测试。 [LoadRunner]:预测系统行为和性能的负载测试工具。 [其他工具与自动化测试框架]:Rational Functional Tester、Borland Silk系列工具、WinRunner、Robot等。 国内免费软件测试工具有:AutoRunner和TestCenter。

  展开全部挺多的,测试方法包括测试需求分析方案,测试设计方案,测试执行方法,不知道你想了解的是哪类。平常来说,测试设计方法有:边界值,等价类,因果图,状态图,错误推出法等。

  展开全部工业标准级负载测试工具LoadrunnerLoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。自动化功能测试工具AutoRunnerAutoRunner是黑盒测试工具,可以用来完成功能测试、回归测试、每日构建测试与自动回归测试等工作。是具有脚本语言的、提供针对脚本完善的跟踪和调试功能的、支持IE测试和Windows native测试的自动化测试工具,是目前国内最好的银行业务测试工具。全球测试管理系统testdirectorTestDirector 是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理,测试计划,测试执行以及错误跟踪等功能,TestDirector极大地加速了测试过程。测试用例管理工具TestCenterTestCenter是一款功能强大测试管理工具,它实现了测试需求管理、测试用例管理、测试业务组件管理、测试计划管理、测试执行、测试结果日志察看、测试结果分析、缺陷管理,并且支持测试需求和测试用例之间的关联关系,可以通过测试需求索引测试用例。终端自动化测试工具TARTAR适用于VT100、VT220等标准的应用系统,支持命令行模式和窗口模式(使用Cursors编写的应用程序)。 支持针对终端应用的自动录制。支持连续录制和单独的窗口录制。支持的窗口组件:栏位、表格、对话框、窗口等。功能测试工具Rational RobotBorland SilkTest 2006属于软件功能测试工具,是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试,无论是程序设计新手或资深的专家都能快速建立功能测试,并分析功能错误。 性能测试工具WASMicrosoft Web Application Stress Tool 是由微软的网站测试人员所开发,专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具,您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。自动化白盒测试工具JtestJtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。parasoft同时出品的还有C++ test,是一款C/C++白盒测试工具。功能和性能测试的工具JMeterJMeter是Apache组织的开放源代码项目,它是功能和性能测试的工具,100%的用java实现。性能测试和分析工具WEBLODEwebload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能。企业级自动化测试工具WinRunnerMercury Interactive公司的WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

  在敏捷方法中,XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”,它告诉大家现在到哪了,正在往哪个方向走。测试员为项目组提供丰富的信息,使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量,而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误,而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈,需要动态调整测试计划、测试的执行。并且,敏捷测试人员参与到了更多的敏捷生产活动中,积极的影响了团队做出的决定和计划。

  在测试初期,测试人员要学会做静态测试,做好需求分析,做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性,将自身作为第一用户积极参与项目和系统的需求分析,设计和开发。积极地参与前期工作,并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试,不要等待到功能完全做好才开始。

  产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来

  在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通,来确定每个user story的优先级。

  客户可以很清楚的了解到哪些user story需要花费多长的时间,以及他们的优先级。

  在user story的时间估算上,开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。

  由于版本更新很快,任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间,比如开发中遇到问题的时间,开会,给其他成员提供帮助的时间,等等。

  开发人员估算某个user story编码的时间需要1.5天,开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。开发阶段实际的花费时间如下,每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题,结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素,某本XP相关的书上写到,在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人,但是实际的过程中,的确需要这么多的时间。

  测试人员根据已审核通过的需求和设计编制测试计划,设计测试用例。在前面提到的三种文本中,功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。

  为使开发人员能参与到Test Case的Review中来,以保证TC的质量和可行性,确保测试工作的顺利进行,让开发人员迅速地了解测试的重点并给出相应的意见和建议,测试人员在出 TC的同时,应出一份TC_Matrix(Test Case跟踪矩阵),其中注明TC已覆盖了哪些Features,具体每个Features对应的TC的编号,这样在测试经理和PM对TC进行 Review的时候,能够对TC的覆盖率一目了然,对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见。

  另外,在每天早上的Morning Meeting上,测试人员可以简洁地讲述一下当天测试的重点部分,以及项目中存在哪些严重的bug,让开发人员了解当天测试的重点是什么,怎样进行测试,并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通,使测试工作能够更加有效,更加顺利地开展。

  在敏捷方法中,测试有两种:单元测试和接收测试。单元测试是由开发人员来完成的,接收测试是由客户代表来完成。

  由于我们客户无法在现场,我们采取了,开发人员做单元测试,测试人员做验证测试,最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试,发布版本之后由客户做接收测试,提出需要修改的地方。需要修改的地方将在下一个发布完成。

  在daily build版本给测试前,开发首先要做单元测试,提前告知软件中的薄弱环节,帮助测试人员调整测试重点。Unit test

  做单元测试的好处是可以提高版本质量,减轻测试的工作量,减少浅层次的bug的发生率,使测试人员能够将更多的精力投入到寻找深层次的bug上面。

  测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合,根据产品的架构和功能模块的依赖关系,按照项目的总体计划共同推进。从测试的过程来看,测试执行的一开始可以是针对部分功能的,之后可以逐步扩展。接着开始采用迭代的过程完成测试任务,即将测试任务划分为多个周期,一开始可以做些关键的功能性测试,可以对代码中的可复用部分(组件,构件)做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试,最后的几个迭代应该用于回归测试,和关键的性能和稳定性测试。

  为方便衡量项目的进度,测试可每天测试完毕后提供测试的bug趋势,即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势,到项目中后期被解决Bug数曲线会趋于上升,而新生Bug数曲线应下降,到项目最后,两条曲线都趋向于零。PM会持续观察这张图表,确保项目健康发展,同时通过分析预测项目Bug,

  对于每个版本的bug,开发都应该想想为什么会出现这样的问题,特别是很低级的bug,对于同类的bug,是否可以避免。

  在执行测试阶段中,测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例:一是对于当初测试设计不周全的领域,二是对于外部的Bug(比如从Beta客户报告来的),没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁),所涉及的测试用例也要相应地修改,使测试用例保持和现有的功能需求同步。

  在项目进行过程中,测试人员需要不断积累经验,不断补充、完善各类目的Common Sense标准。例如,由CTTS项目总结出的Common Sense for USA标准,在以后的美国项目中要严格按照它来执行测试,保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时,不断积累新的经验。

  为更好地保证软件质量,规避风险,必须加强对中间版本的控制。例如,客户要求或者计划周五要提交版本,则周三一定要提交一个中间过程的版本进行测试,也就是控制中间版本,避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松,到后期bug越来越多,开发人员和测试人员都异常忙碌,经常加班的情况。为减少后期工作量,规避风险,建议开发进行Daliy Build,或者按照完成一个feature就进行一次build,针对这个feature进行测试,这样就可以有效避免后期bug越来越多的状况发生,后期工作量也就会相应减少,项目的质量也会更有保证。

  在每次发布版本之前,测试人员要根据待发布的版本情况编写Release Note,使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容:Fixed,New Features,Known Problems。其中,Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题,有待下个版本改善;或者列出需求不太明确的地方,有待客户给出明确答复意见,在下个版本中完成。

  采用敏捷开发模式的项目中,客户对于需求的变更很频繁。因此,需求管理是十分必要和重要的工作。整个项目进行过程中,对不断变化的需求,一定要作跟踪,每次的需求变更都要有相应的历史记录,方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中,并使该文档始终保持最新更新的状态,与需求的变化保持同步。

  客户可能会在一个功能点上来回修改他们的需求,也许开始需要某个功能,结果做完以后又觉得不好,于是让去掉这个功能。后来又由于一些原因,有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间,不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明。说白了,是有证据证明我们做了很多的变更。大家可能觉得,怎么会有这个问题。其实当一个项目长达半年以上,也许大家的记忆力都不可靠了(:p)

  目前采用的是vss工具,对每天的Email中提到的需求变更做一次backup,文档以当天收到Email的日期命名

  在项目开发的末期,可以开展“bug大扫除”活动。划出一个专门的时间段,在这期间所有参与项目的人员,集中全部精力,搜寻项目的Bug。注意以下要点:

  (1)尽管这是一个测试活动,但参与者并不仅限于测试人员。项目经理,开发人员甚至于高层管理人员都应参加,如同全民动员。目的是要集思广益;(2)要鼓励各部门,领域交叉搜索,因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性,增强趣味性,可以适当引入竞争机制,比如当活动结束时,评出发现Bug最多,发现最严重Bug的个人,给以物质和精神奖励。(4)可以分专题展开,比如安全性、用户界面可用性、国际化和本地化等等。

本文链接:http://cincybowl.com/fakongshebei/770.html