自动化的软件测试
2017-03-08 20:23:36 qq_34420188 阅读数 1481

软件测试的对象包括:程序、数据、文档。目标程序和源程序都属于程序。


软件系统的主要测试内容及技术接口与路径测试 功能测试 健壮性测试 性能测试 用户界面测试 信息安全测试 压力测试 可靠性测试 安装/反安装测试。


软件测试的目的是尽可能多的找出软件的缺陷。


对手机可以施加的压力测试类型主要有:存储压力、边界压力、响应能力压力、网络流量压力。


并发压力是针对服务器的,因为每次并发是一个客户端。


首先可以新建场景,编写不同的测试脚本,当初我用java语言编写过测试脚本。

编写完成之后,就可以执行测试了;
测试结束之后,就可以生成各种图表,进行结果分析。
loadrunner  包括 脚本编辑工具, 测试执行工具, 结果分析工具。

设计系统测试计划需要参考的项目文挡有哪些?
【软件需求】是软件开发之前做好的,软件开发是根据这个做的,那么软件测试自然也需要参考该文件
【迭代计划】是软件的某个周期的计划,自然也需要参考
【可行性】是软件开发前做好,用于证明该计划可行的,没有必要参考


测试方法可以分成哪几种?

人工测试分为:个人复查、抽查和会审

按照测试实现,是否关心软件设计代码实现分为白盒和黑盒


做好文档测试需要注意的是:

仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例;
检查文档的编写是否满足文档编写的目的;
内容是否齐全,正确,完善;
标记是否正确;

2017-10-27 20:54:42 qq_16328677 阅读数 2773

软件测试–配置测试
配置测试是指使用各种硬件来测试软件运行的过程。
1.分离测试缺陷
判断缺陷是配置问题而不仅仅是普通缺陷最可靠的方法是,在另外一台有完全不同配置的计算机上一步步地执行导致问题的相同操作。若没有缺陷产生,就极有可能是特定的配置问题,在独特的硬件配置下才会暴露出来。
2.执行任务
确定测试哪些设备和如何测试的决定过程是相当直观的等价划分工作。在计划配置测试时应该采用的一般过程如下:

  • 确定所需的硬件类型:在选择哪些硬件来测试时容易忽略的一个特性例子就是联机注册。如果软件有联机注册功能,就需要把调制解调器和网络通信考虑在配置测试中。
  • 确定有哪些厂商的硬件、型号和驱动程序可以用。
  • 确定可能的硬件特性、模式和选项
  • 将确定好的硬件配置缩减为可控制的范围
  • 明确与硬件配置有关的软件唯一特性:唯一是指只需测试那些与硬件交互式互不相同(不同等价划分)的特性即可。
  • 设计在每一种配置中执行的测试用例
  • 在每一种配置中执行测试
  • 反复测试直到小组对结果满意为止:配置测试一般不会贯穿整个项目期间

3.获得硬件:对于需要的硬件来说,可以根据实际情况进行解决。
4.明确硬件标准

2018-12-26 21:59:37 qq_32126633 阅读数 1963

花了一个多星期整理上课使用的ppt,书写不易,请大家多多支持

概述

计算机系统的软件可靠性问题

  • 1994年,Intel奔腾芯片缺陷
  • 千年虫问题
  • ”冲击波“计算机病毒
  • 2008年奥运会门票预售叫停
    • 系统访问量超8倍
    • 票务系统抗压测试
    • 性能测试

软件质量

软件质量包括正确性,可靠性,可读性,可移植性和健壮性,主要含义是软件的可靠性

软件可靠性

特定环境下,在给定时间内,无障碍运行的概率

度量

  • 软件中初始故障的数量
  • 软件经过测试后,通过查错,改错,在软件中剩余故障的数量
  • 平均无故障时间
  • 故障间隔的时间长度
  • 故障发生率
  • 经过预测下次故障的发生时间

软件故障

定义

  • 从内部看,软件故障是软件产品开发或维护过程中存在的错误,毛病等各种问题
  • 从外部看,软件故障是系统所需要实现的某种功能的失效或违背

计算机系统或程序存在任何一种破坏正常运行能力的问题,错误,或者隐藏的功能缺陷等
软件故障导致软件产品在某种程度上不能满足用户的需求

  • 硬件故障

    物理性能恶化

  • 软件故障
    设计阶段人为因素造成的
  • 操作故障
    操作人员和维护人员的错误
  • 环境故障
    电源,外界干扰,地震,火灾,病毒等各种外界因素引起的故障

