📖 前言:广州某农产品企业软件测试实习岗线下笔试记录。
🕒 1. 判断题
- 软件测试过程中要进行穷举测试。
- 没有产品说明书和需求文档的情况下,也能够做黑盒测试。
- 所有的软件缺陷都是需要修复,且可以修复的。
- 边界值分析法是一种黑盒测试技术,专注于测试输入和输出的边界条件。
- 冒烟测试是一种全面覆盖系统功能的测试方法。
- jmeter 是一款使用java 语言开发、仅支持http/https协议的性能测试工具。
- HTTP响应状态码404表示服务器内部错误。
- 接口的请求部分包括请求地址、请求方法、请求头、请求体。
解析:
-
错误
穷举测试是不现实的,尤其是对复杂系统。由于输入空间通常非常大,完全穷举是不可行的,因此软件测试通常会使用代表性测试用例来覆盖主要功能和边界情况。 -
正确
黑盒测试不依赖于产品的内部结构或实现细节,可以基于软件的功能要求进行测试。即使没有需求文档,测试人员仍可以根据用户的使用场景或历史行为进行测试。 -
错误
并非所有缺陷都需要修复。某些缺陷可能是低优先级,或者在产品发布后并不会对用户产生显著影响。此外,有些缺陷可能在技术上无法修复。 -
正确
边界值分析法是一种常用的黑盒测试技术,主要关注输入和输出的边界条件,旨在发现那些在边界附近容易出现的缺陷。 -
错误
冒烟测试是一种初步的测试,主要用于验证软件的基本功能是否正常工作,而不是全面覆盖系统功能。它通常在每次构建后进行,以快速判断软件是否可以进行进一步的测试。 -
错误
JMeter 是一款开源的性能测试工具,虽然它是使用 Java 开发的,但它支持多种协议,包括 HTTP/HTTPS、FTP、JDBC、SOAP、REST 等,因此并不限于 HTTP/HTTPS。 -
错误
HTTP 响应状态码 404 表示“未找到”(Not Found),而不是服务器内部错误。服务器内部错误通常对应状态码 500。 -
正确
接口的请求部分确实包括请求地址、请求方法(如 GET、POST 等)、请求头和请求体。它们共同定义了如何与 API 进行交互。
🕒 2. 选择题
-
以下关于处理缺陷不正确的是()
A.技术不支持的缺陷不需关注
B.需要关注推迟修改的缺陷
C.本版本所有缺陷必须修复后才能上线
D.关注开发人员修复缺陷时回复的修改意见和回归范围
E.测试工作过程中发现问题则需要马上提交bug到开发 -
以下说法正确的是()
A.软件质量是依靠软件测试来保证的
B.严格的软件测试可以有效地提高软件质量
C.只进行黑盒测试的系统也可以上线
D.HTTPS证书的主要作用包含加密客户端和服务器之间的通信、加快网页加载速度等。
E.当接口返回状态码403 Forbidden时,通常表示客户端没有权限访问请求的资源。
解析:
-
不正确的选项:
- A
技术不支持的缺陷虽然可能无法立即修复,但仍需关注,因为它们可能影响未来的功能或版本规划。 - C
并非所有缺陷必须在上线前修复,特别是低优先级或已知问题,可以推迟到后续版本修复。
- A
-
正确的选项:BCE,错误选项如下:
-
A
软件质量不仅依靠测试来保证,还包括需求分析、测试用例设计、编码等多个环节的质量管理,测试只是其中的一部分。 -
D
HTTPS证书的主要作用是加密通信和确保数据的完整性和真实性,而不是加快网页加载速度,后者是受多种因素影响的。
-
🕒 3. 计算题
按权重进行分摊是常用的方法之一,请根据下图所列数据,以各部门人数占总人数的权重,计算金额应怎样分摊。假设需分摊的总金额为1000元,占比计算结果精确到小数点后2位(如19.25%),分摊金额计算结果四舍五入精确到分。
部门 | 人数 | 占比 | 分摊金额 |
---|---|---|---|
A部 | 5 | ||
B部 | 14 | ||
C部 | 22 |
答案:
部门 | 人数 | 占比 | 分摊金额 |
---|---|---|---|
A部 | 5 | 12.20% | 121.95 元 |
B部 | 14 | 34.15% | 341.46 元 |
C部 | 22 | 53.66% | 536.59 元 |
🕒 4. 问答题
请简述什么是软件测试?为什么软件测试在软件开发过程中很重要?作为软件测试工程师在软件开发过程中可以承担什么角色?
解答:
软件测试概念:软件测试是评估软件应用程序或系统的一种过程,目的是识别和修复缺陷,验证软件产品特性是否满足用户的需求。
重要性: 软件测试有助于降低软件开发过程中的风险。 通过提前发现并解决潜在问题,可以减少在软件发布后出现严重的故障或漏洞,从而降低对业务和用户造成不良影响。
担任角色:
- 需求分析:参与需求评审,确保需求的可测试性和明确性。
- 测试计划和策略制定:制定测试计划,包括测试范围、资源、时间安排和风险评估。
- 设计测试用例:根据需求和功能设计详细的测试用例,包括正向和负向测试用例,确保覆盖所有关键功能和边界条件。
- 执行测试:手动或使用自动化工具执行测试,记录结果并报告缺陷。
- 缺陷管理:追踪缺陷的修复状态,验证修复是否有效,并回归测试以确保修复不影响其他功能。
- 测试报告:编写测试报告,提供测试结果的总结,帮助团队了解软件质量。
- 持续改进:参与回顾和改进测试流程,提升测试效率和质量。
🕒 5. 数据库查询
请写出以下问题的SQL查询语句。
客户表(user):
id | uid | name | sex | tel |
---|---|---|---|---|
1 | U0001 | 张三 | 男 | 18812345675 |
2 | U0002 | 李四 | 男 | 18812345676 |
3 | U0003 | 王五 | 男 | 18812345677 |
4 | U0004 | 许六 | 女 | 18812345678 |
订单表(order):
id | orderNum | uid | amount |
---|---|---|---|
1 | 00001 | U0001 | 34 |
2 | 00002 | U0002 | 87 |
3 | 00003 | U0004 | 108 |
4 | 00004 | U0001 | 99 |
5 | 00005 | U0001 | 78 |
6 | 00006 | U0001 | 87 |
7 | 00007 | U0003 | 80 |
8 | 00008 | U0002 | 88 |
(1)用一条 SQL 查询出 user 表中有多少名男生和女生。
(2)用一条 SQL 统计各个性别的消费订单数和消费总金额。
答案:
(1)
SELECT sex, COUNT(*) AS count FROM user GROUP BY sex;
(2)
SELECT
sex,
COUNT(order.id) AS order_count,
SUM(amount) AS total_amount
FROM
user
LEFT JOIN
`order` ON (user.uid = order.uid)
GROUP BY
sex;
解析:
- 第一条查询:通过
GROUP BY
对性别进行分组,并使用COUNT(*)
统计每个性别的用户数量。 - 第二条查询:使用
LEFT JOIN
将用户表与订单表连接,按性别分组并统计每个性别的订单数(COUNT(order.id)
)和消费总金额(SUM(amount)
)。使用LEFT JOIN
确保即使某些性别没有订单也能显示。
🕒 6. 接口测试
假设你负责一个电商平台的订单系统接口测试,该系统包含以下主要接口,请选择任一接口简单描述下如何开展接口测试工作,及该接口进行接口测试需要重点关注的内容。
- 创建订单接口:接收用户提交的订单信息,包括商品ID、数量、用户ID等,并返回订单ID。
- 查询订单接口:根据订单ID查询订单详情。
- 取消订单接口:取消指定订单。
解答:以创建订单接口为例
- 需求分析:了解接口的功能、输入参数、输出结果及预期行为。明确订单信息的格式要求(如商品ID、数量、用户ID等)和返回的订单ID格式。
- 测试用例设计:
- 正向测试用例:确保接口在有效输入下返回正确的订单ID。例如:
- 提交有效的商品ID、数量和用户ID。
- 负向测试用例:验证接口对无效输入的处理。例如:
- 商品ID不存在。
- 数量为负值或为零。
- 用户ID格式错误。
- 边界值测试:测试输入的边界条件,例如:
- 最大数量限制。
- 商品ID的字符长度。
- 正向测试用例:确保接口在有效输入下返回正确的订单ID。例如:
- 接口调用:使用工具(如 Postman)发送请求,记录返回结果。
- 结果验证:核对接口返回的结果与预期结果是否一致,检查返回的订单ID是否符合格式要求。
- 性能测试:考虑高并发情况下接口的响应时间和系统稳定性。
- 安全测试:验证接口的安全性,包括:
- 是否有身份验证机制。
- 是否对异常情况进行适当处理(如 SQL 注入、跨站脚本等)。
重点关注内容:
- 输入参数验证:确保所有必需参数都得到有效验证,防止无效数据提交。
- 返回结果格式:检查返回的订单ID是否符合预期格式,确保 JSON/XML 格式正确。
- 错误处理:验证接口在接收到无效请求时,是否返回明确的错误消息和状态码(如 400、404、500)。
- 性能与稳定性:在高并发情况下,接口是否能够保持稳定,响应时间是否在可接受范围内。
- 安全性:确保接口能够防止常见的安全攻击,保护用户数据和交易安全。
🕒 7. 测试用例
写出以下业务场景的测试用例(表格形式输出)
问题描述:假设你负责测试一个电商系统小程序。系统允许用户选择门店、浏览商品、添加至购物车和结算订单。请设计测试用例,覆盖以上的主要功能,并考虑各种可能的情况。
解答(示例):
测试用例ID | 测试类别 | 测试用例描述 | 前置条件 | 测试步骤 | 预期结果 | 实际结果 | 备注 |
---|---|---|---|---|---|---|---|
TC001 | 功能测试 | 选择门店 | 用户已登录 | 1. 打开小程序 2. 点击“选择门店” 3. 选择一个门店 | 门店选择成功,页面更新门店信息 | ||
TC002 | 功能测试 | 浏览商品 | 用户已选择门店 | 1. 点击“浏览商品” 2. 查看商品列表 | 商品列表正常显示 | ||
TC003 | 功能测试 | 添加商品至购物车 | 商品已浏览 | 1. 选择一个商品 2. 点击“添加至购物车” | 商品成功添加至购物车 | ||
TC004 | 功能测试 | 结算订单 | 购物车有商品 | 1. 打开购物车 2. 点击“结算” | 跳转到结算页面 | ||
TC005 | 界面测试 | 检查门店选择界面 | 用户已登录 | 1. 打开“选择门店”界面 | 界面元素清晰可见,无错位 | ||
TC006 | 界面测试 | 检查商品浏览界面 | 用户已选择门店 | 1. 打开商品浏览界面 | 商品信息完整,样式一致 | ||
TC007 | 易用性测试 | 确保用户能轻松选择门店 | 用户已登录 | 1. 观察用户选择门店过程 | 用户能迅速完成选择,无困惑 | ||
TC008 | 兼容性测试 | 在不同设备上测试小程序 | 用户已登录 | 1. 分别在iOS、Android设备上打开小程序 | 所有设备上功能正常,无布局问题 | ||
TC009 | 性能测试 | 测试高并发下的商品浏览 | 多个用户同时登录 | 1. 模拟100个用户同时浏览商品 | 商品列表加载时间小于2秒 | ||
TC010 | 安全测试 | 测试用户数据保护 | 用户已登录 | 1. 尝试访问其他用户的数据 | 访问失败,数据安全得到保护 | ||
TC011 | 网络测试 | 测试网络不稳定情况下的体验 | 用户已登录 | 1. 模拟弱网环境 2. 尝试浏览商品 | 系统能友好提示网络问题 | ||
TC012 | 中断测试 | 测试购物车操作中断后恢复 | 购物车有商品 | 1. 在购物车页面关闭小程序 2. 重新打开小程序 | 购物车内容保持不变 |
❗ 转载请注明出处
作者:HinsCoder
博客链接:🔎 作者博客主页