func1 最后一行是 return func2,func2 不加括号就是返回 func2 这个函数本体,所以执行 func3 = func1(1) 的时候相当于 func3 = func2,再执行 func3(2) 时等同于执行 func2(2)
python 里函数也是对象,可以用来作为参数传递和赋值,这里贴一个高阶函数的教程https://www.liaoxuefeng.com/wiki/1016959663602400/1017328525009056
之前也见过一些人在做录制回放和云真机平台的集成,确实降低了使用要求和学习成本,作者能够完成这样一个平台并落地,发文章出来,想来也应该是有一定成效,但还是有一些疑问希望提出来大家共同探讨。
UI 通常包含多个部分的内容,例如样式、文案、动态内容和用户状态,使用截图对比的方式会不会 UI 稍微一变动就会报错,缺少容错性;截图对比具体是靠什么指标去判断断言是否通过呢,相似度么,会有一个绝对差值么。
如果一条用例中有一小部分改动了,这个时候怎样去维护用例呢,修改 solopi 指令不能达到模拟手动操作的效果会需要重新录制脚本么。
用截图对比和录制的方式,可以做到兼容性测试么,录制的用例能否覆盖多个主流机型。
开发这样一个 UI 自动化平台大概需要多少人天
同楼上,楼主在避免处理魔术方法时把带__
的方法都漏掉了,漏掉了__classcell__
,所以报 DeprecationWarning,高版本 python 应该会报 RuntimeError,漏掉了__init__
,类创建后默认使用了无参初始化方法,所以报 MetaClassTest() takes no arguments
class LowerAttrMetaClass_4(type):
def __new__(mcs, name, bases, attr):
attr = {key if key[:2] == "__" else key.lower(): value for key, value in attr.items()}
return type.__new__(mcs, name, bases, attr)
class MetaClassTest(metaclass=LowerAttrMetaClass_4):
Say = "hello world"
def __init__(self, name, age):
self.name = name
self.age = age
def Run(self):
print("MetaClassTest run method")
tmp_obj = MetaClassTest(name="zzz", age=20)
tmp_obj.run()
# >>>
# MetaClassTest run method
xmind 本质上来讲是一个多叉树数据结构,而测试用例算是一个数据类,这中间的转化过程主要分为两步:
您的问题点在于:
规范不是为了限制 xmind 和使用人原有的能力,而是为了方便抽离转化的普遍规律以及统一使用人的认知和习惯。
综上,您目前的问题虽说增加了归类和匹配的复杂度,但是并没有超出转化模型的能力范围,是完全能够解决的,编程是把抽象的逻辑信息化,在用例转化这个问题上,只要您能看懂文档 (更希望团队的所有人都能看懂),计算机也就能看懂、识别、转化,并不存在特别的限制。
首先讲讲 xmind 的优点,利于发散,快捷键生成不同节点比 excel 等编辑更顺畅,格式简单且方便收折...总体来讲编写和阅读体验会比传统的 excel 或者在线编辑更好,这个没什么疑问,所以 xmind 是首选。=> 一定要用 xmind。
关于强格式规范,虽说有固定解析规则,但解析规则其实并不多,因为测试用例核心要素本就不多,迭代名称取 root 节点,用例标题按照中间的路径生成,倒数两个节点解析为操作步骤、预期结果,比起以往其实只多了一个预期结果。大部分人不喜欢写预期结果,而不喜欢写预期结果的原因在于结果一般是常识性问题,所以预期结果不复杂时可以写得很简单 (例如 “执行成功”,“数据展示 ok”),当然前提是操作步骤和预期结果等算是常识时才尽量精简,如果复杂的话,还是写得准确些更好。说起是规范,但更多的是约定大于配置,这些约定基本是符合人的思考方式和常识的,并不是强制制定一个规范而让大家都来遵守。=> 规则不多,且符合常识和 xmind 使用习惯,推行时学习成本很低。
从规范上来讲,争议最大的点应该是操作步骤和预期结果是否应该写得很详细以及重复的内容是否应该写几遍,关于这两点,①有操作步骤和预期结果应该是下限,写得完整且准确应该是上限。每一个有追求的测试人员都应该守住下限,提高上限。测试用例是需要评审的,需要用于开发自测,产品验收的,需要后人接手的,如果没有下限,将会是灾难。②重复内容可使用父节点和概要归纳为一个节点,相对减少重复编写的内容。=> 问题看似很难,实际不难。
关于接受度,我个人使用上来讲非常能够接受,因为和我之前的编写习惯基本一致,反而因为规范,我写的用例比之前更加清晰明了;其他人至少基本没有不能接受的,也有一部分人觉得现在细节还不够,希望再增加一些规则 (例如优先级、编写人) => 基于上面的原因,目前接受度还行。
贴一份最近写的完全符合解析规则的用例吧,虽说内容相对简单,但是书写思路和复杂用例是一样的,用例编写难在设计,书写反而是简单的 (类似编程)。
现状和道理很多人都或多或少有感触,关键还是要如何去破局,转行转岗就不说了,就说说怎么在这条路坚持下去。
职业发展往上走,都是需要综合素质和影响力的,看似瓶颈,但实际上能做的还有很多。测开和开发、产品等岗位本质上都是一样的,运用自己的知识、经验,提供交付能力,只是侧重点略微不同而已。
说点实际的吧,我个人的话是预期在未来往两个方向努力:
瓶颈归瓶颈,真正遇到瓶颈的人,哪怕晋升再难,实际过得也已经很不错了,慢慢沉淀呗,总是有各个方面需要提升的。另外真有其他打算,也可以换条赛道。
这道题只是一道简单的字符串题,一个遍历就搞定,不涉及动态规划。具体的动态规划可以搜一下动态规划标签的题
我看了下内存占用,开 IJ WS PC DG 四个 IDE+chrome 几个网页 + 一个通讯软件的情况下就占用 16G 了,8G 不够用的