2011-07-21 17:02:58 iteye_19555 阅读数 148
  • 解密华为DevOps 在线技术峰会

    在全球软件、服务化的趋势下,软件的开发周期越来越短,软件开发质量越来越难得以控制,挑战加大,迫切需要新的软件研发组织形态、产品交付平台来支撑研发工作的创新。观看在线直播,与华为DevOps讲师共同探究云端的软件研发实践,深度体验一站式云端DevOps平台,从项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等领域感受全生命周期服务的超能力。

    1640 人正在学习 去看看 CSDN讲师
软件测试中常见的功能测试检查点

Functional testing (功能测试),也称为behavioral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。 功能测试也叫黑盒子测试或数据驱动测试,只需考虑各个功能,不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发,按照需求编写出来的测试用例,输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。

功能测试常见检查点如下:

1.页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。

2.相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。

3.检查按钮的功能是否正确:如update、cancel、delete、save等功能是否正确。

4.字符串长度检查:输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度,会不会出错。

5.字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错。

6.标点符号检查:输入内容包括各种标点符号,特别是空格、各种引号、回车键。看系统处理是否正确。

7.中文字符处理:在可以输入中文的系统输入中文,看会否出现乱码或出错。

8.检查带出信息的完整性:在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。

9.信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

10.检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。

11.检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型。

12.检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错。同时,也要注意,会不会报和自己重名的错。

13.重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。

14.检查多次使用back键的情况:在有back的地方,back,回到原来页面,再back,重复多次,看会否出错。

15. search检查:在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确。如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确。

16.输入信息位置:注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

17.上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。

18.必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*

19.回车键检查:在输入结束后直接按回车键,看系统处理如何,会否报错。

20.快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。
2017-05-31 10:13:41 jiuqifengyu 阅读数 763
  • 解密华为DevOps 在线技术峰会

    在全球软件、服务化的趋势下,软件的开发周期越来越短,软件开发质量越来越难得以控制,挑战加大,迫切需要新的软件研发组织形态、产品交付平台来支撑研发工作的创新。观看在线直播,与华为DevOps讲师共同探究云端的软件研发实践,深度体验一站式云端DevOps平台,从项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等领域感受全生命周期服务的超能力。

    1640 人正在学习 去看看 CSDN讲师
版权声明:本文为原创文章,转载请先联系并标明出处

在正式介绍检查点之前,我们先思考一个问题:在性能测试的过程中,如何才能算是脚本正确执行?

我们说,一个性能测试负载模型建立的再好,一个性能测试方案设计的再完美,如果在实际落地的时候,脚本实现或者执行却有问题,那么前面的一切也都是白搭。所以,问题来了,到底怎么样才能算是一个脚本正确的执行呢?

我认为这个正确应该分为两点:一是脚本正确;二是执行正确;

脚本正确很容易理解,就是你的脚本完全实现了你对应的用例,使用用户、操作步骤、输入数据都与你的用例一般无二;

而执行正确,我认为至少要分三点:

1、最基本的一点是脚本执行没有报错;

2、再者,即便测试脚本没有报错并不代表测试脚本是正确的按照预期输出,不仅是HyperPacer,对于任何一种测试工具来说,都是根据HTTP状态码来判断返回成功还是失败的。也就是说只要HTTP的状态码是200它就认为这个请求通过了,而我们系统在设计的时候为了用户体验,一般不会直接报错,而是设计相应的错误页面或者异常提示页面,这样在执行过程中,我们的操作或者数据出现异常了,然后返回有一个异常提示的页面。这时候,对于工具来说也是有响应返回,而且状态码为200,所以测试工具认为是正确的,但是对于我们的测试用例中预期输出来说,实际上这是失败了,所以这样也不算是执行正确;

3、最后一点就是脚本跑并发的时候是按照测试方案设计的模型运行的,即并发用户数每个模拟用户使用的参数化数据处理数据都是按照方案设计运行的。譬如,我们性能测试方案中设计的是要并发的每个用户都使用不同的用户名,录入不同的数据,如果我们运行的时候所有并发用户都是使用一个用户名,录入的数据也都一样,那么就跟我们方案预期的运行模式不一样,这样也不算是执行正确。

满足以上三点,我认为才是一个脚本正确的执行了。

基于以上的理解,我们再来看,第一点很容易验证,执行一下看有没有报错就可以了。第二点和第三点该如何保证和确认呢,这就说到我们这次要介绍的另一种技巧了——检查点。

检查点,顾名思义就是用来进行检查,一般是通过预期的文本内容或者大小等特征来与实际返回进行比对,与比对规则能匹配上,则检查通过,反之则不通过。

HyperPacer中提供5种不同的检查类型,分别为:

  • Response:响应内容检查
  • Duration:响应时间检查
  • Size:响应文件大小检查
  • Variables:响应内容中变量检查
  • Function:自定义功能检查

