？没看明白。

建议先解决你说的文档问题再做接口的测试，接口测试比较顺了再做自动化。规范接口文档需要的不是说 “我做自动化需要用到”，这样是推不动的，因为这是你的问题，不是开发或者领导的问题，自动化收益再高都没用。要改为说前后端没有接口文档出现过多少联调方面的问题导致返工，和进度相互卡住（前端等服务端）资源无法释放问题，这个才是开发或者你领导都要解决的问题——提高开发效率问题。然后要做文档方法不是加重开发负担额外多写，而是用 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 拿了个据说敏感词识别不错，空格啥的都可以排除的库，实际试用误杀率还是比较高

这个思路不错，确实发广告的基本都是批量广告，普通账号日常也就 1-2 个可能被识别为广告。

估计是。但这样计算个人觉得不合理。如果有 100 个，那最后一个批次的 10 个，tps 就是 10/10=1 了，这样 100 个的平均 tps 会比 10 低不少。

但实际上，服务的处理能力并没有下降过，一直都是每秒处理 10 个事务，只是因为有等待，导致响应时间增加了（在题目的理想模型下）。tps 应该只和本身性能有关，这样才符合当 tps 达到本身服务能力上限后，再增加负载 tps 会持平，而响应时间增加的现象。

集思广益，有想法都可以提出哈~

常规手段（敏感词等）都有自己的一些缺陷，而且我们缺少专职内容审核人员，所以全内容审核也比较难做到。所以需要一些非常规但成本又不会很高的手段。目前我们自己想到的主要是强制绑定微信账号，但也想看看有没有更好的想法。

这是一种方法，但也容易发现和绕过。之前见过有的广告贴末尾加一段红楼梦里随便找的 100-200 字的片段，估计就是绕过这种限制用的。

实名制个人觉得确实是一个可操作的点。当然不是说直接让大家给身份证，而是用微信之类做绑定，由微信帮我们创造给这些非正常用户的注册门槛。

问题 3 这个算法很神奇。第一次见到这么拆开求平均的 tps 算法。
平均响应时间公式也不大对，应该是 总请求响应时间/总请求数（10*2+10*1）/ 20 ，虽然结果一样，但意义不一样。

之前试过，有点太直接了，对方察觉到后稍微改下就绕过了，而且也影响了正常大家发帖（比如问个大会门票开发票的，可能就命中敏感词了）。

管理员已经在看到的第一时间删除，尽量减少影响了。
但发广告的基本都是凌晨发，而且手上都有不少账号屯着，不好解。

大家有什么好建议也可以发表下，一起想想办法