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

测试设计：等价类划分与边界值分析

问题1： 一个输入框要求输入1到100之间的整数（包含1和100）。使用等价类划分法，至少需要设计几个有效等价类和几个无效等价类？边界值分析又该如何取值？

答案与解析：

• ►等价类划分：
• ►有效等价类：1个（1到100之间的整数）。
• ►无效等价类：2个（小于1的整数；大于100的整数）。注意，非数字字符（如字母、特殊符号）属于另一类无效等价类，但本题限定“整数”，所以只考虑数值范围。
• ►边界值分析：
• ►上点：1和100（边界上的点）。
• ►离点：0和101（紧邻边界的点，属于无效等价类）。
• ►内点：取一个中间值，例如50（确保有效区域内取值正确）。
• ►通常边界值分析会设计5个测试数据：0、1、50、100、101。

易错点：很多人只想到“1-100”这个有效范围，忽略了“非数字字符”这类无效输入。边界值分析时，离点取值要严格根据边界类型（开区间还是闭区间）来确定。

缺陷管理：Bug的生命周期

问题2： 描述一个Bug从发现到关闭的完整生命周期（至少包含5个状态）。

答案与解析：

一个典型的Bug生命周期包括：

1. New（新建）：测试人员提交Bug，状态为New。

2. Assigned（已分配）：开发经理/负责人将Bug指派给某个开发人员，状态变为Assigned。

3. Open（打开/已确认）：开发人员确认这是一个有效的Bug，开始修复，状态变为Open。

4. Fixed（已修复）：开发人员完成代码修改，提交修复，状态变为Fixed。

5. Reopen（重新打开）：测试人员进行回归测试，如果Bug依然存在或修复不完整，则将其置为Reopen，重新进入修复流程。

6. Closed（已关闭）：测试人员验证修复通过，确认Bug已解决，将其关闭。

7. Rejected（已拒绝）：开发人员认为这不是Bug（如：需求如此、无法重现、重复提交等），可以拒绝该Bug，状态变为Rejected。

易错点：混淆“Assigned”和“Open”状态。Assigned只是指派了人，Open才表示开发者开始处理。另外，Rejected状态需要开发人员给出明确理由，测试人员可以据理力争，但不能随意关闭。

用例编写：判定表法

问题3： 一个登录功能，规则如下：如果用户名和密码都正确，则登录成功；如果用户名错误，则提示“用户名不存在”；如果用户名正确但密码错误，则提示“密码错误”；如果用户名或密码为空，则提示“输入不能为空”。请用判定表法设计测试用例。

答案与解析：

判定表的条件桩是：用户名是否正确、密码是否正确、用户名是否为空、密码是否为空。但注意，条件之间有逻辑关系（例如，用户名正确是密码判断的前提）。简化后的判定表如下：

解释：

• ►规则1：用户名正确且密码正确 → 登录成功。
• ►规则2：用户名正确、密码错误、两者都不为空 → 提示密码错误。
• ►规则3：用户名正确、密码为空 → 提示输入不能为空（优先处理为空的情况）。
• ►规则4：用户名错误、不为空 → 提示用户名不存在。
• ►规则5：用户名为空 → 提示输入不能为空。
• ►规则6：密码为空 → 提示输入不能为空。

易错点：条件组合太多时，要合并逻辑上不可能或重复的列（例如，用户名错误时，密码正确与否的结果相同）。判定表法能保证测试用例的完整性，但需要先梳理清楚条件之间的依赖关系。

自动化测试：元素定位

问题4： 使用Selenium WebDriver定位一个包含动态ID的按钮，该按钮的HTML如下：提交，其中12345是每次刷新页面都会变化的数字。请写出至少3种稳定的定位方式。

答案与解析：

绝对不能用By.ID，因为ID会变。稳定的定位方式有：

1. By.CSS_SELECTOR（类名+标签）：driver.find_element(By.CSS_SELECTOR, "button.btn-primary")。通过稳定的类名和标签组合定位。

2. By.NAME：driver.find_element(By.NAME, "submitBtn")。通过稳定的name属性定位。

3. By.XPATH（文本内容）：driver.find_element(By.XPATH, "//button[text()='提交']")。通过按钮的文本内容定位，不依赖任何属性。

4. By.XPATH（部分属性匹配）：driver.find_element(By.XPATH, "//button[contains(@id, 'submit_')]")。通过包含固定前缀的ID来定位。

易错点：新手常犯的错误是直接使用By.ID。当遇到动态ID时，优先选择稳定的类名、name、文本内容或CSS选择器。XPATH的contains()函数也很有用，但性能略低于CSS选择器。

性能测试：并发与吞吐量

问题5： “100个用户并发登录”和“100个用户同时登录”是同一个概念吗？为什么？请简要解释并发用户数与吞吐量的关系。

答案与解析：

不是同一个概念。

• ►100个用户并发登录：指在同一时间段内，有100个用户向服务器发送登录请求。服务器需要同时处理这100个请求（或通过排队机制依次处理）。这是性能测试中模拟真实高负载场景的核心概念。
• ►100个用户同时登录：字面意思是100个用户在完全相同的毫秒级时间点发起登录请求。这在真实世界中几乎不可能发生，通常用于测试服务器的瞬时峰值压力。

并发用户数与吞吐量的关系：

• ►并发用户数是系统承受的压力来源，而吞吐量（如每秒处理的事务数TPS）是系统处理能力的结果。
• ►理想情况下，随着并发用户数增加，吞吐量会线性增长，直到达到系统瓶颈（如CPU、内存、数据库连接池耗尽），之后吞吐量不再增加甚至下降。性能测试的目标就是找到这个“拐点”，即系统的最佳并发用户数。

易错点：混淆“并发”与“同时”。性能测试中，我们常通过集合点（Synchronizing Timer）来模拟“同时”操作，但更关注的是“并发”场景下的系统表现。吞吐量不是越高越好，而是要与系统资源消耗和响应时间一起评估。

---

总结：

这5道题覆盖了测试设计的核心方法、缺陷管理流程、用例编写技巧、自动化定位的稳定性以及性能测试的基本概念。如果你能全部答对，说明你的测试基础相当扎实。如果有些地方卡壳，不妨对照解析，把相关知识点再梳理一遍。