测试理论概述

一、测试基础

1、什么是测试？

弄清楚产品实际功能与需求的差别的过程。

2、软件测试的目的：

根本目的是检验产品是否满足用户的需求。除此之外，可细分为三个层面：

• 证明：证明软件可用
• 检测：发现缺陷（BUG）以及一些可优化项。
• 预防：预防缺陷，可以尽早的进行测试，以发现开发人员的错误或者遗漏，以及分析存在的bug，避免错误发生后带来的损失。

3、什么是缺陷？

软件内部发生错误引发的不符合产品预期的表现，缺陷相关：

• 错误：产生不正确结果的人为行为，如代码错误、文档错误。
• 缺陷（bug、defect）：软件或文档中不符合预期的表现，是由错误引发的缺陷，缺陷是错误的具体表现。
• 失效：缺陷引发功能无法使用，即失效。
• 故障：缺陷在正式环境（生产环境）下暴露出来，引发较为严重的后果，即软件故障。
  
  

Ps：

• 生产环境/线上环境/正式环境：即用户在使用的真实环境
• 预发布环境：软件在上线前进行回归测试的环境，大回归测试
• 测试环境：测试人员使用的环境，用来发现缺陷（执行用例、小回归测试）
• 开发环境：开发人员使用的环境，用来调试代码、开发自测
  
  

4、软件生命周期：

简介：在软件工程中，通过定义软件生命周期，将整个周期分为若干个阶段，规定了每个阶段（采用什么标准、什么规范、什么工艺）的必须完成的交付物，用以保证产品的质量。

基于软件瀑布模型的生命周期：

• (1)计划：一般由项目经理来完成该阶段，产出物是《项目计划》，其内容是确立项目目标、调研、沟通，评估可行性、资源、成本、进度、收益等（一般从what、when、who三方面考虑）。

• (2)需求分析：由需求人员（项目经理、需求分析师、产品经理）来完成，输出《软件需求规格说明书》,也称SRS，其内容是解决“what”问题，即分析具体需求（显示需求、隐式需求），逐步细化，并定义清楚。

• (3)设计：由架构师来完成，输出《概要设计》，即HLD；《详细设计》，即LLD，其内容是解决“How”问题，对系统-子系统-模块-函数进行逐层设计。

• (4)编码：由开发人员来完成，输出可运行的程序以及一些代码。

• (5)测试：由测试人员来完成，输出《测试报告》，期间还有《测试计划》、《测试方案》、《测试用例》、《缺陷报告》等输出，通过细致的分析来检测软件是否有缺陷。

• (6)运维：由运维人员、技术支持来完成，在产品上线后对产品进行升级维护、安装部署、线上问题排查等

5、常见研发组织架构：

• (1)职能型：①产品部：UI设计师、产品经理。。。②开发部：前端开发工程师、后端开发工程师。。。③测试部：测试工程师、测试开发工程师。。。④质量部：QA（质量保证人员）、CMO（配置管理员）、项目管理员。。。

• (2)项目型：①产品1组（部）：项目经理、需求分析师、开发、测试。。。②产品2组（部）：项目经理、需求分析师、开发、测试。。。③。。。。。

• (3)矩阵型：以上两种的混合体。

6、常见研发流程模型：

• (1)瀑布模型：按照计划-需求分析-设计-编码-测试-运维流程进行产品的研发。

  • 特点：串行流程，测试到后期才会介入，一个测试工程师可负责多个项目，前期的阶段做的越完善，后期修改的成本就越低，交付质量也就越高。
  • 缺点：风险到后期才会显露，只有在项目后期才能看到产品，对需求变更的适应力差。
    适合复杂度低、需求稳定的项目，通常周期较短。
    
    

• (2)快速原型：在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

  • 优点：克服了瀑布模型的缺点，早期就能看到产品的雏形，减少了需求不明确带来的风险。
  • 缺点：经过不断的修改，可能导致产品质量比较低。
    适合周期短、需求明确、需要尽早的看到产品原型的项目。
    
    

