软件测试基础概念

其实在软件开发中，在一个团队中有特定的软件工程师进行测试，可能我们在编写代码的时候都是直接去发现了Bug再去解决Bug的，其实这样的话可能会有潜在的Bug我们不知道，被疏忽了，或者说在写了很久很久之后，才发现这个Bug，但是已经深入到你的项目中了，其实在我们开发ios的时候会有这么一个框架XCTest，如果我们能够很好的应用它能帮我们减少一些问题的产生。

下面是苹果的官方文档关于测试的一些解释

All software is built using composition; that is, smaller components are arranged together to form larger, higher-level components with greater functionality until the goals and requirements of the project are met. Good testing practice is to have tests that cover functionality at all levels of this composition. XCTest allows you to write tests for components at any level.


It’s up to you to define what constitutes a component for testing—it could be a method in a class or a set of methods that accomplish an essential purpose. For example, it could be an arithmetic operation, as in the calculator app used as an example in the Quick Start chapter. It could be the different methods that handle the interaction between the contents of a UITableView and a list of names you maintain in your code’s data structures. Each one of those methods and operations implies a component of the app’s functionality and a test to check it. The behavior of a component for testing should be completely deterministic; the test either passes or fails.

The more you can divide up the behavior of your app into components, the more effectively you can test that the behavior of your code meets the reference standards in all particulars as your project grows and changes. For a large project with many components, you’ll need to run a large number of tests to test the project thoroughly. Tests should be designed to run quickly, when possible, but some tests are necessarily large and execute more slowly. Small, fast running tests can be run often and used when there is a failure in order to help diagnose and fix problems easily.

Tests designed for the components of a project are the basis of test-driven development, which is a style of writing code in which you write test logic before writing the code to be tested. This development approach lets you codify requirements and edge cases for your code before you implement it. After writing the tests, you develop your algorithms with the aim of passing the tests. After your code passes the tests, you have a foundation upon which you can make improvements to your code, with confidence that any changes to the expected behavior (which would result in bugs in your product) are identified the next time you run the tests.

Even when you’re not using test-driven development, tests can help reduce the introduction of bugs in your code as you modify it to enhance features and functionality. You incorporate testing in a working app to ensure that future changes don’t modify the app’s existing behavior other than in your planned ways. As you fix bugs, you add tests that confirm that the bugs are fixed. Tests should exercise your code, looking for both expected successes and expected failures, to cover all the boundary conditions.

翻译过来就是

所有的软件都是用合成的;也就是说，将较小的组件组合在一起，形成更大的、更高级别的组件，并具有更大的功能，直到满足项目的目标和需求。良好的测试实践是在该组合的所有级别上进行覆盖功能的测试。XCTest允许您为任何级别的组件编写测试。

由您来定义测试组件的组成部分——它可以是一个类中的方法，或者是完成一个基本目标的一组方法。例如，它可以是一个算术运算，就像在快速启动章节中使用的计算器应用程序一样。它可以是处理UITableView内容和在代码的数据结构中维护的名称列表之间的交互的不同方法。这些方法和操作中的每一个都意味着应用程序功能的一个组成部分和一个检查它的测试。测试组件的行为应该是完全确定的;测试要么通过，要么失败。

你越能将你的应用程序的行为划分为组件，你就可以更有效地测试你的代码的行为在你的项目增长和变化时符合所有细节的参考标准。对于一个包含许多组件的大型项目，您需要运行大量的测试来彻底测试这个项目。在可能的情况下，测试应该被设计为快速运行，但是有些测试必须是大的，并且执行得比较慢。小型、快速运行的测试可以经常运行，并且在出现故障时使用，以帮助诊断和修复问题。

为项目的组件设计的测试是测试驱动开发的基础，这是一种编写代码的风格，在编写测试代码之前编写测试逻辑。这种开发方法可以让您在实现代码之前将需求和边界情况编码。在编写测试之后，您开发了您的算法，目的是通过测试。在您的代码通过测试之后，您就有了一个基础，您可以对代码进行改进，并相信在下一次运行测试时，对预期行为的任何更改(这会导致产品中的错误)都被识别出来。

即使您没有使用测试驱动开发，测试也可以帮助您在修改代码时引入bug，以增强特性和功能。您在一个工作应用程序中加入了测试，以确保未来的更改不会改变应用程序的现有行为，而不是您计划的方式。当您修复bug时，您将添加确认bug被修复的测试。测试应该执行您的代码，寻找预期的成功和预期的失败，以覆盖所有的边界条件。

这里再介绍下测试驱动开发也就是TDD的含义，简单来说其实就是先去根据需求写测试，不通过测试再去继续改，然后通过之后就去进行组合全部测试，然后测试如果不通过了，就进行重构，然后去更新失败的测试，然后再进行组合到全部测试中。

其实测试配合组件化来使用的好处是十分明显的，而且测试还有分为很多种，比如说故障注入，回归测试，静态测试，动态测试等等这里也就不一一描述了。