软件测试中为什么缺陷越早发现越好?
BUG本意是用于IT编程中出现的缺陷用在指代人身上一般有以下几点含义:1、此人某项才能已经超出了常人范畴,相当专业;2、此人的行为或想法与众不同,只是说不同,也有可能指好的方面,也有可能指离谱的方面;3、此人很逊,急需补救
怎么用excel写软件测试bug报告
摘要:当前用户对软件企业开发出来的软件质量提出了越来越高的要求了。
所以在这种大的环境背景下,催生了一个新兴的职业——“软件测试工程师”的职业。
尤其是最近2-3年来加入这个职业或者即将加入到这个职业的人也越来越多了。
那么作为一名软件测试工程师,我们该如何迅速找到软件中的缺陷Bug呢? 下面结合作者多年的软件测试经验谈谈。
按照作者的观点:凡是不符合用户需求的,或者在使用过程中给用户造成不便的,都认为它是Bug。
话虽然说的有点极端,但是现实就是如此。
那么对于刚入行的软件测试新手迅速找出软件中的Bug思路如下: 1、尽快熟悉公司的产品业务 比如你们公司做ERP软件的,你肯定要迅速熟悉EPR的业务流程;比如你们公司是做法院软件的,那么你一定要熟悉法院审判案件的流程,只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷,你发现的软件缺陷才是有价值的。
否则即使你能找到一些软件缺陷,那也是纯软件的缺陷,价值不大。
2、把自己当成是用户 把自己当成是用户去使用该系统,比如在使用该系统过程中是这样操作的吗? 2.1 比如在大量要求用户输入的软件界面中,有一些用户喜欢使用Tab键采用全键盘的输入;此时的正确的接口应该采取从左到右,从上到下的顺序。
2.2 比如有的用户喜欢使用快捷键操作等(Ctr+C,Ctr+V,Ctr+F),但是实际情况下一些开发出来的软件的快捷键却根本不起作用。
2.3 比如软件在需要用户输入的信息的时候(特别是在填写个人资料的时候),必填项后面一律要用*等醒目的标示,要让用户知道这个地方时必须填写的。
2.4 下拉框不选值的时候,应该有个默认值;并且要多检查程序中的多处下拉框,因为很多情况下下拉框取不到值。
3、善于怀疑,不要迷信高手 世界上没有绝对正确的,总有错误的地方,具有叛逆心理,别人认为不可能发生的事,我却认为可能发生。
别人认为是对的,我却认为不是对的。
如果你认为某个或者某些程序员水平很高,他写的这个地方应该没问题吧,那么我要说你错了,这样很容易遗漏软件中的Bug。
因为程序开发人员毕竟是普通的人,只要是人就会犯错误的。
4、不要让程序开发人员的观点:“用户不会进行这样的操作”而说服自己 遇到这样的情况,你要坚持你自己正确的想法,以后对方会明白你的。
比如在一个录入员工基本信息的系统中,系统中对员工的年龄作为负值、而没有作为判断、也可以保存到数据库中,此时你不要被程序员的用户不会进行这样操作的观点说服自己,你要坚持你正确的观点,把这种现象作为一个Bug吧,勇敢点!你的选择不会不错! 5、在软件测试过程中要跟踪一条数据完整的流程 在软件测试的时候要跟踪一条数据完整的流程,保证数据的正确性这个真的是太重要了:假如你在测试一个销售的类型的软件的时候:你应该先做订货-à入库-à盘点-à销售-à查询。
首先你要保证这个数据的流向是正确的无误的。
假如你在测试法院审判软件的时候,你要先收案-à立案-à发送审批-à排期---审理审判-à结案判决-à归档-à查询。
总之跟踪一条数据的流程,保证数据的正确性。
如果经过你测试的软件在用户使用过程中业务流程上都走不通的话,那么这样的软件你说经过你的测试,但是在比人看来与没有测试有什么区别呢? 6、回归测试要注意的细项 程序员提交新的程序版本后,作为测试人员应该立即与程序员沟通这个修改的功能、并且这个新修改的功能影响哪些功能。
举个简单的例子来说明一下:比如在一款软件中,程序开发人员修改了某个“会员”的某个字段信息。
作为测试人员首先你要测试“会员”的功能这个是你首先需要做的。
另外你还要和程序员沟通询问他们新修改的这个会员的字段,会影响会员的销售功能吗?会对会员以前的销售记录的查询有影响吗?如果对这些功能有影响,那么这些功能都是你在回归测试的时候重点测试的地方,也是最容易产生Bug的地方了。
7、与使用者互动的缺陷 7.1 如填写资料错误应的时候,应该能够提示错误的位置,让用户知道是这个地方输入数据不对。
7.2 删除数据之前给一定要给出是否删除确认提示。
7.3 不要在软件中使用中英文混合的提示比如:比如对于用户某个操作的错误提示,不要一会用“error”、一会用“错误”;一会用“succeed”另一会用“成功”,总之要统一。
软件测试流程和bug生命周期?
测试流程依次如下:1.需求:阅读需求,理解需求,与客户、开发、架构多方交流,深入了解需求。
--testing team2.测试计划: 根据需求估算测试所需资源(人力、设备等)、所需时间、功能点划分、如何合理分配安排资源等。
---testing leader or testing manager3.用例设计:根据测试计划、任务分配、功能点划分,设计合理的测试用例。
---testing leader, senior tester4.执行测试:根据测试用例的详细步骤,执行测试用例。
--every tester(主要是初级测试人员)5.执行结果记录和bug记录:对每个case记录测试的结果,有bug的在测试管理工具中编写bug记录。
--every tester(主要是初级测试人员)6.defect tracking:追踪leader分配给你追踪的bug.直到 bug fixed。
--every tester7.测试报告:通过不断测试、追踪,直到被测软件达到测试需求要求,并没有重大bug.8.用户体验、软件发布等……
测试过程中如何准确进行bug描述
但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误,也就是bug。
因此需要一个方法来跟踪、分析和展示那些测试活动,避免偏离最小。
这种方法称之为错误跟踪系统。
它主要是有效的管理缺陷,实现以下作用:1)减少由于缺陷报告不明确而被开发组驳回的情况;2)加快缺陷的处理速度;3)提高测试的可信度;4)加强测试组与开发组在整个项目过程中的团队合作3、如何才能提交好的测试bug在有些组织里,程序员几乎会把一半的测试bug返回给测试组,因为那些错误不可再现、没有发现错误、同设计要求一致,或者错误报告根本无法操作。
如果错误报告有如此高的返回率,基本可以认为是过程崩溃,需要立即解决:因为编写这些报告浪费了时间;会影响程序员和测试人员之间的团队凝聚力;最糟糕的是失去改进产品质量的机会。
有些错误总是不可再现的或提出质疑的。
有些错误只是间断地在模糊的或极端的条件下表现出来。
有时候,测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。
在需求不清楚的项目中,在一定的测试条件下,对“正确”行为的观点可以存在合理的不同。
有时候,当真正的问题在于糟糕的测试过程、测试数据或不正确的测试用例时,测试人员可能错误解释测试测试结果和报告错误。
为了防止这类问题,要提交好的测试bug,作为一个好的测试人员,必须遵循以下八个步骤:1) 结构:无论你是做探索性的或是描述性的、手工的或自动的测试,都要认真仔细的测试;2)再现:尽量三次再现故障。
如果问题是间断的,那么最好报告问题发生的概率;例如,每3次出现一次,每3次出现2次等;3) 推广:确定系统其他部分是否可能出现这种错误,以及使用不同的数据是否可能出现这种问题,特别是那些存在严重影响的问题。
4)总结:简要描述客户或用户的质量体验和观察到的一些特征。
5)压缩:精简任何不必要的信息,特别是冗余的测试步骤。
6)去除歧义:使用清晰的语言,尤其要避免使用那些有多个不同或相反含义的词汇。
7)中立:公正地表达自己的意思,对错误及其特征的事实进行描述,避免夸张或忽略的语句,引起过度的注意力或忽视。
8)评审:至少有一个同行,最好是一个有经验的测试工程师或测试经理,在你提交测试报告或测试评估报告之前先自己读一遍。
好的测试bug描述是告诉读者测试人员发现了什么,而不是测试人员做了什么。
因此只需要根据上述八个步骤写下最少的必需重现步骤。
系统中的BUG是什么来的
什么是Bug??Bug的定义可以很广泛,在软件使用过程中所出现的任何一个可疑问题,或者导致软件不能符合设计要求或满足消费者需要的问题都可以是Bug,即使这个Bug在实践中是可行的?Bug可以真正消灭吗?可以说,没有任何一个产品没有Bug,也永远不可能找出并修复所有的Bug。
在修复了旧的Bug的同时,往往又会产生新的Bug?以微软的经验,每修复三到四个Bug,一般又会产生一个新的Bug?所以,Bug提交开发人员解决后,可能会有以下几种类型的反馈?1。
Fixed:表示Bug已经被修复或更正了2。
Duplicated:表示测试人员所找到的某个Bug已经被别人找出来了。
3。
PostPoned:表明这个Bug不是很重要,在当前阶段不用进行更正了,或者更正这个Bug风险太大,Bug本身又不会造成大的影响4。
By Design:测试人员认为是Bug,不符合逻辑,也不符合用户的需求,但开发人员则认为是按照项目经理的设计做的5。
Not repro:以前出现的某个Bug自动消失了,可能是处理其他Bug的时候把这个Bug一并修复掉了6。
Won't Fix:这个Bug是一个错误,还没有重要到非要更正不可的地步,完全可以忽略不计?软件测试应该注意的问题1。
测试最重要的一件事就是要考虑所有的出错可能性。
同时,还要做一些不是按常规做的,非常奇怪的事情2。
除了漏洞之外,测试还应该考虑性能问题,也就是一定要保证软件运行得很好,非常快,没有内存泄漏,不会出现越来越慢的情况3。
另外,测试还要考虑软件的兼容性??软件测试方法和辅助工具1。
覆盖性测试(Coverage Testing)??? 这是一种从代码的特性角度(即内部)出发的测试方法,包括以下方式单元测试(Unit Test),按照代码的单元组逐个进行测试 功能测试(Function Test)或特性测试(Feature Test):按照软件的功能或特性逐个进行测试。
提交测试(Check-in Test):在开发人员对代码做了任何修改,或者修复了某个Bug时,需要重新Check-In代码,即将修改后的代码放入到整个大的系统中。
这时开发人员也要进行测试,看代码是否工作正常。
基本验证测试(Build Verification Test):对完成的代码进行编译和连接,产生一个构造,以检查程序的主要功能是否会像预期一样进行工作。
?回归测试(Regression Test):过一段时间以后,再回头来对以前修复过的Bug重新进行测试,看该Bug是否会重新出现。
2。
使用测试(Usage Testing)??? 这是一种用户角度(即外部)出发的测试方法,包括以下方式配置测试(Configuration Test):从用户的使用出发进行多方面的测试。
兼容性测试(Compatibility Test):例如一个产品的不同版本,不同厂家的不同产品的兼容性问题 强力测试(Stress Test):在各种极限情况下对产品进行测试(如很多人同时使用该软件,或者反复运行该软件),以检查软件的长期稳定性 根据微软的实验经验,如果一个软件产品能通过72小时的强力测试,则该产品超过72小时后出现问题的可能性微乎其微。
所以,72小时就成为微软产品强力测试的标志。
性能测试(Performance Test):保证程序具有良好的性能。
如果别人的产品只需要5秒就能得出结果,而你的产品需要10秒,就说明你的产品性能不好。
如果在测试阶段发现性能问题,修复起来非常艰难。
因为这常常意味着程序的算法不好,结构不好,或者设计有问题,因为在产品开发的初期阶段,就要考虑软件的性能问题。
文档和帮助文件测试(Documentation and Help FIle Test):因为用户通常是通过文档和帮助文件来学习使用产品的,如果文档和帮助文件存在错误,就可能会导致用户无法正常使用产品。
Alpha和Beta测试(Alpha and Beta test):在正式发布产品之前,往往会先发布一些测试版,让用户能够反馈相关信息,或者找到存在的Bug,以便在正式版中解决??另外一种分类方法?1。
白盒测试(White Box Testing)又叫做玻璃盒测试(Glass Box Testing),在软件编码阶段,开发人员根据自己对代码的理解和接触进行的软件测试。
主要以软件开发人员为主。
2。
黑盒测试(Black Box Testing)接受性测试(Acceptance Testing) Alpha/Beta测试(Alpha and Beta Testing) 菜单/帮助测试(Menu/Help Testing) 发行测试(Release Testing) 回归测试(Regression Testing) RTM测试(Release to Manufacture Testing) 功能及系统测试(Function & System Testing) 规范验证 正确性 可用性 边界条件 性能 强力测试 错误恢复 安全性 兼容性 软件配置 软件安装还有一种分类方法1。
手工测试2。
自动测试?辅助工具计算机 优秀的办公处理软件(用于编写测试计划和规范) 视频设备 秒表(计算程序的运行时间,测试产品性能) 自动跟踪系统(微软内部使用的是RAID,用来自动跟踪Bug) 自动测试工具(产生AutoMation脚本) 软件分析工具 好的操作系统(如Windows 2000,有很多有用的工具,如文件比较器,查看器,转换器,内存监视器等) 多样化平台相关测试文档测试计划 测试规范 测试案例 测试报告 Bug报告如何与项目经理及开发人员沟通巴迪测试(Buddy Test) 友好的关系(Friendly Relationship) 测试是...
软件测试具体是做什么的?(面试人员说刚开始做的是处理一些代码非...
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。
执行测试用例后,需要跟踪故障,以确保开发的产品适合需求。
使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 它是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程;是SQA(software quality assurance)的重要子域。
Grenford J.Myers曾对软件测试的目的提出过以下观点: (1)测试是为了发现程序中的错误而执行程序的过程; (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案; (3)成功的测试是发现了至今为止尚未发现的错误的测试。
然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此!(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者 发现当前软件开发过程中的缺陷,以便及时改进;(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性;(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法 软件测试完整分类,参见:软件测试的完整分类以上的都是官话!其实说白了,软件测试就是在开发人员做出软件投放市场前,尽可能早的找出软件当中所存在的BUG!因为任何软件在理论上来说都是存在问题的,都不是完美的!尽早的找出漏洞,公司的损失也就越低!这也就是软件测试人员越来越受重视的原因!其实软件测试是一种相当乏味枯燥的工作,一般面公司都比较偏向稍微内向的人,另外测试人员还要具备相当的口才,方便与开发人员还有客户交流!
转载请注明出处51数据库 » 软件测试过程中发现的缺陷(bug)太多时