下面我们来逐个说明。

1、RESPONSE:响应内容检查


响应内容检查一般应用在响应的结果验证,即我们上文中所提到的第二点,响应需要是成功的。

取值范围:设置进行检查点校验的取样器范围

  • 父节点:检查点仅应用于父节点
  • 兄弟节点:检查点应用于所有平行节点
  • 所有节点:检查点应用于所有节点

检查范围:此选项可以设定测试的响应域。

  • TextResponse:来自服务器的响应文本,即主体,不包括任何HTTP头
  • Document(text):从不同类型的文档中提取的文本
  • URLSampled
  • ResponseCode:例如200
  • ResponseMessage:例如OK
  • ResponseHeaders:包括设置的Cookie头(如果有的话)

忽略响应状态:将响应的初始状态设置为成功。

HTTP响应状态在4xx和5xx范围内,通常被认定为失败。"忽略响应状态"设置为true,可以在进行进一步检查之前将响应状态强制设置为成功。请注意,这种设置将会导致清除之前任何失败的检查点,所以请确保这只是设置在第一个检查点上。

匹配规则:设定使用哪种模式测试文本。

  • 包含:文本中包含正则表达式
  • 完全匹配:整个文本能够完全匹配正则表达式
  • 相等:整个文本等于匹配字符串(区分大小写)
  • 包含子字符串:文本中包含匹配字符串(区分大小写)
  • 不包含:文本中不包含正则表达式
  • 不完全匹配:文本不能够完全匹配正则表达式
  • 不相等:文本不等于匹配字符串(区分大小写)
  • 不包含子字符串:文本中不包含匹配字符串(区分大小写)

注意!相等和子字符串模式使用的是纯字符串,不是正则表达式。

匹配项列表:被测试的匹配项列表。

分别测试每个匹配项。如果一个匹配项失败,那么不会继续检查下面的匹配项。添加一个设置多种匹配项的检查点和添加多个只设置一种匹配项的检查点,效果是一样的(假设其他的选项是一样的)。

2、DURATION:响应时间检查


持续时间(ms): 检查的持续时间,如果为0,那么此检查点将被忽略。

3、SIZE:响应文件大小检查


取值范围: 进行取值判断的范围,包括Full、Head、Body、Code、Message。

比较规则:检查时使用的运算规则。包括:相等、不相等、大于、小于、大于等于、小于等于。

比较大小:要检查的字节数。需配合比较规则使用。

4、VARIABLES:响应内容中变量检查


名称: 要检查的变量名称

类型: 选择要检查的变量类型:数值、字符串、对象。

匹配规则: 根据选择的类型,选择执行的匹配规则。

值: 输入要对变量进行检查的值。

5、FUNCTION:自定义功能检查


函数: 在其他检查类型均不满足时,可通过自动义编写的函数进行检查。编写的语法可参考HyperPacer帮助手册中的计算表达式语法手册,如果有疑问,可以QQ用户服务群(237936872)咨询。

 

介绍完了原理,我们以“用户登录业务系统”为例来说明一下检查点在实际的性能测试工作中是怎么使用的。

 

首先,我们需要创建一个检查点,在HyperPacer中,支持对测试场景、事务、具体的请求等设置检查点。此例中,我们要验证用户登录成功,所以将检查点创建在用户登录的取样器下,命名为Check:


我们要验证登录是成功的而非登录异常,即需要检查响应代码为200或者响应消息为OK,则Check检查点选择Response响应内容检查,检查范围选择Response Code,匹配规则为完全等于,设置完成后保存检查点设置:


检查点设置成功后,需要调试运行,校验检查点是否设置正确:


在快照浏览器中选择登录取样器,查看“检查结果”页签,Check检查点没有出现异常,状态为ture,表明该检查点被执行通过。

 

当检查点执行失败时,快照浏览器中该取样器快照标红显示,且检查结果页签,状态为false,并给出错误的详细信息,如下图:


以上这个检查点设置,很好的解决了“脚本执行通过但数据执行失败”的问题。那么,为了保证我们的脚本完全正确,是不是可以在每个请求下面都添加这样一个检查点呢?可以。但是我们强烈建议您不要这么做。因为每个检查点的对比校验都是一次性能损耗,尽管这种损耗非常小,但是量变引起质变,做的太多的话,脚本本身的性能损耗可能导致性能测试结果的严重失真。所以,只要在每个事务中选择最关键的一个请求进行检查就可以了。

参考文章:


LoadRunner技巧之检查点


