1. 我们公司的整个测试流程是怎样的？（以CRMEB开源商城系统为例）

作为实习生，我参与的测试流程主要围绕CRMEB商城系统展开，分为以下几个阶段：

1. 需求理解：

   • 产品经理提供需求文档（如新增“直播带货”功能），我会先阅读文档，对比系统原型图，标记不理解的部分，通过询问同事或查看帮助文档（如CRMEB的B站二开教程）明确测试目标。

2. 测试用例设计：

   • 根据需求拆分测试点，使用等价类划分和场景法设计用例。例如测试“用户积分兑换优惠券”功能：
     • 有效场景：用户积分足够时兑换成功，积分扣除。
     • 无效场景：积分不足时提示“积分不够”，输入非数字字符时拦截提交。
   • 使用Excel编写用例，标注优先级（如核心功能P0，次要功能P1）。

3. 用例评审与修改：

   • 参与团队评审，开发指出“积分兑换并发问题”未覆盖（如多人同时兑换同一张券），补充“高并发场景”测试用例。

4. 执行测试与提Bug：

   • 冒烟测试：先验证核心流程，例如用户能否正常登录、商品加入购物车、下单支付。
   • 详细测试：逐条执行用例，使用Fiddler抓包检查接口返回。例如发现“优惠券叠加使用”时价格计算错误，通过禅道提交Bug（附截图和日志）。
   • 回归测试：开发修复后，重新验证Bug是否解决，并检查关联功能（如修复订单支付后，确认积分是否正常到账）。

5. 上线前验收：

   • 在预发布环境模拟真实用户操作，例如用手机测试H5端下单流程，确保与PC端数据同步。
   • 验证文档中提到的“页面DIY”功能，拖拽组件后页面渲染是否正常。

6. 上线后跟踪：

   • 监控线上日志（如查看ELK平台），协助复现用户反馈的问题。例如用户反馈“拼团成功后未收到通知”，排查后发现短信服务商接口限流，提交给运维处理。

实习生的视角补充：

• 工具使用：用Postman测试接口（如商城API的返回状态码），用Jmeter简单模拟秒杀场景的压力测试（现学现用，同事指导）。
• 学习路径：遇到不熟悉的概念（如“分布式事务”）时，通过CRMEB的官方文档（数据字典、接口文档）和社区提问解决。
• 协作细节：每天站会同步测试进度，遇到阻塞问题（如环境部署失败）及时求助，用钉钉截图向开发说明报错信息。

举例：
在测试“直播带货”功能时，因对直播推流协议不熟悉，主动学习OBS工具，并参考CRMEB的直播模块接口文档，最终设计出“用户进入直播间-抢购商品-订单生成”的全链路测试场景，发现库存扣减时序错误，获得带教同事的认可。

2. 测试用例的设计方法有哪些？

常用的测试用例设计方法包括：

• 等价类划分：将输入数据分为有效类和无效类，减少重复用例。
• 边界值分析：针对输入范围的边界值（如最小值、最大值）设计用例。
• 场景法：基于用户实际使用流程（如登录-下单-支付）设计端到端场景。
• 错误推测法：根据经验推测易出错的场景（如异常操作、网络中断）。
• 因果图法：分析输入条件的组合关系（如药品采购中“库存充足”与“允许下单”的关系）。

3. 这些方法在项目中如何应用？举例说明

① 等价类划分 + 边界值分析
在药品采购系统的“采购数量”功能测试中：

• 等价类：有效类（1-999）、无效类（0、非数字、负数、>999）。
• 边界值：测试0（无效）、1（最小有效值）、999（最大有效值）、1000（无效）。
  发现Bug：输入1000时系统未提示“超出最大采购量”，开发修复后增加了校验逻辑。

② 场景法
在CRMEB商城系统的“优惠券使用”流程中：

• 主流程：用户领取优惠券 → 下单选择优惠券 → 支付成功 → 优惠券状态变“已使用”。
• 异常场景：优惠券过期后下单、重复使用同一张券。
  验证结果：发现过期优惠券仍可勾选，提交Bug后开发优化了券状态判断逻辑。

③ 错误推测法
在4S系统的“客户信息导入”功能中：

• 推测问题点：文件格式错误（如非Excel）、数据重复（如手机号已存在）。
• 测试用例：上传.txt文件、导入重复客户数据，检查系统是否提示明确错误。
  结果：系统未处理.txt文件导致崩溃，开发增加了文件类型校验。

④ 因果图法
在药品采购的“审批通过”条件中：

• 输入条件：库存充足（是/否）、采购单填写完整（是/否）。
• 组合结果：仅当两者均为“是”时允许审批通过。
  用例设计：覆盖4种组合，发现“库存不足但审批通过”的漏洞。

8. 你们调用的接口是内接口还是外接口？

