1. 信贷项目的介绍、信贷项目将背景、业务流程？

我们最近的一个项目，是华兴银行推出的一款兴 e 贷产品，纯信用、无抵押无担保，全流程线上操作，用户可通过本行 APP 进行申请贷款和还款操作，涉及的模块有贷前申请、贷中审批、放款 、贷后还款 催收 结项，工作过程中我全流程都有了解过，主要负责贷前申请还有贷后还款模块。

信贷流程：

那他的一个流程是这样的，首先用户进入 APP，点击贷款那个商品，然后会进入一个贷款的一个详情页，在这块可以看到贷款的一个基本条件、贷款的最高额度、贷款的利率、贷款的周期等等。

然后用户点击申请贷款的话，必须是登录状态下才可以申请。

未登录的话，系统会跳转到登录的一个界面，在这里用户可以进行登录或者注册。

用户登录成功之后呢，系统会先判断用户有没有实名，如果没实名的话，我们会去跳转到实名认证的一个页面，需要客户上传身份证正反面照片，然后进行人脸识别操作。

这里的话我们需要对接第三方公安系统来核对用户信息的一个真实性，如果核对无误的话，我们会看一下用户是不是黑名单，我们有两种方法去判断，如果是本行的客户，那我们会通过 CRM 客户关系系统去查询，如果他是本行的新用户，那么我们会通过人行征信平台去查看用户的黑名单情况，如果用户是黑名单话，那他就申请不了这笔贷款，如果不是黑名单，还需要去判断用户有没有预授信额度，如果他是有额度的话，那他是可以直接进行贷款申请，如果没有额度的话，就需要填写他的个人的一个基本信息。他的工作信息，还包括他的一些资产情况，联系方式等等，然后我们的风控系统会去根据用户的一个信用评分，还有他的它的一个财务状况，它的还款能力，还有它跟银行的客户关系，综合的给到它一个额度，然后用户就可以根据这个额度去申请贷款，然后到贷款申请页用户可以填写他想要贷款的具体金额，还有期数，然后还有它的一个还款的方式，是等额本息还是等额本金（等额本金和等额本息的核心区别就是等额本金的话，它每个月还的本金是固定的，然后那个它的这个月供（本金 + 利息）是逐月减少的，等额本息的话就是每个月的本金加利息（月供）是固定不变的，然后往后逐月这个本金递增、利息递减。然后具体一个计算的话，当时是有一个 Excel 的一个公式），还有它的一个收款账户，如果它没有绑定银行卡的话，系统会提示用户去走一个绑定银行卡的一个流程，这是那个贷前申请阶段。然后贷中是审核和放款，这个阶段信贷后台系统会对客户的这个申请，包括他的资质，他的一个信息，去做一个审核，这里涉及到初审、复审、终审。初审的话，先去是审核用户提交的一些基本信息，财务情况，包括他的一个资产证明，或者他之前上传的一个房产证明、车辆证明之类的，那么复审的话，就会去复核初审的一些信息，还会去确认用户的他的额度和利率。然后终审的话会决定用户他是否能够通过这次的一个贷款申请，申请通过的话，会通过短信或者push 消息方式通知到用户。然后合同管理系统也会生成合同，需要用户去签署、然后上传，那么银行审核无误的话，就按照合同规定的放款日期等待放款，放款前银行这边会对用户的一个贷款信息进行核算。包括他后续的一个还款金额、还款计划和账单之类，

接下来是贷后还款，就是到了还款日，用户可以选择按照当前的还款计划进行还款。

另外一种是提前还款，分为提前还全部和提前还部分。

提前还全部的话，用户还款之后，这笔贷款就是会显示已结清，然后会进行结项处理。

如果是提前部分还款，然后用户还款成功之后，系统会去更新、核算他的新的一个还款计划（申请金额变更、还款方式变更、卡号变更、利率变更（变更LRP（浮动）+百分点）），大致有两种还款方式，一种是月供减少，期数不变，另外一种是月供不变、期数减少。然后会根据他的一个还款方式去更新他的新的一个贷款和账单。然后用户去按照新的这个还款计划去还款，还有提前还款的话，会涉及到一个违约金的一个收取，就可能会将用户提前还款的金额的1%作为一个违约金，向。然后到最后一期还款成功话，那么也会去做一个贷款的结项处理，并且更新用户的信用情况。然后用户可能会出现逾期还款的情况，逾期还款的话是会有三天的宽限期的（M0 阶段（逾期 1-30 天）：自动触发短信、APP 推送、语音提醒，强调提醒而非施压。 M1-M2 阶段（逾期 30-60 天）：人工电话催收，结合客户还款意愿调整策略（如分期、减免利息）。 M3+阶段（逾期 90 天以上）：高风险案件转入法务流程或委外催收，甚至抵押物处置。），三天后开始计算用户的一个罚息，罚息的话是按日计息。那罚息的利率是在用户贷款利率的基础上浮50%，那么用户逾期之后，银行这边会及时通过催收系统去提醒，通过短信或者电话等方式提醒到用户尽快的及时还款，那么如果用户能够把钱还上，用户的信用也是会更新恢复，那么如果说，用户还是还不上的话，可能会进入预警名单，那么如果他的贷款逾期超过90天的话，银行会去做一个贷后核销的操作，就是他的一个正常的贷款就会变为非应计贷款。那么它的逾期贷款的状态就会转为呆滞状态。那么如果后续银行审核之后认为他这边的是无力偿还的话，就是银行这笔钱收不上来了，可能会将这个贷款的状态改为呆账状态，做一个贷后核销的一个操作，基本上贷款的一个前后流程是这样的一个情况。

贷后核销

针对催收环节，它会涉及到一个逾期90天的一个贷后核销操作，它逾期了90天，会从应计贷款变为非应计贷款。

正常的一个贷款金额它会产生一个应收应计利息，这笔正常的贷款金额它发生逾期之后，会变成逾期的一个本金，逾期之后银行催收系统就会进行一个催收处理，在催收的过程中会产生催收的应计利息和催收罚息两种费用。

他的逾期的本金还没有到核销处理的时候，会产生一个应收应计罚息，它是计入贷款的一个应收账款中的。

当用户去结清这笔款之后，他应收应计罚息会变为一个应收罚息。

如果他的那个逾期的本金超过了逾期90天，逾期了90天了，他会变成一个呆滞本金，，银行工作人员就会去进行一个核销处理，在核销过程中就会把应收罚息记录到应收账款之中，它的记录方式就是说把应收罚息通过一定的会计准则把它变为一个应收应计罚息，这个过程就是一个就是应收应计复息。

如果呆滞的本金经过银行的一个催收之后，确认这个款大概率催不回来了，确认是一个坏账。

就会通过手工转移的方式把呆滞本金状态变为一个呆账的本金。

1. 信贷项目的测试计划安排，需求分析、案例设计、测试执行（时间安排、轮次安排），出现问题怎么解决的？

前期开发阶段只用了半年，第一版就完成开发并上线了；上线后就是持续的更新、迭代，完善各类功能。

迭代频率的话，整个项目下来大概迭代了 3 到 4 期。具体节奏是这样的，项目初期是两个月迭代一期；后来调整为一个月一期。如果遇到规模较大的需求，会先把它拆分成多个小任务来推进

因为上线时间是固定的，必须在规定时间内完成，不能出现开发延期的情况。比如以前遇到大需求时，两个月的周期刚好能做完，就直接按完整需求推进；后来迭代周期缩短到一个月，再遇到大需求就先优先完成核心功能上线，那些细枝末节的功能会放到后续的迭代任务里再逐步跟进完善。

1. 测试环境安排（每个环境都涉及哪些类型的测试，具体测试哪些东西，测试耗时多久）？

SIT 阶段和 UAT 阶段的话，

首先第一点的话它们是在测试环境上有区别。

SIT 阶段的话是系统测试，它是在测试环境当中测试，UAT 阶段的话是用户验收测试，需要在预发布环境进行测试。

第二点的话是它们的一个数据不同。

SIT 阶段是我们自己模拟的制造的假数据，UAT 阶段的数据（预发布环境用的是和生产环境同一个数据库，虽然测试数据和真实用户数据是隔开的，但最好不要去随意创建测试数据，避免影响到线上环境客户的真实使用。通常会尽可能地使用真实数据，但是考虑到隐私和安全性，需要进行严格的管理和保护。

）和生产环境当中的数据一致，是真实数据，所以我们在对数据修改之后要尽量地去复原，不能造成脏数据。

第三点就是SIT 阶段时，在确保功能和业务的完整性之后，我们对于功能和业务都需要去测到，然后功能的话主要就是说 SIT 测试得比较细，要从等价类边界值，然后异常，然后弱网等方面去测试。

而 UAT 阶段的话，它是在确保功能完整性的情况下，利用真实的数据，我们去测试看它有没有一些 bug，如果说有 bug，我们不能直接的是在 UAT 阶段进行回归，我们要去到测试环境当中去复现问题，然后开发解决之后再进行回归测试。

直到在 SIT 阶段没有问题之后再到，UAT 阶段进行回归测试。

然后最后的话就是说它们两个的，那个要求不一样，bug 的要求不一样。

对于 SIT 阶段的话，如果说系统比较复杂的话，可能会涉及到，三个轮次，我们会按照那个测试用例的优先级去安排第一轮、第二轮、第三轮，第一轮测试通过的话，首先是要求它的严重级别的 bug 在30%以下才能进行第二轮，第二轮的话是它严重级别的 bug 不能超过10%。第三轮要确保无严重级别的 bug，并且没有业务级别的 bug 才可以推进到 UAT 阶段。

 UAT 阶段测试当中需要开发将所有的遗留问题都要解决掉，然后保证它的一个 bug 通过率是达到95%以上。可以有一些，与产品商量之后可以有一些下个版本再解决。

各环境测试任务

SIT测试，主要是做功能测试、接口测试、验证集成模块之间的业务没有问题，UAT测试，主要是争对核心业务流程，执行验收测试，验收新功能业务流程完成是不是ok的，能不能正常跑通，灰度测试（发送给一部分优质用户先去体验新的版本，给指定用户去执行新业务 新流程），定版测试（全量测试），先在内部测试，测试完成ok，才会给到运营组去把app的新版本的包上线到各个应用市场，像华为市场、豌豆荚、应用宝等市场

测试环境各项目所需时间

SIT测试，需求测试/需求变更/业务流程（1-2个月），用例测试（2-3个月），bug回归（1-3个月），UAT测试3个月左右，定版测试：1个月内测试完全，并且bug全部修改完毕，不能在改动了！

Bug比例 sit：Uat=4：1

1. 需求怎么来、怎么分析、涉及人员、分析过程中的难点？

他肯定是有一个需求说明书的。然后首先第一步就是快速的了解这些系统说明书，它的这个主要的这个系统框架包括是什么？它的一些内容主要是一些什么？然后如果说自己有不懂的话，可以去跟开发或者自己的测试组长评审的时候沟通，然后自己懂了之后再进行一个实操，这个样子的话可以更快的了解和熟悉这个系统。

