10测试
从单元测试、性能测试两个维度进行讲解，重视测试，并在项目中使用，事半功倍
单元测试
好代码，比较好写单元测试，相互促进 不好的代码，需要重构，再写单元测试
- 原则
- 1、单一职责，一段代码只做一件事，方便编写测试
- 2、接口抽象，针对接口进行测试，具体实现变化不影响测试单元
- 3、层次分离，mvc 逐层测试，逐层保证
- 1、断言：断言就是单元测试中用来“保证最小单元是否正常”的检测方法；
- 测试第一步，看功能是否正常，对基本的判断；
- assert 模块：断言库大多都是基于assert模块进行封装和扩展的，这包括著名的should.js断言库
- 2．测试框架：
- 断言检查失败会停止整个应用
- 实际应该：记录下抛出的异常并继续执行，最后生成测试报告；应用测试框架
- 它本身并不参与测试， 主要用于管理测试用例和生成测试报告，
- mocha
- 测试风格
- TDD 测试驱动开发 suite test
- TDD关注所有功能是否被正确实现，每一个功能都具备对应的测试用例
- TDD的表述方式偏向于功能说明书的风格
- BDD 行为驱动开发 describe it
- BDD关注整体行为是否符合预期，适合自顶向下的设计方式
- BDD的表述方式更接近于自然语言的习惯
- 单元测试框架 mocha
- TDD 测试驱动开发 suite test
- 测试报告
- 报告格式
- mocha --reporters 可以查看所有报告格式
- mocha -R json
- json 通用、html-cov 可视化查看代码覆盖率
- 看文档
- 报告格式
- 测试风格
- 3、测试代码的文件组织
- 测试代码放test文件夹
- 4、测试用例
- 基本包括：至少一个断言、正向测试和反向测试
- (对于node还有)异步测试 done、超时设置如何设置 this.timeout(500)
- 5、测试覆盖率：（重要指标）
- 如何判断单元测试对代码的覆盖情况， 我们需要直观的工具来体现。
- jscover模块 （java）、lanket模块 （纯js模块，解决jscover不足）（都过时）
- 6、mock
- 模拟异常
- 我们通过伪造fs.readFileSync()方法抛出错误来触发异常。
- 同时为了保证该测试用例不影响其余用例，我们需要在执行完后还原它
- 推荐模块 muk（过时）
- 7、私有方法
- rewire模块提供了一种巧妙的方式实现对私有方法的访问。
- 原理：引入文件，设置全局__get__()方法，eavl执行
- 8、工程化、自动化
- 工程化 Makefile
- 持续集成 travis-ci
- 其他：
- supertest 支持express等web框架测试
目前使用框架：
- 之前都是偏于零散模块处理，单元测试，后边发展出集成度高的测试框架Jest等
- 后端：
- 前端交互：
性能测试
- 检测已有功能是否能满足生产环境的性能要求，能否承担实际业务带来的压力
- 负载测试
- 1、基准测试
- 在多少时间内执行了多少次某个方法
- benchmark模块
- 并不简单的统计次数时间
- 它对测试有着严密的抽样过程
- 2、压力测试
- 吞吐率、
- 响应时间、
- 并发数
- 工具：
- ab、
- ab -c 10 -t 3
http://localhost:8001/ - 十个并发数、3秒内
- Requests per second：
- 这是我们重点关注的一个值，它表示服务器每秒能处理多少请求，是重点反映服务器并发能力的指标。
- 这个值又称RPS或QPS。
- 结果的每一个字段的意义，可以查看书中具体的对应解释
- ab -c 10 -t 3
- siege、
- http_load
- ab、
- 3、基准测试驱动开发 BDD
- Benchmark Driven Development
- 大致思路：
- (1) 写基准测试。(2) 写/改代码。(3) 收集数据。(4) 找出问题。(5)回到第(2)步。
- 帮助写测试
- 4、测试数据与业务数据的转换
- 评估业务量，以便系统可以胜任在线任务量
- 假设每天访问量是100w，集中在10小时以内，
- 那么100w/100h= qp约等于27.7，
- 每秒处理27.7个请求才能胜任业务