new
This commit is contained in:
marsal
@ -1,75 +1,115 @@
|
||||
# 司机/车辆信息核验接口文档
|
||||
### 测试人员试用期考试题目
|
||||
|
||||
## 一、接口规范
|
||||
---
|
||||
|
||||
### 1.1 信息提交接口（服务商→中道）
|
||||
#### 一、选择题（每题5分，共10题）
|
||||
|
||||
**接口地址**: `/provider/driver-info`
|
||||
**请求方式**: POST
|
||||
**Content-Type**: application/json
|
||||
1. **（技术）以下哪种测试方法主要用于验证软件是否符合需求文档中的功能描述？**
|
||||
A. 白盒测试
|
||||
B. 黑盒测试
|
||||
C. 灰盒测试
|
||||
D. 单元测试
|
||||
|
||||
#### 请求参数说明：
|
||||
2. **（经验）在测试过程中发现一个偶现的缺陷，但无法稳定复现，此时应如何处理？**
|
||||
A. 直接忽略该缺陷
|
||||
B. 记录缺陷并注明“偶现”
|
||||
C. 要求开发立即修复
|
||||
D. 不提交缺陷报告
|
||||
|
||||
| 参数名 | 必填 | 类型 | 说明 |
|
||||
|----------------------|------|--------|--------------------------------------------------------------------|
|
||||
| providerCode | 是 | String | 服务商编码（由中道分配） |
|
||||
| operateType | 是 | String | 操作类型：1-新增 2-修改 3-停用 |
|
||||
| rescueNo | 是 | String | 救援师傅工号（唯一标识） |
|
||||
| rescueName | 是 | String | 师傅姓名 |
|
||||
| rescuePhone | 是 | String | 师傅联系电话 |
|
||||
| sex | 是 | String | 性别：0-女 1-男 |
|
||||
| identity | 是 | String | 身份证号码 |
|
||||
| nonMotorVehicle | 是 | String | 是否非机动车驾驶员：1-是 0-否（选1时驾照相关字段可不填） |
|
||||
| identityPhoto_1 | 是 | String | 身份证正面照片URL |
|
||||
| identityPhoto_2 | 是 | String | 身份证反面照片URL |
|
||||
| licenseType | 否 | String | 驾照类型（A1/A2/A3/B1/B2/C1/C2） |
|
||||
| licenseStartDay | 否 | String | 驾照领证时间（格式：yyyy-MM-dd） |
|
||||
| licenseEndDay | 否 | String | 驾照失效时间（格式：yyyy-MM-dd） |
|
||||
| LicensePhoto | 否 | String | 驾照照片URL |
|
||||
| rescuePersonPhoto | 否 | String | 师傅正面照URL |
|
||||
| belongType | 是 | String | 归属类型：1-自有师傅 0-外协师傅 |
|
||||
| timestamp | 是 | String | 请求时间戳（格式：yyyy-MM-dd HH:mm:ss） |
|
||||
3. **（规范）以下哪种命名方式符合测试用例的规范要求？**
|
||||
A. Test_Case_1
|
||||
B. TC_Login_ValidCredentials
|
||||
C. Case123
|
||||
D. LoginTest
|
||||
|
||||
### 1.2 核验通知接口（中道→服务商）
|
||||
4. **（技术）以下哪项是性能测试工具？**
|
||||
A. JIRA
|
||||
B. Selenium
|
||||
C. JMeter
|
||||
D. Postman
|
||||
|
||||
**回调地址**: 需服务商提前配置
|
||||
**通知方式**: POST
|
||||
**Content-Type**: application/json
|
||||
5. **（经验）测试用例设计中，等价类划分法的核心目的是：**
|
||||
A. 减少测试用例数量
|
||||
B. 覆盖所有可能的输入组合
|
||||
C. 仅测试边界值
|
||||
D. 验证用户界面
|
||||
|
||||
#### 通知参数说明：
|
||||
6. **（规范）测试文档中，以下哪项内容属于测试计划的必要组成部分？**
|
||||
A. 缺陷统计表
|
||||
B. 测试范围与目标
|
||||
C. 测试用例详细步骤
|
||||
D. 开发人员名单
|
||||
|
||||
| 参数名 | 必填 | 类型 | 说明 |
|
||||
|---------------|------|--------|--------------------------------------|
|
||||
| providerCode | 是 | String | 服务商编码 |
|
||||
| rescueNo | 是 | String | 救援工号 |
|
||||
| status | 是 | String | 核验状态：certifying/fail/success/expired |
|
||||
| timestamp | 是 | String | 状态变更时间（格式同上） |
|
||||
| remark | 否 | String | 失败原因说明 |
|
||||
7. **（技术）自动化测试脚本的维护成本较高的主要原因是：**
|
||||
A. 脚本语言复杂
|
||||
B. 需求频繁变更导致脚本失效
|
||||
C. 测试人员能力不足
|
||||
D. 开发工具限制
|
||||
|
||||
## 二、业务流程
|
||||
8. **（经验）在敏捷开发模式下，测试人员的主要职责不包括：**
|
||||
A. 参与需求评审
|
||||
B. 编写用户手册
|
||||
C. 执行每日构建测试
|
||||
D. 设计测试用例
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant 服务商系统
|
||||
participant 中道系统
|
||||
|
||||
服务商系统->>中道系统: 提交司机信息（/provider/driver-info）
|
||||
中道系统-->>服务商系统: 返回受理结果
|
||||
|
||||
alt 数据校验失败
|
||||
中道系统-->>服务商系统: code=2001
|
||||
else 校验通过
|
||||
中道系统->>中道系统: 状态变更为「认证中」
|
||||
|
||||
loop 核验流程
|
||||
中道系统->>中道系统: 人工审核/系统核验
|
||||
end
|
||||
|
||||
中道系统->>服务商系统: POST核验通知（/provider/verification-notify）
|
||||
|
||||
alt 核验成功
|
||||
服务商系统->>服务商系统: 锁定认证字段
|
||||
else 核验失败/过期
|
||||
服务商系统->>服务商系统: 开放对应修改权限
|
||||
end
|
||||
end
|
||||
9. **（规范）以下哪种行为违反了缺陷管理规范？**
|
||||
A. 缺陷描述中包含复现步骤和实际结果
|
||||
B. 将多个相似缺陷合并为一个报告
|
||||
C. 缺陷状态标记为“已关闭”后不再验证
|
||||
D. 使用优先级和严重程度区分缺陷
|
||||
|
||||
10. **（技术）以下哪项是安全测试的典型场景？**
|
||||
A. 验证用户登录功能
|
||||
B. 检测SQL注入漏洞
|
||||
C. 测量系统响应时间
|
||||
D. 检查界面布局兼容性
|
||||
|
||||
---
|
||||
|
||||
#### 二、填空题（每题3分，共5题）
|
||||
|
||||
1. **（技术）测试用例的三大核心组成部分是：______、测试步骤、预期结果。**
|
||||
2. **（规范）测试计划中应明确测试的______、资源分配、风险评估和交付物。**
|
||||
3. **（经验）BUG的生命周期通常包括新建、______、修复、验证、关闭。**
|
||||
4. **（技术）性能测试中，TPS的全称是______。**
|
||||
5. **（规范）代码审查时，应重点关注______、可维护性和潜在风险。**
|
||||
|
||||
---
|
||||
|
||||
#### 三、简答题（每题5分，共7题）
|
||||
|
||||
1. **（技术）请简述黑盒测试与白盒测试的核心区别。**
|
||||
2. **（经验）如何设计一个高覆盖率的登录功能测试用例？**
|
||||
3. **（规范）测试人员在提交缺陷报告时需包含哪些关键信息？**
|
||||
4. **（技术）什么是回归测试？在什么情况下需要执行回归测试？**
|
||||
5. **（经验）当开发人员不认可你提交的缺陷时，应如何处理？**
|
||||
6. **（规范）测试用例评审的参与方通常包括哪些角色？**
|
||||
7. **（技术）请列举3种常见的接口测试工具。**
|
||||
|
||||
---
|
||||
|
||||
### 标准答案
|
||||
|
||||
#### 一、选择题
|
||||
1. B 2. B 3. B 4. C 5. A
|
||||
6. B 7. B 8. B 9. C 10. B
|
||||
|
||||
#### 二、填空题
|
||||
1. 用例编号/名称
|
||||
2. 测试范围
|
||||
3. 确认/分配
|
||||
4. Transactions Per Second（每秒事务数）
|
||||
5. 代码逻辑
|
||||
|
||||
#### 三、简答题
|
||||
1. **黑盒测试**关注功能是否符合需求，不关注内部代码；**白盒测试**基于代码结构设计用例，验证逻辑正确性。
|
||||
2. 设计用例需覆盖：有效/无效用户名密码、空输入、特殊字符、密码加密、错误提示、多次失败锁定等场景。
|
||||
3. 缺陷标题、复现步骤、实际结果、预期结果、环境信息、截图/日志、严重程度、优先级。
|
||||
4. **回归测试**用于验证代码修改未引入新缺陷。需执行的情况：需求变更、缺陷修复、版本迭代后。
|
||||
5. 提供更详细的复现步骤和日志；沟通需求文档或设计规范；若仍有争议，可请团队负责人或产品经理仲裁。
|
||||
6. 测试人员、开发人员、产品经理、项目经理。
|
||||
7. Postman、JMeter、SoapUI、Swagger（任选3个）。
|
||||
|
||||
---
|
||||
|
||||
试卷设计覆盖技术能力、实际经验和规范意识，适用于评估测试人员的综合能力。
|
||||
Reference in New Issue
Block a user