软件测试失效案例简介

第一篇：软件测试失效案例简介

http://book.51cto.com/art/200909/151890.htm

失效案例简介

软件出现的问题有多种形式，会产生各种各样的后果。下面是一些例子。

受医用线性加速器的过度辐射，造成6人严重烧伤或死亡。经查，管理加速器的软件包含了一系列程序错误，由于软件结构极差，错误再现困难，也使得机器生产者不愿意收回机器。

火星气候轨道航天器撞到了火星的表面。调查表明，由于测试不充分，没有发现程序中的一个简单的量纲转换错误。

几架“黑鹰”直升机撞毁，多人罹难。调查表明，灾难原因是无线电信号与机载计算机系统相互干扰。

称做CONFIRM的旅游预订系统在经过1.25亿美元的投资后流产。

F22战机的一个软件故障（边界值测试的漏洞）。2007年2月，美军F22战斗机从夏威夷飞往日本，途径日期变更线（东经180度，西经0度）时，软件缺陷爆发，飞机上的全球定位系统失灵，电脑系统崩溃。飞行员无法确定战机的位置，返回夏威夷的希卡姆空军基地。洛·马丁公司对软件进行了维护，48小时后提供了新的软件版本。

2007年北京机场信息系统瘫痪。2007年10月10日13时28分，设在北京首都国际机场的中国民航信息网络股份公司离港系统突然发生故障，短短50分钟内，北京、广州、深圳、长沙机场至少84个离港航班发生延误，受其影响的城市包括上海、长春、南京、南宁、温州、成都、郑州、太原、呼和浩特、重庆、兰州、香港、东京等。该系统是由美国某家公司研发，此事件引发信息系统安全的担忧。

2008北京奥运会售票系统于2007年10月30日上午11时瘫痪：北京奥运会的指定独家票务供应商-北京歌华特玛捷票务有限公司成立于2006年9月，由美国特玛捷公司、中体产业股份有限公司及北京歌华文化发展集团三家出资构建而成。售票系统瘫痪事件发生后，公众普遍质疑歌华特玛捷公司是否具备承担2008北京奥运会的票务销售能力。

用户常常在软件开发初期就发现软件不是他们所期待的。在开发软件之前，需要进行必要的需求分析。充分的需求分析要求软件开发人员与用户进行良好的沟通，充分理解用户需求才能开发出更有用的产品。虽然这些软件故障的后果程度不一，但可以肯定的是，通过严格的软件工程可以极大地降低故障及因此而引发的种种恶果。

1.6.2失效原因

软件失效主要是由于开发组织没有采用好的软件工程方法。尽管软件开发人员知道不好的软件开发可能造成可怕的后果，但为什么大家还不能广泛采用软件工程的方法呢？原因是管理和开发队伍对软件工程早期的重要性的认识严重不足，认为代码的行数是项目进展的唯一尺度，任何与生成代码无关的事情都不是进展，因而也不值得花费时间和资源。

引起软件失效的原因包括：

1)软件复杂度；

2)非线性（多线程）软件；

3)对意外的输入或条件估计不足；

4)与外设接口动作异常；

5)硬件或操作系统与软件不兼容；

6)管理不善；

7)测试不充分；

8)粗心大意；

9)想走捷径；

10)不向管理部门通报问题；

11)风险分析不充分；

12)数据输入错误；

13)错误的输出解释；

14)对软件过于自信；

15)缺乏生产高质量软件的市场或法律压力。

以上是引起软件失效的原因列表，对我们很有帮助，我们应该谨记。考虑的潜在软件失效原因越多，系统就越不易出现失效。例如，如果完全按照一种软件工程方法学来开发软件，假设用户是未经过充分训练的，那么就应考虑可能会出现数据完整性错误，否则，系统可能是没什么用的。

下面来看几个实际的软件开发中的灾难故事，目的是让你充分理解软件开发中和谐工作方式的重要性，不论你是初学者还是计算机专家，均能获益。这些故事也可以让你为争取在你的工作环境下采用好的软件工程方法提供有力证据。

1.6.3 CONFIRM

CONFIRM是一个雄心勃勃的软件开发计划，它的目标是集成飞机订票、汽车出租和旅馆预订以及相关的决策支持机制为一体。它是由美国航空公司的子公司AMRIS提出的，项目开发了3年半，耗资1.25亿美元，结果生产了一个无用的系统。

