1. 单元测试

• 目的：检测程序模块中有无故障存在
• 对象：软件设计的最小单位，与程序设计和编程实现关系密切

2. 集成测试

• 目的：发现与接口有关的模块之间的问题
• 方法：
  非增式集成测试法：对每一个模块进行单元测试；在此基础上按程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。
  增式集成测试法：不断地把待测模块连接到已测模块集（或其子集）上，对待测模块进行测试，直到最后一个模块测试完毕。

3. 确认测试

• 目的：对软件产品进行评估以确定其是否满足软件需求的过程。

4. 系统测试

• 目的：针对系统中各个组成部分进行的综合性检验，证明系统的性能。
• 测试人员要求：系统开发人员不能进行系统测试；系统开发组织不能负责系统测试。

5. 验收测试

• 目的：向用户表明所开发的软件系统能够像用户所预定的那样工作
• 主要任务：
  明确规定验收测试通过的标准；
  确定验收测试方法；
  确定验收测试的组织和可利用的资源；
  确定测试结果的分析方法；
  制定验收测试计划并进行评审；
  设计验收测试的测试用例；
  审查验收测试的准备工作；
  执行验收测试；
  分析测试结果，决定是否通过验收。

用户的评价类型分为:

1. 显式评价

用户明确的给出对物品的评价。如YouTube上的“喜欢”和"不喜欢"

2. 隐式评价

不让用户明确给出对物品的评价，而是通过观察他们的行为来获取偏好信息。如记录用户在纽约时报上的点击记录。用户的实际购买记录。

显示评价的问题：

1. 人们很懒，不愿评价物品
2. 人们会撒谎，或存有偏见
3. 人们不会更新他们的评论

隐式评价的问题：

1. 用户自己的浏览记录不是我自己喜好而去购买，比如我在为朋友选择一件生日礼物而产生的浏览记录。
2. 用户自己的购买记录也不能真实的表现该物品是帮助朋友购买，还是真正的是由于自己的喜好而购买。

基于物品的协调过滤

找出最相似的物品，再结合用户的评价来给出推荐结果
基于模型（物品相似模型）的协同过滤 计算列与列之间的相似度

修正的余弦相似度

为解决“分数贬值”问题，从用户的评价中减去他所有评价的均值。
优点是扩展性好，对于大数据量而言，运算速度快，占用内存少。

实现代码：https://github.com/BubbleM/Python-Recommended/tree/master/chapter3/adjusted_cosine_similarity.py

Slope one 算法

1. 计算所有物品对之间的偏差
2. 利用偏差进行预测

实现代码：https://github.com/BubbleM/Python-Recommended/blob/master/chapter3/slope_one_recommend.py

编写可维护的代码很重要，因为开发人员花费的大部分时间都是在维护他人的代码。确保自己代码的可维护性，以便其他开发人员在此基础上更好的开展工作，提高效率。

可维护代码的特征：

1. 可理解性
2. 直观性（代码中的东西一看就能明白）
3. 可适应性（适应不同数据形式上的变化）
4. 可扩展性（考虑到未来运行对核心功能进行扩展）
5. 可调试性

代码约定

一种让代码变得可维护的简单途径是形成一套代码的书写约定。

可读性

缩进和注释可以带来更可读的代码，在未来则更容易维护。

1. 缩进
   项目团队所有人使用一致的缩进，最常见的缩进大小为4个空格
2. 注释（一般而言，有如下地方需要注释）
   - 函数和方法 描述其目的和用于完成任务所可能使用的算法。陈述事先的假设，如参数代表什么，函数是否有返回值。
   - 大段代码 应在前面放一个描述任务的注释。
   - 复杂的算法 如果使用了一种独特的方式解决某个问题，注释中写明是如何做的。
   - Hack 因为存在浏览器差异，JS代码一般会包含一些hack。

变量和函数命名

适当给变量和函数起名对于增加代码可理解性和可维护性非常重要。

命名规则一般如下：

