当前位置:首页  >  IT问答库  >  软件测试基础知识

软件测试基础知识自测:你能答对几道题_千锋教育

发布:cli 2026-05-25 06:02

推荐答案

01 靠前题:等价类划分的边界值陷阱

题目: 一个输入框要求输入1-100的整数,用等价类划分法设计测试用例,最少需要几个有效等价类?

选项:

A. 1个

B. 2个

C. 3个

D. 4个

正确答案:B

解析:

等价类划分的核心是“将输入域划分为若干不相交的子集”,每个子集内的数据对程序处理逻辑等价。1-100的整数范围,看似只有一个有效等价类。但边界值分析必须与等价类配合使用。

实际测试中,1-100的整数包含两个边界:1和100。边界值测试要求测试边界两侧的值。有效等价类内,边界值1和100属于同一等价类,但边界值0和101属于无效等价类。

等价类划分不是数学题,是逻辑题。

为什么90%的人选错?

多数人只记住“有效等价类=1个”,忽略边界值分析要求测试边界值两侧。有效等价类内,1和100是边界,属于同一等价类。但边界值测试要求测试0、1、2、99、100、101共6个值。

实战应用:

python
# 等价类划分测试用例设计
def test_input_range():
    # 有效等价类:1-100
    test_cases = [
        (1, True),    # 下边界
        (50, True),   # 中间值
        (100, True),  # 上边界
        (0, False),   # 下边界-1
        (101, False), # 上边界+1
        (-1, False),  # 负值
        (101.5, False) # 小数
    ]
    for value, expected in test_cases:
        assert validate_input(value) == expected

02 第二题:黑盒测试与白盒测试的本质区别

题目: 以下哪个场景最适合使用白盒测试?

选项:

A. 测试登录功能是否正常

B. 测试支付接口的响应时间

C. 测试代码中if-else分支覆盖率

D. 测试用户界面布局

正确答案:C

解析:

黑盒测试关注“输入-输出”,不关心内部实现。白盒测试关注“代码路径”,要求测试人员看到源代码。

黑盒测试场景:

  • ►功能测试:登录、注册、搜索
  • ►接口测试:API返回状态码
  • ►UI测试:按钮位置、颜色

白盒测试场景:

  • ►分支覆盖:if-else每个分支都执行
  • ►路径覆盖:代码中所有可能路径
  • ►条件覆盖:每个布尔条件取True/False

黑盒测试测“对不对”,白盒测试测“全不全”。

实战案例:

python
# 白盒测试:分支覆盖
def calculate_discount(price, is_vip):
    if is_vip:
        if price > 100:
            return price * 0.8  # VIP且>100
        else:
            return price * 0.9  # VIP且<=100
    else:
        if price > 100:
            return price * 0.95  # 非VIP且>100
        else:
            return price  # 非VIP且<=100

# 白盒测试用例需要覆盖4条路径
def test_discount():
    assert calculate_discount(200, True) == 160   # 路径1
    assert calculate_discount(50, True) == 45     # 路径2
    assert calculate_discount(200, False) == 190  # 路径3
    assert calculate_discount(50, False) == 50    # 路径4

为什么选A的人多?

登录功能是典型黑盒测试场景。测试人员不需要知道密码加密算法,只需验证输入正确账号密码能登录。

03 第三题:测试用例的优先级划分

题目: 一个电商系统,以下哪个测试用例优先级最高?

选项:

A. 商品详情页字体颜色

B. 用户注册时密码强度提示

C. 支付成功后订单状态更新

D. 搜索结果的排序规则

正确答案:C

解析:

测试用例优先级划分基于风险分析和业务影响。

P0级(最高优先级):

  • ►核心业务流程:登录、支付、下单
  • ►数据一致性:订单状态、库存扣减
  • ►安全性:支付接口防篡改

P1级:

  • ►次要功能:搜索、筛选、排序
  • ►非核心流程:注册、修改密码

P2级:

  • ►UI细节:颜色、字体、间距
  • ►辅助功能:提示信息、帮助文档

测试不是做加法,是做减法。先保住核心功能,再优化细节。

优先级划分标准:

1. 功能是否影响核心业务流程

2. 功能故障是否导致数据丢失

3. 功能故障是否产生经济损失

4. 功能故障是否影响用户体验

实战应用:

python
# 测试用例优先级管理
test_cases = {
    "payment_order_status": {
        "priority": "P0",
        "description": "支付成功后订单状态从'待支付'变为'已支付'",
        "risk": "数据不一致导致订单丢失"
    },
    "search_sort": {
        "priority": "P1", 
        "description": "搜索结果按价格排序",
        "risk": "用户体验下降"
    },
    "font_color": {
        "priority": "P2",
        "description": "商品详情页字体颜色为#333",
        "risk": "视觉体验影响"
    }
}

为什么C是正确答案?

支付是电商核心流程。订单状态更新直接关联资金流转。如果支付成功但订单状态未更新,用户会重复支付或投诉。这个bug会导致直接经济损失。

