软件缺陷
-
错误
人们在开发软件过程中发生的过错
-客户可能未完全描述清楚他的意图
-分析人员未完全理解客户的需求、编写出不完善的需求文档
-设计人员未完全弄清楚需求文档描述的问题
-实现人员受限于自身能力及工作状态编写出不完善的程序
软件错误是一种人为的过程，对于软件本身来讲是一种外部行为 -
缺陷
错误在程序中的表现
存在于软件（文档、数据及程序）之中的那些不希望或不可接受的偏差
当缺陷被激活时，会发生软件故障
缺陷是造成软件故障甚至失效的内在原因
常用bug代指缺陷 -
故障
软件运行过程中出现的不希望/不可接受的内部状态
软件丧失了在规定的限度内执行所需功能的能力
故障是动态的，可能会导致失效
故障是软件缺陷的内在表现 -
失效
软件运行时产生的不希望/不可接受的外部行为结果
系统行为对用户预期的偏离
失效是软件缺陷的外在表现，只有运行中的软件才可能发生失效
软件缺陷类型
- 软件未实现需求规格说明书要求的功能
- 软件出现了需求规格说明书指明不应该出现的错误
- 软件实现了需求规格说明书中未提到的功能
- 软件未实现需求规格说明书虽未明确提及但应该实现的功能
- 软件难以理解、不易使用、运行缓慢等，即：用户体验不佳
缺陷原因
导致软件缺陷的最大原因是需求规格说明书
- 需求分析员不懂用户业务，对用户需求在理解上发生偏差
- 编写的需求规格说明书不够完整，甚至没有编写需求文档
- 用户需求发生了变化，但规格说明书没有同步更新
- 需求规格说明书主要采用自然语言描述，往往带来一定的歧义
- 编写的需求规格说明书没有及时让用户确认
团队协作问题
- 不同阶段的团队成员相互理解不一致
- 相互职责划分不够清晰，存在扯皮推诿情况
- 沟通不够充分，对接口的理解不一致，造成单元无法集成
- 公司或团队文化，对软件质量不够重视
未考虑复杂应用场景
- 未考虑大量用户同时使用软件系统的情况
- 未考虑海量数据使用场合
- 对于边界条件缺乏考虑
- 只考虑正常情况，对于异常情况未充分考虑
- 对于一些实时性系统，未进行整体考虑和精心设计，未注意时间同步要求
技术方面问题
- 开发人员的技术具有局限性
- 新技术不成熟或对新技术不够熟练，使得软件存在缺陷
- 用户的要求在现有技术水平下不可能实现
- 软件逻辑过于复杂，在问题分解时划分的不够合理
软件工程优秀实践
-
迭代式开发
瀑布模型：需求分析-设计-编码及单元测试-集成-系统测试
不足：延迟发现关键风险方案是否合理，通过评估工作量来度量项目进展，难以预测软件完成时间-太晚进行集成和测试工作-不能较早的进行部署-经常导致项目延期 -
管理需求
-
使用组件架构
-
可视化建模
-
持续验证质量
-
管理变更
软件缺陷分类方法
- 以缺陷产生的开发阶段来划分
- 以缺陷的修复成本来划分
- 以缺陷产生的后果来划分
- 以解决缺陷的难度来划分
- 以若不解决带来的风险来划分
- 以缺陷出现频次来划分
典型的软件缺陷
- 输入/输出缺陷
- 逻辑缺陷
- 计算缺陷
- 接口缺陷
- 数据缺陷
软件质量
软件质量模型
McCall模型：产品操作质量因子（正确性、可靠性、有效性、完整性、易用性）产品修复因子（可维护性、易测性、适应性）产品转变（可移植性、可重用性、可操作性）
ISO/IEC 9126模型：功能性、可靠性、易用性、有效性、可维护性、可移植性
比较：两者有很多相似性（McCall模型中质量因子与ISO/IEC 9126模型中的质量特性相对应；都包含可靠性、易用性、有效性等。）二者有很大不同（McCall模型关注内部质量，ISO/IEC 9126模型强调对用户可见的属性；McCall模型有11个质量因子，而ISO/IEC 9136模型只有6个质量特性；McCall模型中，质量因子和质量标准之间是多对多关系，而ISO/IEC 9126模型中质量因子与子特性之间是一对多关系；McCall模型中的一个高层质量因子如易测性在ISO/IEC 9126模型中是属于可维护性的一个低层质量子特性）
注意：没有一种标准的质量模型可以应用于各类软件项目。
软件质量保证：是确保软件产品自诞生起到消亡止的全生命周期的质量活动，即确定、达到和维护所需要的软件质量而进行的所有有计划的系统性管理活动。
目标：
- 保证软件开发及其维护符合功能与技术需求；
- 保证软件开发及其维护符合管理需求；
- 为实现前两个目标，组织一些活动来改进软件开发效率和维护效率。
软件质量保证活动
- 项目前质量活动
- 软件生命周期中的质量活动
- 基础设施方面
- 管理方面的质量活动
- 软件质量标准
- SQA自身的考虑
软件测试模型：对测试流程和方法进行定义。
- V模型
单元测试与详细设计对应
集成测试对应于概要设计
系统测试对应于需求分析
验收测试由用户主导 - W模型
优点：强调测试应伴随整个软件开发周期；测试的对象也不仅仅是程序，还包括需求、设计及相关文档。
缺点：仍将开发活动分解为需求分析、设计、编码等串行活动；测试与开发之间也是一种线性的先后关系；不支持迭代开发。 - X模型
- H模型
软件测试分类
- 是否运行软件：静态测试，动态测试
- 按测试方法：黑盒测试、白盒测试、灰盒测试
黑盒测试也称为行为测试、功能性测试或基于需求的测试，白盒测试也叫玻璃盒测试、透明盒测试或结构性测试。 - 测试执行者：人工测试，自动化测试
- 基于需求的分类：功能性测试，非功能性测试
- 基于测试对象：桌面应用程序测试，嵌入式软件测试，web程序测试、移动APP测试，其他测试
软件测试原则
- 尽早且持续测试
- 全面测试
- 测试用例要完整
- 避免测试自己的程序
- Pareto原则
- 确定软件行为
- 穷尽性测试不现实
- 全面检查每个测试结果
- 妥善保存测试资产
- 测试是富有挑战性的工作
测试思想：是辨识某个测试可能有用的简要说明，是测试用例的思想来源。
来源：需求规格说明书，软件模型，客户的抱怨，用户手册，市场调研，程序源码，头脑风暴等。
