|
|
知识路径： > 嵌入式系统的项目开发与维护知识 > 嵌入式系统软件测试 > 软件测试概述 >
|
被考次数：1次
被考频率：低频率
总体答错率：56%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：2个
|
|
|
|
|
软件测试的定义，伴随软件工程化的发展，在不同时期有所不同。
|
|
|
|
1973年，Bill Hetzel博士首次提出了软件测试的定义：“软件测试就是建立一种信心，确信程序能够按期望的设想进行（Establish confidence that a program does what it is supposed to do）”。该定义的核心是：测试的目的是确信程序能够工作，软件测试就是按照预先的设计，针对系统的所有功能，逐个验证其正确性。该定义存在其缺陷，因为不可能完全证明软件的正确性，“即便在完成系统设计、开发和测试之后，仍不可能估计软件中存在错误的种类和数目”。
|
|
|
|
1979年，Grenford J. Myers在其经典著作《软件测试之艺术》（The Art of Software Testing）中，给出了测试的另外一个定义：“软件测试是为了发现错误而执行软件的过程”。Myers还给出了与测试相关的三个重要观点：第一，测试是为了证明程序有错，而不是证明程序无错；第二，一个好的测试用例是在于它能发现至今未发现的错误；第三，一个成功的测试是发现了至今未发现的错误的测试。该观点指出软件测试以查找错误为中心，以发现错误为唯一目的，查找不出错误的测试就是没有价值的测试。
|
|
|
|
对软件测试的认识也在逐步转变：首先，无错软件的功能未必正确；其次，测试并不仅仅是为了找出错误，通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进；再者，分析错误也能帮助测试人员设计出有针对性的测试方法，提高测试效率、改善测试有效性；最后，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
|
|
|
|
在上述软件测试定义中，测试活动都只包含了运行软件系统所进行的测试，即执行软件的过程。但软件工作产品不仅仅指程序代码，还包括和软件相关的文档和数据。因此，软件测试对象不仅仅是程序代码，还应该包括软件设计开发各个阶段的工作产品，如需求文档、设计文档、用户手册等等。从这个意义上讲，以上对软件测试的定义是一个狭义的概念。实际上这只是测试的一部分，而不是测试的所有活动。
|
|
|
|
随着对软件工程化的重视以及软件规模的日益扩大，软件需求、设计的作用越来越突出。有资料表明，60%以上的软件错误不是程序错误，而是需求和设计错误。若把软件需求、设计上的问题遗留到后期，可能造成设计、编程的部分甚至全部返工，从而增加软件开发成本、延长开发周期等后果。同时，需求和设计阶段所产生的缺陷具有级联放大效应，将更严重地影响软件质量。因此，为了更早地发现并解决问题，降低修改错误和缺陷的代价，有必要将测试延伸到需求分析和设计阶段中去，使软件测试贯穿于整个软件生命周期。提倡软件全生命周期测试的理念，即软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进行的测试，而不仅仅是对程序的运行进行测试。
|
|
|
|
在此基础上，软件测试的内涵得到拓展，提出了软件验证（Verification）和确认（Validation）。验证是通过检查和提供客观证据来证实指定的需求是否满足，通过输入与输出之间的比较，检验软件是否已正确地实现了产品规格书所定义的系统功能和特性，验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致；确认是通过检查和提供客观证据，证实特定目的的功能或应用是否已经实现，在确认时，一切从客户需求出发，通过理解客户的需求，发现需求定义和产品设计中的问题，主要通过各种软件评审活动来实现。
|
|
|
|
1990年的IEEE/ANSI标准将软件测试进行了如下定义：软件测试是在规定条件下运行系统或构件的过程，观察和记录结果，并对系统或构件的某些方面给出评价；软件测试是分析软件项目的过程，检测现有状况和所需状况之间的不同，并评估软件项目的特性。
|
|
|
|
1992年12月，美国航空无线电委员会（RTCA）在其出版的《机载系统及软件合格审定中的软件考虑》（DO-178B）中对软件测试的定义为：“软件测试是执行系统或系统部件以验证其满足需求并检测错误的过程。”同时指出，软件验证贯穿于软件生命周期全过程，软件测试是软件验证的一个组成部分。
|
|
|
|
这些定义，已充分体现出验证、确认相结合的思想，是目前软件测试的主流方向。
|
|
|
