精华内容
下载资源
问答
  • 软件测试学习笔记

    2013-01-17 22:21:42
    软件 测试 学习笔记 包含性能测试的一些概念
  • 软件测试学习笔记:测试点总结软件测试1、可编辑文本框的测试:主要是“字符长度、字符类型、文本格式”的测试字符长度的验证:最大值、最小值、适当值、超长值。字符类型的验证:中(简、繁)、英(大小写)、数字(整数...
  • 软件测试学习笔记白盒 软件测试学习笔记黑盒 软件测试学习笔记性能
  • 软件测试学习笔记(三)控制&数据流测试 视频链接:软件测试_中国大学MOOC 2.3 结构化覆盖 2.4 控制流测试 2.5 数据流测试 1、什么是顶点覆盖? 对每个测试需求,即可达顶点,都可从测试用例集T里找到测试用例t,...
  • 软件测试学习笔记(一)软件测试基础 课程链接 软件测试_中国大学MOOC(慕课) 1.什么是Bug,谈谈你对它的理解 Bug在英文上是小虫子、窃听器的意思,第一次bug的出现,正是一个小虫子落在巨型计算机的导致晶体管...

    软件测试学习笔记(一)软件测试基础

    课程链接 软件测试_中国大学MOOC(慕课)
    在这里插入图片描述

    1.什么是Bug,谈谈你对它的理解

    Bug在英文上是小虫子、窃听器的意思,第一次bug的出现,正是一个小虫子落在巨型计算机的导致晶体管短路,从而使得计算机出现问题。
    我理解的bug是在编译程序时以及后续运行时出现的错误,有很大的不可预测性,进行改错时还可能出现,改掉一个bug同时又生成更多的bug的情况。

    2.计算机中的第一个Bug是谁发现的?

    Grace Hopper女士发现了第一个bug

    3. 关于Bug的三个概念是什么,谈谈它们各自的特点。

    Failer 感染病毒但没有发病;error 发病了但没有死亡; false引发症状 功能不符合需求, 不正确或缺失的异常处理,不符合用户使用习惯的(要根据实际情况来), 超出用户期望的需求(画蛇添足,也不一定)
    bug的错误类型:代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题

    4.什么是PIE模型?观测到一个Failer需要哪些必要条件?

    观测到Failer的必要条件Execution/Reachability(执行):执行时必须通过错误,Infection(感染):项目的状态必须是错误的,Propagation(传播):错误的中间状态必须传播到最后输出,使得观测到的输出结果和预期结果不一致,即失效。

    5.PIE模型的讨论带给我们的启发是什么?

    通过PIE模型能更深刻的理解bug的存在,测试未必能执行到Fault,执行到Fault也未必能引发error,能达到期望结果并不意味着软件都没有问题、没有缺陷了。
    认识fault,error,failer之间的关系

    6.测试用例由哪三部分构成?

    测试预演,通过现有数据,预演预期的结果,进行一个输入数据,查看程序运行的结果,若没有正常出现期望输出,则在过程中一定会有bug
    测试环境,测试情况、测试环境是很重要的前提条件,
    测试用例≠测试数据,测试用例是三个部分构成的

    7.谈谈你对测试和调试的认识

    测试是为了发现bug,调试是为了修复bug
    测试是测试人员进行的,只能找出存在bug,但不知道具体位置在哪里,需要提交bug信息给程序员,来让他们参照bug信息进行调试,来修复bug的错误。

    8.谈谈如何理解Verification(证实)与Validation(确认)

    Validation:将需求文档确定的写在合同文案中,将Verification确认,明确规格文档。
    Verification:是对照合同来检测,也就是软测试,以Validation来作为参考来进行验证测试。

    9.静态测试与动态测试最大的不同是什么?

    静态测试:去观测源代码,进行分析,浏览核心业务,对代码进行理解分析
    动态测试:执行程序,在运行过程中发现问题

    10.黑盒测试与白盒测试的区分点是什么?

    黑盒测试:不需要源代码,不需要知道软件的内部信息,多是用户来进行测试,只关注实际使用时产生的结果能不能达到预期(宏观测试)

    白盒测试:专业测试人士,通过源代码,来进行分析,知道软件内部的结构、逻辑、运行情况,通过专业知识,找出关键点,进行重点测试。(微观测试)

    11.灰盒测试是否等于白盒测试+黑盒测试?

    灰盒测试≠白盒+黑盒
    拿不到源代码,只了解部分的结构信息,要结合黑盒测试特点来进行测试用例的设计,既有白盒的相对微观特点,又有黑盒测试的宏观特性。

    12.测试分为哪四个层次?

    层次一:单元测试
    层次二:模块测试
    层次三:集成测试
    层次四:系统测试

    13.什么是V模型?

    V左侧:需求分析概要设计详细设计~编码实现(从高到低)
    V右侧:单元测试模块测试集成测试~系统测试(从低到高)

    14.测试过程都包括哪些步骤?

    1,第一步要做的是需求分析,根据测评中心收到项目的需求规格说明书和原型图来做需求分析。
    2,编写测试用例,
    3,测试开展
    4,编写测试报告
    5,反馈漏洞,再进行补充设计
    6,循环进行之前几步进行改进升级

    展开全文
  • 本来没有打算写相关博客的,但是在做课后习题时想到做测试必然少不了思考,从不同的角度分析,于是就打算用博客来记录下来,虽然我文章里面可能大多数内容来源百度,后面的软件测试学习笔记与思考也一样,但是也可以...

    这学期开始学习软件测试,课本是软件测试(慕课版)郑炜,刘文兴,杨喜兵,王文鹏,吴潇雪主编的。
    本来没有打算写相关博客的,但是在做课后习题时想到做测试必然少不了思考,从不同的角度分析,于是就打算用博客来记录下来,虽然我文章里面可能大多数内容来源百度,后面的软件测试学习笔记与思考也一样,但是也可以当做笔记,也可以用文字来督促自己好好学习是不?据说做测试比开发轻松呢!但还是比较倾向于开发。。。


    软件缺陷定义

    • 软件未达到产品说明书中标明的功能。
    • 软件出现了产品说明书找你指明不会出现的功能
    • 软件功能超出了产品说明书中指明的范围
    • 软件未达到产品说明书中指明应达到的目标
    • 软件测试人员认为软件难以理解和使用、运行速度慢,或最终用户认为不好。

    软件缺陷严重程度

    • 严重缺陷 不能正常执行
    • 较大缺陷
      在这里插入图片描述
    • 较小缺陷 在这里插入图片描述
    • 轻微缺陷在这里插入图片描述
    • 其他缺陷 其他错误

    软件缺陷优先级

    在这里插入图片描述

    第一章讲的都是软件测试基础,全是一大堆理论概论,看着有点头疼,大致过了一遍,没记住什么概念呢。就来做课后习题了。。

    习题1 什么是软件测试?

    (个人理解,可能不全面,也不对)
    软件测试发现一个应用从开始到结束时的错误,测试是一个过程。
     (Glenford J.Myers 提出对软件测试的定义)
    测试是发现错误而执行的一个程序或系统的过程
    (书上小结)
    测试以发现故障为目的,是为了发现故障而执行程序过程。
    

    习题2 软件测试设计哪几个关键问题?

    谁来测试
    测试什么
    什么时候测试
    怎样进行测试
    测试的停止标准是什么
    

    习题3 为什么说软件需求是软件故障的最大来源?

    (个人理解)
    软件需求是描述了系统有哪些功能,功能操作,性能如何等问题,是开发阶段的重要文档,也是后期软件开发的重要依据。如果软件需求一开始就错了,在后面处理过程则会把错误放大,这样使得修复起来成本就是提升。

    习题4 简述软件测试的复杂性和经济性?

    参考此博客

    习题5 题目太长放图片了?

    在这里插入图片描述
    由于无法输入逗号,无法进行输入,我就当做一个界面缺陷,因为不符合需求,原来是小数点变成了逗号。

    习题6 软件测试应遵循哪些重要的原则或方针?

    参考:软件测试的七大原则

    习题7 假定无法完全测试某一程序,那么在决定是应该停止测试是应该考虑哪些问题?

    在工作中,常用的停止测试标准有五类:

    • 测试超过了预定时间,停止测试
    • 执行了所有测试用例但没有发现故障,停止测试
    • 使用特定的测试用例方法作为判断测试停止的基础
    • 正面指出测试完成要求,如发现并修改70个软件故障
    • 根据单位是见查出故障数量决定是否停止测试

    习题8 假如星期一测试软件的某一功能时,每小时可能发现一个新的软件故障,那么星期二会以什么频率发现软件故障?

    这题有点让人难受,我第一感觉就是与第一天(星期一)的一样,既然前一天发现的频率以每小时都有新的故障,说明软件的缺陷很高,所以第二天也可能有同样的频率。但是这样想感觉又不对,要是第一天测试的是一个功能模块,而第二天测试不同的功能模块,可能功能由于开发人员经验技术问题而导致,所以频率可能也不一样,可大可小。
    如果你有好的看法欢迎留言指导,谢谢。


    最后打一波小广告
    我自己公众号

    在这里插入图片描述

    展开全文
  • 但是无可否认的是,良好的理论素养无论是解决工作中软件测试笔记(一)理论篇 有句话是这么说的:能动手就别哔哔,尤其是在工作节奏堪比跑马的今天,大家都推崇实干精神,能解决问题就好,去他的理论。但是无可否认...
  • 软件测试学习笔记 - 1 - 软件缺陷,测试员目标 1. 软件测试定义: 1983 年,IEEE 对软件测试进行了精确的定义:软件测试是使用人工或自动手段来运行或测定某个系统的过程,检验它是否满足规定的需求或是弄清...

    软件测试学习笔记 - 1 - 软件缺陷,测试员目标



    1. 软件测试定义:


    1983 年,IEEE 对软件测试进行了精确的定义:软件测试是使用人工或自动手段来运行或测定某个系统的过程,检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

    根据调查,软件产品在成本上的分配比例一般来说是: “需求分析” 占6%, “设计” 占5%, “编程” 占7%, “测试” 占15%, “运行维护” 占67%,而测试成本所占的比例还在逐渐上升。


    2. 软件缺陷的定义:



    产品说明书是软件开发小组的一个协定,它对开发的产品进行定义,给出产品的细节,如何做,做什么,不能做什么。这种协定从简单的口头到正式的书面文档有多种形式。软件缺陷并非是软件未按预期目标运行这样简单,只有至少满足下列 5 个规则之一,才称为软件缺陷

    A:软件未实现产品说明书要求的功能

    B:软件出现了产品说明书中指明不应该出现的错误

    C:软件实现了产品说明书未提到的功能

    D:软件未实现产品说明书虽未明确提及但应该实现的目标

    E:软件难以理解、不易使用、运行缓慢,或者从测试员的角度看,最终用户会认为不好


    关于第三点说明如下:软件实现了产品说明书未提到的功能,这些预料不到的操作,虽然有了更好,但会增加测试工作,甚至可能带来更多的缺陷。


    3. 软件缺陷的来源及修复成本:



    导致软件缺陷最大的原因是产品说明书:产品说明书常常没写好——不要忘了,说不出来就做不出来。其他原因是产品说明书虽然有,但是不完整,不停更改,或者产品说明书内容没有和开发小组其他成员沟通。

    软件缺陷的第二大来源是设计:这是程序员规划软件的过程,好比建筑师为建筑物绘制蓝图。这里产生缺陷的原因与产品说明书是一样的:随意,易变,沟通不足。

    编码是第三大引入缺陷的原因:代码错误可归咎于软件的复杂性,文档不足,进度压力和普通的低级错误。一定要注意,许多看上去是编程错误的软件缺陷,实际上是由于产品说明书和设计方案造成的。

    剩下的缺陷课归为一类:某些缺陷产生的原因是把误解(即把本来正确的)当成缺陷,还有可能缺陷多出反复出现,实际上是由一个原因引起的,一些缺陷可以归咎于测试错误。不过此类缺陷只占极小比例。


    软件通常要靠有计划、有条理的开发过程来实现。从开始到计划、编程、测试,到公开使用的过程中,都有可能发现软件缺陷。

    从  说明书 --> 设计 --> 编码 --> 测试 --> 发布的过程中,随着时间推移,软件缺陷的修复费用成指数地增长(十倍地增长)。例如在早期编写产品说明书时发现并修复缺陷,费用只要1美元甚至更少,同样的缺陷如果知道软件编写完成,测试时才发现,修复费用可能要10 - 100美元。


    4. 软件测试员的目标:


    软件测试员的目标是:尽可能早地找出软件缺陷,并确保其得以修复

    “修复” 缺陷并非指一定要改正软件。可以是指在用户手册中增加一段注释或为用户提供特殊培训等。





    展开全文
  • 软件测试学习笔记(三)软件测试过程

    万次阅读 多人点赞 2016-11-30 10:05:03
    软件测试中的集中测试过程简介

    1.软件测试过程概述

    软件测试过程与软件工程的开发过程是相对应的,我们可以采用V型图来表示软件开发与软件测试的对应关系,也可以采用螺旋形图来表示这种关系。

      单元测试的目的是保证每个模块单独运行正确,多采用白盒技术,检查模块控制结构的某些特殊路径,期望覆盖尽可能多的出错点。
      经单元测试后的模块,组装为软件包,对软件包进行集成测试,主要测试软件结构问题,因测试建立在模块间的接口上,所以多为黑盒测试,适当辅以白盒测试技术,以便能对主要控制路径进行测试。
      系统测试主要是检验软件是否满足功能、行为和性能方面的要求,这一步完全采用黑盒测试技术。
      验收测试是检验软件产品的最后一道工序,与前面各种测试过程的不同之处主要在于它突出了客户的作用,同时软件开发人员也要参与。

    2.单元测试

    2.1 单元测试的定义

    单元测试是对软件设计的最小单元—模块进行正确性检验的测试工作,主要测试模块在语法、格式和逻辑上的错误。
    单元选择的依据:
    (1)单元必须是可测的;
    (2)单元的行为或输出是可观测的;
    (3)有明确的可定义的边界或接口。
    确定单元的最基本原则是“高内聚,低耦合”,常见的示例如下(五个):
    (1)在使用过程化编程语言开发设计的软件中,单元可以用一个函数或过程表示,也可以用紧密相关的一组函数或过程表示。
    (2)在使用面向对象编程开发工具设计的软件中,单元可以用一个类或者类的一个实例表示,也可以用方法实现的一个功能表示。
    (3)在可视化图形环境下或图形用户界面环境下,单元可以是一个窗口,或者是这个窗口中相关元素的集合。
    (4)在基于组件的开发环境中,单元可以是一个预先定义的可重用的组件。
    (5)对于Web编程的网页,单元可以是页面上的一个子功能。

    2.2 单元测试的重要性与原则

    2.2.1 单元测试的重要性

    从如下几个方面就可以看出单元测试的重要性:
    (1) 时间方面
    (2) 测试效果方面
    (3) 测试成本方面
    (4) 产品质量方面
    2.2.2 单元测试原则.(7点)
    (1) 单元测试越早进行越好;
    (2) 单元测试应该依据《软件详细设计规格说明》进行;
    (3) 对于修改过的代码应该重做单元测试,以保证对已发现错误的修改没有引入新的错误;
    (4) 当测试用例的测试结果与设计规格说明上的预期结果不一致时,测试人员应如实记录实际的测试结果;
    (5) 单元测试应注意选择好被测软件单元的大小;
    (6) 一个完整的单元测试说明应该包含正面测试和负面的测试;
    (7) 注意使用单元测试工具.

    2.3单元测试的主要任务

    单元测试是针对每个程序模块进行测试,单元测试的主要任务是解决以下5个方面的测试问题。

    2.3.1 模块接口测试

    对模块接口的测试是检查进出模块单元的数据流是否正确,所以对模块接口的测试必须在任何其他测试之前进行。
    针对模块接口测试应进行的检查,主要涉及以下几方面的内容。(11方面)
    ① 模块接受输入的实际参数个数与模块的形式参数个数是否一致。
    ② 输入的实际参数与模块的形式参数的类型是否匹配。
    ③ 输入的实际参数与模块的形式参数所使用单位是否一致。
    ④ 调用其他模块时,所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
    ⑤ 调用其他模块时,所传送的实际参数与被调用模块的形式参数的类型是否匹配。
    ⑥ 调用其他模块时,所传送的实际参数与被调用模块的形式参数的单位是否一致。
    ⑦ 调用内部函数时,参数的个数、属性和次序是否正确。
    ⑧ 在模块有多个入口的情况下,是否有引用与当前入口无关的参数。
    ⑨ 是否会修改了只读型参数。
    ⑩ 出现全局变量时,这些变量是否在所有引用它们的模块中都有相同的定义。
    有没有把某些约束当做参数来传送。

    2.3.2 模块局部数据结构测试

    模块的局部数据结构是经常发生错误的错误根源,在单元测试工作过程中,必须测试模块内部的数据能否保持完整性、正确性,包括内部数据的内容形式及相互关系不发生错误。
    一般注意一下几类错误:
    1)不正确的或不一致的类型说明;
    2)错误的初始化或默认值;
    3)错误的变量名;
    4)不相容的数据类型;
    5)下溢、上溢或者地址错误。

    2.3.3 模块中所有独立执行路径测试

    在单元测试中,应对模块中的每一条独立路径进行测试,此时设计的测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。常见的错误如下:
    (1)误解的或不正确使用算术优先级;
    (2)混合类型的运算;
    (3)错误的初始化;
    (4)算法错误;
    (5)运算精确度不够精确;
    (6)表达式的符号表示不正确等。
    针对判定和条件覆盖,测试用例还要能够发现如下错误:
    (1)不同数据类型的比较;
    (2)不正确的逻辑操作或优先级;
    (3)应相等的地方由于精确度错误而不能相等;
    (4)不正确的判定或不正确的变量;
    (5)不正常的或不存在的循环终止;
    (6)当遇到分支循环时不能退出;
    (7)不适当的修改循环变量。

    2.3.4 各种错误处理测试

    良好的设计应该预先估计到软件投入运行后可能发生的错误,并给出相应的处理措施,测试错误处理的要点是检验如果模块在工作中发生了错误,其中的出错处理实施是否有效。应主要检查下面的情况:
    (1)对运行发生的错误描述得难以理解;
    (2)报告的错误与实际遇到的错误不一致;
    (3)出错后,在错误处理前就引起了系统干预;
    (4)例外条件的处理不正确;
    (5)提供的错误信息不足,无法找到出错的原因。

    2.3.5 模块边界条件测试

    单元测试的最后一步,必须采用边界值分析法来设计测试用例,主要检查以下方面:
    (1)处理n维数组的第n个元素时是否出错;
    (2)在n次循环的第0次、1次、n次是否有错误;
    (3)运算或判断中取最大和最小值是否有错误;
    (4)数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。

    2.4 单元测试环境的建立

    一般情况下,在完成了程序编写、复查和语法正确性验证后,就应进行单元测试。测试用例设计应与复审工作相结合,根据设计信息选取数据,将增大发现上述各类错误的可能性。在进行单元测试时,需设置若干辅助测试模块。
    辅助模块有两种:
    一种是驱动模块(Driver),用以模拟被测试模块的上级模块。 驱动模块在单元测试中,接受测试数据,把相关的数据传送给被测模块,启动被测模块,并打印出相应的结果。
    另一种是被调用模拟子模块(sub),用以模拟被测模块工作过程中所调用的模块。被调用模拟子模块由被测模块调用,它们一般只进行很少的数据处理,以便于检验被测模块与其下级模块的接口。
    一般的单元测试环境:

    2.5 单元测试主要技术和数据

    2.5.1 静态测试

    保证算法的逻辑正确性、清晰性、规范性、一致性、算法高效性。能够发现30%-70%的逻辑设计和编码错误,但是还有大量的隐性错误无法通过视觉检查发现,必须通过跟踪、细心分析才能捕捉到。

    2.5.2 动态执行测试

    可以分别采用白盒测试和黑盒测试。
    通过白盒测试证明每种内部操作是否符合设计规格的要求,所有内部成分是否已经经过检查,进行白盒测试时,采用的白盒测试技术主要是逻辑覆盖法和基本路径法。
    黑盒测试主要包括功能测试和非功能测试,功能测试可以证明每个实现了的功能是否符合要求。非功能测试是在必要时,对单元的性能(系统响应时间,内存使用的相容性等)进行测试。

    2.5.3 状态转换测试

    当单元可能处于不同状态转换时,应根据单元可能进入的状态、这些状态之间的转换、引起转换可能导致的状态等进行测试。

    2.5.4 单元测试中使用的数据

    单元测试中使用的数据,通常不使用真实数据。
    当被测试单元的功能不涉及操纵或使用大量数据时,测试中可以使用有代表性的一小部分手工制作的测试数据。在创建测试数据时,应确保数据充分地测试单元的边界条件。
    当被测试单元要操纵大量数据,并且有很多单元都有这种需求时,可以考虑使用真实数据的一个较小的有代表性的样本。测试时还要考虑往样本数据中引入一些手工制作的数据,以便测试单元的某个具体特性,例如对错误条件的响应等。
    当测试一个单元要从远程数据源接收数据时(例如,从一个客户端/服务器系统中接收数据),有必要在单元测试中使用测试辅助程序,来模拟对这些数据的访问。但在考虑这种选择时,必须首先对开发的测试辅助程序进行测试,以保证模拟的真实性。

    2.6 单元测试工具简介

    自动化单元测试工具的工作原理是借助于驱动模块与桩模块工作的,运行被测软件单元以检查输入的测试用例是否按软件详细设计规格说明的规定执行相关操作。
    目前,单元测试测试工具类型较多,按照测试的范围和功能,可以分为下列几种(八种)。
    1. 静态分析工具;
    2. 代码规范审核工具;
    3. 内存和资源检查工具;
    4. 测试数据生成工具;
    5. 测试框架工具;
    6. 测试结果比较工具;
    7. 测试度量工具;
    8. 测试文档生成和管理工具
    常用的单元测试自动化工具介绍如下:
    1. 基于XUnit测试框架的测试工具
    2. 常用的C语言单元测试工具
    3. Visual Unit单元测试工具
    4. 分析覆盖率的工具
    5. 静态分析工具

    2.7 单元测试人员

    单元测试一般由开发设计人员本身完成,并在开发组在组长的监督下进行,由编写该单元的开发设计者设计所需的测试用例和测试数据,来测试该单元并修改缺陷。开发组组长负责保证使用合适的测试技术,在合理的质量控制和监督下执行充分的测试。

    3.集成测试

    3.1 集成测试的定义

    将经过单元测试的模块按设计要求连接起来,组成所规定的软件系统的过程称为“集成”。

    3.2 集成测试的主要任务

    集成测试是组装软件的系统测试技术之一,按设计要求把通过单元测试的各个模块组装在一起之后,进行集成测试的主要任务是要求软件系统符合实际软件结构,发现与接口有关的各种错误。集成测试的主要任务是解决以下5个方面的测试问题。
    ① 将各模块连接起来,检查模块相互调用时,数据经过接口是否丢失。
    ② 将各个子功能组合起来,检查能否达到预期要求的各项功能。
    ③ 一个模块的功能是否会对另一个模块的功能产生不利的影响。
    ④ 全局数据结构是否有问题,会不会被异常修改。
    ⑤ 单个模块的误差积累起来,是否被放大,从而达到不可接受的程度。

    3.3 集成测试遵循的原则

    集成测试很不好把握,应针对总体设计尽早开始筹划。为了做好集成测试,需要遵循以下原则。(8条)
    ① 所有公共接口都要被测试到。
    ② 关键模块必须进行充分的测试。
    ③ 集成测试应当按一定的层次进行。
    ④ 集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。
    ⑤ 集成测试应当尽早开始,并以总体设计为基础。
    ⑥ 在模块与接口的划分上,测试人员应当和开发人员进行充分的沟通。
    ⑦ 当接口发生修改时,涉及的相关接口必须进行再测试。
    ⑧ 测试执行结果应当如实记录。

    3.4 集成测试实施方案

    集成测试的实施方案有很多种,如:非增式集成测试和增量式集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。
    其中,常用的是非增式集成测试和增量式集成测试两种模式。

    3.4.1 非增式测试方法

    概括来说,非增式测试方法是采用一步到位的方法来进行测试,即对所有模块进行个别的单元测试后,按程序结构图将各模块连接起来,把连接后的程序当做一个整体进行测试。下图给出的是采用这种非增式的集成测试方法的一个经典例子。

    3.4.1 增式测试方法

    <1>自顶向下增式测试

    自顶向下增式测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块(主程序),然后按照软件控制层次结构向下进行集成。 可以有深度优先和广度优先两种集成策略。

    集成测试的整个过程由下列3个步骤完成。
    ① 主控模块作为测试驱动器,把对主控模块进行单元测试时引入的被调用模拟子模块用实际模块替代。
    ② 依照所选用的模块集成策略(深度优先和广度优先),下层的被调用模拟子模块一次一个地被替换为真正的模块。
    ③ 在每个模块被集成时,都必须立即进行测试一遍。回到第2步重复进行,直到整个系统结构被集成完成。

    <2>自底向上增式测试

    自底向上增式测试是从最底层的模块开始,按结构图自下而上逐步进行集成和测试。下图表示了采用自底向上增式测试实现同一实例的过程。

    3.4.3 其他集成测试实施方案(3种)

    <1> 三明治集成测试

    将自顶向下测试与自底向上测试两种模式结合起来,才用并行的自顶向下、自底向上集成方式。
    它采取持续集成策略,软件开发中的各个模块不是同时完成,根据进度将完成的模块尽可能早地进行集成。
    并且,在自底向上集成时,先期完成的模块将是后期模块的被调用程序,而自顶向下集成时,先期完成的模块将是后期模块的驱动程序,从而使后期模块的单元测试和集成测试出现了部分交叉,节省了测试代码的编写,也提高了工作效率。

    <2>核心系统先行集成测试

    思想是先对核心软件部件进行集成测试,在测试通过的基础上再按各外围部件的重要程度逐个集成到核心系统中。

    <3>高频集成测试

    是指同步于软件开发过程,每隔一段时间对开发团队的现有代码进行一次集成测试。该集成方法频繁的将新代码加入到一个已经稳定的基线中,以免集成故障难以发现,同时控制可能出现的基线偏差。

    3.4.4 几种集成测试方案的比较

     

    非增量式集成测试增量式集成测试
    如果在模块的接口处存在错误,只会在最后的集成测试时一下子暴露出来将程序一段一段地扩展,测试的范围一步一步的增大,把可能出现的差错分散暴露出来
    非增量式集成测试可能发现很多错误,为每个错误定位和纠正非常困难,并且在改正一个错误的同时又可能引入新的错误,新旧错误混杂,更难断定出错的原因和位置错误易于定位和纠正,便于找出问题并修改,接口的测试亦可做到完全彻底
    自顶向下测试自底向上测试
    自然地做到逐步求精,一开始便能让测试者看到系统的框架;直到最后一个米快被加入进去之后才能看到整个程序的框架
    需要提供被调用模拟子模块,被调用模拟子模块可能不能反映真实情况,因此测试有可能不充分。
    在输入输出模块接入系统以前,在被调用模拟子模块中表示测试数据有一定困难。
    由于被调用模拟子模块不能模拟数据,如果模块间的数据流不能构成有向的非环状图,一些模块的测试数据便难以生成。
    由于驱动模块模拟了所有调用参数,即使数据流并未构成有向的非环状图,生成测试数据也没有困难

     

    三明治集成测试核心系统先行集成测试高频集成测试
    采用自底向上、自顶向下集成相结合的方式,并采取持续集成的策略,有助于尽早发现缺陷,提高工作效率。能保证一些重要功能和服务的实现,对于快速软件开发很有效果。但要求能明确区分核心软件部件和外围软件部件。集成次数频繁,必须借助于自动化工具来实现。

    3.5 集成测试技术和测试数据

    集成测试主要测试软件的结构问题,因为测试建立在模块的接口上,所以多为黑盒测试,适当辅以白盒测试。
    软件集成测试具体内容包括:
    (1) 功能性测试
    (2) 可靠性测试
    (3) 易用性测试
    (4) 性能测试
    (5) 维护性测试
    集成测试一般覆盖的区域包括:
    (1) 从其他关联模块调用一个模块;
    (2) 在关联模块间正确传输数据;
    (3) 关联模块之间的相互影响,即检查引入一个模块会不会对其他模块的功能后性能产生不利的影响;
    (4) 模块间接口的可靠性。
    执行集成测试应遵循下面的方法。
    ① 确认组成一个完整系统的模块之间的关系。
    ② 评审模块之间的交互和通信需求,确认出模块间的接口。
    ③ 使用上述信息产生一套测试用例。
    ④ 采用增量式测试,依次将模块加入到系统,并测试新合并后的系统,这个过程以一个逻辑/功能顺序重复进行,直至所有模块被功能集成进来形成完整的系统为止。
    此外,在测试过程中尤其要注意关键模块,所谓关键模块一般都具有下述一个或多个特征。
    ① 对应几条需求。
    ② 具有高层控制功能。
    ③ 复杂,易出错。
    ④ 有特殊的性能要求。
    因为集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用,因此集成测试对数据的要求无论从难度和内容来说一般不是很高。
    集成测试一般也不使用真实数据,测试人员可以使用手工制作一部分代表性的测试数据。在创建测试数据时,应保证数据充分测试软件系统的边界条件。
    在单元测试时,根据需要生成了一些测试数据,在集成测试时可适当地重用这些数据,这样可节省时间和人力。

    3.6 集成测试人员

    由于集成测试不是在真实环境下进行,而是在开发环境,或是一个独立的测试环境下进行的,所以集成测试所需人员一般从开发组中选出,在开发组长的监督下进行,开发组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的集成测试。
    在集成测试过程中,测试过程由一个独立测试观察员来监控测试工作。
    集成测试过程中应考虑邀请一个用户代表非正式地观看集成测试 。

    4.系统测试

    4.1 系统测试的定义

    系统测试是指经通过集成测试的软件系统,作为计算机系统的一个重要组成部分, 与计算机硬件、外设、某些支撑软件的系统等其他系统元素组合在一起所进行的测试。
    目的在于通过与系统的需求定义作比较,发现软件与系统定义不符合或矛盾的地方,以验证软件系统的正确性和性能等是否满足需求分析所指定的要求。
    系统测试的主要任务:

    1)较大工作量集中在软件系统的某些模块与计算机系统中有关设备打交道时的默契配合方面。
    2)测试人员要根据原始项目需求对软件产品进行确认,验证软件功能与用户要求的一致性。
    3)此外,还必须对文件资料是否完整正确和软件的易移植性、兼容性、出错自动恢复功能、易维护性进行确认。

    4.2 系统测试前的准备工作

    1)收集软件规格说明书,作为系统测试的依据;
    2)收集各种软件说明书,作为系统测试的参考;
    3)仔细阅读软件测试计划书,以作为系统测试的根据。如果已有编好的系统测试用例,一并收集。
    从上述文档中找出:对系统各种功能的描述;系统要求的数据处理及传输的速率;对系统性能的要求;对备份及修复的要求;对兼容性的描述;对配置的描述;对安全方面的描述等。

    4.3 系统测试技术和测试数据

    4.3.1 系统测试的主要测试技术

    系统测试不需要考虑组件模块的实现细节,而主要是根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。
    完全采用黑盒测试技术。
    系统测试一般要完成以下几种测试。
    (1)功能测试
    (2)性能测试
    (3)系统可靠性、稳定性测试
    (4)系统兼容性测试
    (5)恢复测试
    (6)安全测试
    (7)强度测试
    (8)面向用户支持方面的测试
    用户支持测试 用户界面测试
    (9)其他限制条件的测试,如可使用性,可维护性,可移植性、故障处理能力等的测试。

    4.3.2 系统测试的测试数据

    系统测试所用的数据必须尽可能地像真实数据一样精确和有代表性,也必须和真实数据的大小和复杂性相当。满足上述测试数据需求的一个方法是使用真实数据。
    在不使用真实数据的情况下应该考虑使用真实数据的一个拷贝。拷贝数据的质量、精度和数据量必须尽可能地代表真实的数据。当使用真实数据或使用真实数据的拷贝时,仍然有必要引入一些手工数据。在创建手工数据时,测试人员必须采用正规的设计技术,使得提供的数据真正有代表性,确保软件系统能充分地测试。

    4.4 系统测试人员

    系统测试由独立的测试小组在测试组长的监督下进行,测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的系统测试。
    在系统测试过程中,测试过程由一个独立测试观察员来监控测试工作。
    系统测试过程也应考虑邀请一个用户代表非正式地观看测试,同时得到用户反馈意见并在正式验收测试之前尽量满足用户的要求。

    5.验收测试

    5.1 验收测试的定义

    验收测试是软件开发结束后,用户对软件产品投入实际应用前,进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求,以及用户能否接受的问题。
    验收测试主要是验证软件功能的正确性和需求的符合性。要对软件进行全面的质量检测,还要判断软件是否合格,因此验收测试是一项严格的正式测试活动,是软件工程项目最关键的环节,也是决定软件开发是否成功的关键。

    5.2 验收测试的主要内容

    验收测试应完成的主要测试工作包括(6个):
    (1)配置复审 配置齐全 分类有序 软件维护细节
    (2)合法性检查 开发工具 控件 组件 函数库
    (3)软件文档检查 (3种)
    a 必须提供检查的文档:项目实施计划,详细技术方案,软件需求规格说明书,概要设计说明书,详细设计说明书,软件测试计划,软件测试报告,用户手册,源程序,项目开发总结,软件质量保证计划;
    b 其它可能需要检查的文档:软件配置计划,项目进展报表,阶段评审报表;
    c 文档质量的度量准则:
    完备性:开发方必须按照计算机软件产品开发文件编制指南的规定编制相应的文档,保证齐全。
    正确性:文档描述是否准确,有无歧义,文字表达是否存在错误等。
    简明性:文档的语言表达应该清晰,准确,简练,适合各种文档的特定读者。
    可追踪性:指软件的设计描述是否按照需求定义进行展开的,应用程序是否与设计文档的描述一致,用户文档是否客观描述应用程序的实际操作,另外,还包括在不同的文档的相关内容之间相互检索的难易程度以及同一文档中某一内容在文档范围中检索的难易程度。
    自说明性:指在软件开发各个阶段中,不同文档能够独立表达该软件在其相应阶段的阶段成果能力。
    规范性:指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。
    (4)软件代码测试
    a 源代码一般性检查:仅对系统关键模块的源代码进行抽查,检查模块代码编写的规范性、批注的准确性、是否存在潜在性错误以及代码的可维护性等,包括命名规范检查、注释检查、接口检查、数据类型和限制性检查。
    b 软件一致性检查:编译检查,安装/卸载检查,运行模块检查。
    (5)软件功能和性能测试
    在开发方做完功能演示后,可以进行下列测试:界面测试,可用性测试,功能测试,稳定性测试,性能测试,强壮性测试,逻辑性测试,破坏性测试,安全性测试,性能降级执行方式测试,检查系统的余量要求。
    (6)测试结果交付内容
    测试结束后,由测试组填写软件测试报告,包括:软件测试计划,软件测试日志,软件文档检查报告,软件代码测试报告,软件系统测试报告,测试总结报告及测试人员签字表。

    5.3 验收测试技术和测试数据

    验收测试主要是用户代表通过执行其在平常使用系统时的典型任务来测试软件系统,根据业务需求分析,检验软件是否满足功能、行为、性能和系统协调性等方面的要求。
    完全采用黑盒测试技术。
    只要有可能,在验收测试中就应该使用真实数据。当真实数据中包含机密性或安全性信息,并且这些数据在局部或整个验收测试中可见时,就必须采取以下措施来保证。
    ① 用户代表被允许使用这些数据;
    ② 测试组长被允许使用这些数据,或者合理地组织测试使测试组长不必看到这些数据也可进行测试。
    ③ 测试观察员被允许使用这些数据,或者能够在看不到这些数据的情况下,确认并记录测试用例的成功或失败。
    在不使用真实数据的情况下,应该考虑使用真实数据的一个拷贝。拷贝数据的质量、精度和数据量必须尽可能地代表真实的数据。 当使用真实数据或使用真实数据的拷贝时,仍然有必要引入一些手工数据,例如,测试边界条件或错误条件时,可创建一些手工数据。在创建手工数据时,测试人员必须采用正规的设计技术,使得提供的数据真正有代表性,确保软件系统能充分地测试。

    5.4 α、β测试

    一个软件产品可能拥有众多用户,不可能由每个用户验收,此时多采用α、β测试,以发现那些似乎只有最终用户才能发现的问题。
    α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试,即软件开发公司组织内部人员,模拟各类用户行为对即将面市的软件产品(称为α版本)进行测试,试图发现并修改错误。
    经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并要求用户报告异常情况,提出批评意见。然后软件开发公司再对β版本进行改错和完善。
    所以,一些软件开发公司把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试,而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。

    5.5 验收测试人员

    验收测试一般在测试小组的协助下,由用户代表执行。测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分测试。测试人员在验收测试工作中将协助用户代表执行测试,并和测试观察员一起向用户解释测试用例的结果。

    6. 回归测试

    每当软件增加了新的功能,或者软件中的缺陷被修正,这些变更都有可能影响软件原有的功能和结构。回归测试是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。
    回归测试是指软件系统被修改或扩充后重新进行的测试。
    在理想的测试环境中,程序每改变一次,测试人员都重新执行回归测试,一方面来验证新增加或修改功能的正确性,另一方面测试人员还要从以前的测试中选取大量的测试以确定是否在实现新功能的过程中引入了缺陷。
    因此,严格地说,回归测试不是一个测试阶段,只是一种可以用于单元测试、集成测试、系统测试和验收测试各个测试过程的测试技术。
    回归测试和V模型之间的关系:

    6.1 回归测试技术和测试数据

    回归测试一般采用黑盒测试技术来测试软件的高级需求,而无须考虑软件的实现细节,也可能采用一些非功能测试来检查系统的增强或扩展是否影响了系统的性能特性,以及与其他系统间的互操作性和兼容性问题。
    错误猜测在回归测试中是很重要的。错误猜测主要来自于经验,测试者是使用了一系列技术来确定测试所要达到的范围和程度,这些技术主要有:
    ① 有关软件设计方法和实现技术;
    ② 有关前期测试阶段结果的知识;
    ③ 测试类似或相关系统的经验,了解在以前的这些系统中曾在哪些地方出现缺陷;
    ④ 典型的产生错误的知识,如被零除错误;
    ⑤ 通用的测试经验规则。
    设计和引入回归测试数据的重要原则是,应保证数据中可能影响测试的因素与未经修改扩充的原软件上进行测试时的那些因素尽可能一致。否则要想确定观测到的测试结果是由于数据变化引起的还是很困难的。
    例如,如果在回归测试中使用真实数据,理想的方法是首先使用以前软件测试中归档的测试数据来进行回归测试,以便把观测到的与数据无关的软件缺陷分离出来,如果此次测试令人满意的话,可以使用新的真实数据,再重新执行回归测试,以便进一步确认软件的正确性。

    6.2 回归测试的范围

    在回归测试范围的选择上,一个最简单的方法是每次回归执行所有在前期测试阶段建立的测试,来确认问题修改的正确性,以及没有造成对其他功能的不利影响。
    常用的用例选择方法可以分为以下3种。
    (1)局限在修改范围内的测试;
    (2)在受影响功能范围内回归;
    (3)根据一定的覆盖率指标选择回归测试。

    6.3 回归测试人员

    由于回归测试一般与系统测试和验收测试相关,所以要由测试组长负责,确保选择使用合适的技术和在合理的质量控制中执行充分的回归测试。
    测试人员在回归测试工作中将设计并实现测试新的扩展或增强部分所需的新测试用例,并使用正规的设计技术创建或修改已有的测试数据。
    在回归测试过程中,测试过程由一个测试观察员来监控测试工作。在回归测试完成时测试组组长负责整理并归档大量的回归测试结果,包括测试结果记录、回归测试日志和简短的回归测试总结报告。

    7. 系统排错

    系统测试的目的是为了发现尽可能多的错误,系统排错的任务就是根据测试时所发现的错误,找出原因和具体的位置,并进行改正。排错工作主要由程序开发人员进行,也就是说,谁开发的程序由谁来排错。

    7.1 排错过程

    排错的过程开始于一个测试用例的执行,若测试结果与期望结果有出入,排错过程首先要找出错误原因,然后对错误进行修正。
    排错过程有两种可能:
    (1)能确定错误原因并进行了纠正,为了保证错误已排除,需要重新执行暴露该错误的原测试用例以及某些回归测试;
    (2)未找出错误原因,那么只能对错误原因进行假设,根据假设设计新的测试用例证实这种推测,若推测失败,需进行新的推测,直至找到错误并纠正。

    7.2 排错方法和策略

    下面简要介绍常用的3种排错方法。
    ① 原始类排错方法是最常用也是最低效的方法,主要思想是“通过计算机找错”。例如,输出存储器、寄存器的内容或在程序中安排若干输出语句等,凭借大量的现场信息,从中找到出错的线索,耗费大量的时间和精力;
    ② 回溯法是从错误征兆处开始,人工的沿控制流程往回追踪,直至发现出错根源。但当程序变大时,回溯路线增加,人工回溯不太方便;
    ③ 归纳和演绎法采用“分治”的概念。首先基于与错误出现有关的所有数据,假想一个错误原因,用这些数据证明或反驳它;或者一次列出所有可能的原因,通过测试一一排除。只要某次测试结果说明某种假设已呈现端倪,则立即精化数据,进一步进行深入的测试。
    排错时经常采用的技术:
    (1)断点设置:设置断点对源程序实行断点跟踪,对于断点的设置除了根据经验与错误信息外,还应重点考虑几种类型的语句—函数调用语句,判定转移/循环语句,SQL语句,复杂算法段;
    (2)可疑变量查看:通过比较变量的当前值与预期值,可以比较轻松的定位程序问题根源。
    (3)SQL语句执行检查;
    (4)注意群集现象:注意残存的错误数目与该程序中已发现的错误数目成正比。

    赞赏

    展开全文
  • 我的软件测试学习笔记

    千次阅读 2018-07-08 21:59:20
    满足用户期望或正式规定文档(合同、标准、规范)所具有的条件和权能,包含用户需求和软件需求。 什么是权能? 什么是用户需求? 什么是软件需求? 需求也是需要测试的,并不一定是完全正确的。 BUG 凡是效果...
  • 软件测试学习笔记(一)软件测试概述

    千次阅读 多人点赞 2016-11-28 18:41:35
    软件是由人来完成的,所有由人做的工作都不会是完美无缺的;软件开发是个很复杂的过程,期间很容易产生错误;无论是软件从业人员、专家和学者做了多大的努力,软件错误仍然存在;...软件测试的过程亦是程序运行的过程
  • 软件测试与软件开发的关系 软件测试在软件开发中的作用 项目规划阶段 负责监控整个测试 需求分析阶段 确定测试需求分析,即确定在项目中需要测试什么。同时制定测试计划。 概要设计与详细设计阶段 制定集成测试计划...
  • 简单介绍然间测试过程中的基本测试技术
  • 软件测试的充分性: “充分性”是用来度量一个给定的测试集T是否能验证软件P满足其需求R。充分性度量是相对于具体的测试充分性准则C的。 当一个测试集R满足准则C时,即认为T相对于C是充分的。否侧,如果T不能完全...
  • 软件测试学习笔记(需求分析)

    千次阅读 2018-05-26 20:12:20
    测试一个输入框,一般需要从以下几个方面进行考虑(设计一个文本框的测试用例) 例子:图书类别的添加。图书类别不能为空 首先考虑【对用户输入数据的合法性进行判断】 (1)首先,什么都不要输入,直接点击...
  • 敏捷开发:包含各个工程师并发进行... (比如淘宝的开发,分为商品的浏览,添加购物车购买商品,支付,个人中心等等模块,都可以分别对一个模块同时进行开发,测试使得一个模块能够正常使用) 传统和敏捷开发比较 ...
  • 软件集成测试主要依据软件结构设计(概要设计)文档,测试主要内容有功能性、可靠性、易用性、效率、维护性和可移植性中相关的部分,根据软件需求和设计的要求而选定。 软件集成测试具体内容包括: 1.功能性测试 ...
  • 测试计划一般包括: 1.每个测试阶段的目的; 2.每个测试阶段完成的标志; 3.... 4.每个阶段的负责人员、所需的资源以及测试用例; 5.测试所使用的工具。...纠错时对软件所作的修改; 3.回归测试的情况; 4
  • 软件测试基础学习笔记

    千次阅读 2020-01-02 10:13:38
    软件测试 1.软件测试定义: 通过手工或者工具对被测对象进行测试操作,从而验证实际结果与预期结果之间是否存在差异。 2.测试原则 1、测试证明软件存在缺陷:无论执行什么样的测试操作都不能证明当前软件是有缺陷的 ...
  • 探索式测试(exploratorytesting)是一种自由的软件测试风格,强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动,以持续优化测试工作。  软件测试风格ratherthan具体的软件测试技术  探索式...
  • 软件测试学习笔记(自整理) A crash is when your competitor’s program dies. When your program dies, it is an “idiosyncrasy”.(持续更新) 第一章 软件测试的背景 1.1 软件错误用例 迪士尼的...
  • 单元测试学习笔记

    2021-03-23 16:14:20
    单元测试学习笔记软件测试什么是单元测试单元在程序里可以简单的理解为一个模块,一个方法。单元测试也就是在完成每个模块后都进行的测试。从确保每个模块没有问题,从而提高整体的程序质量。做单元测试的好处对于...
  • Google软件测试之道--学习笔记--转载,网上关于《Google软件的测试之道》一书的学习笔记摘要,帮助读者理解此书的内容和Web软件测试理论。
  • 软件测试笔记

    2019-04-18 10:16:22
    零基础学习软件测试

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 68,060
精华内容 27,224
关键字:

软件测试学习笔记