怎么进行软件测试才能把bug降到最低呢??

最近经常出现这种问题,一个功能,明明做完了,到整体测试的时候,出bug了,一个流程,明明是测试没问题了,产品到到客户那边还是有很多没有测试到的盲点。或许在有测试团队的公司中,会不会出现的少呢,这个不得而知,而在我看来,大体小公司还是经不起测试团队的消耗的,那如果没有测试团队,只靠开发人员开发后的功能测试,该怎么办呢??,或许是不是该使用单元测试,这样会不会耗时比较长。或者,这样,项目整体测试的时候,在只有几个人得情况下,可以先有一个人测试,其他人修改,然后换一个人测试,另外的人再进行修改,这样会不会好点呢??这个一直觉得很纳闷!

还有,很多时候,单个功能做完了,测试没问题了,可后来开发了另外的功能,跟该功能的方法有重用的时候,或者发生修改后,导致原先功能存在了一些逻辑死角的bug,这个该怎么办呢,根据最近的测试总结,很多时候,发生这种事的很多,毕竟多人开发,代码进行了多次修改,以渐渐脱离了开始创建该方法的意图,方法功能虽然强大了,但是往往存在很多思维死角,这个虽然在整体测试上能找到,但是还是会有第一段所说,一个流程,测试了没问题,到客户那边还是有bug.是否我们的开发惯性太大,还是人得偷懒行为,这个不得而知,然而,像这种全靠像后期测试这种,感觉不太实际,因为在事件不充裕的情况下,还是bug不断,代码也随着后期的修改变得混乱,毕竟,你当时开发的想法,修改的人不一定能够了解。

该怎么做,才能把bug减小到最低呢?该怎么做,才能是代码重用性高,且把思维死角的bug降到最低呢?而这些方法,会不会适合小型开发团队,在这种时间紧急的情况下,有什么办法更好的解决这种问题呢?求大神指点一下。谢谢!谢谢!

时间: 2024-09-29 05:56:21

怎么进行软件测试才能把bug降到最低呢??的相关文章

【软件测试】软件测试是找bug,不是找茬

前两天和一个新认识的朋友聊天 "你是码农吗?" 我那个气啊,我这个形象像吗?像吗?真想抽他丫的 "不是,我是做软件测试的,代码用的没有那么多,所以称不上" "哦!那你就是专门挑毛病,找茬的呗?" 当时我就认定了这个朋友拜拜了您内 "我是做测试的,找的是缺陷,不是找茬,谢谢您老了,先忙,再见" 回家了之后我就想分享一下: 第一: 测试是找bug,不是找茬.以前在外包做测试,面对的之间人是PM,面对所谓的客户是开发软件的人,而且因

漫谈程序员系列:无BUG不生活

