软件质量

摘要： 随着科学技术的飞速发展，软件的功能越来越强大，软件的复杂性也越来越高，从而大大增加了软件测试与可靠性评估的难度。为了保证一个软件系统的质量，有必要针对软件的测试与可靠性评估方法进行专门地研究。本文就是针对这一领域所做的一些研究。 　　 一.软件测试的定义 　　软件测试（Software testing）是软件生存期（Software life cycle）中的一个重要阶段，是软件质量保证的关键步骤。通俗地讲，软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码进行最终复审的活动。1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。 　　从用户的角度来看，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，所以软件测试应该是“为了发现错误而执行程序的过程”。或者说，软件测试应该根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误或缺陷。 　　 二.软件测试的生命周期 　　测试主要依据是被试系统的研制任务书和技术规格书，是对软件整体功能和性能的综合测试与评估

6.1 软件测试过程 活动及内容： 　软件测试贯穿整个软件开发周期，软件过程中的关键活动包括提取测试需求、确定测试范围、制定测试计划、开展测试设计、执行测试用例、分析测试结果等 　具体活动及内容： 　　-- 需求与规范管理（需求阶段） 目标：确定测试需求 　　　　* 需求人员确定规范和需求，并发给项目经理、开发经理、开发和测试人员 　　　　* 需求评审，确定最终实现的需求和功能点 　　　　* 开发估算开发工作量 　　　　* 测试对需求文档进行检查并修复完善，测试估算测试工作量 　　-- 项目计划于测试计划（产品设计阶段） 　　　　* 开发根据工作量和需求初步确定开发计划、测试计划和发布时间 　　　　* 开发负责人估算工作量和项目计划 　　　　* 测试负责人估算工作量和测试计划 　　　　* 讨论修改并定稿 　　-- 开发设计与评审（产品设计阶段） 　　　　* 开发人员为主，测试人员可以参与了解被测软件的设计情况 　　-- 测试方案与评审（产品设计阶段） 　　　　* 项目设计阶段，测试负责人编写测试方案 　　　　* 发送相关人员 　　　　* 评审，修改，最终确定 　　-- 测试设计与评审（开发阶段） 　　　　* 编写详细用例设计，包括功能、性能、压力等 　　　　* 用例评审 　　-- 编码实现和单元测试（开发阶段、测试阶段） 　　-- 测试实施（测试阶段） 　　　　* 执行测试

网址 简介 http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考 http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站 http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛 http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表 http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局（NASA)投资设立的一个软件可靠性和安全性研究中心，研究包括了度量、工具、风险等各个方面 http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织，可以提供研究论文的下载 http://sepo.nosc.mil 内容来自美国SAN DIEGO的软件工程机构（Sofrware Engineering Process Office)主页，包括软件工程知识方面的资料 http://www.asq.org/ 是世界上最大的一个质量团体组织之一，有着比较丰富的论文资源

软件测试相关的63个国外站点 网址 简介 http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考 http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考 网站 http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛 http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表 http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局（NASA)投资设立的一个软件可靠性和安全性研究中心， 研究包括了度量、工具、风险等各个方面 http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织，可以提供研究论文的下载 http://sepo.nosc.mil 内容来自美国SAN DIEGO的软件工程机构（Sofrware Engineering Process Office)主页，包括软件工程知识 方面的资料 http://www.asq.org/

