测试基础

此文章只是资料整合，未看内容正确性，若有问题，请指出，谢谢！

什么是软件测试？

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

软件测试的目的：

1.测试工作可以发现并修复软件中存在的缺陷，从而提高用户对软件的使用信心
2.测试操作可以记录软件使用过程中产生的一些数据，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误，从而降低同类型软件开发的风险
4.总结：测试工作的目的就是通过尽可能少的人力财才物力来查找并解决软件中存在的缺陷从而降低商业风险等

测试原则

1.测试证明软件存在缺陷：我们的测试工作只能证明当前软件是有缺陷而不能证明它没有缺陷
2.不能执行穷尽测试：具体的测试操作不可能将所有的情况都一一逻列出来，所以测试工作肯定有终止的时候
3.测试应当尽早介入：一般不要在开发完成之后才执行测试，这样不利于缺陷的尽早发现
4.缺陷存在群集现象：对于一款软件来说核心的功能只占20%，所以在测试的时候我们会花更多的时间去专门测试这些功能，因此它里面缺陷暴露的可能就会更大一些，我们就称之为缺陷群集现象。
5.某些测试操作依赖于特定的测试环境
6.杀虫剂现象：不要过多使用同一条测试案例来对软件进行问题查找，因为软件会产生“抗性”
7.不存在缺陷的谬论：任何的软件不可能是完美的

软件生存周期及其模型

软件生存周期(SDLC，软件生命周期)是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这样的一个过程，称为"生命周期模型"（Life Cycle Model）。这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

什么是软件质量

软件质量：软件产品的特性可以满足用户的功能、性能需求的能力。
软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

软件测试风险

测试人员：业务不熟、人员变动、疲态、同化效应、定位效应

测试材料：需求变更、质量标准不一样、测试用例或测试数据设计不充分

测试环境：测试软件版本不统一、软件环境不统一、硬件环境不统一、硬件不到位

测试时间：测试时间不足、测试时间延长

测试方法：错误或缺失测试方法、场景缺失、测试用例实施不充分

简述测试流程

软件测试阶段及介绍

软件测试阶段包括：
1、测试需求分析阶段；
2、测试计划阶段；
3、测试设计阶段；
4、测试执行阶段；
5、测试评估阶段。

软件测试流程简单叙述

1、阅读学习相关技术文档（如产品PRD、UI设计、产品流程图等）。
2、参加需求评审会议。
3、根据最终确定的需求文档编写测试计划。
4、编写测试用例（等价类划分法、边界值分析法等）。
5、用例评审(主要参与人员：开发、测试、产品、测试leader)。
6、开发提交代码至SVN或者GIT ，配管搭建测试环境。
7、执行测试用例，记录发现的问题。
8、验证bug与回归测试。
9、编写测试报告。
10、确定产品是否上线。

软件开发流程

测试计划编写

测试计划

• 测试目标
  1.1. 根据xxx需求，提炼测试功能点、制定测试策略、评估测试 风险，预估编写测试用例、执行功能测试和回归测试的工作量，进行人员和进度 安排
• 测试范围
  2.1. 功能模块
  2.1.1. 需结合实际情况
• 测试资源
  3.1. 人员安排
  3.2. 测试环境
  3.3. bug管理
• 测试策略
  4.1. 功能测试
  4.2. 性能测试
  4.3. 兼容性测试
• 测试进度安排
  5.1. 测试进度安排
  5.1.1. 任务
  5.1.2. 时间
  5.1.3. 执行人员
  5.1.4. 工作量
  5.2. 输出文档
  5.2.1. 测试计划
  5.2.2. 测试报告
• 通过标准
  6.1. 测试验收标准
  6.1.1. 1.完成所有类型测试 ,没有影响到用户业务使用的bug ,bug数量少于一定数量 , 功能业务，性能指标符合需求
  6.2. 产品上线标准
  6.2.1. 产品checklist
  • 1. 已按照交互文档、需求文档完全的实现需求；
  • 2. 符合交互稿的交互设计规范、符合视觉要求，已经通过设计评审；
  • 3. 允许遗留可能会对用户正常使用造成一定影响的正常级缺陷，但应在发布前告知项目组，并经风险评估同意发布后方可发布
• 风险评估
  7.1. 1.测试范围风险 （测试遗漏，需求变更）
  7.2. 2.测试进度风险（预估量不准确，测试人员变动，其他业务工作，）
  7.3. 3.产品质量风险（代码质量，测试人员能力）

测试用例

一、什么是测试用例测试用例：

 为了特定的目的（证明软件存在某问题）而设计的一组由测试输入、执行条件、预期结果构成的文档
1、测试用例简单来说就是指导如何做测试的文档，用于核定某个特定软件需求
2、测试用例表现形式常见的有两种，可以以模板形式展示
1）一种是通过Excel直接编写
——大多数项目中都需要按照这种方式设计编写
2）一种是通过xmind直接整理测试点
——时间紧迫，项目没有强制要求时，可以设计测试点的形式编写
——对于业务流程类的测试，也可以整理为测试点进行测试
3、设计及执行人员：测试工程师
4、用例的模板：描述编写用例核心内容，一般项目都有自己的设计用例的模板，常见测试用例模板可参照如下：

用例编码  英文+数字表示唯一性
用例标题  验证某个功能的目的，和用例编号一一对应
测试项目  用例属于哪个项目
用例级别  优先级，当前测试功能点对于系统的影响
前置条件  执行的前提条件
测试数据  测试过程中具体输入的数据，没有可不写
执行步骤  验证操作步骤，按编号编写
预期结果  希望得到的结果
实际结果  实际得到的结果
备注

为什么要写测试用例？

• 技术上将需求转化为具体可验证的指标
• 以文档的形式记录软件可能存在的问题
• 防止测试过程的活动出现遗漏，提高工作效率
• 测试工作量的展示

测试用例编写流程：

需求分析–》提取测试点–》测试用例编写–》测试用例评审

测试用例常用设计方法：

软件测试用例设计：白盒、黑盒、接口等
黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。
其中 等价类划分法、边界值分析法、因果图法、场景法、正交表、测试大纲法、错误推断法、随机测试，是常用测试方法

一、等价类划分法

定义：等价类划分法是把所有可能输入的数据，即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。是一种重要的、常用的黑盒测试用例设计方法。
  等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试，因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况：有效等价类和无效等价类。

有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明所规定的功能和性能。

无效等价类 指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能多个
划分标准：

1. 完备测试、避免冗余
2. 划分等价类重要的是：集合的划分、划分为互不相交的一组子集，而子集的并是整个集合
3. 并是整个集合
4. 子集互不相交：保证一种形式的无冗余性
5. 同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到“相同的执行路径”。
     例如，我们要测试一个用户名是否合法，用户名的定义为：8位数字组成的字符。

• 我们可以先划分子集：
    空用户名，1-7位数字，8位数字，9位或以上数字，非数字。
• 然后从每个子集选出若干个有代表性的值：
  　　空用户名：“” （无效等价类实例）
  　　1-7位数字：”123” （无效等价类实例）
  　　8位数字：”00000000” （有效等价类实例，）
  　　9位或以上数字：”1234567890” （无效等价类实例）
  　　非数字：”abc！@#” （无效等价类实例）
  　　他们5个，就是用等价类划分选出的测试用例。实际上，对于1-7位数字的子集来说，选“123”和“11111”没有本质的区别。
  等价类的划分，最关键的是子集的划分。实际上，非数字还可以继续划分子集：字母，特殊字符。

二、边界值分析法

  通过测试发现，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值，测试用例可以记为min，min+，max，max-。
  例如，假定 X 为整数,10≤X≤100,那么 X 在测试中应该取的边界值为：10，11，99，100。
　　注：上面只是说边界值，如果是完整的测试，除了边界值外，还需要一个正常值，即12-98之间的任意值。

三、错误推测（使用少）

错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

四、判定表法（决策表）

  又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表。

例如，某公司的对客户分类标准如下：
　　顾客每次订货额在 1000元以上（含1000元），信誉好的，订单设“
优先”标志；
　　信誉不好，但是老客户的，订单设“优先”标志；
　　信誉不好，但是新客户的，订单设“正常”标志；
　　每次订货额在 1000元以下，订单设“正常”标志。
　　绘制的决策表如下：
　　

• 从表格中分析，我们发现，当订货金额>=1000，信誉好时，无论是老顾客还是新顾客，都设为优先，1，2列可以整合在一起
• 观察5，6，7，8列，只要是订货金额<1000，无论其他两个条件如何，都设为正常，因此，5，6，7，8列可以合并。
• 综上，整理后的表格为：
  

五、正交表法