• (3)增量模型：也称为有计划的产品改进模型，它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。增量模型的最大特点就是将待开发的软件系统模块化和组件化。

  • 优点：
    ①. 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
    ②. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
    ③. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
    
    

  • 缺点：如果要开发的模型不能进行模块化，那么使用增量模型将会给开发带来很多麻烦。
    适合能被模块化、可分批次的进行交付、开发人员对应用领域不熟悉，难以进行一次性的系统开发、项目管理人员把握全局水平的较高的软件

• (4)螺旋模型：采用一种周期性的方法来进行系统开发，该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。

  • 优点：
    ①. 可分多次进行交付。
    ②. 在早期能看到产品雏形。
    ③. 风险暴露早，很容易进行风险控制。
    ④. 对需求变更的适应力较强

  • 缺点：研发周期过长，开发成本较大
    适合复杂度高、周期长、需求可能有变化的项目

• (5)喷泉模型：主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界。

  • 优点：各个阶段没有明显的界限，开发人员可以同步进行，提高软件开发效率，节省时间
  • 缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

7、测试过程：

• (1)测试的四个阶段：

  • Ⅰ、单元测试阶段（UT，Unit Test）：针对软件最基本单位（函数、类）的测试。
    • 测试依据：详细设计说明书（LLD）。
    • 测试对象：函数、类
    • 测试重点：①函数代码和LLD上是否一致。②函数功能实现是否正确。③函数内部逻辑实现是否正确。
    • 测试方法：白盒测试（不关注外部特性，只关注内在实现逻辑）
    • 测试完整性的评估标准：逻辑覆盖率（语句覆盖、判定覆盖、路径覆盖）
    • 执行人员：开发人员或测试人员。
      
      
  • Ⅱ、集成测试阶段（IT，Integration Test）：将测试的每个单元、模块、子系统进行组装。检查它们之间的数据传递是否正确，也叫作组装测试（联合测试）。
    • 测试依据：概要设计说明书（HLD）。
    • 测试对象：模块、接口
    • 测试重点：①检查模块代码和HLD上是否一致。②函数之间相互调用是否正确。③模块功能是否正确。
    • 测试方法：灰盒测试（白盒+黑盒）。
    • 测试完整性的评估标准：接口覆盖率。
    • 执行人员：开发人员或测试人员。
      
      
  • Ⅲ、系统测试阶段（ST，System Test）：将集成的软件系统作为一个元素和其他软件硬件结合一起做综合的测试叫做系统测试
    • 测试依据：需求规格说明书（SRS）。
    • 测试对象：整个软件系统
    • 测试重点：检查软件是否和SRS一致，功能测试、性能测试、安全测试、兼容测试、界面测试、可靠性测试等
    • 测试方法：黑盒测试（不关心内部逻辑，只关心外在特性）。
    • 测试完整性的评估标准：需求覆盖率。
    • 执行人员：测试人员。
      
      
  • Ⅳ、验收测试（AT，Acceptation Test）：一般指由客户参与的测试（甲方；甲方委托第三方；甲方委托乙方；潜在用户）；
    • 测试依据：工作任务书、原始需求、用户手册等。
    • 测试对象：整个软件系统
    • 测试重点：检查软件的功能是否和用户需求一致
    • 测试方法：黑盒测试（不关心内部逻辑，只关心外在特性）。
    • 分类：
      • ①正式验收测试：由第三方评测机构执行。
      • ②用户验收测试：由用户执行的测试，分为：
        α测试：处于受控状态（特定人员、特定环境、特定操作），如游戏内测。
        β测试：不受控，如游戏公测
        
        