目录 开篇 第一步，成为互联网时代合格的测试工程师 第二步，成为互联网时代优秀的测试工程师 第三步，成为互联网时代的测试架构师 开篇 第一步，成为互联网时代合格的测试工程师 如果你是入行不满 3 年的测试工程师，一定对此有迫切需求。此时，你必须具有快速学习的能力，能迅速掌握被测软件的业务功能与内部架构，并在此基础上运用各种测试方法，尽可能多地发现潜在缺陷，并能够在已知缺陷的基础上进一步发现相关的连带缺陷。从知识体系上看，你需要有比开发人员更全面的计算机基础知识，还需要了解互联网的 基础架构、安全攻击、软件性能、用户体验和常见缺陷 等知识。从测试技术上看，你需要能够使用 常见的测试框架或者工具，需要具有一定的自动化测试脚本的开发能力 ，这可以把你从大量重复的工作中解放出来，然后你才能有时间去做更有意思的工作。 第二步，成为互联网时代优秀的测试工程师 如果你想从“合格”变为“优秀”，那必须先认识到两者的差距在哪里。 首先，合格的测试工程师关注的是纯粹的测试，而优秀的测试工程师关注更多的是软件整体的质量，需要根据业务风险以及影响来制定测试策略，有效控制测试的时间和成本，并且能够对测试框架以及工具做出适合项目需求的选型 。以新房装修为例，合格的测试工程师就是各个工序的装修师傅，他们只管按照设计要求做好自己的工序，而优秀的测试工程师更像是个包工头，他们关心的是 整体交付的质量 。其次

统观软件质量属性，一般分为六大质量属性：可用性分析，可修改性分析，性能分析，安全性分析，可测试性分析，易用性分析。今天我将主要针对可修改性进行阐述。 可修改性可以理解为：指系统或软件的能够快速地以较高的性价比对系统进行变更的能力。比如说：对于一个网站，我们要修改它某一板块的UI界面，当我们对界面进行修改时是否会引起对另一个UI模块的影响，是否会引起后台控制，业务逻辑代码的变更，是否会引起整个网站的崩溃，这体现了一个网站的整个架构的是否具备可修改性。 我们为什么要修改我们的代码呢？原因有很多，但是统一来说就是个需求的问题：它可包含两个方面：1、用户需求，2、系统内在需求。在这解释下需求，成本，修改三者的关系：需求无处不在，时时刻刻产生，判别一个需求的重要性来自于它对系统的成本产生的影响，如果严重影响了系统带来的收益，那必须对系统进行修改，如果某一部分相对于系统收益来说微不足道，甚至不会影响系统的收益，那改不改都“无可厚非”，可能你对这部分修改了还引起系统故障了咋办。例如：一个网站的图标有人觉得不好看，有人觉得不错。使用的人们已经习惯这个图标的表示或者惯性的认为这个图标代表什么。那么是否对这个图标进行修改？我以为没有必要修改，如果你修改了反而可能会引起使用者的错误判断，比如：这个网站是停止运维了吗？好，那我去用其他的系统吧。类似错误的判断会影响到系统的收益，所以不进行修改就挺好的。

软件测试方法种类繁多，记忆起来混乱， 因此，我通过查阅资料，参考一些书籍，把常用的软件测试方法列出来，方便认识软件测试的方法。 从测试设计方法分类 测试名称 测试内容 Black box 黑盒测试 把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。从软件的行为，而不是内部结构出发来设计测试. White box 白盒测试 设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。 Gray box 灰盒测试 介于黑盒和白盒之间 总结： 实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。 从测试是手动还是自动上分类 测试名称 测试内容 Manual Test 手动测试 测试人员用鼠标去手动测试 （测试GUI） Automation 自动化测试 用程序测试程序 （测试API） 对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试。 对于软件测试人员个人发展来说， 做自动化测试是个挑战，也是测试人员发展的一个方向，需要测试人员学习大量的开发知识。从长远角度来看，自动化测试肯定是越来越吃香的。

