软件测试技术为何如此重要？

      进入上世纪90年代，软件行业开始迅猛发展，软件的规模变的非常大，在一些大型软件开发过程中，测试活动需要花费大量的时间和成本，而当时测试的手段几乎完全都是手工测试，测试的效率非常低;并且随着软件复杂度的提高，出现了很多通过手工方式无法完成测试的情况，尽管在一些大型软件的开发过程中，人们尝试编写了一些小程序来辅助测试，但是这还是不能满足大多数软件项目的统一需要。于是，很多测试实践者开始尝试开发商业的测试工具来支持测试，辅助测试人员完成某一类型或某一领域内的测试工作，而测试工具逐渐盛行起来。

　　迄今为止，并不是所有的测试人员都需要阅读程序代码，但是研读程度代码作为测试的一部分工作这个观点得到了大部分人的认同。实际上，人工测试对发现程序的错误方面效率非常高，它主要包括桌上检查，走查，代码检查和同行评审技术，使用这些技术能够有效的发现30%-70%的逻辑错误和编码错误。

　　1.桌上检查

　　桌上检查是一种很传统的检查方式，由程序员在程序通过编译之后根据错误表对程序代码进行检查，但是这种检查一般效率很低，因为它违反了测试中开发人员不要测试自己的程序的原则，失去了客观性

　　2.代码检查

　　所谓的代码检查就是以小组为单位，应用一系列的检查错误的技巧来发现程序中的缺陷和错误的过程

　　根据软件产品的规格大小，检查小组的规模也各不相同，每个小组都有其具有特色和作用的成员

　　代码检查是桌上检查之后的改进，目的是为了发现错误而不是改正错误，检查活动主要有两个：

　　（1）由讲解员逐条语句讲解程序的逻辑结构，然后由小组成员提出意见或发现的错误

　　（2）对照常见的错误检查表分析程序

　　3.走查

　　走查和代码检查很相似，但是进行的规格和使用的错误发现技术稍有不同

　　走查实施的过程中，走查人员对程序进行模拟，一步步演示程序是如何处理相关数据的

　　在模拟程序的过程中，每个走查组的成员在自己的脑海中也进行着程序逻辑的模拟

　　这样一来能够高效的发现程序中的错误

　　并且可以精确的定位这些错误

　　4.同行评审

　　同行评审是一种通过作者同行来确认缺陷和需要变更区域的检查方法

　　它涉及的范围比较广，主要分为管理评审，技术评审，文档评审和过程评审等

　　简而言之，同行评审的对象并不只是程序，而是软件生命周期中可能产生的各类产品

　　同时，同行评审的技术和方法从非正式的到最严谨的都各不相同

　　在评审过程中，应该先了解评审经常出现的问题有哪些

　　然后采取相对应的对策进行解决

　　测试概念的范畴

　　广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。

　　狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。

　　测试的目的

　　简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。

　　具体地讲，测试一般要达到下列目标：

　　1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。

　　产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期利益看，这是很不划算的。领测认为接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。

　　当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。

　　最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。

　　2、确保产品满足性能和效率的要求

　　使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。

　　用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。

　　3、确保产品是健壮的和适应用户环境的

　　健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。

　　另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某些第三方产品同时使用的。

　　3、测试的原则---GoodEnough

　　对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

　　Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。最明显的例子就是FIT3.0中文报版的产品测试。

　　测试的规律----木桶原理和80-20原则

　　1、木桶原理。

　　在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

　　2、Bug的80-20原则。

　　一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

　　小编结语：

　　软件测试已有了行业标准(IEEE/ANSI)，1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。

　　以上就是小编在本文要跟大家分享的有关于软件测试的相关内容，更多精彩好文尽在课课家教育~~