评审的话，有测试人员、开发，还有就是产品部门，评审完之后，评审完之后，就是组内来评审，就是主要是看有没有覆盖全你的业务规则，有没有不对的地方，需要进行改进。

难点的话就第一个就是肯定我们要针对这个需求，就是你要把需求理清楚，就是现在整体的这个信贷业务的整体流程我是比较清楚的。然后您说是这个难点的话，我觉得就是我们，就比如说我之前项目的一些难点，我们在贷中做一些，比如说像权限，就是跨越权限、水平权限这些校验的时候，这块要做清，要做的比较细。然后再有一个就是可能对用户贷款审核的这一部分，我们要去校验的，就是怎么去校验这块的测试点要写清楚。

1. 案例设计用到哪些方法、一天设计多少案例、设计过程中碰到什么难点问题点，设计过什么案例，具体说一下？

我们常用的是边界值等价类，然后还有一些比如说业务上的。还有一些场景法，然后银行这边，其实业务性的比较多一点，就是你熟悉这个业务的话，可能会考虑的场景会多一些。

设计测试用例数量的话，不同模块的情况不一样，用例数量和难易度都有差别。按我个人经验，一般一天，大概能写个 40 到 60 条左右。

执行测试用例数量的话，就不一定了。有些场景的用例本身就简单，跑起来快；但有些场景比较复杂，执行起来也费时间。而且很多时候测出来的结果都是常规的，没什么问题，这种就快一些。平均60-80条左右

案例的组成部分的话，主要就是的一个编号，案例的一个名称，然后还有案例的一个就是前提条件，还有就是他的一个输入的一个数据，然后还有就是他的一个操作步骤，然后还有他的一个预期结果，然后还有他的一个就是实际的一个结果。实际结果和预期结果，测试日志，测试日期，备注

1. 案例执行有没有遇见什么bug，bug是前端还是后端的，怎么判断，怎么解决的。bug哪个软件提交的，怎么回归的。测试过哪些模块，有哪些测试点？

（bug前后端问题具体怎么分析）首先的话你可以用fiddler去抓这个请求，然后去定位，看能不能再次发一个请求，重复刚刚的一个操作。然后我们去看一下他的那个返回的信息，这个请求有没有出来（就比如说我们这个开户的话，他的一些身份信息有没有填写，看他这边是不是显示了），如果是的话，那肯定这个前端提交的时候就会有问题，如果是没有问题的话，那我们再看他的请求的参数跟我们发的参数是不是一致的。那如果不是，也是前面那个问题，如果都是一致的，而且也没有任何问题的话，那我们就看后端的一个服务器的一个日志，看当前我们操作的那个日志它有没有出来。日志里面有一些sql日志，如果日志没有出来的话，因为我们正常访问都是有日志的，除非存在网络的问题，比如路由器问题导致网络中断了，然后导致这个请求没有发送到后端里来，那去排查一下网络环境。然后如果日志里面是有记录的话，就立马查询一下数据库当前的一个操作（这个看相应的身份信息），这个数据是不是跟数据库一致的？如果是一致的话，那么看返回的一个结果，比如说网关状态码是200，还有这个返回的参数值是否跟那个数据库一致？如果不一致的话，那就是后台的一个问题。如果数据是一致的，然后再看一下他那个银行有特定的业务码，比如说是10000，交易成功 10001，这个业务码不一致（是不是业务增加，新增业务码导致的），就是后端的一个问题。然后如果是返回的数据跟那个数据库是一致的情况，但是 APP 上面的网页显示不一样，没有全部显示出来，那可能就是前端的一个问题（数据已经返回了，但是前端页面还是有问题），可以用这些思路去做一个判断。

（bug怎么提交缺陷）缺陷的话，首先要就要确认这个缺陷，这个 bug 是不是真实存在的（首先我们是会对这个缺陷进行一个抓包，通过fiddler或者 F12来进行找到这个缺陷所在的问题，以及会通过 Linux 进行一个动态日志的查询，找到这个问题是怎么产生的，然后把这个问题和这个产生的原因。然后提交给这个开发。），然后再用缺陷管理工具进行一个提交，首先就是要保证缺陷的一个描述，一个正确性，就是便于开发进行理解，进行一个修复。提交之后，然后后续的话要关注一下这个缺陷的一个状态的一个流转，然后开发修复完成之后，需要对这个缺陷进行一个回归的一个验证嘛，直到缺陷状态关闭。

如果线上出现 bug，第一时间向团队负责人报备，接着要快速定位产生 bug 的模块场景，报错的原因，尽可能的复现，然后分析是偶现还是必现，如果是偶现的 bug，寻找出现的频次，及时跟开发沟通定位，如果是必现，尽快评估影响的范围，如果范围很小，不影响主流程。

讨论解决的方案是直接解决还是延期到下一个版本的时候解决，

如果影响范围比较大，问题比较严重，及时让开发停止该模块的线上访问。

Linux怎么查error关键词：error 的话，你比如说就是用那个 cat，然后log文件，就比如说log文件，点log，然后那个管道符号 grep，然后那个 error 这样去查

印象深的Bug：在弱网环境进行还款操作时，支付页面一直转圈，没有任何提示。

在执行 “还款业务全链路测试” 时，常规网络下功能正常，但在模拟弱网（延迟 500ms+、丢包率 15%）时，支付页面持续转圈无提示。强行退出重启后，查询数据库发现余额已扣，账单却显示 “未还款”。刚开始开发怀疑是支付网关超时配置问题，调整后无效；也排查前端请求逻辑，未发现异常；最后我们携带设备到真实弱网场景，才捕捉到关键现象 ， 就是后端扣款成功后，状态同步数据包因丢包没有送到前端，并且也没有重试机制，导致数据断层。最后前端新增了弱网检测模块，触发弱网时会有弹窗提示 （当前网络不稳定，还款可能延迟，请勿退出），同时会缓存支付请求记录。在后端方面，优化了状态同步逻辑，增加 3 次重试推送，修复账单查询接口，确保重启后能读取最新的一个扣款状态，最终解决 Bug

（为啥到真实环境才发现问题：因为模拟环境的弱网工具难以真实模拟后端主动推送的状态同步包在真实弱网中可能发生的随机丢包情况，且仿真的银行系统、支付网关缺少真实场景中运营商基站等节点的临时拥塞、信号干扰等不可控因素，而真实环境能完整复现这些情况）

收获：测试需补全真实场景验证以覆盖模拟工具盲区，技术上要通过前后端协同（后端重试、前端弱网提示与缓存）保障关键链路可靠性，且全链路需重点关注异常流的状态闭环。

Bug用户点击短信推送消息里面的链接，无任何反应。

我在执行 “营销活动短信推送全链路测试” 时，通过测试号码接收短信推送链接，点击后页面长时间空白无任何反应，既不跳转也无错误提示。起初怀疑是链接生成格式错误，检查链接参数发现符合规范；接着排查前端路由配置，确认目标页路由存在且正常访问；最后对比推送链接与后端页面状态，才发现该链接指向的活动页面已在 24 小时前被删除，但删除操作未同步通知用户，且前端未配置 “页面不存在” 的异常处理逻辑，导致点击后无响应。

进一步分析发现，后端推送机制存在两个漏洞：一是页面删除时无自动触发 “告知用户” 的消息推送流程，仅依赖运营手动通知，存在遗漏风险；二是链接生成后未关联页面状态，即使页面删除，链接仍能正常生成并推送，无有效性校验。前端则缺少 “404 页面不存在” 的兜底处理，当请求的页面不存在时，未触发异常跳转或提示，导致用户无感知。

最终解决方案分三步落地：前端新增异常处理逻辑，点击链接后若检测到目标页不存在（返回 404 状态码），立即弹窗提示 “您访问的页面已失效”，并提供 “返回首页” 和 “查看热门活动” 两个跳转选项；后端优化推送机制，页面删除时自动触发短信 / APP 内消息推送，告知用户 “您关注的 XX 页面已删除，可点击 XX 链接查看替代内容”；同时在链接生成前增加页面状态校验，若页面已删除，直接阻断链接生成，避免无效链接推送，最终解决 Bug。

Bug人脸识别的时候一直得不到反馈的结果。

后续发现问题就是说用户在进行人脸识别的时候是处于弱网的环境，因为网络延时，用户在进行人脸识别的时候一直得不到反馈，还有就是多次重复的点击

解决的一个方案就是明确告诉用户当前的一个网络状态，如果遇到长时间等待，提供取消或者是重新上传的一个选项。

在技术上引入一个超时重传的机制，在后端记录每一次传输的一个结果。

避免重复请求，在请求没有完成的情况下，不允许用户重复地进行操作。

1. 跑批是怎么做的，你的角色在里面是做哪些工作，跑批主要跑哪些业务？

（我们要做的）有跑批相关这样的任务，我们那边的话是主要是开发在做，我这边也了解一些，就是偶尔也会参与支持跑批，比如说还款过程中，首先这个跑批分跑批前、跑批中、跑批后，然后跑批前的话，我们需要准备不同的数据，比如说准备用户有不同的账户类型，不同的还款方式，比如说客户是这个贷款逾期或者正常的用户，他是提前还款还是正常还款的用户，然后还有会考虑到用户的账单的一个情况，比如说用户他的这个贷款的金额是大额还是小额的一个数据情况，或者说有一些是贷款前期，有些是贷款中期，有些是贷款后期，他去做提前还款的一个操作的一个情况。然后的话，测试数据准备完成之后，然后需要确定我们要执行的业务逻辑，比如说我们今天晚上跑批，要跑哪些账户、跑哪些流程、跑哪些数据、跑哪些逻辑，然后执行跑批的话，我们跑批执行过程中主要是监控我们跑批是否有异常，跑批是否顺利，他是否日志报错，或者跑批过程中是否有出现问题。然后如果跑批过程中出现的问题比较大，是否要停止跑批，待修复后重新跑批这样的情况，然后跑批后的话我们要去检查跑批结果是否有问题，有问题的话，我们要去分析定位，这个问题是什么问题？然后怎么样去修复去解决，然后跑批，将数据修复之后的话，最后的话就是将数据去做一个同步，这一块在跑批前我们就要做一个数据的备份，便于后面数据恢复，最后就是去给出我们这次跑批的一个结果报告

跑批跑哪些业务:贷款发放（新发放的贷款信息：贷款金额、期限、利率、借款人资料等）

还款（客户的还款记录：本金偿还、利息支付、提前还款等）

利息计算（根据贷款合同和当前利率计算的信息：应计利息、已收利息等）

逾期（逾期未还的贷款信息：逾期天数、罚息计算等）

账户余额更新（客户贷款账户的更新信息：贷款余额、可用额度、账户状态等）

担保和抵押物数据（担保品或抵押物的相关信息：价值变动情况等）

信用评级数据（客户信用评级的更新信息：基于还款行为、信用状况的信用评分等）

费用和罚金数据（信贷业务相关的费用与罚金信息：各类服务费用、罚金的计算与收取等）

监管报表数据（按监管要求生成的报表信息：各类合规性报表等）

