软件评测师教程笔记
序言
软件评测[阿斯顿1] 师：
评，点评、评价、评估之意，目的是评估软件是否已完成项目要求，属于验证类；
测，测试、检测之意，目的是校验软件运行是否会出现问题，属于校验类；
软件测试离不开验证与校验，软件测试工作必须从两个方面开展。
第1章 软件测试概论
软件测试是软件工程/项目[阿斯顿2] 发展到一定程度的必然。软件测试范围由初级的狭窄验证到如今宽广的验证工作，体现了软件测试体系越来越规范。行业对于软件测试从业者要求越来越高。从业者需要不断的学习新的测试知识，才可以拥有测试领域的发言权，不被项目环境所淘汰。
首先，从业者需要良好的测试基础。
其次，从业者需要保持思维的活跃。
最后，从业者需要统一各项目阶段不同的项目知识：需求、设计、编码、运维。
第2章 软件测试基础
2.1 软件测试与软件质量[阿斯顿3]
软件测试：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。
软件质量：软件满足规定或潜在用户需求特性的总和。
l 质量保证（QA）：质量保证的重要工作通过预防、检查与改进来保证软件质量。QA的工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求，因此主要着眼于软件开发过程中的过程、步骤和产物，而不是对软件进行剖析找出问题和评估。
l 软件测试：测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行”软件，对过程中的产物——开发文档和源代码进行走查，运行软件，以找出问题，报告质量。测试人员必须假设软件存在潜在的问题，测试中所作的操作是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。对测试中发现的问题的分析、追踪和回归测试也是软件测试中的重要工作，因此软件测试是保证软件质量的一个重要环节。
2.2 软件测试目的
ü 测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试。
ü 测试的目的不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。
2.3 软件测试原则
基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量，制定以下测试原则：
ü 所有的软件测试都应追溯到用户需求。
ü 应当把“尽早地和不断地[阿斯顿4] 进行软件测试”作为软件测试者的座右铭。
ü 完全测试是不可能的，测试需要终止。
ü 测试无法显示软件潜在的缺陷。
ü 充分注意测试中的群集现象[阿斯顿5] 。
ü 程序员应避免检查自己的程序。
ü 尽量避免测试的随意性[阿斯顿6] 。
2.4 软件测试对象
软件包括程序、数据和文档，所以软件测试不仅仅只关注程序本身。
软件测试应贯穿整个软件生命周期，在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。
2.5 软件测试分类
2.5.1 按照开发阶段划分
按照开发阶段划分，软件测试可分为单元测试、集成测试、系统测试、确认测试和验收测试。
l 单元测试
单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的工作，目的在于检查每个程序单元是否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。
单元测试需要从程序内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
l 集成测试
集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件内部的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
软件集成的过程是一个持续的过程，会形成很多个临时版本，在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。
l 系统测试
系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。
l 确认测试
确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。
l 验收测试
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
2.5.2 按照测试实施组织划分
按照测试实施组织划分，软件测试可分为开发方测试、用户测试（β测试）、第三方测试。
l 开发方测试
通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。
l 用户测试（β测试）
在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。
β测试通常被看成是一种“用户测试”。β测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。通过用户各种方式的大量使用，来发现软件存在的问题与错误，把信息反馈给开发者修改。β测试中厂商获取的信息，可以有助于软件产品的成功发布。
l 第三方测试
介于软件开发方和用户之间的测试组织的测试。
一般指第三方测试组织/机构。
2.5.3 按照测试技术划分
按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。
静态测试是指不允许程序，通过人工对程序和文档进行分析与检查：静态测试技术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
l 白盒测试
通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常运行。白盒测试又称为结构测试。
l 黑盒测试
通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查样序是否按照需求规格说明书的规定正常实现。
l 灰盒测试
灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。
2.6 软件测试过程模型
软件测试过程依托与软件开发过程模型，进而整理出对应的测试模型。
软件开发过程模型：瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发（RAD）、Rational统一过程（RUP）。
软件测试过程模型：
V模型：
图中箭头代表时间方向，左边下降的是开发过程各阶段。右边上升是测试过程的各个阶段。
W模型（基于“尽早地和不断地进行软件测试”原则）：
前置测试模型：
2.7 软件生命周期测试策略
2.7.1 软件开发和软件测试
2.7.2 软件测试策略
1.测试信息流
2.分析设计阶段
分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测。
需求说明书评测
良好需求说明书8条原则：
原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。
原则4：规格说明必须包括系统运行的环境。
原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。
原则7：规格说明必须容许不完备性并允许扩充。
原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时。只要修改某个单个的段落。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。
需求说明书框架
需求说明书评测内容
l 系统定义的目标是否与用户的要求一致；
l 系统需求分析阶段提供的文档资料是否齐全；
l 文档中的所有描述是否完整、清晰，准确地反映用户需求；
l 与所有其他系统成分的重要接口是否都已经描述；
l 被开发项目的数据流与数据结构是否足够、确定；
l 所有图表是否清楚，在不补充说明时是否理解；
l 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
l 软件的行为和它必须处理的信息、必须完成的功能是否一致；
l 设计的约束条件或限制条件是否符合实际；
l 是否考虑了开发的技术风险；
l 是否考虑过软件需求的其他方案；
l 是否考虑过将来可能会提出的软件需求；
l 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
l 有没有遗漏、重复或不一致的地方；
l 用户是否审查了初步的用户手册或原型；
l 项目开发计划中的估算是否受到了影响。