学习软件测试的第十六天

1.给支付宝的支付功能设计测试用例

通俗易懂解题思路

首先，我们要考虑支付宝支付功能中可能涉及的几个大场景：

1. 支付成功

2. 支付失败

3. 支付过程中断（比如用户取消支付，网络中断）

4. 支付的边界情况（如金额最小、最大值等）

然后我们按以下步骤进行测试用例设计：

• 功能性测试：验证支付功能是否按预期工作（正确金额、正确账户等）

• 异常测试：验证支付失败、异常场景的处理（如网络问题、余额不足）

• 安全性测试：验证支付过程中用户信息是否安全（如防止篡改支付金额、支付密码等）

• 兼容性测试：验证支付功能在不同设备、浏览器上的表现

• 性能测试：验证在高并发情况下，支付功能的稳定性与响应时间

根据上面思路设计几个典型的测试用例

1. 支付功能正常流程测试

2. 支付失败场景测试

3. 支付过程中断场景测试

4. 边界情况测试

5. 安全性测试

6. 兼容性测试

 面试术语

在设计支付宝支付功能的测试用例时，我会从以下几个方面进行全面覆盖：

1. 功能性测试：验证支付功能的核心流程是否正常，包括支付金额验证、支付密码验证、支付成功或失败的场景。

• 测试支付金额是否正确，支付是否成功。

• 测试余额不足、密码错误等异常支付场景，确保系统能正确处理失败。

1. 支付中断场景：验证支付过程中可能出现的各种中断情况。

• 如用户取消支付、网络中断、支付超时等，确保系统能正确提示用户并保持数据一致性。

1. 边界情况测试：测试支付金额的边界情况，包括最小金额和最大金额的支付。

• 验证系统能正确处理边界值，防止支付金额异常。

1. 安全性测试：确保支付过程中的数据安全。

• 如防止支付金额篡改、密码暴露等，测试系统是否能防范常见的安全风险。

1. 兼容性测试：确保支付功能在不同浏览器和设备上的兼容性。

• 测试支付功能在主流浏览器（如 Chrome、Firefox）和不同设备（安卓和 iOS）上是否正常运行。

我通过设计覆盖正常、异常、边界、安全、兼容等多方面的测试用例，来确保支付功能的健壮性和用户体验。

2.数据库如何多表查询

在数据库中，进行多表查询时常用以下几种连接方式：

1. 内连接（INNER JOIN）：返回两个表中符合连接条件的交集数据。常用于查询多个表之间有共同字段的数据。

   SELECT columns FROM table1 INNER JOIN table2 ON condition;

2. 左连接（LEFT JOIN）：返回左表的所有数据和右表中符合条件的数据。若右表没有匹配数据，结果显示 NULL。

   SELECT columns FROM table1 LEFT JOIN table2 ON condition;

3. 右连接（RIGHT JOIN）：返回右表的所有数据和左表中符合条件的数据。若左表没有匹配数据，结果显示 NULL。

   SELECT columns FROM table1 RIGHT JOIN table2 ON condition;

4. 全连接（FULL JOIN）：返回两个表的所有数据。无论是否匹配，所有记录都会被显示，未匹配的部分用 NULL 填充。

   SELECT columns FROM table1 FULL JOIN table2 ON condition;

5. 自连接（SELF JOIN）：用于查询同一个表中的不同行之间的关系，通过将表别名化来进行自连接。

   SELECT columns FROM table1 AS t1 LEFT JOIN table1 AS t2 ON condition;

这些多表查询方式帮助我们高效地从不同表中获取相关数据，适用于不同的业务场景。

3.你觉得版本能上线的标准是什么

二、总结为标准面试术语版：

我认为版本能上线的标准应包括以下几个方面：

1. 功能完成与验证：所有计划功能已经完成开发并经过全面的测试验证，无阻塞性缺陷；

2. 缺陷管理：所有重大和高优先级的缺陷已修复，剩余的中低优先级缺陷不会影响关键功能；

3. 性能验证：版本的性能指标（响应时间、吞吐量等）符合预期，且经过压力测试验证无瓶颈；

4. 安全性与稳定性：系统无重大安全漏洞，经过稳定性测试验证，具备容错能力；