9.会计分录涉及哪些业务，怎么测的？测试的数据哪里来？

（涉及哪些业务详细）首先的话，如果是账务相关的话，他就涉及到一个资金的一个流转，比如说我们贷款过程中他涉及到资金的话，比如说贷款的放款的话，是银行这边将存款发放给用户，那么这一块的话，它需要满足那个会计分录恒等式，他是银行这边贷款的一个增加，存款减少，那么银行贷款这一块的话是属于会计分录的借方，那么存款这一块属于会计分录的贷方，那么如果是计算利息，就是在放款过程中，利息的计提的话，它应该是属于我们的一个，借方，那么利息收入的话，它应该是属于我们的一个贷方，然后后续涉及到，我们的一个还款也是资金的一个流转，那么用户将贷款归还到银行，那么应该是由贷款客户的贷款转变为银行存款的一部分的过程。那么的话就是从银行存款的一个增加，这个话根据会计分录恒等式的话他应该是属于借方那个客户的贷款的话减少了属于贷方，包括利息收取，那么是由利息转为存银行存款构成，那么它应该是我们的一个存款增加，那么存款也属于登记在借方。那么利息收入减少的话，它应该是登记在贷方，那么包括最后银行做坏账处理的话，因为有一些贷款它是没有办法收回来的话，它就去做一个核销，或者是做一个账务的处理，坏账的一个处理，那么它是由贷款转变为我们的一个坏账的过程，那么坏账增加是属于是借方，那么贷款与不良贷款减少的话，它是属于一个贷方的一个过程。（怎么测）再关于账务就是会计分录这一块处理，我个人认为，我认为就是说我们主要关注到首先它是科目的资金的流转，我们要测试关注它这个科目是否正确，包括借方科目和贷方科目，其二的话它金额的流转包括它金额流转的一个科目的正确性，它的金额的前后流转的一致性，因为他要满足借贷相等关系，恒等式

会计分录涉及的业务：贷中贷款发放、利息计提、贷后的贷款回收、利息收取 、坏账损失

征信怎么测，风控规则怎么测，有哪些测试点？测试的数据哪里来？

（征信测试）这一块会用到挡板，就开发给写一些数据，然后我们去造一些不同状态下，卡的数据，比如说正常挂失、冻结、止付等等的情况，去校验不同场景的一个情况。

（征信授权界面测试）用户进入授权界面后。 正常会阅读几秒，然后完成才出现那个同意并继续提交申请，如果未阅读未滑动。 那同意按钮是无法点击的。  阅读的话。 还要看他是否支持横竖屏的阅读？如果用户贷款申请成功后。 那从产品页面再进来。会没有申请的贷款按钮

10授信额度怎么出来怎么测，前中后有哪些测试点？测试的数据哪里来？什么是循环额度？

（额度怎么评估出来的）预授信额度的话，那我们会去综合的一个评估，用户的一个信用评分啊 信用评分会考虑客户的还款历史啊。负债比例啊，还有信用记录长度啊。 等等（数据来源：调用第三方的系统获取，比如说征信系统或者是第三方的这种查询系统。它就会去查询客户在其他的银行或者是第三方的借款平台上贷款的一个情况，会去查看他的一个风险）。 然后每部分都是会有一个分数占比嘛，分ABC等级， 要看客户的收入怎么样，收入高的话， 额度也会。 稍微给高一点。 还有客户的资产情况。 主要考虑客户的一个净资产。 情况良好的话。 也会额度也会适当调整高一点 ，根据综合性情况会评估出客户一个风险系数。 根据各部分评估出的额度总和，然后乘以系数就等于客户的预授信额度（我们实际测试过程中，首先我会准备一些客户的数据，比如说他的这个还款能力好一点的，中等的、差一点的，然后还有这个财务状况可能会好一点，差一点中等的，以及这个信用评级的话。可能是 a 的、b 的、c ，然后组合不同情况进行一个测试），最终通过人工审核给出的一个具体的实际的金额。

（预授信额度的业务流程方面测试点）预授信申请就是客户的一个人信息填写。包含个人基本信息啊，职业信息啊。 还有联系信息。 那这里主要测试一些输入框的一个边界值粘贴还有格式方面是否正确。 然后还有下拉框，比如说学历。选择后是否显示正确？如果不选的话会不会有报错提示？ 其他的话还有就是证明材料啊。这里会考虑到。 不同格式的材料能不能正常上传？ 还有上传的一个文件数量， 如果超过上传的数量，它会不会限制上传。

还有预授信前一个阶段的话，他的那个不做或者没有完成的话，到这个阶段，是否会进行一个校验，然后这个阶段没有完成的话，进入下一个阶段的话是不会有一些校验，还有一些 Ui 界面的一个测试的一个校验，还有一些内容输入的一个校验。 额度的一个最大值，最小值。 还有异常情况。 是非法的还是复数？ 能不能粘贴？ 还款方式的话。 就等额本息和等额本金能不能正常选择？还有能不能正常，选择下拉的一个期数。 收款账户的话。 首先看。 有没有已经绑定的银行卡，有的话就可以直接选择了。如果没有的话就要走绑卡流程。还有一些就是页面兼容性，比如说不同尺寸屏幕显示是否正常

额度申请出来后测试哪些内容，比如说放款，这个申请的额度是否超过了他的那个限制额度

最大的一个限制额度，然后还有一个就是额度申请的话，比如说放款的时候是否和他申请的额度数额和填写的那个合同的额度是不是一致的，然后申请的额度放款的时候那个额度数额和他审批显示的一个金额的额度是一致的。

循环额度的话就是一个随借随还的，如果是循环额度，你借了一部分可用额度会减少，然后你再还一部分，你的那个循环额度的可用额度又会增加，然后进行一个循环利用，然后就是可以一直接一直还，随接随还。然后如果是非循环的话，借过款后，想再借，就要等当前这笔贷款还清之后才能进行去进行下一次，并且需要重新进行一个额度申请

第三方系统怎么测，涉及哪些业务？以及测试的数据哪里来？

第三方系统通过挡板测试（），涉及实名认证、征信查询（）

合同怎么测，有哪些测试点？测试的数据哪里来？

（合同测试）合同之类的协议的话，这块就是在我们这边审核通过之后，会要去根据用户的这个申请的情况信息，去系统下发一个贷款合同给用户，然后这个贷款合同里面包含这个他贷款的一个金额，贷款的期限包括利息，包括这个还款的方式这里也会做一个校验，就是还款方式上面要看用户是否有绑卡，如果没有绑卡的话就需要引导用户去做一个绑卡的流程。

绑卡的话就需要绑我们本行的这个一类卡等等，这里会做一些不同类型银行卡的一个校验，包括卡状态一个校验，然后用户签订之后就上传提交，然后我们再做一个合同的一个审核，合同审核跟用户申请的以及我们就是前面审批的都保持一致的话，就进行这个放款的审核，就是看客户有没有一些违规的记录，没有的话，就可以正常按照约定去放款。

放款的钱如何到账，放款怎么测试？测试点有哪些？

（放款测试点）比如说放款的时候，前面的一个审批没有通过的话，那会不会提示完成前面的操作。如果审批流程通过的话，那放款的一些金额、利率、还款计划是否和那个合同的一致。还有会计科目方面，比如说放款、利息计提，记帐科目对不对、金额对不对，满不满足恒等式，然后正常放款，钱的流转有没有问题，有没有到客户指定账户，金额对不对，

如果放金额是最大、最小、异常值时（比如超出放款金额或者低于贷款最低额度） ，放款的一个情况。

如果用户的收款账户是正常、风控、冻结，金额是否按时间到账，到账后的是否有消息通知 。

那放款成功后，统一柜面系统能否通过放款凭证查到放款的明细以及金额，客户端的账户金额是否准确，异常情况，财务系统出现放款失败，金额的退款流程是否正常，然后就是还有一个UI界面的一个测试，比如说一个放款单的一个状态，包括拒绝、通过、驳回，能不能正常选择、提交，还有对评审内容的填写，字数的一个边界值测试。包括为空、最大字数、超过最大字数，这样一个情况

（放款的钱如何到账）在银行审批通过之后，会把贷款的信息录入到核心业务处理系统，核心业务处理系统负责跟踪贷款的余额、利息、计算还款计划等，之后会把数据推送到财务系统。财务系统先根据会计分录进行记账，进行资金的安排与管理，贷款金额会从银行的内部账户转移到财务系统，为了确保资金有足够的流动性来满足贷款的需求，然后到了发放的时间节点，会调用自动清算系统，通过电子转账的方式把款项放到客户的银行账户中。此时会联动更新客户信息，触发信息推送等，用户会接收到放款成功的信息。在用户端会显示放款的金额、还款计划等。

还款怎么测有哪些测试点？测试的数据哪里来？

（还款是怎么从钱到银行的）还款是通过绑定银行卡，到了还款日，系统自动划扣，处理流程大致为，到了还款日触发自动还款的信息被录入到银行的交易处理系统中。

交易处理系统会对还款的信息进行处理，确认支付的有效性和完整性，对还款的金额、日期进行记录核算。系统接收到用户的还款信息之后，会根据接收的还款信息更新贷款账户，对于正常还款的账户计算并更新剩余贷款本金、应计利息等。对于非正常还款，例如逾期，还需要更新罚金等，核算系统会根据核心系统的更新信息进行会计分录的记账。还款金额会从财务系统转移到银行内部账户，银行的资金管理部门会监控资金的流入。如果是最后一期或者此次还款是逾期并且超过3天的还款，还款的信息会被发送到信用记录系统，根据最新的还款情况更新客户的信用记录。

（还款测试点）比如说一个正常的还款，还有一个提前还款和逾期还款，然后正常还款的话，比如说你正常进行还款一个UI界面一个操作，正常分期还款这个还款一个操作按钮，这个流程是否正确，是否能清晰地显示，操作是不是易懂，然后还有比如说生成一个不到账单日的一个还款的，他那个界面显示是否正确。然后正常还款的话，比如说还款前一个账单显示的一个状态，然后还有一个卡的一个状态，比如说卡是挂失、到期、冻结、正常的一个状态，然后进行还款。还有一个卡余额，比如说卡余额充足和不足的一个情况进行还款。还有比如说支付的过程中，还款的话会自动进行划扣，如果自动划扣，那个开关打开的话，进行划扣是否能划扣成功？那个自动划扣开关关闭，然后去自动划扣还款，是否可以还款成功然后还有就是卡的余额充足的一个情况，去自动划扣进行还款，是否能还款成功？

