软件测试与维护
动态测试
1 黑盒测试/功能测试/数据驱动测试
1)要求:对接口测试,给输入看输出是否正确、不需了解内部
2)常用方法
1)等价类划分(对一个用例划分不同情况,每种情况测试一次(成绩优良))
2)边界值分析(在边界两边选值测试(及格与不及格))
3)错误推测(根据测试经验,选测试用例测试)
4)因果图
2 白盒测试/结构测试/透明盒测试/逻辑功能测试/基于代码测试
1)要求:测试人员了解程序内部结构和处理过程,对逻辑路经测试,检查内部控制结构和数据结构是否有错、是否达到预期运行状态
2)用例设计方法(发现错误的能力由弱变强):
1)语句覆盖:每句语句至少执行一次(如if else都行执行过就ok,不考虑if不通过的情况)
2)判定覆盖:每个判定分支至少执行一次(把一个判断语句看作一个整体,使每个分支的值都被至少执行一次)
3)条件覆盖:每个判定的每个条件(满足语句覆盖,取分支各个表达式的两个边界值,使这两种值都被至少执行过一次即可)应取到各种可能的值
4)判定/条件覆盖:满足判定覆盖、条件覆盖
5)条件组合覆盖:判定中各条件的每一种组合至少出现一次(每个分支中的一/多个条件*组合得到多个组合,使这些组合都执行一次)
6)路径覆盖:程序中每一条可能的路径(一条语句到另一条语句/重点)至少执行一次
3 灰盒测试
1)概念:介于白盒测试与黑盒测试之间的测试
2)关注:输入正确性行及内部表现(关注较浅)
3)适用:在系统组件的协同性环境中评价应用软件的设计
静态测试
人为观察、分析发现错误(不运行)
1 桌前检查
1)人员:程序员检查
2)任务:对源程序进行分析、检验、并补充文档
3)目的:发现程序中错误
2 代码审查
1)人员:若干程序员和测试员组成
2)流程:发各种文档规范、召开程序审查会(解释逻辑、对照错误检查表提出问题、讨论修改)
3 代码走查
1)人员:程序员、测试人员
2)流程:发材料并阅读程序、与会者在脑中运行,找出错误、不规范
软件维护
占软件生命周期的60%-80%
1 软件可维护性:维护人员对该软件进行维护的难易程度
2 衡量因素:可理解性、可测试性、可修改性
3 类型
1)改正性维护(20%):开发阶段已发生而系统测试阶段尚未发现的错误
2)适应性维护(25%):软件被动适应环境(如android ios)
3)完善性维护(50%):为扩展功能和改善性能而进行的修改
4)预防性维护(5%):为了改进软件的可靠性和可维护性,为了适应未来的变化,主动做出的变化
4 影响维护工作量的因素
系统大小、系统设计语言、系统年龄、数据库技术的应用、先进的软件开发技术
软件质量
1 概念:软件与用户需求的一直程度
2 特点
1)用户需求是度量软件质量的基础(应不少不多)
2)制定的标准定义了一组指导软件开发的准则
3)没有显示描述的隐含需求(默认满足的要求)
3 度量
1)ISO/IEC9126软件质量模型
3个层次:质量特性、质量子特性、度量指标
*1 功能性(满足功能及其性质)
适合性(有此功能)、准确性(准确完成功能)、互操作性(共享)、依从性(符合法规、规范)、安全性(未经授权,不可访问)
2 可靠性(规定时间和条件下,性能保持在标准之上)
成熟性(软件故障引起失效的品读有关)、容错性(操作错误,正常工作)、可恢复性(出错后回复时间)
3 易用性(大众皆可)
4 效率:时间特性:响应、处理时间;资源特性:使用的资源数量、种类
5 可维护性:易分析性:易了解错误原因;修改性:改后基本对,而不是改一处错全部
6 可移植性:适应性:适应多种环境;可替代性:替代其他软件的难易程度
*
4 软件质量保证:为保证软件系统充分满足用户要求的质量而进行有计划、有组织的活动,目的:生产高质量软件
5 手段:
1)开发初期制定质量保证计划
2)开发前选定制定开发标准、开发规范
3)选择分析设计方法和工具,形成高质量分析模型 设计模型
4)严格执行阶段评审,及时发现问题
5)进行阶段测试
6)严格执行变更控制流程
7)有完整阶段文档
6 CMM(软件能力成熟度模型)
初始级:软件过程无序、软件管理反应式、成就取决于个人
可重复级:建立了基本项目管理过程、制定了规章制度、依靠经验取得成功
已定义级:将软件管理和工程文档化、标准化,开发过程受控
已管理级:软件过程和产品质量可度量,对软件过程和产品有定量的理解与控制
优化级:过程的量化反馈和先进的思想、新技术使过程持续不断改进
7 CMMI(软件能力成熟度集成模型)
初始级、可管理级、严格定义级、定量管理级、优化级
软件项目管理
1 内容:范围管理、进度管理、费用管理、质量管理、整体管理、人力资源管理、沟通管理、风险管理、采购管理
2 软件项目估算
1)软件规模的估算
1)LOC估算法(代码行估算法)
将项目划分为小模块,通过**经验**估算软件的代码行数
2)FP估算(功能点估算)
FP(功能点)是一种衡量工作量大小的单位
FP=信息处理规模*技术复杂度
信息处理规模:外部输入数、外部输出数、外部查询数、内部逻辑文件数、外部接口文件数
技术复杂度=0.65(基础)+调节因子
2)软件工作量的估算
COCOMO模型,三级
1)基本COCOMO模型:用已估算出的代码行数(LOC)为自变量的经验函数计算软件开发工作量(人*天)
2)中间COCOMO模型:基本模型的基础上,再用涉及产品、人员等的影响因素调整工作量的估算。
3)详细COCOMO模型:在中间模型基础上,分层(模块层、子系统层、系统层)估算
3)成本估算
3 风险管理
对项目风险从识别到分析乃至采取应对措施等一系列过程
1)编制风险管理计划
2)风险识别(找到存在的风险)
发现风险方法:头脑风暴法(记录每人提出风险)、专家评估法(专家指出)、风险检查表(与表一一对应检查)、假设分析(假设存在看是否有)
风险类别:需求风险(需求变更)、技术风险(是否拥有技术及其实现能力)、团队风险、关键人员风险(核心人员不可流失)、预算风险(少算/多算)、范围风险(范围变更)
3)定性风险分析(发生概率、影响程度)
4)定量风险分析(3的具化)
5)风险应对计划的编制
6)风险跟踪和监控
4 项目计划编排的方法与技术
1)计划评审技术(PERT)
完成时间估算(各个阶段计算后求和):
1)乐观估算:一切顺利的情况下完成某项工作的时间
2)最可能时间:正常情况完成某项工作(把正常情况下的出错囊括在内)的时间
3)悲观时间:最不利的情况下,完成某项工作的时间
开方就是方差开方
2)甘特图/横道图
以横线表示活动起止时间
优点:简单、明了、直观、易于编制、小型项目或高层了解
缺点:不能表达复杂的逻辑关系,不能进行定量计算、不能突出关键活动
3)关键路径法(重点)(CPM)
1)概念:借助网络图和各活动所需时间(估计值),计算每一活动最早/迟开始、结束时间
2)核心:将工作分解结构(WBS)分解的活动按逻辑关系加以整合,统筹计算出整个项目的工期和关键路径
3)每个活动参数
最早开始时间(ES)
最早结束时间(EF)EF=ES+工期估计
最迟结束时间(LF)
最迟开始时间(LS) LS=LF-工期估计
4)两个规则
1)某项活动的最早开始时间必须相同或晚于直接指向这个活动的最早结束时间的最晚时间(通向某个的所有路径中最长路径、正向推)
2)某项活动最迟结束时间必须相同或早于该活动直接指向的所有活动最迟开始时间的最早时间(反向推,一个点指向两个点,指向其中开始时间早者)
5)总时差
一项工作在不影响总工期的前提下所具有的**机动时间/松弛时间**
总时差=该工作最迟完工时间-该工作最早完工时间
总时差=该工作最迟开工时间-该工作最早开工时间
6)关键路径
1)最早开始时间和最晚开始时间相等的活动成为关键活动
2)关键活动串联起来成为关键路径
3)关键路径长度即为项目的工期
1)总持续时间最长的称为关键线路
2)总时差最小的工作组成的线路为关键线路
7)*时差
一项工作在不影响其紧后工作最早开始时间的条件下可利用的机动时间=该工作的紧后工作最早开工时间-该工作最早完工时间