CONFIRM的惨败虽然没有危及任何人的生命，但是如此巨大的经济损失最后都转嫁到了消费者身上。通过这种高的消费代价，大众觉察到如此灾难性软件开发的后果。为了更好地评估避免如此巨大经济损失而应采取的各种策略，将有关的大事列表如下：

1)1987年10月，Marriott,Hilton,Budget Rent-a-Car和AMRIS成立联盟，决定开发和运营CONFIRM，并让AMRIS管理开发。项目计划分两个阶段，计划于1992年6月完工。

2)1988年5月24日，AMRIS发布新闻，宣布CONFIRM设计阶段开始。

3)1988年12月30日，AMRIS向联盟呈报了系统基础设计，Marriott认为系统的功能规约还不够充分，用户需求还不够细，开发人员还不能据此进行开发。

4)1989年3月，AMRIS呈报一份开发计划，结果也未被联盟成员们接受。

5)1989年8月，AMRIS向联盟成员提交了项目经费预算。基于这一预算，其他成员决定继续维持该项目。后来的事实表明，这一预算对人员和操作成本的估计存在严重不足。

6)1989年9月，AMRIS终于完成了一个令联盟满意的设计，同时预算也增长至7260万美元。

7)1990年1月，AMRIS未能按第一合同期限完成终端屏幕的设计。

8)1990年2月，第二个项目里程碑即系统商务领域分析也未能如期完成。AMRIS承认有13周的滞后，但仍声明系统可以在原定的期限完成。

9)1991年2月，AMRIS向联盟成员提交了一份修改过的开发计划，要到1993年3月为Marriott提供完整功能的系统。后来Marriott声称其实AMRIS知道它不可能在新的期限内完成系统，但还是强迫雇员人为地延长工作时间表，否则会遭到解雇或重新调遣。AMRIS也在修改的开发计划中提高了开发的价钱，升至9200万美元。

10)1991年10月，AMRIS总裁以及20余名雇员辞职。

11)1992年5月1日，AMRIS的新总裁认可“系统接口和数据库不足以提供必要的性能和可靠性”，他还将这种状况归究于AMRIS对项目状态的错误认识。

12)最后，于1992年7月，联盟在花费了1.25亿美元后，不堪重负，终于解散。

大量的报刊对CONFIRM项目的无能的管理和技术上的幼稚等进行了无情的嘲讽。不过我们关心的是，如何利用适当的软件工程方法来避免这种灾难。虽然这个例子涉及一个重要的职业道德问题，但首先还是让我们来分析软件失效的根源。

很明显，AMRIS关于项目状态的管理是有问题的。项目是如何发展到管理部门被迫掩盖真相的呢其实在项目的早期就有一些不好的征兆，AMRIS是不能开发一个可行的产品的；第二个征兆是，经过7个月的努力后，AMRIS提交的设计文档技术上是不能令人满意的。这样的一个设计意味着AMRIS没有能力正确估计自己设计的质量。另外，AMRIS的行动表明它并不重视交付设计的质量，只重视初始设计的按期完成。第二次提交的设计再次遭到拒绝，这也再一次表明AMRIS确实太无能，不可能提出一个充分的开发计划。

以上大事记似乎反复强调了AMRIS不能提供高质量的软件工程报告，这意味着基础的软件开发阶段的有效性值得质疑。另外，某种基础的风险分析应能帮助联盟成员识别至少两种高风险目标。这些风险目标应能提醒联盟成员进行某些测验项目，以确定这些目标的可行性。CONFIRM系统的一个高风险目标是需要与联盟伙伴的现有系统连接，这样的连接要求CONFIRM同异构的软硬件能互操作；第二个高风险目标是需要将预订系统同每种商务领域的决策支持系统集成。初始时对这些目标的复杂性作一下分析，就会得到一个更合理的开发进度计划。

1.6.4 电话和通信

今天，人们很难找到比远程电话网应用技术更好的例子。它通过光纤将遍及世界各地的人们可靠地、即时地连在一起，这不能不说是技术上的奇迹。AT&T拥有多达115个交换站，将遍及世界的当地电话公司连接起来，每天可处理1.15亿次美国境内的呼叫和150万次的海外呼叫，每个交换站每小时能处理将近75万次呼叫。

一个交换站，又名4ESS，其实是一个庞大的专用计算机，它运行一个包含4百万行代码的软件。该软件需要仔细处理电话两端的连接、通话费以及其他许多与电话相关的服务，为维护该软件需要雇佣150人以上。有几次事故曾中断了电话服务，原因就是该软件过于复杂。