原文出处
2017-11-30 14:45:05 syfalex 阅读数 488
  • 解密华为DevOps 在线技术峰会

    在全球软件、服务化的趋势下,软件的开发周期越来越短,软件开发质量越来越难得以控制,挑战加大,迫切需要新的软件研发组织形态、产品交付平台来支撑研发工作的创新。观看在线直播,与华为DevOps讲师共同探究云端的软件研发实践,深度体验一站式云端DevOps平台,从项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等领域感受全生命周期服务的超能力。

    1640 人正在学习 去看看 CSDN讲师

软件测试的目标

Glen Myers关于软件测试目的提出以下观点:

- 测试是为了发现错误而执行程序的过程
- 测试是为了证明“程序有错”,而不能证明“程序正确”
- 一个好的测试用例在于能够发现至今未发现的错误
- 一个好的测试是发现了至今未发现的错误的测试

软件测试的原则

有如下几点:

- 应当把“尽早的和不断的测试”作为软件开发者的座右铭
- 程序员应避免检查自己的程序
- 测试从小规模开始,逐渐扩大到大规模
- 设计测试用例时,应包括合理的输入和不合理的输入,以及各种边界条件,特殊情况要制造极端状态和意外状态
- 充分注意测试中的聚集现象:测试过程中80%的错误,可能集中在20%的代码里
- 对测试结果要有确认过程
- 制定严格的测试方案,排除测试的随意性
- 注意回归测试的关联性,往往修改一个错误会导致更多错误
- 妥善保存一切测试过程文档,测试重现往往要靠测试文档

测试用例的定义

测试用例(Testing case):

- 测试用例是为特定的目的而设计的一组测试输入,执行条件和预期的结果。
- 测试用例是执行的最小测试实体。
- 测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序执行的预期结果。

测试用例的特征

- 最有可能抓住错误的。
- 不是重复的,多余的。
- 一组相似测试用例中最有效的。
- 既不是太简单,也不过于复杂

测试用例的设计原则

1. 测试用例的代表性:
    - 能够代表并覆盖各种合理的和不合理的,合法的和非法的,边界的和越界的以及极限的输入数据,操作和环境设置等。
2. 测试结果的可判定性:
    - 测试执行结果的正确性是可判定的,每一个测试用例都应有对应的预期结果。
3. 测试结果的可再现性:
    - 对同样的测试用例,系统的执行结果应是一样的。

软件测试人员

这里写图片描述


软件测试方法的分类

按实施步骤分:

- 单元测试(Unit Testing)
- 集成测试(Integration Testing)
- 确认测试(Validation Testing)
- 系统测试(System Testing)
- 验收测试(Verification Testing)

按使用的测试技术分:

- 静态测试: 走查 / 评审
- 动态测试: 白盒 / 黑盒

按软件组装策略分:

- 非增量测试:整体集成
- 增量测试:自顶向下、自底向上、三明治

1. 单元测试

定义:

- 单元测试是对软件基本组成单元的测试,有时也称为“组件测试”。
- 单元测试一般是由编写该单元代码的开发人员执行,该人员负责设计和运行一系列的测试以确保该单元符合需求。

目的:

    -  目的是验证开发人员所书写的代码是否可以按照其所设想的方式执行而产出符合预期值的结果,确保产生符合需求的可靠程序单元。

环境:

- 驱动模块(driver):模拟被测模块的上一级模块,接收测试数据,把这些数据传送给所测模块,最后再输出实际测试结果。
- 桩模块(stub):模拟被测单元需调用的其他函数接口,模拟实现子函数的一些功能。

2. 集成测试

- 在单元测试的基础上,将所有模块按照总体设计的要求组装称为子系统或者系统进行的测试。
- 集成测试的对象是模块间的接口,其目的是找出在模块接口上和系统体系结构上的问题。

集成测试策略:

- 基于层次的集成:自顶向下和自底向上
- 基于功能的集成:按照功能的优先级逐步将模块加入系统中
- 基于进度的集成:把最早获得的代码进行集成
- 基于使用的集成:通过类的使用关系进行集成

整体集成测试 , 增量式集成测试,三明治集成测试

3. 确认测试

- 检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准。

4. 系统测试

- 系统测试是将已经集成好的软件系统作为一个元素,与计算机硬件,外设,某些支持软件,数据和人员等其他元素结合在一起,在实际运行环境下进行的一系列测试。

系统测试方法:

- 功能测试,协议一致性测试
- 性能测试,压力测试,容量测试,安全测试,恢复性测试
- 备份测试,GUI测试,健壮性测试,兼容性测试,可用性测试
- 可安装性测试,文档测试,在线帮助测试,数据转换测试

功能测试(Functional Testing):

- 功能测试是系统测试中最基本的测试,不理会软件内部的实现逻辑,主要根据软件需求规格说明和测试需求列表,验证产品的功能实现是否符合需求规格。
- 功能测试主要发现以下错误:
    1. 是否有不正确或者遗漏的功能?
    2. 功能实现是否满足用户需求和系统设计的隐藏需求?
    3. 能否正确的接受输入?能否正确的输出结果?
