测试的意义在于,在用户消费产出的代码之前,开发者首先消费它,给以其重要的质量保证。
10.1 单元测试
意义:配备专门的测试人员,会让工程师产生依赖,不正视测试代码。
测试工程师是否可依赖:
第三方代码是否可信赖?
在产品迭代过程中,如何继续保证质量?
对于上述问题,如果你的答案是不关心,那么恭喜你,你的项目只能供短时间玩玩,甚至只是个演示产品。
编写可测试代码有以下几个原则:单一职责、接口抽象、层次分离
单元测试:包含断言、测试框架、测试用例、测试覆盖率、mock、持续集成等几个方面,由于Node的特殊性,加入异步代码测试和私有方法的测试这两个部分。
10.2 性能测试
包括负载测试、压力测试和基准测试等。
基准测试:要统计的就是在多少时间内执行了多少次某个方法。然后比较时间。
压力测试:常用的工具是ab, siege, http_load等
第 11 章 产品化
包括工程化、架构、容灾备份、部署和运维等
11.1 项目工程化
目录结构:
构建工具:Makefile唯一的缺陷也许就是跨平台问题,为此才有ant、rake等工具的出现。Node中有Grunt。
编码规范:文档式的约定,代码提交时的强制检查。前者靠自觉,后者靠工具。
代码审查:git除了实现代码托管外,还增强了bug追踪的系统,并且利用git的分支特点,可以很好地实现代码审查。git的分支开发模式非常灵活,非常利于分布式开发。开发者可以很容易地从主干迁出代码,然后进行功能的开发,待开发完毕后,提交回主干,发起合并请求即可。
11.2 部署流程
需要在测试环境中测试后才允许进入生产环境进行线上测试。
部署环境:
部署操作:
11.3 性能
动静分离:
启用缓存:提升服务的速度和避免不必要的计算。前者提升的性能在海量流量面前终有瓶颈,但后者却能够在访问量越大时收益越多。避免不必要的计算,应用场景最多的是缓存。
多进程架构:
读写分离:主要针对数据库而言。读取的速度远远高于写入的速度
11.4 日志
上线运转起来时,问题就接踵而来,与其遇见bug修复它,不如建立健全的排查和跟踪机制,而日志就是实现这种机制的关键。在健全的系统中,完善的日志记录最能够还原问题现场。通过记录日志来定位问题是一种成本较小的方式。这种非结构化、轻量的记录方式容易实现,也容易扩展。
访问日志:
异常日志:
日志与数据库:将日志分析和日志记录分离开来是较好的选择。
分割日志:
11.5 监控报警
监控的点可以很细致,也可以只选主要的指标。
日志监控:对访问日志的监控能实现PV和UV的监控。
响应时间:可以在Niginx一类的反向代理上监控。健康的系统响应时间应该是波动较小的、持续均衡的。
进程监控:
磁盘监控:主要是用量
内存监控:健康的内存使用应当是有升有降。
CPU占用监控:
CPU load监控:
I/O负载:
网络监控:
应用状态监控:
DNS监控:
报警的事项:邮件报警、短信或电话报警
11.6 稳定性
多机器:
多机房:
容灾备份:
11.7 异构共存