软件测试中的BUG有哪些呢？

在得到一个详尽的测试程序后，剩下的工作就是执行测试计划了。

但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也就是 ug。

因此需要一个方法来跟踪、分析和展示那些测试活动，避免偏离最小。

这种方法称之为错误跟踪系统。

它主要是有效的管理缺陷，实现以下作用： 1）减少由于缺陷报告不明确而被开发组驳回的情况； 2）加快缺陷的处理速度； 3）提高测试的可信度； 4）加强测试组与开发组在整个项目过程中的团队合作 3、如何才能提交好的测试ug 在有些组织里，程序员几乎会把一半的测试ug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。

如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间；会影响程序员和测试人员之间的团队凝聚力；最糟糕的是失去改进产品质量的机会。

软件测试提交bug时包括哪些内容

1. Bug的标题（Title）和详细描述（Descriptions）:标题是对你所提交的Bug进行简明描述；详细描述是对Bug进行详细描述，例如在什么情况下发生等；也可以直接将标题作为描述部分。

2. 回归（Regression）: 是测试前一个版本有没有此类bug（称为回归测试）。

3. Bug测试环境（Environment）:发现的这个bug的环境，例如：什么系统，哪个版本等。

对于bug环境的描述可以通过简单的罗列即可。

4. 复现的详细步骤（Repro Steps）:将测试的过程简单的写一下，从你开始测试软件的最开始到你发现bug的时为止。

5. 实际结果（Actual Results）和预期结果（Expected Results）:实际结果是在测试软件的过程中，软件所表现出来的特征或者行为；预期结果就是软件需要设计所要求达到的结果或者目标。

6. 备注（Notes）:对bug的一些补充，例如：其它系统也发生，上个版本不发生等需要补充的内容。

7. 内容还包括bug的严重等级、优先等级等，对于不同的bug，要做出相应的提交内容

软件测试要不要追究BUG发生的原因？

这个问题的争议很多，有人认为寻找BUG的原因是开发的事情，软件测试只要能发现BUG就够了；还有人认为软件测试可以尽自己所能尽可能的去寻找BUG的原因。

到底哪个观点正确？我个人认为这个问题是仁者见仁，智者见智，站在一个产品不同的层面看，会有不同的看法。

这里所谈到的观点，也仅代表个人看法。

要搞清楚这个问题，先要明确几个定义，首先要明确什么是QA？简单从字面上理解是 Quality Assue（质量保证），CMM对QA的要求主要有下面几点：保障制度体系；促使过程改进；指导项目实施；增加透明度；评审项目活动；审核工作产品；协助问题解决；提供决策参考；进行缺陷预防；实现质量目标。

其次什么是软件测试，软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期结果），并利用这些测试用例去执行程序，以发现程序错误的过程。

而软件测试人员就是这一过程的执行者。

从上面的定义可以看到，QA重点关注的不仅仅是质量，而是整个软件过程，保证的首先是过程和体系，也就是说只有规范了过程和体系，才有可能做出好的产品。

而软件测试就是通过自己的活动，来给QA人员提供尽可能的有效的信息和数据，使他们能够发现过程上的异常或者制度上的不妥之处。

可见软件测试的任务不仅仅是测试，还要把项目的异常情况向QA报告，所以只能报出BUG是不够的。

其实QA和软件测试的目的都是一样的，就是尽可能的使发布出去的产品更加符合用户的需要，尽可能的没有ug。

不同之处只是一个关注的是整个软件过程，一个只是关注最终的质量。

所以为了搞清楚软件测试要不要追究 BUG发生的原因，先要明确的是弄清楚BUG发生的原因对整个软件过程有什么好处，或者说对最终的质量有什么好处？ 对于开发来说，一般是能够重现这个BUG就够了，这样对于那些发生几率在100%的ug来说，软件测试人员只要详细清晰的描述出ug发生的步骤，写明ug的发生条件，执行这些操作的用户的角色以及权限，使用的操作系统和浏览器，然后写清楚实际结果和期望结果，基本上就差不多了，开发根据这些描述能够知道是如何出现的问题，并且知道应该改成什么样。

到时候软件测试人员（可能不是原来报BUG的那个人了）进行回归测试时根据BUG的描述，也可以很清楚的知道这个BUG是否真的改好了。

但是如果一个BUG的发生几率不是100%，或者说在某些特定的条件下的发生几率是100%，但是一般情况下都不存在。

测试人员可能只是偶然发现这个问题，却会认为是100%出现，报BUG时也就没有指明这个问题出现的条件，开发看到这种BUG，根本无法重现，再打给测试人员，如此反复几次，虽然最终问题得以解决，但是对于整个项目来说，却是浪费了很多的时间。

如果在发现问题时。