- 常用的测试技术:
    - 黑盒测试方法:等价类划分,边界值测试

压力测试(Press Testing)

- 压力测试是检查系统在资源超负荷情况下的表现,特别是对系统的处理时间有什么影响。
- 压力测试采用边界值和错误猜测方法,且需要工具的支持。

安全性测试(Security Testing):

- 安全性测试检查系统对非法入侵的防范能力。
- 安全测试期间,测试人员假扮非法入侵者,采用各种办法突破防线。

恢复测试(Recovery Testing):

- 恢复测试是检验系统从软件或者硬件失败中恢复中的能力,采用各种人工干预的方式使软件出错,从而检验系统的恢复能力。

GUI测试(Graphic User Interface Testing):

- GUI测试一是检查用户界面实现与设计的符合情况,二是确认用户界面处理的正确性。
- GUI测试提倡界面与功能的设计分离,其重点关注在界面层和界面与功能接口层上。
- GUI自动化测试工具
    • WinRunner,QARun,QARobot,Visual Test
- 常用的测试技术
    • 等价类划分、边界值分析、基于状态图方法、错误猜测法

安装测试(Installation Testing):

- 系统验收之后,需要在目标环境中进行安装,其目的是保证应用程序能够被成功的安装。

5. 验收测试

- 验收测试是以用户为主的测试,一般使用用户环境中的实际数据进行测试。
- 在测试过程中,除了考虑软件的功能和性能外,还应对软件的兼容性,可维护性,错误的恢复功能等进行确认。

α 测试与β 测试

- α测试与β测试是产品在正式发布前经常进行的两种测试;
    • α测试是由用户在开发环境下进行的测试;
    • β测试是由软件的多个用户在实际使用环境下进行的测试。

6. 回归测试

– 回归测试是验证对系统的变更没有影响以前的功能,并且保证当前功能的变更是正确的。
– 回归测试可以发生在软件测试的任何阶段,包括单元测试、集成测试和系统测试,其令人烦恼的原因在于频繁的重复性劳动。
– 回归测试应考虑的因素:
    • 范围:有选择地执行以前的测试用例;
    • 自动化:测试程序的自动执行和自动配置、测试用例的管理和自动输入、测试结果的自动采集和比较、测试结论的自动输出。
2017-05-02 21:47:22 Software_55White 阅读数 865
  • 解密华为DevOps 在线技术峰会

    在全球软件、服务化的趋势下,软件的开发周期越来越短,软件开发质量越来越难得以控制,挑战加大,迫切需要新的软件研发组织形态、产品交付平台来支撑研发工作的创新。观看在线直播,与华为DevOps讲师共同探究云端的软件研发实践,深度体验一站式云端DevOps平台,从项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等领域感受全生命周期服务的超能力。

    1640 人正在学习 去看看 CSDN讲师
软件测试的对象包括:源程序、目标程序、数据及相关文档


而如何入门软件测试并针对找工作呢?

需要以下知识:

测试的理论,还有测试驱动开发是怎么用的,为什么要用测试驱动开发、linux和数据库、计算机网络(可刷牛客网来提升)。


单元测试->集成测试->确认测试->系统测试->验收测试

(1)单元测试:

 单元测试又称为模块测试,是针对软件设计的最小单位程序模块进行正确性检查的测试工作,单元测试需要从程序内部结构出发设计测试用例,多个模块可以平行地独立进行单元测试。Junit 测试是程序员测试,即所谓 白盒测试 ,因为程序员知道被测试的软件如何( How )完成功能和完成什么样( What )的功能。 Junit 是一套框架,继承TestCase 类,就可以用 Junit 进行自动测试了。

 

工件是加工过程中的生产对象。
(2)集成测试
又称为组装测试或联合测试,在单元测试的基础上,需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

(3)确认测试
确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般由第三方测试机构进行。
(4)系统测试
 软件作为计算机系统的一部分,与硬件、网络、外设、支撑软件、数据以及人员结合在一起,在实际或模拟环境下,对计算机系统进行测试,
目的在于与系统需求比较,发现问题
(5)验收测试
以用户为主的测试,软件开发人员和质量保证人员参加,由用户设计测试用例。不是对系统进行全覆盖测试,而是对核心业务流程进行测试。

 

Alpha测试在Beta测试之前,由一个用户在开发环境下进行的测试,也叫做验证测试。

alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部用户在模拟实际操作环境进行的受控测试,不能由程序员或测试员完成。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

Beta测试软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理。

区别:A测试是一个用户,可以是内部人员也可以是用户,开发人员在场,测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。

           B测试是多个用户在一个或多个实际使用环境下进行,完全是用户,开发人员不在场。着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。

 