• (2)测试阶段的四个活动：

  • Ⅰ、测试计划：由测试经理（测试组长）进行测试范围、时间进度、人员分工的指定，输出《测试计划》。

  • Ⅱ、测试设计：由资深测试工程师、测试工程师进行选择测试方法、测试工具、测试策略等，输出《测试方案》。

  • Ⅲ、测试实现：由测试工程师进行，工作内容包括：编写测试用例（测试工程师进行测试时的指导性文件）、测试规程（用例执行顺序的说明文档）、测试脚本，设计测试数据（测试时需要录入的数据、文件等）。

  • Ⅳ、测试执行：由测试工程师进行。工作内容有：搭建测试环境、准备测试数据、执行测试用例、记录用例执行结果、提交缺陷报告、跟踪缺陷以进行回归测试、编写测试报告、测试总结等。
    
    

• (3)回归测试：把已经测过的再测一遍。

  • Ⅰ、目的：①验证缺陷是否修复。②验证是否引入新的缺陷。

  • Ⅱ、回归测试策略：

    • ①选择性回归：
      a、覆盖修改法：哪里修改就回归测试哪里，适用于对其他模块没有影响的修复内容。
      b、周边影响法：针对于复杂模块的修复，考虑到有影响到其他模块，回归测试将测试修复模块及其影响模块。
      c、指标达成法：按照一定的标准来选择需要回归测试的内容。如：
      1)发现缺陷的用例需要重新执行。
      2)与开发人员修改的代码相关的功能模块的用例需要重新执行。
      3)系统正式发布前，选择严重程度较高的BUG进行回归测试。
      4)系统正式发布前，选择核心模块的1、2级用例进行回归测试。

    • ②完全性回归：把所有的用例全部重新执行。工作量较大，一般很少采用，或者借助自动化测试来使用。

• (4)测试模型：

  • Ⅰ、V模型：本质和瀑布模型一致。
    
    
    
  • Ⅱ、双V模型（W模型）：
    

• (5)测试方法：

  • Ⅰ、根据测试关注点的不同，分为：
    • ①白盒测试：只关注内部的实现细节，不关注外在特性，因相当于一个透明的盒子，可以看清内部的运行逻辑，有时也称透明盒测试。主要在单元测试阶段使用。
    • ②黑盒测试：只关注外在功能特性，不关注内部实现细节，相当于一个黑色的盒子，不理会其中的运行原理。主要在系统测试阶段使用。
    • ③灰盒测试：以上两者兼具。一般在集成测试阶段使用。
      
      
  • Ⅱ、根据是否运行被测对象，分为：
    • ①静态测试：不执行被测对象进行测试。有人工静态测试、自动化静态测试。
    • ②动态测试：运行被测对象进行测试。有功能测试、性能测试、语句覆盖测试。
      
      
  • Ⅲ、根据执行者不同。分为：
    • ①人工测试
    • ②自动化测试：提高效率，但无法提高测试效果（不具备发散性思维），有局限性，如界面元素变化时、界面元素交互发生变化时，脚本会失效，不适合首次测试、功能还不稳定的测试，只能确定软件有无问题，而不能去发现问题。
      
      
      使用自动化测试的基本原则：重复性高、界面很少发生变化时，如冒烟测试、回归测试等。

二、软件质量

1、软件质量是什么？

指软件的实体特性对用户需求的满足程度。

软件的实体特性：即软件质量模型（下文介绍）

满足程度：软件质量的三个层次：

• ①符合需求规格（SRS）。
• ②符合用户显示需求（用户明确说明的目标）。
• ③符合用户实际需求（符合用户使用的要求以及未明确说明的隐式需求）。

2、软件质量铁三角：

• (1)组织：专业的、独立的测试团队。
• (2)流程：质量管理体系（CMMI4）、工作流程（研发流程、测试流程、缺陷管理流程、测试挂起/恢复条件、测试通过标准、评审流程等）。
• (3)技术：技术人才、专业技能、专业知识、培训等
  质量的提高不是无限的，必须兼顾成本和进度，是在成本和进度的约束下，尽可能的提高产品质量。

3、软件质量模型：

常见的软件质量模型：MoCall模型（1977年）、Boehm模型（1978年）、ISO 9126模型（1991年）、ISO 25010模型（2011年）。
接下来重点介绍ISO 25010模型，分为八大特性，31个子特性：

