测开无非写写自动化,写写小工具(这些都不需要很强的开发技能)
然后写写测试平台(各种 bug,难用的要死,无非是在网上抄一个后台管理界面,然后用来增删改查,主要是为了 KPI,还不如直接买,市面上已经各种轮子了)
然后突然发现 精准测试 可以是 侧开的一个发展方向
嗯,有点意思
精准测试是一种利用技术手段对测试过程产生的数据进行采集存储,计算,汇总,可视化最终帮助团队提升软件测试的效率的方法。精准测试并没有改变传统的软件测试方法论,只不过是帮助我们将测试用例与程序代码之间的逻辑映射关系建立起来, 而这个过程则是通过算法和工具去采集测试过程执行的代码逻辑及测试数据,在测试过程加入采集过程,形成正向和逆向地追溯。
正向追溯,开发人员可以看到 QA 执行用例的代码细节,例如用例执行过程中,调用具体方法与实现类,方便进行缺陷的修复与定位。
逆向追溯,测试人员通过 release 前的增量代码快速确定测试用例的范围,极大减少回归测试的盲目性和工作量,提升 ROI,达到测试覆盖率最大化。
精准测试看起来非常友好,随着技术的提升,推荐的用例也会越来越准确,但它有也存在不足的地方,主要有以下几点需要注意:
基于手工测试的精准测试建立映射关系繁杂,如果需求改变频繁,用例维护以及之间的关系维护需要耗费大量时间精力。
精准测试需要一定的自动化测试的覆盖,这样做起来更有意义,例如 api 自动化测试,如果本身用例过少,与代码之间关联关系不多时,变更代码后可能不会得出什么结果。
项目生命周期需要较长,短期项目花费巨大精力开发和维护整套精准测试系统得不偿失。短期项目可以利用精准测试以 api 测试覆盖率作为衡量标准。不去建立繁杂的关系,只监控 UI API 测试覆盖率迭代时的变更来达到目的。
天花板不是早日赚够钱,退休去环游世界吗?
精准测试是啥
天花板是财务自由,把老板开了 哈哈哈哈
精准测试,不知道又是哪个大厂的人才提出来的新名词,今天开会刚讨论这个。
我的结论就是,这玩意不如一个经验丰富的测试自己评估来的准。做的不好的投产比可以干成负数,毕竟一个推荐不准确漏测上线那就是事故了。
如果测试效率可以提升,那么自动化就能完成 90%,其他的都是面子工程。
精准测试是一种利用技术手段对测试过程产生的数据进行采集存储,计算,汇总,可视化最终帮助团队提升软件测试的效率的方法。精准测试并没有改变传统的软件测试方法论,只不过是帮助我们将测试用例与程序代码之间的逻辑映射关系建立起来, 而这个过程则是通过算法和工具去采集测试过程执行的代码逻辑及测试数据,在测试过程加入采集过程,形成正向和逆向地追溯。
正向追溯,开发人员可以看到 QA 执行用例的代码细节,例如用例执行过程中,调用具体方法与实现类,方便进行缺陷的修复与定位。
逆向追溯,测试人员通过 release 前的增量代码快速确定测试用例的范围,极大减少回归测试的盲目性和工作量,提升 ROI,达到测试覆盖率最大化。
精准测试看起来非常友好,随着技术的提升,推荐的用例也会越来越准确,但它有也存在不足的地方,主要有以下几点需要注意:
基于手工测试的精准测试建立映射关系繁杂,如果需求改变频繁,用例维护以及之间的关系维护需要耗费大量时间精力。
精准测试需要一定的自动化测试的覆盖,这样做起来更有意义,例如 api 自动化测试,如果本身用例过少,与代码之间关联关系不多时,变更代码后可能不会得出什么结果。
项目生命周期需要较长,短期项目花费巨大精力开发和维护整套精准测试系统得不偿失。短期项目可以利用精准测试以 api 测试覆盖率作为衡量标准。不去建立繁杂的关系,只监控 UI API 测试覆盖率迭代时的变更来达到目的。
我们去年搞了一套,完全处于 KPI,无实质用处,除了给领导看下,这个是测试的产出,并无他用,平时也没有任何用
基于开发每次提交代码,查看修改了哪些类和方法,然后反推到具体影响到的是哪些接口。我们的接口自动化用例之前就已经做了一部分,然后根据每个接口通过 tag 区分,这样接口修改以后根据对应的 tag 去匹配到接口的自动化用例,然后再触发 Jenkins 上的接口自动化用例执行
明白了,这和我们讨论的不是一种类型。我们这测试想要的是功能测试用例的推荐,我觉得是不切实际的,即便技术可行,前期录制用来映射关系也非常消耗时间
天花板不是有花不完的钱吗
我最近还在想,如果把开发变更代码和功能联系到一起。
是不是能帮助测试快速定位范围。看完最佳回复才知道原来这叫精准测试啊!
当前做法还是开发改修完或者新功能开发完在 PBI 上写上影响范围。
尽管如此问题在于开发人员的描述和测试人员的理解容易出现分歧,结果往往是主观的非客观。
自己实现了代码改动影响范围分析的工具,用 python 语言实现的,可以看看: https://github.com/baikaishuipp/jcci