1.软件测试定义两面性

2.测试的生命周期

测试需求分析-->测试设计-->测试计划-->测试执行-->质量评估

3.软件测试过程：

需求评审和设计评审是验证软件产品的需求定义和设计实现，验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有可测试性以及满足非功能质量特性的要求。这个阶段主要通过对需求文档、设计文档等阅读、讨论，从中发现软件需求工程和系统设计中所存在的问题 。 

单元测试的对象是程序系统中的最小单元---模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块 单元测试一般由编程人员和测试人员共同完成。

集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题 两种集成方式：一次性集成方式和增殖式集成方式。

功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用。

系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等。

验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样 。

安装测试是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试。

软件测试在项目流程中的步骤：

二.需求和设计评审

1. 产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。

2.测试需求：

测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需求难以确定。

•  在制定测试计划之前，必须清楚测试需求
•  明确测试需求的优先级
•  测试需求分解得越细，对测试用例的设计质量越有帮助
•  详细的测试需求还是衡量测试覆盖率的重要依据  
• 测试需求是规划具体项目资源和时间的基础。

3.功能性测试需求

（1）功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。

• 程序安装、启动正常，有相应的提示框、错误提示
• 各项功能符合设计要求，正常运行并输出正确结果
• 功能逻辑合理，并能处理各种异常操作
• 能接受正确的数据输入，输出结果准确，格式清晰
• 系统的各种状态按照业务流程而变化并保持稳定
• 支持各种应用环境，能配合硬件设备

（2）功能测试需求分析

   了解需求范围-->明确目标用户-->分析功能步骤-->挖掘隐藏需求

• 了解需求想要做什么，要完成哪些功能模块
• 需求目标是谁？不同的用户角色，功能和权限是否一样？
• 要完成功能，用户需要哪些步骤
• 挖掘隐藏需求

4.用户界面及其显示要求

用户界面是和用户进行交互的窗口，其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验，简单、方便和明了，让用户舒畅、愉悦

• 通用框架、浮动窗口和文字等整体布局合理
•  文字显示正常，且内容格式正确、美观。
•  色彩协调，风格前后一致，  文字标记和超链接可以打开和跳转成功

5.非功能性需求

非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类 型差异较大。

• 客户端软件，如字处理软件、媒体播放软件等占用较少资源，在容错性、兼容性等方面要求高。
• Web应用系统对性能、安全性等有很高要求 客户端/服务器应用系统。
• 大型复杂企业级系统。

6.测试人员在需求评审中作用

需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。

• 明确自己的角色和责任
•  熟悉评审内容，为评审做好准备  
• 针对问题阐述观点，而非针对个人
•  从客户角度想问题，多问几个为什么
•  在会前或会后提出自己建设性的意见
•  对发现的问题跟踪到底
•  针对需求文档等报告问题

7.设计审查

1）成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。

•  系统架构的审查
•  设计规格说明书的审查
•  系统部署设计的审查
•  多层次审查:high-level  low-level

2）系统架构设计的审查

系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特性在设计中得到充分考虑。

3）组件设计的审查

• 功能和接口定义正  
•  算法的有效性和优化
•  合理的数据结构、数据流和控制流
•  可测试性 等

4）系统部署设计的审查

系统部署设计的审查是基于软件服务的质量目标，用来审查软件部署的目标、策略是否合理，是否得到彻底的执行

•  着重是否服从和遵守部署设计的技术规范
•  逻辑设计的审查
•  物理设计的审查
•  可用性设计的审查  
• 可伸缩型设计的验证
•  安全性设计的验证

 软件的缺陷

1.软件缺陷的定义

• 软件在使用过程中存在的任何问题（如：错误、异常等），都叫软件的缺陷，简称bug。
• 软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求。

2.软件缺陷的判定标准

• 软件未实现需求（规格）说明书中明确要求的功能
• 软件出现了需求（规格）说明书中指明不应该出现的错误
• 软件实现的功能超出需求（规格）说明书指明的范围
• 软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求
• 一般指国际/国家/行业/企业标准规范或者法规的要求
• 软件难以理解，不易使用，运行缓慢，用户体验不好

3.软件缺陷产生的原因

• 需求阶段：需求描述不易理解，有歧义、错误等
• 设计阶段： 设计文档存在错误或者缺陷
• 编码阶段：代码出现错误
• 运行系统：软硬件系统本身故障导致软件缺陷

4.软件缺陷的核心内容

• 缺陷的标题——描述缺陷的核心问题
• 缺陷的预置条件——缺陷产生的前提
• 缺陷的复现步骤——复现缺陷的过程
• 缺陷的预期结果——希望得到的结果
• 缺陷的实际结果——实际得到的结果
• 缺陷的必要附件——图片、日志等信息（证据）

5.构成缺陷的基本要素

• 缺陷编号：缺陷的唯一性标志
• 缺陷状态：表示缺陷当前处于哪个阶段
• 缺陷所属模块：缺陷属于哪个被测的模块
• 缺陷严重程度：该缺陷的破坏程度或者影响程度
• 缺陷优先级：处理该缺陷的优先程度

6.软件缺陷类型

• 功能错误
• 界面(UI)错误
• 兼容性缺陷
• 易用性
• 改进建议
• 其他