bugfree的功能模块有哪些,bugfree是什么工具
常用的软件测试方法和工具
工业标准级负载测试工具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能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
测试经理和PM对TC进行Review:
敏捷测试流程总结:
在敏捷方法中,XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”,它告诉大家现在到哪了,正在往哪个方向走。测试员为项目组提供丰富的信息,使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量,而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误,而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈,需要动态调整测试计划、测试的执行。并且,敏捷测试人员参与到了更多的敏捷生产活动中,积极的影响了团队做出的决定和计划。
根据公司项目目前采用的敏捷开发模式,相应的敏捷测试建议采用以下流程:
1. 验证需求和设计
需求和设计具体来说一般包括:(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员,审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性.
在测试初期,测试人员要学会做静态测试,做好需求分析,做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性,将自身作为第一用户积极参与项目和系统的需求分析,设计和开发。积极地参与前期工作,并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试,不要等待到功能完全做好才开始。
产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来
2. 测试计划,测试用例
2.1 编写计划、测试用例
在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通,来确定每个user story的优先级。
好处:
客户可以很清楚的了解到哪些user story需要花费多长的时间,以及他们的优先级。
问题:
在user story的时间估算上,开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。
分析:
由于版本更新很快,任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间,比如开发中遇到问题的时间,开会,给其他成员提供帮助的时间,等等。
举个例子:
开发人员估算某个user story编码的时间需要1.5天,开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。开发阶段实际的花费时间如下,每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题,结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素,某本XP相关的书上写到,在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人,但是实际的过程中,的确需要这么多的时间。
测试人员根据已审核通过的需求和设计编制测试计划,设计测试用例。在前面提到的三种文本中,功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。
2.2 测试用例的审核
为使开发人员能参与到Test Case的Review中来,以保证TC的质量和可行性,确保测试工作的顺利进行,让开发人员迅速地了解测试的重点并给出相应的意见和建议,测试人员在出 TC的同时,应出一份TC_Matrix(Test Case跟踪矩阵),其中注明TC已覆盖了哪些Features,具体每个Features对应的TC的编号,这样在测试经理和PM对TC进行 Review的时候,能够对TC的覆盖率一目了然,对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见。
另外,在每天早上的Morning Meeting上,测试人员可以简洁地讲述一下当天测试的重点部分,以及项目中存在哪些严重的bug,让开发人员了解当天测试的重点是什么,怎样进行测试,并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通,使测试工作能够更加有效,更加顺利地开展。
在迭代后期测试要抽时间更新test case。
3. 实施运行测试
在敏捷方法中,测试有两种:单元测试和接收测试。单元测试是由开发人员来完成的,接收测试是由客户代表来完成。
由于我们客户无法在现场,我们采取了,开发人员做单元测试,测试人员做验证测试,最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试,发布版本之后由客户做接收测试,提出需要修改的地方。需要修改的地方将在下一个发布完成。
?? 单元测试
在daily build版本给测试前,开发首先要做单元测试,提前告知软件中的薄弱环节,帮助测试人员调整测试重点。Unit test
做单元测试的好处是可以提高版本质量,减轻测试的工作量,减少浅层次的bug的发生率,使测试人员能够将更多的精力投入到寻找深层次的bug上面。
?? 验证测试
测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合,根据产品的架构和功能模块的依赖关系,按照项目的总体计划共同推进。从测试的过程来看,测试执行的一开始可以是针对部分功能的,之后可以逐步扩展。接着开始采用迭代的过程完成测试任务,即将测试任务划分为多个周期,一开始可以做些关键的功能性测试,可以对代码中的可复用部分(组件,构件)做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试,最后的几个迭代应该用于回归测试,和关键的性能和稳定性测试。
3.1 每日提供bug趋势
为方便衡量项目的进度,测试可每天测试完毕后提供测试的bug趋势,即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势,到项目中后期被解决Bug数曲线会趋于上升,而新生Bug数曲线应下降,到项目最后,两条曲线都趋向于零。PM会持续观察这张图表,确保项目健康发展,同时通过分析预测项目Bug,
对于每个版本的bug,开发都应该想想为什么会出现这样的问题,特别是很低级的bug,对于同类的bug,是否可以避免。
测试需要考虑:探索性测试用例的编写
3.2 测试用例的维护
在执行测试阶段中,测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例:一是对于当初测试设计不周全的领域,二是对于外部的Bug(比如从Beta客户报告来的),没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁),所涉及的测试用例也要相应地修改,使测试用例保持和现有的功能需求同步。
3.3 根据项目不断补充Common Sense
在项目进行过程中,测试人员需要不断积累经验,不断补充、完善各类目的Common Sense标准。例如,由CTTS项目总结出的Common Sense for USA标准,在以后的美国项目中要严格按照它来执行测试,保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时,不断积累新的经验。
3.4 控制中间版本
为更好地保证软件质量,规避风险,必须加强对中间版本的控制。例如,客户要求或者计划周五要提交版本,则周三一定要提交一个中间过程的版本进行测试,也就是控制中间版本,避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松,到后期bug越来越多,开发人员和测试人员都异常忙碌,经常加班的情况。为减少后期工作量,规避风险,建议开发进行Daliy Build,或者按照完成一个feature就进行一次build,针对这个feature进行测试,这样就可以有效避免后期bug越来越多的状况发生,后期工作量也就会相应减少,项目的质量也会更有保证。
3.5 发布版本前编写Release Note
在每次发布版本之前,测试人员要根据待发布的版本情况编写Release Note,使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容:Fixed,New Features,Known Problems。其中,Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题,有待下个版本改善;或者列出需求不太明确的地方,有待客户给出明确答复意见,在下个版本中完成。
4. 需求管理
采用敏捷开发模式的项目中,客户对于需求的变更很频繁。因此,需求管理是十分必要和重要的工作。整个项目进行过程中,对不断变化的需求,一定要作跟踪,每次的需求变更都要有相应的历史记录,方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中,并使该文档始终保持最新更新的状态,与需求的变化保持同步。
问题:
客户可能会在一个功能点上来回修改他们的需求,也许开始需要某个功能,结果做完以后又觉得不好,于是让去掉这个功能。后来又由于一些原因,有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间,不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明。说白了,是有证据证明我们做了很多的变更。大家可能觉得,怎么会有这个问题。其实当一个项目长达半年以上,也许大家的记忆力都不可靠了(:p)
建议:
目前采用的是vss工具,对每天的Email中提到的需求变更做一次backup,文档以当天收到Email的日期命名
5. 项目开发末期开展“bug大扫除”
在项目开发的末期,可以开展“bug大扫除”活动。划出一个专门的时间段,在这期间所有参与项目的人员,集中全部精力,搜寻项目的Bug。注意以下要点:
(1)尽管这是一个测试活动,但参与者并不仅限于测试人员。项目经理,开发人员甚至于高层管理人员都应参加,如同全民动员。目的是要集思广益;(2)要鼓励各部门,领域交叉搜索,因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性,增强趣味性,可以适当引入竞争机制,比如当活动结束时,评出发现Bug最多,发现最严重Bug的个人,给以物质和精神奖励。(4)可以分专题展开,比如安全性、用户界面可用性、国际化和本地化等等。

