1、每次都跑完整流程，换订单号
2、跑完后调用删数据接口，或者直接操作数据库/缓存删数据

注册功能用不了：

客气啦，有收获就好。

是的。。。还是老老实实 logger.info() 这么写吧。

要把 self.logger 省掉也是可以的：

class BaseCase(unittest.TestCase):

    @classmethod
    def setUpClass(cls) -> None:
        # 获取当前时间
        now = timer.current_time("%Y_%m_%d")
        filename = dir_config.logs_dir + r"\{}.log".format(now)
        # 格式
        # %(asctime)s 打印日志时间 %(filename)s: 打印当前执行程序名
        # %(lineno)d: 打印日志的当前行号 %(levelname)s: 打印日志级别名称 %(message)s: 打印日志信息
        fmt = "%(asctime)s %(filename)s %(funcName)s [line:%(lineno)d ] %(levelname)s %(message)s"
        date_fmt = "%a %d %b %Y %H:%M:%S"
        # 打印到控制台
        stream_handler = logging.StreamHandler()
        stream_handler.setLevel(logging.ERROR)
        # 回滚文件输出
        rotating_handler = RotatingFileHandler(filename, maxBytes=1024 * 1024 * 5, backupCount=10)
        # 设置logging的输入内容形式及输出渠道
        logging.basicConfig(format=fmt,
                            datefmt=date_fmt,
                            level=logging.INFO,
                            handlers=[stream_handler, rotating_handler])
        cls.logger = logging.getLogger(cls.__name__)

  def log(str):
      self.logger.info()

子类里面直接调用 log("我是日志") 就可以打印日志了，基本简化到和你 Logger("日志") 差不多了，但看你有没有必要咯，别人看起来可能会比较奇怪。

PS: 上面不建议搞静态（类）方法，静态和动态混在一起会比较乱，全动态方法（不带有 @classmethod 注解的方法）就好了，这样每个子类都是独立的，不会相互影响，也比较清晰。

没找到账号密码？

从技术角度，在百度上输入关键字 - 点击搜索，到界面见到搜索结果，大概有几个步骤：

1、前端把输入框的值封装到接口数据里，发起接口请求。
2、接口请求经过漫长的链路（各种网关、路由），到达百度的机房并到达搜索服务
3、搜索服务内部进行搜索处理（里面还有各种内部流程）
4、搜索服务返回结果
5、经过漫长的链路，浏览器收到搜索处理结果（纯数据格式）
6、前端把数据变为界面元素，展示到浏览器

在公网，2、5 的耗时是不稳定的，而整体来说最大的耗时一般在 4、6 两步。那你这里的测试百度查询服务，是从 1-6 么？如果是，最好的是高速录像机录像 + 多次测试，从用户角度来看，更准确。
如果只需要 1-5，那直接 Jmeter 模拟请求即可。

爬虫的方法不大建议，因为爬虫是在 6 的基础上再增加了一个步骤的，耗时会比 1-6 要高一些，稍微不那么准确

这就是继承了 logging.Logger 模块，是可以做到你说的 filter 、handler 赋初值。但这个我理解不改变 logger 的调用方式吧？

？没看明白。

建议先解决你说的文档问题再做接口的测试，接口测试比较顺了再做自动化。规范接口文档需要的不是说 “我做自动化需要用到”，这样是推不动的，因为这是你的问题，不是开发或者领导的问题，自动化收益再高都没用。要改为说前后端没有接口文档出现过多少联调方面的问题导致返工，和进度相互卡住（前端等服务端）资源无法释放问题，这个才是开发或者你领导都要解决的问题——提高开发效率问题。然后要做文档方法不是加重开发负担额外多写，而是用 swagger 等工具做到基于代码自动生成，这样开发才喜欢和愿意配合。

接口文档混乱，你会因为没有文档导致自动化成本很高（只能通过抓包知道接口具体内容，问人知道各个字段含义和要求，也只能通过看代码知道大部分异常代码），导致你时间都花在确认文档上，而非真的发现接口问题上。准备工作成本比后面执行收益高，容易变成大家累但感觉没啥收益。

