一、测试基础（1）

合集 - 大锅乱炖(8)

1.一、测试基础（2）2024-05-232.一、测试基础（3）2024-05-233.二、接口自动化测试（1）2024-05-23

4.一、测试基础（1）2024-05-23

5.二、接口自动化测试（2）2024-05-236.三、Web自动化测试（1）2024-05-247.三、Web自动化测试（2）2024-05-248.三、Web自动化测试（3）2024-05-24

收起

一、需求分析

项目立项后，对于整体产品的需求进行认识和理解（与功能测试的需求分析是一致的）。注意：此时只有产品需求文档，架构师还没有开始建模，主要目的是保证各部门（产品、开发、测试...）对于需求理解一致。

二、需求评审

1、周一早上九点，产品经理群发最新迭代版本的prd文档，并约定评审时间为上午10点

2、开会，参与人员：产品+UI+开发+测试，由产品对PRD进行讲解

3、各角色该提出的问题：

• UI主要关心页面美化效果，以及交互方式的问题

• 开发主要关心功能实现的问题

• 测试？举例如下

• 搜索用户功能——输入框内容的类型和长度约束是什么？输入框内容是精确还是模糊查询？

• 权限字符意义何在？

• 创建时间——精度？开始和结束时间的逻辑？能否选择开始时间=结束时间？

• 能否选择开始时间>结束时间？

• 比较有技术的问题：数据唯一性问题？根据角色名称还是根据权限字符？

• 比较有技术的问题：越权访问时的报错处理问题？是从页面和接口两个层面？

  面试题：

  你们公司需求评审流程是什么样的？

  1、首先是周一早上，产品经理群发网页版的prd文档，让大家熟悉

  2、一般是一个小时后，项目组的产品、UI、开发、测试都来开会

  3、会议主要是由产品经理讲解，再有个方向问

  4、一般一个上午就会全部结束（prd定稿）

  你在需求评审中，提出过那些问题？

  • 最常见的是产品经理没有约束输入字段的长度和类型问题，需要提出并在会议明确

  • 还有数据问题，不能只看原型图，得确认具体的逻辑，比如模糊查询还是精确查询数据唯一性问题，展示字段是否有意义，以及具体查表和排序逻辑

  • 当然还有异常情况，比如越权访问等

 

三、测试计划、用例编写

 

测试计划都包含哪些内容？

1. 测试目标与测试范围——大多数公司不写

2. 角色分工和职责

3. 任务安排、进度与资源分配

4. 风险评估和应急计划

5. 测试的各项标准

测试用例编写：

1、通过思维导图，提取prd文档中的测试点

2、通过测试点分析结果，整理测试用例

很多公司在这一步就结束了，并不会输出测试用例，后续评审直接对测试点进行评审
1、不用输出测试用例的公司类型：产品线较长，迭代快的中小型企业（包括很多上市公司）
2、输出测试用例的公司类型：大厂（核心产品）、银行

用例的设计：

方法一：等价类

这种方法将输入数据划分为若干等价类，以确保在每个等价类中的数据具有相同的行为。通常，只需测试每个等价类的一个有效值和一个无效值。

示例：假设一个登录页面，用户名和密码的有效字符范围为 6 到 12 个字符，那么可以编写以下测试用例：

• 有效等价类测试：输入包含 6 个字符的有效用户名和密码。
• 无效等价类测试：输入少于 6 个字符或多于 12 个字符的用户名和密码。

方法二：边界值

这种方法专注于测试输入数据的边界情况，因为通常在边界处会出现错误。它包括测试最小边界、最大边界和边界之间的值。

示例：对于同样的登录页面，测试用例可能包括：

• 最小边界测试：输入包含 6 个字符的用户名和密码。
• 最大边界测试：输入包含 12 个字符的用户名和密码。

边界之间测试：输入包含 7 到 11 个字符的用户名和密码。

上点：输入边界上的点

离点：离上点最近的点，如果输入域为开区间，则离点在有效范围内，如果输入域为闭区间，则离点在有效范围外

内点：输入域范围内的点

例：

  [6,10] 上点为 6、10 ，离点为5，11， 内点为[7,9]

（6，10） 上点为6，10 ，离点为（7和9），内点为（8）

  [6，10) 上点为（6，10），离点为（5，9），内点为（7，8）

方法三：流程分析

银行取款实例

方法四：判定表

这种方法将测试条件和其对应的动作组合成一个决策表，以便在各种条件组合下进行测试。

示例：考虑一个简单的登机规则系统，根据乘客的舱位和登机牌号决定登机顺序。相关测试用例可能包括：

• 对于不同的舱位和登机牌号组合，确定正确的登机顺序。
• 对于无效的舱位和登机牌号组合，确保系统给出适当的错误提示。

面试题：

你们公司以前是怎么管理测试用力的？

• 我们使用的企业版的石墨文档

• 测试用例在石墨文档上以表格形式进行记录

• 团队可以根据版本号随时查看某个版本的测试用例内容及执行结果

• 后续测试用例维护更新也会在石墨上面进行编辑，同步给其他成员

你负责的项目有多少条测试用例？

• 这个要看项目大小

• 我最近负责的wms项目，每个迭代一般会新增100-200条测试用例

• 高速迭代了一年左右，总数大概有4/5千条

  你参与过开发评审会议吗？一般在会议桑你关注什么问题？

  • 每个迭代都参加

  • 一般研发老大发起开发评审会议，参与人员是相关前后端和测试，有时会UI也会来

  • 我在会议桑一般关注内容是新增了几个接口，就功能设计的修改项是什么，数据表结构和数据的变更问题

  测试用例评审过程中，提出过那些问题？

  • 这类问题还是比较多的，毕竟黑盒测试角度去设计，一个人思维有限

  • 比如弱网状态下表单的连续提交，结果未知，需要考虑

  • 比如在登录过期时提交操作会出现报错信息，能不能跳转到登录页面