• 变量名应该为名词 如car
• 函数名应以动词开始 如getName()。返回布尔类型值的函数一般以is开头，如isEnable()
• 变量和函数都应使用合乎逻辑的名字。不要担心长度，长度问题可以通过后期处理和压缩来缓解。

变量类型透明

由于JS中的变量是松散类型的，应避免出现无法表示所包含的数据类型的无用变量名。

有三种表示变量数据类型的方式： (选择其一使用，保证项目一致)

1. 初始化。
   暗示它将来应该如何应用。但是无法用于函数声明中的参数。如

var found = false;  // 布尔型
var count = 1; //数字
var  name = "";  //字符串
var  person = null;   //对象

2. 匈牙利标记法。
   在变量名前加一个或多个字符来指定数据类型。如

o表对象 s表字符串 i表整数 f表浮点数 b表布尔型 var bFound

3. 类型注释。
   放在变量名右边，初始化前面。

var found  /*:Boolean*/  = false;
var person /*:Object*/ = null;

松散耦合

只要应用的某一部分过于依赖另一部分，代码就是耦合过紧，难于维护。

1. 解耦HTML/JavaScript

直接写在HTML中的JavaScript，使用包含内联代码的<script>元素或者是使用HTML属性来分配事件处理程序，都是过于紧密的耦合。

<!--使用<script>的紧密耦合的HTML/JavaScript-->
<script type="text/javascript">
	document.write("Hello World1");
</script>
<!--使用时间处理程序属性值的紧密耦合的HTML/JavaScript-->
<input type="button" value="Click me" onclick="doSomething()"/>

理想情况下，HTML和JavaScript应该完全分离，并通过外部文件和使用DOM附加行为来包含JS。
还有一种耦合情况是在JS中使用innerHTML方式动态插入元素到页面。一般，应避免在JS中创建大量HTML。一般可以在页面直接包含并隐藏标记，等到整个页面渲染好之后，用JS显示它，而非生成它。
如果不分离，调试可能会很麻烦，因为HTML是动态生成的，你可能在页面源码中不能找到。
2. 解耦CSS/JavaScript
最常见的紧密耦合的例子就是使用JS来更改样式

        element.style.color = "red";
	element.style.backgroundColor = "blue";

通过动态更改样式类而非特定样式能降低耦合。
3. 解耦应用逻辑/事件处理程序

function handleKeyPress(event){
	event = EventUtil.getEvent(event);
	if(event.keyCode == 13){
		var target = EventUtil.getTarget(event);
		var value = 5 * parseInt(target.value);
		if(value > 10){
			document.getElementById("error-msg").style.display = "block";
		}
	}
}

这个事件处理程序包含了应用逻辑和事件处理。问题：除了通过事件之外再也没有方法执行应用逻辑，让调试变得困难。
解决办法就是将应用逻辑和事件处理程序相分离。这两者分别处理各自的东西。一个事件处理程序应该从事件对象中提取相关信息，并将这些信息传递给处理应用逻辑的某个方法中。

function validateValue(value){
	value = 5 * parseInt(target.value);
	if(value > 10){
		document.getElementById("error-msg").style.display = "block";
	}
}

function handleKeyPress(event){
	event = EventUtil.getEvent(event);
	if(event.keyCode == 13){
		var target = EventUtil.getTarget(event);
		validateValue(target.value);
	}
}

重构之后的代码可以在不附加到事件的情况下测试代码，更容易创建单元测试或自动化应用流程。
请牢记以下应用和业务逻辑之间松散耦合的原则：

1. 勿将event对象传给其他方法；只传来自event对象中所需的数据。
2. 任何可以在应用层面的动作都应该可以在不执行任何事件处理程序的情况下进行。
3. 任何事件处理程序都应该处理事件，然后将处理转交给应用逻辑。

编程实践

1. 尊重对象所有权
   JavaScript的动态性质使得几乎任何东西在任何时间都可以修改。尊重对象所有权，即在团队合作中你不能修改不属于你的对象。但是，你依然可以通过以下方式为对象创建新的功能：

