身份证输入框测试用例设计
发表于|更新于|测开
|总字数:114|阅读时长:1分钟|浏览量:
总结
身份证输入框测试需覆盖格式校验、业务规划（年龄/性别/地址）、兼容性、安全性、用户体验五大维度，设计正向与反向用例合法性识别、错误提示及容错处理。
详细测试用例设计
格式校验（核心:18位编码规则）
业务规则验证（解析编码含义）
交互与兼容性
安全性与容错
特殊场景
文章作者: JasmineRain
版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 JasmineRain's blog！
相关推荐
2025-11-17
Dummy对象
定义Dummy 对象（哑对象）是软件测试和单元测试中经常出现的概念，它属于 Test Double（测试替身） 的一种。 Dummy 对象是一种“什么都不做，只为了占位置”的对象。 它不会被真正使用、也不参与逻辑，只是为了满足参数要求，让程序能够正常运行。 它就像“哑巴”，不会说话、不做事、不参与逻辑，仅仅存在。 核心特征：只占位，不使用。 使用场景 函数或类需要某个参数，但测试时根本不需要用到这个参数 例如： 123func Register(user User,logger Logger){ //测试时只关注user 而不是logger} 测试时logger可以用Dummy，对象只为了占位置 避免因为依赖导致无法进行单元测试 例如依赖数据库、网络、日志系统… 但你测试的函数根本不需要它 → 用 Dummy 代替。
2025-11-17
Fake
定义Fake（伪对象） 在软件测试、尤其是单元测试和测试开发中，是一种常见的 Test Double（测试替身）。 Fake 是一种 “带有简化实现的替代对象”，它能部分模拟真实对象的行为，但不完全等价。 它通常 有实际逻辑、能跑起来，但只是 简化版 / 非生产级。 假设业务真正使用：MySQL 数据库、Redis 缓存、文件存储系统 这些在单元测试中启动非常慢，也很重。 于是你可以构造 Fake：FakeDB（伪数据库）：用 内存 map 存储数据，不用启动真正的 MySQL；提供 find/add/update 接口；测试环境可运行、速度快。FakeCache（伪缓存）：用 map 代替 Redis；实现 get/set 逻辑 它们可以运行，但不能用于生产，只适合测试。 样例1234567891011121314151617181920212223242526272829303132type User struct { ID int Name string}type UserRepo interfac...
2025-11-17
Stub
定义Stub（桩）是 Test Double（测试替身）的重要类型。 Stub（桩）是用于替代真实依赖，但会返回“固定的、预设的”结果的对象。 Stub 是一种测试替身，用来替代真实依赖，返回预设的、固定的数据，使单元测试可控、快速、可靠。 用途 控制依赖的返回结果：数据库查询、三方 API 返回、RPC 结果…… 模拟各种测试场景:查询成功、查询失败、超时、无数据….. 让单元测试更快、更稳定、更可控:不用访问真实网络 / 数据库，执行速度飞快。 示例假设有如下函数 1234567func GetUserNameByID(repo UserRepository,id int)string{ user,err:=repo.FindByID(id) if err!=nil{ return "unknown" } return user.Name} 可以自由控制返回的数据，Stub实现为： 1234567891011type StubUserRepository struc...
2025-11-17
常用测试工具总结
单元测试(Unit Test)工具JUnit最主流的Java单元测试框架 TestNG类似于JUnit，但功能更强(分组、依赖) Google Test(gtest)C++最常用的单元测试框架 pytest最强python测试框架 Mocha/Jest前端单元测试最常用工具 Go testing pkgGo自带的单元测试框架 接口/API测试工具PostmanAPI调试/测试，最常用，请求构造、环境变量、脚本测试 JMeter可做接口测试+压力测试，企业常用 SoapUI支持SOAP/REST API，适合老项目 Insomnia类似于Postman，界面更精简 HoppscotchWeb工具，在线API测试，轻量化 自动化测试(UI测试)工具SeleniumWeb，最经典Web UI自动化框架 PlaywrightWeb，新一代自动化测试，更快、更稳定 CypressWeb，前端使用，简单、直观 Appium移动端，Android/IOS自动化测试框架 Robot Framework通用，基于关键字的自动化测试框架 性能测试&#...
2025-11-18
测试驱动开发
定义测试驱动开发（TDD，Test-Driven Development） 是一种先写测试、后写代码的敏捷开发方法，通过“红 → 绿 → 重构”三步循环来驱动功能实现，使代码质量更高、设计更清晰、Bug 更少。 TDD 是先写失败的测试，再写最少量代码让测试通过，最后重构代码，在保证测试仍然通过的前提下持续优化设计的开发方式。 TDD核心循环:Red->Green->Refactor Red(写测试，测试失败)：编写一个针对某个功能的单元测试，因为功能未实现，测试必然失败(Red) Green(让测试通过)：编写实现代码，不追求完美，只写最少代码让测试通过 Refactor(重构)：优化代码结构、命名、抽象，确保测试仍全部通过，不改变对外行为 优势与价值 减少 Bug：因为先写测试，功能未覆盖的场景立即暴露 保证可维护性：持续的自动化测试确保重构安全 让设计更清晰：写测试时你必须明确需求和 API 降低回归成本：所有测试自动运行 避免过度设计：你只写让测试通过所需最少代码 适用于中大型后端项目、复杂逻辑、核心业务模块。
2025-11-18
负载测试
定义负载测试是在逐步增加并发量和请求量的情况下，验证系统在接近设计容量范围内的性能表现，确定系统能承受多大的稳定负载而不出现性能下降。 负载测试（Load Test）是一种性能测试，用来评估系统在正常和接近高负载情况下是否仍能保持：正确性、稳定性、性能指标达标（响应时间、QPS、吞吐量等），它模拟大量用户同时访问系统，通过持续施压来观察系统极限。 目标 验证系统承载能力是否达到设计值（如承诺 10k QPS 是否能达到） 找出性能瓶颈（数据库、缓存、CPU、锁竞争等） 确保系统在高负载下仍能稳定运行 为扩容、容量规划提供依据 发现隐藏问题（慢查询、内存泄漏、线程池耗尽） 常见负载测试指标 指标 含义 QPS 每秒请求数 TPS 每秒事务数 响应时间(P50,P90,P95,P99) 延迟表现 吞吐量 系统每秒处理的数据量 CPU、内存、I/O、网络使用率 监控资源瓶颈 错误率 请求失败占比 饱和度(Saturation) 系统举例极限有多近 通用流程 明确性能目标：例如：QPS ≥ 5000、P99 响应时间 ≤ 50ms、错误率...
评论
公告
Welcome to my Blog