这个思路挺强的，没想到通过 chrome 插件来弄。
我的做法是通过 tapd 的 api 做定时任务来获取缺陷变更记录，根据状态的变化通知到相应的人，确实不如插件来的直接。

解决单身问题后，有的问题就不是问题了，加油。

问题是暂时解决了，但这样做未必就好，跟着项目慢慢体会吧

确定代码里没有 driver.close() 吗？
我自己写了个 demo 没啥问题

就不能写成

driver = webdriver.Chrome()


class BasePage:
    def __init__(self):
        self.driver = driver

conftest 里 import driver 么
另外重用 driver 不一定是好的方式

python 的 module 天然是单例的，所以找个地方初始化 driver = webdriver.Chrome()，其他地方都 import 就行了
或者这样：

driver = webdriver.Chrome()


class BasePage:
    def __init__(self):
        self.driver = driver

创建两个不同的页面 P1，P2 继承 BasePage,打印 id(P1().driver),id(P2().driver) 可以看出是同一个对象，
如果 BasePage 里写成 self.driver = webdriver.Chrome(),那每次实例化都是一个新的 driver

docker, elk
说实话，去大公司面试谈前沿技术有点找虐的嫌疑
小公司实现上两者的从 0 到 1 肯定是大功一件

有序一般是指集合中数据保留插入的顺序，另一种说法是排序。
刚写了一堆才想起来 set 是支持 sorted 排序的，那这里有啥问题呢，至于例子中的{1,2,4,5}, {5,4,2,1}是相等的。
如果想支持自定义排序：

class OrderSet:
    def __init__(self, source_set, key=None):
        self._set = source_set
        self.key = key

    def __getitem__(self, position):
        _set = sorted(self._set, key=self.key)
        return _set.__getitem__(position)

    def add(self, item):
        self._set.add(item)
set1 = {'a', 'bbb', 'cc', 'dddd'}
test_set = OrderSet(set1, key=len)
test_set.add('e')
for each in test_set:
    print(each)  # a,e,cc,bbb,dddd

allure serve xxxx\xml -p 端口号

比较难，首先平台用户是测试人员决定了很难衡量实际价值，换我是老板也不太愿意投入。
老大的决定也挺正确，先保证自动化的稳定运行，做好本职工作。
其次，上面也有人说了，这是个人痛点还是团队痛点？平台是不是解决这些问题的最优解？
不能做完平台再抱怨平台这么好为啥没人用。

如果目标不是写一个漂亮的有自定义格式的 excel 文件，会 pandas 就够了

之前也想过如何开展前端自动化，最后个人得出的结论是只有 TDD 才是可行的方式，但 TDD 的推广在大部分公司都不是件很容易的事。最后摆在 Leader 面前的是一道数学题，为了提高代码的质量，我们愿意付出多少时间和人力成本。

其实需求已经实现了，觉得改源码太粗暴就考虑猴子补丁吧

应该是 pycharm 不知道 aapt 的执行路径
解决方法百度一下吧

有点文不对题，如果真想对比两款工具，做这些还不够，结论也不该是非好即坏的表述方式。
参考下虫师的，https://www.cnblogs.com/fnng/p/14230840.html

收藏了备用，一时半会看不明白

完全搞懂这个问题，得先知道装饰器的用法，再看 fixture 的源码。
大概的原因是 change_id_to_name 被 pytest.fixture 修饰后不能当一个普通方法使用了，也不能接受一个非 fixture 的参数。
confest.py：

@pytest.fixture(scope='function', params=yaml.safe_load(****))  # yaml.safe_load得到的应当是一个type_id的列表
def change_id_to_name(request):
    return hand_other_param.change****(request.param)  # request.param看成是固定写法，就是取出来的type_id

用例：

def test_search_type(self, change_id_to_name)
    print(change_id_to_name)

这样写就自动完成了参数化，不需要再来一次 pytest.mark.parametrize

能否介绍下 airtest 在网易内部的使用情况，比如测试架构设计、自动化测试的入场时机，如何应对版本的迭代，CI/CD 等等...

1、base_request=BaseRequests() 放到方法的内部应该可以解现在的问题
2、另外建议对测试的架构重新设计下，测试类下怎么还有 self.get*** 方法。看上去有太多的封装了，requests,assert，真的有必要吗？用例里最好不要再有条件判断，拆成两条用例更好维护一些。
3、如果接口 A 可以看做 B 的前置条件，用 fixture 实现可能更好一点。
4、fixture 中接受到命令行参数 cmhost 后，如果只是测试用例用得上，可以把它 return 出去，就不用 BaseRequest 初始化时候处理这么麻烦了。
5、pathlib 可以很好地处理文件路径相关的问题

@pytest.fixture(scope='session', autouse=True)
def cmhost(pytestconfig):
    return pytestconfig.getoption('--cmhost')

def test_function(cmhost):
    url = cmhost + _url

能落地的方案就是好方案

这个二分查找真是不得不吐槽，需求是 “给出一组有序数组，查找出其中某一特定元素的值，并返回所在位置”，为了秀递归要求用户在调用时多传个 l,r 参数？
强烈建议不要这么写。

我经常会问，作为高级测试工程师，你觉得自己与新人相比最大的优势是什么。如果答的是技术，就问技术给测试团队带来了什么价值，怎么衡量技术的价值，答的是业务，就让他自己举例新人有什么问题，他是怎么做的

年轻真好，说走就走

业务精通或者技术精通，比如你测了 5 年以上的保险相关、财务相关、通信相关，那可能有一些沉淀是别人比不上的。
技术精通也就是各种自动化技术，代码能力。
都没有的话就看有没有管理能力，能不能带队。

首先评估缺陷逃逸带来的结果能不能承受，再看为了减少缺陷逃逸，愿意付出多少代价，结合上两者制定回归测试策略。提高自动化测试的覆盖率和稳定性，度量测试覆盖率，如果用例数量多，考虑分布式执行。
如果测试团队不是特别强，就不要主动说覆盖率的事了。