软件需求与测试全流程-优快云博客

本文链接：https://blog.youkuaiyun.com/J4Ya_/article/details/81037674

1.需求

1.1 概念

满足用户的期望或正式规定文档(合同, 规定, 规范)所具有的条件和权能

用户需求: 一般比较简单/粗略;
软件需求: 或叫做功能需求,该需求会详细描述开发人员必须实现的软件功能;

吃饭的例子:

用户需求: 我饿了

软件需求: 想吃炒菜米饭,锅包肉,冰淇淋...

需求不一定完全正确,需求也需要测试

2.Bug

2.1 概念

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

Bug后果: 用户流失;

Bug责任: 第一责任人为测试;

Bug处理: 生产环境上的问题,要第一时间回滚,再慢慢定位;

Bug态度: 心存敬畏,但是不要害怕,程序员身上背负的Bug,就像是一个老兵身上的伤疤,是最值得骄傲的军工勋章;

3.测试用例

3.1 概念

为了实施测试而向被测试的系统提供的一组集合,这组集合包括: 测试环境, 操作步骤, 测试数据, 预期结果等要素;

3.2 测试核心步骤

不同的要求步骤会改变,但是以下三点一定是有的

操作步骤
输入数据
预期结果

3.3 测试用例中可能遇到的问题

不知道是否较全面的测试了所有功能;
测试覆盖率无法衡量;
对新版本的重复测试很难实施;
存在大量冗余测试影响测试效率;

手机添加联系人测试用例:

测试用例一:

标题: 手机添加联系人测试用例

环境: android5.7.0 (具体版本)

操作平台: 手机

测试方式: 手工

前置条件:

手机号码正确并且联系人不存在;

操作步骤:

1.打开手机;

2.找到桌面上拨号图标;

3.输入号码;

4.点击添加联系人;

1) 输入联系人姓名(必填);

2) 输入联系人其他信息,如住址,微信等(选填);

3) 点击保存;

5. 点击完成按钮

输入数据:

18706813937

预期结果:

1.进入联系人列表;

2.输入联系人姓名或者手机号码进行查找;

3.成功显示联系人信息;

测试用例二:

标题: 手机添加联系人测试用例

环境: android5.7.0 (具体版本)

操作平台: 手机

测试方式: 手工

前置条件:

手机号码正确但是联系人已存在;

操作步骤:

1.打开手机;

2.找到桌面上拨号图标;

3.输入号码;

4.点击添加联系人;

a) 选择新建联系人还是在原有基础上插入;

b) 输入联系人信息;

c) 点击保存;

5. 点击完成按钮

输入数据:

18706813937(正确且存在)

预期结果:

1.进入联系人列表;

2.输入联系人姓名或者手机号码进行查找;

3.成功显示联系人信息;

测试用例三:

标题: 手机添加联系人测试用例

环境: android5.7.0 (具体版本)

操作平台: 手机

测试方式: 手工

前置条件:

手机号码不正确;

操作步骤:

1.打开手机;

2.找到桌面上拨号图标;

3.输入号码;

4.点击添加联系人;

5.提示号码不正确

输入数据:

111111111111111111

预期结果:

1.进入联系人列表;

2.输入联系人姓名或者手机号码进行查找;

3.未查找到相关信息

4.开发模型和测试模型

开发模型

4.1 软件生命周期阶段

是指从软件产品的设想开始到软件不再使用而结束的时间;

可以大致分为以下六个阶段:

需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运维

4.2 瀑布模型(Waterfall Model)

瀑布模型在软件工程中占有重要地位,是其他模型的基础框架;
瀑布模型的每一阶段都只执行一次,因此是线性顺序进行软件开发模式;

瀑布模型的优点:

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

瀑布模型的缺点:

依赖于早起进行的唯一一次需求调查,不能适应需求的变化
由于是单一流程,开发中的经验教训不能反馈应用于本产品的过程
相同项目的时候才可以,因为瀑布模型是串行,耗时比较长
风险往往迟至后期的测试阶段才显露,因为失去早纠正的机会

在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

4.3 螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。

螺旋测试的优点:

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

螺旋测试的缺点:

引入非常严格的风险识别,风险分析和风险控制,这对风险管理的技能和水平提出了很严格的要求

4.4 增量、迭代

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。

增量开发模型，鼓励用户反馈，在每个达代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈，但是其实两者是有区别的。

增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……
迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

4.5 敏捷开发模型

在每对比对中,后者并非全无价值,但是我们更看重前者

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
相应变化重于遵循计划

scrum

scrum里面的角色

product owner[产品经理]: 定义其商业价值，对其进行排序，制定发布计划，对产品负责;
scrum master[项目经理]: 负责召开各种会议,项目协调,为研发团队服务;
team[研发团队]: 由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品;

迭代开发

与瀑布模型不同,scrum将产品的开发分为若干个小的sprint(迭代),其周期从一周到四周不等,但是不会超过四周;,参与的成员一般是5~9人;

每期迭代要完成的user story是固定的,每次迭代产生一定的交付;

测试模型

V模型

V模型是是瀑布模型的变种

明确标注了测试过程中存在的不同类型的测试,并且清除的描述了这些测试阶段和开发过程期间各阶段的对应关系;
V模型支出,单元和集成测试应检测程序执行的是否满足软件设计的需求;系统测试应检测系统功能,性能的指标是否达到系统要求指标;验收测试确定软件的实现是否满足用户需求或合同的要求;
局限性: 仅仅把测试作为在编码之后的一个阶段, 未在需求阶段就进入测试;

W模型

    用户需求: 确定测试范围; 
  
    概要设计: 搭建概要的设计框架; 
  
    详细设计: 细化测试框架; 
  
    编码阶段: 编写测试用例; 
  
    集成阶段: 编写集成测试的测试用例; 
  
    实施阶段: 正式执行测试, 测试环境的搭建,测试数据的准备,执行测试用例, 缺陷的管理, 编写测试报告; 
  
    交付阶段: 协助客户完成验收测试;

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。