企业 怎么建交互网站,临沂网站建设排名,义乌网站建设优化推广,廊坊做网站厂商定制测试人员的思想理念和工作方法 软件测试的前提假设 测试人员进行软件测试的基本假设是“有罪推断” #xff0c;即认为被测程序一定是有bug的#xff0c;而且每个功能点的实现都存在bug#xff0c;而且一定存在严重的bug。 请牢记这个假设 #xff0c;一旦在日后的工作过程…测试人员的思想理念和工作方法 软件测试的前提假设 测试人员进行软件测试的基本假设是“有罪推断” 即认为被测程序一定是有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转载于:https://www.cnblogs.com/xinyuxin912/p/3511420.html
