注：下面内容一部分来自于我舍友的博客

测开自我介绍

面试官您好，我叫陈温鹏，就读于南京理工大学软件工程专业，学位是学硕，这次应聘的是 测试开发岗位。

我呢，研一的时候积极参加开源社区建设，先参加了Casbin社区一个线上实习，担任社区维护者，日常工作会解决社区 issue，跟踪解决用户需求，修bug以及完善相关文档；然后在研一暑假三个月时间中了一个中科院和 casbin 社区联合举办的一个开源项目，主要的工作是完善社区整个大前端系统，包括 web，移动端功能完善，以及为社区开发了一款支持通用2FA的移动端app。除此之外，我还参与过国家电网经济研究院的一个项目。 这几段项目实习经历锻炼了我文档阅读、编写的能力，并在代码规范、开发流程等技能上获得提升。

其实在开源项目也做过关于测试相关的工作，也激发了我对测试开发的兴趣，所以就应聘了测试开发这个岗位。

然后我呢，我评价觉得自己是一个学习能力很强的人，可以比较快速的学习并适应新的环境和技术栈。 最后感谢 饿了么 给我这次面试机会，我也十分希望能进入 饿了么 ，与公司共同成长进步！

为什么选择测开

之前在社区的一个开发经历让我对软件质量和稳定性产生了兴趣，认为测试开发是保证软件质量的重要环节。我认为测试开发不仅仅是为了找到软件中的bug，更是为了确保软件在各种场景下都能稳定运行，从而提升用户体验。这其实是软件开发中非常重要的一环。

需要与开发人员紧密合作，及时沟通和反馈，确保开发进度和质量。

做过哪些关于测开的工作

之前负责给社区写一个适配器。

Casbin是一个灵活强大的权限访问控制库，PyCasbin 是 Python 版本的，广泛用于管理应用程序中的权限。为了更好地集成数据库操作，PyCasbin 提供了一些适配器，其中包括异步 SQLAlchemy 适配器。这种适配器允许在异步环境中使用 SQLAlchemy 作为持久化层，管理 Casbin 的策略存储。

主要工作：

  • 适配器实现：编写了SQLAlchemy适配器，使得Casbin可以使用SQLAlchemy进行权限管理存储。
  • 测试覆盖：编写了全面的测试用例，覆盖了适配器的所有主要功能，包括政策的添加、删除、更新和过滤。

技术细节

  • 测试框架：使用了unittest库，并扩展了IsolatedAsyncioTestCase来测试异步功能。
  • 测试用例设计：这个适配器需要在异步环境下持久管理 Casbin 策略，所以需要对策略的增删改查、保存、以及策略过滤查找等进行测试。测试用例保证了覆盖基本功能测试。
    • 测试添加一个策略，添加多个策略
    • 测试删除一个策略，删除多个策略，删除经过过滤的策略
    • 测试更新一个策略，测试更新多个策略。

还有就是我在社区中自己做的每个 sdk，其中都使用 Github workflow进行持续集成和部署，然后也可以编写一些这种自动化脚本。

测试类型分类

  • 单元测试(Unit Testing)
    • 定义：对软件中的最小可测试单元进行验证，通常是函数或方法。
    • 目的：确保每个单元独立工作正确。
  • 集成测试(Integration Testing)
    • 定义：在单元测试的基础上，测试多个单元组合在一起后的功能。
    • 目的：确保模块之间的交互正确。
  • 系统测试(System Testing)
    • 定义：在一个完整的系统环境中进行测试。
    • 目的：验证整个系统是否满足需求。
  • 验收测试(Acceptance Testing)
    • 定义：由客户或终端用户进行，确认系统满足业务需求。
    • 目的：确保软件的最终产品符合预期用途。

测试方法分类

  • 黑盒测试：测试者不需要了解内部代码结构，只测试输入和输出。
    • 技术：等价类划分、边界值分析、决策表。
    • 优点：基于功能需求，容易理解和实施。
    • 缺点：无法覆盖内部实现细节。
  • 白盒测试：测试者需要了解内部代码结构，根据代码逻辑进行测试。软件代码改变，测试用例也需要改变。
    • 技术：语句覆盖、分支覆盖、路径覆盖。
    • 优点：可以发现代码中的隐含错误和缺陷。
    • 缺点：需要较高的技术知识，测试维护成本高。
  • 灰盒测试：结合黑盒和白盒测试，测试者了解部分内部结构。
    • 技术：使用部分代码知识进行测试，如数据库图表。
    • 优点：平衡内部和外部测试，能够发现更多缺陷。
    • 缺点：复杂度高，需要更多的时间和资源。

测试用例

描述输入实际值和预期输出行为或者结果的文档，同时也标识了测试过程结果与约束

