软件测试的例子？

Question

我在学习测试。到目前为止，我有点理解其中的要点，但还是有点困惑。

我想到了一个像Photoshop这样的应用程序。单元测试将是开发人员测试“取消”按钮。集成测试将是QA团队测试已合并到菜单中的所有按钮，并查看如何更改整个程序。系统测试将是团队也测试应用程序如何在操作系统环境中运行。

这个准确吗？

Answer 1

一如以往，我个人的意见如下：)

首先是一个评论:我指的是从软件工程师的角度出发的测试，并且主要考虑的是自动化测试。

单元-测试一个小代码单元，一个函数或一个类.放弃很多人犯的错误，用它测试一个“功能”。

例如，如果您期望您的按钮将验证给定的输入，然后导航到另一个页面，这很可能是2个单元(可能更多)。触发第二个单元的Button，验证，如果结果正常，则触发导航(可能是第三个单元)。

因此，在单元测试中，我们试图模拟依赖项，因为如果不这样做，那么我们也测试它们以及它们之间的集成。

集成测试一般测试两个模块之间的通信。对于模块，我的意思是它可以是一个完整的应用程序，一个系统，一个包，一个组件，一个类，.

这些测试应该真正集中于测试模块之间的通信。如果它们也用于测试模块中的功能，那么这可能很容易完成，但是由于运行的代码数量多，很难确定错误。因此，应该将其与单个模块的测试方法相结合。

例如，您有一个功能“优化照片”。它利用一种识别优化潜力的算法，然后在照片中应用多个滤波器。算法和过滤器将是额外的模块。现在运行一个测试来优化照片。很明显，它将测试多个模块，而不是两个模块。这是集成测试的问题之一，它的范围很快就会变大。为此，我们可以尝试模拟所有我们不想测试的模块。这是更多的实现工作，但使测试更快和更精确。

系统测试采用上述“优化照片”功能的集成测试，去掉所有的模拟(每个模块都经过测试)，然后进行系统测试。系统测试是在系统的各个模块中运行的测试。它仍然侧重于模块的集成，但现在系统范围很广。

请注意，外部依赖项，如来自外部系统的数据，仍然应该被模拟。

一个测试的范围越大，它就越容易崩溃，同时，就越难找到问题的根源。

因此，在经过彻底测试的系统中，您将有大量的单元测试、相当多的集成测试和一些系统测试。

这样，在小范围内测试错误的可能性就很高。这使得查找错误变得容易得多:-)

最后，请注意:您可以编写代码以实现功能，然后对其应用测试。

或者您可以考虑测试您的功能，然后编写代码和测试。

区别在于，在第二种情况下，您的代码设计将包含测试。在第一种情况下，代码设计很可能使编写测试变得非常困难。