自动化测试

一、简介

　　自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

软件测试：

　　站在用户的角度下，对程序进行功能性、可靠性、安全性等测试的操作，达到用户满意的效果

软件工程：

　　把系统化、规范化、可度量的途径应用于软件开发、运行和维护的过程，也就是把软件工程化。

软件生命周期：

　　需求==>设计==>编码==>测试==>维护==>升级==>下线

 

二、测试模型

1、瀑布模型：

特点：上一阶段变换的结果是下一阶段变换的输入，相邻两个阶段具有因果相关系，紧密相联。

1.线性化模型结构

2.各阶段具有里程碑特性

3.基于文档的驱动

4.严格的阶段评审机制

 

优点：

　　--有利于大型软件开发人员的组织和管理

　　--有利于开发方法和工具的使用

　　--提高软件的质量和效率

缺点：

　　--各阶段的划分完全固定，阶段之间产生大量文档，极大增加了工作量　　

　　--由于是线性，用户只能在末期才能看到开发成果，极大增加开发的风险

　　--早期的错误可能要等到后期的测试阶段才能发现，极大增加了修复的成本

 

 2.V模型-瀑布模型的变型

优点：
既有底层测试又有高层测试。
将开发阶段清楚的表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。

缺点：
1.易让人误解为测试是在开发完成之后的一个阶段。
2.由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。
3.实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。

 

 

 

3.W模型-V模型的升级版

优点：
1.将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。
2.更早的介入到软件开发中，能尽早的发现缺陷进行修复。
3.测试与开发独立起来，并与开发并行。

缺点：
对有些项目，开发过程中根本没有文档产生，故W模型无法使用。 对于需求和设计的测试技术要求很高，实践起来很困难。　　

 

 三、开发模式

1.迭代式开发

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了定义、

需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。

再通过客户的反馈来细化需求，并开始新一轮的迭代。

 

2.敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

 

四、测试流程

1.产品研发流程

1.需求分析阶段，跟客户对接，生成产品需求文件，产品原始需求产生

2.需求评审，开发，测试工程师介入，除了运维工程师，其他人都参加

3.预研，Demo预研分析报告（需求阶段的评审，除了运维外基本参加）

4.需求规格设计（需求工程师），原始规格确定后，做规格设计产品规格说明书，SPEC设计原型产生

5.进行规格评审（需求阶段）

6.开发计划由各部门负责，软件设计及代码的实现（概要设计文档，软件设计文档）

7.设计评审，测试不用参加，搭建测试环境

8.测试人员写思维导图，5/7、并行进行

9.思维导图，测试方案，测试用例

10.测试用例评审，测试，产品，需求，负责模块开发人员

11.测试的执行，质量评估

12.产品上线

 

2.软件研发流程

1.测试分析，参加会议

2.测试计划、方案（思维导图）

3.测试用例，

4.搭建测试环境

 

3.测试流程图

1.需求分析
2.测试计划
3.测试方案
4.测试用例
5.测试执行
6.测试报告

五、人员组成 

1.软件项目成员

产品经理——靠想，产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润的。
项目经理——靠做，项目经理是把事情做正确，把事情做得完美，在时间，成本和资源约束的条件下完成目标。
架构师 / 技术顾问——技术专家，经验丰富，负责整个系统的体系架构的设计以及关键模块的设计。

需求工程师——负责需求调研，文档编辑和原型图的绘画
测试/开发负责人——负责自己组内的管理，和任务的安排

程序员 / 开发人员——设计、编写软件，并修复软件中的缺陷。
测试工程师——负责找出软件产品存在的问题并报告。

 运维工程师——负责环境和网络配置的相关维护和调试　　　　

 

概念：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估目的：发现bug、提高质量、降低成本

六、测试分类

1、测试质量

软件质量度量标准
　　1）软件需求是度量软件质量的基础，与需求不一致就是质量不高。

　　2）指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。

　　3）通常，有一组没有显式描述的隐含需求（如期望软件是容易维护的）。

　　　 如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。

 

 

2、测试过程

划分为：单元测试、集成测试、系统测试、验收测试

单元测试（开发）：

　　针对软件基本组成单元进行正确性检验的测试工作，检验程序模块

集成测试：

　　是在单元测试的基础上，将所有模块按照概要设计要求组装成为

　　子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。

系统测试：

　　系统测试是将已经集成好的软件系统，作为整个系统与计算机硬件、外设、

　　数据和人员等其他元素结合在一起，在实际运行环境下，对计算机

　　系统进行一系列的测试工作。

确认测试(冒烟测试)：

　　测试主流程

系统测试（SIT测试）：

　　本次需求所要实现的功能

　　轮次测试：第一轮，全覆盖测试，要发现85%的缺陷

　　　　  　　 第二轮，回归测试，5%

回归测试：

　　软件在测试中发现缺陷，再次进行回归测试，直到测试通过

 

 

 

验收测试UAT：

当软件产品是为特定用户开发的时候，需要进行一系列的验收，让用户验证软件产品是否满足了所有的需求。
如果软件是为了多个用户开发的，让每个用户逐个验证这个不切合实际，这个时候往往采用α测试和β测试，来进行验收。

 

α测试和β测试：

 

 

3、其他划分

随机测试（又名猴子测试）
　　随机选择测试数据做测试，主要根据经验进行功能和性能等抽查

敏捷测试（敏捷开发引发）
　　敏捷最大特点是高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。简单点理解：天下武功，唯快不破

 

七、测试方法分类

 

白盒测试（静态分析）：

　　也称为结构化测试或者逻辑驱动测试或基于代码的测试

使用白盒测试方法产生的测试用例：

　　保证一个模块中的所有独立路径至少被使用一次

　　对所有逻辑值需要测试True和False

　　在上下边界及可操作范围内运行左右循环

　　检查内部数据结构以确保其有效性

 

 

黑盒测试：

　　也叫功能测试，测试看不见的程序，主要是被测功能的实现

 

转载于:https://www.cnblogs.com/yuchne/p/10614015.html