• (1)功能适用性：软件所实现的功能达到其设计规范和满足用户需求的程度
  • ①正确性：提供的功能是否正确。
  • ②适合性：提供的个体功能是否完善
  • ③完整性：提供的整体功能是否完善
    
    
• (2)运行效率：在指定条件下，软件对操作所表现出的时间特性（如响应速度）以及实现某种功能有效利用计算机资源（包括内存大小、CPU占用时间等）的程度，局部资源占用高通常是性能瓶颈存在；系统可承受的并发用户数、连接数量等，需要考虑系统的可伸缩性。
  • ①时间特性：响应时间，如2-5-8原则
  • ②资源利用性：如CPU占用率、内存占用率、磁盘IO、网络带宽占用等。
  • ③容量：一个产品或参数最大限度满足要求的程度。如并发用户、磁盘占用、最多能打开多少文档、打开单个文档最大程度等。
    
    
• (3)易用性：对于一个软件，用户学习、操作、准备输入和理解输出所作努力的程度，如安装简单方便、容易使用、界面友好，并能适用于不同特点的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段（即可达性【亦称可访问性】）
  • ①可辨识性：用户可快速判断是否满足自己的需求。如直观的设计（按钮的形状，word文档中保存的按钮就是个SD卡的样子）
  • ②易学性：帮助用户能自行学习的程度。如新手教程、帮助文档、操作手册等。
  • ③易操作性：操作步骤少，如菜单级别不超过3级、支持快捷键的操作等。
  • ④用户错误保护：避免用户输入错误或输入错误有提示。如输入错误的提示、输入框内文案显示，输入框内的提示。
  • ⑤用户界面美观：提高用户喜悦度和满意度的配色、文字比例、界面排版等。
  • ⑥可访问性：残疾人、有缺陷的人能提供产品使用的有效途径或手段。
    
    
• (4)兼容性：同时共享相同的硬件或软件环境时，系统或组件可以与其他系统或组件交换信息，以及执行其所需的功能的程度。
  • ①共存性：软件能给与系统平台、子系统、第三方软件等兼容，同时针对国际化和本地化进行了合适的处理，没有不利的影响。
  • ②互操作性：两个或两个以上的系统、产品或部件可以交换信息，并使用已经交换的信息的程度，涉及API和文件格式等，如word可在不同的打印机上进行打印。
    现今，人们对“兼容性”这个名词的认知发生了一些改变，谈到“兼容性”这个概念时，其实更接近于可移植性里的适应性。如，操作系统兼容性、浏览器兼容性、分辨率兼容性、手机型号兼容性等。
    
    
• (5)安全性：要求其数据传输和存储等方面能确保其安全，包括对用户身份的认证、对数据进行加密和完整性校验，所有关键性的操作都有记录（log），能够审查不同用户角色所做的操作。它涉及保密性、完整性、抗抵赖性、可核查性、真实性。
  • ①保密性：保证数据不会被泄露。如加密存储、加密传输等。
  • ②完整性：保证数据不被破坏，防篡改，防丢失。
  • ③不可抵赖性：已经发生的操作，不可否认。
  • ④可核查性：发生过的操作，可复查。
  • ⑤真实性：使用者身份可证明。
    
    
• (6)可靠性：在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度／概率，如成熟性越高，可靠性就越高；用MTTF (mean time to failure，平均失效前时间) 或MTBF（mean time Between failures，平均故障间隔时间）来衡量可靠性。
  • ①成熟性：软件能很好的处理内部错误，不会发生异常。如淘宝网站程序占用服务器到达一定程度后，会强制释放内存，以保障网站的运行。
  • ②容错性：软件能很好的处理外部错误，不会发生异常，在注册输入框输入超过限制时，不会出现页面异常，而是出现友好提示。
  • ③易恢复性：出现异常后能否恢复、多久能恢复、能恢复到什么程度。如迅雷下载过程中，出现断电、断网、关机时，可进行断点续传。
  • ④可用性：以上三点的组合。
    
    