正交表是一种特制的表格，一般用Ln（m^k）表示，L代表是正交表，n代表试验次数或正交表的行数，k代表最多可安排影响指标因素的个数或正交表的列数，m表示每个因素水平数，且有n=k*(m-1)+1.
1.案例
用户拨打114查询某公司电话时，工作人员需要输入的查询条件有5个，如图：

解：

• 一般的测试方法需要设计 2^5 个测试用例
  （1）找出因素数（变量）和水平数（变量的取值）
  由图，共有5个变量：音型码、拼音码、路名码、行业类别、特征码
  共有2种变量取值：填写或者不填写
  （2）选择合适的正交表

• 正交表因素数 >= 5

• 正交表水平数 >= 2

• 正交表行数最少

  按上述条件查表得：
  L₈(2⁷)
  
  （3）把变量映射到表中
  1：填写 2：不填
  
  （4）将每行的因素水平组合作为一个测试用例
  （5）增补可疑的、未在表中出现的测试用例
  因素水平组合生成测试用例：
  音形码填写、拼音码填写、路名码填写、行业类别填写、特征码填写
  音形码填写、拼音码填写、路名码填写、行业类别不填、特征码不填
  音形码填写、拼音码不填、路名码不填、行业类别填写、特征码填写
  音形码填写、拼音码不填、路名码不填、行业类别不填、特征码不填
  音形码不填、拼音码填写、路名码不填、行业类别填写、特征码不填
  音形码不填、拼音码填写、路名码不填、行业类别不填、特征码填写
  音形码不填、拼音码不填、路名码填写、行业类别填写、特征码不填
  音形码不填、拼音码不填、路名码填写、行业类别不填、特征码填写
  增补测试用例：（只填写一种查询条件）
  音形码填写、拼音码不填、路名码不填、行业类别不填、特征码填写
  音形码不填、拼音码填写、路名码不填、行业类别不填、特征码不填
  音形码不填、拼音码不填、路名码填写、行业类别不填、特征码不填
  音形码不填、拼音码不填、路名码不填、行业类别填写、特征码不填
  音形码不填、拼音码不填、路名码不填、行业类别不填、特征码填写

• 正交实验设计方法时从大量的试验数据中挑出适量的、有代表性的点，从而合理的安排测试。

• 如上案例所示，测试用例太多影响投入产出比；利用正交表可解决。

• 设计方法
  1.找出测试中的因素数（变量）和水平数（变量的取值）
  2.匹配合适的正交表
  正交表因素数 >= 测试因素数
  正交表水平数 >= 测试水平数
  正交表行数最少
  3.将测试的变量映射到已选正交表上
  4.将每行的因素水平组合为一个测试用例
  5.增补可疑的、未在表中出现的测试用例

六、因果图法

1.案例
某系统业务单据处理规则如下；
对于处于提交审批状态的单据，数据完整率达到80%以上或已经过业务员确认，则进行处理
解：

（1）列出可能的输入、输出并编号
输入：
C1:单据处于提交审批状态
C2:单据数据完整率达到80%
C3:单据经过业务员确认
输出：
E1:处理
E2:不处理

（2）找出输入输出的对应关系
若单据不处于提交审批状态，则不处理
若单据处于提交审批状态且数据完整率达到 80%，则处理
若单据处于提交审批状态且经过业务员确认，则处理

（3）画出因果图

（4）将因果图转换为判定表

（5）将判定表转化为测试用例 (略)
2.分析

what?

因果图法就是从需求中找出因（输入条件）果（输出结果或程序状态改变），通过分析输入条件之间的关系（组合关系、约束关系等）以及输入与输出之间的关系，制成因果图，转化为判定表，最后生成测试用例。

why?

等价类划分法和边界值分析法只考虑了输入条件，但是没有考虑输入条件之间的组合、制约关系，而实际输入之间存在着相互依赖关系。

how?

–因果图中的符号：

• Ci 表示原因
• Ei 表示结果
• 恒等：原因结果同时出现
• 与：原因都出现，结果才出现；原因任意一个不出现，结果不出现
• 或：原因任意一个出现，结果出现；原因多不出现，结果不出现
• 非：原因不出现，结果出现；原因出现，结果不出现
• –因果图中的约束：

输入条件

• E 表示a、b两个原因不能同时成立
• I 表示a、b、c中至少有一个条件成立
• O 表示a、b条件中有且仅有一个成立
• R表示当a出现时b也必须出现

输出条件

M 表示结果a是1，则结果b强制为0

–因果图法步骤：

1.分析所有可能的输入输出，并赋予标识符

2.找出输入输出之间的关系

3.根据关系画出因果图

4.将因果图转换为判定表

5.根据判定表生成测试用例

七、场景分析法

1.案例
用户在线购物。选购物品后，进行在线购买。这是需要使用账号登录，登录成功进行付款交易，交易成功后生成订单，完成整个购物过程。
解：
（1）确定基本流，备选流
基本流：选购—登录—付款—生成订单
备选流1：用户名不存在
备选流2：密码错误
备选流3：用户账户余额不足
备选流4：用户账户没钱
（2）根据基本流和备选流确定场景
场景1：购物成功（基本流）
场景2：用户名不存在（基本流，备选流1）
场景3：密码错误（基本流，备选流2）
场景4：账户余额不足（基本流，备选流3）
场景5：账户没钱（基本流，备选流4）
（3）每一个场景生成对应的测试用例

• V 表示这个条件必须是有效才能执行基本流
• I 表示在该种条件下激活备选流
• n/a 表示这个条件不使用测试用例

（4）设计测试数据

2.分析
what?

分析软件应用场景，从用户角度出发，从场景角度设计测试用例，是一种面向用户的测试用例设计方法。

基本流：经过用例的最简单路径（正常流程）
备选流：一个备选流可以从基本流开始，在某个特定条件下执行，然后重新加入基本流中；也可以起源于另一个备选流，或终止用例。不在加入备选流中。（一般为错误流程）

why?

从用户角度出发，是一种面向用户的测试用例设计方法。

how?

1.根据需求，描述出程序的基本流以及各项备选流

2.根据基本流和各项备选流生成不同的场景

3.对每一个场景生成相应的测试用例

4.对生成的测试用例重新复审，去掉多余的测试用例

5.测试用例确定后，为每一个测试用例确定测试数据值

常用测试方法

一、按是否查看程序内部结构分为：

1、黑盒测试（Black Box Testing）：
  黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。简单来说，这种测试只关心输入和输出的结果，并不考虑程序的源代码。黑盒测试分为功能测试和性能测试：
1)功能测试（function testing），是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。包括逻辑功能测试、界面测试、易用性测试和兼容性测试。
2)性能测试（performance testing），软件的性能主要有时间性能和空间性能两种。其中，时间性能主要指软件的一个具体事务的响应时间，而空间性能主要指软件运行时所消耗的系统资源。
2、白盒测试（White Box Testing）：
  白盒测试是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。与黑盒测试相反，这种测试就要研究程序里面的源代码和程序结构。
1>语句覆盖：就是设计若干个测试用例，运行被测程序，使得每一个可执行语句至少执行一次。

2>判定覆盖：使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。

3>条件覆盖：条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支

4>判定条件覆盖：判定-条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件取值组合至少执行一次。

5>条件组合覆盖：在白盒测试法中，选择足够的测试用例，使所有判定中各条件判断结果的所有组合至少出现一次，满足这种覆盖标准成为条件组合覆盖。

6>路径覆盖：是每条可能执行到的路径至少执行一次
3、灰盒测试（White Box Testing）：
  定义：介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现

二、按是否运行程序分为（程序执行状态）

1、静态测试（static testing）：
静态测试指测试不运行的部分，只是静态地检查程序代码、界面或文档可能存在的错误的过程。例如测试产品说明书，对此进行检查和审阅.。
2、动态测试（dynamic testing）：
动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。具体操作就是输入相应的测试数据，检查输出结果和预期结果是否相符的过程。

三、按阶段分为：

1、单元测试（Unit Testing）：
单元测试是最微小规模的测试，测试的是某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。
2、集成测试（Integration Testing）：
集成测试是指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。
3、系统测试（System Testing）：
系统测试是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试
4、验收测试（Accept Testing）：
验收测试是基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。一般从功能、用户界面、性能、业务关联性进行测试。
5、回归测试（Regression testing）：
回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

四、按程序执行方式：手动测试和自动化测试

1、自动化测试，：
顾名思义就是软件测试的自动化，即在预先设定的条件下运行被测程序，并分析运行结果。总的来说，这种测试方法就是将以人驱动的测试行为转化为机器执行的一种过程。
2、手动测试，：
手动测试，其在设计了测试用例之后，需要测试人员根据设计的测试用例一步一步来执行测试得到实际结果，并将其与期望结果进行比对

软件测试级别？

