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