如果余额不足的一个情况，自动划扣的话，它的一个还款的顺序，比如说是不是先还利息再还本金。还有一些就是还款过程中一些错误异常的一个情况。比如说还款余额不足，还款的方式不正确，还有还款的一个账户不正确，还有还款是网络一个异常情况。进行还款，然后还有就是还款成功和还款失败一个情况，还有还款成功和失还款失败是否给能给到用户一个正确的一个提示。还有就是提前还款，提前还款就是提前全部还款，然后比如说用户是否可以在一个任意时间，能不能还款成功，然后提前全部还款的话，系统是否能校验到一个用户的一个提前全部还款的一个金额。比如说剩余未还的金额加一个提前还款的一个手续费，然后还有用户提前还款之后，他的那个未还金额的话是否会归零。还款单的状态是否会停止生成？然后还款的利息是否也会停止去计息？然后用户提前全部还款成功，他的还款单的一个状态是否会变为已结清？是不是会更新用户的一个还款单的一个状态？是否会更新用户的一个还款记录？然后如果说还款成功的话，系统是否能发送的一个正确的一个还款信息， push 消息给到一个用户？还有提前部分还款的话，就看提前部分还款的一个时间，比如说贷款的前几个月或者最后一个月进行提前部分还款。还有就是提前部分还款用户是否能计算提前部分还款的一个金额。还有一个提前还款的一个手续费，然后还款成功之后是否能计算一个剩余的未还的金额。是否能正确地计算一个利息，还有根据剩余的金额更新一个还款计划。还有提前部分还款之后，也会判断是否是最后一期，如果是最后一期的话是否会更新一个还款单的一个状态为已结清，是否会更新用户的一个信用评级。然后就是逾期还款的话，就是验证用户在逾期的时候是否能正确计算一个逾期未还的一个违约金、一个利息。还有就是逾期状态，那个用户还款后，这个状态是否会更新。还有逾期还款的话是否会对用户进行一个催收？比如说验证一个系统的一个消息提醒。其次考虑还款前后用户端界面的状态，账户余额显示、交易流水、账单是否更新正确，是否与柜面系统显示的一致。其他情况多种还款状态下（例如，逾期，正常，提前）的提前还款操作，比如说用户尝试在短时间内进行多次提前还款操作的情况。用户在进行提前还款操作后尝试取消的情况系统维护或升级期间进行提前还款操作的情况，用户端还需要考虑兼容性，不同用户端、不同手机型号、不同系统是否能正常还款，密码的输入是否处理为不是明码、出现闪退、网络中断等，是否能重新发起。

（还款的异常情况）异常情况的话，比如说举个还款例子，在代扣还款的阶段，首先就是网络情况，就是如果说出现这个弱网或者断网的情况，那用户已经去进行了还款操作，是否能够正确地就是原路退回这个款项到用户账户。

然后其次的话，如果出现一些比如说 APP 闪退、服务器崩溃这些情况，那在恢复之后，用户是否能够重新恢复这个还款的一个操作？

然后同时能够正确地还是计算出用户这些还款的一些金额，包括他的本金、利息，或者说一些提前还款的一些违约金等等。

然后异常情况的话还包括比如说可能会涉及一些中断测试，比如说用户在进行还款操作的时候出现了，来电中断，然后短信或者一些后台的一些 push 消息，包括这个，比如插拔耳机、闹钟响了，目前能想到就这些（还款失败场景下冲正测试：先设定余额不足、账户冻结、银行系统故障等可能导致还款失败的场景，在测试环境中模拟这些还款失败场景以观察系统能否正确识别失败原因并执行冲正操作，然后核对客户账户余额是否恢复到还款前状态、检查失败还款记录是否被撤销或标记为失败、验证银行是否通过短信、邮件等方式通知客户及在相关平台提供提示信息，最后跟踪测试银行在冲正操作完成后对重新发起还款、联系客户解决问题等后续事宜的处理情况。）

接口测试怎么测的，做过哪些接口，接口的测试思路。接口的问题怎么分析的。接口测试用到哪些工具怎么用的，具体实例？

（接口测试思路）首先会根据所测的接口进行分析，分析接口业务是单接口还是多个接口，

（1）比如如果给我的接口只是一个查询类型的接口或者单个登录接口，那针对单接口考虑他的请求的参数、请求相关核心信息、响应结果的展示是否符合业务，比如查询出来的结果是否匹配数据库存在的，对结果的值进行一个断言设置。（等价类/边界值的划分开来）

（2）如果是多个接口业务，比如贷款申请，那用户提交一个贷款单成功前，必须完成很多业务的校验，比如登录、实名认证、获取预授信额度等等，还有接口的依赖测试，比如实名认证接口，用户登录成功之后返回的值中有个布尔值是校验用户是否实名，False没实名，True实名了，如果没有实名是走实名认证接口，如果实名了，走判断黑名单接口， 还有测试关联性接口，比如上一个接口响应的值，作为下一个接口响应值进行参数传递，比如登录接口返回的 token 需要作为后续接口的认证凭证、还有user_id会作为后续接口的参数

（贷款申请接口测试）比如说贷款申请，这方面涉及多接口的依赖和参数关联。首先要理清接口间的关联关系和依赖逻辑：比如登录接口，它返回的 token 和 userID 这两个字段，是后续接口必须用到的请求参数，所以需要提前保留并管理好这两个关联参数。

再看依赖，比如说实名认证接口。它同样需要用登录返回的 token 发起请求，那登录响应结果里也会包含一个实名认证状态字段：如果该字段返回 TRUE，说明用户已完成实名认证，后续就无需再调用实名认证接口；如果返回 FALSE，就必须先调用实名认证接口，完成后才能进入黑名单判断。

另外还有一个附件上传的关联场景：用户在提交贷款申请资料时，如果想补充更多证明自身能力的材料，可通过附件上传接口上传文件。该接口成功响应后，会返回一个附件 ID，这个附件 ID 也需要作为后续贷款资料申请接口的请求参数传入。

然后理清这些关联和依赖后，就可以按流程执行接口测试了。首先调用登录接口：若登录失败，接口会直接返回错误信息，测试终止；若登录成功，再根据返回的实名认证状态字段，决定是否调用实名认证接口。

如果实名认证接口执行失败，同样会返回错误信息，后续所有接口都不再执行 ，就是说，只要中间任一接口出现错误，整个流程就会中断。只有所有接口都顺利执行，到最后一个接口调用完成后，才会返回具体结果，包括 “贷款申请资料提交成功” 的提示、对应的贷款单 ID 以及当前贷款状态。

还有一些异常场景：比如网络出现异常或中断时，系统能否识别并返回对应的报错信息；另外，贷款申请中的实名认证等环节涉及与第三方公安系统的交互，若第三方系统无响应，系统是否能及时识别并给出明确提示。

弱网测试fiddler工具怎么用？

首先要配置好环境，下载证书、设置好代理，然后 rules中的Customize Rules打开脚本，搜索到修改网速参数的位置（就什么样的网络对应什么参数），修改完成后，点击performance里的第一个选项设置生效即可，再次点击的话，可以取消模拟网络。

首先，打开 Fiddler 后，通过菜单栏找到 Rules 选项，选择 Customize Rules 打开脚本编辑窗口，在 OnBeforeRequest 函数中添加网络延迟代码，比如设置 oSession ["request-trickle-delay"] 和 oSession ["response-trickle-delay"] 的值来控制请求和响应的延迟时间，以此模拟网络延迟。

接着，保存脚本后，再次通过 Rules 菜单，勾选 Performance 下的 Simulate Modem Speeds 选项，此时 Fiddler 就会按照设置的延迟参数模拟弱网环境。

测试过程中，可根据需要在脚本中调整延迟数值，也能通过取消勾选 Simulate Modem Speeds 快速恢复正常网络环境，同时结合 Fiddler 的请求响应监控功能，观察应用在弱网下的表现，比如加载速度、数据展示是否正常、有无超时或异常提示等

接口测试过程中，postman具体是怎么操作的（面对不同的测试比如依赖性测试、关联性测试）？

（单接口postman操作方法）

参数与核心信息配置：在 Postman 请求页填写接口 URL、请求方法（GET/POST 等），按接口文档配置请求头（如 Content-Type）、请求参数（路径参数、查询参数、请求体等）。

等价类与边界值测试：通过 “Params” 或请求体批量添加参数组合（例如查询接口的日期参数测试合法范围（等价类）和临界值（如最小日期、最大日期，边界值），可借助 “批量编辑” 或导入 CSV 文件实现多组参数快速测试。）

响应结果断言：在Tests标签页编写脚本，

校验响应状态码（如pm.response.to.have.status(200)）、响应体字段是否存在（如pm.expect(pm.response.json().data).to.exist），并与数据库数据比对（可通过 Postman 发送数据库查询接口或结合外部工具获取预期值，再用脚本断言响应值是否匹配，例如pm.expect(pm.response.json().name).to.eql("预期姓名")）。

（多接口posman操作方法）接口依赖与参数传递配置：

提取前置接口响应值：在前置接口（如登录接口）的 “Tests” 标签页用脚本提取关键参数，例如提取 token：pm.environment.set("token", pm.response.json().token)，提取 user_id：pm.environment.set("user_id", pm.response.json().userInfo.id)，将参数存入环境变量或全局变量。后续接口引用参数：在依赖接口的请求头（如 Authorization: Bearer {{token}}）或请求体（如"userId": "{{user_id}}"）中，通过{{变量名}}引用前置接口提取的参数，实现参数传递。

业务流程控制：利用 “集合（Collection）” 按业务顺序编排接口（如登录→实名认证→获取预授信额度→提交贷款申请），通过 “Runner” 功能批量执行，模拟完整流程。

针对条件分支（如实名认证状态判断），在 “Tests” 中编写脚本根据响应值（如isRealName: false）设置环境变量标记（如pm.environment.set("isRealName", "false")），后续接口通过 “Pre-request Script” 判断标记，动态选择执行路径（如：if (pm.environment.get("isRealName") === "false") { pm.sendRequest(实名认证接口URL, ...) }）。

关联性校验：在流程中每个接口的 “Tests” 中添加断言，除校验自身响应正确性外，重点校验参数传递的准确性（如后续接口使用的 token 是否有效、user_id 是否与登录用户一致），以及业务逻辑连贯性（如未实名认证时，提交贷款申请应返回 “需先实名认证” 的错误提示）。

信贷业务涉及账务怎么测，账务又涉及哪些系统，会计分录怎么测？会考虑哪些异常测试点？

数据库信贷里面哪里会用到？具体用来干嘛？数据库的常用命令有哪些？

（数据库命令）

查SELECT * FROM 表名 where

升序 降序 desc  asc

删除Delete from 表名 where 条件

TRUNCATE TABLE 表名

改UPDATE 表名 SET 字段1 = 新值1  WHERE 条件;

增的话就是 insert into，然后表名 然后指定字段，然后就，values，后面跟上新增的对应字段的数据，然后删除的话是。delete 比如说删除某一个字段，比如说删除某一个，嗯，delete from 表名，然后where 后面跟上筛选条件，筛选范围改的话就是，update 表明 然后set 什么字段等于什么值者，带条件的话，用where 进行筛选，查的话就用select 字段 from 表名 用where筛选，涉及到分组就用group by 执行，然后用having对分组内容进行筛选。然后用orderby 进行排序涉及到限制查询结果数的可以用limit后面跟上数量，

（登录数据库）打开终端（Linux），ssh 跳板机用户名@跳板机IP -p 跳板机端口（例：ssh test_oper@10.xx.xx.10 -p 22），连接数据库，然后输入跳板机密码，就会进入跳板机终端。在数据库服务器终端，输入登录命令（sql plus 用户名/密码@服务名）：

