软件测试学习--基础概念篇

软件的生命周期分为六个阶段：

1. 需求分析
2. 计划
3. 设计
4. 编码
5. 测试
6. 运行维护

软件测试的目的原则生命周期

• 目的：验证软件有或没有问题。

• 原则：以客户为中心，遵循软件测试的规范、流程、标准和要求

• 软件测试的生命周期

    1. 需求分析：测试人员了解需求、对需求进行分解，得出测试需求
    2. 计划：根据需求编写测试计划/测试方案 
    3. 设计：测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计 编写一部分测试用例
    4. 编码：测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细 化测试用例以及调整测试计划和方案。 
    5. 测试：测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理 缺陷，测试完成后编写测试报告
    6. 运行维护：测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达 能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相 关负责人。
  

需求

需求大概分为两类：用户需求，软件需求

• 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该 需求一般比较简略。
• 软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。

BUG

软件错误：当存在需求规格说明书并且规格说明是正确的，程序与规格说明之间不匹配就是错误。当没有规格说明书时，程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

• 一个bug的组成：
  ①发现问题的版本
  ②问题出现的环境
  ③错误重现的步骤
  ④预期行为的描述
  ⑤错误行为的描述

• bug级别：①崩溃②严重③一般④次要

• bug的生命周期：

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

• 发现更多的bug

  • 用逆向思维和发散性思维来发现更多的bug
  • 不要局限于用例和需求文档

测试用例

测试用例：是为了实施测试而向测试的系统提供一组集合，集合中包含：测试环境、操作步骤、测试数据、预期结果。

测试用例方法

等价类

边界值

因果图

场景设计法

错误猜测法

开发模型和测试模型

瀑布模型：

特点（不走回头路）：

• 是其他模型的基础。
• 每一个阶段都只执行一次。
• 是线性顺序进行的软件开发模式。

优点：

• 强调开发的阶段性
• 强调早期计划以及需求调查
• 强调了产品测试

缺点：

• 依赖早期的需求分析，不能适应需求的变化。
• 单一流程，开发中的经验教训不能反馈应用于本产品的过程
• 风险往往在后期的测试阶段才会显露，因此会失去及时纠正的机会。

螺旋模型：

适用于前期需求 不是很明确的，比较庞大，风险比较大的项目

优点：

• 强调严格的全过程的风险管理
• 强调各开发阶段的质量
• 提供机会研讨项目是否有价值继续下去

缺点：

• 引入了非常严格的风险识别，风险分析和风险控制，对风险管理的技能水平提出了很高的要求需要人员、资金和时间的投入。

增量、迭代模型

• 都有一定的抗风险的能力，但是迭代模型抗风险更强。

敏捷开发模型

轻文档、轻流程、重目标、重产出
敏捷宣言：

• 个体与交互重于过程和工具

• 可用的软件重于完备的文档

• 客户协作重于合同谈判

• 响应变化重于遵循计划

• 在每对比对中，后者并非全无价值，但我们更看重前者
  scrum
  
    是轻量级的开发。主要2-4周，5-9个人进行。
  角色：

• product owner PO user story

• scrm matser SM

• scrm Team

适用于：需求不明确的开发。

敏捷中的测试

V模型：

W模型