• 仅楼主可见
  • 8.24 百度面试记录 at 2020年08月26日

    他还有一个变题,就是返回倒数第 K 个结点,基本思路一样,而且会简单一些。

  • 8.24 百度面试记录 at 2020年08月26日

    删除链表中倒数第 K 个链表这道题还是很经典的,除了考察双指针的方式,其实里面考察的知识点很多,不过要注意如果链表要删除倒数第一个,直接返回 head.next 就行了。

    public ListNode removeNthFromEnd(ListNode head, int n) {
            ListNode p=head;
            ListNode q=head;
            while(p!=null&&n!=0){
                n--;
                p=p.next;
            }
            if(p==null){
                return head.next; 
            }
            while (p.next != null) {
                p = p.next;
                q = q.next;
            }
            q.next = q.next.next;
            return head;
        }
    
  • 以职业发展而论,UI 测试、接口测试、压力测试、性能测试和抓包分析都是基本功,真正体现你测试能力的是参与产品的需求讨论、做好产品的缺陷预防工作,精准把控产品上线后可能会发生的异常,保证测试部门和其他部门的沟通顺畅,同时把控需求的合理性。做测试是容易做到管理岗的,这源自于测试岗位需要保证产品质量坚如磐石这一特性决定的。

    • 需求经常变动还必须要做 UI 自动化的话,团队最好是采用敏捷开发。除此之外提供一些减轻重复工作的建议:

      • 先写测试用例再开展编码和测试工作,让产品、开发和测试人员共用一种 “语言”,减少 Bug 和对需求的理解不一致,从根源上避避免需求的不停变动。
      • 对于经常变动的 UI 界面,学会使用 Selenide 而非 Selenium,使用 Selenide 的 $("页面元素定位符").find(byText("你要搜索的页面元素")); 去搜索页面上的元素会更高效,代码可读性更高。对于主力是测试前端 Web 页面的公司,那么 Taiko 比 Selenide 还要好一些。可以尝试使用 Taiko 去编写测试脚本。
      • 采用 Gauge+Selenium(或者 Selenide)去做测试,测试用例可读性高,测试报告清晰可见,测试代码复用率高,减轻重复工作量。
      • 需求变动导致工作量增加的本质是以前的代码会废弃,除了上述提到框架工具之外,阅读《Clean Code》这本书对你的帮助会很大,学习重构你的代码,减少代码中的耦合,归并功能一致的代码,抽取公共方法,适当构造静态类便于直接调用。还有清晰可见的方法名、代码即注释的命名习惯,可以很好地抵御频繁变动的需求,尽可能保证代码的可用性。
    • 虽然人们总说改变不了别人,就去改变自己,但是对于团队开发而言,这句话并不是那么妥当。

      • 测试人员最好要求开发人员做好单元测试,如果论收益而言,单元测试的收益是最高的。简单应付了事的单元测试也不行,应要求开发人员单元测试的代码覆盖率达到 95% 或者 100%。

    最后针对你提出的问题:

    • 1.项目规定有统一的 id,前端不加 id 用其他元素定位项目经理会让反工
    • 2.界面需求随时新增没有稳定的需求
      • 减少 XPath 和 CSSSelector 的使用,尽可能使用 byText() 的方法去搜寻元素。
    • 3.接口验证数据库后 UI 自动化也验证数据库???
      • UI 自动化是有预期的,如成功或失败,准备好数据集然后开展自动化测试会更方便一点,即先从数据库里面把数据拉出来,放到 Excel 或者其他可以被编程语言读写的文件里面,然后在开展 UI 测试时去验证即可。当然你连通了数据库再去做测试应该也可以吧。
    • 4.自动化维护成本太高了效率也不怎么样
      • 自动化测试属于敏捷开发中的一环,团队的开发模式有很多种,比如野路子开发、遵循 DevOps 的开发等等,团队的交付有很多种,比如差不多就能上线了,也有遵循 CI/CD 的交付,理想的自动化测试应该是项目交付中的一环,以 Jenkins 为例,开发人员把写好的代码推送到 Git 上,运维人员在 Jenkins 点击构建,Jenkins 自动去 Git 上拉取最新的代码并且把项目打包好,然后上线到测试环境,然后测试人员写的自动化测试脚本(包括单元、集成、接口、UI)会自动执行,自动产出测试报告,如有问题会向开发人员发送邮件,有些做得比较好的测试平台可以自动提 Bug,如果没问题产品会自动上线。所以从总的情况上来看,自动化测试是效率高,收益好且易于维护的。
    • 如果你担心前一条数据失败导致后面若干条数据都没办法执行,可以考虑:
      1. 一条数据配一个测试用例(这个办法比较蠢,不建议使用)

    2.使用测试框架的循环功能,以 Java 的 TestNG 为例,下面贴一小段代码

    @Test(invocationCount = 3)
    public void test1(){}
    

    test1() 这个方法就会执行 3 次了,如果遇到断言失败,程序终止,那么循环还是会继续执行的,比 for 循环好一些(因为遇到断言失败 for 循环就直接停了,但是 invocationCount 不会)。

    • 但是大量的数据输入最好还是推荐接口测试,UI 测试操作相对简单,而且不会输入过多的数据,自然也不存在一条数据失败导致后面若干条都无法输入的情况了。
    • 测试中断言失败后,程序直接终止是合理的。
    • 因为自动化测试不是用来发现 Bug 的,而是用来验证从前正确的项目,现在是否依然可以通过测试。
    • 所以断言一旦失败,可以直接认为该项目没有通过测试,给开发人员提 Bug 就行了。
    • 如果想要验证错误的测试用例,比如说故意输入一些不符合规则的数据,那可以专门写一个失败类的测试用例,专门用于校验这些非法数据。
    • 自动化测试没有开发那么灵活,可以走分支(if else),不然会造成代码可读性和性能都比较差。
    • 一般来说 App 的自动化测试最好可以和接口测试结合,比如说登录、注册要输入的数据比较多,搭配接口测试可以减轻 UI 测试的工作量。同时也能减少你会遇到的问题。
  • 大致意思是录制好了让人家用吗,SoloPi 试下,阿里的团队做的,很新,最近在宣传,你可以加 DD 群多交流。

  • 这个思路很棒,谢谢哈