等你遇到了一个想提拔你为测试经理的领导就行了，其他的都不重要。

请问买了票但因为疫情的原因没有去会场，后续大会的视频是自己找相关工作人员提供吗？

我觉得还是得根据线上 Bug 来反推问题的根源，到底存在哪些问题，从整体角度去看应该解决哪些问题，优先解决哪些问题。线上 Bug 多必定是多个环节都有问题导致的，譬如楼上有人提到的测试左右，缺乏接口自动化在所有问题当中的占比可能很小，这就意味着即使搭建起了接口自动化，也仅仅是解决了一小部分问题，最终还是会有大量 Bug 上线。

提到回归测试，有些公司要是不出点回归覆盖率不够甚至没有回归导致的问题，管理层是不会意识到这是一个问题的，更多的会跟你说，你说自动化测试很重要，但我们现在没有也没出什么问题啊。。。
遇到这类情况，想要在不出问题的情况下改变一个人的思想观念，很难

1.提升回归测试效率
2.节省人力
3.降低手工回归测试带来的人为出错风险
4.提升个人开发能力 = 提升个人价值、行业竞争力

经费有限的话就用第三方兼容性测试平台吧，没办法的办法。假如是为了兼容性测试而自购那成本太大了，不光要覆盖机型，还要覆盖系统版本。同样的机型不同的系统版本，也会有不同的问题。
或者像我说的，老板的机型和优先级更高用户的机型先保证，其他的随缘

个人觉得不同的业务特性判断的规则也不一定。比如交易类 APP，涉及到入金的，那么申请的机型就不能单单只参考使用率，要是我的话优先级应该是：老板的手机型号 > 入金占比最高的那批用户机型 > 使用占比较高的机型

业务性强的接口，肯定是要手工写的。举个例子，一个文章列表接口，测试点会有很多，1.随机抽几篇文章核对内容 2.核对总数 3.检查排序方式。。。等等 类似这样的用例我是想不出通过自动化生成的可能性。
能通过技术等手段提升效率最好，假如不能等话还得老老实实手动写，毕竟接口自动化的目的是发现问题，覆盖率达不到那原始目的就很难达到，这样的话还不如什么都不做，我是这么认为的。

楼主可以考虑一下阿里的 PTS，付费的，但自己折腾环境同样费钱还费时，可以根据性价比权衡一下。
另外我觉得 10 万用户，一台电脑 2000=》需要 50 台，不能这么算。
10 万用户并发具体指 1s 内 10 万用户集合在一个时间点同时访问呢，还是总共有 10 万用户只需要在特定时间内（比如 30 秒内）完成 10 万用户的登录行为就行了？
我想你说的 2000 指的线程数；假设 1 次登录耗时 0.2s（响应时间），1 个线程在 1s 内（无限迭代）可以完成 5 次登录，那么即使在 1s 内完成 10 万用户的登录也只需要 10w/5 = 2w 个线程数，每台压力机能支撑 2000 线程的情况下大约需要 10 台来完成。

确实，假如按 5s 作为标准的话确实很不合理，受教了。刚接触性能测试不久，还处于消化基础概念的阶段

感谢赐教

感谢回复这么细致的分析。确实你提到的许多细节先前都没有考虑到，对业务准确的解读是为了得到更准确的指标值，单单用公式硬套出来的指标与实际情况肯定会有比较大的偏差，受教了

感谢。活动场景有些变化 人数变为 20 万，时间持续 5 分钟。
我自己的计算公式是参考另一篇文章的，计算公式中的分子乘了下完成事务所需的接口数，但我觉得你的才是正确的，假如乘以接口数我的理解是计算出来的是 QPS 而不是 TPS。
应该是：TPS=(200000*80%)/(5*60*20%) = 2666
不知道我理解的有没有问题

https://www.cnblogs.com/NaCl/p/10172142.html 《Appium 的三种启动方式》
刚开始用 Appium 自带的方法来启动，发现死活找不到设置 bp 端口的方法，所以后来改为第二种方法来实现了。