针对手机应用软件的系统测试,我们通常从如下几个角度开展:功能模块测试,交叉事件测试,压力测试,容量测试,兼容性测试,易用性/用户体验测试等.

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

 

设计测试用例时,应注意测试用例的代表性、测试结果的可判定性和可重现性。   

1、测试用例的代表性:能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。

2、测试结果的可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。

3、测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的。

 

什么是静态测试?

:通过运行程序测试软件称为动态测试.通过评审文档、阅读代码等方式测试软件称为静态测试,在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.ddddddd                    

静态测试方法是指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析,找出欠缺和可疑之处,例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错,并为测试用例选取提供指导。

 

什么是白盒测试?

:白盒测试(White-box Testing,又称逻辑驱动测试,结构测试),它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
对开发语言的支持:白盒测试工具是对源代码进行的测试,测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。

 

白盒测试主要应用在单元测试阶段,主要是对代码级的测试,针对程序内部逻辑结构,测试手段有:语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖

1.语句覆盖:可执行语句至少被执行一次;
2.判断覆盖:每个判断的取真分支和取假分支至少经历一次;
3.条件覆盖:每个条件的取值至少满足一次;

4.路径测试:执行所有可能的执行路径;
5.条件组合覆盖:每个条件的所有可能都至少出现一次,并且判定结果至少出现一次 ;

6.判断/条件覆盖:判断和条件都满足;
与条件覆盖的区别:他不是简单要求每个条件出现“真”和“假”两种结果,而是要求这些结果所有可能至少出现一次;
7.基本路径测试:路径测试执行了每个路径,每个判定的结果肯定经历过一次

 

黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、决策表和综合策略。

 

设计系统测试计划需要参考的项目文挡有:软件测试计划、软件需求规范、迭代计划

 

系统测试有负载测试、易用性测试、强度测试、安全测试。

(1)负载测试:数据在超负荷环境中运行,看程序是否能承担。目的是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。

(2)强度测试:在一定的负荷条件下,在较长时间跨度内的系统连续运行给系统性能所造成的影响。
(3)容量测试:容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。面向数据的,并且它的目的是显示系统可以处理目标内确定的数据容量。

 

单元测试能发现约80%的软件缺陷。

 

逻辑测试覆盖中,测试覆盖最强的是条件组合覆盖。

 

测试方法可以分成个人复查、抽查和会审、黑盒测试、白盒测试。

 

软件测试的原则之一是测试应该尽早进行,最好在需求阶段就开始介入。

 

    测试驱动开发(Test-DrivenDevelopment)是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD得原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践,但不只适用于XP(Extreme Programming),同样可以适用于敏感词开发方法和过程。TDD得基本思路就是通过测试来推动整个开发得进行,但测试驱动开发并不只是单纯的测试工作,而是把需求分析,设计,质量控制量化的过程。TDD的重要目的不仅仅是测试软件,测试工作保证代码质量仅仅是其中一部分,而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等),主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。

优点:在任意一个开发节点都可以拿出一个可以使用,含少量bug并具一定功能的产品。

缺点:增加代码量。测试代码是系统代码的两倍或更多。

 

什么是驱动模块?

:驱动模块在大多数场合称为"主程序",它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时,被测单元本身是不能独立运行的,需要为其传送数据,为此写驱动
驱动模块主要完成以下事情:
1
、接受测试输入;
2
、对输入进行判断;
3
、将输入传给被测单元,驱动被测单元执行;
4
、接受被测单元执行结果,并对结果进行判断;
5
、将判断结果作为用例执行结果输出测试报告。

 

什么是桩模块?

:比如对函数A做单元测试时,被测的函数单元下还包括了一个函数B,为了更好的错误,定位错误,就要为函数B写桩,来模拟函数B的功能,保证其正确。

 

需求文档测试:测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

设计文档测试: 测试设计是否符合全部需求以及设计是否合理。

 

测试工具:

loadrunner 包括脚本编辑工具、测试执行工具、结果分析工具

 

性能测试:主要检验软件是否达到需求规格说明书中规定的各类性能指标,并满足一些性能相关的约束和限制条件。

目的是通过测试,确认软件是否满足产品的性能需求,同时发现系统中存在的性能瓶颈,并对系统进行优化。


压力测试:模拟巨大的工作负荷,以查看系统在峰值使用情况下是否可以正常运行,以此来获得系统性能提供的最大服务级别的一种测试。


负载测试:通过逐步增加系统工作量,测试系统能力的变化,并最终确定在满足功能指标的情况下,系统所能承受的最大工作量的测试。压力测试实质上就是一种特定类型的负载测试。


自动化测试和手工测试的适用场景:

自动化测试适用场景:

1.产品需求变更较少。

2.项目开发周期较长。

3.测试用例执行频繁。比如大量的回归测试工作

4.手工测试无法胜任。比如高并发操作,持续收集设备资源,长时间稳定性测试,多用户操作等手工操作或测试无法胜任的工作。