linux哪里会用到，具体用来干嘛，涉及到的命令？

在 test.txt 中找包含 “error” 的行

grep "error" 文本名  在文本中找包含 “error” 的行

-cat 修改文件

-tar 压缩

-head 查看前几行

-tail 查看后几乎 -f 实时查看 -n 指定行数

Vi 编辑文档，:wq 保存退出  :q! 强制退出

-grep 我们一般用来匹配相对应的条件查找指定的文本

find /opt/ohj/test224/ -name "*.*" | grep -ril  "hello"

-who  我是谁

-pwd  我在哪

-cd    选择进入路径指令

-mkdir 创建文件夹

-touch 创建文件

-cat 修改文件

-tar 压缩

-head 查看前几行

-tail 查看后几乎 -f 实时查看

-wc -l 统计文件行数

find -name   find -ctime  find -size 查找文件

-awk  我们用来对文本进行处理 -F就是以什么为分割 $NF表示最后一列，$NR==指定第几行

-sed 一般用来进行文本替换，s就是进行替换  --------sed 's/linux/unix/g' sjk.txt

不同服务器之间文件的传输  SCP  

         scp -r "需要传输的文件" "接收文件服务器的用户名"@"接收服务器的ip":"文件接收路径"

查询进程： ps -aux

                    ps -elf

                    Top

                   Pastree -aup 以树状结构查看进程信息

查看磁盘空间大小的命令：df -h

查看文件和目录大小的命令：du

如果我在 Linux 上面要修改一个文件，然后并且保存，嗯，然后我应该去怎么去做？

我首先我进入到目录之后找到这个文件，通过 VI 编辑器去打开这个，打开我们这个文件，然后找到我们要修改的修改的内容，修改之后我们用嗯 wq 用命令  保存之后退出。

Jira怎么提交缺陷，怎么跟踪回归bug，处理bug的时候具体怎么操作？

一、提交缺陷（创建 Bug）

进入项目（登录 Jira 后，在左侧导航栏或项目列表中点击目标测试项目，如 “信贷系统测试项目”）

发起创建（点击页面顶部 “创建” 按钮（通常是蓝色 “+ Create”），在弹出的 issue 类型窗口中选择 “缺陷（Bug）”）

填写核心信息（

概要（Summary）：输入bug简洁描述，如 “贷款申请页手机号为空时未提示必填”；

描述（Description）：分步骤写复现路径（如 “1. 进入贷款申请页；2. 姓名和身份证号填写正确；3. 手机号留空点击提交”）、预期结果（“应提示‘手机号为必填项’”）、实际结果（“无任何提示，页面无响应”）；

优先级（Priority）：按影响选（如 “高”）；

严重程度（Severity）：按级别选（如 “功能失效”）；

组件（Component）：选择对应模块（如 “贷款申请模块”）；

附件：点击 “上传文件” 添加复现截图或录屏）

提交缺陷（点击页面底部 “创建” 按钮，缺陷状态变为 “新建（Open）”）

二、跟踪缺陷（跟进流转与进度）

定位缺陷（在项目页面点击 “问题”→“搜索问题”，通过筛选条件 “报告人 = 当前用户”+“状态≠已关闭” 找到提交的缺陷）

关注状态变化（

查看状态：缺陷详情页顶部显示当前状态（如 “开发中（In Progress）”“待验证（To Verify）”）；

沟通协作：在 “评论” 区输入疑问（如 “该缺陷是否涉及后端校验逻辑？”），@开发人员（输入 “@+ 姓名”）；

更新信息：若复现步骤有补充，点击 “编辑” 修改 “描述” 字段，或添加 “标签（Labels）” 如 “iOS 端”）

验证修复（当状态变为 “待验证” 时，按原步骤测试，若未修复，点击 “状态” 下拉框选择 “重新打开（Reopened）” 并备注原因；若修复，准备关闭）

三、关闭缺陷（确认问题解决）

确认修复（重复复现步骤，确认实际结果与预期一致，且无衍生问题）

执行关闭（在缺陷详情页，点击 “状态” 下拉框，选择 “关闭（Closed）”）

填写关闭说明（在 “评论” 区输入依据，如 “经测试，手机号为空时已正确提示‘请输入手机号’，符合需求，关闭”，点击 “更新” 完成操作）

fiddler定位bug，具体是怎么操作的？

每个业务会跟哪个系统进行交互？

5.信贷活动（信贷活动的背景、测试点）

24.信贷活动的背景、项目流程介绍？

（信贷活动背景）为了在年中阶段拓展新客户群体、提升信贷业务新客转化率，平台限时推出的一个专属信贷活动，向新客户提供不限量的 20 天免息券，还有总计 6 万份的 10 元的面值的贴金券

（活动测试点）

用户进入到活动展区，如果未注册本行 APP 的新用户，会提示进行注册，已注册但未申请过贷款的用户，可以正常进入活动页面，已注册且申请过贷款但申请取消 / 失败的用户，需验证这类用户能否正常进入活动。

资格校验结果：不符合上述条件的用户（如已成功申请过贷款的老用户），需验证系统是否会明确提示 “无参加活动资格”。

登录状态校验：用户未登录时点击参与活动，需验证是否会引导登录，登录后能否正常进入活动流程。

二、活动券领取测试（分券种验证）

（一）贴金券领取

时效与状态：活动过期后，贴金券需验证是否无法领取且有置灰标识；活动过期前几分钟，需验证能否正常领取。

库存与并发：贴金券领完后，用户进入活动需验证是否有 “已领完” 提示；库存仅剩 1 张时，多人同时领取需验证系统是否正常处理（无超发、无领取失败异常）。

领取结果：领取失败后，需验证用户能否再次尝试领取；领取成功后，需验证用户卡券列表是否显示该券，同时后台券库存是否同步减少。

（二）免息券领取

领取方式：用户参与活动时，需验证是否能自动领取免息券（无需手动勾选）。

时效与结果：活动过期后，免息券需验证是否无法领取且有置灰标识；过期前几分钟需验证能否正常领取；领取失败后可再次尝试，领取成功后需在卡券列表正常显示。

三、活动券使用测试（分券种 + 场景验证）

（一）贴金券使用

使用规则：用户持 1 张贴金券申请贷款，需验证发放时能否正常使用；持多张时，需验证是否仅允许选择 1 张使用。

时效与效果：活动结束后，贴金券需验证是否无法使用且有提示 / 置灰标识；结束前几分钟需验证能否正常使用；使用时需验证贷款金额是否按 “申请金额 - 券面额” 减免，金额计算是否准确。

（二）免息券使用

使用规则：用户持 1 张免息券申请贷款，需验证发放时能否正常使用；持多张时，需验证是否仅允许选择 1 张使用。

时效与效果：活动结束后，免息券需验证是否无法使用且有提示 / 置灰标识；结束前几分钟需验证能否正常使用；使用时需验证还款金额是否按 “正常还款金额 - 免息期利息” 计算，利息抵扣是否准确。

特殊场景：用户在贷款发放前取消申请，需验证已选择的贴金券 / 免息券是否退回账户；活动结束后，未使用的券需验证在卡券列表是置灰显示（非移除）；券即将到期 / 已过期时，需验证是否通过短信、APP 推送通知用户。

四、特殊场景适配测试

环境异常：网络异常、系统升级 / 故障时，需验证活动券领取 / 使用是否稳定（无领取状态不明、使用后金额错误）。

APP 操作：APP 升级、卸载重装、置于后台 / 清除后台后，需验证已领券是否保留、未领券能否正常领取；领取 / 使用时被视频、电话、push 消息打断，需验证后续能否继续操作。

设备与账号：不同系统（iOS/Android）、不同型号设备，需验证活动入口是否正常显示；游客模式需验证是否仅展示活动（无法领取），登录后能否正常参与。

高并发：多人同时参加活动（领取券、使用券），需验证系统响应是否正常（无卡顿、崩溃、数据错乱）。

五、UI 交互测试

活动入口：APP 滚动栏的活动介绍需验证 UI 显示是否正常（无错位、模糊），点击后能否准确跳转至活动详情页。

详情页：活动详情页的规则说明、UI 样式、页面布局需验证是否正常；页面内按钮（如 “领取券”“查看规则”）需验证能否正常点击，且跳转至对应页面（无跳转失败）。

25.活动涉及哪些测试点，涉及哪些模块，哪些系统，测试点有哪些。什么阶段会涉及到活动测试。你负责哪些模块？

26.质押贷款和信贷的区别

提交资料阶段，质押贷款除了信贷提供借款人的基础资料、财务信息、联系方式，还需要补充提供质押物的详细信息，包括质押物的权属证明

审核阶段的话，质押贷款除了对贷款人基础信息、信用、资质的审核，还会对质押物的有效性与合法性进行审核，（比如质押物是否为借款人合法所有、有没有存在产权纠纷、是否符合贷款机构认可的质押范围），还有对质押物的价值进行一个评估。

合同签订阶段的话，质押贷款除了签订《贷款合同》，还需要签订一个《质押合同》。

明确了，这个质押物的详细信息（如权属编号、类型、评估值）、质押物的有效期、质押期限（通常与贷款期限一致），以及违约处理的一些条款（如借款人无法按时还款时，贷款机构对质押物的处置方式，包括折价、拍卖、变卖等）

放款阶段的话，就是在放款前需要对质押物进行登记，确保质押权合法生效

还款阶段，质押贷款，监控范围更广，除关注借款人的还款行为外，还需持续跟踪质押物的价值变动。如果质押物价值出现大幅下跌，贷款机构会要求借款人补充其他合格质押物，或提前偿还部分贷款以维持质押率平衡。

结清阶段，质押贷款的话，借款人除了结清贷款，还要需办理 “质押物解押” 手续，然后质押物的权属状态（从 “已质押” 变更为 “无质押”）

28.信贷和对公贷款的区别

申请与受理阶段（

个人：材料简单，多为身份证、收入证明、征信报告；

对公：材料复杂，需营业执照、公司章程、财务报表、贷款用途证明等法人文件；

个人多线上申请，

对公需线下提交并对接客户经理）

贷前调查阶段（

个人：重点核查收入稳定性、征信记录、负债比例，无需深入行业分析；

对公：需全面调研企业经营状况、现金流、行业地位、关联企业风险，还需验证担保措施合法性）

授信审查阶段（

个人：审查维度单一，侧重还款能力与征信，审批时效快；

对公：审查维度多，需评估企业偿债能力、项目可行性、合规性，需多部门协同，时效较慢）

审批决策阶段（

个人：多为系统自动化审批 + 人工复核，权限层级少；

对公：按贷款额度分级审批，大额需总行或董事会决策，需集体评审风险）

合同签署阶段（

个人：合同条款标准化，签字即可生效，无需额外手续；

对公：合同需法人或授权代表签字 + 加盖企业公章，涉及担保的需办理抵押 / 质押登记等手续）

贷款发放阶段（

个人：资金直接划至个人账户或指定消费账户；

