软件研发流程和质量
最常见软件开发模型：瀑布模型（v、w模型）
快速原型模型
敏捷开发模型
V模型
需求分析、概要设计、详细设计、编码、单元测试（独立的模块测试）、集成测试（模块联调）、系统测试（整体流程）、验收测试（验证是否满足需求）。
v模型的优点：
- v模型清楚地标识出了软件开发的各个阶段；
- 清楚地描述了测试阶段与开发过程各阶段的对应关系与开发同步（引入检测机制，需求分析做的好不好，看验收测试）；它采用自顶向下逐步求精的方式把整个开发过程分为不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程：阶段划分清晰，方便工作的整体把控。
- v模型的测试既包括了底层测试（检验源代码质量的测试：单元测试），又包括了高层测试（需求级的测试：系统测试）。
v模型的缺点：
- 它仅仅把测试过程作为需求分析，概要设计，详细设计，编码之后的一个阶段，容易让人理解为测试是软件开发的最后一个阶段；
- 和瀑布模型一样，流程也是单向的。到了测试阶段，程序已完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。
- 没有明确说明早期的测试，不符合越早测试和不断地进行测试的原则（用户需求对不对要到验收测试才能发现）。
W模型-双V模型
开发一个v，测试一个v，开发和测试并行。
- 开发V：需求分析、概要设计、详细设计、编码、集成、实施、交付。
- 测试V：系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试。
W模型的优点：
- 开发强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试。
- 更早的接入测试，可以发现开发初期的缺陷，那么可以用更低的成本进行缺陷修复。
- 同样是分阶段的工作，便于控制项目过程。
W模型的缺点：
- 软件开发和软件测试依然保持一前一后的线性关系，依然无法支持迭代、自发性和需求等变更调整。
- 对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法适用。
- 使用起来技术复杂度很高，对于需求和设计的测试要求很高，实践起来困难。
软件开发过程模型的目的
- 保证最终产品满足用户需求；
- 提高产品质量，降低产品开发成本；
- 保证项目可管理，进度可控制；
- 作为测试人员的职责，是在所处项目的开发模式中，尽量运用自身的知识和技能，创造出尽量完善的软件。
软件的生命周期
需求（可行性分析、需求分析）、设计（概要设计、详细设计、数据库设计）、编码、测试、维护、升级、废弃。
软件测试流程
需求分析、测试计划、测试方案、测试要点分析、测试用例、测试执行、测试报告、测试总结。
软件研发流程
需求分析、设计、编码、测试。
质量的定义
反映实体满足明确或隐含需求的能力的特性总和。
外部和内部质量的六大特性
- 功能性
- 可靠性：产品在规定条件下，在规定的时间内完成规定功能的能力
- 易用性：在指定使用条件下，产品被理解、学习、使用和吸引用户的能力。
- 效率性：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
- 维护性：“四规”，在规定的条件下，规定的时间内，使用规定的工具或方法修复规定功能 的能力。
- 可移植性：从一种环境迁移到另一种环境的能力。
质量保证者：QA和QC
QC：主要是事后的质量检验类活动为主，默认错误是允许的，期待发现并选出错误。
QA：主要是事先的质量保证类活动，以预防为主。期待降低错误发生的几率。
软件质量最权威的体系：CMMI和ISO9000质量标准体系。
CMMI等级
在模型中，所有软件组织的软件能力成熟度划分为五个等级。数字越大，成熟度越高。高成熟度代表比较强的综合软件能力。
- 5级：持续优化级 关注：持续过程改进
- 4级：量化管理级 关注：组织级量化管理
- 3级：已定义级 关注：组织级过程标准化
- 2级：已管理级 关注：基本项目管理
- 1级：初始级 特征：混乱无序
如何提高软件质量
软件在没有发布之前的开发过程主要分为需求分析、设计、编码和验证四个阶段，最终的软件质量与这四个阶段的各自质量之间有密切的关系。
- 完备的需求分析
- 通过设计方法找出软件实现更好的方法
- 开发人员要有良好的编码习惯（合理添加注释、遵守编码规范等）
- 测试人员要做好各个环节的测试工作（高质量用例，良好的测试执行，良好的缺陷管理，良好的测试流程）
- 遵守软件开发必要的流程
- 选择合适的工具
- 输出高质量的开发文档
测试计划
测试计划的定义
测试计划就是描述所有要完成的测试工作，包括测试项目的背景，目的，范围，资源，进度，环境，策略，任务，以及测试相关的风险和措施等方面。
测试开始和结束条件
测试启动条件：
-
- 版本基本稳定，
- 测试用例、测试代码准备完成，
- 测试环境搭建完成，
- 冒烟测试通过。
测试结束条件：
-
- 需求覆盖率达到100%
- 用例执行率达到100%
- 缺陷解决率高于95%，缺陷遗留率低于5%
- 无致命和严重bug
软件测试基础
软件测试定义的两面性
- 正向思维（验证软件正常工作）：评价一个程序或系统的特性或能力并确定是否达到预期的结果。在设计规定的环境下运行软件的所有功能直至全部通过。
- 逆向思维（假定软件有错误）：测试是为了发现错误，而针对某个程序或系统的执行过程。寻找容易犯错误的地方和系统的薄弱环节， 试图破坏系统，直至找不出问题。
软件测试的定义
IEEE标准定义：
使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于验证它是否满足规定的需求或弄清预期结果和实际结果之间的差别。
软件测试的目的和原则
软件测试的目的
- 以最少的人力、物力和时间，系统地找出软件中潜在的各种错误和缺陷。通过修正各种错误和缺陷提高软件质量，尽量规避软件发布后的风险。
- 测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择和接受软件提供有力的证据。
- 通过分析错误产生的原因，可帮助发现当前软件过程的缺陷，以便进行过程改进。
- 测试是为了证明软件中存在错误，而不是证明软件正确的。
- 软件测试最终的目的是交给用户的软件产品符合用户的需求。
软件测试的原则
- Good-Enough原则（测试既不要不充分，也不是过分）
- 木桶原则
- 80~20原则
- 其它几个重要原则：
- 所有的软件测试都应追溯到用户需求。
- 尽早地和不断地进行软件测试。
- 完全（穷举）测试是不可能的，测试需要终止。
- 测试无法显示软件潜在的缺陷。
- 充分注意测试中的群集现象。
- 程序员应避免检查自己的程序。
- 尽量避免测试的随意性。
- 测试用例应包括合理的输入条件和不合理的输入条件。
- 应当彻底检查每个测试的执行结果。
- 妥善保存测试相关的文档及数据，为管理提供依据，为维护提供方便。
软件测试的对象
根据软件的定义，软件测试对象包括程序，数据和文档。
软件测试的两个手段
为了把握各个环节的正确性，人们需要进行各种验证和确认工作：
- 验证：保证软件符合产品规格说明书的过程。
- 确认：保证软件满足用户要求的过程。
软件测试的分类
按阶段
- 单元测试：主要测试单元内部的数据结构、逻辑控制和异常处理等。
- 集成测试
- 集成测试方法：
- 非增量式集成：采用一步到位的方法来构造测试。
- 增量式集成：采用逐步集成方式实现测试。
- 自顶向下增量式测试：桩程序
- 自底向下增量式测试：驱动程序入口和出口函数
- 集成测试方法：
- 系统测试
- 验收测试
- 非正式验收测试：Alpha 测试（α测试）、Beta 测试（β测试）
-
Alpha 测试 Beta 测试 共同点
1.都希望从实际终端用户的使用角度来对软件的功能和性能进行测试，以发现可能只有
终端用户才能发现的错误；
2.都不能由测试人员和开发人员完全。
区别 测试环境 开发环境或模拟实际操作的环境下
实际使用环境（生产环境） 测试人员 可以是终端用户，也可以是企业内部的用户 终端用户（包括潜在用户） 开发人员是否在场 有开发人员在场，测试是可控的 开发人员通常不在测试现场，测试情况不可控 关注点 Alpha 测试关注软件产品的功能、局域化、可使用性、可靠性、性能和可支持性，尤其注重产品的界面和特色。 Beta测试着重关注产品的支持性， 包括文档、客户培训和支持产品 的生产能力。
-
- 正式验收测试：有正规的测试过程，需要制定测试计划、定义测试方案、选择测试用例，进行测试，结果提交。着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确， 人机界面和其他方面。
- 非正式验收测试：Alpha 测试（α测试）、Beta 测试（β测试）
是否运行
- 静态测试：静态测试指不运行被测程序本身，仅通过分析或检查源程序的语法 、结构、过程、接口等来检查程序的正确性。
- 动态测试：动态测试是指通过运行被测程序，检查运行结果与预期结果的差异 ，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。
是否查看源代码
- 白盒：主要应用于单元测试。
- 灰盒：主要应用于集成测试阶段。
- 黑盒：主要应用与系统测试和验收测试阶段。
- 功能：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试。
- 性能：一般性能测试、稳定性测试、负载测试、压力测试（并发、吞吐率、响应时间）。
其它
- 回归测试
- 冒烟测试
- 随机测试
- 安全测试
测试用例
测试用例的构成元素
用例编号、用例标题、优先级、预置条件、操作步骤、预期结果、实际结果、通过情况、备注