• (7)可移植性：软件从一个计算机系统或环境移植到另一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。它涉及适应性、易安装性、易替换性。
  • ①适应性：软件产品无需采用特别手段就可以适应不同指定环境的能力。操作系统兼容性、浏览器兼容性、分辨率兼容性。。。
  • ②易安装性：软件产品在指定环境中被安装的能力。安装测试。。。图形界面安装、命令行安装等
  • ③易替换性：软件产品在同样环境下，替代一个相同用途的指定软件产品的能力。
    
    
• (8)可维护性：当一个软件投入运行应用后，需求发生变化、环境改变或软件发生错误时，进行相应修改所做努力的程度。它涉及模块化、复用性、易分析性、易修改性、易测试性等

4、常见质量管理体系：

• (1)ISO9000：适用所有行业。

• (2)CMMI：软件能力成熟度模型，适用于软件行业，共有五个级别：

  • Level 1初始级：处于成熟度级别1级时，过程通常是随意且混乱的。这些组织的成功依赖于组织内人员的能力与英雄主义。成熟度1级的组织也常常能产出能用的产品与服务，但它们经常超出在计划中记录的预算与成本。

  • Level 2已管理级：在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。

  • Level 3已定义级：在这一等级，企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程，将这套管理体系与流程予以制度化这样。同时企业开始进行项目积累，企业资产的收集。

  • Level 4量化管理级：在成熟度4级，组织建立了产品质量、服务质量以及过程性能的定量目标。成熟度级别3级与4级的关键区别在于对过程性能的可预测性。

  • Level 5优化级：在优化级水平上，企业的项目管理达到了最高的境界。成熟度级别5级关注于通过增量式的与创新式的过程与技术改进，不断地改进过程性能。处于成熟度5级时，组织使用从多个项目收集来的数据对整体的组织级绩效进行关注。

• (3)6西格玛：适用于IT、制造业，６西格玛指每百万样品中只有3.4个残次品。

三、单元测试：

1、单元测试的对象：

• (1) 函数：可完成某个功能的代码集合。
  函数间的调用关系：
  
  
  
• (2) 桩：测试一个函数时，需要调用的函数称为桩。它使得被测函数能编译通过，且需要对代替的下层函数进行模拟，以获得各种返回值（根据测试需要）。
  
  
• (3) 驱动：被测函数的上层函数，用以验证被测函数的功能实现（返回值与预期结果是否相同）
  
  

4、单元测试策略：

• (1)孤立：不考虑被测函数与其他单元之间的关系，对被测函数进行单一的测试。

  • 优点：可以达到较高的覆盖率
  • 缺点：需要进行大量的桩和驱动的开发，效率低。

• (2)自顶向下：从最顶上的单元往下分层进行函数测试，除最顶层外，把上层已测函数当作驱动，直到测试完所有的单元。

  • 优点：不需要开发驱动，效率较高。
  • 缺点：随着往下进行，测试复杂度越来越高。

• (3)自底向上：从最底层向上进行函数测试，除最底层外，把已测函数当作桩，直到测试完所有的单元。

  • 优点：不需要开发桩，效率较高。
  • 缺点：底层函数的测试质量对上层函数影响比较大。

• (4)混合：以上策略混合使用。

四、集成测试：

1、集成测试层次：

与HLD设计的层次相关，常见的层次有：模块内函数集成、模块间集成、子系统间的集成。

2、集成测试的重点：

• (1)内部接口：关注函数间的相互调用。
• (2)集成后的功能：关注单一功能的使用和功能间并存或相互调用。

3、集成测试策略：

• (1)大爆炸集成：一次性集成所有组件，类似于系统测试，但更关注接口间的调用问题。
  • 优点：操作简单且支持多人并行工作。
  • 缺点：不支持故障隔离（即问题的修复和定位困难）、一次性集成成功的概率很低，即便成功了，很多接口上的测试也会有所遗漏，覆盖度不够。
    
    
