软件测试的定义
关于软件测试的定义，不同学者有不同的观点，了解软件测试的定义，对于⽇后在⼯作中是很有帮助的,
⾸先要明确测试的定义，所谓测试，就是以检验产品是否满⾜需求为⽬标。
⽽软件测试,⾃然是为了发现软件(产品)的缺陷⽽运⾏软件(产品)
⽐较标准的软件测试的定义是：在规定的条件下对程序进⾏操作，以发现错误，对软件质量进⾏评估。
IEEE 标准的定义：使⽤⼈⼯或⾃动的⼿段来运⾏或测定某个系统的过程，其⽬的在于检验；它是否满⾜规定的需求或是弄清预期结果与实际结果之间的差别。对软件测试还有⼀些不同的定义。
G.J.Myers给出的定义:“程序测试是为了发现错误⽽执⾏程序的过程”。这个定义被软件测试业界所认可，并经常被引⽤。但实际上，
这样的定义还不能完全反映软件测试的内涵，它仍局限于“程序测试”。随后，G.J.Myers进⼀步提出了有关程序测试的3个重要观点，那就是:
(1)测试是为了证明程序有错，⽽不是证明程序⽆错误。
(2)⼀个好的测试⽤例在于它能发现⾄今未发现的错误。
(3)⼀个成功的测试是发现了⾄今未发现的错误的测试。
要完整地理解软件测试，就要从不同⽅⾯和视⾓去辨证地审视软件测试。概括起来，软件测试就是贯穿整个软件开发⽣命周期、对软件产品(包括阶段性产品)进⾏验证和确认的活动过程，其⽬的是尽快尽早地发现在软件产品中存在的各种问题—与⽤户需求、预先的定义不⼀致的地⽅。
附注:
1.软件测试的侠义观点和⼴义观点
G.J.Myers给出了测试定义—“程序测试是为了发现错误⽽执⾏程序的过程”，实际上这是⼀个狭义的概念，因为他认为测试是执⾏程序的过程，也就是传统意义上的测试—在代码完成后，通过运⾏程序来发现程序代码或软件系统中错误。但是，这种意义上的测试是不能在代码完成之前发现软件系统需求及设计上的问题的，把需求、发现设计上的问题遗留到后期—最 终在代码中体现出来，这样就可能会造成设计、编程的部分或全部返⼯。需求阶段和设计阶段的缺陷在开发过程中会产⽣扩⼤效应，缺陷的严重性随时间发展越来越 严重，其结果会⼤⼤增加软件开发的成本、延长开发的周期等。这种狭义的观点主要是受软件开发瀑布模型的影响，⽽且⾮常不利于保证软件质量。
延伸后的软件测试，被认为是软件测试的⼀种⼴义概念。这就引出了⼴义的软件测试的两个概念“静态测试”和“动态测试”。这样，静态测试和动态测试就构成了⼀个全过程的、完整的软件测试，⽽且静态测试显得更为重要。
说明：静态测试的主要活动是评审，即通过对需求、设计、配置、程序和其他各类⽂档的审查来检验相应的内容是否满⾜⽤户的需求。由于静态测试不需要运⾏程序，所以测试对象是属于静态的.
动态测试通过运⾏程序来发现软件系统中的问题，在程序运⾏过程中发现缺陷，它具有动态性。
2.软件测试的辨证观点
软件测试项目流程
G.J.Myers的第2个观点是“测试是为了证明程序有错，⽽不是证明程序⽆错误”，引出了软件测试的另外⼀个争论:
软件测试究竟是证明所有软件的功能特性是正确的，还是相反—对软件系统进⾏各种试探和攻击，出软件系统中不正常或不⼯作的地⽅，就我个⼈理解，这两个⽅⾯都有⼀定道理，前者(证明或验证所有软件的功能特性是正确的)是从质量保证的⾓度来思考软件测试，后者(证明程序有错)从软件测试的直接⽬标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，可以认为测试不是为了证明所有的功能都能正常⼯作，恰恰相反，测试就是为了出那些不能正常⼯作、不⼀致性的问题，也就是说，测试
的⼯作就是发现缺陷(detect bug )，即在软件开发过程中，分析、设计与编码等⼯作都是建设性的，唯独测试带有“破坏性”， 它想⽅设法发现软件所存在的问题。软件测试就是在这两者之间获得平衡，但对于不同的应⽤领域，两者的⽐重是不⼀样的。例如，国防、航天、银⾏等软件系统， 承受不了系统的任何⼀次失效，因为任何失效都完全有可能导致灾难性的损失，所以强调前者，以保证⾮常⾼的软件质量。⽽⼀般的软件应⽤或服务，则可以强调后 者，质量⽬标设置在“⽤户可接受⽔平”，以降低软件开发成本，加快软件发布速度，有利于市场的扩张。
(1)验证软件是“⼯作的”，以正向思维⽅式，针对软件系统的所有功能点，逐个验证其正确性。
(2)证明软件是“不⼯作的”，以反向思维⽅式，不断思考开发⼈员理解的误区、不良的习惯、程序代码的边界、⽆效数据的输⼊及系统的弱点.试图破坏系统、摧毁系统，⽬标就是发现系统中各种各样的问题。其代表⼈物就是上⾯多次提到的G.J.Myers。他强调，⼀个成功的测试必须是发现缺陷的测试，不然就没有价值。
3.软件测试的风险观点
测试被定义为“对软件系统中潜在的各种风险进⾏评估的活动”，这就引出软件测试的风险观点。软件测试⾃⾝的风险性是⼤家公认的，测试的覆盖率不能做到100%；另 外⼀⽅⾯，软件测试的标准有时不清楚，软件规格说明书是测试中的⼀个标准，但也不是唯⼀的标准。因为规格说明书本⾝的内容完全有可
能是错误的，它所定义的 国内特性不是⽤户所需要的。所以，我们常常强调软件测试⼈员应该站在客户的⾓度去进⾏测试，除了发现程序中的错误，还要发现需求定义的错误、设计规格说明 书的缺陷。但是，测试在⼤多数时间/情况下是由⼯程师完成的，⽽不是客户⾃⼰来做，所以⼜怎么能保证⼯程师和客户想得⼀样呢?
有⼈把开发⽐作打靶，⽬标明确，就是按照设计规格说明书去实现系统的功能。⽽把测试⽐作捞鱼，⽬标不明确，⾃⼰判断哪些地⽅鱼多，就去哪些地⽅捞：如果只捞⼤鱼(严重缺陷)，⽹眼就可以⼤些、撒⽹区域相对⽐较集中(测试点集中在主要功能上)。如果想把⼤⼤⼩⼩的鱼都捞上来，⽹眼就要⼩，普遍撒⽹，不放过任何⼀块区域(测试点遍及所有功能)。
在“风险”观点的框架下，软件测试可以被看作是⼀个动态的监控过程，对软件开发全过程进⾏检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试完全可以看作是软件质量控制的过程。
对应这种观点，产⽣基于风险的测试策略，⾸先评估测试的风险，每个功能出问题的概率有多⼤?根据Pareto原则(也叫80/20原则)，哪些功能是⽤户最常⽤的功能(约占20%)?如果某个功能出问题，其对⽤户的影响⼜有多⼤?然后根据风险⼤⼩确定测试的优先级。优先级⾼的功能特性，测试优先得到执⾏。⼀般来讲，针对⽤户最常⽤的这20%功能(优先级⾼)的测试会得到完全地、充分地执⾏，⽽低优先级功能
的测试(⽤户不常⽤的功能，约占80% )就可能由于时间或经费的限制，降低测试的要求、减少测试⼯作最，这样做风险性并不是很⼤。
4.软件测试的经济学观点
⼀个好的测试⽤例在于它能发现⾄今未发现的错误”， 这体现了软件测试的经济学观点。实际上，软件测试经济学问题⾄今仍是业界关注的问题之⼀。经济学的核⼼就是要盈利，盈利的基础就是要有⼀个清楚的商业性⽬ 标。同样，商业性⽬标是否正确，直接决定了企业是否盈利。在多数情况下，软件测试是在公司内执⾏的。正是公司的⾏为⽬的，决定了软件测试含义或定义经济性 的⼀⾯。正如对软件质最的定义不仅仅局限于“和客户需求的⼀致性、适⽤性”，⽽且要增加其他的要求—“开发成本控制在预算内、按时发布软件、系统易于维
护”等。
软件测试也⼀样，要尽快尽早地发现更多的缺陷，并督促和帮助开发⼈员修正缺陷。原因很简单，缺陷发现得越早，所付出的代价就越低，例如在编程阶段发现⼀个需求定义上的错误，其代价将10倍于在需求阶段就发现该缺陷的代价。这就是从经济学的观点来说明测试进⾏得越早越好这样⼀个道理。
5.软件测试的标准观点
从标准观点来看，可以定义为“验证”和“有效性确认”活动够成的整体，即软件测试=V&V
“验证”是检验软件是否已正确地实现了软件需求规格说明书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有⽣命周期活动的要求(如正确性、完整性、⼀致性、准确性等)⼀致。相当于以软件产品设计规格说明书为标准进⾏软件测试的活动。
“有效性确认”是确认所开发的软件是否满⾜⽤户真正需求的活动。⼀切从客户出发，理解客户的需求，并对软件需求定义和设计存疑，以发现需求定义和产品设计中的问题。主要通过各种软件评审活动来实现，保证让客户参加评审和测试活动。
当然，软件测试的对象是产品(包括阶段性产品，如市场需求说明书、产品规格说明书、技术设计⽂档、数据字典、程序包、⽤户⽂档等)，⽽质量保证和管理的对象集中于软件开发的标准、流程和⽅法等上。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。