错误

人是会犯错的。过失是人犯下的,是人做一件错事或认为产生的一个不正确的结果

故障

故障时错误的结果

失效

故障引起的结果

软件测试与软件可靠性

  • 软件中都会有故障存在
  • 可以减少故障的引入,但是不可能完全杜绝软件中的故障

软件测试

  • 软件需求分析,设计说明和编码的最终复审
  • 是软件质量保证的关键步骤
  • 是为了发现故障而执行程序的过程

定义:

  1. 是否满足规定的需求
  2. 是否有差别
    测试是为了发现故障而执行程序的过程
  • 谁来执行
  • 测试什么
  • 什么时候测试
  • 怎样进行测试
  • 测试停止的标准
    • 成功采用了具体的测试用例设计方法
    • 每一类覆盖的覆盖率
    • 故障检测率
    • 检测出故障的具体数量或消耗的具体时间

软件生存周期

  • 制定计划
  • 需求分析
  • 设计
  • 程序编码
  • 测试
  • 运行维护

黑盒测试

不考虑内部结构和内部特性,只根据需求规格说明书,设计测试用例,检查程序的功能是否按照规范说明的规定正确的执行

  • 一切实际测试都是不彻底的

测试原则

黑盒测试与白盒测试

黑盒测试

  • 等价类划分
  • 边界值分析
  • 决策表驱动

白盒测试

  • 逻辑覆盖
  • 数据流测试
  • 域测试
  • 符号测试
  • 路径分析
  • 程序变异
  • 程序插装技术

软件测试过程

软件开发是自顶向下,软件测试自底向上

单元测试

又称模块测试,针对程序模块来进行正确性检验的测试工作

  • 模块接口测试
  • 局部数据结构测试
  • 路径测试
  • 错误处理测试
  • 边界测试

静态测试与动态测试

静态测试

不利用计算机运行被测试的程序,通过其他手段达到检测的目的

动态测试

通过运行和使用被测程序,发现软件故障,达到检测目的

回归测试

对程序进行测试已确定是否因修复故障而引入了新的故障

α\alpha测试

由一个用户在开发环境下进行的测试
目的是平价产品的功能,可使用性,可靠性,性能和支持

β\beta测试

软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场

α\alpha测试达到一定的可靠程度时才能进行β\beta测试,它处在整个测试的最后阶段

测试与调试

调试不属于测试
成功的测试发现错误从而引起调试的进行

测试生命周期

  • 测试计划
  • 测试设计
  • 测试开发
  • 测试执行
  • 测试评估

测试工具

测试评估

  • 测试覆盖测试
  • 软件故障评估
  • 测试有效性评估

软件质量评估

检查和评价当前软件开发过程,并设法达到防止软件故障出现

软件过程成熟度

  1. 初始度
  2. 可重复级
  3. 定义明确
  4. 定量管理级
  5. 优化级

第二章

三角形问题

三角形问题之所以复杂,是因为输入与输出之间的关系比较复杂

NextDate函数

  • 讨论输入域的复杂性
  • 确定闰年的规则

股佣金问题

功能性测试(黑盒测试)



优点

  • 功能性测试与软件如何实现无关
  • 测试用例的开发可以和实现并行进行

问题

  • 测试用例之间可能存在严重的冗余
  • 可能有未被测试的软件漏洞

常用测试方法

  • 边界值分析
  • 等价类划分
  • 决策表驱动法

边界值分析

基本原理:故障往往出现在输入变量的边界值附近
基本思想: 利用输入变量的最小值,稍大于最小值,正常值,稍小于最大值,最大值

  • 健壮性测试

    除了取5个边界值,还要采用一个略大于最大值,略小于最小值,看看超过极限时系统会出现什么情况

  • 最坏情况测试

    除了五个边界值,对五个边界值进行笛卡尔乘积运算,生成测试用例

等价类测试

