面经第二弹(自看)

2.介绍自己项目

        龙江银行的一个项目，该项目是实现财务核算由总行-分行-支行的管理层级全覆盖，实现报销工作“集中化、电子化、智能化”这样一个财务核算系统，项目从2020年3月开始立项、设计开发，到2021年1月完成测试发布上线，我们前后有5个人参与这个项目的测试，我主要负责费用管理模块，例如审批流程的设计需要覆盖金额分支、部门分支、费用类型分支等，报销需要关联票据信息、分摊信息、费用类型信息等。我的工作包括需求确定以及分析，设计测试案例、功能测试的具体执行、测试结果分析、最后文档归档总结工作。大概就这些。

3.测试难点

        应该就是费用报销的审批流程了，第一点，十分复杂庞大，条件多审批环节多，覆盖不容易；第二个，流程中遇到同审批人增加自动审批；第三，退回时可退回申请人，上一审批，指定审批人；流程复杂且庞大，覆盖困难。

4.测试过程中遇到的印象深刻的bug

        报销审批时，当最后一个审批节点为自动审批的情况，状态没变为审批结束，但是可以正常进行记账，记账完成账务正常。

5.数据库查询题目

    查询2月份所有的订单总数

    SELECT COUNT(*) FROM orders WHERE order_time BETWEEN '2022-02-01 00:00:00' AND '2022-02-28 23:59:59';

    查询商品数量大于3的订单的订单号和创建时间

    SELECT * FROM orders WHERE order_id IN (SELECT order_id FROM detail GROUP BY order_id HAVING COUNT(goods_id) > 3);

6.一个商品同时满足6个条件会改变状态，至少需要设计几条用例

    7条用例，111111，011111，101111，110111，111011，111101，111110

7.场景法

    模拟特定场景，通过某件事来触发某动作，并观察最终结果，从而发现需求中存在的问题。

附加：测试方法

    【等价类划分法】把所有可能输入的数据，无效/有效等价类（正确/非法输入）划分为若干部分（子集），从每一个子集中选少量有代表性的数据作为测试用例

    【边界值分析法】对输入或输出的边界值进行测试，通常作为对等价类划分法的补充，测试用例来自等价类边界

    二者区别：边界值不是从某等价类中随便挑一个作为代表，而是将等价类每个边界都作为测试条件，且不仅要考虑输入，还要考虑输出产生的测试情况

    【场景法】模拟特定场景，通过某件事来触发某动作，并观察最终结果，从而发现需求中存在的问题。其中基本流是经过用例的最简单的路径；备选流则是在某个特定条件下执行，可重新加入基本流，也可用于另外的备选流（或者终止用例）。

    【判定表】在某些数据处理的问题中，针对不同逻辑条件的组合值会有不同的执行操作；判定表能将复杂的问题按各种可能的情况全部列举出来，设计出完整的测试用例集合。

    【正交排列驱动法】界面中通常有多个控件，且控件之间有多种组合关系，如果数量巨大就没必要全部测试，只需针对组合中最优最少的组合进行测试

    二者区别：正交表一般用于组合较多的场合，判定表一般用于组合较少的情况

    【因果图】适用于检查程序输入条件的各种组合情况。因果图法是图示法(逻辑模型)找出语法中描述不严谨的不可能的组合，将这些不可能组合从判定表中排除掉；因果图法建立在判定表之上的。

    【错误推测法】基于经验和直觉来推测可能存在的错误和容易发生错误的特殊情况。

8.基本流和备选流

        基本流是经过用例的最简单的路径；备选流则是在某个特定条件下执行，可重新加入基本流，也可用于另外的备选流（或者终止用例）。

9.需求业务完全不懂时间紧张怎么做好工作

        首先需求结合被测系统共同进行，实在无法理解可以寻找培训视频培训资料，询问同事，同时做好笔记并且整理出大体框架图，然后逐渐细化，假如后续需求改动，也可以更加准确的定位需求并同步更改。

10.平时和同事沟通

        工作需求不理解或者不明确、缺陷无法重现等等一些情况都需要和同事沟通讨论，日常中和同事关系融洽，很多事情也都共同分享。

11.描述bug都包含哪些内容

        标题、归属模块、优先级、严重级别、操作版本、操作环境、步骤（登录用户，某些重要数据）、实际结果、预期结果、截图

