如果你不实际写代码，你能写单元测试吗？

Question

例如，我假设这就是SDET的作用？

他们实际上并不编写功能代码，但他们能够编写集成/单元测试，我说的对吗？

但是，有人可以先学会阅读代码，然后再开始编写测试吗？

Answer 1

这实际上是一个好问题。当我只做手工测试的时候，我也在同一个地方。以下是我过渡到自动化时的经历。为了回答你的问题，是的，有人可以阅读代码并开始在上面编写测试，但你需要理解你要测试的代码。

在测试应用程序时，可以使用不同类型的测试方法。这些测试是按层完成的，以便对应用程序进行适当的测试。下面是分层的样子：

1)单元测试:这部分通常由开发人员编写。这是因为他们已经编写了代码，并且知道代码的功能，因此他们更容易编写。我是一个SDET，我写过单元测试。只有一个机会出现了，那就是我们重构代码的时候，有很大的空间来写单元测试。在单元测试中，您可以通过为函数提供一些值并验证期望值来单独测试函数。这不是SDET所做的事情，但如果有机会的话，它应该能够做到。

2)集成测试:这部分通常也是由开发人员编写的，但集成测试的定义有点模糊。这意味着隔离测试多个模块。可以是后台的模块，也可以是前端的模块，但不能放在一起。帮助实现这一点的框架是针对您正在使用的技术的代码级集成测试。与Angular应用程序类似，深度集成测试用于测试组件的HTML和CSS，而浅层集成测试仅用于测试两个组件的逻辑。这可以由SDET编写，但通常由开发人员编写。

3) API测试(基于合同的测试)：Pact帮助我们实现这一点。还有其他工具，如rest assured，postman和jmeter，可以帮助测试API端点。Pact帮助测试API在前端的集成，并验证后端的集成。这在微服务中非常流行。这是可以由开发人员或SDET编写的东西。

4)端到端测试:这是SDET唯一负责的事情。这包括根据用户故事对用户流进行测试。它正在一起测试整个堆栈。后端和前端。这允许SDET自动执行用户如何使用应用程序。这也称为黑盒测试。有不同的框架可以帮助实现这一点。硒，量角器，柏树，排毒等。这是SDET的唯一责任。

5)负载测试:这也是SDET要做的事情。使用嘿、jmeter、loadrunner等工具。这些测试允许SDET在系统上启动较重的负载，并检查系统的断点。

6)性能测试:根据页面加载时间、SEO优化程度和页面元素权重，对最终用户的网页性能进行测试。这是由google的灯塔工具实现的，这是一个使用起来很棒的工具。我不知道还有什么比灯塔更令人惊叹的了，因为它给了我们很多数据，我们可以用它来改进我们的网站。这是SDET的主要工作。

7) CI/CD:持续集成和持续部署需要系统的架构知识。这是当您是SDET3或首席QA工程师时可以做的事情。对于亚马逊网络服务和GCP这样的系统，使用像Jenkins和CircleCI这样的CI构建工具，可以建立一个管道，在分支合并到主节点或创建拉入请求时运行所有上述测试。创建管道需要您具备Docker、Kubernetes、Jenkins和您的测试框架的知识。首先将测试停靠，然后构建映像并将其推送到云中的目录，然后使用映像创建一个kubernetes作业，该作业在每次代码中出现更改时运行。

这些是SDET所做的工作级别。理解所有测试框架以及如何将所有测试框架组合在一起需要时间和艰苦的工作。SDET应该了解服务器、http协议、前端、后端、浏览器、缓存、管道管理和测试编排。

Answer 2

是的，当然。您可以编写单元测试，以增加代码库的测试覆盖率。这是来自软件测试工程的非常合格的工作，因为您需要知道代码中发生了什么。这项技能绝对是很棒的！

我建议你看看所谓的“突变覆盖率”。使用突变覆盖率作为比简单单元测试覆盖率更好的度量。突变测试正在改变代码库不同部分的逻辑运算符(生成所谓的“突变体”)，然后运行单元测试，以找出有多少单元测试将失败，以显示其有效性(如果注入突变体后，结果与没有它们时相同-单元测试质量很低，它们不会发现代码库中任何新的注入问题)。