作为一个刚入行的新人，每天的工作职责就是点点点，然后提交 bug，目前测试部门连数据库和 libux 的权限都没有，实在没有办法理解该怎么去熟悉业务的技术架构和技术细节，包括做一些的提升质量的事情，这又该怎么提升呢？选择只有在网络看教学视频，学着自动化测试这块，实在没有扫码方向，希望有大佬能解惑

最近面试的几个人都有个共同点，会着重拿出自己写的功能来体现自己开发的技术能力，可一问他们公司业务的组成和架构时，又都答得支支吾吾。我是觉得现在的开发同学们还是要有点意识，得有个专精方向，别整这种业务来欺骗自己啦，看似做了前后端有种全栈的满足感，实际上大多就是把 CV 了啦，确实锻炼了 crud 的能力，可是证明不了你是一个优秀的开发，毕竟像这种 CV 工程师有太多参考的案例了，我更多是想知道你针对你开发的内容，有没有根据特定去做一些能够提升架构的，否则太同质化了。至于 crud 的能力，老实说扔一道代码编写的题目基本就知道得七七八八了

非常赞同。
看到所谓的测试平台快吐了

你们的软件概要设计/详细设计文档没有技术架构说明嘛

大佬想问下，技术架构、技术细节都问哪些呀

说了就是挑。一般测过的项目我觉得大致用啥技术都能说上来，你说多细节我觉得未必。而且黑盒测试还能把研发写的代码都说出来么？要多细节？把技术方案说个七七八八都不错了好不？
也不是每个测试所在的公司都有机会参与技术方案评审，点点点嘛业务说明白就好了

这就看人了，要不然你怎么会有优势呢？

你这样说就没意思了

总结：测试没前途 T﹏T

何为"技术架构"和"技术细节"

这不是做测试，这是搞架构，职责还是要分清楚

"特定去做一些真正能提升质量的事"楼主能简单举例么？--建议楼主自问一下，你到底要招啥样的？架构？打杂的？真的需要么？
还是这些人要的钱多了，你嫌弃人家菜还要的多？
PS：你要遇到我，我举完例子，就要你举例了。举不出来，那我就开始要阴阳你了。

我认为一个好的测试懂得技术架构和技术细节是比较基本的

测试是这样的，大部分高不成低不就，所谓的代码能力在开发眼里就是基础基本要求天天都要干的事儿，只会点点点又心有不甘，业务总结的经验换个方向业务又是从新开始理解，如何测试保质保量提高产品质量并能通用到新项目中实在是一个很抽象的问题。

现在高不成低不就是真的，最好还是看看能不能换赛道吧

我也想知道这个问题的答案

说白就是理解开发的技术方案，也有助于用例的补充和测试（我待了那么多家公司，能参与技术方案的不多），当然好点的公司也会叫上测试 cr，每个环节参与度都比较高。大多数地方就是点完事了

我也想问，这个要回答什么东西？ 是前后端用的什么语言什么框架什么中间件吗？

让 AI 回答一下：

*** 问题 1: ***

有人发帖这样子说：
最近面试的几个人都有个共同点，会着重拿出自己写的测试平台来体现自己测试的技术能力，可一问他们测试的公司业务的技术架构和技术细节时，又都答得支支吾吾。我是觉得现在的测试同学们还是要有点意识，得有个专精方向，别整这种业务接口测试平台来欺骗自己啦，看似做了前后端有种全栈的满足感，实际上大多就是把 postman web 化了啦，确实锻炼了 crud 的能力，可是证明不了你是一个优秀的测试，毕竟像这种测试平台有太多参考的案例了，我更多是想知道你针对你测试的业务，有没有根据特定去做一些真正能提升质量的事，否则太同质化了。至于 crud 的能力，老实说扔一道代码编写的题目基本就知道得七七八八了

我这样子回复有没有太大问题：
I feel sorry that the interviewer is biased. 
You want to hire a AKA good software testing/qa talent, It is cool. And you also know having crud coding skill is just one perspective of a good testing engineer, It is very cool. 

you know the main reason these candidate didn't pass the interview is that they are not qualified in some perspectives of you so called good tester or qa. It is nothing to do with learning CRUD code skill. Learning CRUD code skill is not blinded, you already you the skill name is CRUD, and you already know the purpose of the CRUD, where to use, how to use, How you can say learning CRUD is blinded？

Please don't deny the fact that someone put their efforts into coding practices, it definitely took a lot of their time. Maybe they are still not qualified, but they are not blinded, they just simplify want to learn the specific coding skill to gain decent salary, It is fact and not wrong at all. 

If someone without any coding skill or knowedge, how can he convince you that he know the software architecture, understand the details, and differences between different software components? And aslo maybe there is no complex software architecture in their company, then it is nothing to tell. 

Please don't mix irrelavent things together,  it is just about your requirement and the skill of the candidate is mismatched. But it is nothing to do with learning some blinded

