精华内容
下载资源
问答
  • 软件测试方法

    万次阅读 多人点赞 2019-04-16 14:49:22
    ...软件测试方法 编辑讨论 软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样化,针对性更强;选择合适的软件测试方法可以让我们事半功倍。 用户界面...

    [https://baike.baidu.com/item/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95%E6%96%B9%E6%B3%95/1850037?fr=aladdin]

     

    软件测试方法

     编辑 讨论

    软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样化,针对性更强;选择合适的软件测试方法可以让我们事半功倍。

    用户界面测试,英文是User interface testing。又称UI测试。用户界面,英文是User interface。是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    中文名

    软件测试方法

    目    的

    测试软件性能

    所属行业

    计算机

    作    用

    选择合适的软件

    目录

    1. 测试分类
    2. ▪ UI测试
    3. ▪ 冒烟测试
    4. ▪ 随机测试
    5. 本地化测试
    6. ▪ 基础化
    7. ▪ 国际化
    8. ▪ 安装测试
    9. 白盒测试
    10. 黑盒测试
    11. 自动化
    12. ▪ 回归测试
    13. ▪ 验收测试
    1. 静态测试
    2. 动态测试
    3. 单元测试
    4. 集成测试
    5. 10 系统测试
    6. 11 端到端
    7. 12 卸载测试
    8. 13 接受测试
    9. 14 性能测试
    10. ▪ 健全测试
    11. ▪ 衰竭测试
    12. ▪ 负载测试
    1. ▪ 强迫测试
    2. ▪ 压力测试
    3. ▪ 恢复测试
    4. 15 安全测试
    5. 16 兼容性
    6. 17 可用性
    7. 18 比较测试
    8. 19 可接受性
    9. 20 边界条件
    10. 21 强力测试
    11. 22 装配安装
    12. 23 隐藏数据
    1. 24 等价划分
    2. 25 判定表
    3. 26 深度测试
    4. 27 基于设计
    5. 28 文档测试
    6. 29 域测试
    7. 30 接口测试
    8. 31 逆向测试
    9. 32 非功能性
    10. 33 极限测试

    测试分类

    编辑

    β测试,英文是Beta testing。又称Beta测试,用户验收测试UAT)。

    β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    当开发和测试要完成所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成,不能由程序员或测试员完成。

    α测试_Alpha测试

    α测试,英文是Alpha testing。又称Alpha测试.

    Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由该系统的程序员或测试员完成。

    在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成,不能由程序员或测试员完成。

    可移植性

    可移植性测试,英文是Portability testing。又称兼容性测试。

    可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。

    UI测试

    用户界面测试是指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单,对话框及对话框上所有按钮,文字,出错提示,帮助信息 (Menu 和Help content)等方面的测试。比如,测试Microsoft Excel中插入符号功能所用的对话框的大小,所有按钮是否对齐,字符串字体大小,出错信息内容和字体大小,工具栏位置/图标等等。

    冒烟测试

    冒烟测试,英文是Smoke testing。

    冒烟测试的名称可以理解为该种测试耗时短,仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后,先通电检查,如果存在设计缺陷,电路板可能会短路,板子冒烟了。

    冒烟测试的对象是新编译的每一个需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

    随机测试

    随机测试,英文是Ad hoc testing。

    随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外,对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug,进行再次测试,可以结合回归测试(Regressive testing)一起进行。

    本地化测试

    编辑

    本地化测试,英文是Localization testing。

    本地化就是将软件版本语言进行更改,比如将英文的windows改成中文的windows就是本地化。本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    基础化

    本地化能力测试,英文是Localizability testing。

    本地化能力测试是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力测试通常在软件的伪本地化版本上进行。

    本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了固定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    国际化

    国际化测试,英文是International testing。又称国际化支持测试。

    国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    国际化支持测试是指验证软件程序在不同国家或区域的平台上也能够如预期的那样运行,而且还可以按照原设计尊重和支持使用当地常用的日期,字体,文字表示,特殊格式等等。比如,用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串?又比如,日文版的Microsoft Excel对话框是否显示正确翻译的日语?一旦来说执行国际化支持测试的测试人员往往需要基本上了解这些国家或地区的语言要求和期望行为是什么。

    安装测试

    安装测试,英文是Installing testing。

    安装测试是确保软件在正常情况和异常情况下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装的测试。异常情况包括磁盘空间不足、缺少目录创建权限等场景。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    白盒测试

    编辑

    白盒测试,英文是White Box Testing。又称结构测试或者逻辑驱动测试。

    白盒测试是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。

    白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖判定覆盖条件覆盖、判定/条件覆盖、条件组合覆盖路径覆盖

    白盒测试是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。

    白盒测试常用工具有:Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。

    黑盒测试

    编辑

    黑盒测试,英文是Black Box Testing。又称功能测试或者数据驱动测试

    黑盒测试是根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    软件测试人员以用户的角度,通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷,而不关心程序具体如何实现的一种软件测试方法。

    黑盒测试常用工具有:AutoRunner、winrunner

    自动化

    编辑

    自动化测试,英文是Automated Testing。

    使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试和功能测试中用得较多。通过录制测试脚本,然后执行这个测试脚本来实现测试过程的自动化。自动化测试工具有QTP、Testcomplete、AutoRunner和TAR等。

    回归测试

    回归测试,英文是Regression testing。

    回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。

    根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的,特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码,因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试,而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化测试

    验收测试

    验收测试,英文是Acceptance testing。

    验收测试是指系统开发生命周期方法论的一个阶段,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

    验收测试一般有三种策略:正式验收、非正式验收或Alpha 测试、Beta 测试。

    静态测试

    编辑

    静态测试,英文是Static Testing。

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

    静态测试常用工具有:Logiscope、PRQA;

    动态测试

    编辑

    动态测试,英文是Moment Testing。

    动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。

    根据动态测试在软件开发过程中所处的阶段和作用,动态测试可分为如下几个步骤:

    1、单元测试

    2、集成测试

    3、系统测试

    4、验收测试

    5、回归测试

    单元测试

    编辑

    单元测试,英文是Unit Testing。

    单元测试是最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。这个工作不容易做好,除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

    集成测试

    编辑

    集成测试,英文是Integration Testing。

    集成测试是指一个应用系统的各个部件的联合测试,以决定它们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前,单元测试需要完成。

    集成测试是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。

    集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元,并确保每个单元的生存能力的测试计划,可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别

    系统测试

    编辑

    系统测试,英文是System Testing。

    系统测试是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不相符合或与之矛盾的地方。

    系统测试的对象不仅仅包括需要测试的产品系统的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此,必须将系统中的软件与各种依赖的资源结合起来,在系统实际运行环境下来进行测试。

    端到端

    编辑

    端到端测试,英文是End to End Testing。

    端到端测试类似于系统测试,测试级的“宏大”的端点,涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。端到端架构测试包含所有访问点的功能测试性能测试。端到端架构测试实质上是一种"灰盒"测试,一种集合了白盒测试黑盒测试的优点的测试方法。

    卸载测试

    编辑

    卸载测试,英文是Uninstall Testing。

    卸载测试是对软件的全部、部分或升级卸载处理过程的测试。主要是测试软件能否卸载,卸载是否干净,对系统有无更改,在系统中的残留与后来的生成文件如何处理等。还有原来更改的系统值是否修改回去

    接受测试

    编辑

    接受测试,英文是Accept Testing。

    接受测试是基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。一般从功能、用户界面、性能、业务关联性进行测试。

    性能测试

    编辑

    性能测试,英文是Performance Testing。

    性能测试是在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。性能测试一般包括负载测试和压力测试。

    通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会出现内存泄露(memory leak)。比如,验证程序保存一个巨大的文件新版本不比旧版本慢。

    健全测试

    健全测试,英文是Sanity testing。

    健全测试是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试能力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,不具备进一步测试的条件。

    衰竭测试

    衰竭测试,英文是Failure Testing。

    衰竭测试是指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

    负载测试

    负载测试,英文是Load testing。

    负载测试是测试一个应用在重负荷下的表现。例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。

    负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    强迫测试

    强迫测试,英文是Force Testing。

    强迫测试是在交替进行负荷和性能测试时常用的术语。也用于描述对象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。

    压力测试

    压力测试,英文是Stress Testing。和负载测试差不多。

    压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分。压力测试的基本思路很简单:不是在常规条件下运行手动或自动测试,而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。

    恢复测试

    恢复测试,英文是Recovery testing。

    恢复测试是测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。恢复测试指通过人为的让软件(或者硬件)出现故障来检测系统是否能正确的恢复,通常关注恢复所需的时间以及恢复的程度。

    恢复测试主要检查系统的容错能力。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败,然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化(reinitialization)、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性;对于人工干预的恢复系统,还需估测平均修复时间,确定其是否在可接受的范围内。

    安全测试

    编辑

    安全测试,英文是Security Testing。

    安全测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。安全测试检查系统对非法侵入的防范能力。安全测试期间,测试人员假扮非法入侵者,采用各种办法试图突破防线。例如:

    ①想方设法截取或破译口令;

    ②专门定做软件破坏系统的保护机制;

    ③故意导致系统失败,企图趁恢复之机非法进入;

    ④试图通过浏览非保密数据,推导所需信息,等等。理论上讲,只要有足够的时间和资源,没有不可进入的系统。因此系统安全设计的准则是,使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

    兼容性

    编辑

    兼容测试,英文是Compatibility Testing。

    兼容测试是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。向上兼容向下兼容,软件兼容硬件兼容。软件的兼容性有很多需要考虑的地方。

    可用性

    编辑

    可用性测试,英文是Practical Usability Testing。

    可用性测试是对“用户友好性”的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

    比较测试

    编辑

    比较测试,英文是Compare Testing。

    比较测试是指与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。来取长补短,以增强产品的竞争力。

    可接受性

    编辑

    可接受性测试,英文是Acceptability Testing。

    可接受性测试是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会很容易程序就挂起或崩溃。如果一个新版本没通过可测试性的验证,就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正

    边界条件

    编辑

    边界条件测试,英文是Boundary Testing。又称边界值测试

    一种黑盒测试方法,是对等价类分析方法的一种补充,由长期的测试工作经验得知,大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例,可以查出更多的错误。

    边界条件测试是环绕边界值的测试。通常意味着测试软件各功能是否能正确处理最大值,最小值或者所设计软件能够处理的最长的字符串等等。

    强力测试

    编辑

    强力测试,英文是Mightiness Testing。

    强力测试通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如,在最低的硬盘驱动器空间或系统记忆容量条件下,验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机

    装配安装

    编辑

    装配/安装/配置测试是验证软件程序在不同厂家的硬件上,所支持的不同语言的新旧版本平台上,和不同方式安装的软件都能够如预期的那样正确运行。比如,把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上,再验证所有功能都正常运行。

    隐藏数据

    编辑

    隐藏数据测试在软件验收和确认阶段是十分必要和重要的一部分。程序的质量不仅仅通过用户界面的可视化数据来验证,而且必须包括遍历系统的所有数据。

    假设一个应用程序要求用户两条信息-----用户名和密码来创建帐户。这个用户输入这两条数据后保存。最后,一个确认窗口将通过数据库中找到这条数据来显示用户名和密码给用户。为了验证所有的数据保存是否正确,一个QA测试人员会在这个确认窗口简单的查看下用户名和密码。如果他们成功了?假设数据库记录了第三条信息----创建日期,它可能不会出现在确认窗口,而只在存档中才出现。如果创建日期保留的不正确,而QA测试人员只验证屏幕上的数据,那么这个问题就不可能被发现。创建日期可能就是一个bug,由于一个用户帐户保存了一个错误的日期到数据库中,这个问题也不可能会被引起注意,因为它被用户界面所隐藏。这只是一个简单的例子,但是它却演化出了一点:隐藏数据测试的重要性。

    等价划分

    编辑

    等价划分测试的英文是equivalence partition testing。

    等价划分测试是根据等价类设计测试用例的一种技术。是黑盒测试的典型方法之一,通过把被测试程序所有可能的输入数据域划分成若干部分。从每一部分中选取少数有代表性的数据作为测试用例,可有效减少测试次数,极大提高软件测试效率,缩短软件开发周期.等价类划分测试的目的就是为了在有限的测试资源的情况下,用少量有代表性的数据得到比较好的测试效果。有效等价类和无效等价类。有效等价类中的数据代表的是一组符合需求文档的正确的有意义数据。无效等价类则正相反。

    判定表

    编辑

    判定表的英文是decision table,是指一个表格,用于显示条件和条件导致动作的集合。

    定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

    判定表的优点:能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。

    在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题

    深度测试

    编辑

    深度测试的英文Depth test ,是指执行一个产品的一个特性的所有细节,但不测试所有特性。

    当比较函数返回真的时候才显示出效果来。必须启用“#深度测试”,才能执行测试。不使用的时候需要关闭。

    基于设计

    编辑

    基于设计的测试的英文是design-based testing,是根据软件的构架或详细设计引出测试用例的一种方法。

    一种基于设计模型的测试方法(Model Based TestIng System,MATIS).该方法利用用户界面自动生成方法,把设计模型中的类属性定义和实现中的控件属性组织在一起,构建描述界面的逻辑对照表,辅助测试脚本引擎执行自动测试脚本.借助设计模型中扩展的类定义,MATIS方法可以自动生成测试用例和测试数据。

    文档测试

    编辑

    文档测试的英文是documentation testing,测试关注于文档的正确性。

    文档测试有三大类分别是开发文件、用户文件、管理文件。

    1. 开发文件:可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书详细设计说明书数据库设计说明书、模块开发卷宗。

    2.用户文件:用户手册、操作手册。

    3.管理文件:项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

    软件测试中的文档测试主要是对相关的设计报告和用户使用说明进行测试,对于设计报告主要是测试程序与设计报告中的设计思想是否一致;对于用户使用说明进行测试时,主要是测试用户使用说明书中对程序操作方法的描述是否正确,重点是用户使用说明中提到的操作例子要进行测试,保证采用的例子能够在程序中正确完成操作。

    一般来说,文档是软件的重要组成部分,因此文档测试也是软件测试的主要内容。在软件的整个生命周期中会出现很多文档,通常可以把文档粗略地分为三类:开发文档,管理文档和用户文档

    由于文档与代码不同,不能直接运行,对于文档的测试通常只能以文档审查的方式进行。对于管理文档和审查通常归属于管理范畴,而不是软件测试范畴,因为对于管理文档审查的目的不是为了发现和消除用户所看到的软件中的缺陷,而是为了更好地管理软件开发的过程。对于开发文档,由于这些文档本身体现了所在开发阶段的软件实际形态,对于这些文档的测试实际上是早期软件测试的主要活动。用户文档是那些随程序一起交付给用户的文档,它们实际上是交付给用户的软件的重要组成部分。对于这些文档的测试是对最终软件产品测试的一部分。

    域测试

    编辑

    域测试的英文是domain testing,定义参考等价划分测试(equivalence partition testing);

    一般分为单域测试和多域测试,其中单域测试包括设备测试和业务测试,设备测试包括测试某个系统的软交换设备、中继媒体网关设备、信令网关设备、接入媒体网关和IAD等设备。

    等价类划分有两种不同的情况:有效等价类和无效等价类。设计时要同时考虑这两种等价类,因为软件不仅要能接收合理的数据,也要能经受意外的考验。

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

    二无效等价类:与有效等价类的定义恰巧相反。

    接口测试

    编辑

    接口测试的英文是interface testing,接口测试测试系统组件间接口的一种测试。

    接口测试的好处:

    由于接口测试代码本身就是用junit(当然接口的类型不同,不一定是Junit来实现)来实现的,是属于自动化测试的范畴,因此必定也包含自动化测试所固有的优势。

    1) 提高测试质量

    软件开发的过程是一个持续集成和改进的过程,而每一次的改进都可能引进新bug,因此当软件的一部分,或者全部修改时,都需要对软件产品重新进行测试。其目的是要验证修改后的产品是符合需求的,而当没有自动化测试代码时,往往会由于各种各样的原因,回归不充分,导致bug遗漏。

    2) 提高测试效率

    软件系统的规模越来越大,功能点越来越多,开发人员的自测或者测试人员的人工测试非常耗时和繁琐,势必导致测试效率的低下,而自动化测试正好解决这些耗时繁琐的任务,在对外接口功能不变的情况下,达到了一次编写,永久使用的效果。

    3) 提高测试覆盖

    通过手工测试很难测试到一些更深层次的异常和安全的问题,通过一些辅助的一些测试工具,能分析出代码的覆盖率,通过覆盖率的提高来提高测试的深度。

    4) 更好地重现软件缺陷

    由于每次执行都是相同的代码,一旦代码出错,必定回归出错

    5) 更好定位错误

    由于接口测试是一种自下向上的测试,因此一旦出错,非常容易定位出错,不像系统测试那样了,一旦有Bug,需要几层验证之后才能确定出错位置

    6) 降低修改bug的成本接口测试基本和开发人员的编码平行工作,因此发现问题会比系统测试早很多,因此减少了修改bug的成本。

    7) 增进测试人员和开发人员之间的合作关系,测试工程师为了更好地开展工作,需要对开发技术有深入的理解和实践,有了与开发工程师更多的交流。

    8) 降低了项目不能按时发布的风险,由于接口测试很早就介入,在提交给系统测试前对项目代码的核心模块已经做了详尽的测试,必定加速系统测试的时间,由此来保证项目的按时发布。

    9)提升测试人员的技能。做接口测试必须了解开发人员的开发流程和一些开发技能,也需要了解测试工具的一些使用方法和一些测试思想,提升了测试人员的技术附加值,提高了自身的竞争力。

    10)促使项目开发过程的规范化

    要进行接口,需要完善的文档进行保障,没有测试文档,接口测试将寸步难行,接口测试将增加开发过程规范化产出,而规范化产出也保证了项目质量。

    逆向测试

    编辑

    逆向测试/反向测试/负面测试的英文是Negative Testing,测试瞄准于使系统不能工作。

    负面测试与正面测试的比较:

    负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说,正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点,正面测试就象一个毕恭毕敬的小学生,老师叫我做什么,我就做什么;而负面测试就象一个调皮捣蛋的孩子,你叫我这样做,我偏不这样做,而且和你对着干。开发人员也是最讨厌修改此类bug的。

    非功能性

    编辑

    非功能性需求测试的英文是non-functional requirements testing ,是与功能不相关的需求测试,如:性能测试、可用性测试等。

    为什么非功能性需求很重要?

    在您设计解决方案的过程中满足功能性需求当然是很重要的。但是,如果没有考虑非功能性需求,您的解决方案则很难取得实效。

    非功能性需求特点:1.不要脱离实际环境;2.可靠性;3.可用性;4.有效性;5.可维护性;6.可移植性。

    极限测试

    编辑

    简介

    极限测试本质上是为了满足极限测试的思想和流程而设计的一套测试策略和流程,其本身并不局限于使用特定的测试技术和方法。

    过程

    1.单元测试

    2.验收测试

    展开全文
  • 白盒测试方法 一、概念 白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。它可以形象得用下图表示: 二、白盒测试方法...

    白盒测试方法

    一、概念
    白盒测试也称结构测试逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。它可以形象得用下图表示:
    在这里插入图片描述

    二、白盒测试方法应该遵循的原则

    • 保证一个模块中的所有独立路径至少被测试一次。
    • 所有逻辑值均需测试真 (true) 和假 (false) 两种情况。
    • 检查程序的内部数据结构,保证其结构的有效性。
    • 在上下边界及可操作范围内运行所有循环。

    白盒测试主要是检查程序内部的逻辑结构,也就是对所有逻辑路径进行测试,是一种穷举路径的测试方法。
    三、测试用例设计方法
    白盒测试常用的测试用例方法有:
    1、逻辑覆盖
    以程序的内部逻辑结构为基础,主要分为语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖。

    • 语句覆盖:语句覆盖法的基本思想是设计若干测试用例,运行被测程序,使程序中的每个可执行语句至少被执行一次。
    • 判定覆盖:判定覆盖法的基本思想是设计若干用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断真假值均曾被满足。
    • 条件覆盖:条件覆盖的基本思想是设计若干测试用例,执行被测程序以后,要使每个判断中每个条件的可能取值至少满足一次。
    • 判定-条件覆盖:判定-条件覆盖是判定和条件覆盖设计方法的交集,即设计足够的测试用例,使得判断条件中的所有条件可能取值至少执行一次,同时,所有判断的可能结果至少执行一次。
    • 条件组合覆盖:条件组合覆盖的基本思想是设计足够的测试用例,使得程序中每个判断的所有可能的条件取值组合都至少出现一次。

    2、路径覆盖
    它主要是再程序控制流程的基础上,分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。
    路径覆盖:路径覆盖就是设计所有的测试用例,来覆盖程序中的所有可能的执行路径。
    路径覆盖这种测试方法可以对程序进行彻底的测试,比前面五种的覆盖面都广。
    3、基本路径测试法
    (1)在白盒测试中还有一种非常重要的测试方法就是基本路径测试法。
    它的一般流程是:

    • 依据代码绘制流程图
    • 确定流程图的圈复杂度
    • 确定线性独立路径的基本集合
    • 设计测试用例覆盖每条基本路径

    (2)下面简单介绍一下基本路径测试方法中的相关概念
    控制流图
    如下图所示:
    在这里插入图片描述

    其中(a)图示一个含有两个出口判断和循环的程序流程图,我们把它简化成(b)的形式,称这种简化了的程序流程图叫做控制流图。
    圈复杂度(v(G))
    圈复杂度:代码逻辑复杂度的度量,提供了被测代码的路径数量。复杂度越高,出错的概率越大。
    在这里插入图片描述
    它的计算方式一般有三种:

    • V(G) = 区域数量(由节点、连线包围的区域,包括图形外部区域)
    • V(G) = 连线数量 - 节点数量 + 2
    • V(G) =简单可预测节点数量 + 1

    圈复杂度为几就有几条独立执行路径
    四、举例说明各个测试方法的应用
    1、逻辑覆盖
    我们要进行设计测试用例的图如下:

    在这里插入图片描述

    (1)语句覆盖:
    只需设计一个测试用例:
    a=2,b=1,c=6;
    (2)判定覆盖

    • a=2,b=1 ,c=6可覆盖判断M的Y分支和判断N的Y分支;
    • a=-2,b=-1 ,c=-3可覆盖判断M的N分支和判断N的N分支 。
      这两组测试用例可覆盖所有判定的真假分支。
      (3)判定覆盖
      判断M表达式:
      设条件 a>0
      取真记为 T1
      取假记为 F1
      条件 b>0
      取真 记为 T2
      取假 记为 F2
      判断Q表达式:
      设条件 a>1
      取真 记为 T3
      取假 记为 F3
      条件 c>1
      取真 记为 T4
      取假 记为 F4
      设计的测试用例如下表所示:

    在这里插入图片描述
    它覆盖了判定M的N分支和判断N的Y分支
    (4)判定-条件覆盖
    设计的测试用例如下表所示:
    在这里插入图片描述
    (5)条件组合覆盖
    设计的测试用例如下表所示:
    在这里插入图片描述

    2、路径覆盖
    设计的测试用例如下所示:
    在这里插入图片描述

    黑盒测试方法

    一、概念
    黑盒测试也称功能测试数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用。
    在测试时,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性,,如下图所示:
    在这里插入图片描述
    二、黑盒测试的测试方法
    1、等价类划分
    等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。等价类是某个输入域的子集,在该子集中每个输入数据的作用是等效的。
    它主要分为:

    • 有效等价类: 是有意义的、合理的输入数据构成的集合。可检查程序是否实现了规格说明中所规定的功能和性能。
    • 无效等价类:与有效等价类的定义恰巧相反。

    2、边界值分析法
    (1)定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
    (2)与等价划分的区别

    • 边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
    • 边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

    (3)设计方法:

    • 确定边界情况(输入或输出等价类的边界)
    • 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

    3、判定表方法
    (1)定义:在实际应用中,许多输入是由多个因素构成,而不是单一因素,这时就需要多因素组合分析。对于多因素,有时可以直接对输入条件进行组合设计,不需要进行因果分析,即直接采用判定表方法。
    一个判定表由“条件和活动”两部分组成,也就是列出了一个测试活动执行所需的条件组合,所有可能的条件组合定义了一系列的选择,而测试活动需要考虑每一个选择。
    (2)判定表方法步骤

    • 列出所有的条件桩和动作桩;
    • 填入条件项;
    • 填入动作项,制定初始判定表;
    • 简化、合并相似规则或者相同动作

    4、因果图法
    (1)定义:多种输入条件的组合,产生多种结果设计测试用例。
    (2)设计方法:

    • 分析软件规格说明文档描述的哪些是原因(输入条件),哪些是结果(输出条件),给每个原因和结果赋予一个标识符。
    • 找出原因与结果,原因与原因之间的对应关系,划出因果图
    • 在因果图上标上哪些不可能发生的因果关系,表明约束或限制条件
    • 根据因果图,创建判定表,将复杂的逻辑关系和多种条件组合很具体明确的表示出来
    • 把判定表的每一列作为依据设计测试用例。

    条件与条件之间又存在以下约束关系
    在这里插入图片描述

    5、场景法
    (1)定义:用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。
    (2)基本流和备选流如下图所示
    在这里插入图片描述

    直黑线表示基本流是经过用例的最简单的路径。
    备选流用不同的彩色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如1和3);也可能起源于另一个备选流(如2),或者终止用例而不再重新加入到某个流(如2和4)。
    6、正交实验法
    7、功能图法
    每个程序的功能通常由静态说明和动态说明组成:

    • 静态说明描述了输入条件和输出条件之间的对应关系
    • 动态说明描述了输入数据的次序或者转移的次序。

    功能图法就是为了解决动态说明问题的一种测试用例的设计方法

    展开全文
  • 白盒测试方法

    万次阅读 多人点赞 2019-08-12 19:27:47
    白盒测试法检查程序内部逻辑结构,对所有逻辑路径进行测试,是一种穷举路径的测试方法。但即使每条路径都测试过了,仍然可能存在错误。因为: 穷举路径测试无法检查出程序本身是否违反了设计规范,即程序是否是一个...

    一、概述:

    白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。

    白盒测试法检查程序内部逻辑结构,对所有逻辑路径进行测试,是一种穷举路径的测试方法。但即使每条路径都测试过了,仍然可能存在错误。因为:

    穷举路径测试无法检查出程序本身是否违反了设计规范,即程序是否是一个错误的程序。

    穷举路径测试不可能查出程序因为遗漏路径而出错。

    穷举路径测试发现不了一些与数据相关的错误。

    二、方法

    白盒测试主要是检查程序的内部结构、逻辑、循环和路径。常用测试用例设计方法有:

    逻辑覆盖:以程序的内部逻辑结构为基础,分为语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖等。

    基本路径测试:在程序控制流程的基础上,分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。

     逻辑覆盖 vs. 路径覆盖:

    逻辑覆盖:以程序或系统的内部逻辑结构为基础,分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等。

    基本路径测试:在程序或业务控制流程的基础上,分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。

    2.1 语句覆盖:

    语句覆盖法的基本思想是设计若干测试用例,运行被测程序,使程序中的每个可执行语句至少被执行一次

    如果是顺序结构,就是让测试从头执行到尾

    如果有分支、条件和循环,需要利用下面的方法,执行足够的测试覆盖全部语句

    只需设计一个测试用例:    a=2,b=1,c=6; 即达到了语句覆盖。

    【优点】 :可以很直观地从源代码得到测试用例,无须细分每条判定表达式。

    【缺点】 :由于这种测试方法仅仅针对程序逻辑中显式存在的语句,但对于隐藏的条件是无法测试的。如在多分支的逻辑运算中无法全面的考虑。语句覆盖是最弱的逻辑覆盖。

    2.2 判定覆盖

    设计若干用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断真假值均曾被满足。 一个判定往往代表着程序的一个分支,所以判定覆盖也被称为分支覆盖。

    a=2,b=1 ,c=6可覆盖判断M的Y分支和判断N的Y分支;

    a=-2,b=-1 ,c=-3可覆盖判断M的N分支和判断N的N分支 。   这两组测试用例可覆盖所有判定的真假分支。

    a=1,b=1 ,c=-3  可覆盖判断M的Y分支和判断N的N分支 ;

    a=1,b=-2 ,c=3可覆盖判断M的N分支和判断N的Y分支 ;   同样的这两组测试用例也可覆盖所有判定的真假分支。

    【优点】:判定覆盖具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性,无须细分每个判定就可以得到测试用例。

    【缺点】:往往大部分的判定语句是由多个逻辑条件组合而成,若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径。判定覆盖仍是的逻辑覆盖。

    2.3 条件覆盖

    设计若干测试用例,执行被测程序以后,要使每个判断中每个条件的可能取值至少满足一次

    判断M表达式: 设条件 a>0 取真 记为 T1           取假 记为  F1  

    条件 b>0 取真 记为  T2            取假 记为  F2

    判断N表达式: 设条件 a>1 取真 记为 T3             取假 记为 F3  

    条件 c>1 取真 记为  T4             取假 记为 F4

    它覆盖了判定M的N分支和判断N的Y分支。 

    测试用例

    覆盖条件

    具体取值条件

     

    a=2,b=-1,c=-2

     

    T1, F2, T3, F4

    a>0,b<=0,

    a>1,c<=1

     

    a=-1,b=2,c=3

    F1, T2, F3, T4

    a<=0,b>0,

    a<=1,c>1

    我们用条件覆盖设计的思想就是让测试用例能覆盖 T1、T2、T3、T4、F1、F2、F3、F4 

    【优点】:增加了对条件判定情况的测试,增加了测试路径。

    【缺点】:条件覆盖不一定包含判定覆盖。例如,我们刚才设计的用例就没有覆盖判断M的Y分支和判断N的N分支。条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果。

    2.4 判定条件覆盖

    判定-条件覆盖是判定和条件覆盖设计方法的交集,即设计足够的测试用例,使得判断条件中的所有条件可能取值至少执行一次,同时,所有判断的可能结果至少执行一次

    测试用例

    取值条件

    具体取值条件

    判定条件

    通过路径

    输入:a=2,b=1,c=6

    输出:a=2,b=1,c=5

    T1,T2,T3,T4

    a>0,b>0, a>1,c>1

    M=.T.

    N=.T.

    P1(1-2-4)

    输入:a=-1,b=-2,c=-3

    输出:a=-1,b=-2,c=-5

    F1,F2,F3,F4

    a<=0, b<=0, a<=1, c<=1

    M=.F.

    N=.F.

    P4(1-3-5)

    按照判定-条件覆盖的要求,我们设计的测试用例要满足如下条件:

    1.所有条件可能至少执行一次取值;

    2.所有判断的可能结果至少执行一次。 

    测试用例

    覆盖条件

    覆盖判断

    a=2,b=1,c=6

    T1, T2,

    T3, T4

    M的Y分支和N的Y分支

    a=-1,b=-2,c=-3

     

    F1, F2, 

    F3, F4

    M的N分支和N的N分支

     要满足T1、T2、 T3 、T4 F1、 F2 、F3、F4

    【优点】 :能同时满足判定、条件两种覆盖标准。

    【缺点】 :判定/条件覆盖准则的缺点是未考虑条件的组合情况。

    2.5 条件组合覆盖

    设计足够的测试用例,使得程序中每个判断的所有可能的条件取值组合都至少出现一次

    它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果,而是要求让这些结果的所有可能组合都至少出现一次

    按照条件组合覆盖的基本思想,对于前面的例子,我们把每个判断中的所有条件进行组合,设计组合条件如表所示,而我们设计的测试用例就要包括所有的组合条件

    组合编号

    覆盖条件取值

    判定条件取值

    判定-条件组合

    1

    T1T2

    M=.T.

    a>0b>0M取真

    2

    T1F2

    M=.F.

    a>0b<=0M取假

    3

    F1T2

    M=.F.

    a<=0b>0M取假

    4

    F1F2

    M=.F.

    a<=0b<=0M取假

    5

    T3T4

    N=.T.

    a>1c>1N取真

    6

    T3F4

    N=.T.

    a>1c<=1N取真

    7

    F3T4

    N=.T.

    a<=1c>1N取真

    8

    F3F4

    N=.F.

    a<=1c<=1N取假

    测试用例

    覆盖条件

    覆盖判断

    覆盖组合

    a=2,b=1,c=6

    T1, T2,

    T3, T4

    M取Y分支,Q取Y分支

    1,5

    a=2,b= -1,c= -2

    T1, F2, 

    T3, F4

    M取N分支,Q取Y分支

    2,6

    a=-1,b=2,c=3

     

    F1, T2, 

    F3, T4

    M取N分支,Q取Y分支

    3,7

    a= -1,b= -2,c= -3

     

    F1, F2, 

    F3, F4

    M取N分支,Q取N分支

    4,8

    要满足1、2、3、4、5、6、7、8条件组合

    测试用例

    覆盖条件

    覆盖路径

    覆盖组合

    输入:a=2,b=1,c=6

    输出:a=2,b=1,c=5

    T1,T2,T3,T4

    P1(1-2-4)

    1,5

    输入:a=2,b=-1,c=-2

    输出:a=2,b=-1,c=-2

    T1,F2,T3,F4

    P3(1-3-4)

    2,6

    输入:a=-1,b=2,c=3 

    输出:a=-1,b=2,c=6

    F1,T2,F3,T4

    P3(1-3-4)

    3,7

    输入:a=-1,b=-2,c=-3

    输出:a=-1,b=-2,c=-5

    F1,F2,F3,F4

    P4(1-3-5)

    4,8

    覆盖了所有组合,但覆盖路径有限,1-2-5 没被覆盖 

    【优点】:条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。

    【缺点】:线性地增加了测试用例的数量。

    2.6 路径覆盖

    设计所有的测试用例,来覆盖程序中的所有可能的执行路径

    测试用例

    覆盖路径

    覆盖条件

    覆盖组合

    输入:a=2,b=1,c=6

    输出:a=2,b=1,c=5

    P1(1-2-4)

    T1,T2,T3,T4

    1,5

    输入:a=1,b=1,c=-3

    输出:a=1,b=1,c=-2

    P2(1-2-5)

    T1,T2,F3,F4

    1,8

    输入:a=2,b=-1,c=-2

    输出:a=2,b=-1,c=-2

    P3(1-3-4)

    T1,F2,T3,F4

    2,6

    输入:a=-1,b=2,c=3 

    输出:a=-1,b=2,c=6

    P3(1-3-4)

    F1,T2,F3,T4

    3,7

    输入:a=-1,b=-2,c=-3

    输出:a=-1,b=-2,c=-5

    P4(1-3-5)

    F1,F2,F3,F4

    4,8

    测试用例

    覆盖组合

    覆盖路径

    a=2,b=1,c=6

    1,5

    1-2-4

    a=1,b=1,c=-3

    1,8

    1-2-5

    a=-1,b=2,c=3

    4,7

    1-3-4

    a=-1,b=-2,c=-3

    4,8

    1-3-5

    【优点】 :这种测试方法可以对程序进行彻底的测试,比前面五种的覆盖面都广。

    【缺点】 :需要设计大量、复杂的测试用例,使得工作量呈指数级增长,不见得把所有的条件组合都覆盖。 

     2.7、逻辑覆盖总结

    根据覆盖目标的不同,逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖

    语句覆盖:选择足够多的测试用例,使得程序中的每个可执行语句至少执行一次。

    判定覆盖:通过执行足够的测试用例,使得程序中的每个判定至少都获得一次“真”值和“假”值, 也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次,也称为“分支覆盖”。

    条件覆盖:设计足够多的测试用例,使得程序中每个判定包含的每个条件的可能取值(真/假)都至少满足一次。

    判定/条件覆盖:设计足够多的测试用例,使得程序中每个判定包含的每个条件的所有情况(真/假)至少出现一次,并且每个判定本身的判定结果(真/假)也至少出现一次。    

    ——满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖。

    组合覆盖:通过执行足够的测试用例,使得程序中每个判定的所有可能的条件取值组合都至少出现一次。    

    ——满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。

    路径覆盖:设计足够多的测试用例,要求覆盖程序中所有可能的路径。

    3.基本路径测试

    3.1流程

    1.依据代码绘制流程图

    2.确定流程图的圈复杂度(cyclomatic complexity )

    3.确定线性独立路径的基本集合( basis set )

    4.设计测试用例覆盖每条基本路径

    3.2 示例:

    Path1: 1-2-3-6-7-9-10-1-11

    Path2: 1-2-3-6-8-9-10-1-11

    Path3: 1-2-3-4-5-10-1-11

    Path4: 1-11P

    基本路径测试并不是测试所有路径的组合,仅仅保证每条基本路径被执行一次

    展开全文
  • 八大黑盒测试方法总结【超详细】

    千次阅读 2020-09-20 23:53:23
    实例说明8、三角形问题的边界值分析测试用例三、错误推测方法1. 定义2. 错误推测方法的基本思想:四、因果图方法1.定义2.因果图法产生的背景:3.因果图介绍4. 因果图概念5. 采用因果图法设计测试用例的步.

    一、等价类划分法

    1.定义

    是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

    2. 划分等价类

    等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。

    2.1 有效等价类

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

    2.2 无效等价类

    与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

    设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验,这样的测试才能确保软件具有更高的可靠性。

    3. 划分等价类的标准

    1. 完备测试、避免冗余;
    2. 划分等价类重要的是:集合的划分,划分为互不相交的一组子集,而子集的并是整个集合;
    3. 并是整个集合:完备性;
    4. 子集互不相交:保证一种形式的无冗余性;
    5. 同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到"相同的执行路径"。

    4.划分等价类的方法

    1. 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
    2. 在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类;
    3. 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
    4. 在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
      例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种这四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。
    5. 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则);
    6. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

    5.设计测试用例

    在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例:

    1. 为每一个等价类规定一个唯一的编号;
    2. 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;
    3. 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。

    6. 三角形实例

    某程序规定:"输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)

    分析题目中给出和隐含的对输入条件的要求:
    (1)整数 (2)三个数 (3)非零数 (4)正数
    (5)两边之和大于第三边 (6)等腰 (7)等边

    如果 a 、 b 、 c 满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一:

    1. 如果不满足条件(5),则程序输出为 " 非三角形 " 。
    2. 如果三条边相等即满足条件(7),则程序输出为 " 等边三角形 " 。
    3. 如果只有两条边相等、即满足条件(6),则程序输出为 " 等腰三角形 " 。
    4. 如果三条边都不相等,则程序输出为 " 一般三角形 " 。

    列出等价类表并编号

    在这里插入图片描述

    覆盖有效等价类:
    在这里插入图片描述

    覆盖无效等价类
    在这里插入图片描述

    二、边界值分析法

    1. 定义

    边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

    2. 与等价划分的区别

    1. 边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
    2. 边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

    3.边界值分析方法的考虑

    长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。
    使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

    4. 常见的边界值

    1. 对16-bit 的整数而言 32767 和 -32768 是边界
    2. 屏幕上光标在最左上、最右下位置
    3. 报表的第一行和最后一行
    4. 数组元素的第一个和最后一个
    5. 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

    5.边界值分析

    1. 边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例。
      例:测试计算平方根的函数
      –输入:实数
      –输出:实数
      –规格说明:当输入一个0或比0大的数的时候,返回其正平方根;当输入一个小于0的数时,显示错误信息"平方根非法-输入值小于0"并返回0;库函数Print-Line可以用来输出错误信息。

    2. 等价类划分:
      I.可以考虑作出如下划分:
      a、输入 (i)<0 和 (ii)>=0
      b、输出 (a)>=0 和 (b) Error
      II.测试用例有两个:
      a、输入4,输出2。对应于 (ii) 和 (a) 。
      b、输入-10,输出0和错误提示。对应于 (i) 和 (b) 。

    3. 边界值分析:
      划分(ii)的边界为0和最大正实数;划分(i)的边界为最小负实数和0。由此得到以下测试用例:
      a、输入 {最小负实数}
      b、输入 {绝对值很小的负数}
      c、输入 0
      d、输入 {绝对值很小的正数}
      e、输入 {最大正实数}

    4. 通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

    5. 相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。

    6. 利用边界值作为测试数据
      在这里插入图片描述

    7. 内部边界值分析:
      在多数情况下,边界值条件是基于应用程序的功能设计而需要考虑的因素,可以从软件的规格说明或常识中得到,也是最终用户可以很容易发现问题的。然而,在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。

    内部边界值条件主要有下面几种
    a)数值的边界值检验:计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。
    在这里插入图片描述
    b)字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。
    在这里插入图片描述
    c)其它边界值检验

    6.基于边界值分析方法选择测试用例的原则

    1. 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
      例如,如果程序的规格说明中规定:“重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……”。作为测试用例,我们应取10及50,还应取10.01,49.99,9.99及50.01等。
    2. 如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
      比如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。
    3. 将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。
      例如,某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元",其测试用例可取0.00及1165.24、还可取一0.01及1165.26等。
      再如一程序属于情报检索系统,要求每次"最少显示1条、最多显示4条情报摘要",这时我们应考虑的测试用例包括1和4,还应包括0和5等。
    4. 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
    5. 如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
    6. 分析规格说明,找出其它可能的边界条件。

    7. 实例说明

    现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:
    在这里插入图片描述
    ①标题:这一组只有一个记录,其内容为输出成绩报告的名字。
    ②试卷各题标准答案记录:每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。
    ③每个学生的答卷描述:该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。
    ④学生人数不超过200,试题数不超过999。
    ⑤程序的输出有4个报告:
    a)按学号排列的成绩单,列出每个学生的成绩、名次。
    b)按学生成绩排序的成绩单。
    c)平均分数及标准偏差的报告。
    d)试题分析报告。按试题号排序,列出各题学生答对的百分比。

    解答:分别考虑输入条件和输出条件,以及边界条件。给出下表所示的输入条件及相应的测试用例。

    在这里插入图片描述
    输出条件及测试用例表
    在这里插入图片描述

    8、三角形问题的边界值分析测试用例

    在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100] 。
    在这里插入图片描述

    三、错误推测方法

    1. 定义

    基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

    2. 错误推测方法的基本思想:

    列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

    1. 例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
    2. 例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:
      I. 程序是否把空格作为回答
      II. 在回答记录中混有标准答案记录
      III. 除了标题记录外,还有一些的记录最后一个字符即不是2也不是3
      IV. 有两个学生的学号相同
      V. 试题数是负数。
    1. 再如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:
      I. 输入的线性表为空表;
      II. 表中只含有一个元素;
      III. 输入表中所有元素已排好序;
      IV. 输入表已按逆序排好;
      V. 输入表中部分或全部元素相同。

    四、因果图方法

    1.定义

    是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

    2.因果图法产生的背景:

    等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

    如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。

    3.因果图介绍

    在这里插入图片描述

    • 因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。
    • Ci表示原因,通常置于图的左部;ei表示结果,通常在图的右部。Ci和ei均可取值0或1,0表示某状态不出现,1表示某状态出现。

    4. 因果图概念

    1. 关系
      ①恒等:若ci是1,则ei也是1;否则ei为0。
      ②非:若ci是1,则ei是0;否则ei是1。
      ③或:若c1或c2或c3是1,则ei是1;否则ei为0。“或”可有任意个输入。
      ④与:若c1和c2都是1,则ei为1;否则ei为0。“与”也可有任意个输入。
    2. 约束
      输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
      在这里插入图片描述
      A.输入条件的约束有以下4类:
      ① E约束(异):a和b中至多有一个可能为1,即a和b不能同时为1。
      ② I约束(或):a、b和c中至少有一个必须是1,即 a、b 和c不能同时为0。
      ③ O约束(唯一);a和b必须有一个,且仅有1个为1。
      ④R约束(要求):a是1时,b必须是1,即不可能a是1时b是0。
      B.输出条件约束类型
      输出条件的约束只有M约束(强制):若结果a是1,则结果b强制为0。

    5. 采用因果图法设计测试用例的步骤:

    • 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
    • 分析软件规格说明描述中的语义,找出原因与结果之间, 原因与原因之间对应的关系,根据这些关系,画出因果图。
    • 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
    • 把因果图转换为判定表。
    • 把判定表的每一列拿出来作为依据,设计测试用例。

    6.实例说明

    6.1 例一

    某软件规格说明书包含这样的要求:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。

    • 根据题意,原因和结果如下:
      原因:
      1——第一列字符是A;
      2——第一列字符是B;
      3——第二列字符是一数字。
      结果:
      21——修改文件;
      22 ——给出信息L;
      23——给出信息M。
    • 其对应的因果图如下:
      11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。
      在这里插入图片描述
    • 根据因果图建立判定表。
    • 在这里插入图片描述
      表中8种情况的左面两列情况中,原因①和原因②同时为1,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了6种情况的测试用例,这是我们所需要的数据。

    6.2 例二

    有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。

    • 分析这一段说明,列出原因和结果
      原因
      1.售货机有零钱找
      2.投入1元硬币
      3.投入5角硬币
      4.押下橙汁按钮
      5.押下啤酒按钮
      结果
      21.售货机〖零钱找完〗灯亮
      22.退还1元硬币
      23.退还5角硬币
      24.送出橙汁饮料
      25.送出啤酒饮料
    • 画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点:
      11.投入1元硬币且押下饮料按钮
      12. 押下〖橙汁〗或〖啤酒〗的按钮
      13. 应当找5角零钱并且售货机有零钱找
      14. 钱已付清
      在这里插入图片描述
    • 转换成判定表
      在这里插入图片描述
    • 在判定表中,阴影部分表示因违反约束条件的不可能出现的情况,删去。第16列与第32列因什么动作也没做,也删去。最后可根据剩下的16列作为确定测试用例的依据。

    五、判定表驱动分析方法

    1. 定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

    2. 判定表的优点
      能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。

    3. "阅读指南”判定表3.  阅读指南”判定表

    4. 判定表通常由四个部分组成如下图所示。在这里插入图片描述

    • 条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

    • 动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

    • 条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。

    • 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

    1. 规则及规则合并
    • 规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

    • 化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。

    六、正交实验设计方法

    利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。
    正交实验设计方法:依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

    利用正交实验设计测试用例的步骤:

    1. 提取功能说明,构造因子–状态表
      把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。
    2. 加权筛选,生成因素分析表
      对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。
    3. 利用正交表构造测试数据集
      正交表的推导依据Galois理论(这里省略,需要时可查数理统计方面的教材)。
      利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。

    七、功能图分析方法

    一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。

    对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.

    功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

    (功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.)

    1. 功能图
      功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。

    2. 测试用例生成方法
      从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例. 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题(如白盒测试)问题了.

    3. 测试用例生成规则
      为了把状态迁移(测试路径)的测试用例与逻辑模型(局部测试用例)的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移(SST)中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.(其表示图形省略)。

    4. 从功能图生成测试用例的过程
      4.1 生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。
      4.2 测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。
      4.3 测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

    5. 测试用例的合成算法:采用条件构造树.

    八、场景设计方法

    现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。
    基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。
    在这里插入图片描述
    实例说明:
    下图所示是ATM例子的流程示意图。
    在这里插入图片描述
    以下是生成的场景:
    在这里插入图片描述
    用例设计

    对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。

    对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。
    在这里插入图片描述

    在这里插入图片描述
    .数据设计

    一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。
    测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 白盒测试是测试人员常用的一种测试方法,越来越受到测试工程师的重视。白盒测试并不是简单的按照代码测试用例而走,需要根据不同的测试需求,结合不同的测试对象,使用适合的方法进行测试。本文介绍六种白盒测试方法...
  • 软件测试基础知识 - 说一说黑盒与白盒的测试方法

    万次阅读 多人点赞 2019-02-11 11:48:37
    白盒测试法检查程序内部逻辑结构,对所有的逻辑路径进行测试,是一种穷举路径的测试方法,但即使每条路径都测试过了,但仍然有可能存在错误。因为:穷举路径测试无法检查出程序本身是否违反了设计规范,即程序是否是...
  • 软件测试之软件测试方法

    千次阅读 2019-06-15 15:50:40
    软件测试过程中,最主要的就是要掌握好软件测试的方法,掌握好了软件测试方法,有利于测试技能的大幅度提高。 软件测试方法 软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样...
  • 测试方法之Java白盒测试(二)

    万次阅读 2019-12-21 19:09:44
    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家!...文章目录五、使用 JUnit 进行单元测试4.JUnit 的安装和使用流程4.1 第 1 步,安装 eclipse 及 jre4.2 第 2 步,新建 Java 项目4.3 第 3 ...
  • 常见的二十种软件测试方法详解(史上最全)

    千次阅读 多人点赞 2021-01-27 22:15:57
    测试方法:白盒测试(因为要测源码) 测试内容:模块接口测试(测试模块里面的参数传递是否正确)、局部数据结构测试(测试变量的作用域范围)、路径测试(if-else 判断必须覆盖所有分支)、错误处理
  • 接口测试-Mock测试方法

    万次阅读 多人点赞 2019-05-26 22:29:02
    对于某些不容易构造(如 HttpServletRequest 必须在Servlet 容器中才能构造出来)或者不容易获取的比较复杂的对象(如 JDBC 中的ResultSet 对象),用一个虚拟的对象(Mock 对象)来创建以便测试的测试方法。...
  • 等价类划分测试方法 在很多情况下,很多人想到的测试方法是穷举测试,穷举测试是最全面的测试,但是数据量很大的情况下不太现实,测试效率太低 实现目标:用最少的测试数据,比较高的效率,以达到最好的测试质量 ...
  • 黑盒测试方法(全)

    万次阅读 多人点赞 2019-07-02 18:13:00
    测试用例的设计方法(全) 目录: 等价类划分方法 边界值分析方法 错误推测方法 因果图方法 判定表驱动分析方法 正交实验设计方法 功能图分析方法 场景设计方法 等价类划分方法: 一.方法简介 1.定义 ...
  • 白盒测试主要包含如下测试方法: 1.语句覆盖 语句覆盖要求必须编写足够多的测试用例,使得每一个可执行的语句都至少被执行一次,语句覆盖常常被称为“最弱的覆盖”,因为它只考虑了可执行语句,但是无法测试隐式...
  • 一些基本的测试方法

    万次阅读 2018-08-09 16:55:22
    接下来我们要讨论的就是怎么做的问题了,即具体的测试方法。 图描绘的质量属性的六大类和测试类型之间的关系,并没有深入到各个质量子属性和各个子属性对应的测试类型中去(大家不妨自己动手绘制一下“质量子属性...
  • 黑盒测试的测试方法

    万次阅读 多人点赞 2017-12-19 11:35:22
    一般我们在做软件测试的时候,会遇到黑盒测试,白盒测试,我们今天主要说的是黑盒测试的 主要测试方法有那些。接下来就是干货了。 最常见的是  边界值 等价类 错误推测法 场景法 因果图法 判定表组成法 正交实验...
  • 测试方法-等价类划分

    万次阅读 多人点赞 2020-04-06 23:36:39
    测试方法测试方法1、黑盒-等价类例1:测试一个两位数的加法计算器例2:余额宝提现例3:三角形测试用例设计 测试方法 软件测试方法 经典定义: 软件测试(Software Testing),在规定的条件下对程序进行操作,以发现程序...
  • 渗透测试方法

    千次阅读 多人点赞 2021-03-28 10:00:47
    文章目录渗透测试方法论2.1 渗透测试的种类2.1.1 黑盒测试2.1.2 白盒测试2.2 脆弱性评估与渗透测试2.3 安全测试方法论2.3.1 开源安全测试方法论(OSSTMM)2.3.2 信息系统安全评估框架2.3.3 开放式Web应用程序安全...
  • (1)白盒测试:又称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构,设计测试数据并完成测试的一种测试方法。 (2)黑盒测试:又称为数据驱动测试,把测试对象当做看不见的黑盒,在完全不考虑...
  • API安全测试方法

    千次阅读 热门讨论 2021-01-16 22:11:36
    API测试小结
  • 黑盒测试用例测试方法

    万次阅读 2018-05-25 17:55:21
    黑盒测试用例设计方法一、等价类划分法 等价类划分法是一种典型的、重要的黑盒测试方法,是指某个输入域的子集合。在该子集合中,所有的输入数据对于揭露软件中的错误都是等效的。 等价类划分有效等价类和无效等价类...
  • 人工智能(AI)测试方法

    千次阅读 2020-05-12 17:26:21
    人工智能利用机器学习技术,通过对现有的经过处理(筛选、消噪、过滤等)的数据,不断进行矫正(设置阀值等方法)机器模型的输出,此过程称为训练,期望通过训练可以得到在未来新数据上有良好表现的模型,从而投入...
  • 车载毫米波雷达测试方法

    千次阅读 2020-08-25 15:01:13
    车载毫米波雷达测试方法文件摘录测试条件4.3 测试目标性能测试5.1 探测范围5.2 探测速度范围5.3 多目标分辨能力 2020年《车载毫米波雷达测试方法》规定了车载毫米波雷达测试的测试条件、性能测试、发射机测试和电气...
  • 黑盒测试主要意味着测试要在软件的接口处进行,这种测试方法是将测试对象看成一个盒子,测试人员不考虑内部,直接按照需求规则说明书,直接检查他的功能是否符合要求。 如上图所示,将系统看成黒盒,内部如何实现是...
  • 软件测试方法分类

    千次阅读 2019-06-02 14:59:09
    软件测试方法种类繁多,有白盒测试、黑盒测试、静态测试、动态测试、集成测试等等,记忆起来容易混乱,傻傻分不清楚,如果把软件测试方法进行分类, 就会清晰很多。现在te...
  • 从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。 下面内容来自网络相关资料的整理: ...对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、或者派生类(子类)中的方法
  • 性能测试方法

    千次阅读 2019-04-26 09:53:39
    备注:以下是常用的测试方法,当然我们还是要根据项目的需要而定,不同项目,不同业务,压测方法不同。比如长连接和短链接不同,协议不同,测试方法不同,大家要根据情况而定。 负载测试:通过在被测系统上不断加压...
  • 黑盒和白盒测试方法详解

    万次阅读 多人点赞 2020-03-19 12:14:53
    1. 黑盒测试 黑盒测试也称功能测试,测试中把被测的软件当成一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据与输出...黑盒测试方法, 详见https://blog.csdn.net/asdx1020/article/details/10487091...
  • 探索式测试方法的实践

    千次阅读 2021-09-08 09:14:02
    经过长期的发展,软件测试方法不断完善,探索式测试方法也是其中的一种。本文将结合实际工作谈谈对探索式测试方法的理解。 任何一个软件公司发布的产品都有缺陷,所以软件测试是产品开发过程中必不可少的一部分...
  • Web测试方法

    千次阅读 2018-09-21 11:10:28
    最近做某项目,项目要求采用B/S架构进行系统总体构建,此次测试为面向Web的测试,现整理出面向web测试设计测试用例时需要考虑的因素。 一、功能测试 首先需要将系统和需求说明书中的功能需求进行对比,查看是否有...
  • 在软件的开发过程中,有两类人是决定软件开发质量的,这两类人是开发人员和测试人员。这两类人必须紧密配合,充分合作,才能一起开发出完美的软件。两者之间在一个软件开发过程中,按照如下的关系紧密结合在一起: ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,740,004
精华内容 1,496,001
关键字:

测试方法

友情链接: TxtFileCopy.zip