@Author:丁晶晶
本期导读：本期技术周报，闫国虹继为我们带来单测时需要用到的基础知识（之二）：窥探Android Touch事件内幕（二），大家可以在回顾上一次之后结合来看；测试同学对于spring框架尤其是IOC容器比较默认，赵晨曦为我们带来基础介绍文章；本期其他技术文章我们偏向于介绍测试基础知识、前言知识及spring、redis、mysql较深层次的调研文章。
一、原创文章
窥探Android Touch事件内幕系列之二@闫国虹
上一篇文章我们主要介绍了Android UI事件处理机制-基于监听器方式、基于回调方法，同时从View的角度分析了Touch事件分发流程。这一篇文章我们将从ViewGroup角度来分析Touch事件分发流程，之前计划的关于Robolectric如何测试相关事件分发流程将会在后续『单元测试之-自定义View』中进行介绍。
Spring IOC容器中bean对象的配置和引用@赵晨曦
Spring 中使用IOC容器来管理对象，通过将对象添加到IOC容器中来达到对象的自动管理和解耦的作用。对象通过使用xml文件配置和使用注解配置。
二、移动测试技术
我来教教你前端自动化单元测试如何做
在这里首先需要知道单元测试的目的及结果：
使代码健壮，质量高，兼容各种临界点；
减少 QA 测试报告的反馈，提高自我影响力；
保证代码的整洁清晰。
如果需要刨根问底追究为什么需要进行单元测试，那我们可以开始讲讲实际项目开发中遇到的一些问题
WEB性能测试研究
随着网络技术的迅速发展，尤其是WEB及其应用程序的普及，各类基于WEB的应用程序以其方便、快速，易操作等特点不断成为软件开发的重点。与此同时，随着需求量与应用领域的不断
三、后端测试技术
如何用测试驱动出100%测试覆盖率的代码
DDM是一个简洁的前端领域模型库，如我在《DDM: 一个简洁的前端领域模型库》一文中所说，它是我对于DDD在前端领域中使用的一个探索。
简单地来说，这个库就是对一个数据模型的操作——增、删 、改，然后生成另外一个数据模型。
Jenkins+Docker搭建持续集成测试环境
本文将重点讨论在Jenkins管理的持续集成以及测试的环境中，我们如何通过引入Docker来优化资源的配置，提高整个环境的性能以及稳定性。
四、通用测试技术
基于CMMI的软件测试过程设计
现在，很多软件组织都在走CMMI之路，这是以软件工程过程的标准化来保证软件质量的一种规范性行为。那么，软件测试在CMMI中是如何定义和实施的呢？作为一名资深软件测试人员，今天来阐述一下基于软件能力成熟度模型集成的软件测试。
敏捷软件测试常见的七个误区
敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法，是能够应对快速变化的需求的一种软件开发能力，它作为一种新型的开发模式，被越来越多地应用到软件项目
五、新技术学习－QA也疯狂
MySQL InnoDB辅助索引
辅助索引（Secondary Index）也就是非聚集索引，或者二级索引。在一张表中只能创建一个聚集索引，但是可以创建多个辅助索引。它是一种B+Tree索引，在辅助索引中叶子节点中并不包含全部的行数据记录。在B+Tree的叶子结点中除了包含一个索引列的键值之外，结点中还包含一个书签，这个书签的作用是在通过辅助索引查询记录的时候，告诉存储引擎在哪里可以找到对应的行数据。InnoDB的表示是索引组织表，辅助索引的书签就是相应行数据的聚集索引的索引列。当通过辅助索引来查找数据的时候，辅助索引会通过页级的指针来找到主键索引的主键，然后通过该主键索引找到相应的行数据。
java 回调函数
回调函数，或简称回调，是指通过函数参数传递到其它代码的，某一块可执行代码的引用。这一设计允许了底层代码调用在高层定义的子程序。以上定义出自维基百科。
在java编程中经常会遇到这个方法:Collections.sort(List list, Comparator c);这个方法就是一个比较典型的回调方法了。它的使用常常是在第二个参数哪里传入一个Comparator的匿名内部类。
redis中的数据类型
redis中有五种数据类型：字符串类型，散列类型，列表类型，集合类型，有序集合类型。值得注意的是redis中没有整形和float类型。文章中有详情介绍
Spring MVC ContentNegotiatingViewResolver内容协商视图解析
内容协商视图ContentNegotiatingViewResolver是Spring3.0中新增加的一种视图解析器。他不负责具体的视图解析器，而是作为一个中间角色根据请求所要求的MIME类型来从上下文种选择一个合适的视图解析器来解析视图。通过这种视图我们可以混合使用多种视图技术。最常见是混合使用jsp,xml,json的视图，我也将会使用这三个作为例子来展开文章。
六、测试杂谈
在小米六年的研发工程师讲述：小米大树之测试之痛
一直想写一系列的笔记，记录整个小米六年的研发工作中实际遇到的困难，以及这一大群人如何不可避免的走向大公司氛围，又如何慢慢打破定势，苦于自己拖延症影响，现在才开始总结。
共分三个部分：基础架构之痛、测试之痛、产品进度之痛。本篇是第二部分。
一个有趣的小 Bug 避免了一场大灾难
我要讲述的这个故事是，在一个下午，视频游戏中的小bug造成的故障，如何促使我去清除来自于软件的潜在危险漏洞，而该软件被来自于世界各地的企业和政府使用。这件事还让我明白了一个实践教训，即你为什么要将代码中发现的问题报告上去，即使一开始它们看上去那么微不足道。
