ACP 及 DOM 认证,敏捷测试入门级,专注性能测试及测试设计。
公众号:CKL 的思考空间

  • 协议的学习技巧 at 2022年12月01日

    基本上我们不会去测试协议本身,只是使用协议。所以不太需要 “拿着 RFC 标准仔细去看看每个字段/字节/bit 的含义”。当然如果你是测试协议,或者自定义一些私有协议,那是需要去理解协议中的细节。

  • 问题 1:我司的实践就是代码走查,直接查看相关 entity 中对象的定义,lombok 用的规范,其实简单的等价和边界都不太会存在问题,反而更应该关注的是数据权限是否合理(是不是返回了太多的数据)、业务权限是否合法(是否有对应的功能权限),数据结构是否规范;

    问题 2:这个现在有蛮多的工具都有类似的功能,以体现自动化测试用例的 “智能”,个人认为意义不大,纯粹的是为了数量好看。

  • 培养一个完善的测试思维、编写一份简洁的报告;拥有承担一点责任的勇气,不断努力精进自己的测试能力

    自己的测试思维,制定针对当前迭代特性内容的测试策略,通过不同方式的测试建模,输出一份高质量的测试用例

    测试报告是测试人员工作的总结,也是测试人员具体的价值体现。一份好的测试报告至少应当包含以下几点内容:测试范围、测试结论、测试风险

    作为测试人,经过自己测试过的内容,应该承担一份责任,能够保证产品的基本质量。

    经过一批批测试人员的努力,不断地研究测试底层逻辑,提升测试能力。他们没有躺平在测试 “仅仅是点一下、看一下、验一下” 的认知中,而是通过提升自己的能力,通过单测覆盖、静态分析、接口测试、各类自动化手段,乃至于安全测试、埋点、监控、生产流量导入等等各种手段和方案,来提升质量,让产品的质量更加可靠,让测试的价值得以更好地发挥

  • 谈一谈今年的 TesterHome at 2022年11月30日

    还在坚持持续分享

    个人的感觉是,随着现在业务技术的复杂度在不断的提升,单靠测试技术的提升已经很难推动落了,不论是精准测试、全链路测试还是变异测试、混沌工程,都不是测试一个部门或者个人能够推动,没有好的技术基础设施,难有大的突破。技术的学习沉淀周期变长了。

    以前测试技术更多的是集中于测试本身,类似接口测试,UI 测试等,可以快速落地,出成果,分享也容易。

    再一个就是公司给大家尝试的机会变少了,大环境如此,新技术的不确定性高,ROI 低,团队的交付压力变大,保障业务是重中之重。

    其实, 在当下,我们可以更多的去思考如做测试本身的提效,在测试策略和测试理论上,下点功夫。这个在技术盛行的时候,容易被忽略。

  • 好像是,我改下,感谢指出。

  • 精准测试是一种利用技术手段对测试过程产生的数据进行采集存储,计算,汇总,可视化最终帮助团队提升软件测试的效率的方法。精准测试并没有改变传统的软件测试方法论,只不过是帮助我们将测试用例与程序代码之间的逻辑映射关系建立起来, 而这个过程则是通过算法和工具去采集测试过程执行的代码逻辑及测试数据,在测试过程加入采集过程,形成正向和逆向地追溯。

    正向追溯,开发人员可以看到 QA 执行用例的代码细节,例如用例执行过程中,调用具体方法与实现类,方便进行缺陷的修复与定位。

    逆向追溯,测试人员通过 release 前的增量代码快速确定测试用例的范围,极大减少回归测试的盲目性和工作量,提升 ROI,达到测试覆盖率最大化。

    精准测试看起来非常友好,随着技术的提升,推荐的用例也会越来越准确,但它有也存在不足的地方,主要有以下几点需要注意:

    基于手工测试的精准测试建立映射关系繁杂,如果需求改变频繁,用例维护以及之间的关系维护需要耗费大量时间精力。
    精准测试需要一定的自动化测试的覆盖,这样做起来更有意义,例如 api 自动化测试,如果本身用例过少,与代码之间关联关系不多时,变更代码后可能不会得出什么结果。

    项目生命周期需要较长,短期项目花费巨大精力开发和维护整套精准测试系统得不偿失。短期项目可以利用精准测试以 api 测试覆盖率作为衡量标准。不去建立繁杂的关系,只监控 UI API 测试覆盖率迭代时的变更来达到目的。

  • 测试先知是什么 at 2022年11月24日

    文章讨论的是这个预期结果怎么来,需要从哪些方面去确认,不仅仅是需求文档,而是需要考虑更多的内容。

  • 测试先知是什么 at 2022年11月24日

    不知道这个文章哪里刺激到大家了。。翻译了一个名词,加上了自己的理解而以。。奇怪。

  • ” 之前反馈给开发说慢的问题,开发就说,我保证我代码不报错就行,这响应时间长和并发量低,他也没办法 “
    --你说:如果你也能和老板这么说,那我也没意见,需求是老板提的,不是我提的。

    前期如果真的意识到性能问题,优化起来的收益是非常可观的。从 5 秒变 1 秒是相对比较简单的,从 1 秒变 500 毫妙,那才麻烦。

    加油。

  • ” 现在领导就想知道我们平台是否可以支撑住 30-50w 的设备去使用,而且功能不分大小,起码每个模块的功能都能支撑的住这 30w 用户去发生多次事件 “

    --大概可以猜测是总量为 50W,那么可以根据每个模块大概的比例,分配出每个模块的用户量(没有必要每个模块都压到 50W,性能测试也是有成本的),比如你们有 ABCDE5 个功能,其中 ABC 占 80%,DE 占 20%,那么 A 功能大约就压到(50W*80%)/3 的量级就可以了。

    测试步骤:测试目标明确了,那就好办了,直接上压力,不需要逐步加压(如果性能真的太差,比如直接压挂了,或者响应时间太长,再逐步用二分法减压)

    等每个模块的性能问题解决的差不多了(TPS 和响应时间大家都能接受了),再考虑全系统加压

    重点关注系统分发功能的性能、资源互锁的问题

    最后再做稳定性测试(一般的做法是 80% 左右的峰值量去压)

    铺底数据的问题,建议越多越好,直接按 30W 的量去准备就好,SQL 或者接口都行。

ACP 及 DOM 认证,敏捷测试入门级,专注性能测试及测试设计。
公众号:CKL 的思考空间