对公：资金需划至企业对公账户，部分需监管资金用途，防止挪用）

贷后管理阶段（

个人：仅跟踪还款状态，逾期后短信 / 电话催收；

对公：定期上门核查企业经营，监控资金用途、担保物价值，风险预警更频繁，逾期后需对接企业管理层协商）

贷款收回阶段（

个人：逾期后可通过扣划个人账户、催收等方式追偿；

对公：逾期后需启动法律程序，处置企业资产或担保物，流程更复杂）

质押贷款项目背景和流程

（质押项目背景）为满足个人消费者的融资需求，广东华兴银行推出质押贷款产品 “兴付贷”，该产品以质押 + 保证为核心担保方式，全流程支持线上操作，客户可通过本行 APP 端完成贷款申请与还款，涉及贷款产品介绍、贷款申请、抵押物信息录入、实名认证、权属核验、授信（贷款额度确定）、绑卡、审批（多级复核）、放款和还款十大模块。系统聚焦质押贷款业务全生命周期管理，涵盖贷前管理（质押物评估、客户资质审核）、贷中管理（质押登记、放款审核）、贷后管理（质押物状态跟踪、还款监控）、催收管理（逾期处置、质押物查封）、财务管理（利息计算、违约金计提）、产品配置（质押率设置、评估机构对接）六大核心模块，保障质押贷款业务合规开展与风险可控。

首先是登录与身份核验阶段，这是质押贷款的 “准入前置”。用户进入质押贷款产品申请页后，系统会先判断是否已登录，未登录则自动跳转至登录页面，需输入账号、密码完成登录；登录成功后，不直接进入申请环节，而是先核查 “实名认证状态”—— 系统会对接公安身份系统，确认用户是否完成实名（如姓名、身份证号、手机号是否一致）。若未实名，会引导用户走实名认证流程，比如上传身份证正反面、完成人脸识别；若已实名，再进入 “黑名单筛查” 环节，系统核查用户是否在银行禁贷名单内（如存在逾期未还、失信记录等），是黑名单则提示 “无法申请贷款”，非黑名单则进入押品类型选择环节。

接着是押品类型选择与有效性确认阶段，这是质押贷款的 “核心前提”。用户需在两种质押类型中选择：一种是 “理财产品质押”，选择后系统会自动查询用户在本行的理财产品持仓情况 —— 包括是否有可质押的理财产品（排除封闭期内、已冻结的产品）、产品当前净值是否达标（通常要求净值≥申请贷款金额的 1.2 倍）。若用户在本行没有符合条件的理财产品，系统会提示 “您暂无可用的本行理财产品作为押品，无法申请该类型质押贷款”；若有符合条件的产品，就进入贷款信息填写环节。另一种是 “定期存款质押”，选择后系统会查询用户在本行的定期存款记录 —— 确认是否有未到期、可质押的定期存款（排除已质押、已冻结的存款）、存款本金是否满足要求。若没有符合条件的定期存款，同样提示 “无法申请”；若有，则同样进入贷款信息填写环节。

然后是贷款信息填报与账户绑定阶段，重点是 “信息完整 + 账户合规”。无论选择哪种押品类型，用户都需填写贷款具体信息：包括贷款金额（不能超过押品评估价值的一定比例，比如理财产品质押最高可贷 80%、定期存款质押最高可贷 90%）、贷款期限（通常与押品到期日匹配，比如定期存款还有 1 年到期，贷款期限最长 1 年）、还款方式（如按月付息到期还本、等额本息）、贷款用途（需符合监管要求，如消费、经营等，需选择具体用途并简要说明）。信息填完后，系统会核查用户填写的 “收款账户” 和 “还款账户” 是否为用户本人在本行开立的账户 —— 若账户不存在或非本人账户，会引导用户走绑卡流程，需输入银行卡号、预留手机号接收验证码，完成绑定后确认账户状态正常；若账户已存在且合规，就进入安全验证环节。

之后是安全验证与申请提交阶段，这是 “操作安全的最后防线”。当前环节主要通过 “U 盾验证” 确认操作真实性，用户需将本行 U 盾插入设备（手机需用 U 盾连接线，电脑直接插入），在系统提示下输入 U 盾密码完成验证。若验证成功，申请资料会自动提交至银行审贷系统，后续进入审批、放款环节；若验证失败（如连续输错 U 盾密码 3 次），系统会立即触发银行风控预警，对该账户进行临时锁定 —— 锁定后用户无法再操作质押贷款申请，也无法使用该账户办理其他需要 U 盾验证的业务，需用户携带本人身份证、U 盾到银行线下网点，由工作人员核实身份后人工解锁账户，解锁后才能重新发起申请。

审批通过后，银行会按合同约定将贷款资金划转到用户绑定的收款账户，同时对押品进行 “冻结处理”—— 理财产品暂停赎回、定期存款暂停提前支取，直至贷款结清。

接下来是还款阶段，核心是 “按约还款 + 押品释放”，分为正常还款和提前还款两种场景。

正常还款：系统会在每期还款日之前 3 天，通过短信、APP 推送提醒用户还款金额和截止时间。到还款日当天，系统会自动从用户绑定的还款账户划扣当期还款资金（如按月付息到期还本，每月划扣利息，到期一次性划扣本金 + 最后一期利息）。若划扣成功，系统会更新还款进度，并在 APP 端展示 “本期还款成功”；若划扣失败（如账户余额不足），会立即发送 “还款失败提醒”，告知用户需在宽限期内手动还款。

提前还款：用户若想提前结清贷款，需在 APP 端提交 “提前还款申请”，选择 “提前部分还款” 或 “提前全部还款”。选择提前部分还款的，需输入还款金额（通常要求不低于最低还款额，如 1 万元），系统会计算需支付的当期利息和提前还款本金，用户确认后从还款账户划扣资金，划扣成功后更新剩余本金和还款计划；选择提前全部还款的，系统会计算剩余本金、当期利息（截至还款日），用户完成还款后，系统会立即对押品进行 “解冻结处理”—— 理财产品恢复赎回权限、定期存款恢复提前支取权限，同时为用户办理贷款结项，生成《贷款结清证明》供下载。

最后是逾期处置阶段，重点是 “风险梯度化解 + 押品处置”，根据逾期天数分阶段处理：

逾期 1-3 天（宽限期内）：若还款日划扣失败，用户可在宽限期内手动登录 APP 完成还款，系统不收取罚息，也不会将逾期记录上传至征信系统，但会增加 1 次 “还款提醒” 频次（如每 12 小时推送 1 次）。

逾期 4-30 天：宽限期结束仍未还款的，系统会正式认定为 “逾期”，按合同约定收取罚息（通常为正常利率的 1.5 倍，按日计息），同时将逾期记录上传至央行征信系统。此外，银行会通过电话联系用户催收，若用户仍未还款，会对用户名下其他本行账户（除还款账户外）进行 “限额管控”—— 暂停非柜面转账、消费功能，仅保留柜台业务办理权限。

逾期 31-90 天：逾期超 30 天，银行会升级催收措施，除电话催收外，还会发送《逾期催收函》至用户预留地址，并安排客户经理上门沟通还款方案。同时，系统会对押品进行 “价值重估”—— 若理财产品净值下跌导致押品价值低于剩余贷款本金的 1.1 倍，会要求用户补充保证金或追加其他押品；若用户拒绝补充，银行会启动 “押品预处置流程”，提前准备押品变现相关材料。

逾期超 90 天：若用户仍未还款，银行会按合同约定启动 “押品处置程序”。对于理财产品质押，银行会强制赎回用户的理财产品，用赎回资金优先偿还贷款罚息、利息，剩余资金偿还本金；对于定期存款质押，银行会提前支取用户的定期存款（按活期利率计息，损失由用户承担），用存款资金偿还贷款本息。若押品处置资金足以覆盖贷款本息，处置完成后为用户办理贷款结项；若处置资金仍不足以覆盖（如理财产品净值大幅下跌），银行会继续向用户追偿剩余欠款，同时将用户纳入 “银行黑名单”，后续禁止其申请任何信贷业务，直至欠款结清。

29.质押品的状态流转，质押品在各个阶段的流转状态，需要做什么事，以及生成物。测试点

30.对公贷款的项目背景、贷款流程

为满足不同客户（小微企业）的需求，广东南粤银行联合粤财普惠金融推出银担贷款产品 “粤易押”，该产品以银担合作提供担保支持，企业可通过本行企业网银 / APP 进行申请贷款和还款操作，涉及的模块有贷款产品介绍、企业贷款申请、企业实名认证、企业黑白名单、授信（还款能力评估）、对公账户绑定、审批（银担联合复核）、放款和还款模块。同时为更好的对公转贷业务进行管理，系统涉及贷前管理（企业信息审核、贷款用途核实）、贷中管理（担保措施确认、放款监控）、贷后管理（资金流向跟踪、风险预警）、催收管理（企业逾期催收、代偿流程）、财务管理（贷款利息计算、担保费用核算）、产品配置（担保额度设置、风险阈值调整）等模块。

首先企业会先通过手机网银提交开通申请，上传营业执照、法人身份证等材料，审核通过后会获取专属客户号和 U 盾 ——U 盾作为对公业务的核心安全工具，后续登录、提交申请、签合同都需要它验证身份。开通完成后，企业进入手机网银贷款模块时，系统会先判断是否已登录，未登录的话会自动跳转至登录页面，要求输入客户号、密码并插入 U 盾验证，确保操作主体是企业本人。

登录成功后，第一步是 “黑名单筛查”。系统会自动对接银行内部风控系统和外部信用平台，核查企业是否在 “禁止授信名单” 内 —— 比如存在严重失信、涉诉未结、欠贷欠息等情况。如果企业在黑名单里，系统会立即弹出提示 “您的企业暂不符合贷款申请条件，无法办理本次业务”，直接阻断申请；要是不在黑名单，就进入申请资料填写环节。

接着是申请资料填写与提交阶段，核心是 “信息完整准确 + 选项明确匹配”。企业需要填写两类关键信息：一类是企业基本资料，包括工商注册证、组织机构代码证、税务登记证（现在多为 “三证合一” 营业执照，需上传完整页面）、企业章程（需包含股东出资比例等关键页）、近 3 年财务报表（审计报告或季度财报），每一项都要上传扫描件，系统会自动校验文件清晰度和信息一致性，比如工商注册证编号是否与系统查询结果一致。另一类是贷款相关信息，先选担保方式 —— 可选抵押（如企业厂房、设备）、质押（如股权、应收账款）、保证担保公司担保，选好后要补充对应担保材料（比如抵押需传抵押物评估报告）；再填贷款具体信息，包括申请额度、还款方式（等额本金或等额本息）、贷款期数、收款账户（必须是企业在本行开立的对公账户），所有信息填完后，勾选《贷款申请表》《授权查询征信协议》等文件，插入 U 盾签名确认，就能在 APP 端提交申请，申请资料会自动进入银行审贷系统。

