《软件测试面经》专题

测试用来验证非测试的代码是否按照期望的方式运行的 Rust 函数。测试函数体通常执行如下三种操作： 设置任何所需的数据或状态 运行需要测试的代码 断言其结果是我们所期望的 让我们看看 Rust 提供的专门用来编写测试的功能：test 属性、一些宏和 should_panic 属性。 作为最简单例子，Rust 中的测试就是一个带有 test 属性注解的函数。属性（attribute）是关于 Rust

22.13.7.测试报告 测试任务默认生成以下结果. 一份HTML测试报告 一个与Ant的JUnit测试报告任务兼容的XML.这个格式与许多其他服务兼容,如CI serves 结果是有效的二进制,测试任务会从这些二进制结果生成其他结果。 有一个独立的TestReport任务类型会根据一些Test任务实例生成的二进制源码生成一个HTML报告.使用这种测试类型,需要定义一个destinationDir

22.13.6.测试分组 JUnit和TestNG允许为测试方法精密分组. 对于分组JUnit的测试类与测试方法,JUnit4.8引入了类别的概念.9该测试任务允许您设定JUnit包括或者排除某些类的规范。 例22.12.JUnit分类 build.gradle test { useJUnit { includeCategories 'org.gradle.junit.Ca

22.13.3.测试过滤 从Gradle1.10开始,可以根据测试任务名进行特点的任务测试,过滤与在构建脚本的段落中引入/排除测试任务(-Dtest.single, test.include and friends)是两种不同的机制.后者是基于文件,如测试实现类的物理位置.选择文件级的测试会不支持那些被测试等级过滤掉的一些有趣的测试脚本.下面的这些有些已经被实现,有些是将来会实现的: 过滤特定等级

22.13.1.执行测试 测试从main构建过程中分离出来的,运行在一个单独的JVM中执行.Test任务允许控制这些如何发生. 有许多属性用于控制测试过程如何启动.这包括使用诸如系统属性，JVM参数和Java可执行文件。 可以指定是否要并行执行测试.Gradle通过同时运行多个测试进程提供并行执行测试.每个测试进程在同一时间只能执行一个测试,为了充分利用这一特性,一般不需要为tests任务做什么特

当运行单元测试的时候，Gradle 会输出一份 HTML 格式的报告以方便查看结果。Android plugin 则将所有连接设备的测试报告都合并到一个 HTML 格式的报告文件中。所有测试结果都以 XML 文件形式保存到 build/reports/androidTests/ 中（类似于 JUnit 的运行结果保存在 build/reports/tests 中)。可以自定义路径： android

正如前面提到的，connectedCheck 需要一个已连接设备。这个过程依赖于 connectedDebugAndroidTest task，因此 connectedDebugAndroidTest task 也会运行。该 task 会执行以下内容： 确认应用和测试应用已被构建（依赖于 assembleDebug 和 assembleDebugAndroidTest） 安装这两个应用 运行测试

Android Studio 1.1 添加了单元测试支持，详细请看 Unit testing support。本章的其余部分描述的是 “instrumentation tests”。利用 Instrumentation 测试框架可以构建独立的测试 APK 并运行在真实设备（或模拟器）中进行测试。

5.4 测试报告 当运行单元测试的时候，Gradle 会生成一份 HTML 报告以便于查看测试结果。 Android plugins 在这个基础上扩展了 HTML 报告，以合并所有已连接设备上的测试结果。 5.4.1 单工程报告 在运行测试的时候工程会自动的生成报告，默认位置是： build/reports/androidTests 这和 jUnit 报告的位置 build/reports/tes

5.3 测试Android库 测试 Android 库工程的方式和应用工程是一样。 仅有的不同就是整个库(包括它的依赖)会作为一个依赖库被自动的添加到测试应用中。测试APK的测试结果不仅包括它自己代码的测试，还包括 Android 库的以及库的所有依赖的测试。 库的 manifest 被合并到测试应用的 manifest 中(这种情况就和任何工程引用这个库是一样的) androidTest 任务的

5.2 运行测试 正如前面所提到的，引导任务 connectedCheck 需要一个已经连接的设备才能运行。 这会依赖 androidTest ，所以 androidTest 也会被运行。这个任务做了以下事情： 确保应用和测试应用已经被构建(依赖 assembleDebug 和 assembleTest ) 安装这两个应用 运行测试 卸着这两个应用 如果同时有多个连接的设备，那么所有的测试会在所有

英文原文：http://emberjs.com/guides/testing/testing-models/ 单元测试方案和计算属性与之前单元测试基础中说明的相同，因为DS.Model集成自Ember.Object。 [Ember Data[模型可以使用moduleForModel助手来测试。 假定有一个Player模型，模型定义了level和levelName属性。通过调用levelUp可以增加

英文原文：http://emberjs.com/guides/testing/testing-routes/ 单元测试方案和计算属性与之前单元测试基础中说明的相同，因为Ember.Route集成自Ember.Object。 路由测试可以通过集成测试或者单元测试来进行。集成测试对路由的测试具有更好地覆盖性，因为路由通常用来执行过渡和数据加载，这些测试在完整上下文中更加容易测试，而独立上下文则没有那么

英文原文：http://emberjs.com/guides/testing/unit/ 单元测试用于测试代码的一个小片段，确保其功能正常。与集成测试不同，单元测试被限定在一个范围内，并且不需要Ember应用运行。 全局 vs 模块 过去如果没有作为一个全局变量加载整个Ember应用，要对应用进行测试非常困难。通过使用模块（CommonJS，AMD等）来编写应用，可以只加载被测试的部分，而不用将其

英文原文：http://emberjs.com/guides/testing/test-helpers/ 测试Web应用最大的问题是代码都是事件驱动的，因此很可能出现异步的情况（例如输出与输入不是按照顺序发送）。其衍生问题就是代码可能会以任何可能的顺序执行。 下面这个例子能很好的说明此问题：当一个用户点击了两个按钮，一个接着一个，分别从不同的服务器加载数据。这种情况响应的时间是不同的。 当编写测试