热爱软件测试,《软件测试之魂》《软件测试工程化实战》

  • 有理论,如果有案例分享会更好理解,例如:“质量把控能力—从用例设计转变为测试策略”,具体指哪些方面的用例设计转变为测试策略,因为正常流程上是拿到需求,与开发、需求同事一起讨论需求,一起理解设计实现,然后设计测试方案(过程中需解决测试策略)问题,即现在条件、环境下,如何测试(如何打仗),什么时修测试哪些用例,哪些暂可以不测,等。

  • 用例设计方法怎么用? at 2022年08月06日

    1、分析用户场景,可采用 5W1H 模型展开(理解需求对用户的价值,把握核心操作场景)
    2、业务需求细节分析,可用 viso 画图(流程图,IPO 图都可),如业务操作流程(业务流)
    3、梳理数据流,需理解软件的设计实现,例如:楼主提到打开 开关,用户是一个点击操作,此时对应软件可能是一个消息,此消息触发后面的代码,此时是否有数据的变化,如把背后的配置文件给改变了;弹窗提示有哪些信息,这些信息内容从哪里读取,如是否增加了字符串,这些字符串来自哪里,如果有多语言,其他语言的显示是否正确?弹窗存在与用户的交互吗,交互的数据,如用户输入后的数据回显,是保存在什么地方呢。
    抓住业务操作流、数据流,再以各节点为分支展开分析,可得出可能对系统其他模块的影响(其输入、输出与其他功能的关系)。

  • 这个没有定论,不同公司不同团队需求不同。个人理解测试经理的能力
    1、技术上:精通业务(很重要),测试技术上有某方面强项,如测试策略,测试分析与设计,测试开发等都可,有自已擅长的一面
    2、结果上:过往业绩优秀,能扛事(做事靠谱)
    3、管理上:善沟通,能凝聚团队力量
    4、影响力:能服众(有技术精通的一面,其他方面也有懂一些,正能量,抗压等)

  • 这个主要要看当下团队为什么要制定一些开发规范,是想解决哪些问题,测试人员与开发人员整天在一起战斗,需要总结一下,例如:
    1、开发发的版本质量不高,过去曾遇到哪些问题,是否要增加开发人员的 smoking test,最好能集成到版本构建中自动执行,等。
    2、是否存在开发人员悄悄改代码,导致测试人员漏测情况,如有需要纳入规范
    3、增加单元测试,用什么工具,还是自研框架,是否要纳入代码审计中,等都可纳入规范中

  • 楼主坚持不来的原因是什么呢,需要解决一下,如是目标有问题么?(内因),外因太多?其他情况不太清楚楼主的实际情况,不好建议

  • 复测高手的亮点:
    1、利用生产端用户真实环境生成的数据造数,
    2、录制生产端用户行为回放
    3、理念不错

    对原来自动化测试(脚本化功能测试用例)是一个改进,但也存在以下问题:
    1、真实环境下的数据收集需要时间,及用户量,回归测试此时才开展是否有些晚(因为版本已上线)
    2、不太可能代替原来经验设计的用例,因为生产端的用户场景也只能是一部分(重要的一部分)
    3、复测高手假定的被测对像需要比较稳定或长久性产品

    建议:
    1、复测高手除了收集生产数据、用户行为,是否可进行用户大数据分析,导推需求测试,及需求挖掘。
    2、是否有成功应用的业务领域,分享一下

  • “最后还有一点,测试人员的价值体现在什么地方呢?有一篇文档中说的很好,原话我记不太清了,大概意思是:测试人员的价值体现在发现设计和编码人员思维狭隘的地方,帮助他们修正这个期间产生的错误,提出自己的建议,还有提前识别可能的风险和问题,预防缺陷的产生。”
    --原话:“软件测试的真正价值并不体现在代码中找出了多少缺陷,而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足”,出自 快速算法作者(也是图灵奖获得者)托尼.霍尔

    这句话我也想过很久,咱们测试人员要做到,不是那么容易,但确实是有价值,可以作为大家努力的方向。要在这方面有效果,建议:
    1、精通业务,这是咱们测试的强项,当开发人员更改的方案未考虑全时,可以给出建议,补充局限;
    2、熟悉设计框架,开发的更改一旦不全面(影响分析不足等),例如:开发人员更改了 CBB(平台组件)代码,但未考虑影响哪些产品,可以给出解决方法的影响;
    3、常去分析、积累经典 bug 原因,如内存 leak,数组越界,数据精度,数据库读写冲突等,后面工作中遇到同类问题可以快速识别开发人员代码中埋下的坑

  • 多语言检测工具实践 at 2022年07月31日

    比较赞同
    @Jerry li 的一些观点,楼主提供的解决方案 估计并没有从根源上解决问题。多语言字符串的管理,是否可以独立出来,如同下图:

    此字串需通过转换工具转换成多语言目标文件,前端网页可通过配置或接口调用这些文件中的内容,这样每增加新功能的字串可以直接修改此表,软件的前后端实现逻辑不用改变。降低测试与运维人员成本。具体实现细节@Jerry li 也有提到。

  • 看了楼上大家的回答,据我们曾经的失败与稍有成功的经历,建议如下:
    1、与现在的领导(主管)达成一致,有目标及具体计划,并得到支持,如:个别对技术有兴趣的同事,争取一点资源跟你一起做架构的开发(需要你的指导),后面维护的事,他可以帮你,也为这道框架持续下去打下基础
    2、根据团队的情况,采用低代码开发测试用例的框架,并把用例转化的工作纳入同事们的 KPI(需领导支持)。前提:你这边作指导,如:带头写一个小模块的用例脚本,并运转起来,让同事们看到效果(好处)
    3、主动积极推广:建议主动领某项目的小业务进行功能测试,需与业务同事打成一片,更深入了解他们,为自己的推广及自动化优化工作作好铺垫。(这一点对你来说很重要,也只有这样你才不会偏离方向,技术永远为业务服务才有价值,也为自己争取更多的可能)

    让同事们看到效果(好处),例如通过自动化发现一些业务测试难于发现的问题,并让大家有成长,没有人愿意拒绝成长的,:)

  • 1、首先,不知理解是否正确,应属于 APP 与 SDK 之间交互如何解藕的问题,其实站在任何一方而言,都想在主干上一直往前跑,然后随时可 release 版本。但对于宿主 APP 方,是否清楚 SDK 频繁变更的所有信息,及对自己的影响。如果不清楚,那么肯定被动。此时,看是否自动化一些用到 SDK 调用的场景用例,采用 2-8 原则,把风险业务优先保证,从而提升测试的效率。
    2、其次,SDK 的质量,建议组织相关人员一起讨论,总会有一些办法的

热爱软件测试,《软件测试之魂》《软件测试工程化实战》