测试基础测试流程需求分析-需求评审-需求确定-开发编写设计文档-概要设计和详细设计-编写代码并自测-提交测试需求分析-需求评审-需求确定-编写测试计划-编写测试用例-用例评审-部署环境-执行测试-提交bug并跟踪bug-开发修改-回归测试-测试通过-发布上线测试流程的时间分配测试计划 1天 需求分析 2天 用例编写3天 用例评审0.5天 搭建环境和冒烟测试0.5天 测试执行4天 回归测试0.5天 测试报告0.5天 12天测试用例的方法等价类是指某个输入域的子集合，在该子集合中抽取最具代表性的来进行测试，摄入项的内容为无穷的时使用。等价类包含有效等价类和无效等价类。边界值分析法是对等价类的补充，一般选择等价类的边缘，大于等于或者是小于的值作为测试数据。场景法：通过描述业务流程，或者是代码的实现逻辑来设计用例，验证软件系统的功能是否正确，有正常流和异常流。错误推断法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。因果图方法。判定表，正交表。用例设计的完整过程查阅需求规格说明书，初步熟悉被测试软件的核心业务流程，去拆解功能点，再对某个功能细化需求，列出测试点，编写测试用例，然后进行用例评审，检查是否漏测或者错测等情况，评审通过后，搭建测试环境，正式执行用例，提交bug并跟踪，开发修改，然后进行回归测试，测试通过后，发布上线。回归测试是否全部都做看时间是否充足，如果比较充足，会全部回归测试，因为操作过的原因，再次执行用例的速度会较快一些。如果时间不充足，会挑选重要的模块功能来进行回归测试。测试的种类按照是否运行代码可分为静态测试和动态测试；按照是否查看源代码分为白盒测试和黑盒测试和灰盒测试按照阶段分为单元测试，集成测试，系统测试，验收测试按照测试内容分为功能测试，接口测试，性能测试，易用性测试，兼容性测试其他的有回归测试，冒烟测试，以及探索性测试bug管理工具禅道优点有：禅道他是开源免费的，从下载到使用都是不需要任何费用的。另外禅道的功能非常多，扩展性也不错，且有官方的技术服务保障。缺点是界面设计不够简洁，颜色使用也比较单一，不够丰富。而且禅道虽然有新手入门操作演示，但是对于新手还是会存在一些问题。工作中如何提交bug，一条bug包含哪些内容首先确认问题可复现，多次操作去排除操作实务、环境故障的问题；然后规范填写，写清模块、完整环境、复现步骤、实际结果和预期结果，配上截图、日志或录屏；最后标注严重级别和优先级，同时提前检索避免重复提交Bug。bug包含标题、所属模块、运行环境、前置条件、复现步骤、实际结果、预期结果、严重程度、优先级、附件（截图 / 日志 / 录屏）、提交人、状态等。Bug 的严重等级和优先级怎么划分？严重等级（影响业务 / 功能程度）：致命：系统崩溃、数据丢失、核心功能完全不可用、支付异常等，会造成重大损失；严重：主要功能流程阻断，无法正常使用，但系统不会崩溃；一般：功能可用，存在 UI 错乱、文案错误、次要功能异常；轻微：体验类问题、优化建议，不影响正常使用。优先级（修复紧急程度）：高：立即修复，阻断测试 / 线上使用的问题；中：当前版本修复，不影响主流程；低：可延后版本迭代修复。你工作中遇到过哪些常见的 Bug 类型？功能类：按钮点击无响应、重复提交、数据回显错误、流程卡死、状态不同步；接口网络类：404/403/500 接口报错、弱网无友好提示、传参异常；UI 界面类：样式错位、适配问题、错别字、图片裂图、弹窗异常；边界值问题：空数据、超长文本、负数 / 极值、时间计算错误；兼容性问题：不同浏览器、手机机型、系统版本展示 / 功能异常；权限类：越权访问、登录态失效；还有一类偶现 Bug，多和缓存、异步、并发、时序问题相关。遇到不能复现 / 偶现 Bug，你怎么处理？首先完整保留报错现场与日志，再重点排查网络、异步竞态、并发、脏数据等常见原因，通过反复模拟场景、加日志来尝试复现。线上先做容错兜底止损，找到问题后彻底修复，并增加线上监控。测试时发现 Bug，开发认为这不是 Bug，你怎么沟通？先冷静沟通，先查看需求文档、原型、交互规则，确认双方对功能预期理解是否一致；拿出证据：截图、操作录屏、日志，一步步演示复现过程，讲明当前现象和需求不符的点；分情况处理：理解偏差：重新对齐需求，达成统一认知；属于设计疏漏 / 逻辑不合理：同步产品经理评估，由产品判定是否优化；确实是缺陷：坚持观点，交由产品 / 组长仲裁；全程客观对事不对人，只围绕需求、现象、用户体验讨论。同一个 Bug，多个版本都存在，你怎么处理？先确认根本原因，判断是代码共用、版本合并遗漏还是修复未全量同步；提单时注明受影响的所有版本，同步给开发和版本负责人；要求开发在所有对应版本统一修复；回归时逐个版本验证，确保全部修复，避免问题遗留。为什么会出现偶现 Bug？常见原因有哪些？偶现 Bug 大多不是功能代码显性错误，常见诱因：时序 / 异步问题：多个接口异步请求，返回顺序不固定，导致逻辑异常；并发竞争：多用户同时操作、高频点击，引发数据竞争、重复请求；缓存问题：本地缓存、服务端缓存新旧数据混杂；弱网 / 网络波动：请求中断、超时、丢包，无异常处理；特殊边界数据：只有特定脏数据、历史数据才会触发；资源抢占、系统性能、定时任务交叉影响。如何减少偶现 Bug？测试侧：增加压力测试、并发测试、弱网测试，覆盖非常规操作场景；高频重复操作模拟用户随机行为；开发侧：完善异步逻辑、加接口防重、超时重试、异常捕获、日志埋点；做好缓存策略；流程侧：规范版本合并、充分做版本回归，避免修复遗漏。回归测试时，Bug 修复了又重新出现（回归漏测 / 重复出现），怎么处理？重新提单，标注回归复现，关联原 Bug 单号；和开发确认：是修复不彻底、版本合并错误，还是引入了新代码导致问题复发；扩大测试范围，检查周边功能是否受影响；优化用例，补充该场景的测试点，后续重点覆盖。网络http和https的区别首页在安全性上http是明文传输，无加解密。而https是http协议的安全加强版，通过在http上建立加密层，对传输数据进行加密。http的端口是80，https是443。http无需证书，https是需要CA数字证书，验证网址真实身份。http工作在应用层，https工作在传输层。Cookie 和 Session的区别存储位置不同，Cookie是在客户端（浏览器）而Session是在服务端。数据大小也有限制，Cookie 有 4KB 限制，Session：无严格大小限制，取决于服务器内存 / 磁盘。安全性上Cookie存在客户端，易被篡改、窃取，安全性低，Session数据在服务端，相对安全。生命周期Cookie 可长期保存，Session 一般会话结束即失效。Cookie 默认不支持跨域，需单独配置。Session 依赖 Cookie，Cookie 跨域受限则 Session 也受影响如果浏览器禁用 Cookie，Session 还能用吗？默认不能用。因为 Session 靠 Cookie 传 SessionID。解决方案：URL 重写，把 SessionID 拼接在请求地址后面传递。为什么不用 Session 完全替代 Cookie？Session 占用服务器资源，用户多会造成服务器压力大客户端每次请求都要交互服务端，性能不如本地 Cookie分布式 / 集群环境下 Session 共享复杂，Cookie 更易实现Cookie 分类会话 Cookie：关闭浏览器立即删除持久 Cookie：设置expires/max-age，存本地，到期才删除get和post请求的区别传参位置GET的参数会显示在URL地址栏上，而POST的参数是放在请求体里。数据大小GET：受 URL 长度限制，最多只能有1024字节，传参小，而POST无明确限制，可传大数据、文件。安全性上GET参数明文可见，不安全，而POST请求体隐藏，相对安全。GET 幂等，对多次请求结果一致，而POST一般不幂等编码上GET 只支持 ASCII；POST 支持多种编码。B/S、C/S 区别部署使用C/S：必须装客户端，更新麻烦；B/S：打开浏览器即用，升级维护只改服务端。兼容性C/S：适配对应系统，跨平台差；B/S：依托浏览器，跨平台强。性能体验C/S：本地处理多，交互流畅、功能强；B/S：依赖网络，复杂操作体验偏弱。安全C/S：客户端可做多层校验，安全性更高；B/S：面向公网，易受网络攻击，安全防护要求高。维护成本C/S：全员客户端都要维护，成本高；B/S：仅维护服务器，成本低。