5.人物财力资源充足。

手工测试适用场景:

1.产品需求变更较多。

2.项目开发周期较短,需要迅速交付。

3.测试用例执行不是很频繁,需要人为观察,需要灵活测试。


自动化测试和手工测试的优缺点:

自动化测试的优点:

1、对回归测试更方便:周期较长的回归测试工作量大,测试比较频繁,适合自动化测试。由于测试的脚本和用例都是设计好的,测试期望的结果也可以预料,将回归测试自动化可以极大的提高效率缩短回归时间。
2、模拟真实情况:可以执行手工测试无法执行的测试,比如同时并发上千用户测试系统的负载量,测试人员无法达到测试目的,而使用自动化测试工具可以模拟多用户的并发过程。
3、有效的利用人力物力资源:频繁地机器化的动作可以用自动化测试执行,减少错误的发生,更好的利用人力资源。
4、测试的重复利用:由于自动测试通常使用的是自动化脚本技术,这样就可以只需要做较少的甚至是不修改就可以实现在不同的测试过程中使用相同的用例。
5、减少人为的错误:自动化测试是机器完成,不存在执行过程中人为的疏忽和错误。

自动化测试的缺点:

1、自动化测试是工具执行,没有思维,无法进行主观判断,对界面色彩、布局和系统的奔溃现象无法发现,这些错误通过人眼很容易发现。
2、自动化测试工具本身是一个产品,在不同的系统平台或硬件平台可能会受影响,在运行时可能影响被测程序的测试结果。
3、对于需求更改频繁的软件,测试脚本的维护和设计比较空难。
4、自动化测试是机器执行,手工测试比自动测试发现的缺陷更多
5、自动化测试要编写测试脚本,设计场景,这些对测试人员的要求比较高,测试的设计直接影响测试的结果。

综上所述,可以归结自动化完成不了的,手工测试都能弥补,两者有效的结合是测试质量保证的关键。

2008-12-20 16:42:00 TestCompetenceImprov 阅读数 1942
  • 解密华为DevOps 在线技术峰会

    在全球软件、服务化的趋势下,软件的开发周期越来越短,软件开发质量越来越难得以控制,挑战加大,迫切需要新的软件研发组织形态、产品交付平台来支撑研发工作的创新。观看在线直播,与华为DevOps讲师共同探究云端的软件研发实践,深度体验一站式云端DevOps平台,从项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等领域感受全生命周期服务的超能力。

    1640 人正在学习 去看看 CSDN讲师
 

软件测试定义

马均飞 郑文强

简单地说,对一段代码进行检查并查找错误,这就是测试活动。在工业制造和生产中,测试被当作一个常规的检验产品质量的生产活动,其含义为“以检验产品是否满足需求为目标”。

那么,对于软件测试行业,什么是软件测试的定义呢?根据测试目的的不同,会有不同类型的软件测试定义。下面是几个典型的软件测试定义:

1.1 软件测试正向思维

软件测试的正向思维的出发点是使自己确信产品是能够工作的。主要代表人物是Bill Hetzel博士。他于1972在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。1973年他首先给出软件测试的定义:“测试就是建立一种信心,确信程序能够按期望的设想进行”。1983年他又将软件测试的定义修改为:“评价一个程序和系统的特性或能力,并确定它是否达到期望的结果。软件测试就是以此为目的的任何行为”。在这个定义中,“设想”和“期望的结果”就是我们现在常说的用户需求或者功能设计。同时他把软件的质量定义为符合要求,其中的核心思想为:测试方法是试图验证软件是工作的,即软件的功能是按照预先的设计执行的,以正向思维,针对系统的所有功能,逐个验证其正确性。

测试目的为确信产品能够工作,可以简单抽象地描述为这样的过程:在设计规定的环境下运行软件的功能,将其结果与用户需求或设计结果相比较,如果相符则测试通过,如果不相符则视为存在缺陷。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行,并通过,并确认这些功能,确认这些功能的适合性和正确性。这类测试方法以需求和设计为本,因此有利于界定测试工作的范畴,更利于部署测试的侧重点,加强针对性。这一点对于大型软件的测试,尤其是在有限的时间和人力资源情况下显得格外重要。

但是,软件测试是使自己确信产品能够工作的正向思维方法,在测试过程中会导致这样的想法:为了让我们看到产品在工作,可以将测试工作往后推一点。测试活动始终后于开发活动,测试通常被认为是软件生命周期中编码之后的一项活动。因此,测试活动通常指的是测试对象的执行和运行,和贯穿于整个软件开发生命周期的测试理念不合,我们可以认为是一种狭义的软件测试定义。

1.2 软件测试反向思维