基类不是工具类，他是要被继承的。
通过继承，子类拥有父类已拥有的东西，子类不用重复编写或者引入这些东西。

推荐你找个相对流行的 UI 测试框架，看看它自带的 demo 之类示例看看，你需要先扩展视野，要不你的感觉是不大准的。
曾经见过为了写法上节省个 new，然后全部类都搞成静态类，然后由于对象共用，导致用例间相互影响无法并行的，这就有点捡了芝麻掉了西瓜了。

我想要自己的这个类 Logger 替代 logger.info，直接 Logger(……) 就可以了，请问可以实现吗

你现在的就是这个方式的实现了，因为你这里是一个类的初始化方法，所以 logger 对象肯定是在你的初始化方法里初始化的，没法获取到你这个 Logger("xxx") 被调用的位置

用 @cheunghr 的方法就可以了。你想要不 new 直接调用方法，其实就是调用静态方法（python 里对应就是有 @classmethod 注解的类方法），用这个思路就可以了，只是这种用法其实有点怪。

日常接触，大部分用法是使用模板模式，搞个用例基类，里面已经初始化好 logger 对象，然后用例里面直接用 logger.info() 就直接记录日志。这样也不浪费 getLogger(__name__) 可以让日志打印出所在类的特性。而且这种情况下，除了 logger 对象，还可以有很多通用的对象可以在基类里面初始化（比如 UI 自动化里初始化 driver ，或者接口测试里面初始化一些和数据库的连接），节省用例里面额外 new 的语句。

看了不少代码后，个人感受大部分时候规范的写法比自己想出来的极简的写法综合起来更好，因为这些规范都是前人经过无数踩坑后总结的最佳实践，能满足最常用的场景且也有足够的灵活性，关键是这些使用姿势以后换公司换框架都能继续沿用，而不会被框架特有写法绑定死。至于这些规范写法或者优雅写法怎么写，建议可以看看 Python cookbook

也要看资源消耗情况。个人理解，一般并发高的时候，无法立即处理的请求会放在队列之类的地方等待，这个等待队列本身也有一些资源消耗的，从等待队列挪到处理进程也会比并发低时不用这个动作多一些处理成本。

tps 一般是在可用资源恒定的情况下会保持一个相对稳定的值，但如果资源已经减少（分配了一部分去做等待队列或者别的事情，不参与请求处理），那 tps 也会下降。

打印的行号是调用 logger 对象的所在行。你现在封装后 logger 对象永远只有你这个类在调用，别的类都没调用，所以行号都在你自己这个类里了。

PS：看你的用法，应该是想打印的日志里带有用例名称？这个原生 loggging 框架完全可以做到的，用 logging.getLogger(__name__) 就可以了。

其实一般返回值只需要内容正确就行，类型这个基本上服务端的解析框架都会先做一层类型强转，如果转不了就会直接异常，很容易发现。
比如 1 和 "1" ，对服务端来说没啥差别，只要服务端对应对象是 Integer ，都会转成数字 1 进入后面的处理逻辑。

加时间是为了方便区分，要不看到一样的 summary 有 3 个已解决 1 个待解决会有点怪。不过如果可接受也可以不加时间。

message 太长的可以做个简单的截取算法哈，只截取最多多少个字符，并且从后往前截取（针对层层叠加的最外层很可能都是长一个样）。不过一般 message 都不会太长，除非是少数层层叠加的。

保存在 excel 文档后，也想通过代码去删选是否 bug 已存在

没明白代码删选具体是想怎么做，是无人工介入代码直接判断么？个人觉得你的方向可以朝着怎么降低自动化发现 bug 上报到缺陷管理里面的成本（比如搞个简单的 web 界面，人工做一次简单复核，人工复核确认是要上报的一键上报），但代码直接判断会比较复杂（要综合当时的其他数据判定，有一套严谨的规则，甚至考虑引入机器学习自迭代），有这个资源还不如投入到怎么自动生成自动化用例里面。

后端接口测试侧重点是检查数据的交换、传递和控制管理过程

