|
1、自我介绍 重点在于吐字清晰、逻辑清晰，时间卡在2-3分钟左右 2、请对您工作过的项目进行具体介绍 重点介绍信贷业务，凸显需求分析、案例设计、案例评审、案例执行、BUG跟踪 3、有那些测试方法？使用那些测试工具 功能测试、接口测试、自动化测试、安全测试、性能测试 测试工具：结合自己的以往项目情况讲自己平时工作用到的工具，如: 数据库SQL 接口测试工具：jmeter、postman 性能测试工具：LoadRunner 案例管理工具：TMS 缺陷管理工具：JIRA、QC、禅道 项目管理工具：SVN、JIRA 自动化测试工具： 4、项目实施过程中怎么做好沟通协调工作？ A、在测试工作开展前，先要明确各关联方的职责；如业务人员要提供定稿的需求、要确认需求问题、要仲裁BUG等；如开发人员要解决bug、提交合格的测试版本等； B、测试执行过程中：一般性问题通过日报、周报、月报及例会向领导进行汇报，紧急和阻碍问题可以发起会议或现场直接找人解决； C、通过的方式：通过方式不限于微信、RTX、邮件、会议等 5、怎么评估工作量？ 工作量评估有几个大的模块：需求分析、案例设计、案例评审、测试前准备、测试执行、测试总结； 其中案例设计和测试执行占的工作量最多，一般每人每天设计45条案例，每日每天执行40案例； 举例：一份需求评估出来要写2800条用例，
其中案例执行还要结合执行轮次；一般是执行四轮，冒烟测试（5-10%）、第一轮全量测试、第二轮全量测试、第三轮回归测试（30.00%） 6、怎么处理多任务并行？ A、首先我们得梳理清楚自己手上任务的优先级，按重要、紧急、不重要、不紧急分； 优先做重要紧急的、再做紧急的、再做重要的、再做不重要、不紧急的 B、重要任务：领导重视的、涉及业绩的、涉及监管的、涉及业务开展的； C、紧急任务：马上要上线的、生产缺陷、领导再三叮嘱的 7、我们怎么应对项目风险？ A、第一：提前预防风险，项目实施过程中对可能发现可能风险的地方提前梳理应对措施； B、第二：及时汇报风险，当发现风险时，高级级别的风险要马上向领导汇报，并马上采取应对措施；低级别的风险可以通过例会、日报、周报等方式向领导反馈； C、第三：当风险成为问题时，需要提前向领导和公司寻求帮助；并积极协助解决问题； 8、测试过程中加塞需求，怎么安排测试的优先级？ A、第一：先需要确认自己的工作量是否已经饱和，如果饱和需要提前和领导报风险，并且新加的需求优先级比较高，就需要暂停其他需求的测试； B、第二：一般加塞的需求都是紧急的需求，但是我们依然需要和领导确认加塞的需求是否为紧急、重要需求，如是，就优先测试； C、如果同时手上有几份重要紧急的需求，并且时间上冲突的话，一样需要向领导汇报风险集寻求领导人力支援； 9、 自动化介绍？ 有做过的话，就简单介绍下；没有做过的尽量说有涉及，但是不精通。 10、信贷测试流程？ 信贷流程： 对公信贷流程（粗）：1、建立客户信息→2、授信申请→3、贷款申请→4、贷款申请审批→5、合同管理→6、出账管理（申请、审批）→7、贷后检查→8、监管、征信报送→9、催收 个人信贷流程（粗）：1、建立客户信息→2、授信申请（与贷款申请一起）→3、授信申请审批→4、合同管理→5、出账管理（申请、审批）→6、贷后检查→7、监管、征信报送→8、催收 11、怎么设计案例？ A、拿到需求，先分析需求，并且编写测试点； B、依据测试点编写案例 测试案例的重点是业务流程、业务逻辑、业务场景、系统控制、账务； 12、信贷会计核算？ 会计核算测试专业性比较强，如果没有测试过，就说有接触过会计分录测试；但是没有单独负责过会计核算办法的测试。会计分录的测试重点是会计分录的时间、币种、借贷方向、金额等。 13、sit与uat测试的区别，各侧重点是什么？ SIT：系统测试，重点是系统功能测试，会使用到数据库，会细到测试字段长度； UAT：业务验收测试，重点是模拟用户行为测试，并且关注用户体验 14、各银行使用的测试工具？ 缺陷管理工具：jira、禅道、QC及其他行里自研的工具 项目管理工具：SVN等 接口测试工具：Postman、jmeter等 自动化测试工具：Selenium、jmeter及行里自研的工具等 性能测试工具：loadrunner 15、执行过程中，bug的处理流程是怎么样的？ A、致命的阻碍性问题、无法测试了，马上在项目组大群里面@BUG的负责人，并且他座位去督促负责人解决问题；然后再在系统里面提BUG； B、严重问题，此类问题主要是业务逻辑、账务或单个系统功能无法正常使用，遇到此类问题，优先提bug，并且将bug严重级别定为严重，并且每半天跟进下问题解决的进度，如果开发没解决，就需要找开发了解原因，如果超过1天时间，还没解决，就需要找领导报风险并且让领导推进此问题； C、一般和微小类问题：此类问题一般是直接在系统里面提bug，要关注的是，bug标题要清晰明了，要有截图、测试数据、测试环境、操作步骤、预期结果、实际结果 温馨提示： 如果开发质疑bug重发、无效等，我们需要仔细核对，并且让开发给出证据，我们再关闭或取消bug； 如果开发打回的bug无法验证，请马上打回给开发，并将此情况汇报给测试组长，有测试组长收集此类问题，统一和开发交涉。 16、如果你的测试案例是别人写的，你怎么开展工作？ A、不管是谁写的案例，在测试过程中一定会出现如需求变更、编写错误、测试点编写不全等情况，需要调整测试案例；如果遇到此问题，应该优先和之前编写测试案例的人员沟通，再修改测试案例，如果变动量大，需要组织案例评审 B、在开展测试前，需要项目组安排测试前培训，包括但不限于业务需求、测试系统功能、测试案例、行里测试规范（测试执行规范、提bug规范等）； 17、测试执行过程中，一般会遇到哪些问题，你的应对措施是？ A、需求变更：项目实施过程中，一定会遇到需求变更；一般的应对措施是测试在需求分析阶段就参与进来，避免出现测试人员不知道有需求变更，依然以旧需求在测试，浪费时间； B、测试版本提交时间延迟：向领导汇报风险；提前去开发环境熟悉系统，方便提测后快速测试；优先执行住流程案例，摸清楚开发提交的测试版本质量； C、测试时间不够：报向领导风险、加班赶进度、调整测试策略，确保重要流程、重要业务被测试。 |
|
|