前面阐述了软件测试的正向思维,即确信软件产品是能够工作的,这一观点受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers,他认为测试不应该着眼于验证软件是工作的,相反应该首先认定软件是有错误的,然后用逆向思维去发现尽可能多的缺陷。他同时认为,将验证软件是可以工作的作为测试目的,非常不利于测试人员发现软件中的缺陷。1979年,Glenford J. Myers给出了他对软件测试的定义:“测试是为发现错误而执行一个程序或者系统的过程。”同时,Myers还提出了三个重要观点:

·          测试是为了证明程序有错,而不是证明程序无错误。

·          一个好的测试用例在于它能发现以前未发现的错误。

·          一个成功的测试是发现了以前未发现的错误的测试。

这个软件测试的定义,或者说软件测试的反向思维,简单地说就是验证软件是不工作的,或者说是有错误的。Myers认为,一个成功的测试必须是发现缺陷的测试,不然就没有价值。这就如同一个病人(假定此人确有病),到医院做一项医疗检查,结果各项指标都正常,那说明该项医疗检查对于诊断该病人的病情是没有价值的,是失败的。

Myers提出的“测试的目的是证伪”这一概念,推翻了过去“为表明软件正确而进行测试”的理解,为软件测试的发展提出了新的方向,软件测试的理论方法在之后也得到了长足的发展。这个软件测试的定义,强调了测试人员不断思考开发人员理解的误区、不良的习惯等等,它的目标就是发现系统中各种各样的问题,而与系统需求和设计之间没有必然的关联,这种方法往往能够更多的发现系统中存在的缺陷。

然而,对Glenford Myers先生“测试的目的是证伪”这一概念的理解也不能太过于片面。在很多软件工程学、软件测试方面的书籍中都提到一个概念:“测试的目的是寻找错误,并且是尽最大可能找出最多的错误”。这很容易让人们认为测试人员就是“挑毛病”的,而由此带来诸多问题:

·          若测试人员以发现缺陷为唯一目标,而很少去关注系统对需求的实现,测试活动往往会存在一定的随意性和盲目性;

·          假如软件企业或者组织接受了这样的方法,以缺陷数量做为考核测试人员业绩的唯一指标,也不科学。

和软件测试正向思维的定义一样,软件测试反向思维指的也是软件的执行和运行,而不是全程的软件测试的概念,因此,也是一种狭义上的软件测试定义。

1.3 IEEE定义的测试

随着软件和IT行业进入了大发展,软件趋向大型化、高复杂度,软件的质量越来越重要。软件测试的目的从发现软件产品可以工作和尽量发现产品中的缺陷,慢慢开始转向测试是软件质量保证的重要手段之一,也是进行软件质量评估的一个基础。

这个时候,人们还将质量的概念融入其中,软件测试定义发生了改变,测试不单纯是一个发现错误的过程,而且将测试作为软件质量保证(SQA)的主要职能,包含软件质量评价的内容,Bill Hetzel在《软件测试完全指南》(Complete Guide of Software Testing)一书中指出:“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。

1990年的IEEE/ANSI标准将软件测试进行了这样的定义:

·          在规定条件下运行系统或构件的过程。观察和记录结果,并对系统或构件的某些方面给出评价。

·          分析软件项目的过程。检测现有状况和所需状况之间的不同,并评估软件项目的特性。

1.4 广义软件测试定义

在前面两种软件测试定义中,测试活动都只包含了运行软件系统进行的测试,也就是执行软件的过程。但软件工作产品指的不仅仅是程序代码,还包括和软件相关的文档和数据组成。因此,软件测试对象不仅仅是程序代码,还应该包括软件设计开发各个阶段的工作产品,比如需求文档、设计文档、用户手册等等。从这个意义上讲,传统的软件测试定义(主要关注软件运行过程中的对软件进行的检查和发现不一致的行为)是一个狭义的概念。实际上这只是测试的一部分,而不是测试的所有活动。

随着人们对软件工程化的重视以及软件规模的日益扩大,软件分析、设计的作用越来越突出。有资料表明,60%以上的软件错误不是程序错误,而是分析和设计错误。若把软件分析、设计上的问题遗留到后期,可能造成设计、编程的部分甚至全部返工,从而增加软件开发成本、延长开发周期等后果。同时,需求和设计阶段所产生的缺陷具有放大效应,严重影响软件质量。因此,为了更早地发现并解决问题,降低修改错误和缺陷的代价,有必要将测试延伸到需求分析和设计阶段中去,使软件测试贯穿于整个软件生命周期,提倡软件全生命周期测试的理念,即软件测试是对软件形成过程中的所有工作产品(包括程序以及相关文档)进行的测试,而不仅仅是对程序的运行进行测试。

测试的活动包含了测试执行之前和之后的所有的阶段活动,包括测试计划和控制、测试分析和设计、测试实现和执行、测试出口评估和报告、测试结束活动等。整个测试活动中除了进行动态测试外,还将进行静态测试,比如静态分析、文档或代码的评审等。

