《单元測试及持续集成实战》 201409
1. 质量(Quality)：一组内在特性满足需求的程度；一个系统、构件或过程满足特定需求(顾客或用户须要或期望)的程度。
软件质量管理：确定一个软件产品的质量目标，建立实现这些目标的计划。监督、调整软件计划、软件工作产品、活动和质量目标，以满足顾客、终于用户须要和期望的过程。
一般在软件企业中，提到质量管理(quality management, QM)主要是两个方面：质量控制(qualitycontrol, QC)、质量保证(quality assurance, QA)。
质量控制(QC)主要是指对文档的评审、代码复查、单元測试、集成測试、系统測试、验收測试等等。
质量保证(QA)主要是指通过过程评审、产品审计等对中间环节过程、工作产品质量的监控来确保终于产品质量符合要求。
QC、QA在某种情况下专指角色。譬如測试人员被称作QC角色；质量保证人员被称为QA角色。
质量管理(QM)除质量控制、质量保证之外。还包含确定质量方针、目标和职责。质量体系建设、质量策划、质量改进等活动(EPG(质量体系建设)工作)。
QC各环节包含：(1)、各种文档的走查；(2)、各种文档的评审；(3)、代码复查；(4)、单元測试。(5)、集成測试。(6)、系统測试；(7)、验收測试。(8)、准生产/投产測试。
2. 单元測试(UnitTest, UT)：是针对软件设计的最小单位----程序模块，进行正确性检验的測试工作。
其目的在于发现每一个程序模块内部可能存在的差错。
假设把全部測试环节比作是清洗一台机器：(1)、系统測试就是清除机器外面的尘土；(2)、集成測试就是保证机器各个部件的接头处干净；(3)、单元測试就是清洗各零件的内部。
单元測试的目的：(1)、缺陷排除前移使得企业质量成本降低；(2)、尽早发现缺陷。节省项目总工作量；(3)、改进质量的本质----尽早消除缺陷。
软件项目管理四要素：成本、范围、进度、质量。
项目经理在项目管理期间中最为重要的任务是均衡项目四要素。
3. 单元測试方法简单介绍：
什么是单元？：(1)、面向对象的软件开发：以Class(类)的方法作为測试的最小单元。以方法的内部结构作为測试的重点。(2)、结构化的软件开发：以模块(函数、过程)作为測试的最小单元。
单元測试内容：(1)、面向代码的代码复查(静态单元測试)；(2)、面向单元的黑盒測试(单元功能測试)；(3)、面向单元的白盒測试(单元覆盖率測试)。
单元測试是程序猿的基本职责，也是程序猿的基本职业素养能力，必须对自己编写的代码认真负责。
编码人员除了编码、单元測试(静态、动态)外，还包含集成測试、參与系统測试案例走查等，还有辅助项目管理等等工作。
4. 单元測试的策划：项目測试时要充分考虑单元測试过程并为各过程留出足够多的时间：(1)、单元測试计划；(2)、单元測试设计；(3)、单元測试实现；(4)、单元測试运行。(5)、单元測试评估。
以上活动QA、项目经理在检查项目计划时须要验证这些计划是否存在。
单元測试计划：时间进度表；工作量；任务分配；资源安排；測试工具。结束标准(能够设置量化标准)；风险分析(譬如被压缩工作量、技能不足等)；风险应对；输出单元測试计划文档。
单元測试设计：对哪些单元进行測试；被測单元与其他模块之间的关系；測试策略选择；怎样设计測试案例；怎样设计单元測试代码；输出单元測试案例文档。
单元測试实现：编写測试案例；測试脚本编写；測试驱动构建；桩构建。输出測试案例；输出測试代码和脚本。
单元測试运行：搭建測试环境；运行測试脚本。记录測试结果。跟踪缺陷；回归測试；输出单元測试报告。
5. 单元測试的裁剪：不建议裁减掉整个单元測试。
单元測试环节的裁剪策略：(1)、范围裁剪。(2)、过程裁剪。
单元測试的范围裁剪，假设測试时间不够，可优先考虑下面部分：(1)、对项目目标达成最重要的功能；(2)、用户最经常使用的功能；(3)、对系统安全性能影响最大的功能；(4)、和“钱”最有关系的功能。(5)、对用户最重要的功能；(6)、在开发过程早期就能够測试的部分；(7)、代码最复杂的部分；(8)、开发得最匆忙的部分。(9)、前一版本号或相似项目中造成问题的部分或相关部分；(10)、相似项目中花费大量维护费用的部分或相关部分。(11)、需求或设计中不清晰的部分；(12)、开发者觉得最可能有问题的部分；(13)、一旦有问题会造成客户最大损失的部分。(14)、一旦有问题会造成最大维护成本的部分。(15)、风险/时间比最大的部分。
6. 单元測试的跟踪监控：
跟踪监控的形式：(1)、项目周例会的召开(最佳实践)：本周完毕情况；下周计划情况(获取承诺)。风险问题。眼下各种定性、定量指标的监控。
进度、工作量、范围、质量、风险问题、承诺、数据、关键软硬件资源、人员參与等。
(2)、项目里程碑的召开：阶段工作成果；下阶段是否开展及开展工作计划等等。阶段定性定量指标监控；风险问题等等。(3)、事件驱动。
项目跟踪监控的两大件：(1)、进度表：任务是否在要求时间点结束。(2)、质量目标表：任务是否达到完毕的标准。
项目跟踪监控的新理念：质量目标 & 进度跟踪的配合使用。
7. TDD測试驱动开发：(1)、TDD以測试作为编程的中心，它要求在编写不论什么代码之前，首先编写定义代码功能的測试案例。编写的代码要通过案例，并不断进行重构优化；(2)、TDD不是为了全面測试，而是在质量保证的前提下提高开发的效率。
測试驱动开发强调測试并不应该是负担。而应该是帮助减轻工作量的方法。
TDD測试驱动开发的基本流程：(1)、定义应用程序的功能要求，能够记录成一个TODO列表。(2)、熟悉应用程序的功能区域。确定要使用的单项功能项或功能要求；(3)、创建验证要求的測试列表；(4)、为功能或要求定义接口和类；(5)、编写測试代码；(6)、运行測试案例不通过。(7)、依据測试编写/改动产品代码；(8)、运行測试直到全部測试都通过。(9)、整理、重构代码。并运行測试代码通过；(10)、反复上面的步骤。
TDD不仅仅是測试技术，它的目的也不是仅仅用来測试代码。TDD是一种面向对象的开发方法。
(1)、TDD首先是一种分析方法。它迫使程序猿细致思考要做什么和不要做什么，特别是各种例外的情况。并用程序语言正式的写下来。这就好像在程序猿的任务和程序猿之间签订了一个清晰的正式合同。(2)、TDD是一种设计方法。程序猿必须清晰的定义程序的验收条件才干写出它的Function Test。
而此时程序猿无需清除内部怎样实现的。程序猿仅仅须要考虑Class的界面和功能。这不就是面向对象的封装设计。(3)、TDD是一种重构和优化的方法。我们总希望代码能够美丽、运行效率高。所以我们会不断地去改进。
測试驱动开发的最佳实践：(1)、简化：保持測试案例、源代码尽可能的简单。以验证业务为首要目标。(2)、业务导向：功能性測试，针对每一个须要验证的业务场景进行測试，而不是对代码的每一个方法进行測试。(3)、測试隔离：每一个測试类都能够单独运行。不依赖于其他不论什么測试。也能够一起运行，而不会互相干扰，提高案例的可维护性。(4)、測试列表：在開始开发之前，先列出全部须要的測试，并在开发中不断维护该列表，避免遗忘一些必要的測试；(5)、及时重构：开发出来的单元測试和功能代码都须要不断重构，改进代码的可读性，可维护性，降低冗余代码等。(6)、反向project：在某些开发环境中。如Eclipsse，能够使用IDE所提供的反向project能力从測试代码自己主动生成必要的类、方法等。(7)、代码凝视：不须要另外单独的文档，而是在測试类中对每一个測试方法相应的业务场景，输入和期望的输出进行具体的描写叙述；(8)、小步前进：当功能单元较大时。为降低难度，可分解为多个更小的功能单元，并逐一用TDD实现。
TDD測试案例的编写：採用传统的功能測试技术，集中功能測试。集中easy出现故障的模块的測试工作。
(1)、案例应尽量模拟正常使用场景，深入測试測试案例再考虑白盒内容。TDD的难易程度能够通过測试案例的深入程度来调节；(2)、全面的功能性測试应该尽量做到正常值、边界值、异常值；核心的代码如有必要。最好能做到白盒的语句、分支、路径覆盖，但此时也要考虑案例与代码过于相近。不好维护的情况。(3)、測试案例和測试数据应该尽量简单。easy理解。(4)、为了避免对其他代码过多的依赖，能够实现简单的桩函数等。(5)、假设内部状态非常复杂或者应该推断流程而不是状态，能够通过辅助输出日志字符串的方式进行验证。
TDD仅仅适用于功能性明白的project项目。不适用于某些探索性的。输入输出不确定的开发。比方password系统。人工智能，安全等领域的研发。
8. 白盒測试：(1)、測试依据：依据程序的内部结构。比方语句的控制结构。模块间的控制结构以及内部数据结构等进行測试；(2)、长处：能够对程序内部的特定部位进行覆盖測试。(3)、缺点：无法检验程序的外部特性，无法对未实现规格说明的程序内部欠缺部分进行測试；(4)方法举例：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、路径覆盖。
几种经常使用的白盒逻辑覆盖方法：(1)、语句覆盖。(2)、判定覆盖；(3)、条件覆盖。(4)、判定----条件覆盖。(5)、路径覆盖。
语句覆盖：在測试时首先设计若干个測试案例。然后运行被測程序，使程序中的每一个可运行语句至少运行一次。
这里所谓“若干个”当然是越少越好。
语句覆盖在測试被測试程序中，除去对检查不可运行语句有一定作用外，并没有排除被測程序包含错误的风险。
由于被測程序并不是语句的无序堆积。语句之间的确存在着很多有机的联系。
判定覆盖：按判定覆盖准则进行測试是指。设计若干測试案例。运行被測程序，使得程序中每一个推断的取真分支和取假分支至少经历一次，即推断的真假值均曾被满足。
条件覆盖：是指设计若干測试案例，运行被測试程序以后，要使每一个推断中每一个条件的可能取值至少满足一次。
判定/条件覆盖：要求设计足够的測试案例。使得推断中每一个条件的全部可能至少出现一次，而且每一个推断本身的判定结果也至少出现一次。
路径覆盖：按路径覆盖要求进行測试是指，设计足够多的測试案例要求覆盖程序中全部可能的路径。
由此看出。各种结构測试方法都不能保证程序的正确性，必须多种方法结合进行。我们能够通过代码复查来补充单元測试。适当降低单元測试难度。
測试仅仅是为了尽可能的挑选错误，而不是用来证明測试对象是正确的。
9. 黑盒測试：(1)、測试依据：依据用户能看到的规格说明，即针对命令、信息、报表等用户界面及体现它们的输入数据域输出数据之间的相应关系，特别是针对功能进行測试。(2)、长处：能站在用户立场上进行測试；(3)、缺点：不能測试程序内部特定部位。
假设规格说明有误，则无法实现；(4)、方法举例：等价类划分、边值分析、因果图。
等价类：(1)等价类划分：是典型的黑盒測试方法。设计測试案例时。全然不考虑程序内部结构。(2)、方法：把程序的输入域划分成若干部分，然后从每一个部分中选取少数代表性数据当作測试案例。有效等价类和无效等价类。(3)、选取理由：穷举測试的案例数量太大，以至于无法完毕。促使我们在大量的案例中选取一部分作为測试案例。
有效等价类指的是对程序的规格说明是有意义的、合理的输入数据所构成的集合。利用有效等价类能够检验程序是否实现了规定的功能。有效等价类能够是一个，也能够是多个。
无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。利用无效等价类可检验程序容错能力。无效等价类至少应有一个，也可能有多个。
等价类划分的原则：(1)、假设输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。(2)、输入条件规定了输入值的集合，或是规定了“必须怎样”的条件，则可确定一个有效等价类和一个无效等价类。(3)、假设我们确知，已划分的等价类中各元素在程序中的处理方式是不同的。则应将此等价类进一步划分成更小的等价类。
10. 改良后的单元測试：(1)、单元測试是针对软件设计的适当单位----大单元(改良1)，进行正确性检验的測试工作。
其目的在于发现“大单元”模块内部可能存在的差错；(2)、专业測试人员与开发者一一结对(改良2)的方式。(3)、先黑盒。后辅助白盒分析补充測试案例(改良3)。
11. 静态单元測试：代码复查(code review)。一种通过复查代码提高代码质量的过程。
代码复查俗称“静态的单元測试”。通俗讲。大家帮那个同事看看他写的代码，替他把把关。
代码复查要求代码适当稳定；同一时候由于代码复查可能会大规模改动代码。使得曾经做的单元測试失效，因此应放在单元測试前面。
代码复查发现的问题是内部逻辑问题。其測试的内容及效果不是能够通过系统測试、验收測试等外部測试替代的。缺少代码复查环节，质量控制上就少了有力环节。
选取不同的代码复查自己主动化工具，如PMD、findbugs、sourcemonitor、C++ Test、Jtest、FindBug、checkStyle等等。
12. 结对编程：两位程序猿在一台电脑前工作。一个负责敲入代码，而另外一个实时检视每一行敲入的代码。操作键盘和鼠标的程序猿被称为“驾驶员”，负责实时评审和协助的程序猿被称为“领航员”。
领航员检视的同一时候还必须负责考虑下一步的工作方向。比方可能出现的问题以及改进等。
13. 配置管理(configurationmanagement, CM)：採用技术手段和行政手段进行管理和监督的一套规范化方法。包含，对配置项的功能特性和物理特性加以标识，并将其文件化；控制这些特性的变更；报告变更进行的情况和变更实施的状态。并验证与规定需求的一致性。
配置项(configurationitem, CI)：是配置管理的指定实体。包含软件产品的全部组成元素(技术文档、计算机程序、数据文件和分包商的软件部件。
比如源代码、运行码、系统环境定义、数据库定义、參数文件、编译程序、数据转换程序、安装程序等)。
基线(BaseLine)：是描写叙述一个或多个配置项以及构成配置项的相关实体，一般在项目或产品过程各阶段的结束点形成，其形成标志是有一个或多个软件配置项通过验证与确认而获得认可。基线为持续地评价配置项提供稳定的基础。
版本号(Version)：一组配置项在某一时刻或某一特定点的集合。
配置管理(CM)的目的是通过配置标识、配置控制、配置状态报告、配置审计等来建立和维护产品生命周期中的工作产品一致性和完整性。
配置管理各库介绍：(1)、开发库：仅供开发者个人使用的开发工作环境。由开发者自己管理；(2)、配置库：用于存储和管理变更受控的工作产品，供项目组/团队及其相关人员共同使用，由版本号管理员管理；(3)、产品库：用于存储和管理已形成产品基线并可公布的软件产品。
公司有且仅有一个产品库。是向客户公布软件产品的唯一源头。(4)、构建库：进行产品构建(从源代码生成运行码)的环境，由版本号管理员负责管理，在构建过程中不能进行变更操作，要保证源代码和运行码的一致性；(5)、測试库：进行产品測试的环境，由版本号管理员负责管理。包含搭建測试环境及更新測试环境中的版本号；(6)、配置管理库：开发库、配置库、构建库、測试库、产品库统称为配置管理库。
14. 产品集成：包含计划、集成和公布三个主要活动。在集成的同一时候对接口进行管理。
计划中的关键元素：集成方案、集成顺序、集成环境配置、Build方案。
集成的目标：将分模块编码后得到的各个分离的构件或子系统进行连接。合并成一个统一的系统。
接口管理目标：确保接口之间的兼容性。降低集成失败的可能。
15. 持续集成(continuousIntegration, CI)：是一种软件开发实践。即团队开发成员经常集成它们的工作，通常每一个成员每天至少集成一次。也就意味着每天可能会发生多次集成。每次集成都通过自己主动化的构建(包含编译、公布、自己主动化測试)来验证，从而尽早地发现集成错误。
持续集成要求开发者频繁地提交他们的所完毕的工作产品。这个频率一般是至少每天一次，有时候能够多次。
每次集成会通过自己主动化构建(automated build)的方式进行尽量高速地验证，以确保新提交的变化不会造成新的问题。假设在集成的过程中出现异常，则应当高速的反馈给相关的人员。
构建是将源代码放在一起，并验证软件能够作为一个一致的单元运行的过程；验证活动一般包含编译、測试、审查和部署。
持续集成的价值：降低风险。降低反复过程；不论什么时间、不论什么地点生成可部署的软件；增强项目的可见性；建立团队对开发产品的信心；免费的測试专家----编译器。
持续集成要素：统一的代码库。自己主动构建；自己主动測试。每一个人每天都要向代码库主干提交代码。每次代码递交后都会在持续集成server上触发一次构建；保证高速构建；模拟生产环境的自己主动測试；每一个人都能够非常easy的获取最新可运行的应用程序；每一个人都清晰正在发生的状况。自己主动化的部署。
持续集成原则：全部的开发者须要在本地机器上做本地构建，然后再提交的版本号控制库中。从而确保他们的变更不会导致持续集成失败；开发者每天至少向版本号控制库中提交一次代码。开发者每天至少须要从版本号控制库中更新一次代码到本地机器；须要有专门的集成server来运行集成构建，每天要运行多次构建。每次构建都要100%通过；每次构建都能够生成可公布的产品。修复失败的构建是优先级最高的事情。
持续集成第二版：仅仅维护一个源代码仓库；自己主动化build。让你的build自行測试；每人每天都要向mainline提交代码；每次提交都应在集成计算机上又一次构建mainline；保持高速build；让每一个人都能轻易获得最新的可运行文件。每一个人都能看到进度。自己主动化部署。
持续集成的分级管理模型。包含构建管理、系统部署、自己主动測试和分析报告四个维度五个等级，贯穿软件开发全过程。
自己主动化构建工具：ApacheAnt、Phing、NAnt.
持续集成(CI)：(1)、CI要求开发团队能够频繁地集成开发和測试工作，以便尽早发现问题。降低项目风险；(2)、CI事实上是由一系列的最佳实践所构成：源代码的版本号控制和管理、日构建、冒烟測试、代码复查、自己主动部署等；(3)、持续集成提供产品质量的高速反馈。保证随时拥有可工作的软件产品。
持续集成的长处：(1)、尽早排除缺陷，避免集成时爆发大量问题，降低质量成本；(2)、面向客户交付，不论什么时间、不论什么地点生成可部署的软件；(3)、使得系统測试尽早開始，測试人员尽早介入。(4)、採用免费的測试人员----编译器；(5)、确保良好开发环境。提升开发效率。(6)、降低项目管理(尤其是版本号管理)的成本。约10%；(7)、添加项目管理的可视性。(8)、降低项目风险。
敏捷开发强调UT、CI，敏捷开发最佳实践：(1)、增量迭代式开发；(2)、面向客户交付的开发模式；(3)、需求的优先级排序(产品待办列表)。(4)、任务拆分成细粒度的管理方法(多级项目规划)；(5)、项目跟踪监控时的每日站立会议(不要超过15分钟)。(6)、跟踪监控的公示(看板、燃尽图)，避免项眼下松后紧；(7)、加强单元測试、代码复查。强调測试驱动开发(test driven development, TDD)。(8)、引入持续集成等开发环境(持续集成)。(9)、引导客户积极參与开发过程(客户紧密參与)。(10)、当规模较小时，沟通无需文档驱动时。兴许补文档；(11)、鼓舞项目组成员去主动学习项目已定义过程的能力；(12)、持续过程改进(自适应，sprint回想会议)。
