测试人员的思想理念和工作方法.docxVIP

测试人员的思想理念和工作方法 　　 软件测试的前提假设 　　测试人员进行软件测试的基本假设是“有罪推断” ，即认为被测程序一定是有bug的，而且每个功能点的实现都存在bug，而且一定存在严重的bug。 请牢记这个假设 ，一旦在日后的 工作过程中产生了这样的认识：“这个功能很简单，肯定不会出现问题，就不再测试了。”或者“这个功能上一轮刚测试过，当时就没有问题，这一轮应该也不会有问题，就不用测试了。”等等诸如此类的意识，那么 你就有90%的概率导致漏测 ，造成线上问题。其原因也正是这个测试工作的基本前提假设，一旦被违背就从开端导致了测试工作存在问题，所以真正出现问题的可能性也就很大了。 正因为软件测试的这个前提假设，在导致了如果我们同开发人员看待程序的角度和出发点完全不同。因为，通常情况下一个有自信心的开发人员不会认为自己写的代码全部都有问题，他一定是认为自己的代码没有问题了才交付测试的。因此，如果要从事软件测试工作，那么就必须牢记并运用该假设。 这个前提假设要求我们在实施测试的过程中不能放过任何一个细小问题。比如，某个程序运行时在控制台打印了一些错误信息，但是实际上该程序的运行和功能都没有问题，如果我们摒弃有罪推断的假设，从合理实现的角度去分析，那么就可以认为这是开发人员对于 日志打印的输出控制没有做好导致的，属于微不足道的小问题，不需提出即可。于是，这就使你有90%的可能性错过了发现其编码上的异常分支判断错误导致的重大问题。此类案例更常见与那些小概率问题，即在测试过程中偶尔出现，但确实很难、甚至无法复现的问题，如果我们同样摒弃有罪推断的假设，这些问题也会从我们手边溜走，跑到线上由用户发现。相信诸如此类的教训在每一个测试人员那里都不是少数。 所以， 请转变思维，牢记这个假设 。 　　测试工作的开展思路 　　从需求出发 　　无论什么样的软件产品，其设计开发的目的必然是为了满足一定的需求，这种需求或者是用户提出的，或者是某个关联系统提出的。因此，软件产品最终是为了交付给用户使用的，也因此可以满足需求是对于软件产品质量的基本保证，其它如扩展性、维护性等等其实也算是更为广义的需求。 所以，我们开展软件测试工作必须从需求出发。首先要全面了解需求，包括其背景、关联性、用户特点等；其次要深入挖掘隐含的需求和关联，包括某个需求隐含了对于系统现有功能的修改等等。 我们只有在全面、深入了解需求的基础上，才能设计全面、有效的 测试用例来进行测试，以满足对于软件产品满足需求的基本质量保证。 　　测试依据是测试设计 　　我们进行测试设计的依据是对于软件产品需求的全面和深入分析，但是需求决不全是软件测试的依据。因为我们不仅要验证需求，而且要验证设计。比如程序实现的异常（指针越界、字符串copy越界等等）判断，是保证软件产品可以正常运行的必要实现，但是我们在需求中是无法描述和分析出来的。 那么进行测试的依据是软件产品的设计或者是代码吗？当然也不是，因为如果依据开发人员的设计或代码来进行测试的话，设计或代码正确，但是不符合需求逻辑的错误就无法发现。而且，如果依据设计或代码进行测试的话，那么也就违背了我们进行软件测试的基本假设——有罪推断。 所以，我们进行软件测试的依据应该是我们根据对需求的全面深入分析和对设计实现的了解，两相综合产生的测试设计。 正因为如此，测试是否充分和有效的根源也是测试设计。所以，我们的工作重点也是测试用例设计。 　　测试人员只是验证质量 　　首先要明确的是测试人员无法保证软件产品的质量，软件产品的质量是通过参与软件过程的各方联合共同保证的。 有两个原因：一、由于软件测试人员不是产品设计人员和开发人员，所以无法做到比他们更了解产品需求和产品设计，如果他们都无法保证需求和设计没有问题，那么测试人员就更无法保证了；二、软件测试位于 软件开发生命周期的末端，如果依靠测试人员来发现所有的bug来保证质量的话，那么风险就会后置，导致问题修复的成本增加，同时也增加了修复问题带来新问题的风险，因为在项目末端是不可能投入过多的成本来进行那怕接近全面覆盖的测试的。 也正因为如此，我们是无法决定一个软件产品质量的好坏的，只有PM设计出产品需求，RD编码完成，我们才能够通过我们的工作，促进PM、RD改进他们的产品、系统，从而达到产品、系统的高质量。 所以，我们才要参与需求评审和设计评审，大家一起努力，各个阶段由专业化的人员来保证阶段的质量，将问题尽量在前期发现。而测试人员只能根据前期分析的结果，设计出测试用例，来验证软件产品在事先设计或后续补充的测试用例上不存在问题。 但是“测试人员只是验证质量”决不是指我们可以不为产品质量负责。 因为大家（PM、RD、QA、OP等）工作的最终目标是产品质量保证，这个目标是大家共同的目标，所以每个人都必须为这