3.介绍银行存款业务以及流程

        先去建立客户信息，然后使用该客户信息进行开户，开户之后进行存入交易，之后可以进行提前支取，或者转存续存等，或者到期赎回后进行销户。

4.开户时存在哪些异常情况

        黑名单用户、客户证件信息过期、证件信息不符，对公是话还有基本户、一般户的限制

5.怎么才能把测试工作做好，关键点是什么

        硬技能方面，第一计算机知识，包括数据库、编程语言等；第二软件测试知识，包括各种测试理论，测试方法，测试用例编写，缺陷跟踪流程，软件质量评估等；第三产品业务分析能力，熟悉所测产品的一些隐藏需求或者功能。

        软技能方面，像沟通能力、做事严谨耐心、富有责任心、对被测产品具有怀疑和破坏的精神、另外还要善于自我总结、自我督促。

6.怎样提高测试用例的覆盖呢

        举例来说，在财务系统中，费用报销的审批流程，十分复杂庞大，条件多审批环节多，覆盖不容易；流程中遇到同审批人增加自动审批；退回时可退回申请人，上一审批，指定审批人；流程复杂且庞大，覆盖困难。当时采取的措施就是，根据行内的要求，画出审批流程图，每一条件、每一分支进行覆盖，条件进行组合覆盖等。

7.梳理需求当中会遇到什么问题

        1. 有详细的需求文档：

            比较严谨负责的团队项目的实施是有详细的需求文档的，我们就可以详阅需求文档来进行测试点的梳理工作，对于需求中我们认为不明确的地方可以找项目领导人进行沟通，做到对需求整体把握和理解，利于测试更好的进行。

        2. 需求文档不明确即有文档但是文档很粗糙：

            一般有两种办法，如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档，如果因为各种原因比如时间紧张或者开发就是不愿意，那么就需要自己去沟通对于文档中不明确的点问清楚，不能含糊不清的测试，于人于己都没有好处。

        3. 没有需求文档：

           我们知道做测试很重要的一点是：我有一个预期，我要把软件运行的实际值跟我的预期去比对，如果达到了预期，那么就没问题，如果跟预期不一致那就是有问题。那么如果没有需求，我们该怎么办：①靠嘴去问，大家去协调，协商沟通，然后大家都回答没问题了，我会自己写一个概要的需求描述，然后让他去确认，他说可以，那就可以这样测，有问题就不断的口头沟通；②要基于用户使用的场景和行业的经验来去做判断它是不是合理的。

        作为一个测试人员必须尽可能获取更多详细的需求信息，否则测试用例的设计肯定也是无从谈起。

附加：如何判断自己掌握了足够的需求呢？

        让负责梳理需求的测试人员直接当做产品人员一样去给测试团队的其他人去讲解需求，如果能够说清楚所有的模块、功能点和必要的流程，且不会被测试团队成员问太多自己回答不了的问题，我觉得需求就算理解的差不多了。如果做不到解答大部分测试人员问的需求问题，那么一定是你的需求还理解的不够到位，需要在进一步去了解和沟通。

8.你觉得自己是个什么样的人

        我觉得自己是一个善于沟通并且严谨的人。在公司人缘很好，无论是本部门同事还是开发同事都比较喜欢和我去沟通问题。遇到有争议的bug，我也能及时沟通解决。

        其次就是善于复盘与记录，对每一天做的事情都整理起来，方便回顾自己时间花在那些方面，效率有没有提高，同一错误会不会再犯。

        缺点就是，有时候会对测的比较苛刻。但是，我觉得对于系统的安全与稳定，测试是最后的防线。该严谨的地方还是得严谨。

9.效率，一天大概写多少测试用例

        一天大概六七十条案例吧，不计算可直接复制的公共案例

10.用例详细到什么样的程度

        手机号码测试为例，1、不输入，空内容2、空格输入 3、输入空格+数字，空格出现在开头、中间、结尾 都要测 4、输入其他非数字字符 5、输入长度为10,11 ，如果是座机 的话需要测13位 6、长度超过11位时，输入框不能在输入

11.提出缺陷情况

        财务系统累计大概提出了3300+条缺陷

3.sql语句能力

4.可以提问公司架构 ，负责的工作，公司目前状况，公司社保 ，公司奖金绩效规则，公司位置