自动化测试用例与手工测试用例是否存在强依赖?能否优雅化解耦?

各位大佬,大家好。

目前我正在新公司组建测试开发团队,第一个目标是先完成组内的自动化测试,在回归测试方面(目前迭代紧张,业务组无时间回归老功能)发挥重大作用。

但是目前情况是组内没有体系化的手工测试用例,目前的形式只是写了各种xmind脑图,很分散并且可读性很差,很难直接进行自动化用例转化。所以目前面临着抉择。

  1. 组织业务团队进行手工测试用例的沉淀,可以继续借助xmind脑图形式,然后通过类似xmind2testcase这类工具转成xml文件,然后再导入到testlink中进行测试用例的沉淀,然后业务测试人员基于testlink的手工测试用例对应翻译成自动化测试用例,这样的话从测试场景到自动化覆盖率都比较好统计。

  2. 测开人员翻译业务测试人员的手工测试用例。

  3. 无手工测试用例,直接测开人员写自动化测试用例。

1,2方案都会面临的问题是,业务测试人员的负担会比较重,势必会影响接下来的迭代测试。同时1方案对于业务测试人员的代码能力也是个挑战。
3方案对于测开人员的业务能力是个挑战,同时覆盖场景很难覆盖全,自动化覆盖率很难统计。

大家能分享下经验吗?在这块有什么好的建议,期待大家的回复。

这条路我之前的公司用过,差点没把业务测试工程师搞离职。光其中枯燥的工作就已经让人崩溃了。

测试人员的手工测试用例,大部分都是写的比较粗糙,没有严格的数据上下文的。

你反馈的问题也是存在的。正确的做法还是先回归到你的当下top矛盾上去解决。

老功能回归不搞定,你是没法腾出人力去做其他的改进的。所以建议是先让测试开发工程师,去覆盖回归流程,用例先让他们自己写。等覆盖到30%左右的时候,已经可以带来一些基础保护作用的时候,再开始跟已有的业务测试用例结合,以深入业务。

我倒是不担心你什么时候跟业务测试结合,更担心的是你怎么做自动化。目前很多团队是搞不定自动化的。所以你最好从最简单的接口测试开始去做。然后逐渐的保证基础功能,搭建起来最基本的自动化回归体系。然后再逐渐的拓展到UI自动化与端到端自动化测试。

哈哈,确实是,这块真有可能有把业务测试人员搞离职的风险,那我还是不触及这个雷区了。

谢谢思寒大佬的详细回复,您说得很中肯,很有道理。我这边关于回归测试是这么想的,您看下是否可行。

测开人员在最开始写自动化的时候先开展UI自动化,只覆盖高优先级以及经常发生问题的区域,主要针对以下几点来开展。

  1. jira中记录的发生问题比较多的重灾区模块
  2. 参考部分冒烟或是P0级别的测试点

接下来针对一些细节进行一些接口自动化来校验更多细节方面的场景。这时候也可以让一些业务人员参与进来,进行一些深业务场景的自动化用例编写。