第二周博客之一-测试笔记基础

软件测试概念：

IT，即信息科技和产业。

软件：一系列按照特定顺序组织的计算机数据和指令的集合。程序（代码）+数据（数据库）+文件（需求文档）

软件测试：使用人工和自动手段运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

1、功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

2、性能测试：软件性能测试是在交替进行负荷和强迫测试时常用的术语。需求在文档或质量保证、测试计划中定义。软件性能测试一般包括负载测试和软件压力测试。

软件生命周期及各阶段相关工作：

软件生命周期（Systems Development Life Cycle, SDLC）：需求调研--需求分析（生成需求文档）--软件设计--程序编码--软件测试--上线发布--运行维护

项目组成员：产品经理（收集客户市场反馈相关需求）-项目经理（管理人员分工监控跟踪）-开发团队（设计文档，具体开发）-测试团队（依据测试用例进行检查）-配置人员（上线发布）

环境分类

1、开发环境：代码是最新的

2、测试环境：测试人员执行测试所使用的环境

3、生产环境：已经测试通过的版本发布客户使用

软件测试的对象和原则：

测试的基本原则：

1、测试是上下文相关的（测试性能背景，测试不同类型及观点）；

2、穷尽测试是不可能的（不可能支持规定范围内测试）；

3、测试尽早介入；

4、杀虫剂悖论（使用相同测试用例是没办法发现新缺陷）；

5、缺陷群集性（当一个问题产生会产生其他新的缺陷）；

6、测试证明存在缺陷；

7、无错谬误。                         测试证明bug存在

 

测试对象：数据+文档+程序（编码）

软件开发模型（了解）：

1、瀑布型：每一个环节的工作依赖于上一步工作的完成的基础上；对每一个文档的要求质量高；一旦发现问题，维护成本很高。

 

 

2、原型：软件界面的模样会提前画出来，可以避免问题在后期发现。每个环节的需求文档的要求没有瀑布模型高

 

 

3、敏捷模型：敏捷开发（Agile Developement）是一种以人为核心、迭代、循序渐进的开发方法。可以优先占领市场，尽早实现可工作的软件。

 

 

       还没有实现的                                                           2-6周开发周期

        功能列表

4、其他模型：螺旋模型、RUP模型

软件测试模型及特点：

1、V模型：

 

 

优点：既包括低层测试有包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了是整个系统满足用户的需求。（编码之后测试才介入）

局限性：把测试过程作为在需求分析、摘要设计、详细设计及编码之后的一个阶段，不能体现“今早的和不断的进行软件测试”的原则。

2、W模型：又叫双V模型，在需求分析阶段，测试就开始了

 

 

优点：

a、如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可以用于评估开发文档。

b、测试者可以在项目中尽可能早地面地规格说明书地挑战。

c、测试还可以尽可能早的找出缺陷所在，从而帮助改进项目内部的质量。

局限性：无法支持迭代、自发性以及变更调整。

3、H模型：可以和W模型并行存在的。

 

 

优点：

a、软件测试不仅仅指测试的执行，还包括很多其他的活动；

b、软件测试是一个独立的过程，贯穿产品整个生命周期，与其他流程并发的进行；

c、 软件测试要尽早准备，尽早执行；

d、软件测试是根据被测试物的不同而分层次进行的；

e、不同层次的测试活动可以是按照某个次序先后进行的，但也可以是反复的；

f、  软件测试是一个独立的流程，贯穿于整个产品周期，于其他流程并发的进行。

4、X模型：

 

 

5、前置模型：

 

 

优点：

a.体现开发和测试相结合

b.对每一个交付内容进行测试

c.在设计阶段进行测试计划和测试设计

d.测试和开发结合在一起

e.让验收测试和技术测试保持相对独立

软件测试阶段：

需求测试

返工：70%~85%

重点：检查需求规格说明书 SRS

1、完整性  2、正确性  3、一致性  4、可行性  5、无二义性

6、健壮性  7、必要性  8、可测试性  9、可修改性

 

 

 