测试用例的设计方法

测试用例设计方法是软件测试中的关键环节，旨在确保全面覆盖软件的各个功能和可能的缺陷。以下是一些常见的测试用例设计方法：

  1. 等价类划分(Equivalence Partitioning)
    • 定义：将输入域划分为若干等价类，每个等价类中的数据被认为是等价的，选取一个代表进行测试。
    • 目的：减少测试用例数量，同时覆盖所有可能的输入。
    • 应用：输入字段长度、有效值范围。
    • 例子：如果输入年龄在1-100之间有效，可以划分为有效等价类(1-100)和无效等价类(小于1，大于100)。
  2. 边界值分析(Boundary Value Analysis)
    • 定义：关注输入值的边界，选择边界值及其附近的值进行测试。
    • 目的：发现边界值上的缺陷，因为边界往往是错误集中发生的地方。
    • 应用：最大值、最小值、边界值上下的值。
    • 例子：对于输入年龄在1-100之间的情况，测试值可以是0、1、2、99、100、101。
  3. 决策表(Decision Table)
    • 定义：列出所有可能的输入条件及其对应的输出，形成一个表格，用于逻辑分析。
    • 目的：确保所有逻辑路径都得到测试。
    • 应用：复杂的业务逻辑、多条件判断。
    • 例子：银行贷款审批系统，可以根据申请人的收入、信用评分、贷款金额等条件，生成决策表来测试不同组合的结果。
  4. 状态转换图(State Transition Diagram)
    • 定义：根据系统状态和事件，描述状态之间的转换关系。
    • 目的：验证系统在不同状态下的行为，确保状态转换正确。
    • 应用：工作流系统、状态机。
    • 例子：在线购物系统的订单状态，可以从“新订单”到“处理中”，再到“已发货”或“已取消”。
  5. 因果图(Cause-Effect Graphing)
    • 定义：根据输入条件(原因)和系统响应(结果)，绘制因果关系图，生成测试用例。
    • 目的：确保所有可能的输入组合都被测试。
    • 应用：复杂系统的逻辑测试。
    • 例子：电梯控制系统的输入条件如楼层选择、开关门按钮，可以使用因果图设计测试用例。
  6. 场景测试(Scenario Testing)
    • 定义：基于用户的实际使用场景，设计真实的操作流程来进行测试。
    • 目的：确保系统在实际使用中的正确性和用户体验。
    • 应用：用户故事、用例。
    • 例子：在线银行系统中，用户从登录到转账的整个操作流程。
  7. 探索性测试(Exploratory Testing)
    • 定义：没有预先定义的测试用例，测试人员在探索系统过程中，根据发现动态设计和执行测试。
    • 目的：发现意外的缺陷和问题，特别是那些传统测试用例未覆盖的部分。
    • 应用：新功能、快速反馈。
    • 例子：新上线的功能模块，通过不同用户角色和操作路径进行随机测试。
  8. 使用基于模型的测试(Model-Based Testing)
    • 定义：利用系统的模型(如状态机、流程图)来生成测试用例。
    • 目的：自动生成测试用例，确保系统行为符合模型。
    • 应用：复杂系统的行为测试。
    • 例子：ATM机操作流程模型，用于生成取款、查询余额等操作的测试用例。

这些测试用例设计方法可以帮助测试人员全面和系统地覆盖被测试软件的功能和可能的缺陷，从而提高测试效率和测试质量。

测试生命周期

  1. 测试计划(Test Planning)
    • 定义：制定测试策略、范围、资源和时间表。
    • 输出：测试计划文档。
  2. 测试设计(Test Design)
    • 定义：设计测试用例和测试脚本。
    • 输出：测试用例文档、测试脚本。
  3. 测试执行(Test Execution)
    • 定义：执行测试用例，记录测试结果和缺陷。
    • 输出：测试执行记录、缺陷报告。
  4. 测试评估(Test Evaluation)
    • 定义：评估测试结果，确保所有缺陷已修复和验证。
    • 输出：测试报告、缺陷状态报告。
  5. 测试闭合(Test Closure)
    • 定义：结束测试活动，归档测试文档和数据。
    • 输出：测试总结报告、测试文档归档。

如何理解测试开发中的开发

  • 编写测试用例： 测试开发人员编写测试用例来验证软件系统的不同功能。这些测试用例可以是单元测试、集成测试、端到端测试等，覆盖不同层次和方面的功能和行为。
  • 编写自动化测试脚本： 测试开发人员使用编程语言(如Java、Python、JavaScript等)编写自动化测试脚本，用于执行测试用例并检查系统的响应和行为。这些脚本通常使用测试框架(如JUnit、TestNG、Selenium等)来组织和运行测试。
  • 开发测试工具和框架： 测试开发人员开发测试工具和框架，用于简化测试过程、提高测试效率和覆盖率。这些工具和框架可以包括测试数据生成工具、模拟器、Mock对象、测试管理系统等。
  • 维护测试代码： 随着软件系统的演变和变化，测试代码也需要不断更新和维护。测试开发人员负责确保测试代码的可靠性、稳定性和可维护性，以及及时更新测试代码以反映系统的变化。
  • 参与持续集成和持续部署： 测试开发人员参与持续集成和持续部署流程，确保每次代码提交或部署后都运行自动化测试，并及时发现和解决问题。

