星城哈哈

# 7.补充学习

# 补充资料

# 软件测试的分类

第一部分：软件测试的分类

  • 按测试执行阶段划分

    单元测试、集成测试、系统测试、验收测试（正式验收测试、Alpha测试、Beta测试）

  • 按测试技术划分

    白盒测试、黑盒测试、灰盒测试

  • 被测试对象是否运行划分

    动态测试、静态测试（文档检查、代码走查、界面检查）

  • 按不同的测试手段划分

    手工测试、自动化测试

  • 按测试包含的内容划分

    功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试、压力测试、负载测试、恢复测试

  • 其他测试

    冒烟测试、回归测试、探索性测试/自由测试（测试思维）

第二部分：接下来对软件测试分类进行一个说明

第三部分：测试工具

SVN，Git——>版本控制管理工具

禅道——>Bug管理工具

Fiddler——>抓包，定位问题你

postman，jmeter，soapui——>接口测试

Loadrunner，Jmeter——>性能，压力测试

# 2019年Javascript测试概览

https://medium.com/welldone-software/an-overview-of-javascript-testing-in-2019-264e19514d0a

这是一篇非常好的国外的博文，同时也是2018年Javascript测试概览的作者。这里有2018年的译文：

展望 2018 年 JavaScript Testing (opens new window)

在文中很好介绍到了测试类型，并举了大量的例子，非常全面。

# 什么是TDD？

测试驱动开发（TDD）总结——原理篇 (opens new window)

TDD （Test Driven Development） 在不同的圈子、不同的角色的认知中可能会有不同的理解，有人可能会理解成 ATDD（Acceptance Test Driven Development），也有人可能会理解成 UTDD（Unit Test Driven Development），为了避免产生歧义，文章涉及到 TDD 专指 UTDD（Unit Test Driven Development），即 「单元测试驱动开发」。

TDD 的目标

Kent Beck 在他的著作《Test-Driven Development》一书中提到：“代码简洁可用这句言简意赅的话，正是 TDD 所追求的目标”。

对于如何保证“代码简洁可用”可以使用分而治之的方法，先达到“可用”目标，再追求“简洁”目标。

可用： 保证代码通过自动化测试。

代码简洁： 在不同阶段人们对简洁的理解程度也不一样，不过遵循的原则差不多，例如 OOD 的 SOLID 原则，Kent Beck 的 Simple Design 原则等。

虽然有很多因素妨碍我们得到整洁的代码，甚至可用的代码，无需征求太多意见，只需要采用 TDD 的开发方式来驱动出简洁可用的代码。

# Karma的前世今生

2016年的文章，由淘宝前端团队书写：http://taobaofed.org/blog/2016/01/08/karma-origin/

通篇介绍了karma的工作原理及实现原理，非常有价值的文章。

# ava框架的配置文件

{
	"ava": {
		"files": [
			"test/**/*",
			"!test/exclude-files-in-this-directory",
			"!**/exclude-files-with-this-name.*"
		],
		"helpers": [
			"**/helpers/**/*"
		],
		"sources": [
			"src/**/*"
		],
		"match": [
			"*oo",
			"!foo"
		],
		"cache": true,
		"concurrency": 5,
		"failFast": true,
		"failWithoutAssertions": false,
		"environmentVariables": {
			"MY_ENVIRONMENT_VARIABLE": "some value"
		},
		"tap": true,
		"verbose": true,
		"compileEnhancements": false,
		"require": [
			"@babel/register"
		],
		"babel": {
			"extensions": ["js", "jsx"],
			"testOptions": {
				"babelrc": false
			}
		}
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
  • files：用于选择测试文件的glob模式数组。带有下划线前缀的文件将被忽略。默认情况下，仅选择具有js扩展名的文件，即使该模式与其他文件匹配。指定extensions并babel.extensions允许其他文件扩展名
  • helpers：用于选择帮助文件的glob模式数组。这里匹配的文件永远不会被视为测试。默认情况下，仅选择具有js扩展名的文件，即使该模式与其他文件匹配。指定extensions并babel.extensions允许其他文件扩展名
  • sources：一组glob模式，用于匹配文件，这些文件在更改时会导致重新运行测试（在监视模式下）。有关详细信息，请参阅 (opens new window)
  • match：通常在package.json配置中没用，但等同于在CLI上指定--match
  • cache：缓存编译的测试和帮助文件node_modules/.cache/ava。如果false，文件缓存在临时目录中
  • failFast：一旦测试失败，停止运行进一步的测试
  • failWithoutAssertions：如果设置成false，那么如果没有运行断言，则测试失败
  • environmentVariables：指定要供测试使用的环境变量。此处定义的环境变量会覆盖其中的环境变量process.env
  • tap：设置成 true，启用TAP报告
  • verbose：设置成 true，启用详细输出
  • snapshotDir：指定用于存储快照文件的固定位置。如果快照最终位于错误的位置，请使用此选项
  • compileEnhancements：设置成 false，禁用了 power-assert (opens new window)，否则有助于提供更具描述性的错误消息， 并检测t.throws()断言的不当使用
  • extensions：未使用AVA的Babel预设进行预编译的测试文件的扩展名。请注意，文件仍然会被编译为启用power-assert和其他功能，因此您可能还需要设置compileEnhancements为false文件是否为有效的JavaScript。设置此"js"值会覆盖默认值，因此请确保在列表中包含该扩展名，只要它不包含在内babel.extensions
  • require：在运行测试之前需要额外的模块。工作进程中需要模块
  • babel：测试文件特定的Babel选项。有关详细信息，请参阅Babel配置 (opens new window)
  • babel.extensions：将使用AVA的Babel预设进行预编译的测试文件的扩展。设置此选项会覆盖默认"js"值，因此请确保在列表中包含该扩展名。
  • timeout：AVA中的超时行为与其他测试框架中的行为不同。AVA在每次测试后重置计时器，如果在指定的超时内没有收到新的测试结果，则强制测试退出。这可用于处理停滞的测试。请参阅我们的超时文档 (opens new window)以获取更多选

请注意，在CLI上提供文件会覆盖该files选项。

# 参考资料

上次更新: 2020/11/7 下午6:47:53

←