• 创建包含所需功能的新对象，并用它与相关对象进行交互。
• 创建自定义类型，继承需要进行修改的类型。然后可以为自定义类型添加额外功能。

2. 避免全局量
   最多创建一个全局变量，让其他对象和函数存在其中。单一的全局量的延伸便是命名空间的概念。命名空间包括创建一个用于放置功能的对象。可参考YUI的构建。命名空间很重要的一部分是确定每个人都同意使用的全局对象的名字，并且尽可能唯一，让其他人不太可能也使用这个名字。在大多数情况下，可以是开发代码的公司的名字。命名空间有助于确保代码可以在同一页面上与其他代码以无害的方式一起工作。
3. 避免与null进行比较
   JS不做任何自动的类型检查。如果看到了与null进行比较的代码，尝试使用以下技术替换:

• 如果值应为一个引用类型，使用instanceof操作符检查其构造函数；
• 如果值应为一个基本类型，使用typeof检查其类型；
• 如果是希望对象包含某个特定的方法名，则使用typeof操作符确保指定名字的方法存在于对象上。

4. 使用常量
   尽管JS没有常量的正式概念，但它还是很有用的。这种将数据从应用逻辑分离出来的**，可以在不冒然引入错误的风险的同时，就改变数据。需要抽取的值如下：

• 重复值：任何在多出用到的值都应抽取为一个常量。这就限制了当一个值变了而另一个没变的时候会造成的错误。
• 用户界面字符串：任何用于显示给用户的字符串，都应该被抽取出来以方便国际化。
• URLs:资源位置很容易变更，推荐用一个公共地方存放所有的URL。
• 任意可能会更改的值：如果某个字面量值未来可能会更改，就应抽取出来。

基于用户的协调过滤

找到相似用户。将一个用户与其他用户进行对比，找到相似的人。这里可以用距离表示，即找到距离最近的两个用户。
基于内存的协调过滤 计算行与行之间的相似度。

数据集来源：

1. 用户的浏览记录
2. 其他浏览过该商品的用户的浏览记录

计算距离的算法有以下几种：

1. 曼哈顿距离
   

2. 欧几里得距离（利用勾股定理计算两点间的直线距离）
   

3. 闵可夫斯基（将曼哈顿和欧几里得距离归纳成一个公式）
   
   以上三种方式实现代码请访问： https://github.com/BubbleM/Python-Recommended/blob/master/recommend1.py

4. 皮尔逊相关系数（描述两个变量之间的线性相关程度 评价标准之间的差异）
   

实现:
https://github.com/BubbleM/Python-Recommended/blob/master/recommend2.py

5. 余弦相似度（不足在于并没有很好的解决分数贬值问题）
   

区别：
在数据完整“密集”的情况下使用曼哈顿和欧几里得距离效果最好。
当数据存在“分数膨胀”问题，使用皮尔逊相关系数效果最好。
在数据稀疏，非零值较总体要少得多的情况下使用余弦相似度效果最好。

K最邻近算法

如果只依靠最相似的一个用户来做推荐，这个用户有些特殊的偏好，会直接反映在推荐内容里。解决之一就是找寻多个相似的用户。
实现代码：
https://github.com/BubbleM/Python-Recommended/blob/master/recommend.py

基于用户的协调过滤的弊端：

1. 扩展性
   随着用户数量的增加，其计算量也会增加。
2. 稀疏性
   大多推荐系统中，物品数远大于用户数因此用户仅仅对一小部分物品进行了评价，就造成了数据的稀疏性。

注意作用域

只要能减少花费在作用域上的时间，就能增加脚本的整体性能。

1. 避免全局查找（将一个函数中会用到多次的全局对象存储为局部变量）

function updateUI(){
       	var doc = document;
       	var imgs = doc.getElementsByTagName('img');
       	for(var i=0 , len=imgs.length;i<len;i++){
       		imgs[i].title = doc.title + "image" + i;
       	}
       	var msg = doc.getElementById("msg");
       	msg.innerHTML = "Update complete.";
}

