郑州易盛信息技术有限公司·测试中心·效能组
主要从事自动化测试平台开发、虚拟化及容器云相关技术,工程效能领域实践探索。
E-mail: diyuchen@esunny.cc 欢迎交流
Gitee: https://gitee.com/dyc289686387/electron-quick-start-framework(有段时间没更新了)

  • 测试左移考虑的点 at 2022年09月21日

    开发->测试->运维 以测试角度来说,左移我觉得就可以是向开发靠近,关注开发关注的内容,以测试人员的视角提出独特的观点,举例来说:开发实现了一段前端代码,开发人员做 review 的时候也觉得没什么问题,但测试同事可能更关注代码的可测试性,会提出一些意见(举个不一定恰当的例子:UI 自动化的元素定位有多种方式,开发如果给元素加了 id,后期测试写自动化会更容易一些,直接 findById,也会比较稳定,开发的这个 id 可能完全没有什么业务作用,纯粹是为了给 UI 自动化定位用的,这就是可测试性的一个例子)。

    测试左移,可以以测试人员的视角有独特的关注点

  • 测试左移考虑的点 at 2022年09月21日

    架构设计是否合理(一般适用于新项目),帮开发写单测(?有待讨论),代码扫描,参与 CodeReview,质量门禁与质量卡点,每次交付给测试进行系统测试之前,用自动化跑一遍作为冒烟(如果有自动化的话),能做的事挺多的

  • 我们公司内部环境还算不错:
    1.领导都是懂行的人,不会有外行指挥内行的情况,知道这个东西有价值,也愿意投入资源让我们尝试
    2.之前有成功的案例,于是大家现在也都愿意去当这个种子团队,形成了良性的循环了,持续积累

  • 对落地过程深有体会,概括来说:
    内部有痛点,外部有方法,取其精华去其糟粕,进行 “本地化” 改造。
    综合考虑人员能力水平,项目开展方式,选择种子团队,自动化(非自动化测试,而是将方案以平台或者脚本方式提供)以降低门槛,保姆式的手把手教学,练习并持续的改进方案,与用户(测试团队)共同获益,种子团队试点成功,进一步向其他团队推广,种子团队失败,分析问题,重头再来。整个过程会持续 1-2 年,对推动者来说是极大的考验,对团队来说是肉眼可见的成长,绝非一朝一夕之力,浅尝辄止之能。

  • 具体正确性的定义是什么呢?如果是满足某种业务规则的话,你也可以写个脚本读库然后校验

  • 数据库 + 文件系统。数据库保存元数据,文件系统保存具体的用例内容。采用这种结合的方式既方便平台管理,也方便实际使用。

  • 两方面看待:
    1.可能确实是和 “具体的测试” 工作无关,但是是质量保障的动作,往往测试人员是熟悉产品的,可能比开发人员更合适,之前听过某老师讲过,测试可能更适合做实施环节,因此编写手册和答疑也似乎合理
    2.确实是一些无关工作,那就不发表简介了

  • docker exec 进去的时候的 root 是 no-login 的 shell ,你进入容器后再 su - root 一下试试,应该就有了,或者把容器内 ssh 服务启动,22 端口对外映射出来,直接通过 xshell 等工具 login 进去,就也是 login 的 shell 了

  • "但对于维护项目来说,测试覆盖点都是增量或修改需求点,那未覆盖的处会很多,那分析测试遗漏就不好搞了"

    1. 可以考虑采用增量的方案,只关注本次的变更是否都覆盖到了,虽然 “覆盖率高” 和 “质量好” 画不了等号,但增量(或者说变动代码)的覆盖率低可能说明确实存在遗漏的场景没有执行到,可以进行分析并决定要不要补充。
    2. 给测试人员及相关人员提供信心,有时候信心也是一个关键的要素,覆盖率高比覆盖率低总是要多一些信心,多一点信心总是好的。

郑州易盛信息技术有限公司·测试中心·效能组
主要从事自动化测试平台开发、虚拟化及容器云相关技术,工程效能领域实践探索。
E-mail: diyuchen@esunny.cc 欢迎交流
Gitee: https://gitee.com/dyc289686387/electron-quick-start-framework(有段时间没更新了)