软件测试开发实习生_实习软件测试项目

软件测试

软件测试的定义

使用人工或自动的手段运行或测试软件得到实际结果，找 BUG、发现缺陷，检验软件是否满足预期的需求。

• 软件是否符合设计要求

• 软件是否符合用户的实际需求

软件测试的目的

以最小的人力、物力、时间成本，找出软件中潜在的错误与缺陷。

软件测试的原则

• 测试应尽早介入。缺陷越早发现，修改所需成本越低。

• 无法穷尽测试。

• 缺陷是必然的，没有发现缺陷也不能证明没有缺陷。

• 80% 的用户只用到 20% 的功能。

测试流程

1. 需求分析

   阅读需求文档、产品文档、设计说明书，分析真正的需求。

2. 制定测试计划、方案

   • 制定测试的范围、进度安排、人力物力安排、测试策略、风险评估…

   为什么去做、何时去做、谁去做、怎么做、做哪里、如何去做。

   • 针对测试的目标选取测试工具，注重测试的重点。

3. 设计测试用例

4. 执行测试用例

5. 打印测试报告，进行评估

开发模型

瀑布模型

计划时期

• 问题定义
• 可行性研究

开发时期

• 需求分析
• 大概设计
• 详细设计
• 编码
• 测试

运行时期

• 维护

特点

• 一个阶段完成以后才能进入下一个阶段
• 每个阶段都有一个检查点，比对文档，发现是否不合理，可以保证质量
• 前一阶段完成后，只需关注后续阶段

缺点

• 每个阶段都是确定的，不适合需求模糊或经常变动的系统，灵活性差
• 用户需要较长时间的等待

增量模型

规格说明 -> 设计 -> 实现和集成 -> 交付客户

不是等待整个系统开发完成，每次只是增加了一个小的功能，就交付给客户。

快速原型

快速分析 -> 构造 -> 运行 -> 评价

快速实现了一个很小的需求，适合需求不明确的软件系统开发，但选用的开发技术与工具不一定符合主流的发展，快速建立的系统结构加上连续的修改可能导致产品质量低下。

测试模型

V 模型

单元测试 -> 集成测试 -> 系统测试 -> 验收测试，分别对应如下阶段：

编码 -> 详细设计 -> 概要设计 -> 需求分析

缺点：测试介入较晚，对于前期的一些缺陷无法发现和修改。

W 模型

需求分析 -> 概要设计 -> 详细设计 -> 编码 -> 集成 -> 实施 -> 交付，分别对应：

验收测试设计 -> 集成测试设计 -> 单元测试设计 -> 单元测试 -> 集成测试 -> 系统测试 -> 验收测试

优点：测试伴随软件的整个生命周期

软件测试分类

测试阶段

• 单元测试

  编码完成前或后测试，主要测试类、方法（函数）、模块

• 集成测试

  单元测试完成以后、模块已经写完编码时测试，主要测试模块与模块之间的调用

• 系统测试

  集成测试完成后，主要测试整个程序、软件、app、网站项目

• 交付测试

  系统测试之后，测试整个系统，内测、公测

是否覆盖源码

• 黑盒测试

  看不见源码，只关注是否实现功能，不关注内部实现，运行程序得到的实际结果与预期结果比对。

  用于功能测试、性能测试。

  功能测试主要测试：

  • UI 测试
  • 业务测试
  • 文档测试
  • 易用性测试
  • 安装、卸载
  • 兼容性测试：多个浏览器都能正常运行？不同平台？（不同系统 windows、安卓、ios，不同品牌的手机等）软件升级后是否兼容以前的数据？是否打开其它有关联的软件？

  性能测试

  • 一般性能测试，包括响应速度、cpu 的使用率、gpu 的使用率、内存占用
  • 稳定性测试：服务器、程序的稳定性
  • 负载测试，能够承受高并发的访问
  • 压力测试，在资源极少的情况下运行（如内存不足），观察程序的状况

• 白盒测试

  可以看见源码内容，包括：

  • 语句覆盖，确保代码中的每条语句都会被执行
  • 条件覆盖，每个条件分支都会执行

• 灰盒测试

  除了关心输入输出，也要关心程序运行的状态，但不需要关心所有代码

冒烟测试

检查最基本的模块是否能正常运行

测试用例

为了某个特殊目标准备一组输入、执行条件以及预期结果，测试程序是否符合特定需求。

测试用例的要素

等价类划分法

将所有可能的输入划分成若干部分，从每部分中抽取有代表性的数据作为测试用例。

有效等价类：合理、有意义的输入数据构成的集合

无效等价类：不合理、无意义的输入数据构成的集合，要给出错误原因，程序也不应崩溃

边界值法

边界值易出错，输入数据应取边界值、离边界值最近的点。

因果图

考虑输入条件的组合情况、制约关系。

条件：

1. 输入 50 元
2. 输入 100 元
3. 充值 50 元
4. 充值 100 元

结果：

a. 完成充值、退卡

b. 提示充值成功

c. 找零

d. 提示错误

出现记为 1，不出现记为 0
exclude：至多只有一个 1
include：至少有一个为 1
mandatory：若一个是 1，另一个必须是 0
only：有且只有一个为 1
required：若一个是 1，另一个必须是 1
1
2
3
4
5
6

判定表

正交表

https://cnblogs.com/gisen_6/p/3708201.html

https://blog.csdn.net/jiangjunsss/article/details/123684835

以最小的用例获得最大的测试覆盖率。

红色、粗体、宋体、30

红色、斜体、正楷、40

红色、下划线、方正、50

黄色、粗体、正楷、50

黄色、斜体、方正、30

…

可通过 allpairs 生成。

场景法

从起点经过一系列步骤达成某一结果，到达终点的过程，用于冒烟测试。

基本流：a 拨打 b 的电话 -> b 电话响铃 -> b 接电话 -> 通话中 -> 挂断

备选流：a 拨打 b 的电话 -> b 电话未响铃 -> 提示对方关机或不在服务区，a 挂机结束

备选流2：b 电话响铃 -> b 主动挂断 -> 提示对方关机或不在服务区，a 挂机结束

备选流3：通话中 -> c 拨打 a 的电话 -> 对方忙，c 挂机结束

…

流程分析法

找出业务流程的各个页面与其它页面的跳转关系，分为广度优先和深度优先。

每个节点能够到达的地方：

深度优先：选择一条路往前走，遇见多条分支，只选择一条分支走到黑；若选择的分支已重复走过，返回上一节点，选择另一条分支，直到覆盖到所有分支。

a -> b -> e -> f -> c -> h -> g 返回上一节点 h、c、f、e、b、a，选择 d 继续往下走。d -> i 返回上一节点 d -> j。

广度优先：走遍当前节点的所有相邻节点，再依次走遍相邻节点周围的相邻节点。

a -> b、c、d

b -> e、f

c -> h、g

d -> j、i

先考虑场景法，关注业务逻辑是否实现

需要输入数据的地方，考虑等价类划分法和边界值法

包含输入条件的组合情况，使用因果图与判定表法

对于配置类软件，需要考虑参数的组合情况，使用正交表

文章质量提示
此文章质量较低，不会获得较多流量扶持！ 可能的原因为：篇幅太短，广告涉嫌违规，外链过多，缺少代码，图片涉嫌违规。 了解规则