然后是审贷审批阶段，实行 “三级审核” 机制，每一级都有明确的审核重点。初审主要看 “材料完整性和基础合规性”，审核人员会检查基本资料是否齐全（比如有没有漏传企业章程）、贷款信息是否填写规范（比如额度是否在该产品授信范围内），有问题的话会退回并注明 “需补充 XX 材料”；没问题就进入复审。复审是核心风控环节，会深入评估企业还款能力和担保有效性 —— 比如分析财务报表中的营收、现金流是否能覆盖还款，担保方式对应的担保物价值是否充足（如抵押品估值是否达标），还会测算实际可贷额度和利率。复审通过后，终审重点看 “政策适配性和流程合规性”，确认贷款用途是否符合监管要求（比如不能用于房地产投资、股票交易）、审批流程是否完整，没问题就会下放最终额度和利率，并生成电子贷款合同。

合同签署与放款阶段，关键是 “合法有效 + 按约执行”。系统生成电子合同后，会推送至企业手机网银，企业需插入 U 盾查看合同内容 —— 包括额度、利率、还款计划、担保条款等，确认无误后用 U 盾签名提交。合同签署完成后，银行会对合同进行最终核验，核验通过就会按照合同约定的时间放款。放款时系统会再次确认收款账户信息，确保无误后将贷款资金划转到企业指定的对公账户，同时在 APP 端推送 “放款成功” 通知。

最后是还款与逾期处置阶段，对公还款规则更严谨，逾期处置也更注重风险化解和流程闭环。系统会实时跟踪贷款还款日，在还款日到来前，先判断企业是否选择提前还款：没到还款日且企业申请提前还款的，分两种情况 —— 提前部分还款的，企业需先还清当期应付利息和申请的部分本金，还款到账后，系统会根据剩余本金、原还款方式和期数，重新计算每月还款金额，生成新的还款计划和还款合同，推送至企业网银确认；提前全部还款的，除了还清所有本金和利息，系统还会触发担保物释放流程，走解质押处理（比如办理解押登记），全部手续完成后，办理贷款结项。

要是到了还款日，系统会先判断是不是最后一期：如果是最后一期，企业正常还款后，担保物会按流程走解质押处理，解除担保关系，之后办理结项；如果不是最后一期，再看企业是否逾期。没逾期的话，系统会自动从企业收款账户划扣当期还款金额，划扣成功后更新还款进度；要是逾期了，第一步判断是否超过宽限期（对公宽限期通常 1-3 天），没超的话，按正常账单金额划扣，不额外收罚息；要是超过宽限期，再看是否逾期 90 天 —— 没超 90 天的，企业会被纳入预警名单，催收系统会启动多维度催缴：APP 发 push 提示、打电话给企业财务负责人、线下上门沟通，同时按合同约定收取罚息（通常为正常利率的 1.5 倍）；要是逾期超 90 天，就进入深度处置阶段：有担保人员的，会向担保人员发送催收通知，要求履行代偿责任；有质押品的，会启动质押品处置流程（如拍卖、变卖）；如果质押品处置后仍无法还清贷款，且担保人员未代偿，就按银行不良贷款管理规定走核销流程；要是处置后贷款结清，就办理结项手续。

31.对公贷款押品的状态流转、各个阶段的押品状态、涉及的测试点

问题一：请简述对公押品在信贷全流程中的关键流转环节？

对公押品流转需兼顾企业经营属性、权属合规性和风险缓释能力，核心围绕 “押品准入 - 评估 - 登记 - 监控 - 处置” 闭环展开，关键环节如下：

押品准入与信息核验阶段：企业提交信贷申请时，需同步提供对公押品的 “权属证明文件”（如房产证、股权登记证明、应收账款确权函）及 “价值支撑材料”（如近 3 年财报、资产评估报告）。银行先核验押品是否符合准入标准（如是否为限制抵押的公益资产、权属是否无争议），再将押品信息（类型、数量、权属人、对应授信额度）录入对公信贷系统，完成 “押品建档”。

分层评估与审核阶段：

初审侧重 “押品合规性”：审核权属证明有效性（如房产证是否在抵押期内、股权是否被冻结）、押品与企业主营业务的关联性（如生产设备抵押需匹配企业生产规模），不合规则退回企业补充材料；

复审核心 “价值评估”：需委托第三方专业机构（如资产评估公司）对押品估值（如厂房按市场法评估、应收账款按回收率测算），同时结合企业信用评级调整押品折扣率（如 AA 级企业固定资产折扣率 60%，A 级企业下调至 40%），价值不达标则终止流程；

终审重点 “风险缓释匹配”：确认押品评估流程合规、折扣率合理，且押品对应授信额度不超过 “押品评估值 × 折扣率”，合规则进入担保合同签署环节。

押品登记与合同绑定阶段：与企业签署《最高额抵押合同》《质押合同》后，需完成 “法定登记手续”（如不动产抵押到住建部门登记、股权质押到市场监管部门登记、应收账款质押到央行征信中心登记），获取登记证明后，将押品与授信合同 “强绑定”，系统标记 “押品已登记，担保生效”。若未完成法定登记（如股权未公示），押品不具备法律效力，需重新办理。

贷后监控与动态管理阶段：放款后需定期（每季度 / 半年）对押品进行 “动态监控”：固定资产需核查是否存在闲置、损毁；股权需跟踪企业股价波动、股东结构变化；应收账款需确认债务人还款进度；大宗商品需关注市场价格走势。若押品价值下跌超 10%（或触发合同约定阈值），需要求企业补充押品或提前归还部分授信。

逾期处置与解押阶段：企业逾期后，先通过协商要求企业补充押品或还款；协商无果则启动 “对公押品处置”，如拍卖企业厂房、划转质押股权收益、向应收账款债务人追索；处置后款项优先偿还授信本息及处置费用（如诉讼费、评估费），剩余部分退还企业。若企业正常结清授信，需协助办理押品注销登记（如解除不动产抵押、删除股权质押公示），完成押品解押。

问题二：对公押品在信贷各阶段对应的核心状态有哪些？这些状态如何反映业务进展？

对公押品状态需精准体现 “权属合规性、价值稳定性、担保有效性”，核心状态随业务阶段动态变化，具体如下：

准入阶段初始状态：

待准入核验状态：押品信息已录入系统，但未完成权属合规性审核（如未核查股权冻结情况），处于 “预建档” 阶段，不具备担保资格。

审核阶段动态状态：

合规待补正状态：押品权属存在瑕疵（如房产证未体现共有权人）或材料缺失（如应收账款无确权函），需企业补充材料后重新审核；

价值待评估状态：押品合规性通过，但未完成第三方评估，等待估值报告出具；

评估值不足终止状态：第三方评估值 × 折扣率低于授信需求（如企业申请 5000 万授信，押品评估值 8000 万、折扣率 60%，仅能覆盖 4800 万），押品担保无效，流程终止；

审核通过待登记状态：押品合规、价值达标，等待办理法定抵押 / 质押登记，具备担保基础。

登记与贷后阶段核心状态：

已登记担保生效状态：完成法定登记，押品正式成为授信担保物，对应授信可正常放款；

贷后监控中状态：放款后定期跟踪押品价值、权属变化，状态随监控结果更新（如价值稳定则维持此状态，价值下跌则触发预警）；

押品不足预警状态：押品价值下跌超阈值（或企业新增其他负债影响押品优先级），需企业补充押品，否则可能触发授信提前到期；

待处置状态：企业逾期且协商无果，押品进入处置流程（如启动拍卖程序），状态标记为 “处置中”；

已处置 / 解押完成状态：押品处置完毕（款项用于偿债），或企业结清授信后完成押品注销登记，担保责任终止。

问题三：站在银行风控与系统测试视角，对公押品在各阶段需重点验证哪些测试点？

对公押品测试需聚焦 “企业权属复杂性、估值专业性、贷后监控时效性”，核心测试点围绕风险防控和流程合规展开：

准入与审核阶段：合规性与估值准确性测试

权属核验测试：模拟 “押品权属瑕疵” 场景（如企业以租赁厂房抵押、股权存在质押冻结），验证系统是否能通过对接工商、不动产登记、征信中心数据，自动识别并拦截；

估值逻辑测试：测试第三方评估报告上传后，系统是否能按企业信用评级自动计算 “评估值 × 折扣率”（如 AA + 级企业应收账款折扣率 70%，A 级 50%），且能拦截 “评估值不足覆盖授信” 的申请；

材料校验测试：验证系统是否能校验押品材料完整性（如固定资产抵押需上传房产证、土地使用证、环评报告），缺失关键材料时无法进入下一环节。

登记与合同阶段：法律效力与绑定一致性测试

登记信息同步测试：模拟 “押品登记完成” 场景（如获取不动产登记证明），验证系统是否能自动关联登记编号、登记期限，且与授信合同绑定，避免 “合同签署但未登记” 的法律漏洞；

合同条款匹配测试：测试系统是否能根据押品类型自动生成对应合同条款（如股权质押合同需包含 “股权分红优先偿债” 条款、应收账款质押需包含 “债务人通知义务” 条款），无条款缺失或错配。

贷后与处置阶段：监控与风险处置测试

贷后监控触发测试：设置押品价值下跌阈值（如大宗商品价格下跌 15%），验证系统是否能自动推送预警通知，且关联 “补充押品”“提前收贷” 等处置建议；

处置流程闭环测试：模拟 “企业逾期处置” 场景，验证系统是否能记录押品处置进度（如拍卖公告发布、竞买登记、成交确认），处置款到账后是否能自动核算 “本息抵扣、费用扣除、剩余退款”，无核算错误；

解押登记测试：企业结清授信后，验证系统是否能自动生成 “押品注销登记指引”（如需提交的材料、办理部门），且登记完成后同步更新押品状态为 “解押完成”，无状态残留。

1. 理财产品的背景

宝盈理财卓越臻享是南粤银行开发一款新型净值型理财产品，配套了后台管理系统。为投资者提供一个充分了解风险、自主选择购买的投资平台。这款产品销售渠道涵盖手机银行 APP、企业、手机网银等。项目涉及的模块包括理财产品申购、认购、赎回、份额查询、明细查询等模块，在这个项目中我主要负责认购、赎回模块。

33.理财产品的业务流程

34.开户、认购、申购、赎回流程

1. 开户

开户的过程需要绑定银行卡，用于理财产品购买啊和赎回操作，需要客户填写银行卡号、持卡人姓名、预留手机号，进行绑定，然后根据所选理财产品类型。然后用户需设置一个独立的用于交易的密码。交易密码是用于确认用户在购买理财产品、赎回等操作时的身份使用

1. 认购流程：