5. 兼容性与回归测试：兼容性测试已完成，确保新版本不会影响已有功能，回归测试无关键问题；

6. 用户体验：用户界面和交互符合设计要求，用户体验顺畅；

7. 版本文档：所有相关文档已经更新并且完整，包括用户手册、API文档和部署手册；

8. 备份与回滚方案：上线前已准备好完整的备份和回滚方案，确保出现问题时能迅速恢复。

这些标准确保了版本的质量和稳定性，并保障了用户的正常使用体验。

4.你认为怎么样是一个好的软件测试工程师

我认为一个好的软件测试工程师应具备以下几个关键特点：

1. 扎实的专业技能：熟练掌握常见的测试方法和工具，包括功能测试、性能测试、自动化测试和接口测试，能够高效完成各类测试任务；

2. 细致入微的测试思维：能够从用户的角度出发，发现潜在的缺陷和问题，具备强大的问题发现能力；

3. 良好的沟通与协作能力：能够与开发人员、产品经理以及其他团队成员有效沟通，及时反馈问题，推动问题的解决；

4. 主动性与责任心：不仅完成分配的测试任务，还能主动发现问题，提出改进建议，帮助团队提高测试效率和质量；

5. 持续学习与适应能力：随着技术不断发展，能够跟随技术趋势，不断学习新工具和技术，提升自己的专业水平；

6. 高度的细节意识与质量要求：对软件的质量要求高，注重每一个细节，确保产品达到高质量标准，真正为用户提供价值。

一个好的测试工程师不仅是一个执行者，更是质量的守护者，能够通过细致的测试工作，确保产品的稳定性和用户体验。

5.测试人员一般用Linux做什么

测试人员使用Linux环境的原因主要是因为Linux在自动化测试、性能测试、服务器管理、日志分析等方面具有优势。具体使用场景包括：

1. 自动化测试脚本编写与执行：利用Linux的命令行工具和自动化框架（如 Selenium、Jenkins）进行测试脚本的编写、调度和执行；

2. 性能与负载测试：在Linux环境中使用性能测试工具（如 JMeter、Locust）进行高并发、压力测试，评估系统性能；

3. 服务器端功能验证：测试人员通过SSH连接到Linux服务器，检查系统日志、数据库连接、API接口等；

4. 日志分析与问题排查：使用Linux的文本处理工具（如 grep、awk）对系统和应用日志进行分析，定位问题；

5. 版本控制与持续集成管理：在Linux环境下使用Git进行版本管理，结合Jenkins等工具进行自动化构建和持续集成；

6. 测试环境搭建与管理：使用Linux环境搭建测试环境，利用Docker等工具进行虚拟化和容器化管理，保证测试环境的一致性。

6.如果开发因为多个任务并行使开发周期拉长，从而导致测试时间被压缩怎么办

在开发周期拉长、测试时间被压缩的情况下，我会采取以下策略来应对：

1. 与开发团队协作，明确优先级：通过与开发团队沟通，明确当前任务的优先级，确保最关键和最紧急的功能在有限的时间内得到充分验证；

2. 并行测试：通过并行测试策略，将测试工作分散进行，确保不同模块的测试不互相耽误，充分利用测试时间；

3. 自动化测试：利用自动化测试加速回归测试，确保常见的功能和高频的测试场景能够快速覆盖，减轻人工测试负担；

4. 高风险区域聚焦：在时间有限的情况下，专注于高风险区域和集成测试，优先测试修改频繁或关键路径的功能；

5. 灵活调整测试计划：根据实际情况调整测试计划，及时向项目经理和开发团队反馈，确保最重要的功能得到测试，并考虑逐步发布功能来分摊风险。

通过这些策略，可以在确保核心质量的前提下应对压缩的测试时间，并确保上线的版本具有良好的稳定性。

7.微信群发红包要怎么测试

详细解释

1️⃣ 功能性测试

目的：确保红包功能按预期工作，红包金额分配正确，发放正常。

• 测试用例示例：

  1. 发放金额正确性：输入红包金额，确保发放金额与总金额一致，分配的红包金额符合预期（如普通红包、拼手气红包等）。

  2. 红包数量：确保红包数量与输入的数量一致，避免多发或少发。

  3. 红包发送成功：发送红包后，红包成功展示在群里，且红包可以被群成员领取。

  4. 红包领取：确保领取红包的用户可以看到红包金额，并且金额正确。

