初入软件测试行业人员必读

摘要：在用友软件公司从事ERP软件测试3年时间，自己从初入软件测试行业的一无所知到现在成为部门的主测试人员，通过3年的软件测试工作中自己对软件测试有自己的见解，本文从软件测试基本概念 、软件测试现状 、软件测试过程 、软件测试基本原则个方面来进行阐述，以自己测试的ERP软件来进行举例说明软件测试中一些概念。对于刚刚步入软件测试行业的新手，我想他们现在的处境和迷茫跟我三年前是一样的，希望这篇初入软件测试行业人员必读总结能给那些初入软件测试行业人员对于软件测试工作有初步的认识，帮助他们能尽快投入自己的软件测试工作中去。尽快提升自己的测试能力。

关键词：初入职场、软件测试基本概念、测试现状、测试过程、测试基本原则、

　　一、软件测试基本概念

　　1、什么是测试

　　没有人对测试给出过严格的定义。下面的定义是其中的一种：

　　“职责明确的人员，按照规定的程序，采用以发现BUG为目的的所有方法，对软件产品进行使用性检验、归纳出BUG和BUG出现的规律并对修改工作进行核实的开发工作，就是测试。”

　　软件测试的比较公认的定义是Myers于1979年在其经典著作《The Art of SoftwareTesting》一书中阐述的：“测试是为了发现错误而运行一个程序或者系统的过程”。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

　　（1）什么是错误

　　衡量软件质量好坏的标准应该是使用户满意。凡是不符合该标准的我们都应称之为错误。

　　根据这个原则，我们对错误进行了一个归类，下面的现象都应该是错误：

　　◆ 让用户没法用！

　　◆ 让用户不敢用！

　　◆ 让用户不会用！

　　◆ 让用户不方便！

　　◆ 让用户不理解！

　　（2）错误的分类及造成的后果

　　需求错误：与实际的业务、会计准则等不符。用户没法用——固定资产计提折旧仅提供‘直线法’，使采用‘加速法’计提折旧的用户无法使用。

　　计算错误：数据计算不正确。用户不敢用——账龄分析列表将某客户应收账款10万元、欠款已达1年的数据记录成应收账款10元且在账期内，给用户造成了损失。

　　信息性错误：用户不会操作时，无法得到帮助。提供给用户的‘手册’或‘帮助’令人费解。用户不会用——看不懂《产品使用手册》及产品的‘帮助’，给售后服务带来过重负担。

　　易用性错误：功能键不符合用户的操作习惯，未从用户使用角度出发。用户不方便用——操作烦琐、无参照录入、输入汉字过多等。

　　提示错误：提示的信息让用户感到莫名其妙，不知所云。用户不知道下一步该怎么办。用户不理解——提示对话框的提示信息有二义性，既可以这样理解也可以那样理解。

　　性能错误：运行速度慢，填制一张单据需半个小时。用户心急——使用手工账时，每月月底加班；电算化后天天加班。老板更无法容忍这种‘消极怠工’以及加班费的支付。

　　输出错误：屏幕显示、打印以及备份等没有按照用户的习惯和要求，或者所见非所得。用户迷茫——套打时，输出的文字没有打印在套打纸上的指定位置。

　　耗费资源：消耗大量的内存、硬盘等。用户心酸——刚升级的计算机又不行了。

　　文字错误：指错别字、直接与用户对话的计算机术语等。用户反感——小小的错别字会使软件的质量大打折扣；难懂的计算机术语使用户不知所云。

　　死机：操作被强行终止，程序无法继续运行，须退出后重新启动执行程序，更严重甚至需要重新安装操作系统和软件。导致死机的原因很多，要找出规律具体分析。例如内存不足、死循环、非法操作、越界等。

　　不可重复错误：测试情况的复杂性导致有些问题难以再现。及时记录错误，即使问题不可再现也能留下一点线索。

　　升级错误：由于软件升级，使原版本并未出现的错误在升级后出现。升级版的测试仍很重要。

　　以上所列未穷尽错误种类，需要你在测试过程中不断积累经验，来完善错误的类别。记住“产品是否有错误，要多听听用户的意见”。

2、测试的目的

