软件缺陷分析(软件缺陷分析方法)

软件缺陷分析方法有哪些

已经修改的错误重复出现; 无法清晰的描述当前版本的缺陷状态; 对测试中发现的问题,主要依靠记忆得方式来记录;能记录的数量有限,并且经常遗忘; 采用了记录单或问题表单的方式来记录缺陷,但只是简单的记录了错误内容,没有分析和流程跟踪能力; 研发经验教训得不到继承,重复同样的错误; 缺陷跟踪管理系统可以规范项目中开发、测试、缺陷处理的流程.

常用软件缺陷预防技术和缺陷分析技术有哪些？

一般常用的缺陷预防有几个阶段，需求阶段，设计阶段，编码阶段。

第一，在需求阶段，最重要的事情是需求验证。一般验证的几个大项是，功能是否完整，是否考虑性能，有没有模糊需求，有没有考虑安全性，有没有冗余和错误的需求，需求是不是过于苛刻，需求是不是矛盾等方面。一般常用的方法是列出需求检查表，并进一步执行需求/测试矩阵。

第二，设计阶段，这个阶段主要通过技术评审测试逻辑设计。常用比较规范的作法是建立过程/数据矩阵，也就是CRUD矩阵，把过程影射到实体，把整个程序的数据的生命周期（建立，更新，读取，删除）反映出来。

第三，编码阶段，这个阶段预防措施主要有统一编码规范，代码评审，

单元测试

。统一代码规范一般是开发经理统一要求，代码评审则是互相评审或者开发leader进行评审，最后最重要的则是单元测试，就是一般说的白盒测试。

再来说缺陷分析吧，很多很高深的分析技术也不很实用，我只介绍一点常用的分析方法。

1.模块的缺陷分布，一般用柱状图或饼状图，就是每一个功能模块发现bug的比例，发现bug最多的模块证明在发布以后需要更多的维护。

另外，历史数据可以参照，譬如上一个版本在哪个模块发现的bug比例对这个版本就是一个参考。如果，某个模块发现bug的比例比上个版本大幅下降，则很可能说明该模块还需要更多测试。

2.缺陷的起因分布，一般用柱状图或饼状图，一般可分为架构缺陷、功能缺陷、易用性缺陷、性能缺陷、安全性缺陷、界面文字缺陷。一般如果架构缺陷占的比例较大，则说明设计有很大问题。

3.按照不同发现人员的缺陷分布，一般用柱状图或饼状图，一般分为测试人员发现，开发人员发现，beta测试发现，外部客户发现。如果测试人员发现的bug低于某个比例，证明质量保证测试不足。

4.按照不同方式的缺陷分布，一般有需求审查，设计测试，代码走查，JAD，手工测试，

自动化测试

，白盒测试。一般来说，如果通过需求审查，设计测试，代码走查，JAD发现的bug比重很低则说明测试前期重视不够，另外，在手工测试和自动化测试之间的比例也能说明自动化测试的贡献度。

5.缺陷差额分析，就是已经发现的和已经解决的曲线关系，以时间为横轴，两者越接近说明产品质量越高

6.按照时间段的缺陷分布，一般用时间为横轴的曲线图表示，主要说明在哪个阶段发现的bug最多，对测试总结有指导意义

7.Rayleigh分析，就是俗称的零缺陷追踪法，一般截至某个时间点发现的缺陷总数和时间有一个函数关系（一个复杂的数学函数），一般用这个函数来推测经过多少天测试之后软件中大概还有多少个bug，以及交付到用户手中之后大概还能出现多少个bug。不过由于本人严重怀疑该方法的实用性，我还没用过。

一不小心，罗罗嗦嗦这么多，希望对大家有帮助，哪怕是一点点，也希望大家多探讨探讨。

软件缺陷分类的标准