在测试CRMEB开源商城系统时，我们调用的接口既有内部接口（系统内模块间交互），也有外部接口（依赖第三方服务）。以下是我的实际工作场景：

（1）内部接口

定义：系统自身前后端模块间的接口，例如用户登录、商品列表查询、订单生成等。
测试场景举例：

• 案例1：优惠券领取接口

  • 接口功能：用户点击领取优惠券时，前端调用后端接口/api/coupon/receive，校验用户积分、库存后返回结果。
  • 测试重点：
    • 业务逻辑：积分不足时接口返回{"code": 400, "msg": "积分不足"}。
    • 数据一致性：领取成功后，数据库user_coupon表和coupon库存需同步更新。
  • 我的操作：
    使用Postman直接调用接口，覆盖正常和异常场景（如重复领取、库存为0），并检查数据库变化。

• 案例2：购物车商品合并接口

  • 在“拼团功能”中，用户从商品详情页加入拼团购物车时，调用内部接口/api/cart/merge合并普通商品和拼团商品。
  • 发现Bug：拼团商品未校验活动时效，导致过期活动商品仍可加入购物车，提交后开发修复了活动状态判断逻辑。

（2）外部接口

定义：与第三方系统交互的接口，例如支付、短信、物流等。
测试场景举例：

• 案例1：微信支付接口

  • 接口功能：用户下单后调用微信支付接口生成支付二维码。
  • 测试重点：
    • 接口连通性：确保预发布环境与微信沙箱配置正确（如签名、商户号）。
    • 异常处理：模拟支付超时、用户取消支付等场景，检查订单状态是否回滚。
  • 我的操作：
    • 使用公司申请的测试商户号，在Postman中调试支付回调接口。
    • 发现Bug：支付成功后，订单状态未更新为“已支付”，原因是回调地址配置错误，协助开发排查日志后修复。

• 案例2：阿里云短信接口

  • 接口功能：用户注册时发送短信验证码。
  • 测试难点：
    • 频率限制：同一手机号60秒内不可重复发送。
    • 成本控制：测试环境需屏蔽真实短信发送（避免浪费资源）。
  • 我的操作：
    • 在测试环境配置Mock短信服务，直接返回固定验证码（如“123456”）。
    • 使用Jmeter压测接口，发现高并发下短信队列阻塞，反馈后优化了异步处理机制。

（3）实习中的学习与挑战

• 区分内外接口的方法：
  • 通过接口文档（如CRMEB的Swagger文档）判断：/api/internal/前缀多为内部接口，/api/third/或包含wxpay、sms等关键词的为外部接口。
  • 询问开发同事：例如“物流查询”接口是否调用第三方快递100的API。
• 测试策略差异：
  • 内部接口：重点关注业务逻辑覆盖和数据一致性，利用数据库断言。
  • 外部接口：优先保证接口连通性和容错性，通过Mock减少依赖。
• 举例：
  在测试药品采购系统的“药品资质审核”功能时，需调用药监局外部API验证药品批号。
  • 测试时发现药监局接口响应慢（超时10秒），推动开发增加异步审核机制，避免阻塞主流程。

总结：
作为实习生，我主要通过接口文档和团队协作区分内外接口。对内部接口侧重逻辑验证，对外部接口注重稳定性和异常处理，同时利用Mock工具降低测试成本。例如在CRMEB项目中，通过封禁真实短信接口，既完成了功能验证，又避免了测试资源浪费。

10. 测试环境搭建（实习生视角）

作为实习生，我并未直接参与环境搭建，但通过观察和文档学习，了解到公司的测试环境搭建流程大致如下（以CRMEB商城系统为例）：

（1）基础流程（开发/运维主导）

1. 代码获取：

   • 从GitLab拉取CRMEB开源代码的指定分支（如test分支），使用docker-compose一键部署MySQL、Redis等依赖服务。

2. 配置修改：

   • 调整application.yml中的数据库连接、第三方API密钥（如微信支付测试商户号）等参数，指向测试环境资源。

3. 依赖服务Mock：

   • 对部分外部接口（如短信、支付）使用Postman Mock Server或Apifox模拟响应，避免调用真实服务产生成本。

4. 测试数据准备：

   • 通过SQL脚本初始化测试账号（如预设账号test_user）、商品库存、优惠券规则等基础数据。

5. 服务部署与启动：

   • 后端：使用Jenkins构建Java服务并部署到测试服务器（如内网IP192.168.1.100:8080）。
   • 前端：通过Nginx代理静态资源，访问地址如test.crmeb.com。

（2）实习生如何参与？

• 访问已有环境：
  直接使用公司提供的测试环境地址（如域名或IP），通过分配的测试账号（如tester01/123456）执行用例。

• 数据恢复辅助：
  若测试环境数据被污染，协助执行reset_test_data.sql脚本恢复初始状态（运维提供脚本）。

