测试其实可以很简单

tomzhang

测试其实可以很简单
测试的目的就是尽可能多的发现bug，发现bug是它唯一目的；
那么如何发现bug呢？这就需要一些理论知识，这些在课本里有都介绍，我想重点强调的就是思路和态度(严谨)。
还有就是需要一些工具，工具是否必须？我个人持保留看法，据说LR一套要花上万美元，不过它还是比较值的；而QTP也要花不少银子，我倒觉得挺怨的。
能够发现bug，那为什么同样的bug老是重复出现？这可能就是软件版本的问题了，1个bug在企业版里修正了，可没有在专业版里修正。解决这个问题，要从版本管理和测试库的管理2方面入手，对于测试而言，bug一定要入库，有特点的bug一定要向帖子一样置精，开发人员往往不会收集问题的解决方法，这需要测试人员来督促来补充。
测试完了，就要要向开发组交差，这就要提供一些数据，一些报告，这些各个公司都会有各自的模板。
如果测试通过后交付到用户那里，用户仍然发现bug了，测试组往往需要承受巨大的压力，但是不必太较真，没有bug的软件是不存在的，觉得自己已经做好了自己的工作就可以了。
这是我个人的拙见，欢迎大家拍砖。我的QQ是：896219716，如需加我，请注明来自51Testing。

peag

~~对你的言论我保留意见~

msnshow

简单与复杂都是相对的，把一项工作，细化之后都是非常简单的

bestgo

以前看书，也是说测试的主要目的是发现软件中的缺陷，但是工作一段时间后，看法有所改变，那就是书上说的东西实践起来很难，只能说有指导意义。
在企业里做软件开发，最先要求的是软件能用，最基本的功能要保证在发布时绝对是没问题的，有一些小缺陷可以原谅。往往一个项目，最后是带着不少已知问题出去的。往往在编码人员修复一个问题后，又引入了新的缺陷，而新引入的缺陷是致命的，但是由于测试资源紧张而导致最终带入了正式发布的版本。回归测试的疏忽并不少见，往往在手工测试的多轮回归之后出现这种情况。
比较正规的项目在开始都会有一个测试用例，这个测试用例到项目结束时应该也是有效的（不是在项目结束时软件的实现和设计之间已经相差十万八千里了），测试人员首先要保证测试用例上的所有内容都没问题，然后再谈其他。我的经验是通常等到这步，项目经理就迫不及待地发布版本了，不会剩多少时间让测试人员去进一步寻找软件缺陷了，说不定下个项目正等着开始呢。