2️⃣ 异常场景测试

目的：验证系统在极端或异常情况下的表现，如网络中断、金额不符等。

• 测试用例示例：

  1. 网络中断：在红包发送过程中断开网络，验证系统是否能够处理网络异常，是否能重新连接或提示用户。

  2. 金额不足：发送的红包金额大于账户余额，系统应该提示余额不足，不能发送红包。

  3. 重复发送红包：测试用户在发送红包时多次点击发送，系统是否会出现重复红包或错误提示。

  4. 红包领取限制：模拟已经领取红包的用户再次领取红包，验证系统是否有重复领取的限制。

  5. 红包数量限制：测试红包数量超过系统最大支持数量时，系统是否有提示和正确限制。

3️⃣ 边界情况测试

目的：确保红包功能在极限条件下依然能正常工作。

• 测试用例示例：

  1. 最小金额红包：测试最小红包金额（例如 0.01 元）是否能正常发放。

  2. 最大金额红包：测试最大红包金额，确保金额没有超出系统允许范围。

  3. 最多接收红包的用户数：测试发送给极大数量群成员的红包是否能成功。

  4. 红包发送频率：限制每个用户的红包发送次数，确保不会超出发送频率限制。

4️⃣ 用户体验与性能测试

目的：验证红包功能是否符合用户体验，确保在高并发情况下稳定运行。

• 测试用例示例：

  1. UI展示：确保红包金额、红包个数等信息在界面上清晰展示，用户操作流程简洁流畅。

  2. 并发性能测试：在群成员接收红包的高峰期，模拟大量用户同时领取红包，确保系统能够稳定处理并发请求。

  3. 红包领取的延迟：测试不同网络环境下，领取红包的延迟是否符合预期。

面试术语 

在测试微信群发红包功能时，我会从以下几个方面进行全面的测试：

1. 功能性测试：确保红包功能的基础操作正常，如金额分配正确、红包数量正确、发送成功、领取准确等；

2. 异常场景测试：验证系统在极端情况下的表现，如网络中断、金额不足、红包重复发送、领取限制、红包数量限制等；

3. 边界情况测试：测试极限条件下红包的表现，如最小金额红包、最大金额红包、最大接收人数、发送频率限制等；

4. 性能与用户体验测试：验证系统在高并发情况下的稳定性，确保用户界面友好，红包金额、个数清晰展示，并且在不同网络环境下领取红包的响应时间合理。

通过这些全面的测试，可以确保微信群发红包功能在不同场景下都能稳定、安全地运行。

8.selenium：有哪些定位方式，最常使用的有那几个？切换窗口的关键字是什么？显示等待和隐式等待的区别

在 Selenium 中，常用的元素定位方式包括：

1. ID定位、名称定位、类名定位、标签名定位、链接文本定位和部分链接文本定位，这几种是最常用的。

2. 另外，CSS选择器定位和XPath定位也非常常用，尤其是在复杂的页面结构中，XPath可以帮助我们精确地定位元素。

对于窗口切换，使用 switchTo() 方法切换到需要的窗口，使用 getWindowHandles() 获取所有窗口句柄，然后可以切换到新窗口或父窗口。

显示等待和隐式等待是 Selenium 中两种等待机制：

1. 隐式等待是在整个 WebDriver 生命周期内设置的一个全局等待时间，适用于元素加载时间不可预测的情况；

2. 显示等待是通过 WebDriverWait 和 ExpectedConditions，对某个特定元素或条件进行等待，直到条件满足或者超时，适用于需要精确控制等待条件的场景。

9.python：给你一个列表如何对里面的数据进行去重；如何删除最后一个元素；列表和元组的区别

在 Python 中，针对给定的列表，我会采取以下方法：

1. 列表去重：使用 set() 方法可以对列表进行去重，但它会丢失原有顺序。若要保持顺序，我会使用列表推导式来手动去重，避免重复元素。

2. 删除最后一个元素：使用 pop() 方法可以方便地删除列表中的最后一个元素，且该方法会返回删除的元素，默认情况下删除的是列表的最后一个元素。

3. 列表与元组的区别：