如何使用测试保证一个模块的质量

为了保证一个模块的质量，需要制定全面的测试策略，覆盖不同类型的测试，从多个方面验证模块的功能、性能、安全性和可靠性。以下是具体步骤和方法：

  1. 需求分析
    • 目标：明确模块的功能、性能和安全需求。
    • 方法：与产品经理、开发人员和相关利益方沟通，阅读需求文档。
  2. 制定测试计划
    • 内容：定义测试范围、测试目标、测试资源、测试环境、测试时间表。
    • 文档：编写测试计划文档，列出测试策略和测试用例。
  3. 测试用例设计
    • 功能测试用例
      • 等价类划分：将输入域划分为若干等价类，选取代表进行测试。
      • 边界值分析：选择输入值的边界和附近值进行测试。
      • 决策表：列出所有可能的输入条件及其对应的输出。
      • 状态转换图：描述系统状态和事件之间的转换关系。
    • 非功能测试用例
      • 性能测试：设计负载测试和压力测试用例，验证模块在不同负载下的响应时间和吞吐量。
      • 安全测试：设计安全漏洞测试用例，如SQL注入、XSS、CSRF等。
      • 兼容性测试：设计跨平台和跨浏览器测试用例，验证模块在不同环境下的表现。
  4. 搭建测试环境
    • 硬件和软件环境：配置与生产环境类似的测试环境。
    • 测试数据：准备多样化的测试数据，覆盖正常、异常和边界情况。
  5. 执行测试用例
    • 手动测试：按照测试用例手动执行测试，记录测试结果。
    • 自动化测试：使用自动化测试工具执行回归测试、性能测试等。
  6. 缺陷报告和跟踪
    • 报告缺陷：使用缺陷跟踪工具(如JIRA)记录发现的缺陷，描述缺陷的复现步骤、严重性和优先级。
    • 跟踪缺陷：与开发团队合作，确保缺陷得到及时修复和验证。
  7. 测试评估和报告
    • 分析测试结果
      • 测试覆盖率：分析测试用例覆盖率，确保关键功能和边界情况得到充分测试。
      • 缺陷分析：分析缺陷分布和严重性，评估模块质量。
    • 编写测试报告
      • 内容：包括测试摘要、测试结果、缺陷统计、测试评估和改进建议。
      • 分享报告：与团队和相关利益方分享测试报告，讨论测试结果和改进措施。
  8. 执行回归测试
    • 目的：在缺陷修复后，重新测试相关功能，确保修复不影响其他部分。
    • 工具：使用自动化测试工具，如Selenium、JUnit、pytest，快速执行回归测试。
  9. 验收测试
    • 定义：根据需求文档和测试计划，定义模块验收标准。
    • 执行：与客户或终端用户一起进行验收测试，确认模块满足业务需求。
  10. 测试闭合
    • 总结测试过程：分析测试的成功和失败，提炼经验教训。
    • 归档测试文档：保存测试计划、测试用例、测试报告、缺陷报告等文档，以备将来参考。

通过上述步骤，全面和系统地进行测试，可以有效保证模块的质量，确保其功能正确、性能优良、安全可靠。

针对优酷视频 从系统层面如何进行测试

