自动化测试
自动化测试
自动化测试是，把人对软件的测试行为转化为由机器执行测试行为的一种实践。
自动化测试的本质是先写一段代码，然后去测试另一段代码，所以实现自动化测试用例本身属于开发工作，需要投入大量的时间和精力，并且已经开发完成的用例还必须随着被测对象的改变而不断更新，你还需要为此付出维护测试用例的成本。
自动化测试的优势
- 自动化测试可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上；
- 自动化测试可以大幅提升回归测试的效率，非常适合敏捷开发过程；
- 自动化测试可以更好地利用无人值守时间，去更频繁地执行测试，特别适合现在非工作时间执行测试，工作时间分析失败用例的工作模式；
- 自动化测试可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试等；
- 自动化测试还可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽。
适合做自动化测试的项目
- 需求稳定，不会频繁变更。
- 研发和维护周期长，需要频繁执行回归测试。
- 需要在多种平台上重复运行相同测试的场景。
- 某些测试项目通过手工测试无法实现，或者手工成本太高。
- 被测软件的开发较为规范，能够保证系统的可测试性。
- 测试人员已经具备一定的编程能力。
自动化测试的范畴
自动化测试包括但不限于
- 测试环境的搭建和管理
- 测试环境的检查，监控和报警
- 测试代码的编译和测试构建
- 测试代码的静态检查和报警
- 测试用例的分发和执行
- 测试结果的保存与管理
- 测试报告的生成
- 测试优先级的建议
自动化测试的目标
错误的预期
1.不清楚自动化测试的目标，以及为达到目标所计划的投入
2.对自动化测试抱有不切实际的幻想型期望，认为自动化测试能够干很多活同时省很多钱
自动化测试的第一目标从来都不是节省测试的人力成本。
成功的自动化测试，作为软件测试的一种工具，从业务「最终效果」来看，应该是能够「节省成本」和「提高产品质量」的。
大部分的测试，所要做的是不是保证系统没有bug，而是保证在单位时间内测出大部分「不影响客户使用」，并「不被普通客户发现的bug」。
自动化测试不直接找bug，而是通过解放有经验的测试工程师的生产力，让其从重复的回归测试中解放出来，从事新的测试方法和测试手段的研究。
通过自动化测试解放出测试人员的时间和精力来间接地找到更多、更深层次的新bug，将产品质量再提高一个档次。
错误的观念
1.自动化应该是一种Service（Automation As A Service)，所有的测试人员和开发人员都应该可以自己很方便的去跑自动化
2.自动化测试的运行结果应该是可以自动分析的，占用很少的时间
3.自动化测试的成功率应该是要很高的（比如95%以上）
4.自动化应该是写一次，运行很多次，为什么花那么多时间还要去改自动化代码
自动化的成本与收益
自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
为什么要做自动化测试
需要先分析一下「手工测试」和「自动化测试」各自的特点：
- 手工测试，测试点广深度浅，需要准备时间少，效果卓越，后续工业化弱
运用场景项目初期测试冒烟，系统测试，验收测试
-
自动化测试，测试点窄深度深，需要准备时间长，效果相对一般，工业化高
兼容性测试，接口测试，单元测试，线上监控测试，性能测试，稳定性测试，回归测试
当前的自动化实践
从自动化测试的范畴来看一下我们当前的自动化测试状态
-
测试环境的搭建和管理
问题：执行环境（JDK，python，git，allure）需要手工搭建。
- 替换代码中win独有的相关库，使其可以在全平台上运行，方便使用Docker技术
-
测试环境的检查，监控和报警
问题：IPC设备信息 存放在代码data中，但是没有统一的管理与状态监控。
- 搭建「设备运维管理平台」统一管理设备状态，信息
-
测试代码的编译和测试构建
python代码不需要编译，使用CI/CD的方案（Jenkins）来进行测试的构建
-
测试代码的静态检查和报警
搭建Gitlab代码管理平台，使用Gitlab-runner的CI进行代码静态检查
-
测试用例的分发和执行
使用Jenkins参数化构建选择执行设备，集成JSON Editor进行执行用例选择。
-
测试结果的保存与管理
使用Jenkins流水线中的文件打包进行结果保存，直接在Jenkins上查看对应执行的报告
-
测试报告的生成
使用Allure进行报告的展示
-
测试优先级的建议
问题：暂无
-
根据某策略自动选择某设备需要执行的用例
测试
-
