对于软件测试理论的一些个人看法：

liujun_newnew

对于软件测试理论的一些个人看法：
首先自我介绍一下：我现在是一个专业（不是指技术达到专业水平而是说除了测试不做其它工作的那个意思）测试人员，在公司的测试任务中负主要责任——当然由于我们公司不大像我这样的专业测试人员就是我一个了，其余的都是临时性的帮一下忙，而且他们也就不会使用专业的测试技术，我对测试有以下一些个人理解（大家曾提到过的我就不提了）：
1、测试是一种想尽一切办法查找软件Bug的工作。那么通过什么办法能够达到这个“想尽一切办法”或尽可能多的办法的目的呢？我认为应该是用尽可能多的角度去测试我们的软件。那么，这“尽可能多的角度”又从哪里来呢？我们知道每个人都有不同的性格和思想，看待问题的方式和角度会不同，同时思考问题的方式也会有很大的差异。所以，我想，如果能够调动一大批人来进行测试，那么在等价的时间内测试效果应该说是最全面的。所以，对于软件行业内部测试工作我产生了一个这样的想法：在最后测试阶段，调动公司所有人员进行测试，同时，测试人员从其他非测试人员身上吸取测试技巧和经验作为以后测试工作的经验。我个人认为这种测试方式在特定的时候要比纯粹利用几个高级测试技术人员进行测试的测试方式在测试全面性和效率上要高得多，而且也科学得多——当然，我并没有轻视高级测试技术人员的意思，在平时普通而长期的测试任务中，我们这些专业测试人员才是主力。而且这种集体测试形为能够给大家一个充分理解测试人员从而在以后的工作中更好的配合测试人员工作或相互配合打下基础。我想现在我们公司之所以仅安排我一个专业测试人员而只是在临时安排几个非专业人员帮一下忙，可能也包含了这样一种意思，但是公司领导层有没有从理论上意识到这一点我就无从考证了……；
待续……
大家对于我的观点或整个测试理论有一些什么看法和评论，希望大家一起多多交流，互相促进……我是最喜欢与大家一起讨论和共享思想的……

天网

我来谈谈我的一些看法：

1、关于测试的目标，已经从原来单纯的发现软件的BUG发展为除了发现BUG外，还要进行缺陷的预防；

2、用尽可能多的角度去测试我们的软件，是需要一定的测试理论来保证的，并不是人多就能保证测试的充分性和完整性。系统掌握了测试理论和测试方法的测试工程师，在进行测试分析、测试设计和测试执行的时候，会从各角度去进行测试。测试也不是只有测试执行一个阶段，在测试执行阶段安排一些临时人员来参加，最多只能在执行阶段多些观察角度，而如果前期分析和设计质量高，这些角度应该是已经包含在用例里了的。如果前期分析和设计质量低，甚至没有这些环节，完全靠执行阶段凭测试人员的灵感来测，即使人多，漏测也不可避免。

一家之言，欢迎继续讨论。

wzb521

我也谈谈我的看法：
1、在我们质量保证中，技术评审可以看成最前期的质量工作，过程保证可以看成中间期的工作，软件测试可以看成善后的工作（也许你会说，前期也有测试加入，但我这里指的测试是大家广泛理解、也应用面最广的后期测试。当然这三点是我将软件开发环节，每个环节脱离开来所确定的。）。从某个间接的角度上来说，做测试是受着广泛约束的，就像木桶原理一样，即使你测试再突出，装的水也不能超过一定的高度。所以我认为：测试并不是仅仅为了发现软件BUG，关键是如何对软件过程中发现的问题进行评估、进行总结，之后进行软件的过程改进。如果你在程序员角度多增加了一个环节，比如说：要检查MAXLENTTH、检查上下限限制等等，那你测试是不是只要验证一下就可以了，这样测试是不是简单些了呢？那好，这也可以划到过程改进中去。软件过程本身就是个：制定、执行、跟踪、评估、改进、打造，这样的循环过程。
2、我们要学会从源上去控制软件出错的机率，软件出错的根源：需求、设计、编码，试着再这些地方做手脚，也许你的测试质量会更好。当然这一切都是在测试手段已经不能再提高的基础上的。
3、学会去改变测试效率，当你埋怨开发人员打包频率很快的时候，试着规范一下，比如说软件发布规范，等等。。
4、测试理论终究是理论，再很大前提上，某些理论是建立在极其正规、极其理性化的基础上的，所以要打造自己公司的自己的测试流程。就像写测试用例一样，由于开发人员的思考是不一样的，所以再写不同人员所开发的代码的用例时，也许需要加上一些额外的用例，比如说添加的2次操作，删除的连续删除等等。

个人看法，具有盲目性，敬请谅解

liujun_newnew

虽然本人理解和接受水平有限，还是很感谢两位专家的支持和讨论。本人的观点确实存在极端性和片面性。向各位前辈高手学习。