《提升下属主动性，使用模板化思维追踪问题》

除了将自动化测试工具的基本运维工作拆解后指派给下属，还需要自己负责的测试业务内容进行拆解，从而从庞大的问题海洋中脱身。

自己干

在对业务内容进行拆分之前，工作内容非常的庞大和复杂，其中对于测试问题进展的追踪是最耗费精力的。基本的流程主要包括遍历问题，询问研发问题根因，与研发核对修复进展，和测试沟通复测计划，最后确保问题闭环。当负责的业务线数量非常庞大之后，光是遍历测试问题就会花掉非常多的时间，容易陷入碌碌无为的怪圈。

让下属干

之前尝试过让测试同学负责追踪自己问题的进展，但是下属汇报的风格和质量参差不齐，不得不花时间针对汇报进行查漏补缺，结果花费的时间还比自己做的更多，后来不得不收回下放的业务。

制定问题追踪的模板

有了之前混乱的经验教训，将问题追踪的内容定义为一张卡片，对格式做了统一规范，再次下方问题追踪的业务时，明确要求汇报时需要以卡片的形式提交。

在主动沟通中成长

汇报问题有了固定的模板，就意味着填写的过程中需要和研发人员进行对接。例如表格中的 “问题跟因”、“下一步进展” 往往需要研发输出。在这个过程中不仅让测试人员加强了和研发的沟通交流，还推进了问题的进展，也让测试同学了解到了更多业务中的技术细节。
汇报的卡片更新时间可以交由自动化提醒完成，每次更新卡片都会让系统更新最新的时间戳。如果系统检测到 7 天内未闭环的任务没有更新进展，会自动发出提醒，要求测试同学及时更新进展。

问题日志

源源不断的卡片最终形成了测试项目管理中的问题日志，采用看板的分类形式，有利于测试项目经理迅速明确当前项目的风险。
如果将卡片的状态置为已修复，那么看板上也会有自动更新对应的状态。同时也可以直接用鼠标将卡片从 “未解决” 的区域拖动到已解决。

形成良性循环

原先庞大的测试问题，经过了一轮过滤和筛选后，问题就会比较明确和清晰。一开始下属在上交问题卡片时难免会出现填写有误或者理解有误的情况，所以在遍历问题卡片时，也是一个很好的培训成长下属的机会，灌输自己对业务的标准和理解，从而让团队内部对问题的认识理念达成一致。

结语

模板化思维特别适合基层的管理者，而且可以根据业务程度的不同，选择性的将业务问题的追踪下放给测试人员。

发我简历哈，我问问那边的同事

要不你发我简历，我发给深圳的同事问问，我这边是南京，所以不太清楚

应届生什么的走校招哈，社招全年都欢迎的，随时都招聘

我的天，5 年经验，15K 太低了。。。。

只有南京哈

你好，Maven 是基于 Java 的项目管理工具，建议使用 IntelliJ IDEA Community 构建你的 Java 项目：）

支持

收到

Thanks,狂师，it helpd me a lot ：）

for your example,it also works：

from deepdiff import DeepDiff
import pprint

list1 = [{"a": "apple", "b": "banana"}, {"a": "angry", "b": "boring"}]
list2 = [{"a": "boring", "b": "angry"}, {"a": "apple", "b": "banana"}]
pprint.pprint(DeepDiff(list1,list2,ignore_order=True))

Hi,try to use python DeepDiff,make sure ignore_order=True , for example:

from deepdiff import DeepDiff
import pprint

a = {
  "title": "V2EX",
  "slogan": "way to explore",
  "description": "创意工作者们的社区",
  "domain": {
    "url": "www.v2ex.com",
    "host": "8080"
  },
  "data": [{"id":"5e4fa8531225c9423dcda9d8","author_id":"51f0f267f4963ade0e08f503","tab":"share"}, {"id":"5e16978581adfe260207a8c1","author_id":"54009f5ccd66f2eb37190485","tab":"share"}]
}
b ={
  "title": "V2EX",
  "slogan": "way to explore",
  "description": "创意工作者们的社区",
  "domain": {
    "url": "www.v2ex.com",
    "host": "8080"
  },
  "data": [{"id":"5e16978581adfe260207a8c1","author_id":"54009f5ccd66f2eb37190485","tab":"share"},{"id":"5e4fa8531225c9423dcda9d8","author_id":"51f0f267f4963ade0e08f503","tab":"share"}]
}
pprint.pprint(DeepDiff(a,b,ignore_order=True))

try to set MaxWinodwsSize

还有一点，最新的 appium 里面已经集成了 webdriveragent 了，以 appium-desktop 为例，只需要进到文件下面，找到 appium-webdriveragent 然后按照教程编译、安装就行了，因为以前的一些问题，大家都建议去 github 上下载最新的 webdriveragent 代码，编译，然后再复制到 appium 的目录下，现在已经无需这一步了。

执行./Scripts/bootstrap.sh 命令之前要先创建一个 bundle 文件，这一步骤在国内外教程里面是有的，你需要搜一下。
如果你上不了 google，那用 bing.com 国际版搜索 how to test ios with appium. 国内对 appium 文章不少，但是大多都是基于 android 的，ios 的比较少。

1.安装 Appium Desktop
2.进入 Appium Desktop 的 appium-webagent 目录下
3.创建 Resources 目录下的 bundle 文件
4.执行你提到这个 sh 命令
5.用 xcode 打开 webagent 文件
6.修改所有 target 的签名
7.run

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

删除链表中倒数第 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 群多交流。

这个思路很棒，谢谢哈