测试环境搭建

装置JDK 8https://www.java.com/zh-CN/do... 上下载Java 8点击装置在.zshrc 中设置环境变量在终端输出source .zshrc 让配置失效export JAVA_8_HOME="/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home"export JAVA_HOME=$JAVA_8_HOMEexport PATH="$PATH:$JAVA_HOME"export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar装置Android_SDK新建 Android 文件夹$ mkdir ~/Library/Android在 .zshrc 中设置环境变量export ANDROID_HOME=/Users/xxx/Library/Android/export PATH=${PATH}:${ANDROID_HOME}/toolsexport PATH=${PATH}:${ANDROID_HOME}/platform-toolsexport PATH=${PATH}:${ANDROID_HOME}/tools/binexport PATH=${PATH}:${ANDROID_HOME}/emulatorexport ANDROID_SDK=${ANDROID_HOME}export ANDROID_NDK=${ANDROID_HOME}/ndk-bundle在终端输出source .zshrc 让配置失效$ source .zshrc下载 android-sdk$ brew install android-sdk查问sdk有哪些包反对$ sdkmanager --list安装包$ sdkmanager "build-tools;31.0.0"$ sdkmanager "platform-tools"装置网易MUMU模拟器https://mumu.163.com/mac/inde... 下载最新模拟器连贯模拟器的两种形式adb connect 127.0.0.1:5555adb kill-server && adb server && adb shell

【转载请注明出处】：https://blog.csdn.net/huahao1989/article/details/107827383 在咱们理论的我的项目迭代过程中，基本上会经验过的几个问题： 测试用例不标准，有些甚至没有测试用例文档文档随集体爱好轻易应用，word、excel、xmind...没有专门的人去治理这些文档，工夫长了就失落了测试用例和测试脚本很凌乱，根本都是测试集体保存以前的公司，包含当初的公司都自研过本人的测试平台，然而都不尽人意，直到看到MeterSphere让人眼前一亮，产品的厂家和JumpServer的厂家是同一个，比拟靠谱，从公布到当初差不多7个月的工夫，star曾经超过了1.4k，十分沉闷。 为什么要继续测试?传统 QA 团队和实际难以满足数字业务的需要 数字业务的要求缩短交付工夫快节奏交付从品质保障到品质帮助传统 QA 的不足之处人工测试耗时长“部门墙”和“交接”依然存在Bug 发现和解决老本高什么是 MeterSphere ?MeterSphere 是一站式的开源企业级继续测试平台，涵盖测试跟踪、接口测试、性能测试、团队合作等性能，兼容JMeter 等开源规范，无效助力开发和测试团队充分利用云弹性进行高度可扩大的自动化测试，减速高质量软件的交付。 整体定位继续测试是企业 DevOps 实际中的关键环节 测试跟踪 测试用例治理树状用例治理构造在线编辑用例疾速导入用例测试计划跟踪基于已有用例发动测试在线更新用例执行后果自定义测试报告模板接口测试 测试脚本在线编辑测试内容反对参数化测试反对断言、变量提取通过浏览器插件疾速录制测试报告主动生成测试报告屡次测试后果比照查看申请及响应详情测试报告内容导出性能测试 测试脚本齐全兼容 JMeter 脚本在线调整压力参数分布式、多平台测试资源池通过浏览器插件疾速录制测试报告主动生成测试报告屡次测试后果比照丰盛的报告展现详情测试报告内容导出团队合作 多租户反对多级租户体系反对多种租户角色租户资源隔离测试资源管理性能测试资源池测试报告模板第三方零碎对接MeterSphere 的劣势全生命周期 可能笼罩从测试计划到测试执行、测试报告剖析的不同阶段自动化 & 扩展性 反对接口和性能的自动化测试，可充分利用云弹性实现超大规模的性能测试继续测试 可能与继续集成工具无缝集成，撑持企业实现测试左移团队合作 反对不同规模的测试团队，小到几个人的测试团队，大到数百人的测试中心技术栈后端: Spring Boot前端: Vue.js中间件: MySQL, Kafka基础设施: Docker, Kubernetes测试引擎: JMeter整体架构 Frontend: MeterSphere 的前端工程, 基于 vue.js 进行开发Backend: MeterSphere 的后端后称, 基于 Sprint boot 进行开发, 为 MeterSphere 的性能主体Chrome plugin: 浏览器插件, 录制 web 拜访申请生成 JMeter 脚本并导入到 MeterSphere 中用于接口测试及性能测试Node controller: 为性能测试提供独立节点类型的测试资源池, 接管来自零碎的性能测试工作, 动静的启动 JMeter 容器实现性能测试MySQL: MeterSphere 我的项目的次要数据均存储在 MySQLKafka: 接管 JMeter 产生的性能测试后果数据Data streaming: 从 Kafka 中获取性能测试后果数据进行解决后存入 MySQL 数据库Docker engine: 为 Node Controller 提供 JMeter 容器运行环境各个组件间的关系可参考下图 ...