软件缺陷(software defect)分类标准缺陷属性属性名称描述缺陷标识(Identifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识缺陷类型 (Type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。缺陷严重程度 (Severity) 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。缺陷状态(Status) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。缺陷来源(Source) 缺陷来源指引起缺陷的起因。缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。缺陷类型（Type）缺陷类型编号缺陷类型描述 10 F- Function 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。 20 A- Assignment 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。 30 I- Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。 40 C- Checking 提示的错误信息，不适当的数据验证等缺陷。 50 B Build/package/merge 由于配置库、变更管理或版本控制引起的错误。 60 D- Documentation 影响发布和维护，包括注释。 70 G- Algorithm 算法错误。 80 U-User Interface 人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。 90 P-Performance 不满足系统可测量的属性值，如：执行时间，事务处理速率等。 100 N-Norms 不符合各种标准的要求，如编码标准、设计符号等。缺陷严重程度（Severity）1.3.1 软件测试错误严重程度 # 缺陷严重等级描述 1 Critical 不能执行正常工作功能或重要功能。或者危及人身安全。 2 Major 严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法） 3 Minor 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法） 4 Cosmetic 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。 5 Other 其它错误。1.3.2 同行评审错误严重程度 # 缺陷严重等级描述 Major 主要的，较大的缺陷 Minor 次要的，小的缺陷缺陷优先级（Priority）# 缺陷优先级描述 1 Resolve Immediately 缺陷必须被立即解决。 2 Normal Queue 缺陷需要正常排队等待修复或列入软件发布清单。 3 Not Urgent 缺陷可以在方便时被纠正。缺陷状态（Status）缺陷状态描述 Submitted 已提交的缺陷 Open 确认“提交的缺陷”，等待处理 Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷 Resolved 缺陷被修复 Closed 确认被修复的缺陷，将其关闭缺陷起源（Origin）缺陷起源描述 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段发现的缺陷缺陷来源（Source）缺陷来源描述Requirement：由于需求的问题引起的缺陷 Architecture：由于构架的问题引起的缺陷Design：由于设计的问题引起的缺陷 Code：由于编码的问题引起的缺陷Test：由于测试的问题引起的缺陷 Integration：由于集成的问题引起的缺陷

软件的缺陷等级应如何划分?

补充相关方面：A类—严重错误，包括以下各种错误： 1．由于程序所引起的死机,非法退出 2．死循环 3．数据库发生死锁 4．因错误操作导致的程序中断 5．功能错误 6．与数据库连接错误 7．数据通讯错误 B类—较严重错误，包括以下各种错误： 1．程序错误 2．程序接口错误 3．数据库的表、业务规则、缺省值未加完整性等约束条件C类—一般性错误，包括以下各种错误： 1．操作界面错误（包括数据窗口内列名定义、含义是否一致） 2．打印内容、格式错误 3．简单的输入限制未放在前台进行控制 4．删除操作未给出提示 5．数据库表中有过多的空字段D类—较小错误，包括以下各种错误： 1．界面不规范 2．辅助说明描述不清楚 3．输入输出不规范 4．长操作未给用户提示 5．提示窗口文字未采用行业术语 6．可输入区域和只读区域没有明显的区分标志

软件缺陷的简介

软件缺陷(Defect),常常又被叫做Bug.所谓软件缺陷,即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷.缺陷的存在会导致软件产品在某种程度上不能满足用户的需要.IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背.在软件开发生命周期的后期,修复检测到的软件错误的成本较高.

软件测试中软件缺陷有哪些表现

不符合用户需求的就是缺陷

怎么去分析一套软件或系统的优缺点,主要是从那些方面.

第一,功能强大且完善. 第二,运行速度要快. 第三,所占用的资源不能太大. 第四操作简单.

个人软件过程的缺陷管理

缺陷是指程序中存在的错误，例如语法错误、标点符号错误或者是一个不正确的程序语句，是任何影响程序完整而有效的满足用户要求的东西，是可以表示、描述和统计的客观事物。

有人把缺陷称为Bug，这是不正确的。当成为Bug时，令人想到的是那些令人讨厌的小虫子，应该把它们拍死或者不予理睬。这会使一些重要的问题被视为琐碎小事，会养成一种错误的态度。缺陷并不像无足轻重的Bug，更像是定时炸弹。大家可能会觉得有些夸大其词，绝大部分细小的缺陷没有引起严重后果。然而不幸的是，很小一部分看起来无关紧要的缺陷却能引起严重问题。虽然现在缺陷对你来说还不是一个严重问题，但很快就会成为一个重要的问题。

设计错误的复杂性和所导致的缺陷的影响没有直接关系，一些微小的编码错误却可能引起严重的系统问题。事实上，绝大多数软件缺陷都源于程序员的疏忽大意。

为了减小缺陷，就必须进行缺陷管理，研究已经引入的缺陷，确定引起这些缺陷的原因，并学会在将来如何避免重复同样的错误。

缺陷分类。在分析缺陷时，将缺陷进行分类是有帮助的。通过缺陷分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷，这就是缺陷管理的关键。把精力集中到最容易引起问题的几类缺陷上，一旦这几类缺陷得到控制，在进一步找到新的容易引起问题的几类缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。

不要急于把10种类型的每一类细分出若干子类，直到你已经搜集到大量程序的缺陷数据。那时，才能够看出哪里需要更详细以及补充什么样的信息才是最有用的。

统计缺陷个数。采用缺陷记录日志，记录那些当你完成初始设计或编码后仍然留在产品中的缺陷。人们很容易对缺陷辩解，但是要管理好缺陷，就必须收集有关缺陷的准确数据。如果原谅缺陷，那只会自欺欺人。如果你这样做的话，就别指望有所提高。

为什么要尽早发现缺陷。不要期望一个简单拼凑出来的满是缺陷的程序，经过修改可以成为一个合格的产品。一旦生产出一个有缺陷的程序，它将永远是有缺陷的。虽然你可以修复所有已知的问题，并且让它通过所有的测试，但它还是一个有许多不定的有缺陷的程序。如果工程师能宽容有缺陷的工作，他将生产出低质量的产品。“我们忙，以后在修补吧”，这样的态度不可能出产出优质产品。

发现和修复缺陷的费用。在典型项目中，产品被分成很多小的模块，由不通的工程师负责开发。在模块设计、实现、编译后，工程师作初始的单元测试；单元测试后，多个模块组成一些大组件进行集成测试；经过各种级别的组件测试后，这些组件集成为产品进行产品设计；最后，将产品集成到系统中进行系统测试。随着系统的规模和复杂程度不同，单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、复杂程度有所不同，但几乎所有规模的软件产品，都需要这个过程。

研究证明，开发过程每前进一步，发现和修复缺陷的平均代价要增长10倍。尽管缺陷的修复时间变化很大，但平均时间总是遵循这样的规律，而与缺陷的类型无关。

发现和修复缺陷的方法。尽管没有办法不引入缺陷，但是在开发过程中尽早发现和修复缺陷还是可能的。有多种发现程序中的缺陷的方法，基本上都包括以下步骤：表示缺陷征兆；从征兆中推断出缺陷的位置；确定程序中的错误；决定如何修复缺陷；修复缺陷；验证这个修复是否已经解决了这个问题。

有多种工具和辅助手段来帮助完成这些步骤，工程师最常用的工具是编译器，它能够表示出大部分语法缺陷。但是编译器最基本的任务是生成目标代码，并且可能会在源程序有缺陷的情况下生成代码。因此，不能检查出所有的拼写、标点符号或其他不符合语法的缺陷。一般编译器仅提供了缺陷的征兆，你必须自己对问题定位，并确定是什么问题，通常很快能够做到这一点，但偶尔也需要较长的时间

另外一种常用方法就是上面讲述的测试。测试的质量是由测试用例覆盖所有程序功能的程度决定的。测试可以用来验证程序几乎所有的功能，但有自己的缺点：同编译器一样只能满足缺陷派出的第一个步骤，你仍必须从缺陷征兆找出问题的根源，然后才能修复；随着项目规模的扩大，全面的测试会花费大量的时间，要进行完全测试几乎不可能的。

最有效的发现和修复缺陷的方法是个人复查源程序清单。这种方法是负很难彻底清除程序中的缺陷，但事实证明，这是最快而且最有效的方法。

代码复查就是研究源代码，并从中发现错误。代码复查更有效的原因是：在复查时看到的是问题本身而不是征兆。从头到尾复查代码时，考虑的是程序应该做什么。因此，当看到某些地方不正确时，就可以看到可能的问题是什么，并立即去验证代码。复查的缺点是：非常耗时，而且很难恰当的进行；复查时一种技能，当然可以通过学习和实践来提高。

代码复查的第一步是了解自己引入的缺陷的种类，这是收集缺陷数据的主要原因。因为在下一个程序中引入的缺陷种类一般会与前面的基本类似，只要采用同样的软件开发方法，情况会一直如此。另一方面来说，当你有了技能和经验或改变了过程，缺陷的类型和数目会随之变化。但是到了一定程度后，改进就变得非常困难了。这是，就必须研究缺陷，这可以帮助你找到更好的发现和修复缺陷的方法。

如何进行代码复查。代码复查的目标是在软件过程中尽可能早和尽可能多的发现缺陷，缺陷发现时间越少越好。采用表4.3描述的一个有序的检查方法，在编译之前进行代码复查，是完成目标最好的方法。

编译之前进行复查。有几个原因说明应在编译之前进行代码复查：不论编译前或编译后，进行完整的代码复查的时间大约相同；不论编译前或编译后，对检查语法有效性的效果是一样的；先做复查将节省大量编译时间，若不做代码复查，一般要花12%～15%的开发时间进行编译，一旦使用代码复查后，编译时间可以缩短至3%或更少；编译程序后，代码一般复查很难彻底的进行；经验证明，在编译阶段有大量的缺陷时，一般在测试阶段也有许多缺陷。

建立个人代码复查检查表。如果想发现和改正程序中的每一个缺陷，就必须遵照一个精确的规程。检查表可以确保遵循这个规程，它包括一系列程式的步骤。按照检查表去作时，就知道如何进行代码复查。

如果能够正确使用检查表，还能知道每个步骤发现了多少缺陷。这样就能测量出复查过程的效率，并进一步改进检查表。检查表包括了个人的经验。通过不断的使用和改进个人检查表，就可以帮助你用较少的时间发现这些缺陷。表4.4是一个C++程序代码复查表的范例。

定期更新检查表。随着时间的推移，检查表自然的要变大。但是，检查表的主要作用是帮助你把注意力集中在关键的方面。太大以后，你将失去重点。所以要定期复查缺陷数据，删除那些不能找到问题的表项。

从个人检查表的方法可以认识到，每个工程师都有各自的特点，某个工程师的实践经验对别人不一定适用。因而要设计出适合自己的检查表，并定期的对它进行检查以保证检查表更有效。只要你在代码复查中还遗漏缺陷，就要不断寻找改进检查表的方法。

进展是很缓慢的。最初，你发现缺陷的能力随着每次复查都有所提高。此后，提高将变得很困难。要坚持收集和分析缺陷数据，并坚持思考如何才能预防缺陷的产生或怎样更好的找到缺陷。只要坚持不断的做下去，就能在代码复查中不断进步，不断提高自己编写程序的质量。

编码标准。编码标准是被广泛接受的、能够作为工作样板的编码实践集。良好的编码标准将有效地帮助您避免开发有潜在危险的代码，有助于预防缺陷。例如，可以在编码标准中列出那些应该避免使用的方法，规定号循环入口或在说明是初始化变量，避免不良的变量命名等。编码标准还能有效地统一和规范整体开发活动。当其他开发人员加入到项目中来时，他们能够很好地适应这一切。代码也将变得更规范更易维护。

其他种类的代码复查。在软件组织中，一种常用的方法是同行评审，就是几个工程师彼此复查程序。组织良好的同行评审一般会发现程序中50%～70%的缺陷。互查虽然需要很多时间，但是可以有效发现缺陷，因为工程师往往难于发现自己的设计错误。他们创作这个设计，直到程序应该完整什么，即使概念有瑕疵、作了错误的设计或实现假定，他们往往很难发现。检查这可以帮助他们克服这些问题。对一个大的项目，最佳检查策略是，先做个人代码复查再进行编译，然后在任何测试前进时行同行检查。

细心工作是有回报的。当工程师觉得对自己开发的程序附有质量责任时，他就不会依赖于编译器或其他工具来发现缺陷。全面的代码复查要花费时间，但是他们节省出来的时间比花费的时间多得多，并能够生产出更好的产品。

引入缺陷是人类的正常现象，所有的工程师都会引入缺陷。因此所有的工程师都应该了解自己引入缺陷的类型和数据。

在开发过程中，总是可再进行一轮测试或代码复查，决定是否这样做的唯一方法就是分析缺陷数据。通过分析历史数据，可以估计出程序中缺陷的个数。通过把当前项目的数据??的质量情况。这样就能决定是否需要增加一些缺陷排除步骤。

缺陷率的预测。当开发一个新的程序时，可能会觉得很难估计你将引入多少缺陷，理由是缺陷的个数因程序的不同而不同。缺陷个数不稳定是有以下几个原因造成的。首先使经验问题，个人的技能是在不断提高的。开始编程序时，要面临着很多以前没有碰到过的问题。往往不能确定有些过程和函数是如何执行的，可能是语言的结构不清楚或者可能会遇到新的编译器或编程环境的问题。这些问题都会引起开发时间和缺陷路的波动。有了经验后，你将逐渐克服这些问题，犯的错误就减少了。这既减少缺陷的总数又减少缺陷数目的波动。缺陷的减少起初是由于经验的增加和对语言熟练程度的提高。经过这最初的提高后，就需要收集和分析缺陷数据来进一步改进了。

缺陷路波动的第二个原因是个体过程不稳定。当开始学习写程序时你也同时开始学习使用新的过程和方法。你的过程将随着实际的经验不断的发展，这就会引起完成不同程序任务的时间和引入缺陷的数据的波动。

最后，缺陷本身也是这种变化的原因，引入的缺陷越多，修复这些缺陷所花时间就越长。修复缺陷所花的时间越长，引入新的缺陷的几率也就会增加。因此缺陷的修改时间变动幅度很大。所以，很难对一个引入很多缺陷的过程进行预测。

随着开发过程的改进，过程会逐步稳定下来。这种稳定将提高缺陷预测的准确性。试验证明，如果在代码复查方面花了足够的时间，你的过程会迅速稳定下来。一旦你的过程相当稳定，缺陷也将容易预测。

根据对最近的程序跟踪每千行引入和排除的缺陷数，就可估计出在将来的程序中可能引入和排除的缺陷数。

以下哪一种选项不属于软件缺陷

1.基于“测试阶段”的原则：　　每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。　　2.基于“测试用例”的原则：　　测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。　　3.基于“缺陷收敛趋势”的原则：　　软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。　　4.基于“缺陷修复率”的原则：　　软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。 5.基于“验收测试”的原则：　　很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试;如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。　　6.基于“覆盖率”的原则：　　对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。　　7.基于“项目计划”的原则：　　大多数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员(开发，管理，测试，市场，销售人员)达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。　　8.基于“缺陷度量”的原则：　　这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。　　9.基于“质量成本”的原则：　　一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是：人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug 的成本还高，也可以终止测试。 10.基于“测试行业经验”的原则：　　很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。