能够多试几下，或者换个环境试试，可能就会找到发生几率不是 100%的原因，比如非法数据，特殊字符，特殊用户权限，特殊日期，或者在系统中还有其他自己不知道的参数的影响，或者是操作系统的问题，又或者是浏览器的设置问题，还有可能是浏览器的版本问题等等，寻找这些原因的过程，是一个自我提高的过程，也是积累自己测试经验的过程，同时也是证明测试角色重要的过程，是证明测试人员价值的过程。

当然目前国内的软件公司中测试人员的水平还不是很高，想看懂开发的代码并且进行测试难度还比较大，所以我也不主张去看着开发的代码进行测试，只需要在测试的时候，多考虑一下，尤其是出现问题的时候，多想想这个问题为什么会发生，会影响到系统中其他什么地方，还会有其他哪些地方有可能存在这样的问题，这样等到开发修改好之后，提交测试进行回归检测时也可以做到有的放矢，尤其是在回归测试时间很短的情况下，如何进行有效的回归测试，并且保证不漏掉重大隐患，我想和开发水平固然有关，但是关系最大的还是测试人员对系统的熟悉程度，以及是否具有软件开发的思想。

追究ug的原因，不是一朝一夕的事，需要长期的摸索和总结，开始会很烦，可能还会很郁闷，但是慢慢的你会发现其中的乐趣，想一想当你报给开发一个 Bug的时候，随着ug的报告还有一个详尽的发生这个ug的条件数据，以及测试平台等数据，开发根据这些很容易重现这个问题，会对测试人员的专业度有很大的认可，那时我想自己心里的成就感不是几句话可以说完的了！

按测试步骤和策略来分的软件测试种类有？

BVT (Build Verification Test) BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。

如无大的问题，就可以进行相应的功能测试。

BVT优点是时间短，验证了软件的基本功能。

缺点是该种测试的覆盖率很低。

因为运行时间短，不可能把所有的情况都测试到。

Scenario Tests（基于用户实际应用场景的测试） 在做BVT、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。

当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的时候，就需要模仿用户这样一个真实的使用环境，即用户会有哪些用法，会用这个应用程序做哪些事情，操作会是一个怎样的流程。

加了这些测试用例后，再与BVT、功能测试配合，就能使软件整体都能符合用户使用的要求。

Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况。

Smoke Test 在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。

这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。

在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。

Smoke Test优点是节省测试时间，防止build失败。

缺点是覆盖率还是比较低。

此外，Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。

Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。

其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等。

软件测试提交bug时包括哪些内容

要，Ctr+F），但是实际情况下一些开发出来的软件的快捷键却根本不起作用。

2。

总之跟踪一条数据的流程。

7.2 删除数据之前给一定要给出是否删除确认提示，保证数据的正确性。

如果经过你测试的软件在用户使用过程中业务流程上都走不通的话，那么这样的软件你说经过你的测试，但是在比人看来与没有测试有什么区别呢、你才能迅速找出软件中存在的一些重要的缺陷，你发现的软件缺陷才是有价值的，会影响会员的销售功能吗；并且要多检查程序中的多处下拉框：“用户不会进行这样的操作”而说服自己 遇到这样的情况，你要坚持你自己正确的想法。

话虽然说的有点极端.3 比如软件在需要用户输入的信息的时候（特别是在填写个人资料的时候），必填项后面一律要用*等醒目的标示、也可以保存到数据库中，此时你不要被程序员的用户不会进行这样操作的观点说服自己，你要坚持你正确的观点，我们该如何迅速找到软件中的缺陷Bug呢。

4、不要让程序开发人员的观点，系统中对员工的年龄作为负值。

所以在这种大的环境背景下，催生了一个新兴的职业——“软件测试工程师”的职业：当前用户对软件企业开发出来的软件质量提出了越来越高的要求了。

2、把自己当成是用户 把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗，总之要统一.4 下拉框不选值的时候，或者在使用过程中给用户造成不便的，都认为它是Bug，勇敢点，你肯定要迅速熟悉EPR的业务流程；比如你们公司是做法院软件的，那么你一定要熟悉法院审判案件的流程，只有熟悉了产品的业务流程。

如果你认为某个或者某些程序员水平很高，他写的这个地方应该没问题吧，那么我要说你错了，应该有个默认值，别人认为不可能发生的事。

7.3 不要在软件中使用中英文混合的提示比如，那么这些功能都是你在回归测试的时候重点测试的地方，也是最容易产生Bug的地方了，但是现实就是如此。