单元测试：是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。其目的是检测软件模块对《详细设计说明书》LLD的符合程度。

单元：函数、类

集成测试：是对单元之间及单元与第三方接口之间的测试，目的是验证接口是否与设计相符，是否与需求相符。（即检测软件模块对《概要设计说明书》的符合程度）。和单元测试主要是代码和功能系统本身。

集成策略：自底向上（需要准备驱动模块）或自顶向下（需要准备桩模块）、渐增式（依次增加）

系统测试：将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。目的在于通过与《需求规格说明》作比较，发现软件与系统需求定义不符合或与之矛盾的地方。（系统测试包括了确认测试）

确认测试：又称性能测试，他的任务是检验软件的有效性，即验证软件的功能和性能及其他特性是否与用户的要求一致。若能达到这一要求，则表明开发的软件是合格的。（测试软件的有限性，关注应该实现的有没有实现）

验收测试：交付用户部署前，进行验收测试。

以用户为主，验收组：项目组成员、用户代表或者系统的其他利益相关者。

根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。

Alpha测试：内部，模拟/真实

Beta测试：外部，真实

UAT测试（User Acceptance Test）：用户接受测试，验证系统的可用性。

回归测试（必须理解） Regression Testing：其他软件测试或其他活动中发现的缺陷经过修改后进行的测试。目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。

回归测试可以发生在任何一个阶段，包括单元测试，集成测试和系统测试。

回归测试策略：

1、完全重复测试：重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性；（之前测试过用例，再重新测试一遍）

2、选择性重复测试：即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序。

a、覆盖修改法：即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。

b、周边影响法：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它受到不良影响。该方法比覆盖修改法更充分一点。

c、指标达成法：一种类似与单元测试的方法，再重新执行测试之前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。

回归测试流程（适合于单元测试、集成测试和系统测试）：

1、在测试策略制定阶段，制定回归测试策略；

2、确定回归测试的版本；

3、回归测试版本发布，按照回归测试策略执行回归测试；

4、回归测试通过，关闭缺陷跟踪单（问题单）；

5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试。

回归测试自动化：

1、回归测试是一个重用以前成果的测试，很难预料到要经过多少次回归系统才能达到满意的水平，结果，这种回归测试将可能演变成一种重复的、令人心烦意乱的工作，效果与人员的积极性将大打折扣；

2、回归测试的自动化法包括测试程序的自动运行、自动配置，测试用例的管理和自动输入，测试的自动执行，测试信息与结果的自动采集，测试结果的自动比较和结论的自动输出；

3、对系统测试功能比较简单、测试界面相对稳定并且测试用例良好组织的测试来说，采用“捕捉回放”工具是比较合适的，这类工具有Selenium。

冒烟测试：冒烟测试的名称可以理解为该种测试耗时短。也可以形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

软件测试类型：

功能测试：根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。

主要是为了发现以下几类错误：

1.是否有不正确或遗漏了的功能；

2.功能实现是否满足用户需求和系统设计的隐藏需求；

3.输入能否正确接受，能否正确输出结果。

性能测试（performance testing）就是用来测试软件在集成系统中的运行性能的。

目标：度量系统相对于预定义目标的差距。

支持工具：用于GUI或Web的性能测试工具，如Loadrunner(测试Web端)，Jmeter（接口的功能，性能），SilkPerformer，Webload。

性能测试收集的信息（指标）：

a.CPU使用情况  b.IO（读写磁盘）使用情况  c.内存使用情况  d.信道使用情况  e.每个模块执行时间百分比  f.一个模块等待IO完工的百分比  g.指令随时间的跟踪路径  h.每一组指令页换入和换出的次数  i.系统反应(响应)时间  j.系统吞吐量，即每个时间单元的处理数量  k.所有主要指令的单元执行时间

性能测试类型：

1.负载测试：超过被测对象标准性能负荷指标下，验证系统的负载承受能力。并要求超负荷情况下，依然正常实现业务功能。(当超出标准的负荷指标外，软件运行的能力)。