• (2)自顶向下集成：与单元测试类似。
  • 优点：支持故障隔离，能较早的发现主控制点和判断点的问题。
  • 缺点：需要进行桩的开发。
    
    
• (3)自底向上集成：与单元测试类似。
  • 优点：支持故障隔离。
  • 缺点：需要进行大量的驱动开发，且发现上层错误的时机延迟了。
    
    
• (4)三明治集成：自底向上和自顶向下的混合使用，分为三层：上层、目标层、底层，最终在目标层会合。
  
  
• (5)基于功能集成：和大爆炸集成类似，但比大爆炸集成慢。
  • 优点：能尽早的看到功能的实现。
  • 缺点：和大爆炸集成的缺点类似，故障隔离不完全，接口测试不充分.

五、系统测试：

1、什么是系统测试：参上。

2、系统测试过程：参照测试活动

3、常见系统测试类型：

• (1)功能测试：

  • ①单功能测试：某个单一功能的测试。如登录等。
  • ②功能交互：不同功能间是否有相互影响的测试，如前台和后台的交互：不同权限的登录、登录后才能进行相关的操作等。
  • ③业务场景：模拟用户使用被测软件的测试。业务流程的测试。
    
    

• (2)性能测试：

  • ①定义：根据需求提出的性能指标进行的测试。
  • ②常见的性能指标：
    • 响应时间：如页面的响应时间，操作的响应时间（导出、导入、查询等）
    • 内存占用：运行该系统时的内存占用情况。
    • CPU占用：运行该系统时的CPU用情况。
    • 磁盘IO：运行该系统时磁盘读写的速率。
    • 流量：运行该系统时网络带宽的变化情况。
    • 磁盘空间占用：该软件占用磁盘空间的大小。
  • ③常见性能测试：

    • 负载测试：产品在不同并发量下的表现，如某个网站在1000/2000/5000名用户同时在线时，网站的查询速度如何，这个逐步增加用户数的过程也称增量加载。

    • 容量测试：产品承受数据量的最大能力，如WPS，在一台电脑上最多能打开多少个空白文档，每个文档最多能存储多少，网站最多能支持多少在线用户数。

    • 压力测试：产品在远超需求要求的最大负载时产品的性能表现和可靠性表现。也叫破坏性测试。

    • 稳定性测试：产品在正常负载下，长时间运行下产品的性能表现和可靠性表现。

• (3)界面测试（GUI测试）：针对界面的元素的显示，处理响应（如按下某个按钮，有颜色上的变化，通常对应按钮的操作事件），元素的布局（参照需求规格说明书中的原型图），快捷键的支持（tab键，enter键）的测试。

• (4)兼容性测试：主要考虑不同环境下的功能测试和界面测试。常考虑的点有：

  • ①操作系统：

    • PC端：Linux（centOS（6、7、8）、ubutun、redHat等）、Windows（7、8、10）、macOS
    • 移动端：Android（不同版本）、IOS。

  • ②浏览器：

    • PC端浏览器：chrome、Firefox、360、IE、safari、猎豹等。
    • 移动端浏览器：UC、Safari、夸克等。

  • ③分辨率：

    • PC端：1376768、19201080等
    • 移动端：。。。

  • ④网络环境

    Ps：兼容性测试策略：因无法在不同环境下执行全部测试用例，一般分为主测环境和辅测环境。主测环境可有一个或多个，需要执行全部的测试用例，辅测环境一般有多个，执行1、2级优先级的用例并关注界面测试。

• (5)安全性测试：对一些数据的安全性、权限的安全性、安全漏洞进行的测试。

  • ①数据安全：用户的敏感数据需要加密处理（加密传输、加密存储），对重要的数据进行备份。
  • ②权限安全：数据的增删改查的权限。
  • ③安全漏洞：运用漏洞扫描工具（burpsuit、appscan等）
    
    

• (6)安装测试：

  • ①安装前测试：检查包中文件是否齐全（安装部署文档、帮助手册等），是否有病毒或木马。
  • ②安装中测试：安装过程中的选项（上一步、下一步、取消等）的测试。
  • ③安装后测试：安装是否完整，安装好的软件是否可运行。
    
    