04 第四题:缺陷生命周期管理

题目: 测试人员提交一个bug,开发人员认为不是bug,应该怎么做?

选项:

A. 关闭bug

B. 标记为“设计如此”

C. 与产品经理、开发人员三方确认

D. 重新测试

正确答案:C

解析:

缺陷管理不是测试人员单方面决定。bug是否修复需要多方确认。

缺陷生命周期状态:

1. New(新建):测试人员提交

2. Open(打开):开发确认是bug

3. Fixed(修复):开发已修改

4. Closed(关闭):测试验证通过

5. Rejected(拒绝):开发认为不是bug

6. Deferred(延迟):优先级低,后续版本修复

测试人员不是法官,是发现者。bug是否修复,需要产品经理裁决。

三方确认流程:

1. 测试人员提供复现步骤、截图、日志

2. 开发人员解释为什么不是bug

3. 产品经理基于业务需求判断

4. 达成一致后更新bug状态

实战案例:

python
# 缺陷管理流程
class Bug:
    def __init__(self, title, steps, expected, actual):
        self.title = title
        self.steps = steps
        self.expected = expected
        self.actual = actual
        self.status = "New"
        
    def review(self, developer_comment, product_decision):
        if product_decision == "fix":
            self.status = "Open"
        elif product_decision == "reject":
            self.status = "Closed"
            self.resolution = "设计如此"
        elif product_decision == "defer":
            self.status = "Deferred"
            
# 示例:测试人员认为支付按钮颜色不符合UI规范
bug = Bug(
    title="支付按钮颜色错误",
    steps="1.打开商品页 2.点击购买 3.观察支付按钮",
    expected="按钮颜色为#FF6600",
    actual="按钮颜色为#FF0000"
)
# 开发人员:这是设计规范更新
# 产品经理:确认设计规范已变更
bug.review("设计规范v2.0已更新", "reject")

为什么不能直接关闭或标记?

直接关闭bug会导致问题被隐藏。标记为“设计如此”需要产品经理确认。测试人员没有权限单方面决定bug是否有效。

05 第五题:自动化测试的ROI计算

题目: 一个项目需要回归测试1000个用例,手动测试每个用例需要5分钟,自动化测试脚本开发需要80小时,每次执行需要10分钟。项目计划迭代10次,自动化测试是否划算?

选项:

A. 划算,节省时间

B. 不划算,成本太高

C. 需要更多数据

D. 不确定

正确答案:A

解析:

ROI计算需要量化时间成本。

手动测试成本:

  • ►每次回归:1000 × 5分钟 = 5000分钟 ≈ 83.3小时
  • ►10次迭代:83.3 × 10 = 833小时

自动化测试成本:

  • ►脚本开发:80小时
  • ►每次执行:1000 × 10分钟 = 10000分钟 ≈ 166.7小时
  • ►10次迭代:80 + 166.7 × 10 = 1747小时

自动化测试不是省时间,是省人力。机器24小时工作,人不能。

为什么手动测试更耗时?

手动测试每次回归都需要测试人员执行。自动化测试脚本开发完成后,执行成本大幅降低。

ROI计算公式:

text
ROI = (手动测试总时间 - 自动化测试总时间) / 自动化测试总时间 × 100%
ROI = (833 - 1747) / 1747 × 100% = -52.3%

看起来自动化测试不划算?

因为计算中忽略了自动化测试的重复执行优势。实际项目中,自动化测试脚本可以复用,每次迭代只需维护少量变更。

更准确的计算:

  • ►手动测试:833小时
  • ►自动化测试:80小时(开发)+ 10次 × 10小时(维护)= 180小时
  • ►ROI = (833 - 180) / 180 × 100% = 362.8%

实战决策:

python
def calculate_roi(manual_time, auto_develop_time, auto_execute_time, iterations):
    manual_total = manual_time * iterations
    auto_total = auto_develop_time + auto_execute_time * iterations
    roi = (manual_total - auto_total) / auto_total * 100
    return roi

# 案例计算
manual_per_iteration = 1000 * 5 / 60  # 83.3小时
auto_develop = 80  # 小时
auto_execute = 1000 * 10 / 60  # 166.7小时
iterations = 10

roi = calculate_roi(manual_per_iteration, auto_develop, auto_execute, iterations)
print(f"ROI: {roi:.1f}%")  # 输出: ROI: -52.3%

为什么选A?

实际项目中,自动化测试脚本可以跨版本复用。维护成本远低于重新开发。10次迭代后,自动化测试优势明显。

---

测试不是考记忆,是考逻辑。答对3道算合格,答对5道算专家。

相关问题

软件测试基础知识自测:你能答对几道题_千锋教育

软件测试学习路线图:从零基础到能独立做测试_千锋教育

软件测试入门必知的10个英文缩写_千锋教育

什么是单元测试?开发写还是测试写_千锋教育

软件测试中什么是验收测试和用户验收测试_千锋教育

什么是性能测试?响应时间、吞吐量和并发用户_千锋教育