针对不同研发阶段的测试目的，测试活动分为需求测试、组件/单元测试、集成测试、系统测试、验收测试、Alpha测试、Beta测试、UAT测试等级别。

需求测试

软件测试双V模型要求测试工程师在需求阶段就开始制定系统测试计划，考虑系统测试方法，但这还不够。全面的质量管理要求在每个阶段都要进行验证和确认的活动。因此在需求阶段，测试工程师还需对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，70%～85%的返工是由于需求方面的错误所导致。因需求错误导致大量返工，造成进度延迟，缺陷发散甚至项目失败，这是一件极其痛苦的事情。因此测试工程师需在软件生产源头-需求就开始测试。

需求测试（Requirement Test）的重点是检查需求规格说明书中是否存在描述不准确、定义模糊、需求用例不正确、语言存在二义性等问题。主要从以下几个方面考虑。

1. 完整性。

每一项需求都必须将所要实现的功能描述清楚，为开发人员设计和实现这些功能提供所有必要的需求依据。

2. 正确性。

每一项需求都必须准确地陈述其要开发的功能。

3. 一致性。

一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾，或者与项目宣传资料一致。

4. 可行性。

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

5. 无二义性。

对所有需求说明书的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户语言表达出来。

6. 健壮性。

需求说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

7. 必要性。

必要性可理解为每项需求都是用来授权编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如需求用例或其他来源。

8. 可测试性。

每项需求都能通过设计测试用例或其他的验证方法来进行测试。

9. 可修改性。

每项需求只应在软件需求规格说明书中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

单元测试：单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。Findyou又称为模块测试，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。（测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试）

集成测试：（集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

系统测试：将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

验收测试:验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。总结验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务，即软件的功能和性能如同用户所合理期待的那样。测试内容：同系统测试(功能…各类文档等)

对于项目类的软件系统，一般都需要进行验收测试。验收测试通常情况下可有Alpha测试、Beta测试、UAT测试等验收测试形式。

一、Alpha测试

Alpha测试是由用户在开发环境下进行的测试，也可以是在开发机构内部的用户模拟实际操作环境中进行测试。进行Alpha测试时，软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用问题，Alpha测试在受控的测试环境下实施，其目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和技术支持）是否达标。

二、 Beta测试

Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与Alpha测试不同的是，进行Beta测试时，开发者通常不在测试现场。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用，测试者发现问题后，统一收集提交至开发人员进行修复。

三、UAT测试

UAT测试（User Acceptance Test）即用户接受度测试。一般用于商业用户验证系统的可用性。通常情况下，由采购方组织终端用户或软件利益相关方对被测对象进行选择性功能试用，关注被测对象核心功能的应用表现，从而为接受该软件系统提供数据依据。例如，银行在外包项目交付时，组织部分行方终端应用人员（如柜台服务人员）进行验收性测试，即为UAT测试。

UAT模式测试还有一种可能，就是根据法律法规、行业现行标准进行验收测试。例如，某政府机关采购的环保监控系统，需遵守政府管理需求及环保法规的约定。

alpha测试和beta测试的区别

1、测试时间不同：

Beta测试是软件产品完成了功能测试和系统测试之后，产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。

alpha测试简称“α测试”，可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

2、测试的目的不同：