对优酷视频(或其他视频播放应用)进行系统层面的测试可以从多个方面入手，包括功能测试、性能测试、兼容性测试、安全测试等。以下是每个测试类型的详细说明：

  • 功能测试
    • 基础功能测试：
      • 播放功能：检查视频的播放、暂停、快进、快退、音量控制、全屏切换等功能是否正常。
      • 搜索功能：测试搜索栏输入关键词后是否能准确返回相关视频。
      • 下载功能：检查视频下载功能，确保下载后的视频可以正常播放。
      • 账户管理：注册、登录、修改密码、找回密码等功能的测试。
    • 高级功能测试：
      • 推荐系统：测试推荐的视频是否符合用户的观看历史和偏好。
      • 字幕和语言选择：检查是否能正常选择和切换字幕及语言。
  • 性能测试
    • 加载时间测试：
      • 启动时间：测试应用从启动到首页加载完成所需的时间。
      • 视频加载时间：测试点击播放视频后视频开始播放所需的时间。
    • 流畅度测试：
      • 播放流畅度：测试视频播放过程中是否有卡顿、缓冲等现象。
      • 响应速度：测试用户操作(如暂停、快进等)后的响应时间。
    • 资源占用测试：
      • CPU和内存使用率：测试播放不同分辨率的视频时CPU和内存的使用情况。
      • 网络带宽占用：测试视频播放过程中网络带宽的占用情况。
  • 兼容性测试
    • 操作系统兼容性：在不同版本的操作系统(如Windows、macOS、iOS、Android)上测试应用的运行情况。
    • 设备兼容性：在不同型号的手机、平板、电脑等设备上测试应用的表现。
    • 浏览器兼容性：优酷视频有网页版，需要在不同浏览器(如Chrome、Firefox、Safari、Edge)上测试。
  • 安全测试
    • 数据传输安全：检查视频播放、账户登录等过程中是否使用了安全的传输协议(如HTTPS)。
    • 隐私保护：确保用户的个人信息(如账号、密码、观看历史等)不会被泄露或滥用。
    • 漏洞扫描：使用自动化工具扫描应用的安全漏洞，并进行人工验证。
  • 自动化测试
    • 脚本编写：编写自动化测试脚本，对上述功能进行自动化测试，减少人工操作的工作量。
    • 持续集成：将自动化测试脚本集成到CI/CD流水线中，确保每次代码变更后都能进行全面的测试。
  • 用户体验测试
    • 界面设计：检查界面的布局、按钮的位置、字体的大小等是否符合用户习惯和视觉美学。
    • 交互体验：测试用户在使用过程中是否能顺畅地完成各项操作，是否有困惑或不便之处。

通过以上多个方面的测试，可以全面保障优酷视频在各个层面的质量和用户体验。

如何测试一个Java项目？

  • 单元测试： 编写单元测试来测试项目中的各个模块、类和方法。使用 JUnit 或 TestNG 等单元测试框架来编写测试用例，并确保覆盖尽可能多的代码路径和边界情况。
  • 集成测试： 编写集成测试来测试项目中不同模块之间的交互。这可以包括测试数据库访问、外部 API 调用、消息队列等。使用 JUnit、Mockito 等工具来模拟外部依赖，并编写集成测试用例。
  • 性能测试： 对项目进行性能测试，评估其在不同负载下的性能表现。使用 JMeter、Gatling 等性能测试工具来模拟大量用户请求，并监控系统的响应时间、吞吐量等指标。
  • 持续集成和持续部署： 将测试集成到持续集成和持续部署流程中，确保每次代码提交或部署后都运行测试，并及时发现和修复问题。

如何判断所写接口功能正常？

  • 功能测试： 确保接口按照预期工作。这包括发送各种有效和无效的输入数据，并验证接口的响应是否符合预期。例如，如果接口是一个登录接口，你可以测试使用正确的用户名和密码进行登录是否成功，以及使用错误的凭据时是否会得到适当的错误消息。
  • 性能测试： 检查接口的性能，包括响应时间、吞吐量等指标。确保接口在负载增加时仍然能够正常工作，并且性能不会严重下降。
  • 安全测试： 确保接口受到适当的安全保护，例如输入验证、防止SQL注入、XSS攻击等。
  • 兼容性测试： 确保接口在不同的浏览器、操作系统和设备上都能正常工作。

怎么构造无用测试用例？

  • 随机数据： 使用随机生成的数据作为输入。这些数据可能不符合业务逻辑或实际情况，从而导致测试用例的无用性。
  • 非法输入： 提供完全不合法的输入数据。例如，如果一个字段要求输入数字，你可以提供字母字符或特殊字符。
  • 重复数据： 重复使用相同的数据进行测试，而不关注不同数据情况下的行为。这样做可能会错过一些潜在的问题。

如何感知线上项目出现问题

日志监控： 实时监控系统的日志以捕获异常情况和错误信息。通过设置适当的日志级别和使用日志聚合工具，可以帮助发现潜在的问题。
性能监控： 监控系统的性能指标，如响应时间、吞吐量、CPU 使用率、内存使用率等。突然的性能下降可能是系统出现问题的迹象。
自动化测试： 编写自动化测试用例，定期运行以确保系统的功能和性能符合预期。自动化测试可以在每次部署后运行，帮助发现新的问题。

小红书购物搜索框设计测试用例

测试用例名称：搜索框输入有效关键词

  • 输入：在搜索框中输入有效的商品关键词，例如“连衣裙”。
  • 操作：点击搜索按钮或按下回车键。
  • 预期结果：搜索结果页面显示与输入关键词相关的商品列表。

