archive-gh-me/node-interview
1
0
Fork 0
mirror of https://github.com/ElemeFE/node-interview.git synced 2026-01-18 16:12:44 +00:00
Code Issues Projects Releases Wiki Activity

Fix index & update test.md

Browse Source
This commit is contained in:
Lellansin 2017-03-21 18:45:23 +08:00
parent c0bc2c786a
commit 56cbdf4df7
2 changed files with 19 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -178,7 +178,7 @@ Hi, 欢迎来到 ElemeFE, 如标题所示本教程的目的是教你如何通过
* [`[Basic]` 集成测试](sections/test.md#集成测试)
* [`[Basic]` 基准测试](sections/test.md#基准测试)
* [`[Basic]` 压力测试](sections/test.md#压力测试)
* [`[Doc]` Assert (断言)](sections/test.md#断言)
* [`[Doc]` Assert (断言)](sections/test.md#assert)
### 常见问题

34
sections/test.md
View File

@ -1,11 +1,11 @@
# 测试
* `[Basic]` 测试方法
* `[Basic]` 单元测试
* `[Basic]` 基准测试
* `[Basic]` 集成测试
* `[Basic]` 压力测试
* `[Doc]` Assert (断言)
* [`[Basic]` 测试方法](#测试方法)
* [`[Basic]` 单元测试](#单元测试)
* [`[Basic]` 基准测试](#集成测试)
* [`[Basic]` 集成测试](#基准测试)
* [`[Basic]` 压力测试](#压力测试)
* [`[Doc]` Assert (断言)](#assert)
## 简述
@ -29,13 +29,13 @@ C
D
```
如上述情况, ABCD 是逻辑层, EFGH 等是更低一次层 (比如工具层等), 当你为了功能 A 的 BUG 修改了 H 的代码, 那么实际受影响的功能除了 A 之外还有 BC, 如果你有针对每一个逻辑的测试, 那么修改了 H 的代码之后, 跑一遍测试即可保证对 H 的修改不会影响到 BC.
如上述情况, ABCD 是逻辑层, EFGH 等是更低一次层 (比如工具层等), 当你为了功能 A 的 BUG 修改了 H 的代码, 那么实际受影响的功能除了 A 之外还有 BC, 如果你有针对每一个逻辑的测试, 那么修改了 H 的代码之后, 跑一遍测试即可保证对 H 的修改不会影响到 BC (如果有影响, 那么相应的测试会报错). 利用这种特性, 你还可以基于测试去做重构, 在通过原有测试的情况下, 即表明新的重构版本可以替代原有的版本.
而这样的效果, 只有当覆盖率达到了一定程度 (通常是 80% 以上, 90% 以上为最理想) 才能实现, 如果测试的覆盖率低, 无法覆盖到多种情况, 那么测试对你的项目可能是没有用甚至起到反作用的 (让你误以为你的修改没问题而发布等).
写测试是否会拖累开发进度, 这要视具体情况而定. 这里需要考虑开发进度需要包含功能和品质两个方面, 单纯的代码速度不能完全代表开发进度. 测试在适当的情况下可以保证项目的品质从而得到更好的开发进度.
写测试是否会拖累开发进度要视具体情况而定. 需要考虑到, 开发进度包含功能和品质两个方面, 单纯写代码的速度不能完全代表开发进度. 测试在适当的情况下可以保证项目的品质从而得到更好的开发进度.
如上述的例子, 在修改功能 A 的 BUG 的时候, 如果你不知道 H 会影响到 BC 又没有测试的话, 那么开发 BC 的同学可能会出现 **"昨天还好好的, 今天怎么就不能用了?"** 的情况.
如上述的例子, 在修改功能 A 的 BUG 的时候, 如果你不知道 H 会影响到 BC 又没有测试的话, 那么开发 BC 的同学可能会出现十分经典的 **"昨天还好好的, 今天怎么就不能用了?"** 的情况.
当然写测试拖累开发进度的情况也是客观存在的, 通常是有以下几种情况:
@ -49,13 +49,13 @@ D
你可以通过测试来避免坑爹的同事在某些逻辑中写出死循环, 在通常的测试中加上超时的时间, 在覆盖率足够的情况下, 就可以通过跑出超时的测试来排查出现死循环以及低性能的情况.
### 测试方法
## 测试方法
#### 黑盒测试
### 黑盒测试
黑盒测试 (Black-box Testing), 测试应用程序的功能, 而不是其内部结构或运作. 测试者不需了解代码、内部结构等, 只需知道什么是应用应该做的事, 即当键入特定的输入, 可得到一定的输出. 测试者通过选择`有效输入`和`无效输入`来验证是否正确的输出. 此测试方法可适合大部分的软件测试, 例如集成测试 (Integration Testing) 以及系统测试 (System Testing).
#### 白盒测试
### 白盒测试
白盒测试 (White-box Testing) 测试应用程序的内部结构或运作, 而不是测试应用程序的功能 (即黑盒测试). 在白盒测试时, 以编程语言的角度来设计测试案例. 白盒测试可以应用于单元测试 (Unit Testing)、集成测试 (Integration Testing) 和系统的软件测试流程, 可测试在集成过程中每一单元之间的路径, 或者主系统跟子系统中的测试.
@ -79,7 +79,7 @@ D
常用的测试覆盖率框架 [istanbul](https://github.com/gotwarlost/istanbul).
当然覆盖率并不完全是由单元测试贡献, 在单元测试之上还有集成测试等. 更多关于覆盖率的内容可以看看这里----[测试覆盖（率）到底有什么用?](http://www.infoq.com/cn/articles/test-coverage-rate-role).
当然覆盖率并不完全是由单元测试贡献, 在单元测试之上还有集成测试等. 更多关于覆盖率的内容可以参见[测试覆盖（率）到底有什么用?](http://www.infoq.com/cn/articles/test-coverage-rate-role)
### Mock
@ -101,6 +101,8 @@ Mock 与 Stub 的区别参见: [Mocks Aren't Stubs](https://martinfowler.com/art
集成测试也称综合测试、组装测试、联合测试, 将程序模块采用适当的集成策略组装起来, 对系统的接口及集成后的功能进行正确性检测的测试工作. 集成测试可以是黑盒的, 也可以是白盒的, 其主要目的是检查软件单位之间的接口是否正确, 而集成测试的对象是**已经经过单元测试的模块**.
例如你可以在本地将项目中的 web app 启动, 并模拟接口调用:
```javascript
describe('Path API', () => {
// ...
@ -175,7 +177,7 @@ suite.add('RegExp#test', function() {
ab -n 100 -c 10 https://ele.me/
```
可以看到一些数据:
可以得到如下的详细数据:
```
Server Software: Tengine/2.1.1
@ -217,7 +219,7 @@ Percentage of the requests served within a certain time (ms)
100% 491 (longest request)
```
可以设置规模以及并发情况. 在比规模不大/需求不复杂的情况下, ab 以及 wrk 也可以用于做压力测试.
与前者相比, ab 等工具可以设置规模以及并发情况. 在比规模不大/需求不复杂的情况下, ab 以及 wrk 也可以用于做压力测试.
## 压力测试
@ -245,7 +247,7 @@ assert(!condition, 'Sth wrong');
等等情况的一种简化. 并且提供了丰富了 `equal` 判断, 对于对象类型也有深度/严格判断等情况支持.
Node.js 中内置的 `assert` 模块也是属于断言模块的一种, 但是官方在文档中有注明, 该内置模块主要是用于内置代码编写时的基本断言需求, 并不是一个通用的断言库 (***not intended to be used as a general purpose assertion library**)
Node.js 中内置的 `assert` 模块也是属于断言模块的一种, 但是官方在文档中有注明, 该内置模块主要是用于内置代码编写时的基本断言需求, 并不是一个通用的断言库 (**not intended to be used as a general purpose assertion library**)
### 常见断言工具