软件测试BUG的判断依据有那些？

软件测试BUG的判断依据有那些？

1、查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础，才能更好地定位问题。

2、查看数据库的数据，了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。

3、查看缓存（如Memcache、apc、redis等缓存）是否正确。

扩展资料：

快速发现bug方法

1、尽快熟悉公司的产品业务，根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。

2、不用让程序开发员＂用户不会这样操作＂的观点说服自己，遇到这样的情况，要坚持自己的正确的观点，把这种现象作为一个Bug。

软件缺陷度量方法简述

1.原则上来讲，我们更希望一种规范化开发的体系来规正这个命题，不需要为此伤脑筋。但在里程碑或计划的截止时间点能结束测试对大多数的软件项目仅仅是一种期望，而不是既定的现实。理想的情况下，我们可以严格执行计划，然后在计划要求的deadline或者里程碑点上提交交付件，以确认该里程碑是否达到要求，是否可以进行下一阶段的工作——但正如前提所言，这个仅仅是理想情况
2.现在让我们现实一点。我们为什么会有这样的问题(一个软件如何确定测试结束点)？往往就是因为我们不知道何时可以结束一个软件的测试。不管教科书上如何说明一个软件只要还在生命周期内，就无法结束测试，但现实要求我们在某一个时间点上，结束对软件某一阶段的测试。那么，这个问题实际上就已经转化为确定该阶段测试的结束点的方法了。这个方法可能是一种规范，一套流程，一些交付件，一些评审，一些由统计学原理得出的收敛曲线或者仅仅只是一些确认而已。而个人认为，无论这个方法是何种形式的，其基本的要求就是能达成一种协议，确认该协议生效——那么这个阶段的测试就结束了，至于这个点在什么时间，我想就是完成所有要求的这些确认的时间而已。
在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定：：
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.基于“测试行业经验”的原则：
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用

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

缺陷表现如下：
软件没有做需求中要求它做的事情；
软件做了需求中要求它不应该做的事情；
软件做了需求中没有提到过的事情；
软件没有做需求中没有提到但是它应该做的事情；
软件难于理解和使用，运行缓慢，或者从软件测试人员的角度来说，软件对于最终用户是明显的不健全（不正确）的。

测试中指出软件缺陷后,就可以提交测试结果报告对吗

测试中指出软件缺陷后,就可以提交测试结果报告对。软件的缺陷处理流程要经过提交、分配、确认、处理、复测、关闭等环节。所以，测试中指出软件缺陷后,就可以提交测试结果报告对。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

软件测试缺陷 流程

先介绍下缺陷的状态：
新建、打开、拒绝、已修复、重新打开、关闭、
特殊情况：BUG延迟修复 在达到可以修复时间点时重新打开。

不同的管理工具和测试流程 BUG的流程会有稍许差异
一般为：新建——打开——已修复——关闭（或重新打开——已修复——关闭）

在软件测试中，哪些软件问题被称为软件缺陷

一.软件缺陷的正式定义：
符合下边5个规则的才能叫做软件缺陷。
1.软件未达到产品说明书标明的功能。
2.软件出现了产品说明书指明不会出现的错误。
3.软件功能超出产品说明书指明范围。
4.软件未达到产品说明书虽未指出但应达到的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
参考
http://www.spasvo.com/baike/504.html

it项目管里单元测试可以发现多少软件缺陷

it项目管里单元测试可以发现80/20软件缺陷。

由于有太多的输入组合、有太多的路径，而且时间是有限的，无法做到完全的测试（100%测试覆盖率）。通过运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。

开发计划：

主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

软件项目管理过程从项目计划活动开始，而第一项计划活动就是估算：需要多长时间、需要多少工作量、以及需要多少人员。此外，我们还必须估算所需要的资源（硬件及软件）和可能涉及到的风险。

为了估算软件项目的工作量和完成期限，首先需要预测软件规模。度量软件规模的常用方法有直接的方法——LOC（代码行），间接的方法——FP（功能点）。这两种方法各有优缺点，应该根据软件项目的特点选择适用的软件规模度量方法。

软件缺陷的处理流程是怎么样的

简单的概括如下:
1.
找到缺陷后,
记录缺陷的各方面信息(如:日志,
图片,
测试步骤,
是否能重复等等).
2.
提交缺陷报告.
3.
跟踪这个缺陷,
看其何时修复.
4.
当缺陷修复后,
再对其进行测试.
并对因这个缺陷而受影响的其它功能进行测试.(如果没有就不测)
5.
如果这个缺陷测试通过,
关闭这个缺陷报告.
如果没有通过,
则再次指回修复缺陷人员,
重新修复.
(以此循环,
直到缺陷修复或者其它结论)

一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

一个缺陷报告必须包含以下核心要素：
1）测试环境
2）软件版本
3）缺陷标题（问题描述）
4）测试步骤
5）期望结果
6）实际结果
7）详细日志及界面截图
一篇高质量的软件缺陷记录应该考虑一下方面：
1) 通用ui要统一、准确
缺陷报告的ui要与测试的软件ui保持一致，便于查找定位。
2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4) 不可重现的缺陷也要报告
首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
5) 明确指明缺陷类型
根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
6) 明确指明缺陷严重等级和优先等级
时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（ui）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
9) 每一个步骤尽量只记录一个操作
保证简洁、条理井然，容易重复操作步骤。
10) 确认步骤完整，准确，简短
保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
11) 根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
 附加必要的特殊文档和个人建议和注解
如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
12) 检查拼写和语法缺陷
在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
13) 尽量使用短语和短句，避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。
以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。
14) 缺陷描述内容
缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

以上就是学分高考的小编对软件测试BUG的判断依据有那些？，以及软件测试BUG的判断依据有那些？的详细介绍与分析，相信大家看完之后都已经对这方面有了更详细的认识与了解。