测试用例名称：搜索框输入无效关键词

  • 输入：在搜索框中输入无效的商品关键词，例如“@@@”。
  • 操作：点击搜索按钮或按下回车键。
  • 预期结果：搜索结果页面提示“未找到相关商品”。

测试用例名称：搜索框输入空关键词

  • 输入：在搜索框中不输入任何内容。
  • 操作：点击搜索按钮或按下回车键。
  • 预期结果：搜索结果页面显示全部商品列表。

测试用例名称：搜索框联想功能

  • 输入：在搜索框中输入部分关键词，例如“连衣”。
  • 操作：等待几秒钟，观察搜索框下方是否出现联想词。
  • 预期结果：搜索框下方显示与输入关键词相关的联想词列表。

测试用例名称：搜索框输入并选择联想词

  • 输入：在搜索框中输入部分关键词，例如“连衣”。
  • 操作：从联想词列表中选择一个词，例如“连衣裙”。
  • 预期结果：搜索框中显示选择的联想词，并跳转到与该词相关的搜索结果页面。

测试用例名称：搜索框清空功能

  • 输入：在搜索框中输入关键词，例如“连衣裙”。
  • 操作：点击搜索框右侧的清空按钮。
  • 预期结果：搜索框中的文本被清空，搜索框恢复为空状态。

登录设计测试样例

测试用例名称：输入有效的用户名和密码登录

  • 输入：有效的用户名和密码。
  • 操作：在登录页面输入用户名和密码，点击登录按钮。
  • 预期结果：成功登录，跳转到用户的个人资料页面或首页。

测试用例名称：输入无效的用户名和密码登录

  • 输入：无效的用户名和密码。
  • 操作：在登录页面输入错误的用户名和密码，点击登录按钮。
  • 预期结果：登录失败，提示用户名或密码错误的错误信息。

测试用例名称：输入不存在的用户名登录

  • 输入：不存在的用户名和有效密码。
  • 操作：在登录页面输入不存在的用户名和有效密码，点击登录按钮。
  • 预期结果：登录失败，提示用户名不存在的错误信息。

测试用例名称：输入正确的用户名和空密码登录

  • 输入：有效的用户名和空密码。
  • 操作：在登录页面输入正确的用户名和空密码，点击登录按钮。
  • 预期结果：登录失败，提示密码不能为空的错误信息。

测试用例名称：输入空用户名和正确密码登录

  • 输入：空用户名和有效的密码。
  • 操作：在登录页面输入空用户名和正确的密码，点击登录按钮。
  • 预期结果：登录失败，提示用户名不能为空的错误信息。

测试用例名称：输入特殊字符的用户名和密码登录

  • 输入：包含特殊字符的用户名和密码。
  • 操作：在登录页面输入包含特殊字符的用户名和密码，点击登录按钮。
  • 预期结果：登录失败，提示用户名或密码格式不正确的错误信息。

测试用例名称：记住登录状态

  • 输入：有效的用户名和密码。
  • 操作：在登录页面勾选“记住我”选项后登录。
  • 预期结果：成功登录后，关闭浏览器再次打开时，应自动保持登录状态，无需重新输入用户名和密码。

测试用例名称：登录页链接验证

  • 输入：无。
  • 操作：检查登录页面上的链接。
  • 预期结果：登录页面应包含“忘记密码”、“注册账号”等相关链接，确保用户可以方便地进行其他操作。

测试用例名称：跳转到登录页面

  • 输入：未登录状态。
  • 操作：尝试访问需要登录权限的页面。
  • 预期结果：跳转到登录页面，并在登录成功后自动跳回原页面。

测试用例名称：登录界面的响应速度

  • 输入：无。
  • 操作：在不同网络环境下打开登录页面。
  • 预期结果：登录页面应该在合理的时间内加载完成，不应该出现过长的加载时间。

微信发送文件的测试用例

功能测试

  • 正常发送文件
  • 发送支持的文件类型

边界值测试

  • 发送最大允许大小的文件
  • 发送超过最大允许大小的文件

异常情况测试

  • 发送空文件
  • 发送损坏文件
  • 网络中断后重新发送

性能测试

  • 同时发送多个文件
  • 选择一个接近最大允许大小的文件

用户体验测试

  • 发送文件时的用户提示
  • 文件发送记录

安全性测试

  • 发送包含敏感信息的文件
  • 病毒文件检测

跨平台测试

微信发送红包的测试用例

  • 功能测试
    正常发送红包
    发送拼手气红包
    发送定向红包

  • 边界值测试
    发送最低和最高金额的红包
    发送超过最高金额的红包

  • 异常情况测试
    余额不足时发送红包
    网络中断后重新发送
    取消发送红包

  • 安全性测试
    多测领取红包
    红包过期
    未实名验证用户发送红包
    单方删除好友后发送红包

用户体验测试

跨平台测试