我决定谈一谈世界上最著名的虫子:BUG ! BUG 困扰了一代又代的程序员,不论是杰出的计算机科学家,还是像 Linus Torvalds(Linux内核创始人) .Bill Joy(传说三天写出BSD的前身,vi和csh的作者)等神一样的传说,抑或你我芸芸程序猿,都是 BUG 骚扰的对象. BUG 是绝对狂热的好战分子,具有永不停歇的战斗欲望,它潜伏在程序员的周围,一双小眼贼亮贼亮,在你百密一疏时出其不意一击奏效.而无论你是钢筋铁骨,还是羊脂玉体,只要被这只虫子袭击(看过<木乃伊>的话,对圣

软件测试者的侦查之旅

[一]文档能力(阅读理解) 从事软件测试就想侦探一样,从最开始接触这个案子,就需要去阅读很多的需求文档,设计文档,用户手册,了解“案情”,做到心中有数.才能够在后续的测试中更好的判断软件是否符合用户的业务需求,才能够保证测试出现的bug不只是停留在操作层面:了解设计文档,掌握产品设计方面的知识,就像侦查里面的枪械科,法医,能够对测试的缺陷定位和分析很有帮助,知道这个“罪犯”在什么地方时间犯罪:了解用户手册,能够最快的了解项目的使用,尽快实践出真知. [二]文档能力(书写) 优秀的缺陷报告能够让开

UVA 658 It&#39;s not a Bug, it&#39;s a Feature! (单源最短路,dijkstra+优先队列,变形,经典)

题意:有n个bug,有m个补丁,每个补丁有一定的要求(比如某个bug必须存在,某个必须不存在,某些无所谓等等),打完出来后bug还可能变多了呢.但是打补丁是需要时间的,每个补丁耗时不同,那么问题来了:要打多久才能无bug?(同1补丁可重复打) 分析: n<=20,那么用位来表示bug的话有220=100万多一点.不用建图了,图实在太大了,用位图又不好玩.那么直接用隐式图搜索(在任意点,只要满足转移条件,任何状态都能转). 但是有没有可能每个状态都要搜1次啊?那可能是100万*100万啊,这样出题

软件测试文档

在软件测试中的流程中,测试文档也是一个重要的流程,所以测试人员也需要学习测试文档的编写和阅读. 一.定义: 测试文档(Testing Documentation)记录和描述了整个测试流程,它是整个测试活动中非常重要的文件.测试过程实施所必备的核心文档是:测试计划.测试用例和软件测试报告. 二.测试文档的重要性 软件测试是一个很复杂的过程,涉及软件开发其他阶段的工作,对于提高软件质量.保证软件正常运行有着十分重要的意义,因此必须把对测试的要求.过程及测试结果以正式的文档形式写下来.软件测试文档用来

WP8.1 Pivot 控件的SelectedIndex 属性与星期天BUG

Pivot 控件有一个SelectedIndex 可以指定当前显示的Pivot Item: 我在一个应用中将周一到周日,一共对应七个Pivot Item,并想实现一打开应用就显示当前日期对应的星期页面 于是这样写:   SelectedIndex =(int)DateTime.Today.DayOfWeek: 结果显示的并不是当天的页面,而是第二天的页面. 于是我就将上面的代码写成 SelectedIndex =((int)DateTime.Today.DayOfWeek-1): 这样过了几天,

遇到问题或bug时要做的事。

1,做事细心,只有细心才能减少bug量,做总结. 2,开发中遇到bug和错误,第一要想到是程序代码的问题.而首先想到的不是其他问题(比如版本,框架或兼容问题等). 3,程序不能按照自己的意愿执行,时先看控制台有没报错吧. 4,遇到没遇到过的错误先百度.确定错误类型或范围. 5,排除法虽然好使,但效率不高. 6,遇到错误要分析(猜)哪里可能出错,而不是逐步排查. 7,前端问题多看控制台和请求的网络地址. 8,后台问题多看控制台. 9,熟悉前后台,开发工具的使用.必要时候可以debug.

修复bug的12个关键步骤

boss:那么,你需要多长时间来修复这个bug? 没有经验的程序员:给我一个小时?最多两个小时?我能马上搞定它! 有经验的程序员:这么说吧,钓到一条鱼要多久我就要多久?! 要多少时间才能修复bug,事先是很难知道的,特别是如果你和这些代码还素不相识的话,情况就更加扑朔迷离了.James Shore在<The Art of Agile >一书中,明确指出要想修复问题得先知道问题的所在.而我们之所以无法准确估计时间是因为我们不知道需要多久才能发现症结的所在,只有清楚这一点,我们才能合理估计修复bu

Dotest--用例该如何书写?完整示例-软件测试

测试用例(case\测试点):指导软件测试工程师找bug的(思想逻辑的整理) 意义:1:怕忘:2:存档(让新人熟悉:产出):3:回归测试(软件即将上线之前,重新执行测试用例)--确认测试 书写测试用例是一个测试工程师最基本也是最重要的能力,无论你是什么岗位:黑盒.自动化.接口.性能亦或是安全测试工程师. 至于如何书写先不讲,先看下我们学员共同完成的一个完整版的用例示例图: QQ登录界面 原文地址:http://blog.51cto.com/dotest/2324162