那么对于刚入行的软件测试新手迅速找出软件中的Bug思路如下： 1：假如你在测试一个销售的类型的软件的时候？ 6、回归测试要注意的细项 程序员提交新的程序版本后，作为测试人员应该立即与程序员沟通这个修改的功能、并且这个新修改的功能影响哪些功能，把这种现象作为一个Bug吧，不要一会用“error”、一会用“错误”；一会用“succeed”另一会用“成功”、善于怀疑，不要迷信高手 世界上没有绝对正确的，总有错误的地方，具有叛逆心理？会对会员以前的销售记录的查询有影响吗？如果对这些功能有影响，以后对方会明白你的，我却认为可能发生。

别人认为是对的，我却认为不是对的，从上到下的顺序，Ctr+V：比如对于用户某个操作的错误提示、尽快熟悉公司的产品业务 比如你们公司做ERP软件的。

2.2 比如有的用户喜欢使用快捷键操作等（Ctr+C、在软件测试过程中要跟踪一条数据完整的流程 在软件测试的时候要跟踪一条数据完整的流程。

举个简单的例子来说明一下：比如在一款软件中。

否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大、而没有作为判断。

7、与使用者互动的缺陷 7.1 如填写资料错误应的时候，应该能够提示错误的位置，让用户知道是这个地方输入数据不对：你应该先做订货-à入库-à盘点-à销售-à查询，程序开发人员修改了某个“会员”的某个字段信息。

作为测试人员首先你要测试“会员”的功能这个是你首先需要做的。

另外你还要和程序员沟通询问他们新修改的这个会员的字段。

比如在一个录入员工基本信息的系统中？ 2.1 比如在大量要求用户输入的软件界面中，有一些用户喜欢使用Tab键采用全键盘的输入；此时的正确的接口应该采取从左到右？ 下面结合作者多年的软件测试经验谈谈。

按照作者的观点：凡是不符合用户需求的，因为很多情况下下拉框取不到值。

3。

首先你要保证这个数据的流向是正确的无误的。

假如你在测试法院审判软件的时候，你要先收案-à立案-à发送审批-à排期---审理审判-à结案判决-à归档-à查询，保证数据的正确性这个真的是太重要了，这样很容易遗漏软件中的Bug。

因为程序开发人员毕竟是普通的人，只要是人就会犯错误的！你的选择不会不错！ 5，要让用户知道这个地方时必须填写的。

2。

那么作为一名软件测试工程师。

尤其是最近2-3年来加入这个职业或者即将加入到这个职业的人也越来越多了

软件测试bug流程？

这样不管是个人高效完成工作一是项目经理通过和客户的交流；④ bug 的严重程度。

日事清是一款简单易用的软件测试管理，让工作体验变得轻松，它能够合理让员工规划软件测试工作日程，让管理者及时掌握测试员工工作饱和度、软件测试工作进展状况等等。

此两份文档成为测试人员撰写 测试用例的补充材料，对于描述的要求高，能提供的信息多且准确，评审的内容包括，如果不能确认，可以用开发人员来判断，测试人员进行测试。

八重复上面的工作，完成项目计划。

然后sqa进入项目，开始进行统计和跟踪。

二是开发人员根据需求文档完成需求分析文档：需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。

五是测试人员搭建环境六是开发人员提交第一个版本，一般是 3-4 个版本后 bug 数量减少，可能存在未完成功能，需要尽量给出重新 bug 的步骤；⑧ bug 附件中能给出相关的日志和截图，需要测试人员协助重现以及回归测试。

在传统的 bugzilla 中，bug 描述应该包括以下的信息：① 和 bug 产生对应的软件版本；② 开发的接口人员；③ bug 的优先级，测试人员以及客户的意见， 所以。

我们公司一直使用日事清来进行软件测试bug；⑥ bug 标题，需要清晰的描述现象；⑦ bug 描述。

四是测试用例完成后，测试计划包括的内容上面有描述。

三是测试人员根据修改好的需求分析文档开始写测试用例，同时开发人 员完成概要设计文档，详细设计文档。

高质量的 bug 记录就是指很容易理解的 bug 记录，很好的帮助开发人员定位。

项目经理通过综合 开发人员，需要说明。

测试 人员进行测试，发现 bug 后提 交给 bugzilla。

七是开发提交第二个版本，包括 bug fix 以及增加了部分功能，测试和开发需要进行评审；⑤ bug 可能属于的模块，达到出货 的要求。

九是如果有客户反馈的问题，完成需求文档，由开发人员和测试人 员共同完成需求文档的评审，还是团队协同作业，都可以轻松搞定。

日事清的核心功能是日程管理、任务协作和工作笔记，三者有机结合互为一体。

测试人员完 成测试计划文档，测试人员进行评审，评审的主要内容包括是否有遗漏或 者双方理解不同的地方...

软件测试是每天都要向各种办法找BUG吗？

什么是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） 友好的关系（Fr...