软件测试培训笔记

《单元测试及持续集成实战》  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)、反向工程：在某些开发环境中，如Eclipsse，可以使用IDE所提供的反向工程能力从测试代码自动生成必要的类、方法等；(7)、代码注释：不需要另外单独的文档，而是在测试类中对每个测试方法对应的业务场景，输入和期望的输出进行详细的描述；(8)、小步前进：当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用TDD实现。

TDD测试案例的编写：采用传统的功能测试技术，集中功能测试，集中容易出现问题的模块的测试工作。(1)、案例应尽量模拟正常使用场景，深入测试测试案例再考虑白盒内容。TDD的难易程度可以通过测试案例的深入程度来调节；(2)、全面的功能性测试应该尽量做到正常值、边界值、异常值；核心的代码如有必要，最好能做到白盒的语句、分支、路径覆盖，但此时也要考虑案例与代码过于相近，不好维护的情况；(3)、测试案例和测试数据应该尽量简单，容易理解；(4)、为了避免对其它代码过多的依赖，可以实现简单的桩函数等；(5)、如果内部状态非常复杂或者应该判断流程而不是状态，可以通过辅助输出日志字符串的方式进行验证。

TDD只适用于功能性明确的工程项目，不适用于某些探索性的，输入输出不确定的开发，比如密码系统，人工智能，安全等领域的研发。

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)的方式进行尽量快速地验证，以确保新提交的变化不会造成新的问题。如果在集成的过程中出现异常，则应当快速的反馈给相关的人员。

构建是将源代码放在一起，并验证软件可以作为一个一致的单元运行的过程；验证活动一般包括编译、测试、审查和部署。

持续集成的价值：减少风险；减少重复过程；任何时间、任何地点生成可部署的软件；增强项目的可见性；建立团队对开发产品的信心；免费的测试专家----编译器。

持续集成要素：统一的代码库；自动构建；自动测试；每个人每天都要向代码库主干提交代码；每次代码递交后都会在持续集成服务器上触发一次构建；保证快速构建；模拟生产环境的自动测试；每个人都可以很容易的获取最新可执行的应用程序；每个人都清楚正在发生的状况；自动化的部署。

持续集成原则：所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败；开发人员每天至少向版本控制库中提交一次代码；开发人员每天至少需要从版本控制库中更新一次代码到本地机器；需要有专门的集成服务器来执行集成构建，每天要执行多次构建；每次构建都要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回顾会议)。