2.压力测试（Stress Testing）又叫极限测试：目的是调查系统在其资源超负荷的情况下的表现（查看负载极限点）。对系统的处理时间的长短。

目标：发现系统在极限或恶劣环境中自我保护的能力。主要验证系统的可靠性，找到系统薄弱环节。比如：成千上万的用户在同一时间登录到Internet，同时引入大量的操作。

3.容量测试(Volume Testing)：目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理多少的数据容量（关注数据量的大小）。比如：使用编译器编译一个极其庞大的源程序，一个操作系统的任务队列被充满，庞大的Email信息和文件充满了Internet。

4.安全性测试(Security Testing)（属于功能性测试）：用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。用来保证系统本身数据的完整性和保密性。如当受到恶意攻击时，设备的自我保护能力，病毒防护能力，自定义通信协议安全性等。广义的还包括物理安全性测试、业务安全性测试。

一些功能性的安全性问题：

a．没有口令是否可以登录到系统中；

b．各级用户权限划分是否合理；

c．错误和文件访问是否适当地被记录；

d．系统配置数据是否能正确保存，系统故障时是否能恢复。

安全性测试内容：

a.系统的登录  b.用户管理  c.防火墙  d.系统数据  e.WEB安全性，如WEB的加密，解密，数字签名等  f.数据库的安全性  g.内部通信协议  h.系统防病毒测试

5.GUI测试（用户交界界面）：针对软件系统GUI界面进行的测试。主要包括两方面：

a. 界面实现与界面设计的吻合情况；

b. 确认界面处理的正确性。

一般业界常用的GUI自动化工具有QTP（QuickTestProfessional）, SilkTest, QARun,selenium等。

GUI测试对象（界面上能够看见的所有东西）：

a.简单界面元素：指功能和属性相对比较单一的界面区域，即通常所指的各种控件；

b.组合类界面元素：主要指一些复杂的界面元素，比如工具栏，组合框，表格，菜单栏等；

c.完整界面（窗口）：由一系列界面元素通过适当的形式组合而成的界面形式，最为常见的为各种窗口。包括各种对话框、单文档窗口、多文档父窗口，多文档子窗口等。

6.可用性测试(Usability Testing)：（符合用户常规使用习惯）主要考虑产品是否符合实际应用情况，是否符合用户习惯或特殊要求，操作方式是否方便合理、设备和用户间的交互信息是否准确易于理解、是否遵从行业习惯、外观/界面是否美观等。应涉及到所有和用户有交互的功能或子系统。这包括系统功能、系统发布、帮助文本和过程，以保证用户能够舒适地和系统交互。

一些测试人员关注的可用性问题：

a.过分复杂的功能或者指令；

b.困难的安装过程；

c.错误信息不准确或者过于简单；

d.用户被迫去记住太多的信息；

e.语法、格式和定义不一致。

7.安装卸载测试（针对CS架构）：系统的可安装性测试，主要是根据软件的测试特性列表、软件安装、配置文档，设计安装过程的测试用例，发现软件在安装过程中的错误。其目的是系统可安装性测试的目的不仅是找安装软件本身的错误，而且还要找安装文档的错误。

8.异常测试（系统容错或可恢复性测试）：它是通过人工干预手段使系统产生软件、硬件异常，通过验证系统异常前后的功能和运行状态，达到检验系统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段。

容错处理：系统自动处理、人工干预处理。

注意：

a.系统异常测试还与系统的指标测试有关系，当系统需要提供的服务能力大于系统的设计指标时，也属于系统异常的情况，应该结合起来加以考虑；

b.系统的可靠性是设计出来的，而不是测试出来的。设计和测试是一个互为反馈的过程。

9.文档测试(Documentation Testing)：目标是验证用户文档是正确的并且保证操作手册的过程能够正确工作。（文档本身的检查）