把输入域划分成若干个互不相交的一组子集–等价类

  • 特点

    • 如果等价类中的一个元素作为测试数据进行测试不能发现程序中的故障,那么使用集合中的其他元素进行测试也不能发现故障

    对于揭露程序的故障来说,等价类的每个元素是等效的

  • 步骤

    1. 确定等价类
      
      • 有效等价类
        • 对程序规格说明,是有意义的,合理的输入数据所构成的集合

        具体问题中,有效等价类可以是一个,也可以是多个

      • 无效等价类
        • 对程序来说,是不合理或无意义的输入数据所构成的集合

        无效等价类可以一个,也可以多个

    2. 确定测试用例
      1. 为每个等价类规定一个唯一的编号
      2. 设计一个新的测试用例,尽可能多覆盖尚未被覆盖的有效等价类
      3. 设计一个新的测试用例,覆盖且覆盖一个还没有被覆盖的无效等价类
  • 弱一般等价类测试

    • 测试数据不考虑无效数据值
    • 测试用例使用每个等价类中的一个值
  • 强一般等价类测试

    • 需要将所有的等价类进行笛卡尔乘积,每部分设计一个测试用例
      • 笛卡尔乘积确保了两种意义上的完备性
        • 覆盖了所有等价类
        • 采用了所有可能的输入组合
  • 健壮性等价类测试

    • 遂与有效输入,测试用例使用每个有效类中的一个值
    • 对于无效输入,一个测试用例只拥有一个无效值,其他值都有效

      健壮指的是无效值的考虑
      强指的是多故障的假设

基于决策表的测试

最严格,最有逻辑严格性的测试方法

  • 优点
    • 把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏
  • 决策表

    描述不同条件集合下采取行动的若干组合情况

    • 利用决策表,可以很好的发现冗余和不一致性
    • 适用于
      • if-then-else逻辑很突出
      • 输入变量存在逻辑关系
      • 设计输入变量子集的计算
      • 输入与输出之间存在因果关系
      • 很高圈复杂度的程序

第三章 结构性测试

  • 特点
    • 基于被测试程序的源代码,而不是软件规格说明
    • 更容易发现软件测试故障,常用于单元测试

结构性测试

白盒测试又称结构测试或者基于程序的测试.

  • 该方法将被测对象看做一个打开的盒子,允许内部人员检查其内部结构.测试人员根据程序内部结构特性,设计,选择测试用例,检查程序的每条路径是否都按照预定的要求正确执行.

常见的白盒测试方法有:

  • 逻辑覆盖
  • 数据流测试
  • 域测试
  • 符号测试
  • 路径分析
  • 程序变异
  • 程序插装

逻辑覆盖

使用最广泛

  • 要求对被测试程序逻辑结构有清楚的了解,要能掌握程序的所有细节
  • 要求对被测试程序的结构做到一定程度的覆盖
  • 分为:
    • 语义覆盖

    是比较弱的测试覆盖准则

    • 判定覆盖

    又称之为分支覆盖,使得每个判断的取真分支和取假分支至少执行一次,即判断的真假值均要被检测

    • 条件覆盖

    每个判断的每个条件的可能取值至少被执行一次

    • 判定-条件覆盖

    判断中的每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果也至少被执行一次

    • 路径覆盖

程序控制图

  • 重要性
    明确地描述测试用例和测试用例所执行的程序部分之间的关系.

McCabe的基本路径法

测试观点

强连通图的圈数就是图中线性独立环路的数目

  1. 选择一条基线路径,一般选择有较多判断结点的路径
  2. 回溯基线路径

符号测试

基本思想

  • 允许程序的输入不仅可以是具体的数值数据,而且还可以包括符号值.
  • 执行过程中以符号计算代替了普通执行中的数值计算,所得到的结果自然是符号公式或符号谓词

    普通测试执行的事算数运算,符号测试执行的是代数计算

程序插装

借助于往被测试程序中插入操作来实现测试目的的方法

考虑的方面

  • 探测哪些信息
  • 在程序的什么部位设置探测点
  • 需要设置多少个探测点

用途

  1. 覆盖分析
  2. 监控和断言
  3. 查找数据流异常

指导方针



基本原则

  • 具有高圈复杂度的程序需要更充分的测试
  • 一般选择V(G)=10
  • 如果单元具有更高的复杂度,可以简化单元或计划更充分的测试
  • 简化单元的最好方法是解决非结构化的问题

覆盖指标

  1. 作为一种强制执行的标准
  2. 作为一种机制,指导要求更严格部分的代码有选择地进行测试

数据流测试

数据流是指关注定义点和使用(或引用)点的一种结构测试方法,它和数据流图没有什么联系.
实际上很多数据流测试支持者和研究人员将这种测试方法看作是一种路径测试.
通过分析变量的定义和使用,以查找如引用未定义变量等程序错误,也可以用来查找对以前未曾使用的变量的再次赋值等数据流异常的情况
早期数据流分析常常集中于现在叫定义/引用异常的缺陷:

  • 变量被定义但是从来没有被使用
  • 所使用的变量没有被定义
  • 变量在使用之前被定义了两次

