软件测试基础概念

一、需求

定义：满足用户期望或正式规定文档所需条件和技能，包含用户需求

用户需求：用户使用产品所必须完成的任务 该需求比较简略

软件需求：详细描述开发人员必须实现的软件功能

需求是标准，测试人员按照这个标准测试，过程如下：业务需求—>软件功能需求点—>测试需求点—>测试用例

二、测试用例

实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

1.测试用例作用

提高测试效率

建立自动化测试的基础

三、软件错误（bug）概念

当程序没有实现其最终用户合理预期的功能要求时，就是软件错误，软件需求、规格说明书是存在且正确的，预期结果不等于执行结果是错误。

1描述bug

发现问题的版本

问题出现的环境：硬件环境和软件环境

错误重现的步骤

预期行为的描述 让开发人员知道什么是正确的，站在用户的角度描述程序的行为

错误行为的描述

2.BUG级别

优先级较高先修复，优先级较低后修复

 

四、软件生命周期及软件测试生命周期

1.软件生命周期

需求分析：分析需求合理性、完整性

计划：对软件开发过程进行计划，由谁负责开发、测试，时间长度

设计 UI/UE设计师将需求转换成图，开发人员软件架构

编码：编写代码

测试：执行测试用例，验收BUG 产出测试报告

运行维护

2.软件测试生命周期

需求分析：判断用户设计是否合理

测试计划：计划测试由谁来做，什么时候开始，什么时候测试结束，

测试设计：设计测试用例

测试开发：开发可以支持测试，提高测试效率的工具

测试执行：执行测试用例

测试评估：产出测试报告

五、开发模型

1.瀑布模型

特点：线性

优点：各个阶段目标明确

缺点：发现问题时机太晚

适用于小型项目

2.螺旋模型

特点：软件每进入一个阶段的时候，都会进行风险分析

优点：避免问题出现在线上

缺点：如果缺点分析错误，将会把问题暴露到线上

适用于大型项目以及风险较多的项目

3.增量和迭代

增量是逐块建造的概念，迭代是反复求精的概念

4.敏捷

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。

4.1scrum

scrum里面的角色
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成

product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布
计划，对产品负责。
scrum master 负责召开各种会议，协调项目，为研发团队服务。
研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

4.2基本流程

产品负责人负责整理user story，
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出
就是制定出这一期迭代要完成的story列表，
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每
个任务都有明确的负责人，并完成工时的初估计。
每日例会：召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取
得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达
到持续改进的效果

六、测试模型

6.1V模型

用户需求：产品经理收集及整理形成软件需求

需求分析与系统：验证需求是否正确 确定编程语言、确定框架

概要设计：项目结构

详细设计：每个接口涉及哪些库表,涉及任务

单元测试：测试每一个方法

集成测试：许多方法集中测试

系统测试：模块之间是否有影响

验收测试：验收的人进行测试

特点：左边开发，右边测试

优点：测试划分为许多类型

缺点：测试人员介入太晚，发现问题时机太晚

6.2W模型

特点：开发一个v 测试一个v

优点：测试人员尽早介入需求

缺点：测试人员和开发人员一定程度上串行的

不能适用敏捷

：