净整些花里胡哨的没用的

想报名但是我太菜了

感觉可以来个造数据小工具，一些操作不便的测试场景都可以试试能不能做成工具。（拿社交软件举例子）

1. 模拟大批量的数据（大批量用户关注/大批量用户私信/增加账户金币）
2. 模拟快速清除数据（从已注册变为已注销，从已经实名认证变为实名认证）

建议是回归用例不用太细，经过好几个版本都稳定的功能可以只包含主流程，一些 P3 级别的路径也只包含主流程。回归完了有空的话再随机探索测试下。

“年纪大了，学习新产品，新工具和新语言的速度弱于年轻工程师”
不管多少岁～都要保持持续学习～

小菜鸡我说下自己的想法～落地一般是为了解决问题，我这边项目是用来做开发提测的卡点，做了 UI 自动化验证提测的包是否主流程通过。
建议先评估目前已有的问题，是否确定能够通过 UI 自动化去解决/有无其他方式/产品的迭代是否稳定，评估可以使用 UI 自动化后先梳理下整个流程。如果期望代替部分手工回归功能，那要先制定好 UI 自动化覆盖的场景、触发自动化的路径、框架选型等，就当写需求文档一样先把你期望的方案写一下～

1. 写方案（场景、路径）
2. 评审方案【个人觉得前期评审方案非常重要，不然你可能好不容易干完了结果大佬评估你这个流程有问题要重构，评审整体流程以及 UI 自动化的场景】
3. 执行方案（技术选型，分 APP/web/PC 桌面端/小程度）如果你是自动化小白，选好技术框架后可以先从框架教程走起
4. 看效果，持续跟进

自动化框架现在行业内挺多的，我这边是 appium，用 PO 模式。这些跟着 appium 教程学一学应该都大同小异

很全面， 如果本次测试遇到的问题较多，也可以抽出来写下问题和改进方案～更亮眼哦

刚入门的小白，建议先把基础功学好了再发展技术。我遇到很多工作四五年的测试，脚本写得飞起，用例写出来完全看不懂，去执行他的用例，真的会要命 。如果评估目前用例写得还不错，可以拿你的用例给同事看一下，看看他人评价如何，或者发论坛 review review～
基础差不多之后，可以根据你想测试的方向去选择学习重点，方向不一样，要重点学习的内容也不一样。如果你测移动端，也许可以重点学习安卓系统/iOS 系统；如果测服务端，也许可以重点学习接口测试工具/数据库/中间件....后续提问的时候也可以简单说下你的发展路线，这样好针对性给你提供建议

改改这报 bug 的标题吧。。。。。

接入机审，人审改为先发后审

只有我想看恒捷的回复么

马克杯我来了～

我的习惯是先和面试官申请 2 分钟自己在纸上梳理下大纲，梳理完之后先说大分类，再说每个大分类下一些比较核心的路径和需要特别注意的点。大的分类比如接口、功能、安全、性能、网络，小的分类如微信发红包，功能测试这个模块就重点讲涉及支付相关的场景，讲的时候结合你说的这部分内容：
“复杂的用户场景（高并发）
功能的数据流向（从哪里来到哪里去）
功能的架构设计（缓存、中间件）”
最后我觉得如果刚好你在支付曾经踩到过坑，可以说下你的总结及对应的测试用例

造数据具体是指的什么？一条条的测试用例么。
我建议可以去参考下其他同事写的好的用例，看下别人是怎么梳理思路的。理论知识基本都差不多，看下实际应用可能上手更快。

回复测试

“要有代入（换位）思维，如果你是用户，你是怎么想的。” 对这个我有点疑惑，我一个人的想法也不一定能代表全部用户，这种站在用户角度思考真的是有效的么？一个功能可能组内的测试同事想法都不一样。

小孩才做选择，都拿下

“接口测试的目的不是取代业务测试，而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量” 赞

怎么感觉是代码本来就没其他控件了；或者你试试直接点中间那块的控件树找一下元素试试

分析需求文档时多考虑海外的文化习惯。想到我司有个很有意思的海外用户反馈，本身产品需求设计只能选择性能女 or 性别男，用户反馈为什么不能选择第三性别。结合这类海外文化，在需求设计阶段测试就可以去提些潜在的设计问题。

要不在一线多干十年，攒点钱回老家开个小店啥的咯

开发演示是否发现主流程问题/自测用例是否超过 10% 的内容不通过/总缺陷数量