一、初级测试工程师工作流程：（介绍黑盒测试）
老板-接了一个项目-实现项目------项目交给【团队负责人】---
团队成员：
项目负责人： 整个项目的管理者
产品经理：负责业务
交互设计：功能的流程和动画效果
UI设计师：设计界面样式
前端开发：开发web网页，小程序等
app开发：开发手机app软件，分安卓开发，iOS开发，鸿蒙开发
后端开发：后台数据管理开发，提供接口
测试员：测试功能并验证
其它
阶段1：需求沟通、完善
--产品经理--对接这个项目功能（功能称为【需求】），产品经理与（客户，用户等）沟通----产品文档PRD（沟通笔记）-----
⚠️--产品完成“产品交互“文档（功能的大致流程）---
-- 团队开始讨论这个产品“需求”---即“需求”评审、讨论（功能沟通、产品功能沟通）----开会讨论--- “需求会议” -
（这个功能是否合理，开发角度实现功能有没有难度【1 有技术难度如何解决 2 解决不了就换一个方式实现功能】）---
需求定义： 需求概念可大可小，大到一个小项目，小到修改一个文案（文字）都可以是一个需求，同一个月可能同时需要开发多个需求。
周期
一个需求的周期多长时间：
1、0-1初始开发版本: 第一个版本时间较长1-3月个发布一个v1.0版（version 1.0）。
2、项目迭代需求：正常一个需求 2-3周 发一个版本（1.1版本，），个别微小需求修改简单的<=3天左右
3、修复版：线上项目出现问题，紧急修复之后的版本1.1.1 fix ，时间1-2天
测试员需求会议关注：
- 深刻理解需求: 功能描述是否模糊或难以理解的部分、业务流程、输入输出及约束
- 评估需求的可测试性： 验收标准，确保可量化验证
- 识别潜在风险： 功能复杂性、兼容性、性能等风险
- 提供测试建议：明确测试类型（功能、性能、安全等）及优先级
- 记录与跟进：记录会议中的疑问、决策及变更，确保后续测试计划与用例设计有据可依
阶段2：编写测试用例
注意：此时设计师应该再设计UI界面。。。
了解业务，功能的“实现步骤” -【准备测试用例】---编写测试用例
（2.1）测试用例编写方法
- 等价类划分法 : 输入数据划分为有效（成功）/无效（失败）
- 边界值分析法: 测试边界值（如输入框允许1-10000时，测试0、1、9999、10000、10001）
- 场景法（流程图法） : 流程复杂的功能先画好流程图，按照流程图步骤写用例
- 判定表法：多条件交叉验证的场景（如登录功能需验证用户名+密码+验证码的组合）
（2.2）测试用例填充具体内容
- 用例编号：按规范命名（如CRM-ST-001）6
- 优先级：核心功能标为高优先级（如登录）6
- 预置条件：如测试支付前需配置支付渠道6
- 操作步骤：需详细到具体输入和点击（如“输入带单引号的用户名”）26
- 预期结果：必须明确具体（如“弹出密码错误提示”）
- 测试结果：是否成功？
（2.3）测试用例表（示例）
| 用例编号 | 优先级 | 预置条件 | 操作步骤 | 预期结果 | 结果 |
|---|---|---|---|---|---|
| 1 | 高 | 用户已注册并拥有有效账号 | 1. 输入用户名（带单引号，如'admin'） 2. 输入密码 3. 点击“登录”按钮 | 1. 弹出密码错误提示（如“密码错误，请重试”） 2. 登录失败，返回登录页 | 失败 |
| 2 | 中 | 支付渠道已配置 | 1. 选择商品 2. 点击“支付” 3. 选择支付方式（如支付宝） 4. 确认支付 | 1. 跳转至支付页面 2. 支付成功后返回订单详情页，显示“支付成功” | 成功 |
| 3 | 低 | 用户未登录 | 1. 点击“我的”页面 2. 尝试查看个人资料 | 1. 弹出登录提示（如“请先登录”） 2. 跳转至登录页 | 成功 |
阶段3：开发阶段
--- OK ----进入开发阶段--- 完善“测试用例” --
阶段4：测试用例评审
- “
测试用例评审“（步骤是否合理，缺陷）----（空档期：进一步熟悉业务）--开发人员继续：开发阶段---
阶段5：提测
---- 开发完成---开发自测”测试用例“（开发验证所有的测试用例 test case 已完成）---【冒烟测试（Smoke Testing）】是软件测试中的一种快速验证策略，主要用于确认软件版本的基本功能是否正常，以决定是否进行后续深入测试---最后“提测”：提交测试验证
阶段6：测试（测试环境验证）、bugfix（bug修复）
-- app/软件 --安装--- ”测试“ 环境 （test 环境通常只在公司环境和公司员工使用，不对外）--
--测试员验证功能---发现问题，称：bug ---- 提交（也叫“上报”）这个bug ---bug单--
Bug单 包含内容：
- 问题标题：比如登陆失败
- 问题等级：严重程度 p0：很严重、p1:严重、 p2:一般、 <= p3:低
- 问题复现步骤
- 问题截图，录制视频
- 数据：相关的某个接口的url - json数据
- 修改者：对应的开发修复人员
-- 开发修改bug- 开发修改完成提交代码-- 测试安装新的 ”修复包“ -- 验证这个bug是否修复（”回归“一下）--
Bug单 主要状态：
- 待修复
- 修复中
- 已修复
已验证（测试验证OK）
--- 所有的bug都解决（循环修改-修复-验证 步骤）---验证OK---
阶段7：验收
-- ”产品验收“（产品经理主要验证功能是否完整），
-- ”UI验收“（设计师和交互师 主要验证 动画效果、界面UI细节、像素，位置，图标 等是否正常）-
-- 他们都验收完成-------准备发布上线（正式对外）----
阶段8：接口发布（上线）
--接口上线--10号晚上（凌晨1点）发布”正式“接口--
阶段9：测试（正式环境验证）
安装正式环境的软件-验证”正式环境“（release环境）功能 ----把一些重要的步骤都要回归一遍---OK--
阶段10：软件发布（上线）
--”发布“软件----【1、官网软件直接更新下载Download地址 2、安卓系统：应用上传-审核- OK- 3、iOS 苹果 同安卓 】--- ”灰度“发布（先对一部分用户开放，没问题再开放一部分，直到100%）
二、工具
1、交互图
产品和交互设计员：以网页形式展示和访问
详细描述功能的流程和动画效果
2、UI设计稿
设计师：以网页形式展示和访问，详细描述每个页面的样式（开发参照开发）
3、ones文档平台
产品文档，测试管理，企业知识库（wiki）
全体成员：ones文档平台（ones.cn ）：产品文档，测试管理，企业知识库，公司文档管理等等 都在这个上面（每个公司平台不一样，有其他的，记一个就行）
4、bug管理平台
测试员+开发员：ones、Bugzilla、Testin云 等都可以
功能：bug提交，管理，状态跟踪，测试用例编写和管理，质量报告等
5、postman 电脑接口调试
开发通过请求url地址拿到显示在屏幕上的数据，测试员通过工具直接访问查看原始数据，进行对比。以此来判断bug的责任是软件开发者还是后端（数据服务）开发员。
比如天气接口： wis.qq.com/weather/com…
url地址：wis.qq.com/weather/com… （不要业务不一样，通过此路径找到数据位置） url参数：province=四川&city=成都 等 （通过参数找到对应 精准的数据）
状态码：
200： OK
3xx重定向：如301（永久重定向）、302（临时重定向）
4xx
客户端错误(找前端或app开发)：如403（禁止访问）、400（请求语法错误）5xx
服务器错误（找后端开发）：如502（网关错误）、503（服务不可用）
6、stream 手机软件
抓包：手机上通过此软件快速获取页面调用了哪些接口（类似postman，但是stream不需要手动输入url地址，他会所以url请求都抓取），通过数据对比判断是谁的问题
7、JMeter （电脑软件）
接口压力测试，不同于postman（通常手段验证一些接口数据），JMeter通常用来做压力测试（同一时间发送成千上万次，模拟大量用户同时使用的场景），如果压力测试过程中出现问题，说明需要修改和优化。
下载失败问题： 此软件为国外网站下载，外国网站下载速度有限制，可以搜索中国镜像地址下载（镜像地址就是把国外网站的数据复制一份到国内，这样相当于直接访问国内网站，下载就会很快）
下载地址（官方国外）：www.oracle.com/technetwork…
下载地址（国内镜像）：repo.huaweicloud.com/java/jdk/
参考： www.cnblogs.com/xyztank/art…
cloud.tencent.com/developer/a…
8、MySQL
公司的和用户使用的数据都以 数据形式存储在 数据库Database中，通过MySQL可以查看和管理。了解即可。
一些数据相关概念
1.数据：文字信息，图片，视频等
2.数据表（table）：记录数据的表格
3.数据库（database）：管理数据表格的库（仓库）
4.数据操作（sql）：添加数据、删除数据、修改数据、查询数据。（简称：增删改查）
三、【快充】后端管理端项目介绍
充电后端管理系统/小程序：功能实现与架构解析
后端管理端功能
华为超充联盟平台：support.huawei.com/enterprise/…
3.1、系统概述
充电后端管理系统是充电桩运营管理系统的核心部分，采用前后端分离的架构设计，确保系统的高性能、高可用性和易维护性。系统基于MySQL 5.7+、JDK 1.8+和Redis等技术栈构建，前端则采用Vue 2.6.14和Element-UI 2.15.6，并在Node 14.21.3环境下运行。这一架构不仅支持高并发访问，还通过模块化设计简化了系统的扩展与维护，为运营商提供了稳定可靠的数字化管理平台。【⚠️ 了解即可】
3.2、功能详细实现
1.1 信息总览
功能描述：提供系统的整体概览，包括关键数据和统计信息，方便快速了解系统状态。例如，实时显示充电桩总数、活跃用户数、日充电量等核心指标，帮助管理员快速决策。
实现方式：通过数据接口从数据库获取关键指标，如充电桩使用率、故障率等，并以图表形式展示。系统还支持自定义时间范围的数据筛选，确保信息的实时性和准确性。
1.2 数据看板
功能描述：展示各种数据可视化图表，帮助用户直观理解数据趋势和模式。例如，通过折线图展示充电量随时间的变化，或通过饼图显示不同充电站的利用率分布。
实现方式：使用ECharts等图表库，将数据以柱状图、折线图等形式展示，支持自定义筛选和导出。管理员可以根据需要调整图表参数，实现数据的深度分析。
1.3 电站监控
功能描述：实时监控电站的运行状态，包括电力输出和设备健康状况。例如，系统会监测充电桩的电压、电流和温度等参数，确保设备安全运行。
实现方式：通过设备接口获取实时数据，并设置阈值告警，当数据异常时触发通知。系统还支持历史数据回溯，帮助管理员分析设备故障原因。
1.4 电站电桩管理
功能描述：
电桩监控：监控电桩的使用情况和性能，确保电桩正常运行。例如，实时显示电桩的在线状态、充电进度和故障记录。
站点月表：展示站点的月度报告，包括运营数据和关键性能指标，如充电次数、收入总额和用户满意度。
对账单：提供财务对账单，包括收入、支出和账户余额，支持自动生成和导出PDF格式。
实现方式：通过数据接口从数据库获取电桩使用数据、站点运营数据和财务数据，并以表格形式展示。系统还支持批量操作，如批量更新电桩状态或导出报告。
1.5 投资者/物业管理
功能描述：管理投资者和物业的信息，包括联系详情和投资记录。例如，系统可以记录投资者的入股比例和收益分配情况，便于财务审计。
实现方式：提供CRUD（创建、读取、更新、删除）操作界面，支持批量导入和导出功能。系统还集成了权限控制，确保敏感信息仅对授权用户可见。
1.6 营销活动管理
功能描述：
横幅广告：管理网站或应用的横幅广告，包括广告内容、投放时间和效果监测。例如，系统可以设置节假日促销广告，并跟踪点击率和转化率。
活动列表：展示所有营销活动的列表，包括活动详情和状态。管理员可以查看活动的参与人数和优惠券使用情况。
优惠券列表：管理发放的优惠券，包括优惠券的创建、发放和使用情况。系统支持设置优惠券的有效期和使用条件。
实现方式：通过活动管理模块创建和管理活动，支持设置活动规则和优惠券发放条件。系统还提供数据分析功能，帮助优化营销策略。
1.7 订单管理
功能描述：处理和跟踪订单，包括订单状态更新、发货和售后服务。例如，系统可以自动匹配充电订单与用户账户，并生成结算报告。
实现方式：提供订单管理界面，支持订单查询、修改和导出功能，并与支付系统集成实现自动结算。系统还支持退款处理和订单历史记录查询。
1.8 用户列表管理
功能描述：展示所有用户的列表，包括用户信息和行为数据。例如，管理员可以查看用户的注册时间、充电频率和反馈记录。
实现方式：通过用户管理模块提供用户列表，支持用户信息查询和导出功能。系统还集成了用户行为分析，帮助识别高价值用户。
1.9 系统配置
功能描述：
运维用户：管理运维团队的用户账户，包括账户创建、权限分配和监控。例如，系统可以设置不同层级的运维权限，防止越权操作。
角色权限：定义不同角色的权限，控制用户对系统资源的访问和操作。例如，管理员可以自定义角色，如“财务员”或“运维员”，并分配相应的功能权限。
实现方式：通过权限管理模块实现用户角色和权限的分配，支持自定义角色和权限规则。系统还提供操作日志记录，便于审计和故障排查。
四、 小程序端项目介绍
参考特来电界面截图
2.1 充电地图
功能描述：
充电站搜索：允许用户搜索附近的电动汽车充电站，方便用户快速找到可用的充电设施。系统会根据用户位置推荐最优站点。
充值有礼：提供充值优惠信息，鼓励用户充值以享受更多优惠。例如，首次充值可获赠额外积分。
充电地图：展示充电站的地图视图，用户可以查看充电站的具体位置。地图还支持缩放和路线规划功能。
收藏：用户可以收藏常用的充电站，方便下次快速访问。收藏列表会同步到用户账户，支持多设备登录。
实现方式：通过地图API实现充电站定位和搜索功能，支持收藏功能的数据存储和同步。系统还集成实时数据更新，确保地图信息的准确性。
2.2 扫码充电
功能描述：
轻触照亮：提示用户轻触屏幕以激活或点亮某个功能，例如在低光环境下辅助扫码。
输入充电桩编码：用户需要输入充电桩的编码，这可能是为了识别特定的充电桩或启动充电过程。系统会验证编码有效性，防止错误操作。
打开相册：提供了一个选项，允许用户打开手机的相册，可能是为了上传充电桩的照片或扫描充电桩的二维码。例如，用户可以从相册中选择已保存的二维码图片进行识别。
实现方式：通过扫码功能实现充电桩的识别和充电启动，支持相册上传和二维码扫描功能。系统还集成安全验证，确保充电过程的安全性和可靠性。
2.3 个人中心
功能描述：
钱包余额：显示当前用户的钱包余额，支持实时更新和交易记录查询。
充值选项：提供“充值”选项，用户可以通过这个功能向钱包中充值。系统支持多种支付方式，如微信支付或支付宝。
我的卡包：可能包含用户的各种充值卡、优惠券或会员卡信息。例如，用户可以查看优惠券的有效期和使用规则。
充电订单：显示用户有4个充电订单，用户可以在这里查看和管理自己的充电订单，包括订单详情和支付状态。
我的收藏：用户可以收藏常用的充电站，方便下次快速访问。收藏列表支持分类管理和快速搜索。
个人信息：用户可以查看和编辑自己的个人信息，如姓名、联系方式和车辆信息。
实现方式：通过个人中心模块实现用户信息和订单的管理，支持钱包充值和卡包管理功能。系统还集成消息推送，及时通知用户订单状态或优惠活动。
四、结语
充电后端管理系统的推出，为电动汽车用户提供了一个便捷、高效的充电服务网络，同时也为运营商提供了强大的管理工具。通过先进的技术栈和优秀的功能设计，平台能够实现充电服务的高效运作，推动绿色能源的发展。例如，系统的实时监控和数据分析功能，帮助运营商优化资源分配，提升用户体验。立即行动，拥抱数字化能源管理的未来！
五、问题
软件测试员在工作中可能会遇到多种问题，以下从不同方面为你详细阐述：
需求相关问题
• 需求不明确或不稳定：需求文档不完整、不清晰、不一致，或在开发过程中频繁变更，这使测试人员难以设计和执行有效测试用例，也难以判断测试结果是否符合预期。例如需求文档未明确用户界面的布局和颜色，测试人员就无法判断界面的美观和易用性。
• 需求定义不准确或不完整：部分需要测试的操作未在需求中列出，导致测试覆盖不全面。如电子商务网站的某些操作未在需求里，测试人员就无法对其进行测试。
时间相关问题
• 测试时间有限：开发团队通常会设定紧迫的发布时间，留给测试的时间不足，容易遗漏缺陷。比如面向消费者的移动应用程序，为赶在特定假期前发布，测试时间变得非常有限。
• 测试时间评估困难：测试时间评估需考虑需求变更、开发进度延误、bug修复不稳定（不能按时修复）等诸多不确定因素。但实际中测试人员往往最晚得知新需求内容，还需在临时会议中马上给出测试时间估计。
资源相关问题
• 测试资源不足：执行测试所需的设备和工具可能不足或不可用。例如汽车制造公司的软件测试中，若测试人员没有足够的物理车辆进行测试，测试工作将受到严重限制。
• 测试人员技能和经验不足：若测试人员缺乏自动化测试等相关知识和技能，就难以有效利用自动化测试提高测试效率和覆盖率。
测试环境相关问题
• 测试环境不一致：测试环境和生产环境差异较大，影响测试的有效性和可靠性（问题：测试环境正常，在正式环境异常），也不利于缺陷的复现和排除。例如测试环境与生产环境的网络速度不一致，会导致无法准确评估软件的性能和响应时间。
• 测试环境不稳定：测试环境经常出现故障或变更，给测试工作带来困扰。
缺陷管理相关问题
• 缺陷管理不规范：缺陷的报告、跟踪、分配、修复和验证缺乏统一流程和工具，导致缺陷重复、遗漏、误报或漏报，以及修复引入新缺陷。如缺陷报告未明确描述重现步骤和影响范围，开发人员就难以定位和解决问题。
• 缺陷修复争议：开发人员可能认为不是代码问题，或是需求如此定义；也可能将问题推给其他负责人。比如开发称“这个不是代码问题，需求这么定义的”或者“这块是别人负责的，我负责的部分没有问题”。
测试执行相关问题
• 提测质量差：第一个提测版本质量不佳，部分未通过冒烟测试。原因可能是功能完成度低、新团队处于磨合期、提测要求不明确等。
• 功能反复出现问题：上一个版本正常的功能，在新版本中又出现问题。
• 功能漏测：测试过程中可能会遗漏某些功能的测试，影响软件质量。
• 线上线下环境差异导致问题：测试环境没问题，但线上环境出现问题。
自动化测试相关问题
• 传统自动化测试维护工作量大：传统自动化测试维护工作量占比超60%，月均脚本失效率达25%，每次异常处置耗时超30分钟，让企业自动化测试之路困难重重。
