《软件测试概论第二次课》由会员分享，可在线阅读，更多相关《软件测试概论第二次课（32页珍藏版）》请在金锄头文库上搜索。
1、Aeroflot Flight 593 飞行员Yaroslav Kudrinsky在值班飞行时, 第 一次带着他的两个孩子，让孩子们坐在从莫 斯科到香港的国际航班的驾驶舱内。 飞行员开启了自动飞行模式，然后他让孩子 们坐在控制台上，开始是女儿坐在飞行员座 位上. 飞行员调整了飞机的方向，让孩子产生 她在操纵飞机的感觉。其实她并没有真正控 制飞机。Aeroflot Flight 593 然后轮到他儿子坐在飞行员座位上了。跟 他妹妹不同，他真的使劲拉动了操作杆， 只要持续使力30秒，飞机的某些部分就会 自动脱离自动驾驶模式， 改为手动驾驶模 式。 系统果然切换飞机副翼部分成手动控制， 但其他部分仍
2、然是自动模式。 飞机没有给 出一个报警信号，尽管有一个指示灯亮了 ，但很明显飞行员忽略了。因为以前这种 情况应该还有一个听得到的报警信号的。Aeroflot Flight 593 飞机突然向右倾斜飞行）,快速上升后， 立马快速下降。 飞机撞在西伯利亚的一个山坡上，所有 75个乘客和机组人员全部死亡。Therac-25 The Therac-25 是一种放射性治疗仪器，由于超 剂量给药，导致病人死伤多例。仪器已经在 1987年召回，并进行深入的设计修正，包括在 软件失效情况下硬件方式的防护问题。 现在Therac 25事故已经成为美国大学讲解软 件安全性设计与测试的一个经典案例：硬件备 份、互锁
3、和其他的安全保护器件，在许多不同 的系统中现在已经被软件置换，其中包括商用 飞机、核电站和武器系统。 结论：软件不应该单独承担安全的职能华航140航班失事事件 1994年4月26日的夜晚，中华航空公司 140航班的最后一班从台北飞往名古屋的 飞机。当时名古屋的天气情况很好，有 微风，空客 A300-600R 的状况也非常好 ，且刚刚保养过. 这架欧洲产的飞机各性 能指标都很新，几个月前才刚调来跑台 湾海峡这条航线。华航140航班失事事件 当飞机降临跑道只有几英尺的时候，飞 机突然突然倾斜昂头返回天空. 飞行员是 一个有经验的驾驶员，他开始与飞机“搏 斗”甚至开骂。多次试图将飞机拉回跑道 着陆。
4、但是，每一次他的企图都失效了 。华航140航班失事事件 飞行员跟控制系统斗争了三次。每一次 这架飞机都好像只尊崇自己的意愿，在 最后一秒钟总是倔强地抬头升空。在第 三次抬头时，飞机已经失去了所有的速 度，这架空客在空中徘徊着，静止悬立 在一千英尺的跑道空中，突然一阵震颤 摇晃, 撞落在名古屋机场上，231人死亡 。华航140航班失事事件 到底发生了什么？通过黑盒子分析，飞 行员当时把飞机设置为计算机控制的“触 摸-运行”模式, 强迫飞机在降落期间爬 升。这个指令是飞行员设的，目的是让 飞机慢慢掠过跑道，返回天空。华航140航班失事事件 不知道为什么，飞行员试图不管计算机的指令 让飞机下降，但却
5、一直没有关掉计算机控制系 统。 所以每一次的降落，飞机都很忠实地跟随 指令升空。二飞行员坚决要降落，最后形成一 个典型的计算机式的死循环。 思考问题：当程序与手工操作发生矛盾时应该 怎么办？遗憾的是测试没有做。汉莎空客失事事件 1993年9月14日, 汉莎空客A320-200 在一 个恶劣的天气情况下降落波兰华沙机场, 飞行员已被告知有逆风，有雨和寒冷的 气温。为了对付天气情况，飞机下降时 增加了20节的速度，也使用了标准的逆 风降落模式。 其他机翼的倾斜，档位都 是正确的设置。汉莎空客失事事件 由于有风和雨水，飞机降落后的9秒钟其实还 在水中滑行。 风和水夹杂在一起愚弄了飞机的 计算机控制系
6、统， 以为还没有落地. 计算机控 制系统不让刹车系统启动。后果是飞机一直在 跑道滑行，直到撞到一座山。死亡一个工作人 员,一个乘客，45人受伤，飞机彻底毁掉。汉莎空客失事事件 事故报告称，机组人员严格按照空客的 手册：如何在恶劣天气下降落的要求做 的。后来汉莎公司改变了空客的手册程 序，后来再没有类似的事件发生。 空客当然坚持认为他们的控制软件没有 问题 Interesting Quotes “If Microsoft made cars instead of computer programs, product-liability suits might now have driven th
7、em out of business.” if cars were like software, they would crash twice a day for no reason, and when you called for service, theyd tell you to reinstall the engine “Thank the programmer”, Airline pilot after a smooth landingfamous BSOD软件质量 软件测试的核心问题就是：正确客观地衡量软 件质量是很困难的。 质量可以考虑用一系列的软件产品属性及其量 化值来衡量：量
8、化值可以让用户进行打分获取 。软件质量 ISO发布了标准，包括六个主要的属性域。 对用户最重要的属性 对开发者最重要的属性有效性 可维护性 高效性 可移植性 灵活性 可重用性 完整性 可测试性 互操作性 可靠性 健壮性 可用性软件质量属性 functionality (suitability, accurateness, interoperability, compliance, security) reliability (maturity, fault tolerance, recoverability) usability (understandability, learnability
9、, operability) efficiency (time behavior, resource behavior) maintainability (analyzability, changeability, stability, testability) portability (adaptability, installability, conformance, replaceability)软件质量 这些标准大多比较主观，不能在选择测试方法时提 供合适的量化依据。 没有一种方法可以无二意地度量某个属性。对统一 属性用不同方法度量得到不同的结论。 经过充分的测试，开发人员还是不确认产
10、品到底运 行怎么样，直到他们真的实际运行碰到问题时。软件质量 缺乏清晰定义的质量标准使得大多数公司只能 依靠简单的缺陷数目衡量。 单元测试：严重缺陷密度大于15个每千行代码 LOC 但是这些简单的标准在消除用户对产品质量的 不确定方面却没多少作用。比如，兼容性，可 靠性，可维护性等。软件质量量化标准 软件质量的度量方法仍然比较模糊。 商业领域的标准：AIPHA版：在已找到的缺陷中所有严重级别的缺陷被修正并通 过复测。BETA版：次严重缺陷完成修正并通过复测正版：缺陷发现率低于修正率，此距离逐渐拉开并一直保持稳定 的一段时间。 IEEE 提出的候选指标 : fault density requi
11、rements compliance mean time to failure mean time to repair量化标准的标准 简单，可计算: Learning the metric and applying the metric are straightforward and easy tasks 有说服力的: The metrics appear to be measuring the correct attribute. 一致的，客观的: The results are reproducible量化标准的标准 与编程语言独立: The metrics should not be b
12、ased on specific tasks and should be based on the type of product being tested 可以提供反馈信息的: Results from the metrics give useful information back to the person performing the test软件行业的诞生 核心事件是1969 年美国司法部要求IBM取消它的软 件跟它自己的硬件产品的捆绑销售策略。 避免用户 既要买它的软件又要买它的硬件。 在这之前，几乎所有的和应用软件都是由硬件 制造商开发的，主要就是,或者由少量的小型 团队接受定制
13、软件订单 ，导致一种软件产品只能为 一种产品服务兼容。软件测试的历史 软件开发强调写代码以及测试部分给定的代 码段，不重视对于较大系统的开发，这些方法 是否适合。测试被看成是向用户证明软件产品能否正常运 转的魔鬼。软件测试的历史测试跟其他软件工程革新一样是从“软件危机 ”中演变来的。包括：工程，CMM，OO，软 件过程。Software Crisis危机涉及到过程的复杂性，作为一个行业的软 件工程，它的不成熟表现形式有：超钱 超期，质量低下， 不满足需求 项目难管理，代码难易维护。软件测试的历史 分为四个阶段：质量成为目标；软件工程成为研究领域；软件生命周期或过程开始研究；自动化测试开始；软件
14、测试的历史1970s: testing as a discipline（科目）; it became a separate task from debugging 1979-1982: the destruction oriented period, where the goal was to find errors 1983-1987: the evaluation oriented period: the intention here was that during the software lifecycle a product evaluation was provided and q
15、uality measured From 1988 to now: the prevention oriented period where tests are to demonstrate that the software satisfies its specification, and to detect and prevent faults软件测试时间分布The sooner you start coding the longer it will take to finish the program. Ideally, more time should be spent on planning and testing according to Brooks in the Mythical Man Month, 1975软件测试时间分布 50%Brooks/Myers, 1970s 80%Arthur Andersons Director of testing in North America, 1990s工作量分配 工作量分配 Since the 1970s, software developers beg