以上函数包含了三个对于全局document对象的引用，如果页面上有多个图片，那么for循环中的document引用就会被执行多次甚至上百次，每次都会要进行作用域链查找。通过创建一个局部变量doc指向document对象，现在函数只有一次全局查找，要快很多。

2. 避免with语句（在性能非常重要的地方必须避免使用with语句。和函数类似，with语句会创建自己的作用域，因此会增加其中执行的代码的作用域链的长度。）

3. 选择正确方法（性能问题的一部分是和用于解决问题的算法或者方法有关的）

• 避免不必要的属性查找

常见的算法类型
O(1) 常数 不管有多少值，执行的时间恒定。一般表示简单值和存储在变量中的值。
O(logn) 对数 总执行时间和值的数量有关，但是要完成算法不一定要获取每个值。如：二分查找
O(n) 线性 总执行时间和值数量直接相关。如：遍历某个数组中的所有元素
O(n^2) 平方 总执行时间和值的数量有关，每个值至少要获取n次。如：插入排序
使用变量和数组要比访问对象上的属性更有效率，后者是一个O(n)操作。

• 优化循环

一个循环的基本优化步骤如下：
(1)减值迭代
大多数循环使用一个从0开始，增加到某个特定值的迭代器。在很多情况下，从最大值开始，再循环中不断减值的迭代器更加高效。
(2)简化终止条件
避免使用属性查找或其他O(n)的操作。
(3)简化循环体
(4)使用后测试循环
最常用的for和while都是前测试循环。do-while这种后测试循环，可以避免最初终止条件的计算，因此运行更快。

• 展开循环

当循环的次数时确定的，消除循环并使用多次函数调用往往更快。如果循环的迭代次数不能事先确定，可以考虑使用一种叫做Duff装置的技术。

软件生命周期

6个阶段：计划、需求分析、设计、程序编写、测试、运行和维护

软件测试在软件开发中的作用：

项目规划阶段：负责整个测试阶段的监控。
需求分析阶段：确定测试需求分析，制定系统测试计划。

测试需求分析是指产品生存周期中测试所需的资源、配置、各阶段评审通过的标准等。

概要设计阶段和详细设计阶段：制定集成测试计划和单元测试计划。
编码阶段：开发相应的测试代码或测试脚本。
测试阶段：实施测试，并提交相应的测试报告。

软件测试过程模型

软件测试过程V模型：明确地表明了测试的不同级别，清晰地展示了软件测试与开发之间的关系

软件测试过程W模型

软件测试环境

测试环境=硬件+软件+网络+数据准备+测试工具
硬件环境：主要是指PC机、笔记本电脑、服务器、各种PDA终端等。
软件环境：主要是软件运行的操作系统。
网络环境：主要是指是C/S结构还是B/S结构。
数据准备：主要指的是测试数据的准备。考虑数据量和真实性。
测试工具：目前测试工具很多，可分为静态测试工具、动态测试工具、黑盒测试工具、白盒测试工具、测试执行评估工具、测试管理工具等。

软件测试

所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。
软件测试是对软件需求分析、设计规格说明好编码的最终复审，是软件质量保证的关键步骤。
应该一开始就假设程序中隐藏着错误，然后测试程序，发现尽可能多的错误。测试是为发现错误而执行程序的过程。

策略

应该在测试之前建立某些策略：黑盒测试和白盒测试是两种最普遍的策略。

黑盒测试：又称数据驱动的测试或输入\输出驱动的测试。使用这种测试方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确执行的环境条件。判定标准是“”穷举输入测试“”

白盒测试：又称逻辑驱动的测试。允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查，从中获取测试数据，遗憾的是常忽略了程序的规范。判定标准是“”“穷举路径测试”

软件测试的原则：

1. 测试用例中一个必需的部分是对预期输出或结果进行定义
   一个测试用例必需包括两个部分:对程序的输入数据的描述；对程序在上述输入数据下的正确输出结果的精确描述。
