问答日常点点点测试工作比较多，小组内也只有自己一个测试，主要接触的是 TOB 类型的产品，想要提升一下自己测试方面能力，有啥建议吗

呼噜呼噜 · 2025年05月13日 · 最后由小行星回复于 2025年05月29日 · 12609 次阅读

现状

从事功能测试大概有 3 年了，测过 web 应用，小程序。也接触过压测和自动化，但是这两者都没激起太大水花。主要原因可能是个人自驱力不够，然后工作上也没有硬性要求。每次都是测完一个版本，主要是针对该版本进行功能方面的测试反思和复盘。

问题

功能测试这里，我觉得自己也没做太好，设计出来的测试用例，是测试点的时候就还好，但是一描述成具体的用例就感觉很奇怪。我觉得好点的用例，就是一个新手在基本熟悉了功能之后，应该就能上手这个用例进行测试，显然我没有做到。
自动化测试，我就是实践了 python+selenium+allure 搭建起了一个项目，然后手动执行 pytest 具体的测试脚本能生成报告。本意想的是能够通过自动化测试给手工测试减轻一点工作量。至少在回归测试场景是可以走的通的。但每次脚本调试，定位元素都要耗时好久。由于我测试的应用的关系，它分两个态，设计态和运行态。设计态其实就是进行表单，视图，菜单，流程，规则等等的配置。而运行态就是生效这些配置。我们有些功能其实都已经固定了的。但是通过脚本去自动化测试这些对我来说还是有点难度。有时候往往头天调试好了，第二天就又不好使了。页面元素并未变化。开发同事也没有更新代码。有时候都被打击到了....

需求

我想通过 testerhome 这个平台，能收到各位前辈的建议或者是具体的学习路线。我真的很想把自己变成一个有技术水平的测试工程师，而不是纯点工。特别想要那种系统的提升或者学习路线。比如从功能测试 - 接口测试 - 压力测试 - 自动化测试逐步提升。

9 个赞

共收到 28 条回复时间点赞

尼古拉斯静 #1 · 2025年05月13日 3 个赞

跟楼主差不多，能把功能测试做好都不容易，平时技术上也没啥提升

挥霍。 #2 · 2025年05月14日 3 个赞

如果对技术感兴趣，还是趁早看机会找技术的岗位吧，哪个方向都可以

Time #3 · 2025年05月14日 1 个赞

当前的学习难度会比之前小很多，可以在做点工的同时，发现自身在测试过程中有哪些痛点，依据这些痛点去询问 deepseek 等 AI 工具，如何解决此类痛点，这是从你实际的运用角度出发去解决你面临的实际问题，从这个方向走会更好的促进你去往相关知识领域发展，比如你遇到的问题需要开发一个小工具，那么你就会去着手接触 python、后期语法熟悉后，你就可以看 python 在测试领域的拓展，比如 App 性能方面的知识，接口自动化方面的知识，选择你喜欢的领域发展，不用开始就盲目跟从所谓的接口自动化、UI 自动化、性能等。

在路上 #4 · 2025年05月14日 3 个赞

toB 业务相当复杂专业，本身就是一定的门槛，好好学习业务吧

Xindy #5 · 2025年05月14日

现在感觉测试的话，还是深入业务，知道一些底层东西；会好一点；当然，自动化、性能这些也得具备；性能不单单要会执行脚本，还得懂一点分析

呼噜呼噜 #6 · 2025年05月14日 Author

对

在路上回复

我主要接触的就是每次的功能宣讲以及编写测试用例过程中的打磨这些，实际业务使用场景我其实接触的不同。但是通过我测试的这个应用有实施人员搭建出客户的实际使用场景。不过没有人会专门给我培训客户实际使用场景。这样的话，我是不是就需要自己去看一下客户的实际使用场景，然后再结合自己的测试用例，每一轮新功能测试完成后都按照这个方式去，慢慢的就能提升自己的业务能力呢

呼噜呼噜 #7 · 2025年05月14日 Author

对

挥霍。回复

纯点工肯定不行的，但是我想要结合测试这方面提升一下自己开发技术。其实之前有短暂接触过前后端，自己有写过很简单的前后端分离的那种系统。特别的基础。后来误入测试，开发在我日常的工作中没有什么实践机会。我之前也看过前端代码，想着自己测试熟悉功能，能看代码然后学会写。但是怪我自己没坚持。有时候测试工作紧张。我下班后又不想多学会。时间一久就搁置了

