• 打听一下绩效制定 at 2024年06月04日

    笑死,我们团队自从量化 bug 数量,以前一个问题如接口返回报文字段缺失,就报一个 bug。现在演化成了缺了多少个字段就报多少个 bug

  • 我入门技术,可以获得一份分工吗

  • 回归测试遇到的问题求助 at 2024年05月08日

    @ 白开水 pp #6 大佬已现身 ,直接问问

  • 回归测试遇到的问题求助 at 2024年05月08日

    有大佬:https://testerhome.com/topics/39516
    github:https://github.com/baikaishuipp
    初步实践过,很强,可以直接找出影响了具体的接口

  • 我们是分工的时候就交叉了,让你测不同模块的。

  • 我认为你说的这种方式会更加合理一些,会比我们现在的策略更加合理。我们只是单纯的采用了交叉,没有采用其他配套的方式:指定负责人,用例重视及完善的呢个等

  • 1、交叉测试适用场景,我也认为应该是功能比较稳定的时候才适用的场景。而我们现在是功能场景还在不断迭代的时候,就已经开始进行这种测试方式了。
    2、目前我们对测试用例的重视程度不够,没有内审,只有项目评审,项目评审的作用也没有被发挥出来。 属于是交叉测试学了样子,没学到里子

  • 感谢回复~
    我再次返回头来理解,checkList 为梳理测试点, 测试用例是具体执行步骤。
    我尝试在新的迭代版本中使用一下这个模式

  • 感谢讨论~
    checkList 由谁去编写,如何保证覆盖性这个问题 @ 沫沫 sir 确实说出了我心中的疑问 --【不过也会存在写的 checklist 有可能会过于通用,或者很多方面和具体的业务其实关联不上的情况】
    我更为关注的也是这个问题,我认为这是最基本的问题:既当你想推动一项新的变化事项时,如何去向大家证明新事项的有效性。
    当然,我考虑的问题会基于目前的项目情况:迭代频率大概 3 个星期 1 次,迭代范围广。且项目深度、广度都有,团队的测试人员很难有一个能够知悉全部业务细点的人存在。
    1、所以像第一点中您的回复,我认为在项目中需要一个对全局业务都能了解,并且能对版本迭代新功能都有了解的人来学 checkList,才能保证覆盖性。 如果不存在,可以由负责对应模块的测试人员来写。 那问题就来到了第二点(哈哈哈)
    2、如果每个人只熟悉自己的模块的时候,即使进行团队 checklist review 环节, 成员之间应该也很难发现彼此 checkList 覆盖不全的问题。
    需要说明一点的是,我所在的团队不是敏捷开发模式,我本人也未曾长时间呆过敏捷开发的团队,因此对这个流程是缺乏实际感受的。但看到您提出来实际的操作流程来看,这个 checkList 应该是行得通并且可持续的。
    因此还是想得到答案(哈哈哈):3、在楼主已有的执行记录来看,checkList 的验证性和遗漏点的比例是多少,有效性如何?
    另外还有一个疑问:checkList 的推广对团队成员的要求是啥,或者说 checkList 的推广是否存在局限性

  • 感觉是一个很好的规范用例,查漏验证点的工具。但具体实施起来有几点疑问:
    1、checkList 由谁去编写?(谁来保证 checkList 的覆盖性)
    是由负责对应模块的测试人员去编写吗? 如果是的话,我理解可能 checkList 本身也会有遗漏。理论上需要考虑测试点校验的时候,也相当与在编写测试用例雏形了
    2、checkList、用例都写完了,是由谁来进行检查,什么时间进行检查
    这个问题本质上还是在询问怎么去确保 checkList 结果的正确性。
    3、在楼主已有的执行记录来看,checkList 的验证性和遗漏点的比例是多少,有效性如何?
    4、可以分享执行这个 checkList 过程中需要注意的点吗