也是比较具体的实践路线，感谢给出的建议

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

你可以按照这个思路去构想一下
1.首先介绍一下功能测试 - 因为是面向大家的，而这个群体可能有的对功能测试认知比较片面
2.介绍一下自己平时在功能测试过程中的步骤，可以突出强调一些自己觉得比较好的方面 - 这样可以让大家快速知道哪些是值得借鉴的点
3.以某个案例具体说一下怎样展开测试，以及问题排查，最后验证问题的解决
4.分享一些测试学习资源

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

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

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

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

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

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

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