软件测试的相关基础概念

需求：满足用户期望或正式文档规定的条件和权能
软件需求是测试人员进行测试工作的基本依据。
Bug：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
若没有需求规格说明书，判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
测试用例：为实施测试而向被测试程序输入的一组组合。包括：测试环境，操作步骤，输入数据，预期结果···。
软件生命周期：从软件产品的设想开始到软件不再使用而结束的时间。
分六个阶段:需求分析，计划，设计，编码，测试，运行维护。

开发模型：

（1）瀑布模型：串行，需求稳定

优点：
★强调开发的阶段性；
★强调早期计划及需求调查；
★强调产品测试。
缺点：
★依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
★由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
★风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

（2）螺旋模型：渐进式，强调风险，规格大，复杂度高，风险高

优点：
★强调严格的全过程风险管理。
★强调各开发阶段的质量。
★提供机会检讨项目是否有价值继续下去。
缺 点：
★引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人 员、资金和时间的投入。

（3）增量，迭代模型：降低风险

（4）敏捷模型：
价值观: 人与人沟通
特点：轻文档，客户参与，拥抱变化
敏捷模型
1）调整心态跟上步伐
2）多用思维导图，任务大时可采用自动化
3）讲求合作，测试人员积极向开发人员了解需求，讨论研究bug。
(注：后续会重点讲述敏捷模型，今天先提个概念)

(5) V模型

V模型各阶段测试人员需要完成的工作：

需求分析阶段：了解需求，编写测试计划
编码阶段：编写测试用例
单元测试阶段和集成测试阶段：白盒测试工程师或研发工程师对模块代码进行测试（代码测代码）
集成测试：白盒测试工程师或研发工程师测试
系统测试：
a: 搭建测试环境
b: 数据准备
c: 执行测试
d: 缺陷管理
e:编写测试报告

验收测试阶段：配合用户完成测试

（6）W模型：

W模型各阶段测试人员需要完成的工作：
用户需求：了解需求的范围，目的，背景，并为验收测试做准备
需求分析：学习分析需求，编写测试计划，并为系统测试做准备
概要实际：
（1) 搭建测试用例框架
(2) 细化测试计划,并为集成测试做准备
详细设计：细化测试用例计划，并为单元测试做准备
编码阶段：编写测试用例，单元测试
集成阶段：提取集成测试用例（从编码阶段提取），进行集成测试。
实施阶段：
（1）搭建测试环境
（2）数据准备
（3）执行测试
（4）缺陷管理
（5）编写测试报告

交付：配合用户完成测试
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。 W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和 确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制 定应对措施，显著减少总体测试时间，加快项目进度。
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段 完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模 型并不能解除测试管理面临着困惑。
配置管理:是通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些
被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。

配置项

软件配置管理的优点：
(1)能够对项目中的文档、代码等的变化进行有效管理。
(2)能够方便地重现某个文件的历史版本。
(3)能够重新编译某个历史版本，使维护工作变得容易。
(4)能够使异地多团队开发、并行开发成为现实。
(5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工作效率

软件测试的生命周期

软件测试的生命周期： 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
软件测试&软件开发生命周期:
★需求阶段:测试人员了解需求、对需求进行分解，得出测试需求
★计划阶段:根据需求编写测试计划/测试方案
★设计阶段:测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计
编写一部分测试用例
★编码阶段:测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试
★测试阶段:测试人员最为重要的工作阶段
★运行维护:测试人员参与项目的实施工作

一个合格的bug描述应该包括以下几个部分：
(1)发现问题的版本
(2)问题出现的环境
(3)错误重现的步骤
(4)预期行为的描述（预期结果）
(5)错误行为的描述（实际结果）
(6)其他：功能故障，界面故障，兼容性故障等。（可根据重要性设置优先级）
(7)不要把多个bug放到一起
一条测试用例只有一个结果

定义bug的级别：
(1)Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能
丧失，基本模块缺失等问题。
(2)Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测
试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳
定性等。
(3)Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
(4)Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
10.bug的生命周期

bug状态转换图:

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed