软件测试的常识

软件测试基本概念1.1软件分类按功能：系统软件、应用软件按技术架构：单机版软件、C/S结构软件、B/S结构软件按功能：产品软件、项目软件按开发规模：小型软件、中型软件、大型软件1.2测试用例(TC)测试用例的基本要素：测试环境、操作步骤、输入数据、期望结果测试模板：Excel模板(适合写功能用例)、Word模板(适合写性能用例)软件测试分类2.1黑盒测试和白盒测试黑盒测试(black-boxtesting):把被测软件看作一个黑盒子，只关心软件的输入数据和输出结果。它包括功能测试和性能测试。白盒测试(white-boxtesting):研究软件的源码和程序结构。需要一定编码能力，并会使用一些测试工具。2.2静态测试和动态测试静态测试(statictesting)：不实际运行被测软件，只是静态地检查程序代码、界面或文档中可能存在的错误。动态测试(dynamictesting)：实际运行被测软件，输入相应的测试数据，检查实际输出结果和预期结果是否相符。2.3单元测试、集成测试、系统测试和验收测试它们是软件测试中的重要概念，是按照软件测试的阶段来划分的。单元测试(unittesting)：指对软件中的最小可测试单元进行检查和认证。通常在程序员编码之后，代码已通过编译后进行。单元测试一般由白拿测试工程师或开发人员来测试。依据是源程序本身和项目的<<详细设计>>文档。标准是语句的覆盖率达到100%，分支的覆盖率达到85%。集成测试(integrationtesting)：单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。一般由白拿测试工程师或开发人员来测试。集成测试的依据是单元测试的模块以及<<概要设计>>文档。系统测试(systemtesting)：将整个软件系统看做一个整体进行测试，包括对功能、性能以及软件所运行的软硬件环境进行测试。主要由黑盒测试工程师在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。系统测试的主要依据是<<系统需求规格说明书>>文档。验收测试(acceptancetesting)：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。验收测试又分为a测试和B测试。其中a测试指的是由用户、测试人员、开发人员等共同参与的内部测试，而测试指的是内测后的公测，即完全交给最终用户测试。测试的主要依据是<<系统需求规格说明书>>和验收标准。2.4功能测试和性能测试功能测试(functiontesting)：检查实际软件的功能是否符合用户需求。细分为多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。性能测试(performancetesting)：一般要用到自动化测试工具。包括一般性能测试、稳定性测试、负载测试和压力测试。一般性能测试指的是让被测试系统在正常的软硬件环境下运行的测试。稳定性测试，也叫可靠性测试，指连续运行被测系统，检查系统运行时的稳定程序。负载测试指让被测系统在其能忍受的压力的极限范围内连续运行，为测试系统的稳定性。与稳定性测试的区别在于负载测试需要给被测系统施加其刚好能承受的压力，为我们测试系统在临界状态下运行是否稳定提供了一种方法。压力测试指持续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。黑盒测试技术主要包括等价类技术、边界值技术、因果图技术、业务流程图技术白盒测试技术根据是否运行源代码，白盒测试又可分为：静态测试和动态技术。实用的动态测试技术包括:边界值、逻辑驱动覆盖、路径图法等。4.1边界值：数据类型的边界值、数组的边界值、分支判断语句的边界值(1)数据类型的边界值：32760+8=32768吗？#include<stdio.h>main(){shortintx=32760;shortinty=8;shortintz=x+y;printf("%d”,z);数组的边界值：数组上下越界问题#include<stdio.h>main(){inti,pos[2];for(i=0;i<=2;i++)scanf("%d”,&pos[i]);//输入数组2个元素for(i=1;i<2;i++)printf("%d”,pos[i]);//打印数组2个元素}4.2逻辑驱动覆盖：是一种传统的白盒测试技术，专门用来测试程序中的分支结构和循环结构。分支结构的测试又包括语句覆盖、分支覆盖、条件覆盖、分支-条件覆盖、条件组合覆盖及路径覆盖等方法。语句覆盖测试：指设计若干测试用例，使得程序中的每条语句至少执行一次。虽然能够执行所有的语句，但不能覆盖所有的分支，是最弱的逻辑驱动覆盖。分支覆盖测试：也叫判定覆盖测试，是指设计若干测试用例，使得程序中每个分支的取真分支和取假分支至少各执行一次。条件覆盖测试：条件覆盖是选取足够多的测试数据，使被测试程序中不仅每条语句至少执行一次，而且每个判定表达式中的每个条件都取到各种可能的结果。分支-条件覆盖测试：选取足够多的测试数据，使得程序中每个分支的取真分支和取假分支至少各执行一次，而且每个判定表达式中的每个条件都取到各种可能的结果。条件组合覆盖测试：选取足够多的测试数据，使得判定表达式中条件的各种可能组合都至少出现一次。路径覆盖测试：选取足够多的测试数据，使得程序的每条可能路径都至少执行一次。Tag标签：软件测试，黑盒测试，白盒测试，单元测试，集成测试，系统测试本文来自CSDN博客，转载请标明出处：/lovehuahui/archive/2009/11/21/4840715.aspx单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。黑盒测试黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：1）功能错误或遗漏；2）界面错误；3）数据结构或外部数据库访问错误；）性能错误；）初始化和终止错误。白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：1） 如何测试功能的有效性？2） 何种类型的输入会产生好的测试用例？3） 系统是否对特定的输入值尤其敏感？4） 如何分隔数据类的边界？5） 系统能够承受何种数据率和数据量？6） 特定类型的数据组合会对系统产生何种影响？运用黑盒测试方法，可以导出满足以下标准的测试用例集：1） 所设计的测试用例能够减少达到合理测试所需的附加测试用例数；2） 所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。白盒测试RexBlack白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：1） 保证一个模块中的所有独立路径至少被使用一次；2） 对所有逻辑值均需测试true和false；3） 在上下边界及可操作范围内运行所有循环；4） 检查内部数据结构以确保其有效性。“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？”答案在于软件自身的缺陷：1、 逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。2、 我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。3、 笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。正如Beizer所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它。GUI测试RogerS.Pressman图形用户界面（GUI）对软件测试提出了有趣的挑战，因为GUI开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时，GUI的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在GUI设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见GUI测试的指南：窗口：-窗口是否基于相关的输入和菜单命令适当地打开？-窗口能否改变大小、移动和滚动？-窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？-当被覆盖并重新调用后，窗口能否正确地再生？-需要时能否使用所有窗口相关的功能？-所有窗口相关的功能是可操作的吗？-是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？-显示多个窗口时，窗口的名称是否被适当地表示？•活动窗口是否被适当地加亮？-如果使用多任务，是否所有的窗口被实时更新？•多次或不正确按鼠标是否会导致无法预料的副作用？•窗口的声音和颜色提示和窗口的操作顺序是否符合需求？•窗口是否正确地被关闭？下拉式菜单和鼠标操作：•菜单条是否显示在合适的语境中？•应用程序的菜单条是否显示系统相关的特性（如时钟显示）？•下拉式操作能正确工作吗？•菜单、调色板和工具条是否工作正确？•是否适当地列出了所有的菜单功能和下拉式子功能？•是否可以通过鼠标访问所有的菜单功能？•文本字体、大小和格式是否正确？•是否能够用其他的文本命令激活每个菜单功能？•菜单功能是否随当前的窗口操作加亮或变灰？•菜