软件测试概念篇

目录

1.软件测试

2.需求

2.1 用户需求

2.2 软件需求

2.3 测试人员眼里的需求

2.4 需求的重要性

3.测试用例

3.1 什么是测试用例

3.2 为什么有测试用例

4.BUG

4.1 BUG的概念

4.2 如何描述一个BUG

4.3 如何定义BUG的优先级

4.4 BUG的生命周期

5.软件生命周期

6. 软件开发模型

① 瀑布模型 (Waterfall Model):往往适用于需求非常稳定的项目。

② 螺旋模型(Spiral Model):大型项目,具有一些风险适用于螺旋模型。

③ 迭代、增量模型

④ 敏捷模型

7.软件测试模型

① 软件测试v模型

② 软件测试W模型

8.软件测试生命周期

 


1.软件测试

定义:软件测试就是一系列活动,这些活动是为了评估一个程序或者软件系统的特性或能力,并确定是否达到了预期的效果。

软件测试是一个过程,就是进行一个比较,拿着预期的结果和程序的执行结果作比较。

特点:软件测试只是一个样本试验,具有不可穷尽性。


2.需求

满足用户期望或正式规定文档(合同、标准、规范)所具有的条件和权能,包含用户需求和软件需求。

在大多数软件公司,会有两部分需求,一部分是用户需求,一部分是软件需求。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求,开发人员和测试人员工作的直接依据 就是软件需求。

软件需求是测试人员进行测试工作的基本依据。

用户需求比较简答,软件需求越详细越好。

2.1 用户需求

可以简单理解为甲方提出的需求,如果没有甲方,那么就是终端用户使用产品时必须完成的任务。该需求一般比较简略。

2.2 软件需求

或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能。

2.3 测试人员眼里的需求

需求是测试人员开展软件测试工作的依据。

测试人员以“用户登陆”为例,来阐述下整个过程:

业务需求—>软件功能需求点—>测试需求点—>测试用例

软件测试概念篇_第1张图片

2.4 需求的重要性

从软件功能需求出发,无遗漏的识别出测试需求是至关重要的,这将直接关系到用例的测试覆盖率。

② 对于识别出的每个测试需求点,需要采用具体的设计测试用例的方法来进行测试用例的设计。


3.测试用例

3.1 什么是测试用例

测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素。

3.2 为什么有测试用例

执行测试用例的时候,绝大部分的测试点都是参考测试用例执行的。

① 测试用例解决测试人员工作重复性的问题。

② 测试用例可以提高测试人员的效率。

③ 测试用例是自动化的基础。


4.BUG

4.1 BUG的概念

准确的来说:当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误。

当需求规格说明书没有提到的功能,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能需求时,就是软件错误。

4.2 如何描述一个BUG

① 发现BUG的版本

② 问题出现的环境:PC电脑,手机,浏览器型号、版本

③ 错误重现的步骤:通过什么样的操作可以出现这个问题

④ 预期行为的描述:预期结果的描述

⑤ 错误行为的描述:执行结果的描述

⑥ 其他:bug标题,bug优先级

⑦ 不要把多个bug放到一起

4.3 如何定义BUG的优先级

bug的定义每个公司都不一致,在定义级别之前需要查看公司规范。

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

4.4 BUG的生命周期

测试人员应该跟踪一个Bug的整个生命周期,从Open到Closed的所有状态。

软件测试概念篇_第2张图片

bug的不同状态:Start 与 End 不是流程里的状态,只是开始,结束标志。

● New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。

● Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。

● Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。

● Rejected:如果认为不是Bug,则拒绝修改。

● Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。

● Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。

● Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。

无效的bug:open->closed open-rejected-closed


5.软件生命周期

软件的生命周期:软件从诞生到不能使用。

软件的生命周期可以分成6个阶段,即需求分析、计划、、设计、编码、测试、运行维护。

① 需求分析

测试人员产出需求文档(软件规格说明书)

开发人员判断需求是否合理,需求是否完整。

② 计划

软件开发让谁去做,软件什么时候开始开发,什么时候结束开发。

③ 设计

UI设计师:产出一个UI设计稿

开发人员:产出一个技术文档(接口,库表,缓存,mq...)

④ 编码

写代码实现需求

⑤ 测试

执行测试,提出BUG,验收BUG,发送测试报告。

⑥ 运行维护

上线、维护线上软件质量(当发现线上BUG,测试人员需要复现BUG,开发人员需要修复问题)

6. 软件开发模型

① 瀑布模型 (Waterfall Model):往往适用于需求非常稳定的项目。

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

特点:每个阶段之间的关系是线性的。

优点:每一个阶段要做的工作非常的清楚。

缺点:产品效果出现的较晚。如果测试人员介入的太晚,以至于如果测试阶段发现问题,需要不断的向前回溯,如果需求出现问题,此时我们之前的工作(开发,测试)付之东流,需求需要重新设计。

② 螺旋模型(Spiral Model):大型项目,具有一些风险适用于螺旋模型。

软件测试概念篇_第3张图片

特点:每一次实施的时候都要进行风险分析。

优点:风险分析可以避免一些未知的问题。

缺点:风险分析错误,会导致一系列的损失。风险分析需要一定的成本。

③ 迭代、增量模型

例如淘宝:登录、注册、搜索、查看商品信息、支付……

迭代:先开发淘宝-登录大概框架,先开发淘宝-注册大概框架,先开发淘宝-搜索大概框架,查看,支付……

增量:先开发登录直到登录开发结束再去开发注册,注册开发结束在进行下一步……

增量:适用于模块和模块之间没有任何关系。

迭代:项目先看到雏形,然后再仔细开发最终实现项目。

④ 敏捷模型

敏捷宣言:

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

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

客户协作重于合同谈判

响应变化重于遵循计划

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

特点:重沟通,轻流程。重支付,轻文档。重协作,轻谈判。拥抱变化。

Scrume角色:

PO:产品经理,收集用户需求

SM:项目经理,对项目进行计划、对需求进行优先级排序。

Team:研究团队(开发---实现需求、测试---负责项目测试、设计师---产出交互设计稿)

Scrume具体流程:

软件测试概念篇_第4张图片

7.软件测试模型

① 软件测试v模型

软件测试概念篇_第5张图片

特点:线性的;左边是开发,右边是测试。

优点:将测试分为了好多种类型。每个阶段要做的工作非常明确。

缺点:测试介入的太晚,测试和开发是串行的。

② 软件测试W模型

软件测试概念篇_第6张图片

 特点:开发一个V,测试一个V。

优点:测试人员尽早介入了需求。开发人员和测试人员并行的。

缺点:测试和开发相应来说也是串行的。不能拥抱变化,不能适用于敏捷。

8.软件测试生命周期

软件测试的生命周期:

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估→维护上线。

每一个阶段测试人员做的工作

需求分析:分析需求正确性、完整性

测试计划:who(由谁测试),when(何时开始测试、何时结束测试,测试点有哪些)

测试设计:编写测试用例、编写测试工具、测试用例评审

测试执行:执行测试用例,发现BUG,提交BUG,验收BUG...

测试评估:产出一个测试报告

运行维护:上线、维护线上软件质量(当发现线上BUG,测试人员需要复现BUG,开发人员需要修复问题)

你可能感兴趣的:(软件测试,单元测试,压力测试)