性能测试

  • 高频发送红包
  • 大规模红包领取(拼手气红包)

电影订票功能的测试样例

功能测试

  • 检查电影本身的信息和电影院(不同的电影院)、场次(不同的场次)、座位信息(已售出和可售状态)是否显示正确
  • 验证不同支付方式是否可用
  • 验证电子票是否包含必要信息、是否能通过扫描进入影院

边界和异常情况测试

  • 无效的账户或者账户余额不足进行支付
  • 用户选择座位但未完成支付，座位在一定时间后能否自动释放

性能测试

  • 系统负载测试：高并发访问
  • 正常负载和高负载下的响应时间是否正常

兼容性测试

电商满减优惠券测试用例设计

设计电商满减优惠券的测试用例需要考虑各种场景，包括正常情况、边界情况和异常情况。以下是一些详细的测试用例设计：

  • 正常情况

    • 优惠券满减条件满足
      • 用例描述：用户购物车金额为150元，使用满100减20元优惠券。
      • 预期结果：最终支付金额为130元。
    • 优惠券满减条件满足多张
      • 用例描述：用户购物车金额为250元，使用两张满100减20元优惠券。
      • 预期结果：最终支付金额为210元。

  • 边界情况

    • 刚好满足满减条件
      • 用例描述：用户购物车金额为100元，使用满100减20元优惠券。
      • 预期结果：最终支付金额为80元。
    • 差一分钱满足满减条件
      • 用例描述：用户购物车金额为99.99元，使用满100减20元优惠券。
      • 预期结果：不能使用优惠券，最终支付金额为99.99元。
    • 超过满减条件1分钱
      • 用例描述：用户购物车金额为100.01元，使用满100减20元优惠券。
      • 预期结果：最终支付金额为80.01元。

  • 异常情况

    • 优惠券已过期
      • 用例描述：用户尝试使用一张已过期的满100减20元优惠券。
      • 预期结果：提示优惠券无效，不能使用，最终支付金额为原金额。
    • 优惠券不适用商品
      • 用例描述：用户购物车内商品不在优惠券适用范围，购物车金额为150元，使用满100减20元优惠券。
      • 预期结果：提示优惠券不适用，不能使用，最终支付金额为150元。
    • 优惠券已被使用
      • 用例描述：用户尝试使用一张已被使用过的满100减20元优惠券。
      • 预期结果：提示优惠券已被使用，不能再次使用，最终支付金额为原金额。

  • 多重优惠情况

    • 叠加优惠券
      • 用例描述：用户购物车金额为300元，使用一张满200减50元优惠券和一张满100减20元优惠券。
      • 预期结果：先使用满200减50元优惠券，金额变为250元，再使用满100减20元优惠券，最终支付金额为230元。
    • 不同优惠券叠加使用规则
      • 用例描述：用户购物车金额为300元，使用一张满200减50元优惠券和一张全场9折优惠券。
      • 预期结果：先使用满200减50元优惠券，金额变为250元，再使用9折优惠券，最终支付金额为225元。

  • 优惠券优先级情况

    • 有多张优惠券可用
      • 用例描述：用户购物车金额为200元，有满100减20元优惠券和满150减30元优惠券。
      • 预期结果：系统自动选择满150减30元优惠券，最终支付金额为170元。

  • 无法使用优惠券的情况

    • 购物车金额不足
      • 用例描述：用户购物车金额为50元，使用满100减20元优惠券。
      • 预期结果：不能使用优惠券，最终支付金额为50元。
    • 优惠券被取消
      • 用例描述：用户尝试使用被商家取消的优惠券。
      • 预期结果：提示优惠券无效，不能使用，最终支付金额为原金额。

这些测试用例涵盖了常见的优惠券使用场景，可以帮助全面测试电商平台的满减优惠券功能，确保系统能够正确处理各种情况下的优惠券使用。

外卖优惠券测试用例设计