α测试的目的是评价软件产品的(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试即为非正式验收测试。

Beta测试是一种验收测试，通过了验收测试，产品就会进入发布阶段。

测试人员及场所不同：

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员或测试员完成。α测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。

Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。

软件测试类型

功能测试：也叫黑盒测试，功能测试指测试软件各个功能模块是否正确，逻辑是否正确。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面(GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。

性能测试：指验证软件的性能可以满足系统规格给定的指定要求的性能指标。性能测试是一个比较大的范围，可以进一步衍生出负载测试、强度测试、压力测试、稳定性测试。通过自动化测试工具模拟多种正常、异常、峰值条件，对系统各项性能指标测试

配置测试：用硬件来测试软件运行情况，1.软件在不同主机上运行的情况（Apple和Dell）2.在不同组件上运行情况（开发的拨号程序要测试不同厂商生产的Moden上运行情况）3.不同的外设、接口、内存的运行情况

强度测试：强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

负载测试：通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

压力测试：压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。测试出系统所能承受的最大极限。是指系统在极限下的压力情况，系统在什么样的压力下会导致系统得到失效，无法正常运行。100个用户连续访问1小时可以看做是压力测试，连续访问10小时可以认为是负载测试

稳定性测试：压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。一般是稍大于业务量的一个负载，对系统进行的一个持续的，长时间的测试，比如24*3,连续3天的施加压力，确定系统在较长运行时间的情况下，系统的稳定性情况

网络测试：wifi、4G、3G、不同运营商网络测试、

UI界面测试：UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等。

分辨率测试：测试在不同分辨率下，界面的美观程度,分为800600，1024768，1152864，1280768，12801024，12001600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

安装测试：安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。

内存测试：CPU测试、响应时间测试、唤醒率测试等，都属于性能测试。还有强度测试、容量测试、基准测试等。

文档测试：文档测试是检验样品用户文档的完整性、正确性、一致性、易理解性、易浏览性。包括用户手册、使用说明、用户帮助文档等

可靠性测试：这个主要是硬件方面的，比如高低温测试、防水防尘等测试

安全测试：对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网管、关来访问。比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

兼容测试：检查软件在不同软件、硬件平台是否可以正常运行。 主要查看在不同操作系统、浏览器、数据库、不同版本是否正常运行、向前兼容和向后兼容、、数据共享兼容

浏览器兼容性测试：测试软件在不同产商的浏览器下是否能够正确显示与运行、比如测试IE，Natscape浏览器

操作系统兼容性：测试软件在不同操作系统下是否能够正确显示与运行；比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？

硬件兼容性测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用。比如在INTER,舒龙CPU芯片下系统是否能够正常运行？

并发测试：并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。

Bug的生命周期？

作为一名测试人员，重要的工作内容之一，就是找BUG，提交BUG，验证BUG，推进BUG的解决，直至软件达到发布的标准，提高软件的质量，及研发的工作效率和质量。
要找BUG，那么，就要先了解一下BUG的定义是什么？

BUG的定义

软件的BUG,狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
我们的职责就是，发现这些BUG，并提交给开发，让开发去修改。

BUG的由来

1、缺乏有效沟通

2、软件的复杂度

3、编程错误

4、不断变更的需求

5、时间的压力

了解了BUG的定义以及由来后，那就要去了解BUG的类型，只有了解了BUG的类型，才能有的放矢，才能有目的，有范围的去寻找BUG，避免盲目寻找BUG，浪费宝贵的测试时间。

BUG的类型

要确定一个BUG的类型，需要对项目（或产品）有比较深的理解。这个划分对于问题类型的统计就比较重要了。
划分方式一：
功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、文档错误、兼容问题、用户体验、其它。
划分方式二：
功能类、性能类、界面类、易用性类、兼容性类、其它。
  找到BUG后，那么，就要对BUG区分等级，以便开发人员，根据BUG的优先级来处理BUG，优先解决紧急的，致命的BUG，次要解决严重的BUG，接着解决一般的BUG，再接着解决轻微的BUG，最后，解决界面上的细小问题，这样，能提高软件研发的进度，提高软件的质量。

BUG的等级

Bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高，那么可能被修复的等级会高一些，有些公司还会根据你提的BUG数量和BUG等级来考察你的绩效。很多情况下，我们提交BUG大致的等级差不多即可，没有严格区分。

如何判断BUG的等级（严重程度1、2、3、4），一般可以参照下面的判断条件

1、致命错误（1级提BUG需慎重）

（1）常规操作引起的系统崩溃，死机，死循环

（2）造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露

（3）涉及金钱

（4）用户数据受到破坏，或者危及人身安全

2、严重错误

（1）重要功能不能实现；

（2）错误的涉及面广，影响到其他重要功能的正常实现；

（3）严重操作导致的程序崩溃、死机、死循环；

（4）外观难以接受的缺陷；

（5）密码明文显示；

（6）数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响

3、一般错误

不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷

（1）次要功能不能正常实现；

（2）操作界面错误（包括数据窗口内列名定义、含义不一致）；

（3）查询错误，数据错误显示；

（4）简单的输入限制未放在前端进行控制；

（5）删除操作未给出提示；

4、细微错误

程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

（1）界面不规范；

（2）辅助说明描述不清楚；

（3）提示窗口文字未采用行业术语；

（4）界面存在文字错误；

找到BUG，提交BUG后，那么，就要进入BUG的生命周期了。

bug的生命周期

BUG的生命周期，就是一个BUG被发现到这个BUG被关闭的过程。

生命周期中缺陷（bug）状态：新建–>指派–>已解决–>待验–>关闭

发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

如果待验的BUG在验证时没有解决好，我们需要重新打开–指派—已解决—待验，循环这个过程。

中间其他状态：拒绝、延期等

设计如此（不是缺陷）：1、核对需求规格说明书 2、找业务或者产品进行确认 3、确认是设计如此（不是缺陷），则直接关闭BUG。4、确认设计不是如此，跟开发沟通，重新激活指派BUG

重复BUG： 测试人员找到对应重复BUG的ID。如果确认是重复BUG，直接关闭（通常是关闭，后面提交的那个重复的BUG）

无法重现：1、确认开发的环境，跟操作步骤是否跟测试人员一致；2、在与提交BUG相同的环境下，重复验证一定的次数，比如，15-20次等，再未重现BUG，将状态该为无法重现

注意事项：

开发人员应在BUG系统中，备注好以下信息：

已修改BUG应在该BUG的注释处，备注修改方案及信息，以备以后出现类似的问题时，可以快速的找到原因

设计如此（不是缺陷）、不予解决、延期解决的BUG、无法重现的BUG，应备注处理的原因，节省沟通的时间，以及，如果后续有相同问题时，可以快速查找到原因

重复BUG注明重复BUGID

状态处理
1.已经指派的BUG—已经指派给开发的，应随时关注并进行跟踪自己所提BUG的状态变化！如果一直未修复，提醒开发人员修改；如果已经修复等待测试环境更新后进行验证

2.已解决的BUG----等待测试环境更新后进行验证，验证通过则关闭；验证不通过则重新指派给开发

3.重复BUG----先去查看下是否跟开发指定的BUG或者，自己在BUG系统内看到的BUG重复？如果确定重复则关闭；如果不重复，说明原因，重新打开指派给开发。

4.不是缺陷----确认开发环境是否和测试环境一致，如果如开发所说不是缺陷则进行关闭；如果确认是缺陷跟开发沟通，沟通未达一致找产品/反馈老大确认，确认是BUG注明情况并再次指派给开发。

5.无法重现----确认开发环境是否跟测试环境一致？包括操作步骤，浏览器、环境、特定账号等，如果多个版本验证之后，如开发所说重现不了，依据BUG的严重程度跟产品，开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发。

6.不予解决—找产品经理进行确认。确认不予解决进行关闭；确认需要解决请备注原因并打开指派给开发

7.设计如此—找产品经理进行确认。确认设计如此进行关闭；确认是问题，备注原因重现指派给开发。

8.延期修改—请看下BUG严重程度，是否影响当前版本发布？与产品经理进行确认。不予延期请根据情况重新打开并将情况进行备注说明；确定延期则做好记录，后续版本进行关注。

参考：https://blog.csdn.net/hhl18/article/details/92780701

软件开发过程中测试主要工作

测试配合开发等进行需求分析和讨论，根据需求说明书指定《项目测试计划》，编写测试用例，建立测试环境。
测试负责新产品测试，原有产品的升级测试，负责软件问题解决过程跟踪，软件开发文档、开发工作的规范化，管理开发部门的产品文档，制作用户手册、操作手册，产品上限测试，监督软件开发过程执行，提高软件质量。

使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程

Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。
　
Bugzilla是一个搜集缺陷的数据库。它让用户报告软件的缺陷从而把它们转给合适的开发者。开发者能使用bugzilla保持一个要做事情的优先表，还有时间表和跟踪相关性。不是所有的”bug”都是软件缺陷。一些数据库中的内容是作为增强的请求(RFE)。一个RFE是一个严重级别字段被设为”enhancement”的”Bug”.人们常说”bug”,实际上意思是Bugzilla中的记录,所以RFEs经常被称作bug。

它能够为你建立一个完善的 Bug 跟踪体系, 包括报告 Bug, 查询 Bug 记录并产生报表,处理解决,管理员系统初始化和设置四部分。

特点
Bugzilla能够建立一个完善的bug跟踪体系：报告bug、查询bug记录并产生报表、处理解决bug、管理员系统初始化和设置四部分。（Bug管理系统的通性：比如TFS）
Bugzilla具有如下特点：

1．基于Web方式，安装简单、运行方便快捷、管理安全。

2．有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面详尽的报告输入项，产生标准化的bug报告。提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行bug统计。当缺陷在它的生命周期中变化时，开发人员、测试人员、及管理人员将及时获得动态的变化信息，允许你获取历史记录，并在检查缺陷的状态时参考这一记录。

3．系统灵活，强大的可配置能力。Bugzilla工具可以对软件产品设定不同的模块，并针对不同的模块设定开发人员和测试人员。这样可以实现提交报告时自动发给指定的责任人，并可设定不同的小组，权限也可划分。设定不同的用户对bug记录的操作权限不同，可有效控制进行管理。允许设定不同的严重程度和优先级。可以在缺陷的生命期中管理缺陷。从最初的报告到最后的解决，确保了缺陷不会被忽略。同时可以使注意力集中在优先级和严重程度高的缺陷上。

4．自动发送Email,通知相关人员。根据设定的不同责任人，自动发送最新的动态信息，有效的帮助测试人员和开发人员进行沟通。（每个人收到邮件后要自觉的进行相关处理）

Bugzilla操作说明：

用户登录及设置

1.1用户登录

1． 用户输入服务器地址http://192.168.1.128。

2． 进入主页面后，点击【Forget the currently stored login】，再点击【login in】进入。

3． 进入注册页面，输入用户名和密码即可登录。用户名为Email 地址，初始密码为用户名缩写。

4． 如忘记密码，输入用户名,点击【submit request】,根据收到的邮件进行重新设置。

1.2、修改密码及设置

1．Login登录后，【Edit prefs】->【accout settings】 进行密码修改。

2．【Edit prefs】->【email settings】 进行邮件设置。

3．【Edit prefs】-> 【permissions】 进行权限查询

Bugzilla操作说明：报告Bug

2.1.1测试人员报告Bug

1． 请先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个而自己去修改。

2． 若Bug不存在，创建一份有效的bug报告后进行提交。

3． 操作：点击New，选择产品后，填写下表。

4． 填表注意：Assigned to: 为空则默认为设定的 owner, 也可手工制定。CC: 可为多人，需用"，"隔开。Desription中要详细说明下列情况：

1） 发现问题的步骤

2） 执行上述步骤后出现的情况。

3） 期望应出现的正确结果。

选择group设置限定此bug对组的权限，若为空，则为公开。

5. 操作结果：Bug状态（status）可以选择Initial state 为New或Unconfirmed.

系统将自动通过Email通知项目组长或直接通知开发者。

6．帮助： Bug writing guidelines

2.1.2 开发人员报告Bug.

1. 具体方法同测试人员报告。

2. 区别： Bug初始状态将自动设为Unconfirmed，待测试人员确定后变为“New".

nBug的不同处理情况（1）

2.2.1 Bug的属主 (owner) 处理问题后，提出解决意见及方法。

1 . 给出解决方法并填写Additional Comments，还可创建附件（如：更改提交单）

2．具体操作（填表项如下）

3 . 填表注意：

FIXED 描述的问题已经修改

INVALID 描述的问题不是一个bug (输入错误后，通过此项来取消)

WONTFIX 描述的问题将永远不会被修复。

LATER 描述的问题将不会在产品的这个版本中解决.

DUPLICATE 描述的问题是一个存在的bug的复件。

WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。

Bug的不同处理情况（2）

2.2.2 项目组长或开发者重新指定Bug的属主。（owner）

1． 为此bug不属于自己的范围，可置为 Assigned,等待测试人员重新指定。

2． 为此bug不属于自己的范围，但知道谁应该负责，直接输入被指定人的Email， 进行Ressigned。

3. 操作：（可选项如下）

* Accept bug (change status to ASSIGNED)

* Reassign bug to

* Reassign bug to owner and QA contact of selected component

4． 操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。

Bug的不同处理情况（3）

2.2.3测试人员验证已修改的 Bug.

1． 测试人员查询开发者已修改的bug，即Status为"Resolved",Resolution为"Fixed".进行重新测试。（可创建test case附件）

2． 经验证无误后，修改Resolution为VERIFIED。待整个产品发布后，修改为CLOSED。

若还有问题，REOPENED，状态重新变为“New"，并发邮件通知。

3． 具体操作（可选择项）

1. Leave as RESOLVED FIXED

2. Reopen bug

3. Mark bug as VERIFIED

4. Mark bug as CLOSED

Bug的不同处理情况（4）

2.2.4 Bug报告者（reporter）或其他有权限的用户修改及补充Bug

1. 可以修改Bug的各项内容。

2. 可以增加建立附件，增加了相关性, 并加一些评论来解释你正在做些什么和你为什么做。

3． 操作结果：每当一些人修改了bug报告或加了一个评论，他们将会被加到CC列表中，bug报告中的改变会显在要发给属主、写报告者和CC列表中的人的电子邮件中。

Bug的查询

1．直接输入Bug Id，点击find 查询。可以查看Bug的活动纪录。

2．点击Query，输入条件进行查询。

3．查询Bug活动的历史

4．产生报表。

5．帮助：点击Clue.

Bug：关于权限的说明

1． 组内成员对bug具有查询的权利,但不能进行修改。

2． Bug的owner 和 reporter 具有修改的权利。

3． 具有特殊权限的用户具有修改的权利

Bug：BUG处理流程

1． 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。

2． 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

3． 开发者收到Email信息后，判断是否为自己的修改范围.

1） 若不是,重新reassigned分配给项目组长或应该分配的开发者。

2） 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充明）

4． 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）

1） 经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED

2） 还有问题，REOPENED，状态重新变为“New”，并发邮件通知。

5． 如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的owner，直到采取行动。

关于Bugzilla：
1．Bug按严重程度（Severity）分为：
Blocker，阻碍开发和/或测试工作
Critical，死机，丢失数据，内存溢出
Major，较大的功能缺陷
Normal，普通的功能缺陷
Minor，较轻的功能缺陷
Trivial，产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等
Enhancement，建议或意见
2．Bug按报告状态分类（Status）
待确认的（Unconfirmed）
新提交的（New）
已分配的（Assigned）
问题未解决的（Reopened）
待返测的（Resolved）
待归档的（Verified）
已归档的（Closed）
3．Bug处理意见（Resolution）
已修改的（Fixed）
不是问题（Invalid）
无法修改（Wontfix）
以后版本解决（Later）
保留（Remind）
重复（Duplicate）
无法重现（Worksforme）
参考：https://blog.csdn.net/weixin_30797199/article/details/98154970
总结来讲：

1. 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
2. 经验证无误后，修改状态为VERIFIED（已证实）.待整个产品发布后，修改为CLOSED（关闭）
3. 还有问题，REOPENED（重新打开），状态重新变为“New"，并发邮件通知。
4. 项目组长根据具体情况，重新分配给bug所属的开发者。
5. 若是，进行处理，断言并给出解决方法。(可创建补丁附件及补充说明)
6. 开发者收到Email信息后，判断是否为自己的修改范围。
7. 若不是，重新分配给项目组长或应该分配的开发者。
8. 测试人员查询开发者已修改的bug，进行重新测试。确认无误后，关闭该bug。

缺陷报告组成

①缺陷编号（Defect ID）:提交缺陷的顺序
②缺陷标题（summary）：简明扼要的描述缺陷
③缺陷的发现者（Defected By）:测试人员
④缺陷发现日期（date）：一般为当天
⑤缺陷所属的模块（subject）：在测试哪个功能模块时发现的bug.
开发组可以据此决定由谁负责修改该bug
⑥发现缺陷的版本（Defected in release）:
⑦指派给谁处理（Assigned to）:测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员。
⑧缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况
（1）测试人员发现缺陷，提交缺陷报告、把缺陷的状态置为new（新）
（2）开发经理验证提交的bug，如果是bug,把状态改为open（打开的bug，开发组承认的bug），指派给具体的开发人员解决；如果不是bug,把状态改为rejected（拒绝的bug）
（3）开发人员看到指派给自己解决的bug，进行缺陷修复，修改完后，把缺陷状态改为fixed（已经修复的bug，可以返测的bug）
（4）测试人员对修复的bug进行返测，若返测成功，将状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）

参考：https://blog.csdn.net/jiangshangchunjiezi/article/details/80240416

软件测试模型？

软件测试模型指的是软件测试和开发阶段的对应关系，它可以被用来指导整个软件测试过程，常见的软件测试模型包括：V模型、W模型、H模型、X模型，其中V模型是最具代表性的软件测试模型，需要掌握，其余模型了解即可

1、V模型

V模型从左往右依次是用户需求-需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试

（1）用户需求阶段：一般由甲方业务牵头部门成立需求编写小组，由小组人员编写并完善需求文档，有的项目也可能由乙方来完成。产出物为《XX业务需求》、《XX新增功能工程业务需求》、《XX新增功能及扩容改造业务需求》等

（2）需求分析阶段：由甲方业务人员、用户、开发人员等完成，针对需求文档进行细致研讨和分析，产出物为《需求分析说明书》、《需求规格说明书》等

（3）概要设计阶段：该阶段由开发人员完成，产出物为《概要设计说明书》

（4）详细设计阶段：该阶段由开发人员完成，产出物为《详细设计说明书》

（5）编码阶段：该阶段由程序员完成，产出物为程序，即源代码

（6）单元测试阶段：也叫模块测试，是最小的测试单位，理论上以白盒测试为主，测试对象一般就是一个功能、类、函数、窗口、菜单等。实际工作中，考虑成本问题，一般由程序员自己完成。测试依据是《详细设计文档》，从模型图中我们能看出，单元测试与详细设计相对应

（7）集成测试阶段：也叫组装测试，组装过程一般是逐步完成的，所以会形成很多临时版本，理论上以黑盒测试为主，核心模块适当采用白盒测试。测试依据是《概要设计文档》，从模型图中我们能看出，集成测试与概要设计相对应

（8）系统测试阶段：是在所有功能组装完成后，对集成了硬件、软件、数据的完整系统进行的测试。测试的重点在于系统在真实环境下的正确运行以及系统的兼容性问题，测试方法为黑盒测试，测试依据是《需求规格说明书》、《需求文档》等文档。从模型图中我们能看出，系统测试与需求分析相对应

（9）验收测试阶段：也叫用户接受度测试，是由用户参与的验收过程，包括alpha测试和beta测试。从模型图中我们能看出，验收测试阶段与用户需求阶段相对应

特点：

V模型是一个从左往右串行的模型

V模型中开发阶段和测试阶段划分明确，对应关系明确

V模型中既包括专业级测试（如单元测试、集成测试）又包括用户级测试（如验收测试）

V模型中没有体现对需求、文档和设计阶段的测试，容易被误解为测试工作只是开发完成后的收尾

V模型没有体现尽早测试和不断测试原则

2、W模型

W模型又称双V模型，它由V模型演变而来，弥补了V模型的不足。左边的V是开发的生命周期，右边的V是测试的生命周期

W模型不仅体现了对程序的测试，还体现了对需求、文档和设计阶段的测试

W模型是一个开发与测试并行的模型，能否清楚的看到开发和测试工作同步进行

W模型体现了尽早测试和不断测试原则

W模型也有其局限性，左边的V亦是把开发视为一系列串行的活动，无法支持迭代

3、H模型

H模型只体现了测试过程，未体现开发过程，它表明测试是一个独立的过程

H模型有一个测试就绪点，即达到准入条件（测试方案、测试策略、测试用例、测试环境、输入输出项等是否明确）才能继续执行

H模型的测试范围不仅仅是需求、文档和程序，它涉及整个产品包

H模型体现了尽早测试和不断测试原则

4、X模型

X模型也是对V模型的改进，X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成，最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生
此外，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高
参考：https://zhuanlan.zhihu.com/p/103765623

自动化测试软件作用：

一：jmeter：

纯java编写负载功能测试和性能测试开源工具， 支持接口自动化测试，录制、抓包、可进行压力测试（增加线程，考验服务器最大支持访问数）、弱网测试、添加请求、添加断言，查看断言、结果树，聚合报告，分析测试报告等

聚合报告参数详解：

1. Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值
2. Samples：请求数——表示这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100
3. Average：平均响应时间——默认情况下是单个 Request 的平均响应时间
4. Median：中位数，也就是 50％ 用户的响应时间
5. 90% Line：90％ 用户的响应时间
6. Min：最小响应时间
7. Max：最大响应时间
8. Error%：错误率——错误请求数/请求总数
9. Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second）
10. KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

二：ant：

将软件编译、测试、部署等步骤联系在一起加以自动化的一个工具，并生成测试报告并发送

三：jenkins：

Jenkins是一个开源CI服务器，基于Web访问，jenkins是基于Java开发的一种持续集成工具，用于监控持续重复的工作，能实时监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性，拥有大量的插件：这些插件极大的扩展了Jenkins的功能，持续集成工具，所有工作都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间和工作量；

四：monkey：

它是Android SDK系统自带一个命令行工具，可以运行在模拟器里或者真是设备中运行。向系统发送伪随机的用户事件流，实现对正在开发的应用程序进行稳定性测试。

五：charles：

1.抓包（http、https）：设置手机HTTP代理、https charles也需要证书

2.弱网测试：通过Throttle Settings（网络控制）、Enable Throttling（启用设置）、Throttle preset（通过预设网络值来拟定网络）、设置网络带宽值等

3.网络请求的截取并动态修改：

4.压力测试：通过右键点击链接，Repeat Advanced（重复），选择Iterations（重复次数）Concurrency（并发数）

5.数据替换：通过链接右键点击Map Local（本地位置）进入设置，选择替换数据文件，替换即可

六：selenium ：

web自动化测试框架（测试浏览器兼容性的自动化）selenium不支持桌面软件自动化测试。软件测试报告，和用例管理只能依赖第三方插件unittest优点:兼容更多的平台（ Windows、Linux 、 Macintosh等）以及浏览器（火狐，IE，谷歌等）

定位元素方式：id、name、class_name、tagname、link_text、partial_link_text、xpath、css_selector

强制等待：sleep()强制等待,不管你浏览器是否加载完,程序都得等待

显示等待：WebDriverWait,配合该类的until()和until_not()方法,就能够根据判断条件而进行灵活地等待了.它主要的意思就是:程序每隔多久查看一次,如果条件成立了,则执行下一步,否则继续等待,直到超过设置的最长时间,然后抛出TimeoutException

隐式等待：implicitly_wait(),整个driver周期有效，如果在规定时间内网页加载完成,则执行下一步,否则一直等到时间截止

七：appium：

开源测试自动化框架，可用于原生，混合和移动Web应用程序测试

两大组件：

一：Appium Server就是Appium的服务端——一个web接口服务，使用Node.js实现。

二：Appium Desktop是一款适用于Mac，Windows和Linux的开源应用程序，提供Appium自动化服务器的强大功能。

Appium GUI是Appium desktop的前身。 也就是把Appium server封装成了一个图形界面，降低了使用门槛。

因为Appium是一个C/S结构，有了服务端的肯定还有客户端，Appium Clients就是客户端，它会给服务端Appium Server发送请求会话来执行自动化任务。

Appium-desktop主界面包含三个菜单：

Simple
host：设置Appium server的ip地址，本地调试可以将ip地址修改为127.0.0.1
port：设置端口号，默认是4723不用修改
start server：启动 Appium server

Advanced：高级参数配置修改，主要是Android和iOS设备，log路径等相关信息的配置。
Presets：将Advanced中的一些配置信息作为预设配置。

八：pytest：

pytest是一个全功能的Python测试框架，

优点：
1、简单灵活，容易上手，文档丰富；
2、支持参数化，可以细粒度地控制要测试的测试用例；
3、能够支持简单的单元测试和复杂的功能测试，还可以用来做selenium/appnium等自动化测试、接口自动化测试（pytest+requests）;
4、pytest具有很多第三方插件，并且可以自定义扩展，比较好用的如pytest-selenium（集成selenium）、pytest-html（完美html测试报告生成）、pytest-rerunfailures（失败case重复执行）、pytest-xdist（多CPU分发）等；
5、测试用例的skip和xfail处理；
6、可以很好的和CI工具结合，例如jenkins
编写规则：
测试文件以test_开头（以_test结尾也可以）
测试类以Test开头，并且不能带有 init 方法
测试函数以test_开头
断言使用基本的assert即可

# -*- coding:utf-8 -*-
import pytest
 
@pytest.fixture(scope='function')
def setup_function(request):
    def teardown_function():
        print("teardown_function called.")
    request.addfinalizer(teardown_function)  # 此内嵌函数做teardown工作
    print('setup_function called.')
 
@pytest.fixture(scope='module')
def setup_module(request):
    def teardown_module():
        print("teardown_module called.")
    request.addfinalizer(teardown_module)
    print('setup_module called.')
 
@pytest.mark.website
def test_1(setup_function):
    print('Test_1 called.')
 
def test_2(setup_module):
    print('Test_2 called.')
 
def test_3(setup_module):
    print('Test_3 called.')
    assert 2==1+1              # 通过assert断言确认测试结果是否符合预期

fixture的scope参数
scope参数有四种，分别是’function’,‘module’,‘class’,‘session’，默认为function。

• function：每个test都运行，默认是function的scope
• class：每个class的所有test只运行一次
• module：每个module的所有test只运行一次
• session：每个session只运行一次

setup和teardown操作

• setup，在测试函数或类之前执行，完成准备工作，例如数据库链接、测试数据、打开文件等
• teardown，在测试函数或类之后执行，完成收尾工作，例如断开数据库链接、回收内存资源等
• 备注：也可以通过在fixture函数中通过yield实现setup和teardown功能

九：unitest：

unittest单元测试框架不仅可以适用于单元测试，还可以适用WEB自动化测试用例的开发与执行，该测试框架可组织执行测试用例，并且提供了丰富的断言方法，判断测试用例是否通过，最终生成测试结果

unittest.TestCase：TestCase类，所有测试用例类继承的基本类：
class BaiduTest(unittest.TestCase)

unittest.main():将一个单元测试模块变为可直接运行的测试脚本，main()方法使用TestLoader类来搜索所有包含在该模块中以“test”命名开头的测试方法并自动执行他们。

unittest.TestSuite()：unittest框架的TestSuite()类是用来创建测试套件的。

unittest.TextTextRunner():unittest框架的TextTextRunner()类，通过该类下面的run()方法来运行suite所组装的测试用例。

unittest.defaultTestLoader(): defaultTestLoader()类，通过该类下面的discover()方法可自动更具测试目录start_dir匹配查找测试用例文件（test*.py），并将查找到的测试用例组装到测试套件，因此可以直接通过run()方法执行discover。用法如下：discover=unittest.defaultTestLoader.discover(test_dir, pattern=‘test_*.py’)

unittest.skip():装饰器，当运行用例时，有些用例可能不想执行等，可用装饰器暂时屏蔽该条测试用例。一种常见的用法就是比如说想调试某一个测试用例，想先屏蔽其他用例就可以用装饰器屏蔽。

TestCase类的属性：

setUp():setUp()方法用于测试用例执行前的初始化工作。如测试用例中需要访问数据库，可以在setUp中建立数据库连接并进行初始化。如测试用例需要登录web，可以先实例化浏览器。

tearDown():tearDown()方法用于测试用例执行之后的善后工作。如关闭数据库连接。关闭浏览器。

assert()*:一些断言方法：在执行测试用例的过程中，最终用例是否执行通过，是通过判断测试得到的实际结果和预期结果是否相等决定的。

TestSuite类的属性：

addTest(): addTest()方法是将测试用例添加到测试套件中，是将test_baidu模块下的BaiduTest类下的test_baidu测试用例添加到测试套件。 suite = unittest.TestSuite() suite.addTest(test_baidu.BaiduTest(‘test_baidu’))

TextTextRunner的属性：

run(): run()方法是运行测试套件的测试用例，入参为suite测试套件： runner = unittest.TextTestRunner() runner.run(suite)

微信朋友圈测试用例：

自动化测试——po模型

selenium自动用例脚本，相似功能地方，代码基本都是一样的，界面元素换个查找方式，把原来的使用 xpath方式，改为使用 id 查找，需要对每个用例脚本都要改，虽然几个用例看不出什么工作量，但是重复findElement的代码，已经让我们感到了代码的笨重。如果某些定位发生了改变，我们就得贯穿整个测试代码进行调整元素定位，这样就会导致我们的脚本在后期，难以维护。
因此通过Page Object Model 我们可以创建更加健壮代码，并减少或者消除重复的测试代码，从而也能够提高代码的可读性，减少编写脚本的工作量。Page Object Model的实现，就是通过分离测试对象和测试脚本的抽象来实现的。简单来说就是代码的封装，将测试方法进行封装对外暴露方法实现调用，在调用界面直接调用某个方法输入具体元素值以及内容。

集成测试

集成测试是为了在集成时测试模块/组件，以验证它们是否按预期工作，即测试单独工作的模块在集成时没有问题。

在使用黑盒测试技术测试大型应用程序时，涉及多个彼此紧密耦合的模块的组合。我们可以应用集成测试技术概念来测试这些类型的场景。

什么是集成测试？

集成测试的含义非常简单- 将单元测试模块逐个集成/组合，并将行为测试为组合单元。

该测试的主要功能或目标是测试单元/模块之间的接口。

我们通常在“单元测试”之后进行集成测试。一旦创建并测试了所有单个单元，我们就开始组合这些“单元测试”模块并开始进行集成测试。

该测试的主要功能或目标是测试单元/模块之间的接口。

首先单独测试各个模块。模块经过单元测试后，逐个集成，直到所有模块都集成在一起，检查组合行为，验证需求是否正确实现。

在这里我们应该理解，集成测试不会在周期结束时发生，而是与开发同时进行。因此，在大多数情况下，所有模块实际上都无法测试，这就是测试不存在的东西的挑战！

为何进行集成测试

我们认为集成测试很复杂，需要一些开发和逻辑技能。确实如此！那么将这个测试集成到我们的测试策略中的目的是什么？

以下是一些原因：

1. 在现实世界中，当开发应用程序时，它被分解为更小的模块，并且为每个开发人员分配1个模块。一个开发人员实现的逻辑与另一个开发人员完全不同，因此检查开发人员实现的逻辑是否符合预期并根据规定的标准呈现正确的值变得很重要。
2. 很多时候，当数据从一个模块移动到另一个模块时，数据的面或结构会发生变化。附加或删除某些值，这会导致后续模块出现问题。
3. 模块还与某些第三方工具或API进行交互，这些工具或API也需要进行测试，以确保该API
   /工具接受的数据是正确的，并且生成的响应也是预期的。
4. 测试中一个非常常见的问题 - 频繁更改需求！:)许多时间开发人员在没有单元测试的情况下部署更改。当时集成测试变得很重要。

好处

这种测试有几个优点，下面列出的很少的一部分。

• 此测试可确保集成模块/组件正常工作。
• 一旦要测试的模块可用，就可以开始集成测试。它不需要完成其他模块以进行测试，因为Stubs和Drivers可以用于相同的操作。
• 它检测与接口相关的错误。

挑战

下面列出的是集成测试中涉及的一些挑战。

1. 集成测试意味着测试两个或多个集成系统，以确保系统正常工作。不仅应该测试集成链接，还应该考虑环境进行详尽的测试，以确保集成系统正常工作。
2. 管理集成测试变得复杂，因为它涉及的因素很少，如数据库，平台，环境等。
3. 在将任何新系统与遗留系统集成时，需要进行大量的更改和测试工作。在集成任何两个遗留系统时也是如此。
4. 如果在任何一个系统中进行任何更改都不确定，那么两个不同公司开发的两个不同系统的集成对于其中一个系统如何影响另一个系统是一个巨大的挑战。

为了最大限度地减少开发系统时的影响，应该考虑很少的事情，例如可能与其他系统集成等。

集成测试的类型

下面给出了一种测试集成及其优缺点。

大爆炸方法：

Big bang方法一次性集成了所有模块，即它不会逐个集成模块。它会在集成后验证系统是否按预期工作。如果在完全集成的模块中检测到任何问题，则很难找出导致该问题的模块。

大爆炸方法是一个耗时的过程，找到一个自身有缺陷的模块，因为这需要时间，一旦检测到缺陷，修复相同的方法会花费很高，因为在后期检测到缺陷。

大爆炸方法的优点：

• 这对于小型系统来说是一种很好的方法。

大爆炸方法的缺点：

• 很难检测出导致问题的模块。
• Big Bang方法需要所有模块一起进行测试，这反过来会导致更少的测试时间，因为设计，开发，集成将占用大部分时间。
• 测试仅在一次进行，因此不会孤立地进行关键模块测试。

集成测试步骤：

1. 准备集成测试计划。
2. 准备集成测试场景和测试用例。
3. 准备测试自动化脚本。
4. 执行测试用例。
5. 报告缺陷。
6. 跟踪并重新测试缺陷。
7. 重新测试和测试一直持续到集成测试完成。

测试集成方法
从根本上说，有两种方法可以进行测试集成：

1. 自下而上的方法
2. 自上而下的方法。

让我们考虑用下图来表述该测试方法：

自下而上的方法：

自下而上的测试，从应用程序的最低或最里面的单位开始，逐渐向上移动。集成测试从最低模块开始，逐步向应用程序的上层模块发展。这种集成一直持续到所有模块都集成在一起，整个应用程序作为一个单元进行测试。

在这种情况下，模块B1C1，B1C2和B2C1，B2C2是经过单元测试的最低模块。模块B1和B2尚未开发。模块B1和B2的功能是调用模块B1C1，B1C2和B2C1，B2C2。由于B1和B2还没有开发，我们需要一些程序或“刺激器”来调用B1C1，B1C2和B2C1，B2C2模块。这些刺激计划称为驱动程序。

简单来说，DRIVERS是虚拟程序，用于在调用函数不存在的情况下调用最低模块的函数。自底向上技术要求模块驱动程序将测试用例输入提供给被测模块的接口。

这种方法的优点是，如果在程序的最低单元存在重大故障，则更容易检测到它，并且可以采取纠正措施。

缺点是在最后一个模块被集成和测试之前，主程序实际上不存在。因此，只会在最后检测到更高级别的设计缺陷。

自上而下的方法：

该技术从最顶层的模块开始，逐渐向较低的模块发展。只有顶层模块是单独进行单元测试的。在此之后，下层模块逐个集成。重复该过程，直到所有模块都被集成和测试。

在我们的图中，测试从模块A开始，下层模块B1和B2逐个集成。现在，较低的模块B1和B2实际上不可用于集成。因此，为了测试最顶层的模块A，我们开发了“ STUBS ”。

“Stubs”可以称为代码片段，它接受来自顶层模块的输入/请求并返回结果/响应。这样，尽管模块较低，但是不存在，我们能够测试顶层模块。

在实际情况中，存根的行为并不像看起来那么简单。在这个复杂模块和体系结构的时代，被调用模块大多数时候都涉及复杂的业务逻辑，如连接数据库。因此，创建Stubs变得像真实模块一样复杂和耗时。在某些情况下，Stub模块可能会比受激模块更大。

Stub和驱动程序都是虚拟代码，用于测试“不存在”模块。它们触发函数/方法并返回响应，并将其与预期行为进行比较

让我们总结一下Stubs和Driver之间的一些区别：

唯一的变化是这个世界的常数，所以我们有另一种称为“ 三明治测试 ”的方法，它结合了自上而下和自下而上方法的特征。当我们测试像操作系统这样的大型程序时，我们必须拥有一些更有效的技术并增强信心。三明治测试在这里起着非常重要的作用，其中，自上而下和自下而上的测试同时开始。

集成从中间层开始，同时向上和向下移动。在我们的图中，我们的测试将从B1和B2开始，其中一个臂将测试上部模块A，另一个臂将测试下部模块B1C1，B1C2和B2C1，B2C2。

由于这两种方法同时开始，这种技术有点复杂，需要更多的人以及特定的技能组合，从而增加了成本。

启动集成测试的步骤

1. 了解应用程序的体系结构。
2. 确定模块
3. 了解每个模块的功能
4. 了解数据如何从一个模块传输到另一个模块。
5. 了解数据如何输入和接收到系统中（应用程序的入口点和出口点）
6. 隔离应用程序以满足您的测试需求。
7. 确定并创建测试条件
8. 一次采取一个条件并记下测试用例。

集成测试的进入/退出标准
进入标准

• 集成测试计划文档已签署并批准。
• 已经准备好集成测试用例。
• 测试数据已创建。
• 开发的模块/组件的单元测试已完成。
  所有关键和高优先级缺陷都已关闭。
  测试环境设置为集成。

退出标准：

• 所有集成测试用例都已执行。
• 没有关键和优先级P1和P2缺陷被打开。
• 测试报告已经准备好了。

集成测试用例
集成测试案例主要关注模块之间的接口，集成链接，模块之间的数据传输，作为已经过单元测试的模块/组件，即功能和其他测试方面已经涵盖。

因此，主要思想是测试集成时两个工作模块的集成是否按预期工作。

对于示例集成Linkedin应用程序的测试用例包括：

• 验证登录页面和主页之间的接口链接，即当用户输入凭证并记录时，应将其定向到主页。
• 验证主页和配置文件页面之间的接口链接，即配置文件页面应该打开。
• 验证网络页面和连接页面之间的接口链接，即单击网络邀请页面上的接受按钮，一旦点击，就会在连接页面中显示接受的邀请。
• 验证通知页面之间的界面链接并说出恭喜按钮，即单击说恭喜按钮应指向新的消息窗口。
• 可以为此特定站点编写许多集成测试用例。以上四点只是了解测试中包含哪些Integration测试用例的一个示例。

集成是白盒还是黑盒技术？
集成测试技术可以在黑盒子和白盒技术中统计。黑盒技术是测试人员不需要任何系统内部知识的地方，即不需要编码知识，而白盒技术需要应用程序的内部知识。

现在，在执行集成测试时，它可能包括测试两个集成Web服务，这些服务将从数据库中获取数据并根据需要提供数据，这意味着可以使用白盒测试技术进行测试，而可以测试在网站中集成新功能使用黑匣子技术。

因此，集成测试不是黑盒子或白盒技术。

集成测试工具
有几种工具可用于此测试。

以下是工具列表：

Rational Integration Tester
TESSY
Protractor
Steam
系统集成测试
系统集成测试用于测试完整的集成系统。

在集成组件之前，模块或组件在单元测试中单独测试。

一旦测试了所有模块，就可以通过集成所有模块来完成系统集成测试，并对整个系统进行测试。

集成测试和系统测试之间的区别
集成测试是一种测试，其中集成了一个或两个经过单元测试的模块进行测试和验证，以验证集成模块是否按预期工作。

系统测试是对整个系统进行测试的测试，即所有模块/组件都集成在一起，以验证系统是否按预期工作，并且由于集成模块而不会出现问题。

结论
这是关于集成测试及其在白盒和黑盒技术中的实现。希望我们用相关的例子清楚地解释它。

测试集成是测试周期的一个重要部分，因为它可以在集成两个或多个模块时更容易找到缺陷，以便在第一步中将所有模块集成在一起。

它有助于在早期发现缺陷，从而节省了工作量和成本。它确保集成模块按预期正常工作。
参考：https://blog.csdn.net/chengyuweng7838/article/details/100996270

集成测试的环境？

1.硬件环境： 集成测试时，要尽可能的考虑用户使用的实际环境；当实际环境难以达到的时候，模拟环境考虑到与实际环境之间
可能存在的差异。

2.操作系统环境：考虑到不同的操作系统版本，对于可能使用的操作系统环境，要尽可能的测试到。

3.数据库环境：数据库的选择合乎实际情况。容量，性能，版本等多方面考虑。

4.网络环境：一般的网络环境可以使用以太网、wifi、3G、4G。

集成测试通常都有那些策略？

1.大爆炸集成
2、自顶向下集成
3、自底向上集成
4、三明治集成适应于大部分软件开发项目
5、基干集成
6、分层集成
7、基于功能的集成
8、基于消息的集成
9、基于风险的集成
10、基于进度的集成

什么是测试脚本？

测试脚本是为了进行自动化测试而编写的脚本，测试脚本的编写必须对应相应的测试用例

测试脚本是一段代码不假。但是这段代码可能是为了执行某一条，或很多条测试用例而写的。也有可能 ，本身就是一条用例。

用例本身并不局限，在基于功能。脚本和用例没有并列的可比性。脚本可能是用例，也可能是执行用例用的功能。用例也可能是脚本。

公司的测试环境

开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。

测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。

生产环境：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。

三个环境也可以说是系统开发的三个阶段：开发->测试->上线，其中生产环境也就是通常说的真实环境。

UAT环境：UAT，(User Acceptance Test),用户接受度测试 即验收测试，所以UAT环境主要是用来作为客户体验的环境。

仿真环境：顾名思义是和真正使用的环境一样的环境（即已经出售给客户的系统所在环境，也成为商用环境），所有的配置，页面展示等都应该和商家正在使用的一样，差别只在环境的性能方面。

测试通过与失败标准

一般公司不同，标准也不一样，以下做参考：

1. 系统测试执行对需求达到覆盖100%
2. 系统功能测试，高级别和中级别测试用例100%执行，低级别用例执行率达到60%
3. 缺陷修复率达到80%及以上，且无致命及严重级别的缺陷未修复
   参考：https://www.cnblogs.com/JodieRao/p/10575222.html

测试挂起的标准及恢复的必要条件：

1.如果测试过程中发生致命问题，导致50%用例堵塞无法执行，需要将测试挂起，待导致堵塞的问题被修复后，恢复测试
2.如果高优先级用例未能100%执行，需要将测试挂起，等导致堵塞的问题被修复，并通过了回归测试后，恢复测试
3、不断的修改、变更版本引起部分结果失效，需要将测试挂起，待开发自检确定测试版本，且通过了回归测试后，恢复测试
4.如果项目因外界因素导致进展受阻，由项目经理批复后挂起，待项目经理通知重启后恢复测试

一级目录.测试退出标准：

单元测试退出标准

1. 单元测试用例设计已经通过评审
2. 核心代码100％ 经过Code Review
3. 单元测试功能覆盖率达到100％
4. 单元测试代码行覆盖率不低于80％
5. 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
6. 不存在A、B类缺陷
7. C、D、E类缺陷允许存在
8. 按照单元测试用例完成了所有规定单元的测试
9. 软件单元功能与设计一致

集成测试退出标准

1. 集成测试用例设计已经通过评审
2. 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
3. 按照集成构件计划及增量集成策略完成了整个系统的集成测试
4. 达到了测试计划中关于集成测试所规定的覆盖率的要求
5. 集成工作版本满足设计定义的各项功能、性能要求
6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
7. A、B类BUG不能存在
8. C、D类BUG允许存在,但不能超过单元测试总BUG的50％。
9. E类BUG允许存在

系统测试退出标准

1. 系统测试用例设计已经通过评审
2. 按照系统测试计划完成了系统测试
3. 系统测试的功能覆盖率达100％
4. 系统的功能和性能满足产品需求规格说明书的要求
5. 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
6. 系统测试后不存在A、B、C类缺陷
7. D类缺陷允许存在，不超过总缺陷的5％
8. E类缺陷允许存在，不超过总缺陷的10％
   注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况了。

保证测试的覆盖率 ？

测试需求分析分两步：

1、测试需求的获取 需求的来源：

显式需求：
1.原始需求说明书
2.产品规格书
3.软件需求文档
4.有无继承性文档
5.经验库
6.通用的协议规范

隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析

2，需求的分析，产生测试需求文档

将不同的需求来源划分成一个个需求点，针对每一点进行测试分析：界定测试范围，利用各种测试设计的方法产生测试点

在测试方法方面，可做如下注意：

其一，分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类组合，然后根据各位测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。

其二，多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手法也是需要注意的。毕竟测试方法比较容易找到，各位达人都很熟悉。如果将每个人不同的测试手法总结出来并在自己的测试实施中加以使用，可能会收到意想不到的成果。

二、当测试需求分析完成，并且形成文档后，要进行测试需求评审，保证需求的准确性以及完整性。

三、测试需求完成以后，可以根据测试需求设计测试用例。

要保证测试用例能够全面覆盖测试需求，要包含所有的情况。

测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑。

在设计测试用例的时候，可以使用多种测试用例设计方法。

●首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类,这是减少工作量和提高测试效率最有效的方法。

●必须使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。

●可以使用错误推测法追加一些测试用例，这需要依靠您的智慧和经验。

●对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测试用例。

●如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。

●对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

●对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。

当测试用例设计完成后，要组织测试用例的评审，这样可以吸取别人的意见，减少遗漏，补全测试用例。

四、测试用例编写完成后，就是测试执行

1.测试用例执行100%覆盖。2.在测试执行过程中，要继续对测试用例补充完善，确保提高测试覆盖率。

五、在整个测试过程中，需求都是不可能不变的，所以要及时的更新测试需求、测试用例。

六、要将测试需求、测试用例以及发现的bug关联起来，便于管理和跟踪，同时也便于查看覆盖率。

测试用例评审？

1. 评审就是对测试用例进行检查

2. 评审类型：同行评审、小组评审、部门评审、三方评审

3. 评审目的：发现测试用例不足，方便测试人员改进测试用例，提高测试质量

4. 评审过程：循环执行 “测试用例评审–》改进测试用例”

做好测试（用例）计划的关键？

1.明确测试计划

2.明确测试内容、测试过程、测试目的

3.测试范围与测试内容高度覆盖

4.测试结果的直观性、准确性

5.测试开始与结束时间

6.测试方法与测试工具的实用性

7.测试文档与测试软件

8.采用评审和更新机制

9.保证测试计划满足实际需求

完整的测试组成？

1.测试设计：需求分解，细化执行测试过程，为每个测试过程选择合适的测试用例

2.测试计划：根据需求和性能指标说明，定制相应测试计划，安排测试测试人员，测试内容，测试时间以及测试需要的资源

4.测试执行：建立自动化测试，对发现bug跟踪管理，按步骤测试（单元测试，集成测试，系统测试，验收测试）

5.测试评估：结合量化测试覆盖域以及bug跟踪，对软件质量，开发进度，工作效率等综合评价

所有的软件缺陷都可修复吗，都要修复吗？

理论上软件的缺陷是可修复的，不过有的修复成本比较高，不能追求软件的完美，根据风险来确定是否修复缺陷

1.没有足够的时间，在项目中没有足够时间修改缺陷可能会引出其他缺陷，导致项目的推迟

2.有些缺陷只在特殊环境下出现，这种缺陷处于项目的利益考虑可以放在以后版本中进行修复升级

3.不是缺陷的缺陷。缺陷的是否修改应该由测试人员、项目经理、程序员共同讨论决定，以确保项目的正常运行

参考：
https://my.oschina.net/zhangyujian/blog/754595
https://blog.csdn.net/weixin_33713350/article/details/92609118
https://blog.csdn.net/weixin_42693865/article/details/82935989