　　测试是保证软件质量的主要手段。测试的目的不是验证程序的正确性，而是让程序执行失败。测试只能表明错误的存在，而不能表明错误的不存在。这就好比测试一个科学的理论不是要证明它，而是要推翻它，也就是证明它有错误。

　　3、为什么测试

　　开发软件的是“人”不是机器，世界上没有不犯错误的“人”。根据公司实践经验统计，平均每个程序员每天大约要写300行程序，每100行程序平均大约有2~3个BUG，这还不包括模块之间的“关联”错误。我们只有经过测试，才可能发现这些BUG。没有测试的开发是不可想象的。

　　4、能否彻底测试

　　测试工作无论做的多么仔细与完全，你将永远无法发现程序中的最后一个bug。

　　一个仅有20行代码的执行程序，它可能会有100万亿个路径，一个熟练的测试人员将其全部测完需要10亿年。

　　5、测试的工作量

　　软件测试的工作量要占据开发总工作量的40%到60%，测试工作贯串于开发全过程的始终。

　　6、测试的效率

　　软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成软件开发项目。在测试阶段既然穷举测试是不可实现的，为了节省时间和资源，提高测试效率，就必须精心设计测试用例，使得采用这些测试用例能够取得最佳的测试效果。“不充分的测试是愚蠢的，而过度的测试则是一种罪孽。”

　　7、测试工作中的问题

　　测试工作中通常会出现以下问题：

　　◆ 不承担测试职责的人员，责任感不到位，出发点也不同

　　◆ 没有一套严格的操作程序，工作一紧张就会顾此失彼

　　◆ 不讲究方法，许多BUG根本查不出来

　　◆ 不按照用户的实际使用思路测试，对特殊情况没有意识，会遗漏BUG

　　◆ 不归纳BUG的出现规律，程序员很难修改

　　◆ 不验证错误的修改，就不知道错误是否纠正，是否“诱发”了其他错误

　　二、软件测试现状

　　软件产品的质量问题一直令人困扰。到底什么样的软件才算是一个好产品？保证软件质量谈何容易。

　　IT界迅猛的发展速度已经不能允许研制者“精雕细琢”，在市场经济杠杆的作用下，用户的性情越来越“急躁”，一个市场需求刚刚冒头就希望第二天拿到产品；而且顾客还经常振振有词：你要是干不了我去找别人……

　　从上面谈到的情况看，软件过程的质量已经远远超出是某个版本“产品本身质量”的问题了。用比较全面和准确的语言描述的话，高质量的软件产品应当等于“让用户满意”。

　　让顾客完全满意的要素有三点：产品质量、交货期和成本价格。

姑且不谈论成本价格；单从产品质量和交货期而言，我们会发现：两者之间在测试时间T轴上竟然是完全“负相关”的。

　　毫无疑问，测试时间越长产品质量越有保证，但交货期滞后会令顾客烦恼；反之，顾客会对产品的质量提出抱怨甚至发生“退货”。明智的开发商应该知道如何控制发版时间T0时刻。

　　综前所述，在保证产品质量的活动中，时间限制就是T。（这是开发成本最低、顾客综合感觉最满意的发版时间）。如何在这个时间之内将产品的质量尽可能地达到最好，就是我们所面临的工作情况。

　　我们可以提高顾客满意程度的方向有两个：

　　◆ 保持目前的T。但让产品质量水平更高（测试的高效率、精心设计和严密组织配合）。

　　◆ 维持目前产品的质量水平不变，缩小T。（确立既定目标和发版标准，制定严密的测试工作计划）。

　　如何在有限的资源（人力、物力和时间T。）条件下，保证并提高产品的质量，是每个开发人员（特别是测试人员）义不容辞的责任。

　　我们在努力实现上面目标遇到的困难是：

　　◆ 对于测试工作的重视程度不足：在开发工期紧张的情况下，最可能缩短的就是测试工期；

　　◆ 对测试理论和方法的研究不够：许多测试人员几年来测试手段和方法一直没有明显的改进；

　　◆ 忽视产品测试设计和测试数据的设计：T。的紧迫性和大量重复性测试验证工作，及测试组织的不协调性等大都源于设计计划不周；

