寄予你肆意心动
软件公司用什么bug测试工具
你是说BUG管理工具吗？开源免费的有：mantis,bugzilla,redmine，禅道。
前两个是专门的BUG管理工具，后两个还有项目管理的功能。
要花钱的有：JIRA,QC,ClearQuest。
建议从开源的中选取你需要的。
只是BUG管理的话，用开源的已经十分够用了。
如何写一个强大的bug测试报告
在报告中说“不好用”；所报告内容毫无意义；在报告中用户没有提供足够的信息；在报告中提供了错误信息；所报告的问题是由于用户的过失而产生的；所报告的问题是由于其他程序的错误而产生的；所报告的问题是由于网络错误而产生的；简单地说，报告bug的目的是为了让程序员看到程序的错误。
您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。
如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。
当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。
所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是程序员的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。
除此以外，请记住：如果是，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。
“程序不好用”程序员不是弱智：如果程序一点都不好用，他们不可能不知道。
他们不知道一定是因为程序在他们看来工作得很正常。
所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。
他们需要信息，报告bug也是为了提供信息。
信息总是越多越好。
本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。
不同的程序员会喜欢不同形式的bug报告。
如果程序附带了一套报告bug的准则，一定要读。
如果它与本文中提到的规则相抵触，那么请以它为准。
如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。
）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。
“演示给我看”这些可能还不够。
也许他们觉得还需要更多的信息，会请您重复刚才的操作。
他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。
他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。
如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。
但是最重要的是在程序出错的时候让程序员在电脑旁。
一旦他们看到了问题，他们通常会找到原因并开始试着修改。
如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。
当他们亲眼看到错误时，就能够进行处理了。
“哪儿出错了？在我看来一切正常哦！”如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。
有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。
特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。
不要以为您看不出任何意义，它就没有意义。
错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。
给错误消息编号是因为用语言描述计算机错误常常令人费解。
用这种方式告诉您错误的所在是一个最好的办法。
如果您使用UNIX系统，程序可能会产生一个内核输出（coredump）。
内核输出是特别有用的线索来源，别扔了它们。
另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发之前最好先问一下。
还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。
游戏盒软件测试注意项 怎样找出更多bug
测试一般来讲都是根据测试用例来进行的，这是根本。
但是当一个人面对上千条甚至上W条的用例就可能由于烦操感而导致用例执行的不仔细，认真，这里就是一个非常重要的问题，如何在面对庞大的工作还能保证一个良好的心态就是最重要的，同样跑一份用例，我就见过一个人只能找出10几个Bug，而另外一个找出40多个Bug，而且他们都是按照测试用来进行的，有的公司没有测试用例，那么你就需要按照界面的顺序，，对于每个显示的内容，及可点击的功能点，进行无遗漏的测试，还有BUG发现最多的地方一般就是异常状态，例如你使用软件的时候突然关机，然后在开机软件会不会有什么异常之类的，这个只是个简单的例子，经验也是非常重要的。
游戏测试有些不太一样，游戏经验丰富的玩家可能会相对容易的找出一些Bug，但是根本的东西都相差不多~~ 纯手打，累死了= =
一个人做一个软件时挑bug与测试所须的时间大概是做整个软件时间的...
1.严格按用例执行；2.如果是作随机测试时，把测试步骤的点进行速记；3.偶发BUG一般都是严重的，保留现场，让开发人员一起分析留下的现场（如数据的变化，界面窗口的变化等，找出问题的引子，那怕是千丝万缕，只要有一线希望，都要与开发人员一起分析，千万别关机（关机后再重启很多现场已破坏，不少数据是保存在闪存中的）。
4.最好的做法：要求开发打开trace，测试版本在执行时能自动把测试的路径，或触发的消息等输出到文件，相当于软件的执行log，这个log对解决偶发问题将大有裨益。
5.即使一时没有重现，一定也要录入故障库，并标明发生的概率。
在日后不同的迭代版本中进行跟踪验证，并把验证的路径写上。
软件测试工程师通常用的是什么软件
常用的软件测试工具一般是：QTP+LoadRunner+QC软件测试中还需的工具如下：功能测试工具：QTP(HP),WinRunner(MI),Robort(IBM),QARun(Compuware)性能测试工具：LoadRunner(HP),WAS(MS),Robort(IBM)【必须下载相应的插件才支持性能方面的测试】，QALoad(Compuware)测试管理工具：TestDirector/Quarlity Center【这两个工具一个横版一个竖版，功能完全一样】，Rational TestManager缺陷跟踪工具：Bugzilla、Mantis其他：Rational Purify、Rational PureCoverager一般测试流程：需求分析阶段：只要就是对业务的学习，分析需求点。
测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
《测试方案》编写完成后也需要进行评审。
测试方案阶段：主要是对测试用例和规程的设计。
测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。
这时开始编写用例才能保证用例的可执行和对需求的覆盖。
测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。
其中操作步骤和预期结果需要编写详细和明确。
测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。
同样，测试用例也需要评审。
测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档
