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

项目-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删除，可以做新的业务。

• 还没有人评论，欢迎说说您的想法！