　　◆ 对测试技能培训不足：多数测试人员的技能和经验是摸索和积累出来的；新员工甚至叫喊：我上班两星期了还不知道应当怎样做测试！

　　三、软件测试过程

　　一个产品从代码完成到发版，以自己测试的ERP软件中U8产品中的单据来说，一般有以下测试过程和环节：

单元测试

　　通过采用单元测试用例或需求规格说明等作为指南，对最小的软件设计单元的进行的测试，以发现错误保证软件各组成单元正确实现，可以采用白盒测试方法和黑盒测试方法。

　　举例来说：新作一张单据。对单据的增加、修改、删除、查询等的测试就是单元测试。如修改的测试，测试各可输入栏目的非法字符、极限值等等，都属于单元测试。

　　联调测试

　　在单元测试完成后进行的单产品测试，包括对有接口及数据关系的产品进行组合测试，主要是测试有上下游单据关系、上下游数据关系的各项功能。

　　以会计凭证的相关操作为例：在会计凭证的后续节点上，比如记账，在记账前需要查询出符合条件的会计凭证，会计凭证有各种各样的，在利用较复杂、较多的会计凭证来测试“查询出符合条件的会计凭证”这一功能点时的测试，就属于联调测试。

　　集成测试

　　单产品的联调测试完成后，对本次发版所有产品进行的整合测试。这个阶段，通常模拟用户，模拟企业不同的实际运用场景进行测试。

　　测试工作的流程如下图所示：

　　四、软件测试基本原则

　　1、思想原则

　　1.1 怀疑一切：测试就是为了发现错误，交给你的产品就是有错误的产品。不管程序人员如何“信誓旦旦”，你的工作就是以发现BUG而“油然而生”自己的“成就感”。

　　1.2 宁可错杀一千，不能放过一个：不能“迁就”自己的感觉，不要担心自己的“无知”。理解错了很正常，但放任过去可能会“后患无穷”。即便是“帮助”中的一个标点符号，也要推敲一下。

　　1.3 实事求是：不要夸大错误的性质，也不要对错误“轻描淡写”。

　　2、技术原则

　　2.1 一次和三次：BUG出现一次程序肯定有错误，不要相信“以后决不会出现”的许诺；让BUG重复出现三次，才有可能摸清楚BUG出现的操作规律，记录详细的操作规律对程序员缩小查错范围十分重要。

　　2.2 路径覆盖：要按照软件设计的数据流程，遍历所有流程分支。不要想象程序中存在“等同状态”或“与此类推”的情况。没走到的地方肯定有BUG。

　　2.3 确定预期输出结果：测试之前就应明确什么是正确结果，甚至每一个操作事先都要知道正确的结果是什么。

　　2.4 合法输入与非法输入相结合：程序员对合法输入测试较多，他们最可能疏忽的就是“非法”输入操作。用户的使用方式“千奇百怪”，你不知道他们要如何操作，所以，你必须设计操作方式。

　　2.5 测试复核：找一个BUG十分不易，如果没改正你就“白费劲”了。对于测试出的错误修改后必须要验证，并且考虑到可能影响的范围。

　　2.6 提供信息：测试应该为排错提供必要的诊断信息，找出错误出现的规律十分必要。

　　2.7 尽早暴露缺陷：缺陷暴露得越早，越能降低开发和维护成本。例如，需求分析中的缺陷如果在需求评审时被暴露出来，只需要改几个字就可以了；如果在设计评审时暴露出来，产品的框架结构可能需要调整；若待编码完成后暴露出来，设计人员和程序员几个月的辛苦可能付诸东流；如果到测试完成后，发现需求错误，开发过程可能要延期，造成巨大的人员和时间浪费。最不幸的是，如果到用户现场实施阶段暴露出来，用户发现根本不是自己所要的产品，可能退货或返工，那么所有的投入都是无用功。软件寿命周期中，暴露缺陷的阶段与修改缺陷产生的开发成本之间的对应关系如下图所示：

　　现代测试理论认为，对软件寿命周期全过程的工作产品（包括需求文档、设计文档等）的检查和评审都是软件测试的工作范围。