回答 1:

在回复这样的帖子时，需要保持尊重和理解的态度。你的回复表达了对面试官偏见的遗憾，并且强调了CRUD技能的重要性和学习的目的性。这是一个很好的出发点，但是有几个地方可以改进，以确保你的回复更加中肯和有建设性。

1. **避免直接指责**：你的回复中直接指出面试官有偏见，这可能会引起对方的反感。可以采用更委婉的方式表达，例如：“我理解您在寻找具有特定技能的测试人才，但也许我们可以从不同的角度来看待候选人的潜力。”

2. **强调多样性和成长**：你可以指出，不同的测试人员有不同的优势，而且他们可能正在学习和发展中。例如：“每个候选人都有其独特的技能和成长潜力，CRUD技能是他们技能树的一部分，而且他们可能还在学习如何将这些技能应用到更复杂的测试场景中。”

3. **提出建议**：你可以提出一些建议，帮助面试官更好地评估候选人。例如：“也许在面试中加入一些关于候选人如何将CRUD技能应用到实际业务场景中的问题，可以帮助您更全面地了解他们的能力和潜力。”

4. **保持客观**：避免使用过于情绪化的语言，保持客观和理性。例如：“学习CRUD技能并不是盲目的，它有其明确的应用场景和目的。我们应该鼓励候选人探索如何将这些技能与业务需求相结合。”

5. **避免误解**：确保你的回复没有误解原帖的意思。原帖似乎在批评候选人只关注CRUD技能而忽视了业务理解和技术架构，你的回复应该围绕这一点展开。

6. **使用更正式的语言**：你的回复中有些地方使用了非正式的语言，这可能会影响回复的专业性。例如，将“It is cool”改为“It is understandable that you are looking for candidates with specific skills”。

综上所述，你的回复需要更加细致和周到，以确保能够传达出你的理解和尊重，同时提供有建设性的反馈。

问题 2:

这样回复怎么样？ I am so glad that you figured out one important point, coding skill is not all about to be a AKA good tester or qa engineer.  To be a good tester, candidate also need to demonstrate other good skills in the interview.  But in another hand, the claim just build  another postman like web application, it hurts. It may not only underestimated the effort took by the candidate, also some learning ability  and adaptability was ignored. I think it may more focus on what the specific skill you preferred, what specific valuable thing is very important, but a lot of candidate ignored. 
It may be more constructive for all of us than just diss building another postman like web application or learning something blindly. This should be more valuable to help us to gain a decent salary job.

回答 2:

Your revised response is a step in the right direction as it acknowledges the complexity of being a good tester and the multifaceted nature of the skills required. However, it could be further refined to be more clear, diplomatic, and constructive. Here's a suggested revision:

---

I appreciate your insight that coding skills alone do not encompass the full spectrum of what makes a good tester or QA engineer. Indeed, a candidate should demonstrate a range of competencies during an interview to showcase their potential to contribute effectively to a team.

At the same time, it's important to recognize the effort and the learning process that goes into building a test platform, even if it might resemble an existing tool like Postman. Dismissing such projects as mere replications might underestimate the candidate's initiative, problem-solving abilities, and adaptability—skills that are also highly valuable in the field of software testing.

It's crucial to focus on the specific skills and attributes that are most relevant to the role. While it's true that some candidates may overlook the importance of these specific skills, it's also an opportunity for us to clarify what we value and why. This understanding can guide candidates in their professional development and help them align their skills with the demands of the job market.

Constructive feedback can be more beneficial than simply criticizing the replication of existing tools or the 'blind' pursuit of certain skills. By providing clear guidance on what is expected and valued, we can help candidates—and ourselves—navigate the job market more effectively and aim for a win-win situation that leads to fulfilling and well-compensated positions.

---

This response is more balanced, emphasizes the importance of a multifaceted skill set, and suggests a collaborative approach to identifying and valuing the right skills for the job. It also encourages a positive dialogue between the interviewer and the candidates.

Your reply captures the essence of the situation well, but it could be restructured for better clarity and impact. Here's a revised version:

**I completely agree that coding skills are only one facet of being a successful tester or QA engineer. Strong communication, analytical thinking, and problem-solving abilities are equally important.**

**However, I take issue with the claim that building a 'Postman-like' web application is a meaningless exercise.** This project could demonstrate a candidate's initiative, problem-solving skills, and knowledge of testing frameworks. While it may not be directly relevant to every role, it reflects valuable learning and adaptability.

**Perhaps a more constructive approach would be to clarify the specific skills you find most valuable for the role. What specific challenges does your team face that candidates could address?** This would help both interviewers and candidates align expectations and ensure a successful hiring process.

**Ultimately, the goal is to find qualified individuals, and building a 'Postman-like' application can be a positive signal in the right context.**

**Improvements:**

