-
1 电子教材
-
2 PPT
软件测试一直是当今软件企业最热门的话题之一，是软件开发过程中不可缺少的一部分，对于发现软件缺陷、保证软件产品质量具有不可替代的作用。而软件测试的实施又是一个非常复杂的过程，需要考虑技术、管理、工具等众多因素。
本章主要介绍了软件测试产生的背景、软件测试的定义及目的、软件测试的现状和发展前景，及一个合格的软件测试工程师应具备的技能和素质。通过本章的学习可以了解软件测试是在什么情况下产生的，什么是软件测试及做软件测试的目的是什么，当前国内外软件测试发展的如何及做软件测试的发展空间有多大，对软件测试的认识和了解从本章开始。
软件产品对于人类而言是一个全新的东西，其发展历史不过四、五十年，人们对软件的认识经历了一个由浅入深的过程，也许大多数人认为软件仅仅是从软盘或光盘安装到计算机上的程序，这样的描述是不全面的。现在，被普遍接受的软件定义为：软件（software）是计算机系统中与硬件（hardware）相互依存的另一部分，它是包括程序（program）、文档（document）的完整集合，如图1-1所示。
图1-1 软件的组成
随着计算机的发展，软件包含更多与数据和人相关的内容，在这里给出一个简单的公式来定义软件：
软件=程序（P）+数据（库）（DB）+文档（D）+服务（S）
其中，程序表示能够完成预定功能和性能指令的集合，如C语言程序、Java程序等。数据（库）是依照某种数据模型组织起来并存放在二级存储器中的数据集合。文档指软件在开发、使用和维护过程中产生的文字与图形的集合，如系统需求规格说明书、测试计划、用户手册等。服务是指通过提供必要的手段和方法，满足接受服务对象需求的过程，如安装指导、用户培训、售后技术支持、接受投诉等。
从软件的定义中我们可以看出，软件测试不仅仅是对程序的测试，还应包括对数据、文档和服务的测试。而软件开始不仅仅包括程序的开发，还包括文档的撰写等。因此，软件测试工作不能等到程序代码全部完成之后才开始，而应贯穿于整个软件生命周期中，且在整个软件的生命周期过程中，各个阶段有不同的测试对象，形成不同开发阶段的不同类型的测试。
可从不同的角度对软件进行分类，在不同类型的软件中，软件测试具有不同的范围和侧重点。
1. 按功能分类
按功能可将软件分为四种：固件、系统软件、中间件和应用软件。
2. 按技术架构分类
按技术架构可将软件分为单机版软件、C/S（Client/Server，客户端/服务器端）架构的软件和B/S（Browser/Server，浏览器/服务器）架构的软件。
3. 按用户分类
按用户分类可将软件分为产品软件和项目软件。
测试并不是一个新事物。牛津英语大词典记载“test”一词来源于拉丁语testum，原意是罗马人使用的一种陶罐，在当时它用来评估像稀有金属矿石这样材料的质量。
像“test”这个单词的发展过程一样，软件测试定义的内涵也在随着时间的推移而不断完善，在1979年出版的一本经典著作《软件测试艺术》(The Art of Software Testing)中，Glenford J.Myers曾经对软件测试进行了这样的定义：软件测试就是“为了发现错误而执行程序或者系统的过程”。这一定义明确了软件测试的根本目的是为了发现程序中的错误。Myers撰写该著作的时期，软件测试通常在软件产品开发的后期开始，主要目的就是寻找产品运行过程中的缺陷。因此，他对软件测试所下的这一定义被人们广泛接受，反映了人们在当时对软件测试所持的观点。随着这一定义被广泛使用，人们发现了定义中存在的不足。于是，1983年在IEEE提出的软件工程标准术语中，调整了对软件测试的定义，即“使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。更新后的定义除吸收了从前人们对软件测试定义中的精华外，还明确指出，软件测试作为保证软件质量的一个重要手段，其主要任务是在已设计测试用例的基础上检验软件各个部分，以及整个系统是否正确、完整地实现了预定的功能，以确保软件质量。今天，人们对软件测试有了更进一步的认识，从广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。例如，设计评审、单元测试、系统测试。从狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。现代软件开发领域的大多数工作者都对测试有直观的认识，最常见的看法如下。
Ø 保证程序和相应的规范说明一致。
Ø 发现软件中的缺陷。
Ø 确保软件不做不必要的事情。
Ø 确保系统合理地执行。
Ø 明确在系统失败之前可以让系统正常运行到何种程度。
Ø 明确发布给用户的系统中有哪些风险。
现代软件测试活动一般包含以下内容。
Ø 测试需求分析。
Ø 制定测试计划。
Ø 设计测试用例。
Ø 实施测试。
Ø 提交缺陷报告。
Ø 测试总结。
另外，从保证软件质量的角度分析，软件测试的目的与软件开发过程中其他工作的性质有很大的差异。其他工作大都是“建设性”的，而测试工作却有着很大的“破坏性”——努力证明程序中有错误，不能按照预定的要求正确工作。不过，这仅是从表面上来看，实际上暴露问题并不是软件测试的最终目的。发现问题是为了解决问题，软件测试的根本目的是尽可能多地发现问题并排除潜在的错误，最终把一个高质量的软件系统交给用户使用。
真正的商用软件程序开发始于20世纪50年代，从那时到现在，程序的规模经历了一场爆炸式的增长，从最初几行或几十行的机器语言，发展到现在的千万数量级代码行数。伴随着这种爆炸式的增长，程序结构和算法复杂度也呈几何级数增长，确定程序的正确性和可用性成为一项非常棘手的问题。软件再也不是只需要程序员自己理解的一个黑盒，如何在软件程序自身的技术内涵和用户特定领域的需求间找到平衡点，成为学者和实践者们追寻的目标。
软件测试作为度量软件与用户需求间差距、追求软件产品高质量、提高市场竞争力、树立品牌信心的手段登上了历史舞台。
曾经有一款很著名的英汉翻译词典软件把“往返票”写成“return ticket”。这些软件中存在的错误虽小，但总是让使用者啼笑皆非，同时也对软件产品感到失望。
作为一个软件用户，最讨厌的莫过于在使用过程中遇到层出不穷的问题。有时，出现问题之后，很多用户被厂商告知是因为自己的系统无法满足软件的运行需求或设置的问题。 实际上，这些软件作者和用户都没有意识到软件的衡量标准中稳定性的重要性。
在竞争激烈的今天，无论是软件的开发商还是软件的使用者，都生存在竞争环境中。软件开发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在竞争中被淘汰出局。
用户为了保证自己业务的顺利完成，当然希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成公司信誉下降。一些关键的应用领域（例如银行、证券交易、军事等）如果质量有问题，还可能造成灾难性的后果。
现在人们已经逐步认识到是软件中存在的错误导致了软件开发在成本、进度和质量上的失控。 由于软件是由人来完成的，所以它不可能十全十美，虽然不可能完全杜绝软件中的错误，但是可以通过软件测试等手段使程序中的错误数量尽可能少，密度尽可能小。
接下来看看成功的软件测试带来的好处和不完整的软件测试带来的教训。
Ø IE和Netscape
在IE 4.0的开发期间，微软为了打败Netscape而汇集了一流的开发人员和测试人员。测试人员搭建起测试环境，让IE在数台计算机上持续运行一个星期，而且要保障IE在几秒钟以内可以访问数千个网站，在无数次的试验以后，测试人员证明了IE在多次运行以后依然可以保障它的运行速度。而且，为了快速完成IE 4.0的开发，测试人员每天都要对新版本进行测试，不仅要发现问题，而且要找到问题是哪一行代码造成的，让开发人员专心于代码的编写和修改，最终IE取得了很大的成功。
Ø 360存在严重后果缺陷导致系统崩溃
电脑中了木马，使用360安全卫士查出一个名为Backdoor/Win32.Agent.cgg的木马，文件位置为C:\Windows\system32\shdocvw.dll。进行清理后看不到Windows任务栏和桌面图标，根本进不去桌面，手工运行Explorer.exe也是一闪就关，后来查明是由于360在处理此木马时存在严重缺陷。360安全卫士只是简单的删除了木马文件，没有进行相关的善后处理工作，致使系统关键进程Explorer.exe无法加载。
Ø 2009年2月份Google的Gmail故障
2009年2月份Google的Gmail故障，应该算是最近因软件故障而受到广泛关注的事件。据Google后称，那次故障是因数据中心之间的负载均衡软件的Bug引发的。
360问题和Gmail故障还仅是导致用户不能正常使用电脑或几个小时内无法访问邮箱，并没有造成伤亡。当然了，对某些用户来讲，是非常不便。
但看了下面的一个例子您会发现，360和Gmail的问题真是“小巫见大巫”了。
Ø 2011 年温州7.23 动车事故
2011年7月23日20时30分05秒，甬温线浙江省温州市境内，由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生动车组列车追尾事故，造成40人死亡、172人受伤，中断行车32小时35分，直接经济损失19371.65万元。
上海铁路局局长安路生28日说，根据初步掌握的情况分析，“7·23”动车事故是由于温州南站信号设备在设计上存在严重缺陷，遭雷击发生故障后，导致本应显示为红灯的区间信号机错误显示为绿灯。
Ø 致命的辐射治疗
辐射剂量超标的事故发生在2000年的巴拿马城（巴拿马首都）。从美国Multidata公司引入的治疗规划软件，其（辐射剂量的）预设值有误。有些患者接受了超标剂量的治疗，至少有5人死亡。后续几年中，又有21人死亡，但很难确定这21人中到底有多少人是死于本身的癌症，还是辐射治疗剂量超标引 发的不良后果。
Ø 消失在太空
在制造其火星气候轨道探测器时，一个NASA的工程小组使用的是英制单位，而不是预定的公制单位。这会造成探测器的推进器无法正常运作。正是因为这个 Bug，1999年探测器从距离火星表面130英尺的高度垂直坠毁。此项工程成本耗费3.27亿美元，这还不包括损失的时间（该探测器从发射到抵达火星将近一年时间。）
Ø 阿丽亚娜5型火箭的杯具处女秀
1996年6月4日，阿丽亚娜5型运载火箭的首航，原计划将运送4颗太阳风观察卫星到预定轨道，但因软件引发的问题导致火箭在发射39秒后偏轨，从而激活了火箭的自我摧毁装置。阿丽亚娜5型火箭和其他卫星在瞬间灰飞烟灭。
后来查明的事故原因是：代码重用。阿5型的发射系统代码直接重用了阿4型的相应代码，而阿4型的飞行条件和阿5型的飞行条件截然不同。此次事故损失3.7亿美元。
Ø 英特尔奔腾芯片缺陷
如果在计算机的“计算器”中输入以下算式：
（419583/3145727）X3145727-4195835
结果显示为零。而在1994年，结果可能为其他答案，这就是英特尔（Intel）奔腾（Pentumn）CPU芯片所带来的一个浮点触发缺陷。英特尔为此付出了4亿多美元的代价。
Ø 一触即发的第三次世界大战
1980年，北美防空联合司令部曾报告称美国遭受导弹袭击。后来证实，这是反馈系统的电路故障问题，但反馈系统软件没有考虑故障问题引发的误报。
1983年，苏联卫星报告有美国导弹入侵，但主管官员的直觉告诉他这是误报。后来事实证明的确是误报。
幸亏这些误报没有激活“核按钮”。在上述两个案例中，如果对方真的发起反击，核战争将全面爆发，后果不堪设想。
通过以上的例子，可以看出软件发生错误时对人类生活所造成的各种影响，有的甚至会带来灾难性的后果。软件测试可以使这种风险降低，它在一定程度上解放了程序员，使他们能够更专心于解决程序的算法效率。同时它也减轻了售后服务人员的压力，交到他们手里的程序再也不是那些“一触即死机”的定时炸弹，而是经过严格检验的完整产品。同时，软件测试的发展对程序的外形、结构、输入和输出的规约和标准化提供了参考，并推动了软件工程的发展。
Grenford J.Myers对软件测试目的提出过以下观点：
Ø 软件测试是为了发现软件中的错误而执行程序的过程。
Ø 测试是为了证明程序有错，而不是证明程序无错。
Ø 一个成功的测试用例在于发现至今未发现的错误。
Ø 一个成功的测试是发现了至今未发现的错误的测试。
这种观点指出测试是以查找错误为中心，而不是为了演示软件的正确功能。但是只从字面意思理解，可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的测试，实际上并非如此。首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程的缺陷，以便及时改进。同时，这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。其次，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出软件中的错误，那么测试就应该直接针对软件比较复杂且容易出错的部分或是以前出错比较多的部分。如果测试目的是为了给最终用户提供一个具有一定可信度的软件产品，那么测试就应该直接针对在实际应用中会经常用到的流程和功能。
注意：不同的机构会有不同的测试目的，即使在相同的机构中也可能存在不同测试的目的，因此要根据不同的测试目的制定相应的测试计划，组织安排测试。
软件的商业化至今不过是几十年的时间，而软件测试则在20世纪70年代才开始逐渐引起人们的重视。因此可以说软件测试至今还处在一个起步阶段，但是随着人们对软件质量要求的提高，软件测试的技术水平也会不断提高。
研究数据显示，国外软件开发机构40%的工作量花在软件测试上，软件测试费用占软件开发总费用的30%~50%。对于一些可靠性、安全性要求比较高的软件，测试费用可能占整个软件项目开发费用的3~5倍，特别是一些大型的软件企业，例如，在Microsoft的软件开发队伍中，软件测试人员是软件开发人员的1.5~2.5倍，这可能远远超出了大家对测试人员的理解。但是微软软件开发的实践过程已经证明了这种人员结构的合理性，它使软件测试渗入到软件开发的每一项过程当中，也正是由于有这种严格的质量保障体系，Microsoft才能不断地推出让广大消费者喜爱的和市场占有率极高的软件。表1-1以Exchange 2000和Windows 2000为例介绍了微软产品团队的人员组成。
表1-1微软开发人员和测试人员比例
Exchange 2000 | Windows 2000 | |
项目经理 | 25人 | 约250人 |
开发人员 | 140人 | 约1700人 |
测试人员 | 350人 | 约3200人 |
测试人员与开发人员比例 | 2.5 ： 1 | 1.9 ： 1 |
关于国内软件测试行业的现状，在2009 年国内某软件测试专业机构有过一份调查．发现仍有一半左右的企业没有设立专门的软件测试部门。而在专职测试人员的规模方面，10 人以下的仍然占了大部分，可见大部分企业在软件测试的投入方面仍然较弱。
从调查的结果来看，国内软件测试经过这几年的发展，各企业开始重视软件测试，但是总体而言，对软件测试的投入仍然偏低，测试人员的比例也偏低，一方面是由于公司对质量管理和软件测试的意识有待提高；另外一方面也跟软件测试人员缺口较大，尤其是优秀的软件测试人员比较缺乏，难以满足公司的要求有关。
这几年的测试人员现状可以用“浮躁”两个字来形容。
一方面，测试的职位由于比较紧缺，受到大家的重视．测试人员的地位也开始提高，随之而来的是待遇、跳槽的机会。因此，有不少的软件测试人员不能安下心来努力积累经验、提高自己的能力。
另一方面，分析这几年来很多测试人员的应聘表现，可以看到测试人员的主要表现有以下几种。
Ø 基础知识不够扎实：知道一些基本的测试设计方法，但是仅仅停留在表面的概念性了解，没有深入去理解这些基本的概念。
Ø 专业技术不够精通：简历上写着精通某某技术或某某工具，但是基本上没有真正地实实在在的应用过。
Ø 没有建立起相对完整的测试体系概念，忽视理论知识，大部分人对软件测试的基本定义和目的不清晰，对自己的工作职责理解不到位。测试理论知识缺乏，认为理论知识没用而没有深入理解测试的基本道理。
尽管如此，这是软件测试行业在中国必然经历的一个不成熟阶段．软件测试行业最终会趋于平静、进入平稳的发展阶段。
Harry Robinson 在2004 年就曾经对软件测试的未来趋势进行过预测，他认为测试领域在将来会有如下的一些变化。
1. 工程师、开发人员会成为软件测试人员中的一份子，他们与测试人员之间开始互相帮助。
2. 测试的方法日趋完善，缺陷预防和早期检查将成为测试工具的主流。
3. 通过仿真工具来模拟真实环境进行测试。
4. 测试用例的更新变得容易。
5. 对测试质最的衡量开始从计算缺陷数量，测试用例数量转到需求覆盖、代码覆盖等方面。
6. 机器将替代测试人员做大部分的工作，测试人员开始把注意力集中在更严重的问题。
7. 测试人员将运行更多更好的测试。
8. 测试执行与测试开发的界限开始模糊。
9. 测试与开发的界限开始模糊。
10. 顾客反馈与测试合为一体。
11. 新的挑战，例如安全测试等新问题开始出现。
12. 测试人员获得尊重、测试变得流行。
13. 追求进度，到最后一刻才加入测试的行为仍然会存在。
在随后的这几年，可以看到，上面的一些变化已经开始。例如，人们逐步意识到测试只是事后的检测．并没有达到消灭缺陷的作用，人们开始转向缺陷产生的早期，对缺陷进行预防性的工作。
Harry Robinson 还提出了以下几点迎接测试未来挑战的建议。
1. 要不满于现状：不要被动接受和满足于测试的现状，不要埋头苦“测”，要思考一下“我们在做些什么毫无意义的事情？”。
2. 抛开人与人之间的隔阂：总结如何更好地测试，并且分享这些测试经验，只有每个人都试图使其所写的代码达到最佳状态时，整体质量才会改进。
3. 学习更多关于测试的知识：软件测试行业发展受到各种软件测试创新思维、好想法的激发。通过参加交流会，加入邮件列表，上网搜索等方式来了解在测试前沿发生的事情。
4. 学习更多关于开发的东西：参加一个编程培训课程，即使不打算编写大量的代码，也可以把培训当作是在缺陷领域上的一次侦察飞行。
5. 改变这个世界：正如PC先驱Alan Kay 所言“预测未来的最好方式就是创造未来”。
以上的建议对于测试人员来说是一个启示，测试领域有很多值得探索的东西，有很多值得思考的东西，有很多值得学习和研究的东西。
