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

软件测试的前提假设

　　测试人员进行软件测试的基本假设是“有罪推断” ，即认为被测程序一定是有bug的，而且每个功能点的实现都存在bug，而且一定存在严重的bug。 请牢记这个假设 ，一旦在日后的工作过程中产生了这样的认识：“这个功能很简单，肯定不会出现问题，就不再测试了。”或者“这个功能上一轮刚测试过，当时就没有问题，这一轮应该也不会有问题，就不用测试了。”等等诸如此类的意识，那么 你就有90%的概率导致漏测 ，造成线上问题。其原因也正是这个测试工作的基本前提假设，一旦被违背就从开端导致了测试工作存在问题，所以真正出现问题的可能性也就很大了。 正因为软件测试的这个前提假设，在导致了如果我们同开发人员看待程序的角度和出发点完全不同。因为，通常情况下一个有自信心的开发人员不会认为自己写的代码全部都有问题，他一定是认为自己的代码没有问题了才交付测试的。因此，如果要从事软件测试工作，那么就必须牢记并运用该假设。 这个前提假设要求我们在实施测试的过程中不能放过任何一个细小问题。比如，某个程序运行时在控制台打印了一些错误信息，但是实际上该程序的运行和功能都没有问题，如果我们摒弃有罪推断的假设，从合理实现的角度去分析，那么就可以认为这是开发人员对于日志打印的输出控制没有做好导致的，属于微不足道的小问题，不需提出即可。于是，这就使你有90%的可能性错过了发现其编码上的异常分支判断错误导致的重大问题。此类案例更常见与那些小概率问题，即在测试过程中偶尔出现，但确实很难、甚至无法复现的问题，如果我们同样摒弃有罪推断的假设，这些问题也会从我们手边溜走，跑到线上由用户发现。相信诸如此类的教训在每一个测试人员那里都不是少数。 所以， 请转变思维，牢记这个假设 。

　　测试工作的开展思路

　　从需求出发

　　无论什么样的软件产品，其设计开发的目的必然是为了满足一定的需求，这种需求或者是用户提出的，或者是某个关联系统提出的。因此，软件产品最终是为了交付给用户使用的，也因此可以满足需求是对于软件产品质量的基本保证，其它如扩展性、维护性等等其实也算是更为广义的需求。 所以，我们开展软件测试工作必须从需求出发。首先要全面了解需求，包括其背景、关联性、用户特点等；其次要深入挖掘隐含的需求和关联，包括某个需求隐含了对于系统现有功能的修改等等。 我们只有在全面、深入了解需求的基础上，才能设计全面、有效的测试用例来进行测试，以满足对于软件产品满足需求的基本质量保证。

　　测试依据是测试设计

　　我们进行测试设计的依据是对于软件产品需求的全面和深入分析，但是需求决不全是软件测试的依据。因为我们不仅要验证需求，而且要验证设计。比如程序实现的异常（指针越界、字符串copy越界等等）判断，是保证软件产品可以正常运行的必要实现，但是我们在需求中是无法描述和分析出来的。 那么进行测试的依据是软件产品的设计或者是代码吗？当然也不是，因为如果依据开发人员的设计或代码来进行测试的话，设计或代码正确，但是不符合需求逻辑的错误就无法发现。而且，如果依据设计或代码进行测试的话，那么也就违背了我们进行软件测试的基本假设——有罪推断。 所以，我们进行软件测试的依据应该是我们根据对需求的全面深入分析和对设计实现的了解，两相综合产生的测试设计。 正因为如此，测试是否充分和有效的根源也是测试设计。所以，我们的工作重点也是测试用例设计。

　　测试人员只是验证质量

　　首先要明确的是测试人员无法保证软件产品的质量，软件产品的质量是通过参与软件过程的各方联合共同保证的。 有两个原因：一、由于软件测试人员不是产品设计人员和开发人员，所以无法做到比他们更了解产品需求和产品设计，如果他们都无法保证需求和设计没有问题，那么测试人员就更无法保证了；二、软件测试位于软件开发生命周期的末端，如果依靠测试人员来发现所有的bug来保证质量的话，那么风险就会后置，导致问题修复的成本增加，同时也增加了修复问题带来新问题的风险，因为在项目末端是不可能投入过多的成本来进行那怕接近全面覆盖的测试的。 也正因为如此，我们是无法决定一个软件产品质量的好坏的，只有PM设计出产品需求，RD编码完成，我们才能够通过我们的工作，促进PM、RD改进他们的产品、系统，从而达到产品、系统的高质量。 所以，我们才要参与需求评审和设计评审，大家一起努力，各个阶段由专业化的人员来保证阶段的质量，将问题尽量在前期发现。而测试人员只能根据前期分析的结果，设计出测试用例，来验证软件产品在事先设计或后续补充的测试用例上不存在问题。 但是“测试人员只是验证质量”决不是指我们可以不为产品质量负责。 因为大家（PM、RD、QA、OP等）工作的最终目标是产品质量保证，这个目标是大家共同的目标，所以每个人都必须为这个目标负责。只是由于咱们处于软件生命周期的最后一个环节，所以目前看起来产品质量都是由我们来负责和把握的，实际上，如果最终发布的软件产品出现了问题，那么无论如何我们肯定是有责任的。

　　测试的内容一定是确定的

　　既然软件测试只能验证质量，那么所要验证的内容必然是确定的，或者说是概率确定的。否则也就无从验证了。 因此，模糊不确定的需求我们无法验证，输出结果没有任何规律的程序设计我们也无法验证，这就是软件产品的可测性判断。也因此，我们进行需求评审和设计评审时是一定要保证这个基本点的。

　　测试的目标不是没有bug

　　综上所述，进行软件测试的目标不是通过测试使得软件产品不存在bug（这是不可能达成的），而是我们根据确定的需求、确定的设计和确定的测试用例验证出的结果不存在bug。 同样的，测试人员的目标也不是在测试执行过程中去找bug，而是运用测试思维，使用一定的测试方法，尽可能早地在需求阶段、设计阶段将所有的bug找出来，真正测试执行阶段只是验证不存在用例所描述的那样的bug，而不是通过用例去发现bug。

　　测试人员的工作方法

　　通过前文的分析，我么可以总结出测试人员的工作方法是这样的： 首先对需求进行全面深入地分析，接着去分析评审程序设计，假定每个需求的功能点开发人员的实现都是存在问题的，同时也假定每一个程序设计的编码实现（无论是方式还是代码写作）都是存在问题的，然后根据这些假定设计测试用例，最后执行这些测试用例，验证程序不存在那些问题。 从中不难看出，我们同开发人员同时由需求出发，开发人员产生详细设计和代码，我们产生方案和测试用例，然后开发人员提交被测程序，由测试人员同时运行被测程序和测试用例，来动态验证程序质量。所以，测试方案和测试用例设计的过程等价于开发人员进行详细设计和代码开发的过程，两相对比可以看出，测试人员最重要也是最核心的工作就是测试设计。 因此，测试人员的工作可以重点描述成：是一个运用测试的思维和各种测试理论及方法，将所测试的软件产品的每一个功能都改变成一组特定的输入和一组特定的输出一一确定对应的形式，形成测试用例，然后待开发人员提交测试后，在测试环境部署被测程序，根据测试用例进行主动测试的过程。

原文地址：http://www.51testing.com/html/40/n-807640.html