1990年1月15日的下午，AT&T的全球电话网络的管理人员发现显示网络状态的视频监视器上不断出现红色报警信号。报警信号说明网络不能完成呼叫，接下来的9个小时内，有近6500万个电话没有接通，造成大约6000万美元的损失。尽管系统的管理人员设法在9小时内解决了问题，但是要查明原因恐怕需要好几天。

大约在系统瘫痪前一个月，软件进行了升级，以允许某种类型的消息更快地通过系统。在升级软件的一小段代码中发现了一个错误，该错误在严格的测试和一个月的试用中没有被发现，因为那几行代码只在网络特别忙而发生了特定的事件序列时才会调用。各单个交换站工作都正常，但交换站之间的消息传递的快速步调引起系统反复重启动。当运行升级软件的交换站数减少到80台左右时，网络似乎又恢复正常。这时，其余的交换站仍然运行旧版软件，可以处理尽可能多的呼叫。

这种类型的“网络隐错”确实很难发现和想到，要在一个测试用的系统上精确模拟和预料真实世界中的网络通信是十分困难的。事实上，AT&T确实也在它的测试网络上测试了该软件，但没能发现该问题。

与首次瘫痪相隔6个月，又遇到了另一个控制交换站的软件失效。在1991年6月到7月间的三个星期内，8次电话不通事故影响了大约2000万电话客户。不通的原因难以捉摸，而且，本地电话公司之间似乎也不愿意彼此透露如何修复问题的有关信息。最终，由BellCore贝尔通信研究公司经过6个月的调查，认定引起这一问题的原因仍然是这个交换机软件。

这些事故的原因是制造交换机的软硬件公司DSC通信公司对软件的一次修改不当造成的。1991年4月，DSC通信公司发布了交换机的新版本。很快，华盛顿、宾夕法尼亚和北卡罗来纳州的用户碰到了这一问题。每次瘫痪首先由一个交换机的一个小问题引起，该问题与信号传输点（Signal Transfer Point，STP）有关。然后这一问题会触发大量的错误消息，结果导致STP被关闭，进而导致邻近系统的瘫痪。

最后，BellCore发现问题出在新版软件中的一个三位错：一个应是二进制数D（1101）的数误为二进制数60110）。在交换算法中，这三位错导致交换机允许错误消息饱和。通过网络，一个系统出错导致其他系统崩溃。正常情况下，饱和的交换机只简单地通告其他系统出现了拥塞情况。DSC通信公司很快发布了该软件的补丁，专门处理这一问题。对源程序作了广泛的测试之后发现，一个程序员对源程序中的三行代码作了修改，其中一行包含低级的打字错误，软件发布前，该段代码没有经过测试。

你也许会庆幸通信问题似乎已成历史，因为以上两个例子均发生在20世纪90代初。然而，事实上近年来也发生了大量的这类失效。例如，一位美国西部技师为科罗拉多州安装一个新的区域码软件时，不经意地关闭了该区域的911系统，结果一位在Longmont的名叫Thomas Carlock的男士死于心脏病，发病时他的妻子不能拨通911急救服务。当时，她至少试过3次，结果每次都没有回答，没有振铃，也没有线路忙信号。最后，她查了号码本，直接呼叫了一个急救室的电话，然后救护车才发往她的住地。在事故追查的过程中，技师一直不清楚911会有问题，Longmont急救人员也是直到事故发生后一个小时才知道911有问题的。按照美国西部的一份报告的说法，公司“已承诺采取措施确保软件安装不会影响到911服务”。

1.6.5阿丽亚娜5型火箭

1996年6月4日，阿丽亚娜（Ariane）5型火箭在法属圭亚那库鲁航天中心首次发射。当火箭离开发射台升空30秒时，距地面约4000米，天空中传来两声巨大的爆炸声并出现一

团桔黄色的巨大火球，火箭碎块带着火星撒落在直径约两公里的地面上。与阿丽亚娜5型火箭一同化为灰烬的还有4颗太阳风观察卫星。这是世界航天史上又一大悲剧。

