软件测试的流程是什么？bug具体是什么？怎么提交？
软件测试的流程：
1、根据软件设计需求制定测试计划，测试数据和测试用例。
2、搭建测试环境、执行测试用例。
3、提交测试报告。
4、跟踪Bug修改情况，不断测试完善产品。
5、产品的其他方面测试。
以下是作为一名测试工程师的日常工作：阶段：编写测试计划，测试用例、测试缺陷报告，并执行测试用例，搭建Windows测试环境，熟练使用Bugzilla提交软件缺陷报告 至于为什么嘛，当然要一步步来的，要有计划才能执行啊，大概是这样吧 ^_^ 使用测试技术及工具：白盒测试和黑盒测试 Loadrunner、Winrunner 能够运用边界值、等价类划分法、因果图、状态图、大纲法等测试方法设计高效测试用例 软件测试工作总体流程图：
详细测试步骤： 1. 书写测试计划 2. 审核测试计划，未通过返回第一步 3. 书写测试用例； 4. 审核测试用例，未通过返回第三步 5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例） 6. 测试过程中发现bug，将bug填写在bugzilla上发给集成部经理；（bug状态NEW） 7. 集成部经理接到bugzilla发过来的bug 7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）; 7.2 对于不是bug的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改; （bug状态RESOLVED，决定设置为INVALID）; 7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改；（bug状态RESOLVED，决定设置为REMIND） 8. 开发人员接到发过来的bug立刻修改;（bug状态RESOLVED，决定设置为FIXED） 9. 测试人员接到bugzilla发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有REOPENED的测试用例）； 10. 如果复测有问题返回第六步（bug状态REOPENED） 11. 否则关闭这项BUG（bug状态CLOSED） 12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务； 13. 本轮测试中发现的错误有98%经过修改并且通过再次测试（即bug状态CLOSED），返回第五步进行新的一轮测试； 14. 测试任务结束后书写测试总结报告； 15. 正规测试结束进入非正规测试，首先是ALPHA测试，请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员，测试人员以正规流程处理bug事件； 16. 然后是BETA测试，请用户代表进行测试。发现bug通知测试人员，测试人员以正规流程处理bug事件。
是否可以解决您的问题？
软件测试工作流程：
1、需求分析、需求评审需求分析和评审就是分析客户的需求可不可行，需要怎么进行测试。
2、编写测试计划编写测试计划通俗一点讲就是什么人在什么时间做什么事，最后产出什么东西。那也就是测试人员要测试哪些模块、在什么期限内，提交哪些文档。
3、编写测试用例、用例评审测试用例就是指导测试的文档，比如我们要测试商城登录、买东西等功能，通过测试方法和策略设计测试用例。评审就是评价审查，不能想当然该怎么测。不能只是输入正确的用户名和密码，能登录进去就完事了。
作为软测工程师需要有破坏性，比如密码输错时怎么办，会不会有相应的报错等等。
4、执行测试、提交bug、回归测试Bug就是缺陷，发现bug之后，要提交给开发人员让他们去修改，然后进行回归测试，验证开发人员有没有改好。
5、编写测试总结报告Bug都改好了之后，要编写测试总结报告，这款软件的质量如何。
Bug的标题和详细描述:
标题主要是对你所提交的Bug进行简明扼要的描述；
详细描述是对Bug进行进一步详细的描述，例如在什么情况下发生等；也可以直接将标题作为描述部分。
两者都是为了让查看Bug的人员很清楚的知道你所表达的意思。
Bug测试环境：
在什么环境中发现的这个bug，例如：什么系统，哪个版本等。对于bug环境的描述可以通过简单的罗列即可（精简为主）
扩展资料：
软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。
对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。
参考资料：百度百科-软件测试
1.软件测试流程:需求了解,测试计划,测试设计,测试用例编写,测试执行,bug管理跟踪,测试报告生成.
2.bug:测试过程中发现的程序缺陷,可以指需求上的,也可以指功能,性能上的.
3.bug提交有多种方式,可以通过测试管理工具来管理bug,比如QC等.
4.bug的生命周期: 发现bug,修复bug,关闭bug.
简单跟你讲下吧，
1.软件测试流程，一般是这样：需求了解——测试计划——测试设计——测试用例编写——测试执行——bug管理跟踪——测试报告生成
2.bug就是测试过程中发现的程序缺陷，可以指需求上的，也可以指功能、性能上的
3.bug提交有多种方式，可以通过测试管理工具来管理bug，比如QC等
4.bug的生命周期： 发现bug（open）——修复bug（fixed）——关闭bug（closed）
软件测试的流程：
1）项目经理通过和客户的交流，完成需求文档，由开发人员和测试人 员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合 开发人员，测试人员以及客户的意见，完成项目计划。然后 sqa 进入 项目，开始进行统计和跟踪 2）开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或 者双方理解不同的地方。测试人员完 成测试计划文档，测试计划包括的内容上面有描述。
3）测试人员根据修改好的需求分析文档开始写测试用例，同时开发人 员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写 测试用例的补充材料。
4）测试用例完成后，测试和开发需要进行评审。
5）测试人员搭建环境
6）开发人员提交第一个版本，可能存在未完成功能，需要说明。测试 人员进行测试，发现 bug 后提 交给 bugzilla。
7）开发提交第二个版本，包括 bug fix 以及增加了部分功能，测试人员进行测试。
8）重复上面的工作，一般是 3-4 个版本后 bug 数量减少，达到出货 的要求。
9）如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
在传统的 bugzilla 中，bug 描述应该包括以下的信息
① 和 bug 产生对应的软件版本
② 开发的接口人员
③ bug 的优先级
④ bug 的严重程度
⑤ bug 可能属于的模块，如果不能确认，可以用开发人员来判断
⑥ bug 标题，需要清晰的描述现象
⑦ bug 描述，需要尽量给出重新 bug 的步骤
⑧ bug 附件中能给出相关的日志和截图。
高质量的 bug 记录就是指很容易理解的 bug 记录， 所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
希望对你有用！
软件测试的流程是什么
需求分析：了解软件需求，分析测试点，生成需求规格说明书
测试计划：编写整个测试计划，在这个过程中需要参考需求规格说明书，这个阶段一般情况下是测试主管编写。包括了参与测试人员，测试时间安排，测试工具，测试方法等。
测试用例编写：编写测试用例，并对测试用例进行评审
用例执行：首先搭建环境，准备好测试数据，进行预测，预测通过后，按照测试用例进入正式测试
缺陷管理：记录bug并跟踪，直至bug被修复
测试报告：写测试报告，对整个测试的过程和版本的质量做一个评估
缺陷管理流程：发现bug（new）->激活bug（open）->修复bug（fixed）->再次激活（reopen）->关闭bug（close）
bug具体是什么？
bug就是漏洞，错误。其实bug就发生在我们身边，比如我们操作微信的时候微信闪退，比如说我们去淘宝购物，商品价格是1元，实际确扣了你99，本身是99最后扣了1块钱，再或者你玩一款游戏，这个游戏上线之后再下线，装备丢了，你可以看到，这就是bug。软件测试是要避免这些bug出现，对用户造成损害，对用户造成影响，这是软件测试要做的事情。
如何提交bug？
提交bug时描述的越详细越好。随着测试管理工具的完善、利用，提交bug时很多项系统已帮我们自动实现了，如提交者姓名、提交日期等。但有些项仍然需要我们自己填写。如摘要、操作步骤、预期结果、输出结果等。
提交bug一般都要包含的信息的表格，根据实际项目的不同，需要适当进行增加：如硬件配置、测试环境等。
bug信息包含：编号、摘要、预置条件、操作步骤、预期结果、实际结果、概率、严重等级 、 版本、测试者、测试日期 ……
摘要：要求用一句简短的话概括出提交的问题；
预置换条：也就是我们的测试环境，出现某一问题时的先决条件，如果没有说明则为默认情况；
操作步骤：最好使用傻瓜式，一步步地把具体操作步骤详细的描述出来；
预期结果：我们预期的正确输出结果是什么样的；
实际结果：实际的输出结果是什么样的；
提交bug的一些注意事项：
1． 发现一个问题时，不必急着提交，可以先做验证（包括复现、对比测试等）进行证实，看是概率性问题还是每次必现的问题，需要时也应使用不同版本不同机器做对比验证，当然，如果已经很确信是一个bug了，也就不用浪费时间去对比验证了。
2． 描述要清晰、准确。关于这点，如测试游戏时，提交一个bug描述为“游戏帮助说明中有错别字”，并没有说出哪一页哪一行以及具体哪个字错了，应该修改成什么样的。因此就不能说是个好的描述。下面一些bug描述如“蓝牙的名称显示错误”、“插充电器无提示”之类的则就不是一个明确的描述了。
3． 要考虑开发人员的感受，有些问题尤其是有些主观性比较强的问题，在问题描述中一般不要出现带强烈感情色彩的词语标点符号，如“要求”、“必须”和感叹号等（特殊情况除外）。在提交此类问题时可以使用一些诸如“建议……”、“希望……”、“请……”之类比较委婉些的词语。
4． 不能确认一个现象是不是一个bug的时候可以向其他人或者开发人员进行确认，然后再去提交；
5． 概率性的问题，测试过程中难免遇到一些概率性问题，很难找出其产生的规律，甚至该问题在测试过程中只出现一次，对于此类问题也一定要提交，并补充说明无法复现或者无规律；
6． 描述问题时，要实事求是，不要夸大，比如概率性问题，本来出现的概率只有10%，你把它写成50%都是不应该的！
7． 提交bug时，应该在描述清楚问题点的时候把正确的预期输出结果写明，即正确的结果应该是什么样的，这点很重要。现在我们提交的bug中有些测试和开发双方都知道该修改成什么样子了，而在bug描述中未写出修改成什么样子的，如“来电时按挂机键不能拒接来电”这样描述一个bug，并没有写明该如何修改，一般这样描述大家一看就知道该如何修改，所以写不写预期正确结果大家都可以接受。但对于有些bug的描述一定要把预期的正确结果给写进去，否则开发人员会无所适从，不知道该修改成什么样子的。
8． 如果语言文字难以清楚的描述出问题，最好能附件图片或者log记录等做辅助说明。
9． 提交测试bug的时候，如果该问题在某一特定环境下才能出现，一定要将该问题产生的环境（硬件、软件）描述清楚；
10． 提交问题前要清楚的知道软件需求、规格定义。相信很多人都遇到过这样的尴尬情况，提交了一个重要问题后，却被告知其实那并不是一个问题，软件就是那样设计的或者需求就要求那样处理的。真是没面子！
11． 有些问题出现了，不一定就是我们测试软件本身的问题，也可能是其他一些问题导致的，如“手机通话时自动掉线”问题，这有可能是信道切换失败导致的，是网络的问题，不是我们手机本身的问题。类似情况还会很多，这都我们有着丰富的产品背景知识。
12． Bug提交完毕后，并不是就万事大吉了，后续跟踪验证等还多着呢。
答：软件测试工作流程：1、需求分析、需求评审需求分析和评审就是分析客户的需求可不可行，需要怎么进行测试。2、编写测试计划编写测试计划通俗一点讲就是什么人在什么时间做什么事，最后产出什么东西。那也就是测试人员要测试哪些模块、在什么期限内，提交哪些文档。3、编写测试用例、用例评审测试用例就是指导测试...
答：软件测试的5个基本流程:1、需求分析、需求评审。2、编写测试计划。3、编写测试用例、用例评审。4、执行测试、提交bug、回归测试。5、编写测试总结报告。软件测试模型：传统：项目计划——需求分析——软件设计——程序开发——软件测试——集成维护V模型：需求分析-概要设计-详细设计-软件编码-单元测试-集...
答：执行测试：根据测试用例的详细步骤，执行测试用例。执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。缺陷跟踪：追踪leader分配给你追踪的bug.直到被修复。测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug。软件测试方法：从测试设计的方法...
答：1、测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议。2、测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。3、...
答：划分方式一：功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、文档错误、兼容问题、用户体验、其它。划分方式二：功能类、性能类、界面类、易用性类、兼容性类、其它。找到BUG后，那么，就要对BUG区分等级，以便开发人员，根据BUG的优先级来处理BUG，优先解决...
答：高质量的 bug 记录就是指很容易理解的 bug 记录， 所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。我们公司一直使用日事清来进行软件测试bug。日事清是一款简单易用的软件测试管理，它能够合理让员工规划软件测试工作日程，让管理者及时掌握测试员工工作饱和度、软件测试工作进展...
答：软件测试的流程一般是这样的：需求评审-需求定稿，测试人员理解需求-测试组长发布测试计划-测试人员进行测试方案的编写及评审-测试人员根据测试方案定稿进行测试用例的设计及评审-测试人员根据测试用例进执行测试用例-发现问题bug提交-确认bug修复，关闭bug-编写测试报告及总结-编写安装文档或者使用手册-结束。基本...
答：Bug***严重级别(Severity，Bug级别) ：是指因缺陷引起的故障对软件产品的影响程度，由测试人员指定。| A-Crash | 造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失 | | B-Major | 系统的主要功能部分丧失、数据不能保存，单个功能失效导致多个相关功能均失效 | | C-Minor |...
答：5、执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--everytester(主要是初级测试人员)6、defecttracking：追踪leader分配给你追踪的bug.直到bugfixed。--everytester 7、测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.8、用户体验、...
答：软件测试的流程：1、根据软件设计需求制定测试计划，测试数据和测试用例。2、搭建测试环境、执行测试用例。3、提交测试报告。4、跟踪Bug修改情况，不断测试完善产品。5、产品的其他方面测试。
