Evo丶小寶
软件测试流程和bug生命周期？
测试一般来讲都是根据测试用例来进行的，这是根本。
但是当一个人面对上千条甚至上W条的用例就可能由于烦操感而导致用例执行的不仔细，认真，这里就是一个非常重要的问题，如何在面对庞大的工作还能保证一个良好的心态就是最重要的，同样跑一份用例，我就见过一个人只能找出10几个Bug，而另外一个找出40多个Bug，而且他们都是按照测试用来进行的，有的公司没有测试用例，那么你就需要按照界面的顺序，，对于每个显示的内容，及可点击的功能点，进行无遗漏的测试，还有BUG发现最多的地方一般就是异常状态，例如你使用软件的时候突然关机，然后在开机软件会不会有什么异常之类的，这个只是个简单的例子，经验也是非常重要的。
游戏测试有些不太一样，游戏经验丰富的玩家可能会相对容易的找出一些Bug，但是根本的东西都相差不多~~ 纯手打，累死了= =
软件测试提交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，要做出相应的提交内容
软件测试这个行业一般做什么？
以下是软件测试工程师的日常工作：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事件。
在软件测试中,如果第一次测试发现了bug,在第二次测试中是只针对...
在报告中说“不好用”；所报告内容毫无意义；在报告中用户没有提供足够的信息；在报告中提供了错误信息；所报告的问题是由于用户的过失而产生的；所报告的问题是由于其他程序的错误而产生的；所报告的问题是由于网络错误而产生的；简单地说，报告bug的目的是为了让程序员看到程序的错误。
您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。
如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。
当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。
所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是程序员的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。
除此以外，请记住：如果是，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。
“程序不好用”程序员不是弱智：如果程序一点都不好用，他们不可能不知道。
他们不知道一定是因为程序在他们看来工作得很正常。
所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。
他们需要信息，报告bug也是为了提供信息。
信息总是越多越好。
本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。
不同的程序员会喜欢不同形式的bug报告。
如果程序附带了一套报告bug的准则，一定要读。
如果它与本文中提到的规则相抵触，那么请以它为准。
如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。
）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。
“演示给我看”这些可能还不够。
也许他们觉得还需要更多的信息，会请您重复刚才的操作。
他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。
他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。
如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。
但是最重要的是在程序出错的时候让程序员在电脑旁。
一旦他们看到了问题，他们通常会找到原因并开始试着修改。
如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。
当他们亲眼看到错误时，就能够进行处理了。
“哪儿出错了？在我看来一切正常哦！”如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。
有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。
特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。
不要以为您看不出任何意义，它就没有意义。
错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。
给错误消息编号是因为用语言描述计算机错误常常令人费解。
用这种方式告诉您错误的所在是一个最好的办法。
如果您使用UNIX系统，程序可能会产生一个内核输出（coredump）。
内核输出是特别有用的线索来源，别扔了它们。
另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发之前最好先问一下。
还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。
软件测试通过了,为什么使用时还是有很多bug？
大多数测试人员认为测试工作是发现bug，虽然这是测试的主要任务，但其实测试最重要的任务是质量控制，而发现bug和验证bug只是质量控制的一个重要环节而已。
原因主要有以下几类：1. 不同版本的数据兼容2. 测试环境和正式环境的不同3. 服务器的配置所以好的测试不能只把目光放在代码层面的测试，而是要从更高的视角去看整个项目在上线发布的时候存在的各种风险。
望采纳！