阿丽亚娜5型火箭由欧洲航天局研制，火箭高52.7米，重740吨，研制费用为70亿美元，研制时间1985－1996年，参研人员约万人。事故原因报道：阿丽亚娜5型火箭采用阿丽亚娜4型火箭初始定位软件。软件不适应物理环境的变化。阿丽亚娜5型火箭起飞推力15900KN，重量740吨，阿丽亚娜4型火箭起飞推力5400KN，重量474吨。阿5型火箭加速度=21.5g，阿4型火箭加速度=11.4g。阿丽亚娜5型火箭加速度值输入到计算机系统的整型加速度值产生上溢出，以加速度为参数的速度、位置计算错误，导致惯性导航系统对火箭控制失效，程序只得进入异常处理模块，引爆自毁。箭载两套计算机系统由于硬件、软件完全相同，没有达到软件容错的目的。

导航系统负责参照基于惯性参考系统输入的特定轨道来计算航线矫正。一个惯性参考系统让一个移动体（例如火箭）仅根据来自加速仪和回转仪的传感器数据来计算其位置，也就是说，其计算不参考外部世界的数据。该惯性系统首先必须初始化起始坐标，用火箭的初始瞄准来校准其轴。导航系统在发射前，进行校对计算。为了把地球自转产生的影响计算在内，校对计算的结果需要不断更新。校准计算很复杂，大约需要45分钟才能完成。一旦火箭发射后，校准数据将传给飞行导航系统。根据设计，校准计算在数据传给导航系统后，还将继续50秒。这一决定使导弹发射前的倒计数得以在对准数据传出后、在发动机被点火之前终止，而不必重新启动校准计算（即，不必重新启动45分钟的计算周期）。当发射成功时，校准轮在起飞后为下一个40秒产生待处理的数据。

Ariane5的计算机系统与Ariane4不同，电子仪器多了一倍。有两个惯性参考系统来计算火箭的位置，两台计算机将计划中的轨道和实际轨道进行比较，并用两套控制仪器来控制火箭。如果某个构件出了问题，后备系统将随时接替现行系统。

专为地面设计的校准系统，使用16位字来存储水平速度(对由于风和地球运行产生的位移计算而言，16位是绰绰有余的)。飞行30秒后，Ariane5的水平速度计算产生了溢出，由此引出了一种意外，通过关掉机载计算机来处理这一问题，并把控制权交给后备系统。

讨论：由于校准系统没有得到充分测试，尽管它经过成千上万次测试，但没有一次测试包括了实际轨道上的测试。导航系统被单独地进行了测试。系统项目组制定测试计划，导航系统的构造者执行测试。系统项目组没有意识到在飞行中的校准会引起主处理机的关闭。这一实例充分说明了构件组与系统组缺乏沟通。

教训：军用软件的运行依赖于支撑环境，武器平台的变化可能影响军用软件采集数据的精度、范围和对系统的控制。军用软件重用必须重新进行系统论证和系统测试／试验，决不能想当然。

第二篇：软件测试 心得体会

兰州直方科技有限公司

心得体会

如果要进步，那么就要尝试新的技术，新的思维，大胆的使用，在用的过程中肯定会学到新的东西。

加强团队内部的沟通，是解决团队内部分散的最好办法，如果一个团队没有很好沟通，那么这个团队就像是没有肥力的沙漠就没有竞争力，它的存在价值值得怀疑。但是加强团队建设是一件很不容易做到的事情，加入团队中有某一个成员技术很牛，就是搞独立，不按照游戏的规则，那么，作为项目小组的负责人，该如何去解决这个问题。我想在肯定他技术很牛的同时也应该让他明白如果只是将自己所做的模块做好，整个项目却是一般般，那么自己做好的那个模块就起不到任何的作用了。沟通，再沟通，直到他能很好的配合团队的工作，这样我相信我们的团队是一个有凝聚力、竞争力的团队，我们才能按时高质量的完成项目。

在这次的项目中，我们学到了很多。尤为深刻的体会是一个团队如果不能团结在一起，那么它就没有竞争。项目组之间要多交流一边更好的理解别人的思维、项目的进程来及时解决存在的问题以及计划的改进。要对自己准确定位知道自己能胜任什庅样的工作以及在那一方面最擅长可以做得很好。

很荣幸，在本次项目开发中，我个人承担项目小组长的角色，在项目进展过程中，非常感谢项目小组成员对我工作的支持，项目经理对我的信任。感谢在项目开发中，各位领导对项目进度的关注！谢谢！

兰州直方科技有限公司

第三篇：软件测试心得体会

心得体会