呼噜呼噜 #8 · 2025年05月14日 Author

对

Time 回复

确实，同意您的说法。但我现在属于哪个都不精进。确实要按照您说的先解决痛点，然后再选定方向，一步步深耕。最后才会慢慢提升。我会按照这个建议结合自身实际慢慢对自己做出改变

呼噜呼噜 #9 · 2025年05月14日 Author

对

尼古拉斯静回复

你也是差不多的工作年限和现状吗？那考虑做个搭子吗？一起改变自己。我一个人总是半途而废。自身技术不够，又老想着拖延。

呼噜呼噜 #10 · 2025年05月14日 Author

对

Xindy 回复

是的，单纯只按照需求文档列出的功能点测试是不是就认为是很一般的功能测试呢？

呼噜呼噜 #11 · 2025年05月14日 Author 1 个赞

看到大家的很多回复都是说要熟悉业务，但是我目前每次接到一个新功能的测试任务都会按照以下步骤进行，看起来我并没有过多接触业务，我是不是应该主动去寻求接触业务的可能
1.看一遍需求文档结合产品给出的文字说明结合原型图梳理出尽可能全面的测试点
2.把这个需求文档扔给 ai，让他给我梳理一下测试点
3.对比 1，2 进行查漏补缺
4.开始写用例
5.先进行第一轮自己评审，修改编写用例过程中的错别字或者是描述不合理的场景或者是错误的操作步骤或者是本期不实现的功能点
6.列出所有功能的测试重点
7.准备测试数据
8.产品二轮评审，修改用例
9.拿到可以测试的功能后，按照之前列出的重点，先冒烟测试一轮
10.评估一下当前功能的质量，决定要不要打回，大概率是不会进行打回，会继续测
10.先测试高优先级用例
11.记 bug，在提出一个 bug 的时候我会进行排查具体是什么原因，有时候自己也能提供 70% 的解决思路
12.回归修过的 bug
13.总结本版本测试过程中用例编写问题，bug 记录问题

在路上 #12 · 2025年05月14日 1 个赞

对

呼噜呼噜回复

可以系统的了解下你们的业务，写一篇文章出来。
（1）业务维度有哪些模块组成，各模块的核心功能是什么。
（2）技术维度有哪些服务组成，用了哪些中间件，各中间件的功能是什么。
（3）质量维度或效率维度：目前主要有哪些问题，可以想到什么解决方案？如果可以通过技术或非技术手段解决掉，会是面试中很好的加分项。

Xindy #13 · 2025年05月15日

对

呼噜呼噜回复

一般不一般这个不好评价；我的亲身经历把，前几天去面试一个业务重合的公司；当问我问题的时候，我回答的总是一些表面层次的答案；面试官想知道的是深层次的东西；就像 12 楼说的那样，你要知道业务都有哪些模块；模块的核心功能；以及这些核心功能它们的流程是怎么样子的；简单点的就是那个经典面试题；输入一个网址，跳转到一个页面，背后的流程是怎么样的

呼噜呼噜 #14 · 2025年05月15日 Author

对

在路上回复

好的，我按照这样的方式去实践一下。

呼噜呼噜 #15 · 2025年05月15日 Author

对

Xindy 回复

我平时测试确实也比较表面化，虽然接触这个系统很久了，但是还不能完全说出它背后的流程，看来对业务这一块的熟练度还很欠缺。

dun #16 · 2025年05月15日 4 个赞

ToB 业务测试做到顶点，用 AI 赋能测试加成，边工作边学习编程语言（容易上手的，py、go、shell 等）、用于自动化测试（ToB 的产品，业务比较容易自动化），自动化搞定再往服务层钻研，搞定服务层组件的工作原理，再就是能自己完成整个 ToB 系统的自动化测试框架搭建、测试脚本编写和维护（Git）、与 jenkins 集成，最后就学习一门大的编程语言（py、java、JavaScript 等），能自己开发测试工具或者对已有开源工具进行二次开发。这些搞定中小企业应该可以随便进。如果想去大厂，提升学历，python 或者 java 学到精通，能开发小项目

小黑子-IKUN #17 · 2025年05月15日 14 个赞

上面的人都回答得差不多了，我就扯几句没用的。

【把这个需求文档扔给 ai】

这个你要注意下，由于你是 tob 项目的，可能会涉及泄密，甚至引发法律问题

【是测试点的时候就还好，但是一描述成具体的用例就感觉很奇怪】