广义的测试,我们可以引入两个概念来覆盖测试的范畴:验证(Verification)和确认(Validation)。

·          验证(Verification:通过检查和提供客观证据来证实指定的需求是否满足。也就是说,输入与输出之间的比较。也就是说,是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求(如正确性、完整性、一致性、准确性等)相一致。

·          确认(Validation:通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现。在确认时,应考虑使用和应用的条件范围要远远大于输入时确定的范围。一般是由客户或代表客户的人执行。也就是说,是确认所开发的软件是否满足用户真正需求的活动。相当于,保持对软件需求定义、设计的怀疑,一切从客户出发,理解客户的需求,发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现。

对于每个测试级别,都要检查开发的输出是否满足具体的需求,或和这些特定级别相关的需求。这种根据原始需求检查开发结果的过程称为确认。在确认过程中,测试人员来判断一个产品(或者是产品的一部分)是否完成它的任务,据此判断这个产品是否满足它期望的使用要求。

和确认测试不同,验证只针对开发过程的单个阶段。验证需要确保特定开发阶段的输出已经按照它的规格说明(相应开发级别的输入文档)正确而完整的实现了。这意味着验证是用来检查是否正确的实现了规格说明,产品是否满足了它的规格,而不是检查最终的产品是否满足期望的使用。

1.5 测试和调试的区别

必须明确,调试和测试是两个不同的概念。测试可以发现由于软件存在的缺陷引起的失效。而调试是一种开发活动,用来识别引起缺陷的原因,修改代码以及验证是否正确的修改了软件的缺陷(开发人员在解决了问题之后,需要验证软件缺陷是否真的已经解决,这也是开发人员的职责之一)。随后由测试人员进行的再(确认)测试是为了确认修改的代码已经正确修改了缺陷。每个活动的职责是不同的,通常来说,测试人员进行测试活动,开发人员进行调试活动(当然,开发人员也会进行一些测试活动,比如,单元测试通常由开发人员来进行);除此之外,调试和测试的不同还表现在以下几个方面:

·          测试和调试在目标、方法和思路上有所不同。比如,测试的目的之一是发现软件中的缺陷,而调试的主要目的通常是为了定位和修改软件中的缺陷。

·          测试是从已知的条件开始,使用预先定义的过程,并且有预知的结果;调试是从未知的条件开始,结束的过程可能不可预计。

·          测试可以计划,可以预先制定测试用例和过程,工作进度可以度量;描述调试的过程或持续时间相对比较困难。

·          测试的对象包括软件开发过程中的文档、数据以及代码,而调试的对象一般来说只是代码。

综上,不难得出,测试不等同于调试。测试可以发现由于软件存在的缺陷引起的失效;而调试是一种开发活动,用来识别引起缺陷的原因和采取解决方案来修改代码。二者都是程序开发周期中必不可少的活动。

1.6 软件测试定义总结

上面从不同的角度定义了3种不同的软件测试,它们的测试目的是不一样的。当然,软件测试的描述并不仅仅只有这么几种,比如软件测试也可以是对软件产品质量的评估、对软件开发和软件测试过程的评估等等。不同的软件测试定义,其目的有不同的侧重,它们也不是孤立存在于软件开发生命周期的,而是相辅相成的。在不同的测试阶段或者不同的测试级别,可能需要考虑不同的测试目的。例如,在开发测试阶段(单元测试、集成测试、系统测试),测试的主要目的是尽可能地发现缺陷和失效,从而识别和修正尽可能多的缺陷(更多的是运用证明软件中存在缺陷这个测试目的,也包含了质量保证的测试目的);在验收测试阶段,测试的主要目的是对软件的质量进行评估(不是为了修正缺陷),从而为利益相关人提供这样的信息:在给定时间内发布的系统版本所存在的风险(可能更多的是为了证明软件系统是可以正常工作的,也包含了软件质量保证的目的);在维护测试阶段,测试通常是为了验证在开发过程中的变更是否引入了新的缺陷;在运行测试阶段,测试的主要目的是为了评估系统的特征,比如可靠性或可用性等。

整个测试过程的目标可以概括为:以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正各种错误和缺陷提高软件质量,避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。同时利用测试过程中得到的测试结果和测试信息,作为后续项目开发和测试过程改进的重要输入,避免在将来的项目开发和测试中重复同样的错误;采用更加高效的测试管理手段,提高软件测试的效率和软件产品的质量。

上面给出了三种典型的软件测试定义,它们之间并不是完全独立和对立的。在实际的测试过程中,需要根据不同的组织质量方针、项目特点、测试阶段和测试技术等方面的具体情况,来选择合适的软件测试定义,或者是它们之间的组合。

 

 

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