六天的培训结束了，感觉过得好快啊。虽然是因为参加“模拟招聘”获得这次机会的，不像其他同学一样是交钱的，但是我也是抱着要学东西的心态参加的。

第一天老师就给了个下马威——教材全是全是英文版的。对于虽然大三的我来说，英语四级刚过，六级成绩还没出来的情况下，想看懂全文是不太现实的。在老师讲解过程中利用在线翻译才勉强能看懂句子。不过培训过程中最难忘的不是来自教材，而是来自老师的那双犀利的眼神。无论何时，只要你打开了与课堂无关的网页，她总会第一时间或叫号码，或叫名字，或站到你旁边。说实话，大学上课已经很久没有这种高中被管的感觉了。虽然不爽，但是却有种回到高中的快感（说的是实话）。

头几天还蛮不错的，食堂开门的，超市没关。可后几天，当校门口已无人烟，就剩我们这几个的时候就真觉得寝室楼好静啊，还不如在机房呆着。对于老师我想说的是，前几天笑容总是挂在脸上，可两天后明显笑的少了，不知道是不是因为和大家熟了，没有刚见面的客气了（我喜欢看人笑，本身也喜欢笑，老师的这种变化，我很敏锐的察觉了）。

这次培训虽然感觉学到的没有很多，但是我了解了一个企业，起码是软件测试这一行业大致的运作模式，让我对我将来要不要从事这个行业有了认识。貌似软件测试女生为主，男生比较适合从开发做起，这是我这几天得到的最大体会。还有对于课堂结束的演讲，是个锻炼

自己的好机会，我并不否认这点，不过貌似每个人都只有一次机会，我是个表现欲很强的人，让我讲了一次有点不过瘾。

开始我是因为不想浪费免费来上课的就会，来到后我觉得确实很多时候是需要多接触下这些社会上的公司、企业等，毕竟还有一年就毕业了，到底何去何从自己是真的要好好做个打算了。期待下一期的网新的培训„„

第四篇：软件测试心得

《软件测试心得体会》

软件测试在整个软件周期中的重要性。它存在于整个项目周期，在项目开始

下面简单谈谈我的几点体会：

体会一：

体会一：软件测试在整个软件周期中的重要性。

它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。

体会二：软件测试的真正意义在于发现错误，而不在于验证软件是正确的。

再严密的测试也不能完全发现软件当中所有的错误，但是测试还是能发现大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。

体会三：在系统性能测试方面需要重视。

经过这次培训中多个案例的讲解，让我了解到系统在上线之后会有很多不能预知的性能问题，需要在上线之前实现进行模拟，以规避风险，包括大数据量访问，高并发数等等。当然也有很多应对手段，没有哪种手段可称为最完美，只有最合适的，需要灵活掌握，综合运用以达到最优程度，这是个很值得研究的领域。

下面是我的几点想法：

想法一：加强系统上线前的性能测试。

目前我们在项目建设过程中对性能压力测试的重视程度还不太高，厂家也很少有雇佣第三方的测试机构。而是在现网进行试用，遇到问题再解决，可能会产生滞后问题，影响客户使用。希望以后能在性能测试方面提高重视程度，加大人力投入，以保证系统上线后能够稳定运行。

想法二：适当介入相关项目研发

对于快速响应这块，我们不能一味依赖厂家，而希望自己就能快速响应，及时将问题解决。这也是一个比较长远的问题，需要加强研发力量的投入。

我个人是做开发出身，有此类经验，当时是在客户现场，因为了解系统内部结构，能够在第一时间排查解决客户所反馈问题。

现在系统完全由厂家开发，很难了解内部结构，或许会造成后期维护困难。所以，是否应该针对某些项目介入厂家研发工作，比如请厂家提供源代码等相关要素，以增进维护人员对系统的了解。

最后再次感谢公司提供的平台，感谢领导的信任，让我有机会得到更深层次的学习以及展示自己能力的机会，我也会尽我所能来完善工作的系统，提高整体工作效率，为南方电网的发展建设提供更坚实，优秀的支撑服务平台。

第五篇：软件测试总结

面向对象程序的软件测试方法

在软件生命周期过程中，软件测试是保证软件质量的关键环节之一。面向对象方法学在软件工程中的引入极大地方便了软件的设计、开发和维护，为创建高可靠性的软件系统提供了重要保证。但面向对象程序的封装、继承、多态和异常处理机制等新特性却给测试带来新的挑战。一方面需要调整、改进传统的测试策略和方法；另一方面探索出适应面向对象程序特征的测试理论与技术也尤为必要。

