软件与明确的和隐含的定义的需求相一致的程度 ①与需求一致 ②与指定的开发标准一致 ③与隐含需求一致

至少满足下列一个条件，称发生了一个软件缺陷 – 软件未实现产品说明书要求的功能 – 软件实现了产品说明书未提到的功能 – 软件出现了产品说明书指明不能出现的错误 – 软件未实现产品说明书虽未明确提及但应该实现的目标 – 软件难以理解、不易使用、运行缓慢、用户认为不好等

• 正确性：满足需求规格和用户目标的程度 • 可靠性：一定时间内无故障运行的能力 • 有效性：用户完成特定任务和达到特定目标时所具有的正确和完整程度 • 可用性：用户能否用软件完成他的任务，效率如何，主观感受怎样 • 可维护性 ：为修改Bug、增加功能、提高质量而诊断并修改软件的难易程度 • 可测试性 ：对软件进行测试的难易程度 • 灵活性：反映软件适应变化的能力，修改或 改进一个已投入运行的软件所需的工作量 • 可移植性：软件不经修改或稍加修改就可以 运行于不同软硬件环境的难易程度 • 可重用性：重用软件或构件的难易程度 • 互操作性：本软件与其它系统交换数据和相互调用服务用以协同运作的难易程度 • 安全性：向合法用户提供服务，阻止非授权使用服务 • 健壮性：异常情况下软件能够正常运行的能力 • 易用性：用户使用软件的容易程度

评审是软件开发早期查错最有效的机制

• 非正式评审 – 简单桌面检查、临时会议、结对编程评审 • 走查 – 开发组内部进行，采用讲解、讨论和模拟运行的方式查找错误 • 审查 – 开发组、测试组和相关人员联合进行，采用讲解、提问 、以及Checklist方式进行错误查找，以会议的形式进行，制定目标、流程、规则和结果报告

• 正确性：对系统功能性能等的描述正确反应用户真正需求 • 无二义性：每项需求对任何人都只有一种解释 • 一致性：任何一项需求不能和其它需求矛盾 • 完整性：包括用户需要的每一项功能、性能、外部接口、 约束等 • 可行性：每项需求都是可以实施的 • 必要性：每项需求都是客户需要的 • 可验证性：每项需求都能写出测试用例或其它检验方法 • 可跟踪性：每项需求能与它的根源和设计、代码、测试用例之间建立链接 • 可修改性：格式和组织方式应保证后续的修改容易进行

在设计完成、编码开始前进行，检查软件设计说明书，如：接口的定义，功能的设计等。

数据声明错误，数据引用错误等。

软件测试只是软件质量保证的一部分，不能将两者画等号。 • 静态测试：不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。 • 动态测试：为发现程序中的错误而运行程序的过程。 • 测试用例：输入和预期结果 • 测试与调试的区别 – 两者都包含有处理软件缺陷和查看代码的过程 – 测试的目标是发现软件缺陷的存在 – 调试的目标是定位与修复缺陷

运用形式化语法和语义描述需求和设计，采用基于数学的方法建模，能够形式化证明程序的正确性 创建具有极低故障率的软件 。 缺点：不易掌握，没有广泛使用

• 利用程序内部的逻辑结构及有关信息，设计测试用例 • 对程序的所有独立执行路径进行测试 • 对所有的逻辑判定的“真”和“假”的情况进行测试 • 在循环的边界测试 • 测试内部数据结构的有效性

|

为了暴露程序中的错误，至少每个语句应该执行一次。

程序应该执行的路径为sacbed. 所有语句覆盖，但是实际上，只执行了判断为真的路径。

不仅每个语句必须执行一次，而且每个判定的每种可能的结果都应该执行一次，也就是每个判定的每个分支都至少执行一次。 程序应该执行的路径为sacbd，sabed. 所有判断结果都执行了，但是实际上，只执行了一半的路径。

不仅每个语句必须至少执行一次，而且使判定表表达式中的每个条件都读取到各种可能的结果。

程序在a点应该有下述结果： A>1;A1;X1,B=0,A=2,X1,B=0A>1,B!=0A