一、基本信息 标题：时序扩展的UML状态图的测试用例生成研究 时间：2014 出版源：西南大学 领域分类：时序扩展；UML状态图；测试用例；需求规格说明；模型 二、研究背景 问题定义：时序扩展的UML状态图的测试用例生成研究 难点：了解透彻相关的理论基础；知晓充分性准则、UML状态图的时序扩展； 相关工作：学习软件测试基础理论，了解UML及其建模技术；看懂UML状态图； 三、创新方法 1.理论基础和建模技术相结合，发挥了充分性准则的作用； 四、实验 实验1：相关理论基础 要探究的问题:软件测试基础理论；基于模型的测试用例生成简介；UML状态图。 结论：作为检测和控制软件质量的重要手段，软件测试伴随着软件从设计到完成开发的整个生命周期。一个科学的合理的软件开发过程，软件测试与软件的设计和幵发是同步进行的。 模型可以理解为对要处理的系统或者问题，在某些角度或者某些特定层次上进行 的抽象化的描述，使其更加简单，方便人们理解其本质。采用合理的手段对软件进行建模 ，可以使软件的开发者更好地把握 软件的开发需求。将模型的思想应用与测试用例生成过程中， 就是将软件测试的活动进行模型的抽象化。 状态图是一种可以对系统动态行为建模的图形，用于描述系统类对象的生命周期中所有的状态 ，以及当特定事件发生时所引起的类对象状态的转移，可反映系统根据不同事件的发生导致类实体发生状态转移的状况

软件测试最早可以追溯到1958年的美国第一个载人航天计划-水星计划，当时在该计划中首次诞生了软件测试团队。当然，在此之前也肯定是有软件测试存在的，但远没有这次有了自己的江湖地位。但这也仅仅是软件测试的萌芽，远没有到开宗立派的地步。因为你想想这时候软件也只是萌芽阶段，各种软件的理论，标准都还没有诞生，所以更别提软件测试了，因此很长一段时间内，软件测试时间内是没有什么发展的。 时间到了1975年，这一年，软件行业的一个超级豪门诞生了-微软。我不知道微软是不是第一家纯软件开发的公司，但微软确实使软件开发得到了快速的发展。也是从那时候起，美国的软件行业一骑绝尘。随着软件行业的蓬勃发展，软件的规模越来越大，复杂度也越来越高，随着而来的是软件的质量被逐渐的关注起来，软件测试的理论逐渐得到积累。到了1979年，梅尔斯出版了软件测试第一版本著作《软件测试的艺术》这本书，第一次明确的给出了软件测试的定义“The process of executing a program or system with the intent of finding errors”，至此软件测试算是正式的开宗立派， 有了自己的江湖地位。个人认为现代测试的开端应该就由此开始。推荐大家都去读一读这本书，不一定能学到多少新东西，但是就凭它的江湖地位就足以让大家去瞻仰一下了。 自动化测试的历史演进 软件测试的开宗立派

软件测试的基本知识点 软件的分类 C/S与B/S架构 软件测试的定义 软件测试的目的 软件测试的分类 软件生命周期 生命周期模型 1.瀑布型生命周期模型 2.V模型 3.敏捷开发模型 软件测试的基本流程 测试设计用例设计方法 等价类划分法 边界值分析法 场景法 错误推测法 测试用例的编写与评审 软件的分类 软件分为两大类：系统软件、应用软件。 软件测试的对象是：程序、数据、文档。（主要为程序） C/S与B/S架构 C/S ：就是我们一定要安装安装一个客户端才能够使用的软件。 缺点：每次更新都要更新服务端和客户端。 B/S ：只需一个浏览器就可以访问服务。 优点：只需更新服务器不需要更新浏览器，用户主动性比较高。 软件测试的定义 使用人工和自动的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 软件测试的目的 1.软件测试是为了发现程序存在的代码或业务逻辑错误 2.软件测试是为了检验产品是否符合客户的需求 3.软件测试是为了提高用户的体验 软件测试的分类 按测试技术划分：白盒测试、黑盒测试、灰盒测试 对象是否运行划分：动态测试、静态测试 按不同测试手段划分：手工测试、自动化测试 按测试包含的内容划分：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试 其他测试：冒烟测试、回归测试、探索性测试/自由测试 冒烟测试–>主干