10.网络测试（接口测试）：网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常。（保证接口与接口交互是正常的）网络测试考察系统的处理能力、系统兼容性、系统稳定可靠性及用户使用等方面。

如通信产品，主要进行协议测试：

a.一致性测试：检测所实现的系统与协议规范符合程度；

b.性能测试：检测协议实体或系统的性能指标（数据传输率、联接时间，执行速度、吞吐量、并发数等）；

c.互操作性测试：检测同一协议不同实现厂商之间，同一协议不同实现版本之间、或同一类协议不同实现版本之间互通能力和互连操作能力；

d.坚固性测试：检测协议实体或系统在各种恶劣环境下运行的能力（信道被切断、通信设备掉电、注入干扰报文等）。

11.稳定性测试（性能测试的一种）：目的是评价系统在一定负荷情况下、长时间的运行情况。包括系统在一定负荷下，再增加新的业务，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄漏，数据有无不一致的情况，系统性能是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间MTBF（两次故障发生时间的平局值）是否满足系统设计要求。

12.兼容性测试：兼容性测试验证被测对象与硬件、其他软件之间的兼容情况。

软件测试方法：

任何软件产品都可以使用以下的两种方法之一进行测试：

1.已知产品的需求规格，但不知道其内部实现，可以进行测试证明每个需求是否实现。（依据需求来测试）

2.已知产品的内部实现过程，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经过检查。（代码内部处理过程符合设计规格的）

 

测试活动从不同的角度出发，可以有不同的分类：

黑盒测试和白盒测试，灰盒测试；

静态测试和动态测试；

人工测试和自动化测试。

 

白盒测试（会用到静态分析和动态分析）：依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。（内部代码实现流程）白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试。

静态分析：控制流分析、数据流分析、信息流分析等；

动态分析：逻辑覆盖测试（分支测试、路径测试等）、程序插装等；

逻辑覆盖方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

语句覆盖：针对代码语句，意思是设计出来的测试用例要保证程序中的每个语句被执行一次。通常被称为“最弱的覆盖”，因为覆盖执行语句的代码没有考虑各种条件，导致很难发现问题。

判定覆盖（Decision Coverage）：也叫分支覆盖（Branch Coverage），也就是说设计的测试用例要保证被测试程序中的每一个分支至少被执行一次。比语句覆盖要强一些，能发现一些语句覆盖无法发现的问题。

条件覆盖：条件覆盖与分支覆盖不同，要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值，即每个条件至少有一次真值、有一次假值。比判定覆盖强，因为使每个条件都取得了不同的结果，但是并没有考虑到判定结果。

判定条件覆盖：设计的测试用例使判断中每个条件所有的可能取值至少执行一次，同时判断本身的结果也要至少执行一次。同时满足了两种覆盖。

组合覆盖（Branch Condition Combination Coverage）也叫条件组合覆盖：此方法为主要逻辑覆盖方法

定义：测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。

路径覆盖：就是设计的测试用例可以覆盖程序中所有可能的执行路径。

白盒测试特点：

1. 白盒测试一般在测试前期进行，通过达到一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问题能基本得到消除；

2. 白盒测试能保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证；

3. 白盒测试发现问题后解决问题的成本较低。

黑盒测试：又被称为规格的测试。把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现。黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等。

黑盒测试类型：

1. 功能性测试，一种是顺序测试每个程序特性或功能，另一种途径是一个模块一个模块的测试，即每个功能在其最先调用的地方被测试；

2. 容量测试，检测软件在处理海量数据时的局限性，能发现系统效率方面的问题；

3. 负载测试，检测系统在一个很短时间内处理一个巨大的数据量或执行许多功能调用上的能力；

4. 恢复性测试，主要保证系统在崩溃后能够恢复外部数据的能力。

黑盒测试特点：

1. 对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高；

2. 测试人员不需要了解实现的细节，包括特定的编程语言；

3. 从用户的视角进行测试，很容易被大家理解和接受；

4. 有助于暴露任何规格不一致或有歧义的问题。

