如果给一个可以做自动化的项目,你要怎么做自动化?

项目-8大模块-2000左右用例数

1.熟悉业务==需求文档/手工测试/产品聊,了解模块之间的关系/测试人员

项目目前的一个阶段、棘手的问题(不仅写自动化代码,能帮别人用代码解决繁琐的问题)。

2.分析----系统中哪些模块比较适合做自动化、哪些模块不适合

  • 历史稳定性,功能的复杂性(功能太过于复杂就不适合做自动化,从相对简单的模块入手)
  • 核心模块(每个系统都有自己非常核心的模块)
  • 使用频率模块,哪一个模块bug率目前偏高(这个模块经常出历史功能的问题)
  • 测试团队、产品团队中与用户接触的比较高的人开个会交流下,看下哪个模块需要做比较高的维护工作
  • 筛选了2个模块 400个测试用例
  • 如果是接口,就看接口有多少个,每个接口要设计多少个用例
  • 接口自动化用例需达到80-100%

「先分析在哪一个模块来做,能够得到最快的产出比,能够最快的看到效果。」

分析之后,预估先做1个或者某2个模块的自动化测试。

3.功能测试===400个==从功能测试用例中去筛选自动化用例==核心模块的核心功能、主流程、主功能点==140个用例==用例评审(产品、测试、测试经理开会交流进行决定)

先对模块做用例设计,如果你参与了手工测试过程,就了解这个项目的模块。

因为目前不知道项目要做多久的时间,人员安排,阶段安排怎么算,具体也不了解这2个模块的具体情况,也不知道这2个模块大概有多少用例要做自动化测试,不知道用什么框架去做自动化测试。所以测试计划和方案可以放后。

web自动化最大的目的就是负责主流程,异常流程分情况,如果它容易实现没有太大难度就可以做,如果异常场景比较极端,条件准备比较复杂,就可以不去实现它的自动化。先把主流程实现,后期酌情增加异常场景。

做自动化测试需要领导支持的,不然他给你大量的功能测试的工作。如果就你一个测试,就根据上面的3点,自己进行筛选,做完和上级领导汇报一下,告诉他为什么这么选,选出来的结果是什么。领导肯定会问自动化测试计划。

4.自动化计划

「自动化类型:web/api」

1.写清楚前提,为什么选择了这2个模块,为什么选择了这140个用例。

2.告诉领导,还要花1-2周时间进行「框架选型:」 如果是自己一个人,自己写代码顺手就写代码实现,如果熟悉其它的框架就用其它的框架。如果团队有其他人,别人的水平不如你的时候,就要考虑成本代价,如果都用写代码,例如我很懂写代码实现自动化,他们却不懂,他们做不起来怎么办呢?「框架选型主要考虑的是团队人员的水平。」 如果比你差太多了就不要选代码了,就选个容易上手的框架。

「团队人员」是多少:如果就自己,就写1,如果还有人辅助你,就写2

「1-2周时间里需要搭建框架」(准备好整体的一个结构,什么层放什么东西),定规范(在哪写测试用例,怎么设计测试用例,断言里面要怎么设计,有些全局框架方面的内容,其他自动化测试人员发现了可以告诉我,我来优化,其他自动化测试人员只改他们能改的部分就可以)

「时间规划:」 用例编写。2个半月。

「效果:」 评估下覆盖率是多少-用例通过率(如果通过率只有40%,那么就没必要去做自动化了)-跟项目测试进度结合

自动化计划在正式做之前,应该做个PPT或者excel文件,找个机会跟领导讲大概的计划,这是初期的计划,后期根据情况肯定有变动,就是让领导知道你有自己的计划。

可以写完一个模块先用一个,发一次测试报告,不可能全部的自动化测试用例写完再发测试报告。

140功能用例数/平均每天做的web自动化用例数=天数

接口功能用例数/每天做的功能自动化用例数=天数

每个人写的测试用例,用例粗细度是不一样的,所以导致每个人每天写的自动化用例数不一样。

以上4点,接口自动化和web自动化前期准备工作是一样的。具体根据业务场景复杂度,公司项目规模等情况而定。

怎么搭建公司自动化框架?

我们平时做项目,大体框架都是一样的(常用的配置文件,日志文件等都封装成模块),需要套不同的业务场景,进行优化细化。如果换了项目,就把原来的业务上的case删除,可以做新的业务。

愿你我相遇,皆有所获!