面向对象(Object Oriented,OO)是当前计算机界关心的重点，它是90年代软件开发方法的主流。面向对象的概念和应用已超越了程序设计和软件开发，扩展到很宽的范围。如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。

面向对象的定义或说明对象的定义的非常少。其初，“面向对象”是专指在程序设计中采用封装、继承、抽象等设计方法。可是，这个定义显然不能再适合现在情况。面向对象的思想已经涉及到软件开发的各个方面。如，面向对象的分析（OOA，Object Oriented Analysis），面向对象的设计（OOD，Object Oriented Design）、以及我们经常说的面向对象的编程实现（OOP，Object Oriented Programming）。许多有关面向对象的文章都只是讲述在面向对象的开发中所需要注意的问题或所采用的比较好的设计方法。看这些文章只有真正懂得什么是对象，什么是面向对象，才能最大程度地对自己有所裨益。这一点，恐怕对初学者甚至是从事相关工作多年的人员也会对它们的概念模糊不清。

1、面向对象的基本概念

(1)对象。

对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。

(2)对象的状态和行为。

对象具有状态，一个对象用数据值来描述它的状态。

对象还有操作，用于改变对象的状态，对象及其操作就是对象的行为。

对象实现了数据和操作的结合，使数据和操作封装于对象的统一体中

(3)类。具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。

类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。

类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。

(4)类的结构。

在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。

①一般——具体结构称为分类结构，也可以说是“或”关系，或者是“is a”关系。

②整体——部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“has a”关系。

(5)消息和方法。

对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。

类中操作的实现过程叫做方法，一个方法有方法名、参数、方法体。消

2、面向对象的特征

(1)对象唯一性。

每个对象都有自身唯一的标识，通过这种标识，可找到相应的对象。在对象的整个生命期中，它的标识都不改变，不同的对象不能有相同的标识。

(2)分类性。

分类性是指将具有一致的数据结构(属性)和行为(操作)的对象抽象成类。一个类就是这样一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。任何类的划分都是主观的，但必须与具体的应用有关。

(3)继承性。

继承性是子类自动共享父类数据结构和方法的机制，这是类之间的一种关系。在定义和实现一个类的时候，可以在一个已经存在的类的基础之上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。继承性是面向对象程序设计语言不同于其它语言的最重要的特点，是其他语言所没有的。

在类层次中，子类只继承一个父类的数据结构和方法，则称为单重继承。

在类层次中，子类继承了多个父类的数据结构和方法，则称为多重继承。

在软件开发中，类的继承性使所建立的软件具有开放性、可扩充性，这是信息组织与分类的行之有效的方法，它简化了对象、类的创建工作量，增加了代码的可重性。

采用继承性，提供了类的规范的等级结构。通过类的继承关系，使公共的特性能够共享，提高了软件的重用性。

(4)多态性(多形性)多态性使指相同的操作或函数、过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。

多态性允许每个对象以适合自身的方式去响应共同的消息。

多态性增强了软件的灵活性和重用性。

面向对象方法的基本思想是一：面向对象方法是一种运用对象、类、封装、继承、多态和消息等概念来构造、测试、重构软件的方法。

二： 面向对象方法是以认识论为基础，用对象来理解和分析问题空间，并设计和开发出由对象构成的软件系统（解空间）的方法。由于问题空间和解空间都是由对象组成的，这样可以消除由于问题空间和求解空间结构上的不一致带来的问题。简言之，面向对象就是面向事情本身，面向对象的分析过程就是认识客观世界的过程。

面向对象方法从对象出发，发展出对象，类，消息，继承等概念。

面向对象方法的主要优点是：符合人们通常的思维方式；从分析到设计再到编码采用一致的模型表示具有高度连续性；软件重用性好。

面向对象软件测试的特点是: 1.掌握代码检查、走查与评审的基本方法和技术； 2.掌握白盒测试和黑盒测试的测试用例的设计原则和方法； 3.掌握单元测试和集成测试的基本策略和方法；

4.了解系统测试、性能测试和可靠性测试的基本概念和方法； 5.了解面向对象软件和WEB应用软件测试的基本概念和方法； 6.掌握软件测试过程管理的基本知识和管理方法； 7.熟悉软件测试的标准和文档；

8.掌握QESuite软件测试过程管理平台和QESat/C++软件分析和工具的使用方法。