设计外卖平台的满减优惠券测试用例需要考虑各种场景，包括正常情况、边界情况和异常情况。以下是一些详细的测试用例设计：

  • 正常情况

    • 优惠券满减条件满足
      • 用例描述：用户订单金额为60元，使用满50减10元优惠券。
      • 预期结果：最终支付金额为50元。
    • 优惠券满减条件满足多张
      • 用例描述：用户订单金额为120元，使用两张满50减10元优惠券。
      • 预期结果：最终支付金额为100元。

  • 边界情况

    • 刚好满足满减条件
      • 用例描述：用户订单金额为50元，使用满50减10元优惠券。
      • 预期结果：最终支付金额为40元。
    • 差一分钱满足满减条件
      • 用例描述：用户订单金额为49.99元，使用满50减10元优惠券。
      • 预期结果：不能使用优惠券，最终支付金额为49.99元。
    • 超过满减条件1分钱
      • 用例描述：用户订单金额为50.01元，使用满50减10元优惠券。
      • 预期结果：最终支付金额为40.01元。

  • 异常情况

    • 优惠券已过期
      • 用例描述：用户尝试使用一张已过期的满50减10元优惠券。
      • 预期结果：提示优惠券无效，不能使用，最终支付金额为原金额。
    • 优惠券不适用餐厅
      • 用例描述：用户订单来自不适用优惠券的餐厅，订单金额为60元，使用满50减10元优惠券。
      • 预期结果：提示优惠券不适用，不能使用，最终支付金额为60元。
    • 优惠券已被使用
      • 用例描述：用户尝试使用一张已被使用过的满50减10元优惠券。
      • 预期结果：提示优惠券已被使用，不能再次使用，最终支付金额为原金额。

  • 多重优惠情况

    • 叠加优惠券
      • 用例描述：用户订单金额为100元，使用一张满80减20元优惠券和一张满50减10元优惠券。
      • 预期结果：先使用满80减20元优惠券，金额变为80元，再使用满50减10元优惠券，最终支付金额为70元。
    • 不同优惠券叠加使用规则
      • 用例描述：用户订单金额为100元，使用一张满80减20元优惠券和一张全场9折优惠券。
      • 预期结果：先使用满80减20元优惠券，金额变为80元，再使用9折优惠券，最终支付金额为72元。

  • 优惠券优先级情况

    • 有多张优惠券可用
      • 用例描述：用户订单金额为100元，有满50减10元优惠券和满80减20元优惠券。
      • 预期结果：系统自动选择满80减20元优惠券，最终支付金额为80元。

  • 无法使用优惠券的情况

    • 订单金额不足
      • 用例描述：用户订单金额为30元，使用满50减10元优惠券。
      • 预期结果：不能使用优惠券，最终支付金额为30元。
    • 优惠券被取消
      • 用例描述：用户尝试使用被商家取消的优惠券。
      • 预期结果：提示优惠券无效，不能使用，最终支付金额为原金额。

  • 特殊情况

    • 优惠券部分使用
      • 用例描述：用户订单金额为55元，使用满50减10元优惠券，同时使用余额支付(5元)。
      • 预期结果：订单金额55元，使用优惠券后支付45元，再用余额支付5元，最终支付金额为40元。

这些测试用例涵盖了常见的优惠券使用场景，可以帮助全面测试外卖平台的满减优惠券功能，确保系统能够正确处理各种情况下的优惠券使用。

Github Workflow自动化测试

GitHub Workflow 是指 GitHub Actions 的一种自动化流程管理功能。它可以用于多种用途，包括但不限于测试。具体来说，GitHub Workflow 可以用来：

  1. 持续集成(CI)： 自动运行测试用例，以确保代码在合并之前是正常工作的。这是最常见的用例之一。
  2. 持续部署(CD)： 自动将代码部署到生产环境或其他目标环境。
  3. 代码分析和质量检查： 运行静态代码分析工具，以检查代码质量和一致性。
  4. 构建和发布： 自动构建应用程序并发布构建产物，比如发布到包管理工具(如npm、PyPI)或者生成文档。
  5. 自动化任务： 自动执行脚本或命令，如自动关闭已解决的GitHub Issues、定时执行任务等。

在 GitHub Actions 中，workflow 文件是通过 .yml 或 .yaml 文件定义的，通常放在 .github/workflows/ 目录下。每个 workflow 文件定义了一个或多个 jobs，这些 jobs 可以并行或串行地执行。

示例：

以下是一个简单的 GitHub Workflow 文件示例，用于在每次推送时运行测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '14'

    - name: Install dependencies
      run: npm install

    - name: Run tests
      run: npm test

支付宝/微信转账功能测试用例