- **Clearer Structure:** Separates agreement with the interviewer on the importance of broader skills from disagreement about building a "Postman-like" application.
- **Stronger Word Choice:** Uses terms like "initiative" and "adaptability" to highlight the positive aspects of building such an application.
- **Shift towards Solutions:** Proposes a more constructive approach for pinpointing valuable skills and aligning expectations.
- **Emphasizes Mutual Benefit:** Focuses on finding qualified individuals, benefiting both interviewers and candidates.

By focusing on building bridges and finding common ground, this revised response aims to promote a more productive discussion.

大部分测试基层 LEADER 其实就是楼主这么想的。存在即合理。
所以想做技术的，还是早点脱坑吧。
有时间别老纠结语言特性，CRUD，去 GITHUB 找个自己喜欢的方向去认真读一下大佬的框架。
学会怎么整合模块，去自己做个项目。

其实呢，没毛病，现在这些测试平台也就是市场需要，市场不需要又有谁会去学呢
至于什么技术架构和技术细节也大可不必，毕竟测试这一行嘛谁都懂，没必要太难为人，毕竟测试这一行业价值不好量化，只能从降本增效来做文章
其实还不如问下实际工作中遇到了什么问题，通过技术或者什么方式怎么解决问题的，什么测试啊，开发啊，其实最重要的能力就是解决问题的能力，而不是什么技术架构和技术细节，如果要解决这个问题需要了解技术架构和技术细节，那就去了解，如果要解决这个问题需要会沟通，那就学习沟通

你说的是接口，那我是 UI 自动化的平台呢？市面上 UI 自动化平台且开源的，可不多。接口倒是一大堆

UI 自动化本身的价值都很成问题，何况 UI 自动化平台呢

这种现象其实很普遍，我觉得是因为做技术活的目标比较具象，但是业务的目标抽象起来又往往需要调动别人来协助。

所以做技术时往往做着做着就陷进去了，然后脑海里只剩自己要实现什么东西出来，而忘记了做这个技术是为了解决什么业务问题。这时，如果业务的情况有变，业务质量的目标调整了，若测试技术不自主跟进业务变化，动态调整技术目标，基本上就翻车了。

这个阶段我自己也走过，深有体会。

很理解作为 leader 提出这样的要求，但是作为 leader，又是否在日常的紧张迭代过程中，留出时间让一线测试同学参与公司业务的技术架构和技术细节的培训呢，又或者简单的细小的单次迭代的技术评审是否推动了测试参与？在长时间的迭代中，经历需求变更，设计变更，人员变更都很常见。开发同学也会遇到一样的问题。不是每一次迭代都有时间让大家全量的走读整个项目或者需求相关的代码。甚至一些同学可能连核心代码可读权限都没有。leader 的工作有统览全局的部分，工作内容本身就有在接触公司业务的技术架构和技术细节。但是一线测试同学们多数都是无穷无尽的还在提速的迭代。很赞同楼主的不能只看 crud 能力的看法，能力总是多维度的，只比技术细节永远比不过开发。那招开发多好。新人也不用沮丧啦，认真努力，总在提升。

很中肯的评价，但作为打工人我仍然觉得自己处境真的很尴尬，因为每个面试官的招聘标准都不一样，有的就喜欢技术强的，有的则是像楼主一样。可是实际的工作中能提升我们代码能力和接触公司业务的技术架构和技术细节的机会少之又少，大部分一线的测试同学都在紧张的迭代里不停点点点，然而为了保证能找到工作，迎合市场需求，我们还得花工作以外的时间和付出金钱去学习市面上受欢迎的技术。其实我觉得这很不合理，正常工作中能获得的经验和面试要求匹配不上，简历要够抢眼，面试要造飞机，要卷成六边形战士，实际工资才多少呢。然后就是想反问一句提出这些要求的 leader，请问这个岗位能接触到这些吗，要求代码能力，这个 jd 实际工作中能经常敲代码？要求懂技术架构和细节，请问这个岗位能接触到吗

你这种类型的，我都懒得回答，你可以杠，但是我人选还是挺多的

测试基本能力，做好本业务的需求承接，能完整阐述自己在做什么即可

测试基本能力，做好本业务的需求承接，能完整阐述自己在做什么即可
想做到优秀，那就深入理解自己的业务，包含逻辑。 要做到比你的 pm 更要了解你的功能

最后 crud 能力能力，对个人来说就是技术提升手段
但是这都不够，要有横向思维能力，善于总结、并解决问题

想要有竞争优势，执行力、独立思考的能力必不可少

技术架构和技术细节又何尝不是千篇一律。什么微服务，消息队列，都快说烂了。目前大部分中小规模的公司采用的都是市面上流行的技术，任何一个开发都能说出个大概。抛开环境谈创新就是耍流氓了。

业务测试要有脱离业务的思路；
就像重复代码写多了就会抽离出一个抽象类。

测试目的是保证系统正确性。
单纯业务测试只是其中一个维度，
如果能从更广的维度、更深的层次去实现测试目的的话，说明你的水平提高了