首先理财产品在产品成立日之前就会发起理财产品认购，客户可以通过手机银行app，点击理财商品，进入详情栏可以看到理财产品的一个信息，包含理财产品的名称、利率、最低起起购金额、募集状态、认购天数、额度是否充足还有产品的一个风险等级，点击对应的理财产品进行购买，如果没有登录，系统会跳转到登录页面进行一个登录或者注册，然后实名，实名之后开通理财账户，开户的过程需要绑定银行卡，用于理财产品购买啊和赎回操作，需要客户填写银行卡号、持卡人姓名、预留手机号，进行绑定，然后根据所选理财产品类型。然后用户需设置一个独立的用于交易的密码。交易密码是用于确认用户在购买理财产品、赎回等操作时的身份，那开通成功后呢，再看看是否是在认购的受理时间内。如果不是的话，就会提示用户不在受理时间内无法申购。 如果是在受理时间内的话，就会看用户是不是满足那个风险评估类型嘛。这个过程需要用户回答一些问题，比如说用户的年龄、收入、投资经验等方面。用户完成评估后，系统会根据评估结果为用户分配一个风险等级，如保守型、稳健型、积极型等。 如果不满足本产品的话，提示无法认购。 满足条件的话，后面就是确认他那个认购份额、认购费用，要求符合相关规定和公式。 然后系统会判断用户的一个资金是否充足，不足的话就提示他那个资金不足，然后流程结束， 资金充足的话，在划扣前，这里会有个要求，就是投资者持有的理财产品份额不能超过总份额的50%。满足要求就对认购资金进行划扣或者冻结相关资金，这个过程系统会自动创建理财子账户，用于记录用户购买理财产品的份额、收益等信息，然后在规定时间内，投资者可以撤销认购申请，如果点击撤销的话。 那锁定的一个金额就会退回，然后流程也会结束处理，选否的话，就会进入一个认购等待，然后在确认份额之前，锁定的本金会按照银行的活期利率计算利息，并且这个利息不会算到份额里面去，确认份额后。 然后系统会判断他那个认购日期是否到期嘛？如果到期了，就会计算认购的金额和利息。 结束整个流程。 没到期的话，就会继续计算认购利息，这个过程利息会折算成产品份额，类似于复利

1. 申购流程

申购在产品的存续期内，任意时间可以进行购买，用户开户后。 首先会确认是否在受理时间。如果不是在受理时间的话，客户可以进行挂单处理。系统会先判断客户是否满足申购条件才允许挂单，然后到了受理时间内，就是每天会有规定受理时间段的。系统会自动对挂单进行一个处理。挂单成功后，需要客户进行申购确认，确定份额以及支付费用是否支付完成，然后完成交易，需要输入交易密码。 进行一个安全认证。支付完成后，会提示支付成功。 如果没有支付，或者说余额不足的话。 就无法进行申购。  那完成支付后。 就会对订单的认购状态进行标记。 这过程是对账环节是确认用户资金是否实际到账的一个环节，并且订单的流转状态会反馈给客户。 如果不满足挂单要求，客户需要在业务受理时间内进行一些操作，比如说看一下客户是否之前购买过这个产品。 如果没有购买过的话，客户会跳转到用户风险评级界面。 看一下是否满足理财风险评估。 不满足的话，提示用户无法购买这个产品。 满足条件就会进入购买页面确定份额并且需要勾选同意理财协议。如果中途退出或者协议未勾选。购买流程走结束处理。如果确认提交订单后，会完成份额锁定。

1. 赎回流程 

首先会判断是否在受理的时间内。 然后看是不是定期产品。 是定期产品的话，就看有没有到了定期的一个到期日？没有到到期日，可以选择提前赎回，在这个过程定期产品客户是无权赎回的，但是产品发行方有权在3个工作日内，按照合同约定的提前赎回方案进行结息换算， 如果是到了定期，这个过程客户可以选择到期自动赎回或者自己手动赎回，并且需要进行支付身份确认。 比如说需要输入支付密码。进行安全认证。然后生成赎回订单，等待银行支付系统支付。 赎回成功后。 持有份额会减少。 如果不是定期产品不一样的地方就是需要满足持有的一个最低期限

1. 认购和赎回的区别

认购和申购的核心差异是在购买时机、价格机制上：​

认购的话通常发生在理财产品发行之前，或是产品刚刚发行的时期。在认购期间，投资者可以提前预约购买产品，但此时产品尚未正式进入运作阶段。认购时，投资者需按照发行方设定的认购价格来购买产品份额。从适用场景来看，认购通常用于封闭式理财产品，比如信托、资管计划等，同时也适用于某些开放式产品的初始发行阶段。此外，认购环节可能会有一定的募集规模限制，若超出规模可能会有配售机制；同时，认购过程中也可能涉及一定的认购费用。​

那申购的话通常发生在理财产品已经完成发行，并且正式开始运作之后。在产品的运作期内，投资者可以在任意一个交易日申购产品。申购时，投资者需按照产品当日的净值（NAV）来购买相应的产品份额。从适用场景来看，对于开放式理财产品，比如各类基金，申购通常是投资者购买该类产品的主要方式。另外，申购可能会有最低投资金额的要求，投资者需满足金额门槛才能参与；同时，申购过程中也可能涉及一定的申购费用。

3.开户、认购、申购、赎回的测试点

1. 开户测试

开户的流程包含，注册登录--实名认证--绑卡--风险评估--购买理财产品--开启理财子账户

1.注册登录（账号格式校验、密码强度验证、短信 / 邮箱验证码有效性、重复注册拦截、登录状态保持与失效机制、忘记密码 / 找回流程、多设备登录冲突处理）

2.实名认证（身份证号格式校验、姓名与证件号一致性校验、证件有效期验证、人像活体检测与比对、证件照片清晰度校验、外籍 / 港澳台证件支持性、公安接口对接准确性）

3. 绑卡（银行卡号格式校验、开户行信息匹配、预留手机号验证、同名卡校验、绑卡次数限制、挂失 / 冻结卡绑定拦截、快捷支付协议签署有效性）

4.风险评估（问卷必填项校验、答题逻辑与风险等级匹配性、评估结果有效期控制、历史评估记录查询、风险等级与产品购买权限关联、重新评估流程有效性）

5.购买理财产品（起购金额校验、限购额度控制、支付渠道有效性、扣款金额准确性、购买协议签署完整性、余额不足 / 网络中断等异常处理、购买记录实时性）

6.开启理财子账户（开户资格校验、子账户信息唯一性、与主账户关联准确性、开户协议合规性、账户状态同步性、历史开户记录查询）

开户：开户的过程需要绑定银行卡，用于理财产品购买啊和赎回操作，需要客户填写银行卡号、持卡人姓名、预留手机号，进行绑定，然后根据所选理财产品类型。然后用户需设置一个独立的用于交易的密码。交易密码是用于确认用户在购买理财产品、赎回等操作时的身份使用

前提校验：检查用户年龄（如满 18 岁）、身份合规性，以及是否存在重复开户或黑名单情况。

身份验证：确保身份证、手机号等信息格式正确且真实有效，人像比对、第三方接口调用无异常。

风险评估：验证问卷必填性、风险等级计算准确性，以及评估结果与产品购买权限的绑定关系。

合规签署：确认协议完整展示、用户必须勾选同意，同时包含监管要求的风险警示语。

异常与安全：测试网络中断、系统故障等场景的恢复能力，以及敏感信息加密、防刷机制是否生效。

1. 认购的测试

认购前--认购中--认购后

认购前：：

产品查询与选择 --（产品信息展示准确性、风险等级标识清晰度、募集期时间显示正确性、产品筛选功能有效性、历史业绩数据准确性）

认购中：

认购资格校验 --（用户风险等级与产品匹配度校验、实名认证状态校验、绑卡状态校验、特定客群资格校验、黑名单用户拦截校验）

填写认购信息 --（认购金额格式校验、起购金额达标校验、递增金额规则校验、单个用户上限校验、支付方式选择有效性）

协议签署 --（协议完整性展示校验、必填协议勾选校验、电子签名有效性校验、风险提示语强制展示校验、协议内容与产品匹配性校验）

认购后：：：

资金支付与冻结 --（支付渠道支持性校验、扣款金额准确性校验、资金冻结状态正确性校验、余额不足提示校验、网络中断后支付状态恢复校验）

确认份额 --（份额计算准确性校验、份额到账及时性校验、认购失败时资金退还完整性校验、退款到账时间合规性校验、结果通知准确性与及时性校验）

1. 申购的测试

理财产品这一块的测试的话，我们是根据不同的系统模块。进行不同的场景测试，比如说交易处理系统。 包含那个申购理财产品的场景测试，那购买理财产品的话，那我们需要验证这个申购流程的正确性，包括申购金额、支付方式、手续费等参数。比如说输入一个有效的申购金额、支付方式、手续费等参数，是否能支付成功。 如果是输入无效或非法的申购金额、申购超过最高购买限额是不是会有提示，无法购买。

产品查询与选择 --（开放申购状态标识准确性、实时净值 / 价格展示正确性、申赎规则说明清晰度、历史业绩数据准确性、产品筛选筛选功能有效性）

申购资格校验 --（用户风险等级与产品匹配度校验、开户状态校验、特殊产品权限校验、限购用户群体拦截校验、反洗钱黑名单校验）

填写申购信息 --（申购金额格式 / 范围校验、最低申购金额达标校验、单日 / 单月申购限额校验、递增金额规则符合性、支付账户选择有效性）

协议确认 --（申购规则确认弹窗完整性、风险提示语强制展示、申购费率说明准确性、电子确认操作有效性、协议内容时效性校验）

 资金支付 --（支付渠道扣款准确性、多账户组合支付支持性、手续费计算与扣除正确性、余额不足 / 卡异常提示有效性、支付超时处理机制）

份额确认 --（未知价原则下份额计算准确性、净值确认时间合规性、份额到账及时性、申购记录信息完整性、异常情况下资金 / 份额一致性）

结果通知 --（申购成功 / 失败通知及时性、通知内容准确性、持仓信息同步更新校验、交易凭证生成有效性、历史记录查询可追溯性）

1. 赎回的测试

持仓产品选择 --（持仓列表展示完整性、产品名称 / 代码匹配准确性、可赎回状态标识清晰度、历史购买记录关联有效性、产品剩余期限 / 本金展示正确性）

赎回资格与规则校验 --（产品锁定期限校验、开放赎回时间匹配性、用户账户状态有效性、大额赎回限额校验、部分赎回最低留存金额校验）

填写赎回信息 --（赎回金额格式 / 范围校验、全部赎回 / 部分赎回选择有效性、赎回份额计算规则符合性、单日 / 单月赎回限额校验、赎回原因填写（如有）完整性）

赎回费用与收益计算确认 --（赎回费率展示准确性、手续费金额计算正确性、未结转收益包含情况校验、赎回金额（本金 + 收益 - 手续费）预览准确性、费率优惠规则（如长期持有减免）生效校验）

赎回申请提交与确认 --（申请信息二次确认弹窗完整性、用户确认操作有效性、赎回协议（如有）勾选校验、申请提交后状态（待确认 / 处理中）展示正确性、重复提交拦截机制）

赎回审核与处理 --（常规赎回自动处理时效性、大额赎回人工审核流程合规性、特殊情况（如节假日）处理规则正确性、赎回申请驳回原因提示清晰度、处理进度查询功能有效性）

资金到账与结果通知 --（到账时间符合产品规则校验、到账金额（扣除手续费后）准确性、资金到账账户与原支付账户一致性、到账短信 / 站内信通知及时性、赎回记录与持仓更新同步性）