软件测试理论-day01

测试理论day01

软件测试

测试人员 :找bug

软件调试

开发人员 :找bug ,解决bug

预期结果 :客户要求的结果

实际结果 :产品实际实现的结果

软件测试≠软件调试

软件调试:开发时发现错误后消除错误的过程

软件测试:主要目的是寻找缺陷(不包括修复) 调试必须由开发人员自己完成,测试则不一定

软件测试的原则

满足客户需求

设计测试用例时,包括合理的输入条件和不合理的输入条件

不要穷举测试

缺陷发现的越早,代价越小

测试的杀虫剂怪事

不能证明软件中没有错误,但是可以证明软件中有错误

注意测试中缺陷(bug)群集现象

要有预期结果

避免测试自己的软件

保留测试设计和说明文档

三大模型

瀑布模型

软件测试理论-day01_第1张图片

 

优点:1)为项目提供了按阶段划分的检查点。 2)当前一阶段完成后,你只需要去关注后续阶段。 3)它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的 指导。 缺点:1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。 2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。 3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 4)瀑布模型的突出缺点是不适应用户需求的变化。 ​

V模型 

软件测试理论-day01_第2张图片

W模型

软件测试理论-day01_第3张图片

 优点: 测试的活动与软件开发同步进行 、测试的对象不仅仅是程序,还包括需求和设计 、尽早发现软件缺陷可降低软件开发的成本

测试阶段划分:单元测试(模块测试)、集成测试(组装测试,联合测试)、系统测试

UI、IT、ST测试的比较: 测试方法不同 - 单元测试属于白盒测试范畴 - 集成测试属于灰盒测试范畴 - 系统测试属于黑盒测试范畴 考察范围不同 - 单元测试主要测试模块之内的数据结构、逻辑控制、异常处理等 - 集成测试主要测试模块之间的接口和接口间数据传递关系,以及模块组合后的整体功能 - 系统测试主要测试整个系统相对于需求的符合程度 评估基准不同 - 单元测试的评估基准主要是逻辑覆盖率 - 集成测试的评估基准主要是接口覆盖率,路径覆盖率 - 系统测试的评估基准主要是测试用例对需求规格的覆盖率 ​ ​

验收测试

α测试:内测、开发环境

β测试:公测、实际使用环境

UAT测试(用户验收测试)

α测试(内测):α测试是由一个或多个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,α测试不能由程序员或测试员完成。α测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能等。尤其注重产品的界面和特色。
β测试(外测):β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。在β测试中,采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据,并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。
UAT测试(用户验收测试):UAT测试是由相关的用户或独立的测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的          测试。

软件测试的流程图软件测试理论-day01_第4张图片

 

测试计划和测试方案区别:组织方式不同、目的不同

测试环境种类大致分为:

  1. 硬件环境

  2. 软件环境

  3. 服务器环境

环境按照类别大致可以分为三种:开发环境、测试环境、生产环境

测试实施:

1. 冒烟测试(不在轮次中)

2. 第一轮(筛选用例):

测试范围:所有正向业务流程

3.第二轮(包含第一轮Bug的回归):

测试范围:所有业务流程(正向+逆向(重点))

4.第三轮(包含前二轮Bug的回归): 测试范围:再执行正向业务流程

对老功能测试(迭代项目)

5.封包测试:

封包之后,再测试出来Bug,如果不是严重级别的,不做修改

验证已修复的Bug

验证老的功能是否受影响

6. 线上验证

不产生交易数据

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