public class AppiumDriver {
    /**
     * 启动Appium服务
     * @param port
     * @param bp
     */
    public static void startAppiumServer(String port,String bp){
        CommandLine cmd = new CommandLine("/usr/local/bin/node");
        cmd.addArgument("/usr/local/bin/appium");
        cmd.addArgument("-a");
        cmd.addArgument("127.0.0.1");
        cmd.addArgument("-p");
        cmd.addArgument(port);
        cmd.addArgument("-bp");
        cmd.addArgument(bp);

        DefaultExecuteResultHandler handler = new DefaultExecuteResultHandler();
        DefaultExecutor executor = new DefaultExecutor();
        executor.setExitValue(1);

        try {
            executor.execute(cmd, handler);
            Thread.sleep(10000);
        } catch (IOException | InterruptedException e) {
            e.printStackTrace();
        }
    }

    /**
     * 关闭Appium服务
     */
    public static void stopAppiumServer() {
        Runtime runtime = Runtime.getRuntime();
        try {
            runtime.exec("killall node");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

说明小程序进程就是 com.tencent.mm:appbrandxx。
建议清理下手机环境然后再试试，因为这问题我遇到过，小程序自动化一直用"com.tencent.mm:appbrand0"来切换 webview，突然有一天报错切换不了，并且发现 chrome://inspect/#devices 无法调试小程序的 webview（之前都好好的），最后清了下环境就可以了。

想问下你是怎么确定进程一定是 com.tencent.mm:tools 的？
我的方法：
1.打开微信后执行 adb shell ps | grep tencent，打印出进程列表
2.打开小程序后再执行一遍 adb shell ps | grep tencent，然后看看多了哪些进程
3.最后执行 adb shell dumpsys activity top | grep ACTIVITY 看下当前进程，记录下 pid，然后和第二步多出来的进程做比较，存在交集的那个就是小程序的进程

照你这么描述，我和 1 楼一样也怀疑 androidProcess 不对，不然 page_source 怎么会包含发现页面的内容，建议还是检查一下被测小程序的进程是不是你写的那个，比如我这边小程序的进程就是 com.tencent.mm:appbrand0。

假如切换 webview 没报错的话，需要切换至包含期望元素的 handel 才能找到对应元素，LZ 看看是不是这个原因。
下面是我自己切换 handel 的方法：

/**
     * 【WebView】切换至包含指定元素的WindowHandle
     * @param element
     */
    public static Boolean jumpToWindowHandel(WebElement element){
        Boolean isHave = false;
        for(String handle : BaseCase.ThreadDriver.get().getDriverWX().getWindowHandles()){
            BaseCase.ThreadDriver.get().getDriverWX().switchTo().window(handle);  //遍历handel直到找到相应元素
            waitElement(10,element);
            try{
                if (element.isDisplayed()){
                    System.out.println("找到对应元素;当前WindowHandle:" + handle);
                    isHave = true;
                    break;
                }
            }catch (NoSuchElementException | StaleElementReferenceException n){
                System.out.println("未找到对应元素;当前WindowHandle:" + handle);
                isHave = false;
            }
        }
        return isHave;
    }
}

每次启动太浪费效率了，我是这么弄的，LZ 可以参考下，有不足之处也可以一起讨论。以 TestNG 为例：
1.每一个测试类（class）对应一个页面的测试点（methods）
2.BeforeTest：一般都是启动程序进入首页
3.BeforeClass：从首页进入被测页面（每个测试类需要单独写；进入前检测是否在首页，假如不是则重启 APP 进入首页）
4.BeforeMethod：检测是否停留在被测页面（防止部分功能页面跳转但由于 Bug 或者不稳定导致无法返回，比如分享微信），失败 3 次则重启并重新进入被测页面
5.每一个 Method 执行完后都必须返回被测页面，返回的方法单独在 Method 里写
5.AfterClass：返回首页（因为页面路径不同返回的方法每个测试类需要单独写）

有条件的话找开发帮忙或者自己动手加 id，通过唯一的 id 来定位元素是最靠谱的。

多谢提供思路。决定把返回首页的步骤放在@AfterClass里，每个 class 中的 case 执行完后返回首页，然后继续执行下一个 class 中的 case，假如返回失败就重启 APP。

BeforeTest 相当于每个用例（@Test下的方法）执行前都会执行一次，而我目前只会在切换页面（class）的时候才会重新启动。

没用 python 写过就不瞎说了，但建议你可以参考下 https://github.com/richshaw2015/wxapp-appium

我也遇到过同样的问题，我是将 cap.setCapability("androidProcess", "com.tencent.mm:appbrand0"); 替换为 chromeOptions.setExperimentalOption("androidProcess", "com.tencent.mm:appbrand0");之后问题就解决了。

请问解决了吗？我也遇到同样的问题，Chrome 和 Chromedriver 版本是匹配的