软件测试都用哪些工具?各工具有什么特点?
1、Bugfree
BugFree是借鉴微软的研发流程和Bug管理理念,使用PHP+MySQL独立写出的一个Bug管理 系统。简单实用、免费并且开放源代码(遵循GNU GPL)。 命名BugFree 有两层意思:一是希望软件中的缺陷越来越少直到没有,Free嘛;二是表示它是免费且开放源代码的,大家可以自由使用传播。
?
2、bugzilla
Bugzilla 是一个开源的缺陷跟踪系统(Bug-Tracking System),它可以管理软件开发中缺陷的提交(new),修复(resolve),关闭(close)等整个生命周期。
?
3、Testlink
TestLink用于进行测试过程中的管理,通过使用TestLink提供的功能,可以将测试过程从测试需求、测试设计、到测试执行完整的管理起来,同时,它还提供了好多种测试结果的统计和分析,使我们能够简单的开始测试工作和分析测试结果。
?
4、manTIs
TMantis是一个基于PHP技术的轻量级的缺陷跟踪系统,其功能与前面提及的JIRA系统类似,都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业,界面也没有JIRA漂亮,但在实用性上足以满足中小型项目的管理及跟踪。
?
5、QTP
QTP是一个B/S系统的自动化功能测试的利器,软件程序测试工具。Mercury的自动化功能测试软件QuickTest Professional ,可以覆盖绝大多数的软件开发技术,简单高效,并具备测试用例可重用的特点。Mercury QuickTest Pro 是一款先进的自动化测试解决方案,用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。 Mercury QuickTest Pro为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案
?
6、selenium
selenium-core 是使用HTML的方式来编写测试脚本,你也可以使用 Selenium-IDE来录制脚本,但是目前Selenium-IDE只有 FireFox 版本。
?
BugFree哪个国家的
1. BugFree 简介 1.1 BugFree的来源 BugFree是借鉴微软的研发流程和Bug管理理念,使用PHP+MySQL独立写出的一个Bug管理 系统。简单实用、免费并且开放源代码(遵循GNU GPL)。 如何有效地管理软件产品中的 Bug,是每一家软件企业必须面临的问题。遗憾的是很多软件企业还是停留在作坊式的研发模式中,其研发流程、研发工具、人员管理不尽人意,无法有效的保证质量、控制进度,并使产品可持续发展。 针对这个问题,我们独立做出了 BugFree,并且半年多来每天都在使用。我们公司就是用它来管理Bug,不断提高产品质量的:-) 1.2 BugFree名称的含义 命名BugFree 有两层意思:一是希望软件中的缺陷越来越少直到没有,Free嘛;二是表 示它是免费且开放源代码的,大家可以自由使用传播。 1.3 为什么开放BugFree的源代码呢? 根据半年多的实践,觉得BugFree非常有用,我们公司的日常工作已经离不开它 了。虽然没有微软的Bug管理系统(以前叫Raid,现在是 Product Studio)的功能那么强大, 但是处理方法和思想是完全一致的,起码我自己用起来的感觉和在微软时基本一样,值得向大家推荐。 我们是用开放源代码的 PHP+MySQL开发的,目的就是希望跟大家分享BugFree。而 且开放源代码之后,期待高手不断改进它,大家都能用到更加强大的功能。也算为中国的软 件业做点小小的贡献:-) BugFree代码在我们的“数字神经系统”中非常独立,很容易拿出来给大家共享。 1.4 BugFree仅仅是个工具 不过坦率的讲,BugFree 仅仅是个工具而已,重要的是掌握其中蕴含的软件研发的流程思想,才能用好这个工具。如果你以前没有用过 Bug管理系统,那么一开始的时候也许你会觉得这个工具是在浪费时间,因为一个测试人员需要费神把发现 Bug的详细步骤记录下来, 有时还要贴一张示意图,这一切都不如当面说来得直接。 但是使用一段时间,你会发现 BugFree很有用,它忠实的记录着每个问题的处理过程, 不断提醒你存在的问题,永远不会丢失和忘记。如果你参与过较大软件项目或产品的研发, 就会理解它对软件可持续发展是至关重要的。而且研发的规模越大,BugFree 的作用就会越大。 2. 如何安装使用BugFree BugFree的安装和使用都非常简单,就像PHP+MySQL一样: INSTALL.htm 介绍了BugFree的安装 HOWTO.htm 介绍了如何使用BugFree FILES.htm 介绍了BugFree的代码文件结构 希望你能喜欢BugFree,就像我一样。 3. 为什么开发BugFree 一言以蔽之,「工欲善其事,必先利其器」。 3.1 我在方正的困惑 我曾在北京大学计算机研究所(方正技术研究院)学习、工作了七年,那里有我很多师长和好友,我参与研发的方正RIP (PSPNT) 至今仍是方正的核心软件产品。当自认为成了一名合格的 C++开发人员后,我发现面临一个无法解决的难题:如何有效地控制软件研发流程以保证产品质量和进度。我意识到做好一个软件,只靠技术好是很不够的,必须要有一套好的研发流程和配套的研发工具。恰好那时我在吴士宏的《逆风飞飏》中读到了微软的“数字神经系统”及相关叙述,很吃惊,想去那里看看。 3.2 微软数字神经系统的妙处 2000年我加入微软(中国)研发中心,真的很快在这里找到了答案。四年来,我所理解的微软数字神经系统在软件研发中的妙处是: 3.2.1 研发人员分工明确 主要的三个角色: PM (Program Manager)、 Dev (Developer)、 Tester三者分工明确、接口清晰,PM来定义需求、书写出来每个功能特性 (Feature)的设计文档(Spec),Dev写代码来实现这个Spec,Tester来测试 Dev做出来的东西是否符合 PM定义的 Spec,三个角色之间并无必然的上下级关系,只是分工合作完成某个功能(Feature)。我将之形容为“三权分立”,三者之间有效合作并制衡。国内企业好像还没有PM这个角色,而测试人员又往往成为开发人员的附庸,一个 Bug是否要被解决全 查看原帖
大家是用什么工具管理用例的呀。讨论下
是吗?QC没用过,有个问题,QTP能用来管理用例的吗?不可以吧.QTP全称(QuickTestProfessional)是Mercury公司开发的一种自动测试工具,使用QTP的目的是想用它来执行重复的手动测试,主要是用于回归测试和测试同一软件的新版本。
软件测试的项目有哪些常用的缺陷管理工具?
1.QC
QC的全称Quality center, 质量中心的意思,它是一款缺陷管理工具,可以组织和管理一个项目所有的测试阶段.
2.Bugzilla,
Bugzilla是一个Bug追踪系统设计用来帮助你管理软件开发。
Bugzilla是一开源Bug Tracking System,是专门为Unix定制开发的。但是在windows平台下依然可以成功安装使用.
3.Bugfree,
BugFree是借鉴微软的研发流程和Bug管理理念,使用PHP+MySQL独立写出的一个Bug
管理系统。简单实用、免费并且开放源代码(遵循GNU GPL)。
4.JIRA
JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。
JIRA功能全面,界面友好,安装简单,配置灵活,权限管理以及可扩展性方面都十分出色。
JIRA创建的默认问题类型包括New Feature、Bug、Task和Improvement四种,还可以自己定义,所以它也一是过程管理系统。
Jira融合了项目管理、任务管理和缺陷管理,许多著名的开源项目都采用了JIRA。
JIRA 是目前比较流行的基于Java架构的管理系统,由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务,因此在开源领域,其认知度比其他的产品要高得多,而且易用性也好一些。同时,开源则是其另一特色,在用户购买其软件的同时,也就将源代码也购置进来,方便做二次开发。
5.Mantis
Mantis是一个基于PHP技术的轻量级的缺陷跟踪系统,其功能与前面提及的JIRA系统类似,都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业,界面也没有JIRA漂亮,但在实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源,不需要负担任何费用。不过目前的版本还存在一些问题,期待在今后的版本中能够得以完善。
6.Readmine
Redmine是用ruby开发的基于web的项目管理软件,免费。JIRA收费
Redmine可以创建子任务,而jira不易创建子任务。
Redmine来管理项目,但它没有用例管理.
7.禅道
禅道项目管理软件是开源,集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款功能完备的项目管理软件,完美地覆盖了项目管理的核心流程。
8.TAPD
TAPD项目管理软件是基于敏捷开源,隶属腾讯开发出来的,集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款功能完备的项目管理软件,完美地覆盖了敏捷项目管理的核心流程。
9.TESTLINK
略
10.TD
略
如果想这块内容增强的小伙伴参考网上的相关知识(黑马程序员论坛等)
软件可用性评估有哪些软件
ErgoLAB、Bugfree、Bugzilla、TestLink、mantis
Winrunner最主要的功能是自动重复执行某一固定的测试过程,它以脚本的形式记录下手工测试的一系列操作,在环境相同的情况下重放,检查其在相同的环境中有无异常的现象或与预期结果不符的地方。
可以减少由于人为因素造成结果错误,同时也可以节省测试人员大量测试时间和精力来做别的事情。功能模块主要包括:GUImap、检查点、TSL脚本编程、批量测试、数据驱动等几部分。