这一点我刚出来时也有过，这种感觉之所以奇怪是因为你心里没底。

tob 业务流程复杂，涉及多角色、多系统交互，需求是偏向业务逻辑而非用户体验，这导致主流程下会有很多的支线流程。而写测试点容易停留在主干流程，但写成具体用例时需要覆盖各种分支场景，这导致设计时感到逻辑缠绕，因此心里没底就会产生” 奇怪 “的感觉。

举例：贷款审批流程

根据流程列出大概的测试点：
1.客户提交贷款申请
2.审核员审核资料
3.系统自动评估信用评分
4.审批人审批贷款
5.系统发放贷款资金

这些看起来都很清晰，是标准的 “主流程”，你也脑补了写测试用例时要把场景法、边界值法、场景法等用上，细分出异常场景。

等真正上手写了，就会被分支流程搞得没底，比如：

客户上传资料不全 → 审核员退回修改
系统评估信用评分低于阈值 → 自动拒绝
审批人驳回申请 → 客户可重新提交
审批人审批后系统放款失败 → 记录日志并通知人工处理
审批过程中客户取消申请 → 状态变更，终止流程
多个审批人角色（初审、终审）→ 不同权限控制不同操作
多系统交互（如风控系统返回错误）→ 异常处理机制

你试图把这些分支全部写进测试用例时，就会发现：
流程图越来越复杂
用例数量剧增
很难确保所有组合都被覆盖
心理上自然会产生 “奇怪” 的感觉：“我是不是漏了什么？ ”

1 这时候你就可以尝试用 “场景法”+“状态迁移法” 进行结构化设计，来缓解这种 “奇怪” 感

将整个流程抽象为多个 “状态节点”
每个状态之间定义合法/非法的转换路径
画出状态图或流程图

[申请中] --(提交)--> [待审核] --(审核通过)--> [待审批] --(审批通过)--> [已放款]
                ↓ (审核不通过)
                 [资料补充]

2 然后 “边界值法” 与 “异常路径” 做到明确

列出所有可能导致流程中断的因素（如网络、权限、数据异常）
对每类异常单独设计用例 (不要贪多一例多查，一个用例就检查一种情况)
明确系统应对异常如何反馈、记录、恢复

3 用 “判定表” 减少冗余，判定表早期面试还真的挺多人问，现在挺多人都不知道咋用了

对于多个条件组合（如用户角色 + 状态 + 操作类型），可以用判定表统一管理
避免重复写类似用例，提高维护性

4 测试用例设计需要分层

主流程用例核心业务线

子流程用例主流程中的小步骤

异常用例各类失败情况

这样分层后，你可以按层逐步验证，避免一次性陷入细节而迷失方向感到害怕

由于测试只有你一个，不需要给自己太大压力，顺其自然发育即可，多跟开发们、产品们沟通交流，多留意项目的盈利情况和用户客诉。至于用上什么技术提效，这个是自然而然的，你闲事可以想想或者跟 AI 讨论或者找开发们探讨，如果公司体量变大了，就可以申请跟公司要求加人，你业务最熟悉自然而然也会变成小组长，然后面试时找个技术还行的进来完成你的构想

呼噜呼噜 #18 · 2025年05月15日 Author

对

小黑子-IKUN 回复

感谢给出比较具体的例子，我会试着按照您给出的具体方式去调整用例设计的。并且在空闲时也按照上边给出的具体方式去实践的。
我这个测试系统是有点偏向低代码，就明道云那种类型的项目。在写用例过程中也的确存在你列出的 ---- 这导致主流程下会有很多的支线流程。而写测试点容易停留在主干流程，但写成具体用例时需要覆盖各种分支场景，这导致设计时感到逻辑缠绕，因此心里没底就会产生” 奇怪 “的感觉---
虽然只有我一个人，但是我也还挺有压力的，因为感觉相比研发、产品、实施，自己存在感比较低。好像价值不大，更不能创造出很有价值的东西。自从开始测试这个项目，做的最多的也就是纯功能测试，每次一听到有人反馈 bug，就是自己内心一咯噔。虽然知道不可能有完全没 bug 的系统，但是也还是会控制不住自己。有的时候，有些 bug 确实是我没有测到。平时写用例并没有按照 -- “场景法”+“状态迁移法” ，“边界值法” 与 “异常路径” ， “判定表”，用例设计分层这些具体的方法去写用例，最近写完了一个新功能的用例，我再试着去用这些方法，具体实践一下。