• 日志查看：
  通过Kibana查看测试环境日志，定位前端/后端问题（如搜索error关键词）。

11. 上一家公司简介（海外贸易方向）

上一家公司是一家专注跨境电商B2B/B2C的平台服务商，主要面向欧美、东南亚市场，为中小外贸企业提供商品出海、跨境支付、国际物流等一站式解决方案。

核心业务：

• 自研海外电商平台，支持多语言、多币种交易（如PayPal、Stripe支付集成）。
• 搭建供应链管理系统，对接海外仓、清关服务商（如DHL、FedEx接口）。

我的工作：

• 负责平台订单履约、跨境支付等核心模块的功能测试，主导ERP系统与物流API的自动化脚本开发（Python+Selenium）。
• 优化退税申报模块的测试流程，提升30%用例执行效率，保障欧盟VAT税务合规性校验准确性。

技术栈：微服务架构、AWS云部署，测试侧重高并发下单、汇率转换等跨境场景。

13.分析潜在的需求，举个例子
在测试CRMEB商城系统的拼团功能时，我发现一个潜在需求：当用户发起拼团但未成团时，系统会无限期冻结商品库存。这在实际业务中可能导致热销商品被无效订单长期占用，比如在测试中模拟用户发起10人拼团后，即使24小时未成团，库存仍未释放。这一问题的发现源于两个场景：一是业务部门周会上运营同事提到"每次大促后总有顾客投诉商品显示有货却无法下单"，二是压力测试时观察到大量库存被冻结导致后续真实订单失败。当时我通过日志分析发现，有35%的拼团订单超12小时未成团却仍占用库存，于是在缺陷报告中补充了"建议增加拼团库存释放机制"的观察，并主动调取了历史促销数据佐证。后来产品经理确认这是需求文档中遗漏的规则，最终推动开发增加了"智能释放"功能——根据商品热度动态调整冻结时长（普通商品2小时自动释放，爆款商品30分钟强制释放），这个改进使得后续大促期间的库存周转率提升了18%。

15.说一下你负责模块是如何设计测试用例的

21.写测试点你的思路布局是怎么样的
在实际工作中，我写测试点的思路大概分三步走。举个我在药品采购系统的例子吧：比如当时接到采购订单模块的需求，我首先会拿着需求文档和产品经理对齐流程，把采购发起、审批、库存扣减这些核心功能拆成小模块。 然后按正常流程和异常情况来铺测试点。比如正常下单要考虑不同药品类型能不能选，审批时权限对不对。异常情况比如库存不足时能不能拦截下单，审批人没填会不会弹提示。这些边界值和报错信息都是重点。 最后还会结合业务场景补充细节。像药品效期管理，会测试近效期药品下单时有没有提醒；采购单导出格式和权限控制也是必测项。有时候还会参考之前项目的测试用例，比如4S店系统里客户预约的时间冲突处理逻辑，和药品采购的库存互锁机制有点像，可以借鉴思路。过程中遇到不确定的，比如系统怎么处理同时多人提交采购，我就会直接找开发确认逻辑，避免漏测点。

22.Linux是拿来做什么
主要用在三个地方：

1. 后台服务运行环境：像我们药品系统的JAVA后台接口，就是部署在Linux服务器上的。有次生产环境报500错误，开发就是用Xshell连Linux查的Tomcat日志。

2. 数据库托管：测试环境的MySQL数据库装在CentOS系统，有次数据迁移时看运维同事通过命令行做的备份恢复。

3. 自动化脚本执行：虽然我用的是Windows跑测试用例，但听同事说他们的持续集成工具Jenkins是装在Linux上的，每天自动执行接口测试。

其实CRMEB商城的安装文档里也有涉及（比如Nginx环境配置），虽然当时用宝塔面板简化了操作，但底层还是基于Linux的。作为测试，我觉得掌握基础命令比如查看日志（tail -f）、查进程（ps -aux）这些，对定位环境问题会很有帮助

2.开发和测试相关的项目周期流程？
根据我在4S店系统和药品采购系统测试中的实际经历，整个项目流程大概是这样的：

最开始会参与需求评审会，比如药品系统的采购审批流程改动，产品经理拿着原型图讲业务逻辑，我们测试要确认哪些功能点需要重点覆盖。这时候我会边听边记，把模糊的需求当场问清楚（像上次药品库存预警阈值没写具体数值，后来专门找业务方确认了规则）。

开发阶段我们也没闲着，得写测试用例。用XMind画过药品入库流程的思维导图，把正常采购、库存不足、供应商资质过期这些场景都拆解成具体步骤。等开发提测后，先做冒烟测试——比如4S店的客户预约功能，先跑通主流程确保系统能测下去，不然直接退给开发返工。