2. 程序员应该避免测试自己编写的程序。
3. 编写软件的组织不应该测试自己编写的软件。
4. 应当彻底检查每个测试的执行结果。
5. 测试用例的编写不仅应当根据有效和预期的输入情况，而且也应该根据无效和未预料到的情况。
   6.检查程序是否‘未做其应该做的’仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
   7.应避免测试用例用后即弃， 除非软件本身就是一个一次性的软件。
   8.计划测试工作时不应默许假定不会发现错误。
   9.程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
   10.软件测试是一项极富创造性、极具智力挑战性的工作。

人工测试

1.利用错误列表进行代码检查
2.小组代码走查
3.桌面检查
4.同行评审

代码检查与走查是两种主要的人工测试方法。 都要求人们组成一个小组来阅读或直观检查特点的程序。“”头脑风暴会“”的目标是找出错误来，但不必找出改正错误的方法。
代码走查的另一个优点是，一旦发现错误，通常就能在代码中对其进行精确定位，降低了调试的成本。

代码检查

以组为单位阅读代码，它是一系列规程和错误检查技术的集合。

在检查进行时，主要进行两项活动：
1.由程序编码人员逐条语句讲述程序的逻辑结构。
2.对着历来常见的编码错误列表分析程序

用于代码检查的错误列表：
代码检查过程的一个重要部分就是对照一份错误列表，来检查程序是否存在常见错误。
1.数据引用错误
2.数据声明错误
3.运算错误
4.比较错误
5.控制流程错误
6.接口错误
7.输入\输出错误

代码走查

与代码检查很相似，都是以小组为单位进行代码阅读，是一系列规程好错误检查技术的集合。而而走查会议的规程不同，不同于仅阅读程序或使用错误检查列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参与会议。作用是提供了启动代码走查和质疑程序员逻辑思路及其设想的手段。

桌面检查

人工查找错误的第三种过程是古老的桌面检查方法。桌面检查可以视为由单人进行的代码检查或代码走查：由一人阅读程序，对照错误列表检查程序，对程序推荐测试数据。

同行评分

同行评分是一种依据程序整体质量，可维护性，可扩展性，易用性和清晰性对匿名程序进行评价的技术。目的是为程序员提供自我评价的手段，而非发现错误。

建议综合最多的测试方法来设计严格的程序测试，因为每一种测试方法都有其独特的优势和弱点。推荐的步骤是先使用黑盒测试方法来设计测试用例，然后视情况需要使用白盒测试方法来设计补充的测试用例。

标准化

要让所有的数据变得可用我们可以对其进行标准化，最常用的方法是将所有数据都转化为0到1之间的值。（将每个值减去最小值，并除以范围）

需要进行标准化的情形：

1. 我们需要通过物品特性来计算距离
2. 不同特性之间的尺度相差很大

在如何海量的数据时代，如何从海量的商品中选择相关产品？在1100万首iTunes曲目中，肯定有一部分音乐是你特别喜爱的，那么该如何找到它们呢？

• 专家点评推荐（影评家）
• 通过商品本身寻找（我喜欢披头士的一张专辑，所以会认为他们的另一张专辑也不错）

数据挖掘不仅仅是用来推荐商品，或是单单给商人增加销量，同时也能扩展我们的能力，让我们能够处理海量的数据，如让潘多拉音乐站提供个性化的音乐列表。

数据挖掘的重点在于找到数据中的模式。

协调过滤

利用某兴趣相投、拥有共同经验之群体的喜好来推荐用户感兴趣的信息，个人通过合作的机制给予信息相当程度的回应（如评分）并记录下来以达到过滤的目的进而帮助别人筛选信息，回应不一定局限于特别感兴趣的，特别不感兴趣信息的纪录也相当重要。

协调过滤的实现的三步骤：收集数据——找到相似用户和物品——进行推荐

协调过滤，由于使用的是用户产生的各种数据，因此又称为社会化过滤算法。协调过滤算法倾向于推荐那些已经很流行的物品，这类推荐系统会让流行的物品更为流行，冷门的物品更无人问津。