这些异常可以通过程序的索引表发现,可以通过所谓的静态分析发现

  • 将程序中的变量出现分为定义和引用
    • 👎语句K执行时改变了程序变量V的值,则称K定义了变量V
    • 若语句k执行时引用了变量V的值,则称K引用了变量V

定义/使用测试

假设V是程序P中的变量的集合,程序P控制流程图用G(P)表示,其中结点代表语句或语句片段,边代表结点序列.G(P)有一个单入口节点和一个单出口节点,并且不允许有某个结点到自身的边

  • 变量V的定义结点,记作DEF(v,n)

    结点n\in G(P)是变量v\inV定义的结点,当且仅当变量V的值由对应结点n的语句或语句片段所定义.

  • 变量v的使用结点n记作USE(v,n)

    结点n\in G(P)是变量v\inV的使用结点,当且仅当变量v的值在对应结点n的语句或语句片段中被引用.

  • 谓词使用,记作P-use

    USE(v,n)是一个谓词使用,当且仅当n是谓词语句,否则,USE(v,n)是计算使用,记作C-use.

  • 定义/使用路径,记作du-path

    如果对某个变量v\inV,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,则称为一条定义/使用路径,结点m称为该定义使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.

  • 定义清晰路径(defination-clear path),记作dc-path

    如果一个变量v\inV,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,并且从m到n的结点序列中没有其他结点对对变量v进行过定义,则从m到n的结点序列称为一条定义清晰路径,结点m称为该定义/使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.

定义/使用路径和定义清晰路径描述了变量从被定义到被引用点数据流向.
不是定义清晰的定义/使用路径,很可能是潜在问题的所在.所以应该特别关注定义/使用路径

定义/使用路径覆盖测试

  • 数据流覆盖测试指标

P是被测程序,G(P)是其控制流图,T是G(P)的路径集合,并假设定义/使用路径都是可执行路径

  • 所有定义/使用路径覆盖准则

    集合T满足程序P的所有定义/使用路径覆盖准则,当且仅当对所有的变量v\inV,T包含了从v的每个定义结点到v所有使用结点的定义清晰路径.

  • 所有定义覆盖准则

    集合T满足程序P所有定义覆盖准则,当且仅当对所有的变量v\inV,T包含了从变量v的每个定义结点到v的一个使用结点的定义清晰路径.

  • 所有使用覆盖准则

    集合T满足程序P的所有使用覆盖准则,当且仅当对所有的变量v\inV,T包含了从v的每个定义结点到v的所有使用结点的定义清晰路径

  • 所有谓词使用/部分计算使用覆盖准则

    集合T满足程序P的所有谓词使用/部分计算使用覆盖准则,当且仅当对所有的变量v\inV,T包含了从v的每个定义结点到v的所有谓词使用结点的定义清晰路径,并且如果v的一个定义没有谓词使用结点,则定义清晰路径至少包含一个计算使用

  • 所有计算使用/部分谓词使用覆盖准则

    集合T满足程序P的所有计算使用/部分谓词使用覆盖准则,当且仅当对所有的变量v\inV,T包含了从每个定义结点v的所有计算使用结点的定义清晰路径,并且如果v的一个定义没有使用计算节点,则定义清晰路径至少包含一个谓词使用.

2019-05-07 10:54:58 fengliaoai 阅读数 756

软件测试新手期又叫入门,软件测试就是刚刚接触这个东西,不太熟。无论进入哪个行业,我们都要经历一个新手期。这个时候的我们,对该行业一窍不通。你在软件测试新手期吗?告别培训班!零基础软件测试新手教程免费版送给需要的你们。