• 列表（List）：是可变类型，允许元素的增删改，通常用于数据需要频繁修改的场景，表示方式为 [ ]。

• 元组（Tuple）：是不可变类型，不能修改元素，适用于数据不需要修改的场景，且通常用于需要不可变对象的地方，表示方式为 ( )。

总结来说，列表的优势是灵活性，适合需要修改数据的场景，而元组的优势是更高的性能和不可变性，适合需要保护数据不被修改的场景。

10.postman：如何使用代码实现多个接口之间的测试，如何设置环境变量

具体步骤

1️⃣ 实现多个接口之间的测试

Postman 允许我们在多个接口之间共享数据，通过 环境变量、全局变量 和 测试脚本 来实现接口之间的数据传递，从而进行连贯的测试。

• 测试思路：你可以先发起第一个接口请求，并通过 Tests 脚本获取响应中的数据，然后将这些数据保存到 环境变量 或 全局变量 中，供后续接口请求使用。

• 具体步骤：

  1. 发送接口请求（例如登录接口，获取 token）

  2. 使用 Tests 脚本提取响应数据（如 token），并将其保存到环境变量中

  3. 在下一个接口请求中，直接引用这个环境变量，作为请求的一部分。

例子：

假设你有两个接口，登录接口和获取用户信息接口，登录接口返回一个 token，获取用户信息接口需要用这个 token 来访问。

1. 登录接口的测试脚本：

在 登录接口 的 Tests 部分，编写代码提取 token 并保存为环境变量：

// 获取响应体中的 token 并保存到环境变量 var jsonResponse = JSON.parse(responseBody); pm.environment.set("auth_token", jsonResponse.token);

2. 获取用户信息接口的请求：

在 获取用户信息接口 的请求头部分，使用 {{auth_token}} 来引用上面保存的环境变量：Authorization: Bearer {{auth_token}}

这样，第二个接口会自动使用第一个接口返回的 token 作为请求头的一部分。

2️⃣ 如何设置环境变量

Postman 允许我们使用环境变量来存储不同环境下的配置信息，如开发环境、测试环境和生产环境的 API URL、用户名、密码等。

设置环境变量的步骤：

1. 创建环境：

   • 点击 Postman 左上角的 "Environment" 按钮，选择 "Manage Environments"。

   • 点击 "Add" 创建新环境，例如：Development、Production。

2. 设置变量：

   • 在环境中添加你需要的变量。例如：base_url、auth_token。

   • 你可以通过 {{variable_name}} 语法来引用这些变量。

3. 选择环境：

   • 创建并保存好环境后，选择左上角环境选择框中的环境，如 Development。

   • 你选择的环境变量会在当前的请求中生效。

4. 使用环境变量：

   • 在请求的 URL、参数、头部中使用 {{variable_name}} 来引用环境变量。

环境变量示例：

假设你为不同的环境设置了不同的 API URL，如：

• base_url: https://api.dev.example.com （开发环境）

• base_url: https://api.prod.example.com （生产环境）

然后在请求的 URL 中使用这个变量：{{base_url}}/users

Postman 会根据当前选中的环境来替换 {{base_url}}，例如在开发环境中，{{base_url}} 会被替换为 https://api.dev.example.com。

面试术语

在 Postman 中，可以通过以下几种方法实现多个接口之间的测试：

1. 使用环境变量进行数据传递：通过在第一个接口的 Tests 脚本中提取响应数据，并保存为环境变量，后续接口可以直接引用这些变量。这样就可以在多个接口之间共享数据，实现连续的接口测试。

2. 设置和使用环境变量：

   • 创建环境：在 Postman 中为不同的测试环境（如开发、测试、生产）创建不同的环境，配置环境变量（如 API URL、身份认证信息等）。

   • 使用变量：通过在请求中使用 {{variable_name}} 的语法，引用当前选中环境中的变量。环境变量的值可以在请求执行时动态加载，根据不同环境切换配置。

示例：

1. 在登录接口中提取 token，并保存到环境变量中，供后续接口使用。

2. 在请求头中使用 Authorization: Bearer {{auth_token}} 来传递从登录接口获取的 token。

使用环境变量可以大大简化多环境测试和多接口之间的联动，提升测试效率和可维护性。