一、基础
1.1 软件概述
软件生命周期
- 需求分析:研发分析需求说明书,判断需求的可实现性。
- 概要设计:用到具体的技术点,大致模块划分
- 详细设计:详细到可以为编码做支持,类和类关系,类的设计,函数设计,各个接口的细节、数据库 表的关系,字段关系
- 编码:依托于详细设计进行编码操作。
- 测试:
- 维护:上线后也是需要持续维护
1.2 软件开发模型
1.2.1 瀑布模型
瀑布模型的特点
(1)是线性模型的一种,在所有模型中占有重要地位,是所有其他模型的一个基础
(2)每一个阶段执行一次,文档驱动(每—步都有文档产出),按线性顺序进行软件开发。
瀑布模型的优缺点
优点:
(1)开发的各个阶段比较清晰。
(2)当前一阶段完成后,只需关注后续阶段。
缺点:
(1)依赖于早期的需求调查,不适应需求的变化。
(2)风险往往延至后期才显露,失去及早纠正的机会。
1.2.2 快速原型模型
和瀑布模型相反,快速原型模型是在最初确定用户需求时快速构造出一个可以运行的软件原型,这个软件原型向用户展示待开发软件的全部或部分功能和性能,客户对该原型进行审核评价,然后给出更具体的需求意见,这样逐步丰富细化需求。
快速原型模型的特点
快速原型模型的优缺点
优点:
(1)克服瀑布模型的缺点,更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。
缺点:
(1)不适合大型系统的开发(适合开发小型的、灵活性高的系统)。
1.2.3 迭代模型
迭代模型又称为增量模型或演化模型,它将一个完整的软件拆分成不同的组件,然后逐个组件地开发测试,每完成一个组件就展现给客户,让客户确认这一部件功能和性能是否达到客户需求,最终确定无误,将组件集成到软件体系结构中。
迭代模型的特点
整个开发工作被组织为一系列短期、简单的小项目,称为一系列迭代,每一个迭代都需要经过需求分析→软件设计→编码→测试的过程
迭代模型的优缺点
优点:
(1)在较小的迭代中进行测试和调试很容易。
(2)并行开发可以计划。
(3)对于不断变化的项目需求而言, 这是很容易接受的。
(4)在迭代过程中识别并解决风险。
(5)在文档上花费的时间有限, 在设计上花费了额外的时间。
缺点:
(1)不适用于较小的项目。
(2)可能需要更多资源。
(3)由于不完善的要求, 可以一次又一次地更改设计。
(4)需求变更可能会导致预算超支。
(5)由于需求变更, 未确认项目完成日期。
1.2.4 螺旋模型
制订计划、风险分析、实施工程、客户评估,各象限含义如下:
(1)制订计划:确定软件目标,制订实施方案,并且列出项目开发的限制条件。
(2)风险分析:评价所制订的实施方案,识别风险并消除风险。
(3)实施工程:开发产品并进行验证。
(4)客户评估:客户对产品进行审核评估,提出修正建议,制订下一步计划。在螺旋模型中,每一个迭代都需要经过这4个步骤,直到最后得到完善的产品,可以进行提交。
螺旋模型的特点
螺旋模型的优缺点
优点:
(1)螺旋模型很大程度上是一种风险驱动的方法体系。
缺点:
(1)采用螺旋模型需要具有相当丰富的风险评估经验和专门知识。
1.2.5 敏捷模型
敏捷模型以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
在敏捷模型中,软件项目在构建初期被拆分为多个相互联系而又独立运行的子项目,然后迭代完成各个子项目,开发过程中,各个子项目都要经过开发测试。当客户有需求变更时,敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。在这个过程中,软件一直处于可使用状态。
敏捷模型的特点
(1)需要频繁更改。
(2)有一支高素质和经验丰富的团队。
(3)当项目规模较小时。
敏捷模型的优缺点
优点
(1)频繁交货
(2)与客户面对面的交流。
(3)高效的设计并满足业务需求。
(4)随时可以接受更改。
(5)它减少了总的开发时间。
缺点
(1)由于缺少正式文件, 因此会造成混乱, 并且各个团队成员随时可能会误解贯穿各个阶段做出的重要决定。
(2)由于缺乏适当的文档, 一旦项目完成并且开发人员被分配到另一个项目, 完成的项目的维护就会变得很困难。
1.3 软件质量概述
软件质量是指软件产品满足基本需求及隐式需求的程度。软件产品满足基本需求是指其能满足软件开发时所规定需求的特性,其次是软件产品满足隐式需求的程度
实际需求 :是用户的目的
隐式需求 :是用户未表达的而对产品的期待
显示需求 :是用户对产品需求的表达。
软件质量国际标准的6大特性:
(1)功能性:在指定条件下,软件满足用户显式需求和隐式需求的能力。
(2)可靠性:在指定条件下使用时,软件产品维持规定的性能级别的能力。
(3)可使用性:在指定条件下,软件产品被使用、理解、学习的能力。
(4)效率:在指定条件下,相对于所有资源的数量,软件产品可提供适当性能的能力。
(5)可维护性:指软件产品被修改的能力。修改包括修正、优化和功能规格变更的说明。
(6)可移植性:指软件产品从一个环境迁移到另一个环境的能力。
1.4 软件缺陷管理
1.4.1 软件缺陷产生的原因
- 需求不明确
- 软件结构复杂
- 开发人员水平有限
- 项目期限短
- 使用新技术
1.4.2 软件缺陷的分类
1.4.3 软件缺陷的处理流程
1.5 软件测试概述
1.5.1 软件测试的分类
按照测试阶段分类
- 单元测试:验证软件单元是否符合软件需求与设计,开发人员自测。
- 冒烟测试:软件构建版本建立后,对系统的基本功能进行简单的测试,这种测试重点验证的是程序的主要功能,而不会对具体功能进行深入测试。
- 集成测试:冒烟测试之后,将已经测试过的软件单元组合在一起测试它们之间的接口,用于验证软件是否满足设计需求。
- 系统测试:将经过测试的软件在实际环境中运行,并与其他系统的成分(如数据库、硬件和操作人员等)组合在一起进行测试。
验收测试:主要是对软件产品说明进行验证,逐行逐字的按照说明书的描述对软件产品进行测试,确保其符合客户的各项要求。
按照测试技术分类
黑盒测试:把软件(程序)当作一个有输入与输出的黑匣子,它把程序当作一个输入域到输出域的映射,只要输入的数据能输出预期的结果即可,不必关心程序内部是怎么样实现的。
白盒测试:又叫透明盒测试,它是指测试人员了解软件程序的逻辑结构、路径与运行过程,在测试时,按照程序的执行路径得出结果。
按照软件质量特性分类
按照软件质量特性可以将软件测试分为功能测试与性能测试。
功能测试:功能测试就是测试软件的功能是否满足客户的需求,包括准确性、易用性、适合性、互操作性等
性能测试:性能测试就是测试软件的性能是否满足客户的需求,性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。
按照自动化程度分类
手工测试︰测试人员一条一条的执行代码完成测试工作。费时费力且很验证保证测试效果。
自动化测试︰借助脚本、自动化测试工具等完成相应的测试工作,它也需要人工的参与,但是它可以将要执行的测试代码或流程写成脚本,执行脚本完成整个测试工作。
按照测试项目分类
界面类测试:验证软件界面是否符合客户需求。
- 安全性测试:试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理,是否能保证软件与数据的安全。
文档测试:以需求分析、软件设计、用户手册、安装手册为主,主要验证文档说明与实际软件之间是否存在差异。
其他分类
α测试(内测):软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题,整个测试过程是可控的。
- β测试(公测):软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录,然后反馈给开发人员进行修复。
- 回归测试:对修改后的程序重新进行测试确认原有的缺陷已经消除并且没有引入新的缺陷,这个重新测试的过程就叫作回归测试。
- 随机测试:没有测试用例、检查列表、脚本或指令的测试,它主要是根据测试人员的经验对软件进行功能和性能抽查。
1.6 软件测试与软件开发
软件测试在项目各个阶段的作用
(1)项目规划阶段:负责从单元测试到系统测试的整个测试阶段的监控。
(2)需求分析阶段:确定测试需求分析,即确定在项目中需要测试什么,同时制订系统测试计划。
(3)概要设计与详细设计阶段:制订单元测试计划和集成测试计划。
(4)编码阶段:开发相应的测试代码和测试脚本。
(5)测试阶段:实施测试并提交相应的测试报告。
1.6.1软件测试模型
V模型
V模型是瀑布模型的变种,在瀑布模型的后半部分添加了测试工作。
V模型的优缺点
优点:
- 测试v模型即包含了底层测试又包含了高层测试;
- 包含了底层和高层的测试过程
- 每个步骤都是文档驱动的
缺点:
- 当需求变更时将会导致阶段反复,返工量非常大,模型灵活性比较低。
W模型
W模型是由V模型演变而来的,它强调测试应伴随整个软件生命周期。W模型的测试范围不仅包括程序,还包括需求分析、软件设计等前期工作。
W模型的优缺点
优点:
- 强调测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求和概要设计同样要测试
- 更早地介入测试,可以发现开发初期的缺陷,那么可以用更加低的成本进行缺陷修复。
缺点:
- 使用起来技术复杂度高,对于需求和设计的测试要求高,实践起来困难。
H模型
H模型将测试活动完全独立了出来,形成一个完全独立的流程,这个流程将测试准备活动和测试执行活动清晰地体现出来。测试流程和其他工作流程是并发执行的,只要某一个工作流程的条件成熟就可以开始进行测试。
X模型
X模型的设计原理是将程序分成多个片段反复迭代测试,然后将多个片段集成再进行迭代测试。
1.7 软件测试原则
- 测试应基于客户需求
- 测试要尽早进行
- 穷尽测试是不可能的]
- 遵循GoodEnough原则
- 测试缺陷要符合“二八”定理
- 避免缺陷免疫。