正式测试时，像测CRMEB商城的优惠券功能，既要验证领券/核销的正常逻辑，又得检查并发抢券会不会出问题（虽然当时是用JMeter简单压测的）。发现bug就用禅道提交，配上报错日志截图和复现步骤，有次开发说在他本地没问题，结果发现是测试环境Linux服务器时间和数据库没同步导致的。

测试通过后还有验收环节，比如和业务部门一起过药品采购的审批流，他们拿着真实业务数据来操作，我们得跟着记录问题。最后上线前要核对部署清单，记得有次因为漏传了一个配置文件，导致H5页面打不开，后来运维在Linux上重启Nginx才解决。

其实像CRMEB这种开源项目迭代更快，我们当时给商城加直播功能时，基本是两周一个版本。测试得跟着版本节奏走，虽然压力大，但流程更紧凑，开发一边改BUG我们一边回归，还用Git打Tag区分测试版本。现在想想，要是能早点接触自动化测试，可能回归测试效率会更高，这也是我接下来想学的部分。

怎么区分一个bug是前端还是后端？

1. 看接口交互：用浏览器F12抓网络请求（比如药品采购提交失败时），如果前端根本没发请求→前端问题；请求参数正确但接口返回错误→后端问题（比如优惠券接口返回500错误）

2. 换端验证：比如H5页面显示"库存为-1"，用Postman调接口发现库存数据正常→前端没做负数兜底显示；若接口返回就是-1→后端计算逻辑错误

3. 查日志定位：像4S店系统预约时间报错时，前端控制台没报错，但Linux服务器上查到的Tomcat日志里有空指针异常→肯定是后端问题

11.支付场景涉及到的你能考虑到哪些场景？（支付成功，支付争议，
支付退款，支付金额）
结合在CRMEB商城和4S店系统的测试经验，支付场景主要覆盖这些测试点：

1. 支付成功

• 不同支付方式验证（微信/支付宝/余额支付，4S店的线下刷卡支付）
• 支付金额边界值：0元订单（商城优惠券全额抵扣）、大额支付（如药品采购单笔50万限额）
• 支付后订单状态同步（遇到过支付成功但订单卡在"待付款"，查日志发现是MQ消息丢失）

2. 支付争议

• 重复支付（用户点击多次产生两笔支付，需测试系统是否触发自动退款）
• 第三方支付结果不同步（用Fiddler模拟支付宝回调超时，检查系统补单机制）
• 支付渠道异常（如测试微信支付时关闭商户号，验证友好提示和失败日志记录）

3. 支付退款

• 部分退款（商城仅退运费，需核对金额拆分和库存回滚）
• 退款原路返回（用测试商户号验证银行卡/微信零钱的退款到账）
• 超时退款（药品采购合同取消后超过15天协议期限，测试系统阻断退款功能）

4. 支付金额

• 小数点处理（药品采购系统遇过0.5元优惠券抵扣后总价显示-0.0元的前端显示BUG）
• 多币种支付（测试4S店进口车美元结算时，汇率实时更新导致金额四舍五入问题）
• 组合支付（余额+优惠券+微信混合支付，需验证扣款顺序和比例）

特别注意：在CRMEB测试中，用Charles模拟过"支付成功但回调被劫持篡改"，验证系统签名校验机制；还测过Nginx配置错误导致支付页面HTTP被强制跳HTTPS，引发跨协议支付失败的问题。

12.你进入到一个新的项目，你怎么快速熟悉？
结合我在4S店系统和CRMEB商城的经验，如果接手新项目，我会分三步走：
第一步“啃文档”：比如刚接触药品采购系统时，先扒拉需求文档和接口文档，重点看业务流程图（比如采购审批的节点流转），用XMind把核心功能模块的关系图画出来。遇到CRMEB商城这种开源项目，直接看他们Gitee上的Wiki和数据库字典，快速理清优惠券和订单的关联表结构。

第二步“摸系统”：直接上手操作测试环境，比如在4S店系统里走一遍客户预约全流程，用F12抓接口看数据流向，顺带翻服务器日志（像Nginx访问日志和Java应用日志）。如果有现成的自动化测试用例（比如CRMEB的接口自动化脚本），就边跑边看断言逻辑，能快速理解关键校验点。

第三步“问”：拉着产品经理过一遍业务背景（比如药品采购的合规性要求），跟开发聊技术实现（像4S店系统的第三方支付对接方案），再和测试老员工要测试用例库和常见Bug清单。之前在CRMEB项目，就是靠同事给的“优惠券并发测试方案”，省了一半写用例的时间。

实战例子：刚进药品项目时，发现采购单导出Excel总是乱码，通过查文档发现系统默认UTF-8编码，但服务器没装中文字体；又比如在CRMEB商城，通过跑一遍订单退款流程，发现退款状态没同步到前端，其实是后端用了不同的状态枚举值——这些踩坑过程反而是快速熟悉系统的捷径。