这个点赞同，或者说这个应该是后端测试而不仅仅是后端接口测试，只是后端测试大多通过调接口触发。不过好像正文讲着讲着就不是讲这个点了。数据的交换、传递和控制，个人理解应该是要看输出的。接口的输入不止 request，还有中间件数据、请求其他服务得到的数据；输出也不止 response ，还有日志、中间件调用、其他服务调用。

另外，要把这些都关注到位，其实工作量还是挺大的，实践中建议是结合 code review 的方式进行，这样才比较高效。比如 4.cookie：就是将header中的cookie修改或删除后看是否能返回相应的error code ，这些逻辑非常通用，所以一般都是框架层负责的，业务层不负责。所以只要框架层之前这方面有确认过，就不用再测试了，出问题概率极低。

如果觉得是软广，欢迎举报。

也欢迎大家献谋划策，给些怎么控制软广的意见建议

你是中毒了？末尾这一串链接是啥。

哥，你是中毒了？

因为存在一下两种情况：
a）两次错误相同
b）两次错误不相同
问题：怎样判断 bug 是否已存在

我觉得你需要先想想，怎么可以认为 2 个错误是重复的。是根据 e.getMessage 内容就行，还是加上堆栈，还是还得加上前后 n 行的日志？
确定了这个，问题也就解决了。

PS： b）两次错误不相同，这种我觉得怎么判定应该也不会认为是重复的吧？

补充问题：
1）bug 的 summery 现在还不确定该怎么写，因为如果 error_info 太长，创建问题可能会失败，也希望提供关于 summery 写法的意见
2）bug 的优先级应该怎样给值也没想到最好的办法，因为用例的优先级不能完全代替 bug 的优先级

1、summary 建议接口名称 + 失败 message+ 执行时间，确保不重复且开发看起来比较清晰
2、如果说用例优先级不能代替 bug 优先级，那就按 bug 严重程度咯。我目前想到的：http code=4xx/5xx 优先级最高，业务 code!=成功次之，业务 code 成功但返回字段不符合要求优先级最低。不过建议用用例优先级最佳，毕竟功能重要，功能失败对应的 bug 也应该很重要。

总结

其实个人比较赞成一楼的观点，不要自动化测试错误就直接报缺陷，毕竟环境类问题（如配置不对、数据是脏数据、性能慢一点导致用例超时）当做缺陷，开发一般也不会太认可，而且数量一不小心就会太爆炸（比如测试环境网络问题挂了，立马 100 多个 bug，谁都受不了。。。）。我们一般是执行 2 次用例都是同样错误，才会开始人工去确认，确认后再报 bug。

思路不错，按需加载省空间且提升性能。点赞

我倒更希望楼主分享下 “第一️：判断你有没有自学的能力” 怎么做，也建议问题改为 你有没有足够的自学能力独立完成自我提升 。个人认为每个人都有自学能力，不应该说 “有没有”。而且从个人观察到的情况看，很多时候大家缺少的不是学习的能力，而是自律和坚持。

类比很多人健身没成果，关键不是没学会，而是没坚持。

这个我们这叫做开发联调。

这个很明确是开发团队自己的职责，至少在开发环境的联调是要开发自己完成的，测试环境如果是测试管理，那还可以测试来协助。

建议你可以给老板算一个帐：
假设开发自己做联调：1 个人 10 分钟
开发改完测试来测通不通：沟通了解要怎么测（2 个人 5 分钟），实际测试（1 个人 10 分钟，另一个人干等 10 分钟），如果刚好测试有别的事情忙还要额外的等待时间（几分钟到几个小时不等）

这么一算，测试也不是不能干，本身 1 人 10 分钟，会变成 2 人共 30 分钟，增加 3 倍。老板觉得变成 3 倍资源投入可以接受，那也没问题。

如果说开发自己都不会联调，那只能说这个开发不及格。

主要担心只要对方发现我们有额外的审核，不是立即出现帖子，就会各种尝试突破敏感词限制了。

之前试过仿照 ruby-china 拿了个据说敏感词识别不错，空格啥的都可以排除的库，实际试用误杀率还是比较高