例如，我假设这就是SDET？
他们实际上并没有编写功能代码，但是他们能够编写集成/单元测试，对吗？
但是有人可以学习阅读代码然后开始编写测试吗？
答案 0 :(得分：2)
这实际上是一个好问题。当我只从事手动测试时，我一直在同一地方。这是我过渡到自动化时的经历。要回答您的问题，是的，有人可以阅读代码并开始在上面编写测试，但是您需要了解要测试的代码。
测试应用程序时使用了不同类型的测试方法。这些测试是分层进行的，以便正确地测试应用程序。这是分层的样子：
1）单元测试：这部分通常由开发人员编写。这是因为他们已经编写了代码并且知道了代码的功能，并且使他们更容易编写。我是SDET，并且已经编写了单元测试。机会只有一次出现，那是在我们重构代码时，还有很多编写单元测试的空间。在单元测试中，您可以通过给它一些值并验证期望值来隔离测试功能。这不是SDET要做的，但如果有机会，应该可以做到。
2）集成测试：这部分通常也由开发人员编写，但是集成测试的定义有点模糊。这意味着要隔离测试多个模块。这可以是后端中的模块，也可以是前端中的模块，但不能在一起。实现此目标的框架是针对所使用技术的代码级集成测试。与Angular应用程序一样，有深度集成测试可以测试组件的HTML和CSS，也有浅层集成测试可以一起测试两个组件的逻辑。这可以由SDET编写，但通常由开发人员编写。
3）API测试（基于合同的测试）：Pact帮助我们实现了这一目标。还有其他工具，例如放心，邮递员和jmeter，可帮助测试API端点。 Pact帮助测试前端上的API集成并验证后端中的集成。这在微服务中非常流行。这可以由开发人员或SDET编写。
4）端到端测试：这是SDET的全部责任。这涵盖了根据用户故事对用户流进行的测试。它正在一起测试整个堆栈。后端和前端。这使SDET可以自动使用户使用该应用程序。这也称为黑盒测试。有不同的框架可以帮助实现这一目标。硒，量角器，柏树，排毒等。这是SDET的全部责任。
5）负载测试：这也是SDET所做的事情。使用hey，jmeter，loadrunner等工具。这些测试使SDET可以在系统上引发重负载并检查系统的断点。
6）性能测试：根据页面加载时间，SEO优化和页面元素的权重，为最终用户测试网页的性能。这是通过Google的灯塔工具实现的，它是一种了不起的工具。我不知道还有什么能像灯塔一样令人惊叹的，因为它为我们提供了许多可用于改善网站的数据。这是SDET的主要工作。
7）CI / CD：持续集成和持续部署是需要系统架构知识的东西。当您是SDET3或首席质量检查工程师时，可以执行此操作。对于诸如AWS和GCP之类的系统，使用诸如Jenkins和CircleCI之类的CI构建工具，无论分支合并到master还是创建拉取请求，都可以建立运行上述所有测试的管道。创建管道需要您具有Docker，Kubernetes，Jenkins和测试框架的知识。首先，您对测试进行docker化，然后构建映像并将其推送到云中的目录，然后使用映像创建kubernetes作业，该作业在代码中出现更改时就运行。
这些是SDET所做的工作级别。要了解所有测试框架以及所有内容如何组合在一起需要花费时间和精力。 SDET应该具有服务器，http协议，前端，后端，浏览器，缓存，管道管理和测试流程的知识。
答案 1 :(得分：0)
是的，可以。您可以编写单元测试，以增加代码库的测试覆盖率。这是来自软件测试工程的非常合格的工作，因为您需要知道代码中发生了什么。这个技能绝对很棒！
我建议您看一下所谓的“变异覆盖率”。突变覆盖率比简单的单元测试覆盖率更好。变异测试正在改变代码库不同部分中的逻辑运算符（产生所谓的“变异”），然后运行单元测试以找出多少个单元测试将失败以显示其有效性（如果在注入变异之后，结果是相同的）就像没有它们一样-单元测试质量很低，并且它们不会捕获任何新注入到代码库中的问题。