1. 到达率
到达率是指产品的市场普及程度，即查看网站或使用服务的人数。到达率和盈利能力是正相关关系：访问网站的人越多，购买产品或服务的人就越多。从开发的角度来看，搜索引擎优化（SEO）对到达率的影响最大，所以我们会在QA方案里包含SEO。2. 功能
人们一旦访问了你的网站或使用了你的服务，能否把用户留下很大程度上取决于网站功能的质量：一个能像广告宣传那样工作的网站更有可能吸引回头客。与其他几个维度不同，功能测试一般都可以自动执行。3. 可用性
功能关心的是功能的正确性，而可用性评估的是人机交互（HCI）。根本问题是：“这个功能是以对目标受众有用的方式交付的吗？”这个问题经常被换成“它易用吗？”，尽管追求易用性经常跟灵活性或能力是相对的：程序员眼中的“容易”可能跟不懂技术的用户眼中的“容易”不一样。换句话说，评估可用性时你必须考虑目标受众。因为可用性评估的根本输入是用户，所以可用性评估一般无法自动完成。然而，你的QA
方案中应该包含用户测试。4. 审美
审美是四个维度中最主观的，因此也是跟开发最不相关的一个维度。尽管跟网站审美相关的开发问题没有几个，但QA 方案中还是应该包括网站审美的常规评审。把网站展示给有代表性的样本受众，看他们是否觉得已经过时，或者是不是没能激起你所期望的响应。记住，审美具有时间敏感性（审美标准会随着时间而发生变化），并且因人而异（受到某一受众喜爱的东西可能完全激不起其他受众的兴趣）。
通俗点讲
- 人气。
- 内容有没有料。
- 功能好不好用。
- 丑不丑。
5.2 逻辑与展示
从广义上来讲，网站上有两个“领域”：逻辑（经常被叫作“业务逻辑”，因为商业味儿比较浓，所以在这里没用这个词）和表示。
你应该尽可能地在逻辑和表示之间划出清晰的界限。这有很多种方式，本书将把重点放在JavaScript
模块对逻辑的封装上。另一方面，表示，将是对HTML、CSS、多媒体、JavaScript 和jQuery 之类的前端库的一种结合。
通俗点讲
- 处理数据的是业务
- 处理外观的是展示
单元测试和集成测试
- 单元测试：粒度非常细，是对单个组件进行测试以确保其功能正确。
- 集成测试：对多个组件甚至整个系统之间的交互进行测试。（我认为“系统测试”属于集成测试）
5.4 QA技术概览
页面测试（Mocha.js）
页面测试，顾名思义，用来测试页面的表示和前端功能。这同时涉及单元测试和集成测 试。我们会用Mocha 进行页面测试。跨页测试（Zombie.js）
跨页测试是对从一个页面转到另一个页面的功能的测试。比如电子商务网站上的结账功能，通常要跨越多个页面。因为这种测试会涉及多个组件，所以一般被当作集成测试。这个测试用的是Zombie.js。逻辑测试
逻辑测试会对逻辑域进行单元和集成测试。它只会测试JavaScript，跟所有表示功能分开。去毛
去毛不是要找错误，而是要找潜在的错误。去毛的一般概念是找出可能有错误的区域，或者可能在将来导致错误发生的问题代码。我们会用JSHint做去毛。- 链接检查（LinkChecker）
链接检查（确保你的网站上没有破损的链接）属于“唾手可得”的那一类测试。对简单的项目做链接检查看起来可能没有必要，但简单项目也会发展成复杂项目，破损的链接也将会出现。越早把链接检查放到QA过程里越好。链接检查属于单元测试（链接有效或者无效）。我们会用LinkChecker
做链接检查。
通俗点讲
又有一大堆东西要去学。@_@
Mocha：
Zombie.js：
5.5 运行你的服务器 监控工具
nodemon 他可以监听node代码是否有改动，改动后重启node服务器。保证当前服务器与最新代码匹配。同时他有一个Grunt插件。作者后续会讲解Grunt。
5.6 页面测试 下载测试框架 Mocha
npm install --save-dev mocha // 只在开发环境中使用mocha注意，我们用的是--save-dev 而不是--save，这是告诉npm 要把这个包放在开发依赖项中，不要放在运行时依赖项里。这样当我们部署网站的现场实例时，可以减少项目的依赖项。
通俗讲：
在我们写代码的时候会用到测试的一些node工具，但当产品正式上线后用户是不需要这些测试工具的。所以node思维是把模块分为两类
开发环境和生产环境。不同的环境去依赖不同的模块。
可以看看这篇文章：
开发环境、生产环境、测试环境的基本理解和区别
首先为mocha创建一个存放目录，这里放置在静态文件public/vendor/目录下，便于客户端访问。
把你用到的第三方库放在一个特殊的目录中是个好主意，比如vendor。这样比较容易分清哪些代码是需要你负责测试和修改的，哪些代码你不应该触碰。
mkdir public/vendor
cp node_modules/mocha/mocha.js public/vendor
cp node_modules/mocha/mocha.css public/vendor测试通常需要一个浏览器端的assert（或expect）函数。这里可以用Chai 断言库。
相关链接：npm install --save-dev chai
cp node_modules/chai/chai.js public/vendor说实话学到这里我是崩溃的。但没办法有困难就要上，谁叫我们弱小的躯体却怀揣了一颗牛逼的心了。
使用测试作者在这里用了一个小技巧，在特定环境下启动测试。
通过localhost:3000?test=1的方式向路由提供一个test值来判断是否测试。
具体实现
我们准备用一些中间件来检测查询字符串中的test=1。它必须出现在我们定义的所有路由之前：
app.use(function(req, res, next){
res.locals.showTests = app.get('env') !== 'production' && req.query.test === '1';
next();
});在布局模板views/layouts/main.handlebars中加入如下代码：
<head>
<title>Meadowlark Travel</title>
{{#if showTests}}
<link rel="stylesheet" href="/vendor/mocha.css">
{{/if}}
<script src="//code.jquery.com/jquery-2.0.2.min.js">
</head>这里最重要的就是showTests。 在中间件上可以根据查询参数为它传值。模板引擎在根据showTests来判断是否加载mocha模块。上一章提到过的路由与中间件加载顺序。如果路由匹配到后就不会继续接下来的代码，所以这个中间件应该加载到路由的最上面。
{{#if showTests}}
<div id="mocha"></div>
<script src="/vendor/mocha.js">
<script src="/vendor/chai.js">
mocha.ui('tdd');
var assert = chai.assert;
<script src="/qa/tests-global.js">
{{#if pageTestScript}}
<script src="{{pageTestScript}}">
{{/if}}
mocha.run();
{{/if}}
</body>这里多了一个tests-global.js这是用于配置测试的JS脚本。他是一个全局测试脚本用于所有页面通用测试。后面会正对每个页面去写特有的测试脚本。
创建一个目录/public/qa/ 专门用于存放测试代码。发现没有所有与浏览器直接加载的代码全部放在这个静态文件里方便。出了脚本代码还有css,图片等。反正服务端不直接使用的代码都丢在这里然后分文别类，现在这个文件夹里包含：
img : 用于存放图片
vendor : 用于存放一下浏览器用的插件和库。
qa ：用于存放测试代码。
对这些一定要保持有一定的影响，慢慢的这些思维变成自己的条件反色。养成好习惯很重要。
suite('Global Tests', function(){
test('page has a valid title', function(){
assert(document.title && document.title.match(/\S/) && document.title.toUpperCase() !== 'TODO');
});
});（一堆代码没看懂，主要是chaijs mocha还没学。路漫漫~~~）
这样就可以进行测试了，http://localhost:3000/?test=1 已经可以看见测试页面了。
单页面测试接下来就是针对页面的测试
创建一个public/qa/tests-about.js 文件确保关于页面上总是有一个指向联系我们页面的链接。
suite('"About" Page Tests', function(){
test('page should contain link to contact page', function(){
assert($('a[href="/contact"]').length);
});
});这段代码的大致含义是判断页面有没有一个指向/contact的a标签
设置路由
app.get('/about', function(req, res) {
res.render('about', {
fortune: fortune.getFortune(),
pageTestScript: '/qa/tests-about.js' // 这里是模板替换
});
});还记得布局模板中
{{#if pageTestScript}}
<script src="{{pageTestScript}}">
{{/if}}路由到about是会对于加载tests-about.js测试配置，同理其他页面也可以在路由下添加属于自己的测试配置。
5.7 跨页测试
(这个先放放)
5.8 逻辑测试项目创建文件夹qa/用于存放逻辑测试。
创建单元测试，qa/tests-unit.js。
var fortune = require('../lib/fortune.js');
var expect = require('chai').expect;
suite('Fortune cookie tests', function(){
test('getFortune() should return a fortune', function(){
expect(typeof fortune.getFortune() === 'string');
});
});现在可以使用Mocha来进行测试
mocha -u tdd -R spec qa/tests-unit.js5.9 去毛
因为JS是一个弱类型语言，他的自由性也会带来一些意外的出错的可能新。
Douglas Crockford提供了一套JS在编程过程中的使用规则可以有效的避免例如隐身类型转换等问题。
这里使用的工具是JSLint或JSHint
npm install -g jshint只用指定需要检查的文件即可
jshint meadowlark.js也可以直接安装至编辑器中。
5.10 链接检查LinkChecker 可以进行链接检查
linkchecker http://localhost:3000Grunt可以看看慕课的grunt教程，讲的很全面。
首先安装Gruntnpm install -g grunt-cli
npm install --save-dev gruntnpm install --save-dev grunt-cafe-mocha
npm install --save-dev grunt-contrib-jshint
npm install --save-dev grunt-exec在项目根目录创建Gruntfile.js进行Grunt配置
module.exports = function(grunt) {
// 加载插件
[
'grunt-cafe-mocha',
'grunt-contrib-jshint',
'grunt-exec',
].forEach(function(task){
grunt.loadNpmTasks(task);
});
// 配置插件
grunt.initConfig({
cafemocha: {
all: { src: 'qa/tests-*.js', options: { ui: 'tdd' }, }
},
jshint: {
app: ['meadowlark.js', 'public/js/**/*.js',
'lib/**/*.js'],
qa: ['Gruntfile.js', 'public/qa/**/*.js', 'qa/**/*.js'],
},
exec: {
linkchecker:
{ cmd: 'linkchecker http://localhost:3000' }
},
});
// 注册任务
grunt.registerTask('default', ['cafemocha','jshint','exec']);
};本文所有引用部分文字都源自《Node与Express开发》