• (7)可靠性测试：

  • ①异常测试：断网、断电、硬件损坏、故障下的某个功能的运行情况。
  • ②稳定性测试：产品在正常负载下，长时间运行时的性能表现和可靠性表现。（如APp长时间运行会不会闪退或一些其他的错误会不会发生）

4、系统测试环境

• (1)环境组成：
  • 硬件：PC、服务器、网络设备、手持设备等。
  • 软件：被测软件、OS、数据库、web服务器、测试数据、测试脚本等。
    
    
• (2)分类：
  • ①主测试环境：执行所有测试用例。
  • ②辅测试环境：执行基本的功能测试用例（1、2级）
  • ③真实环境：即外放给用户真实使用的环境。
  • ④仿真环境：运用工具进行网络环境模拟以进行测试（fiddler等）；云测试平台；模拟器等。
    
    
• (3)系统测试数据的准备：利用产品数据（用户真实数据脱敏处理后的，如一些订单数据、商品信息）；手工构造；工具生成；随机数。

5、系统测试执行过程：

• (1)搭建测试环境

• (2)预测试：又称冒烟测试，对一些基本功能进行检查，检验是否满足后续测试的要求。

• (3)正式系统测试：需要预测试通过后，用例经过评审后，测试环境搭建好后才正式进行该测试。

• (4)执行用例：填写测试记录，并记录测试用例执行结果（通过【符合预期结果】、失败【不符合预期结果】、阻塞【一些其他原因导致用例无法执行】、N/A【Not Applicable，不适用，表示该用例可以忽略，一般发生在实现方式变化了、需求更改了等导致用例无需执行、不必执行的情况】）。

• (5)提交BUG，等待开发解决BUG后进行回归测试。

• (6)编写测试日报：汇报每天的执行情况（发现多少BUG、执行了多少用例、存在的问题以及需要什么帮助等）。

• (7)编写测试报告/测试总结/缺陷报告：测试执行结束时（达到了测试通过标准）所要编写的文档。

  PS：测试报告：对产品进行质量评估的文档。
  测试总结：测试工作过程的总结。
  缺陷报告：下文提及。

六、测试用例编写：

1、定义：

是测试工程师进行测试执行工作的指导性文件。即告诉测试工程师，怎么去测试一个案例（准备，步骤，预期结果）。

2、作用：

• (1)防止测试的遗漏。
• (2)防止测试的重复。
• (3)测试用例可复用。
• (4)可发现SSR、HLD、LLD中的缺陷。
• (5)可估算测试用例执行的工作量。

3、测试用例八要素：

一般来说，编写用例时仅有红色标识的要素即可。

七、缺陷管理：

1、作用：

• (1)不会造成缺陷的遗漏；
• (2)便于缺陷的跟踪；
• (3)便于缺陷分析，进而预防缺陷。

2、缺陷报告的内容：

3、缺陷提交的原则：

• (1)再现：至少再现三次，如果不是每次都出现，记录重现率。
• (2)初步定位：对出现的缺陷的原因进行初步判断（前端还是后端的）。
• (3)延伸：对出现缺陷的模块的其他部分做检查，检查是否存在同样的问题。
• (4)压缩：精简任何不必要的信息，步骤要简洁清晰明了。
• (5)去除歧义：语义清晰，避免出现二义性。
• (6)中立：态度中立，表述事实。不添加情绪语言。
• (7)评审：提交缺陷前自己先检查一遍，对于初级测试工程师提交的缺陷需要增加有经验的同事进行同行评审。

4、缺陷管理工具：禅道、mantis、Bugzilla、BugFree、及一些自研工具。

5、缺陷跟踪流程：

一般由测试人员提交BUG后，经过测试经理评审，评审后指派给开发经理，开发经理进一步评审（评估），评审通过后指派给开发人员进行修复。不同公司该流程有所不同，以实际为准。