1、按产品功能,测试产品的性能,在功能测试过程中找到功能性的bug
2、长时间的运行,老化,发现隐藏式的bug
3、不同的人,不同的方向去测试
可以在程序中用断点来逐步确认bug位置
人为添加一些外部的原因来确认有没有bug
比如有按键的设置一些条件
硬件BUG一般在极限恶劣的环境下使用后可以发现
软件BUG比较专业,有专门的学科和书籍,需要系统学习数据结构和计算机原理等知识
主要靠人为操作,
1.无论是有多复杂的代码,利用二分法定位技巧一般都是可以定位到问题所在。
2.IDE的VS debug的功能简直就是立竿见影。它可以加断点,单步调试。
3.相对新手程序员来说,如果代码出现bug,可以重新读一遍程序。
4.如果你发现无论如何也找不到BUG,而且代码只是复杂,本身不是很长,直接重写代码吧!
这个是一个十分考经验的活。
当然一些必要的技术手段可以帮助,比如代码覆盖测试,
好的测试用例等等。
在完成初版之后,应当进行功能性测试,这一阶段主要是看软硬件是否能实现某个指定的功能,这种找出来的多数是功能性BUG
然后应当进行老化测试,老化过程中可以找出一些偶发的程序BUG
后面进行小规模出货,这一阶段可以发现在某种特定环境下可能出现的BUG,比如在高温或者低温下,某些硬件可能异常,这时软件也要进行相应调整
这三个阶段走完之后,BUG就排查的差不多的了
看你是希望黑盒测试还是白盒测试了,不同测试目标的测试方法和测试结果都不同。
在我们公司,一般来说,集成测试部进行白盒测试,一般都是开放性测试,根据代码设置关键测试点,验证产品的可靠性。这时发现的bug一般都是边界性条件不满足。
中试部相对收缩,进行黑盒测试,根据产品需要的应用场景,进行可用性测试。这时测试出的bug一般都是在具体环境中,发现某个功能或者性能不适用。
另外,对于代码的安全性,一般是丢给coverity扫描工具来保障(事实上,经常有因为规避扫描出错,把原来没问题的代码改成含bug的代码)。
linux 驱动代码,对内核理解的基础上,看看驱动代码,就能看出来一些 bug,然后针对驱动写点测试代码,测试测试也能找出来bug
其他软件找 bug 我觉得应该都有特定的环境和方法吧,
bug一般都是隐性的,是不好发现的,所以,对于测试的时间与角度要进行不断的修改,时间尽量长时间的测试,才好发现问题。
先进行功能测试,再从不同的方向,让不同的人来测试