在设计支付宝转账功能的测试用例时，应该覆盖各种正常情况、边界情况和异常情况，以确保转账功能的健壮性和可靠性。以下是详细的测试用例设计：

  • 正常情况

    • 成功转账
      • 用例描述：用户A向用户B成功转账100元。
      • 前置条件：用户A账户余额大于等于100元，用户B账户有效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额100元。
        4. 输入用户B的账户信息。
        5. 确认转账。
      • 预期结果：转账成功，用户A账户余额减少100元，用户B账户余额增加100元。
    • 转账金额包含小数
      • 用例描述：用户A向用户B转账50.75元。
      • 前置条件：用户A账户余额大于等于50.75元，用户B账户有效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额50.75元。
        4. 输入用户B的账户信息。
        5. 确认转账。
      • 预期结果：转账成功，用户A账户余额减少50.75元，用户B账户余额增加50.75元。

  • 边界情况

    • 转账金额为0
      • 用例描述：用户A向用户B转账0元。
      • 前置条件：用户A账户有效，用户B账户有效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额0元。
        4. 输入用户B的账户信息。
        5. 尝试确认转账。
      • 预期结果：系统提示转账金额无效，转账失败。
    • 转账金额为账户余额
      • 用例描述：用户A向用户B转账用户A的全部余额。
      • 前置条件：用户A账户余额为200元，用户B账户有效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额200元。
        4. 输入用户B的账户信息。
        5. 确认转账。
      • 预期结果：转账成功，用户A账户余额减少200元，用户B账户余额增加200元。

  • 异常情况

    • 转账金额超过账户余额
      • 用例描述：用户A尝试向用户B转账300元，而用户A账户余额只有100元。
      • 前置条件：用户A账户余额100元，用户B账户有效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额300元。
        4. 输入用户B的账户信息。
        5. 尝试确认转账。
      • 预期结果：系统提示余额不足，转账失败。
    • 用户B账户无效
      • 用例描述：用户A尝试向一个无效的用户B账户转账100元。
      • 前置条件：用户A账户余额大于等于100元，用户B账户无效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额100元。
        4. 输入无效的用户B的账户信息。
        5. 尝试确认转账。
      • 预期结果：系统提示用户B账户无效，转账失败。
    • 网络连接中断
      • 用例描述：用户A在转账过程中网络连接中断。
      • 前置条件：用户A账户有效，用户B账户有效，网络连接不稳定。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额100元。
        4. 输入用户B的账户信息。
        5. 确认转账时网络中断。
      • 预期结果：系统提示网络连接问题，转账未完成。

  • 安全测试

    • 防止重复提交
      • 用例描述：用户A在确认转账后多次点击确认按钮。
      • 前置条件：用户A账户有效，用户B账户有效，转账金额为100元。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额100元。
        4. 输入用户B的账户信息。
        5. 多次点击确认转账按钮。
      • 预期结果：系统只执行一次转账操作，用户A账户减少100元，用户B账户增加100元。
    • 转账金额非法字符
      • 用例描述：用户A尝试输入非法字符作为转账金额。
      • 前置条件：用户A账户有效，用户B账户有效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入非法字符(如”abc”)作为转账金额。
        4. 输入用户B的账户信息。
        5. 尝试确认转账。
      • 预期结果：系统提示金额无效，转账失败。

  • 其他情况

    • 跨境转账
      • 用例描述：用户A向国外的用户B转账100美元。
      • 前置条件：用户A账户有效且支持跨境转账，用户B账户有效，用户A有足够的美元余额。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择跨境转账功能。
        3. 输入转账金额100美元。
        4. 输入用户B的账户信息。
        5. 确认转账。
      • 预期结果：转账成功，用户A美元余额减少100美元，用户B账户美元余额增加100美元。
    • 转账备注
      • 用例描述：用户A向用户B转账100元，并添加备注信息。
      • 前置条件：用户A账户有效，用户B账户有效。
      • 操作步骤：
        1. 用户A登录支付宝账户。
        2. 用户A选择转账功能。
        3. 输入转账金额100元。
        4. 输入用户B的账户信息。
        5. 添加转账备注信息(如“生日礼物”)。
        6. 确认转账。
      • 预期结果：转账成功，备注信息正确保存，用户A账户减少100元，用户B账户增加100元。

这些测试用例覆盖了支付宝转账功能的主要场景，可以帮助全面测试转账功能，确保系统能够正确处理各种情况下的转账操作。

在这个示例中，workflow 文件名为 ci.yml，它定义了一个名为 build 的 job，该 job 在 ubuntu-latest 的环境上运行。整个过程包括以下步骤：

  1. Checkout code：检出代码仓库。
  2. Set up Node.js：设置 Node.js 环境。
  3. Install dependencies：安装依赖。
  4. Run tests：运行测试。

所以，GitHub Workflow 可以用于测试，但它的应用范围远不止于此。

测试工具

  • JUnit：JUnit是Java中最流行的单元测试框架之一，用于编写和运行单元测试。它提供了一组注解和断言方法，使得编写测试用例变得简单易懂。
  • TestNG：TestNG是另一个流行的Java测试框架，提供了比JUnit更丰富的功能，例如参数化测试、测试组、依赖测试等。它也可以用于编写单元测试和集成测试。
  • Selenium：Selenium是用于自动化Web应用程序测试的工具，它支持多种浏览器，并提供了Java API，使得测试脚本的编写和执行变得简单。Selenium可以用于执行功能测试、回归测试等。
  • JMeter：JMeter是一个用于性能测试的工具，它可以模拟大量用户并测量应用程序的性能和稳定性。JMeter也可以用于功能测试和接口测试。