在企业中主要分为两类:用户需求和软件需求
用户需求:甲方的需求,或者终端用户使用产品时必须要完成的任务(比较简略)。
软件需求:或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能。
注:开发人员和测试人员的直接工作依据就是软件需求。
? ? ? ?用户需求通过 技术、市场、成本 等转变成软件需求。
测试用例是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果。
- Bug的概念:当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误的。
- 当程序没有实现其最终用户合理预期的功能要求时,就是软件错误。
- 软件开发的生命周期
注:从产品的角度分析,测试是在开发之后,;从测试的角度分析,测试又是贯穿于产品的整个生命周期。
软件测试的生命周期:
- 尝试复现(普遍都存在的问题还是个别问题,个别问题优先级低一些)复现成功之后通知项目组内所有成员进行问题定位。
- 尝试定位问题出现的原因,帮助开发人员尽快定位问题并解决问题
- 反思问题(为什么会出现问题、如何解决、后续如何避免),如果问题比较严重或者比较典型的话:通常需要写一个文档。
特点:
- 线性结构,每个阶段只执行一次
- 是其他模型的基础框架
缺点:
- 测试后置
- 前面各阶段遗留的风险推迟到测试阶段才被发现,导致项目大面积返工,失去了及早修复的机会。
- 必须留有足够的时间给测试活动,否则到时测试不充分,将缺陷暴露给用户(产品质量差)。
- 周期太长,产品很迟才能被看到和使用,可能导致需求功能过时
使用场景:需求固定的小项目
特点:螺旋模型中增加了风险分析和原型
缺点:
- 项目中可能存在的风险与风险管理人员的技能水平有直接关系
- 需要人员、资金、时间的增加和投入,可能会导致项目的成本太高
使用场景:规模庞大、复杂度高、风险大的项目尤其合适
增量模型:把大的需求划分成一个个可以独立开发上线的功能。
迭代模型:先开发基础版本,然后再基础版本上不断进行功能的完善。
敏捷宣言:
考核标准:可交付的软件
特点:轻流程、轻文档、重目标、重产出。
三个角色:产品经理、项目经理、研发团队
五个重要会议:发布计划会议、迭代计划会议、每日会议、演示会议、回顾会议。
特点:
- 测试过程中存在不同类型的测试
- 测试阶段的参考标准以前面对应阶段为准
缺点:测试后置
- 前面各阶段遗留的风险推迟到测试阶段才被发现,导致项目大面积返工,失去了及早修复的机会。
- 必须留有足够的时间给测试活动,否则到时测试不充分,将缺陷暴露给用户(产品质量差)。
单元测试:对程序最小单元进行测试,最小单元可能是一个类、一个方法、一个接口
特点:
测试的对象不仅是程序,需求、设计等同样要测试,测试与开发是同步进行的 有利于尽早地全面的发现问题。缺点:W模型重流程,不能够迎接变化,不适用于敏捷模型。