忘记了测试的目的了吧?
之前我们做过一个,是这样的。只做了 Android 端,只是一个检查工具,测试照常测试,系统会告诉你测试的代码层级的覆盖,你再看哪些没覆盖到,为什么没覆盖,需不需要扩大测试覆盖。
不要局限现在的工作,你的目标是牛逼的开发,然后做开发做测试都不差。
你对测开有误解,哈哈。我觉得比业务开发一般程序员要求高很多。
我们之前做了一个事情,只有 Android 端。就是统计变更代码的覆盖率,发现没有覆盖的,再针对去覆盖。如果是做成很自动化,再关联用例,那成本其实很高。所以能找出告诉你未覆盖的部分就很有用。
0 .
交付质量第一责任人是测试,所以线上 bug 就是测试的问题。有 bug 你为啥发现不了?bug 多可以不发布,或者作为已知问题通知相关人,但漏了就是测试的问题。找开发查原因以让测试将来看如何避免。但同时线上 bug 不应该纠结所有问题,只挑主要的,P0,P1,P2 的可以考虑,其他的就不要追究了。
这要是让测试背锅,天理难容。 有能力测试也插不上手。妥妥的运维。
女子整片天,牛!
归根到底是测试覆盖率不够,业务知识,产品系统的技术实现逻辑。多加强一下。
现在的 AI,比较多的帮助就是文案和作图吧?
不测功能,那就测 AI 的结果了。测试是需要确定的结果。
如果专职做压测,那你的目标是都测吧,测不完的情况下,再去讨论风险定优先级。但每个接口压测标准可能不一样。标准可以根据实际情况找团队来定。
敏捷测试是啥? 不是敏捷开发模式下的测试吗?
sh_myw23@126.com 先邮箱吧
计划了很久的在线 xmind 用例管理平台在团队的努力下终于上线了,目前已经成为测试团队日常必用工具之一
这个不错啊
已提交。
话说这个啥意思?您平时从事测试左移右移的内容有哪些(最少选 1 项)
前公司比较多。知道这些经历还能找到工作,你是很幸运的
1,功能兼容性问题,通过技术实现分析,找出可能与硬件有依赖的功能,比如录音,播放,或者与系统版本依赖的功能,比如有些技术低版本安卓系统不支持。
2,UI 适配问题,根据需求,比如固定缩放,或者大小不变自动适应,UI 设计实现特征(比如 hybrid or native)
3,用户群的机型分布
4,针对 1,2,将这些功能覆盖到主流厂商,主流系统版本,不同的典型的屏幕尺寸
1,公司内部
2,部分用户(500 左右吧)
技术工种,会技术再自然不过了。艺不压身,越多越好,机会也就越多。
我司科学家一直说,人工智能,没有人工,哪来智能。