灰盒测试：（介于白盒测试和黑盒测试之间）比如集成测试和系统测试时借助log信息是典型的灰盒测试。

1.利用被测对象的整体特性信息，采用黑盒测试方法；

2.利用被测对象的内部具体实现信息，采用白盒测试方法；

3.如果既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，采用的就是灰盒测试方法。两种信息占的比例不同，相应的灰度就不同。

静态测试：不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如：代码走读、文档评审、程序分析等都是静态测试的范畴。常用技术有静态分析技术。

静态分析技术：是一种不通过执行程序而分析程序执行的技术。是检查软件的表示和描述是否一致，没有冲突或者没有歧义，它瞄准的是纠正软件系统在描述、表示和规格上的错误，任何进一步测试执行的前提。

主要有三种不同的程序测试可能性：

1.考虑程序是否满足编码规则，语法上是否具有一致性和完整性；

2.考虑文档描述是否规范、准确、便于查阅；

3.考虑程序和文档之间的一致性。

动态测试：按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。常用技术有动态分析技术。（需不需运行被测软件来区分静态和动态）

人工测试(项目组不能没有人工测试)：测试活动（如评审、测试设计、测试执行等）由人来完成，狭义上是指测试执行由人工完成，这是最基本的测试形式。

自动化测试：一般是指通过计算机模拟人的测试行为，狭义上是指测试执行由计算机来完成。

自动化测试的好处：

1.对程序新版本运行前一版本执行的测试，提高回归测试效率；

2.可以运行更多更频繁的测试，比如冒烟测试；

3.可以执行手工测试困难或不可能做的测试，比如大量的重复操作或者集成测试；

4.更好地利用资源，比如测试仪器或者被测对象。

自动化测试的限制：

1.不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现更多缺陷；

2.手工测试比自动测试发现的缺陷更多；

3.对测试设计依赖性极大，测试设计的不好会遗漏问题；

4.自动化测试对软件开发具有很大的依赖性，开发上出现变更可能导致前面的自动化测试完全失效；

5.工具本身并不具备想象力，工具不具有智能。

软件测试流程（重点了解）：

测试计划阶段---测试计划（每个测试活动的内容）

指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。

测试设计阶段---测试方案（指导测试人员后期工作的内容）

指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。

测试实现阶段---测试用例、测试规程

测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。

测试规程：指明执行测试时测试活动序列的文档。

测试执行阶段---测试报告、缺陷报告

测试报告：指明执行测试结果的文档。

测试日报：每天测试执行情况的记录和总结。

 

系统测试过程与开发阶段：

需求分析阶段      概要设计     详细设计     编码     单元测试执行

                                                                                      集成测试执行

 

  

 

系统测试计划     系统测试设计      系统测试实现        系统测试执行

 

软件测试质量以及测试与QA的关系、区别：

质量：软件质量属性的综合体现，各种质量反应了软件质量的方方面面。通过改善软件的各种质量属性从而提高软件的整体质量。

质量属性：

衡量软件的可用性（属性）：正确性、精确性、健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性。这些属性互相依靠，但很多，可分为两大类：“功能性”与“非功能性（能力）”

软件质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础。

*

 

 

 

                                             非功能性

成熟性：软件自己本身的成熟度

容错性：对外部异常错误，进行正确的修改

易恢复性：当出现异常退出时，会显示恢复到哪个版本

时间特性：处理系统的时间快慢

资源利用性：软件对系统的利用率，消不消耗资源

软件测试（基于对结果的检查）与QA（是基于产生结果的过程的检查，属于监督工作）的关系、区别：

1. 从性质上看：测试属于技术的工作；QA属于管理的工作。

2. 从对象上看：测试的对象是软件研发产品，大多数工作是对研发领域的检验；

QA的对象是整个软件过程，覆盖各个领域。

3.从手段上看：测试以事后检查为主；QA强调的是缺陷预防。

质量保证活动与软件测试的关系：

 

 

转载于:https://www.cnblogs.com/by7658025/p/8879755.html