自学软件测试工程师要多久?
入门的时候只要会看懂中文、理解能力没问题就可以按照测试用例来执行用例了
1、开始自学的时候找一本书来入门(软件测试原版第三版很不错)-差不多要1个月左右的时间、要能看懂明白里面的知识、这个阶段主要是学习理论知识
2、有基础知识之后找一个软件来自己操作、从开始写测试计划、测试用例、到自己完成测试、并输出测试报告(这个阶段必须自己操作、如果有问题可以去51testing论坛提问)这里如果产品小的话1个月左右、软件功能多的话2个月多都有可能、建议从功能少的软件入手
3、在执行第二个步骤的时候经常多去51testing论坛看看那些问题帖子、绝对增长你的知识量
4、前面3个步完成之后可以开始关注招聘网站那些招聘软件测试的公司、去看看他们公司的做的什么产品、可以吧他们的产品下载回来按照步骤2的方式来自己写用例 执行测试、记录BUG、提交测试报告等内容(如果你去面试公司的时候拿着你的测试报告以及BUG单的话 成功率会高很多)
5、前面几个步骤完成之后差不多要开始找工作了、建议去看看那本<软件测工程师试面试指导>的书籍、这本书里面有很多软件测试的面试题目多看看提高知识量
自学软件测试差不多需要6个月左右的时间

软件测试学习路线
第一阶段 系统测试模块

第1章 测试基础
第2章 系统测试流程
第3章 测试用例设计
第4章 测试管理
第5章 缺陷测试

第二阶段 WEB测试模块

第1章 web系统基础
第2章 理解网络协议
第3章 http协议详解
第4章 web前端分析
第5章 web安全性测试
第6章 web兼容性及可行性测试

第三阶段 UFT与Selenium自动化测试

第1章 自动化测试基础
第2章 UFT自动化测试详解
第3章 UFT高级测试开发
第4章 自动化测试框架设计
第5章 UFT综合实战
第6章 自动化测试-selenium

第四阶段 LR性能测试

第1章 性能测试核心技术
第2章 性能测试脚本开发
第3章 LR场景测试
第4章 LR指标分析
第5章 性能测试高级脚本开发

第五阶段 拓展课程

Java语言基础
LinuxSHELL编程与实践
Linux操作系统基础
Mysql基础
Mysql进阶
Python数据库编程
Python语言编程基础
window phone8数据库操作及数据加密

第六阶段 项目实战

第1章 WEB项目测试备战
第2章 产品需求与设计评审
第3章 测试计划
第4章 测试用例架构搭建
第5章 web测试用例设计方法
第6章 功能测试用例设计方法
第7章 性能测试用例设计
第8章 安全测试用例设计
第9章 兼容性测试用例设计
第10章 界面测试用例设计
第11章 web测试用例的评审方法
第12章 搭建测试环境
第13章 粗测上
第14章 粗测下
第15章 功能测试执行上
第16章 功能测试执行中
第17章 功能测试执行下
第18章 系统测试-产品经理
第19章 系统测试-项目经理
第20章 系统测试-开发团队
第21章 系统测试-测试团队
第22章 界面测试
第23章 兼容性测试
第24章 安全测试上
第25章 安全测试下
第26章 回归测试
第27章 BUG管理
第28章 BUG入库
第29章 测试报告
第30章 WEB测试总结及面试

【软件测试教程百度盘下载地址】
http://www.xuexiluxian.net/ceshi-peixun.html

2017-10-11 19:34:19 ah121210 阅读数 396

软件测试原则:

1.测试显示缺陷的存在

      测试可以显示缺陷的存在,但不能证明系统不存在缺陷。测试可以减少软件中存在为被发现缺陷的可能性,但即使测试没有范县任何缺陷,也不能证明软件或系统是完全正确的。

2.穷尽测试是不可能的

      除了小型项目,进行完全(各种输入和前提条件的组合)的测试是不可能的。通过运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽测试。

3.测试尽早介入

      在软件或系统开发生命周期中,测试活动应该尽可能早的介入,并且应该将关注点放在已经定义的测试目标上。

4.缺陷集群性(80-20原则)

      版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。

5.杀虫剂悖论

      采用同样的测试用例多次重复进行测试,最后将不再能够发现新的缺陷。为了克服这种“杀虫剂悖论”,测试用例需要进行定期评审和修改,同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分,从而发现潜在的更多的缺陷。

6.测试活动依赖于测试背景

      针对不同的测试背景,进行的测试活动也是不同的。比如,对安全关键的软件进行测试,与对一般的电子商务软件的测试是不一样的。

7.没有失效不代表系统是可用的

      系统的质量特性不仅仅是功能要求,还包括很多其他方面的要求,比如稳定性,可用性,兼容性等。假如系统无法使用,或者系统不能完成用户的需求和期望,那么此系统的研发是失败的,同时在系统中发现和修改缺陷也是没有任何意义的。



软件测试中的集中测试过程简介

博文 来自: fanxiaobin577328725

软件测试教程

阅读数 1265

没有更多推荐了,返回首页