软件测试工作流程：
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提交完毕后，并不是就万事大吉了，后续跟踪验证等还多着呢。
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ：24596024