为什么软件会存在BUG？

1.与软件本身的特点有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件；软件样品型带态即是产品，试制过程也就是生产过程；软件不会因使用时间过长而“老化”或“用坏”；软件具有可运行的行为特性，在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量，软件质量也较难评价，因此管理和控制软件开发过程十分困难；软件质量不是根据大量制造的相同实体的质量来度量，而是与每一个组成部分的不同实体的质量紧密相关，因此，在运行时所出现的软件错误几乎都是在开发时期就存在而一直未被发现的，改正这类错误通常意味着改正或修改原来的设计，这就在客观上使得软件维护远比硬件维护困难；软件是一种信息产品，具有可延展性，属于柔性生产，与通用性强的硬件相比，软件更具有多样化的特点，更加接近人们的应用问题。随着计算机应用领域的扩大，99％的软件应用需求已不再是定义良好的数值计算问题，而是难以精确描述且富于变化的非数值型应用问题。因此，当人们的应用需求变化发展的时候，往往要求通过改变软件来使计算机系统满足新的需求，维护用户业务的延续性。

2.来自于软件开发人员的弱点。其一，软件产品是人的思维结果，因此软件生产水平最终在相当程度上取决于软件人员的教育、训练和经验的积累；其二，对于大型软件往往需要许多人合作开发，卜源甚至要求软件开发人员深入应用领域的问题研究，这样就需要在用户与软件人员之间以及软件开发人员之间相互通讯，在此过程中难免发生理解的差异，行册从而导致后续错误的设计或实现，而要消除这些误解和错误往往需要付出巨大的代价；其三，由于计算机技术和应用发展迅速，知识更新周期加快，软件开发人员经常处在变化之中，不仅需要适应硬件更新的变化，而且还要涉及日益扩大的应用领域问题研究；软件开发人员所进行的每一项软件开发几乎都必须调整自身的知识结构以适应新的问题求解的需要，而这种调整是人所固有的学习行为，难以用工具来代替

分类: 电脑/网络 >> *** 作系统/系统故障

解析:

什么是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)

测试是独立的（Testing is Independent）

保证软件功能的定义有意义（Make sure the feature definitions make sense)

学会说不(learn to say "no" if you strongly feel so)

项目经理定义的规范也是可以改变的（PM's spec is changeable,too)

坚持正确的看法(Insist what is right)

职业化(Professionali *** )

向项目经理和开发人员反馈（Give PM/DEV Feedbacks)

---