软件测试

大连龙采正元信息技术有限公司软件测试基本概念测试术语失效（FAILURE）-指不完全符合给定的需求，实际结果或行为与期望结果或行为之间的偏差。-当缺陷执行时会发生失效-事故（INCIDENT）是警告用户注意所出现的失效缺陷（DEFECT/BUG）、故障（FAULT）-错误的结果/表现-缺陷屏蔽指一个故障会被系统的某个或某些故障所掩盖。错误（ERROR）、过错（MISTAKE）-人的错误导致缺陷-会扩散测试（TEST）-处理错误、缺陷、失效－目的是发现系统的失效，证明缺陷的存在。－采用测试用例执行被测对象的活动测试用例（TESTCASE）-输入：测试数据和操作步骤-输出：预期结果-测试环境：系统环境设置一个测试生命周期需求规格说明设计缺陷分类缺陷解决缺陷隔离测试编码错误错误错误错误修复事故缺陷缺陷缺陷软件缺陷•软件未达到产品描述标明的功能；•软件出现了产品描述指明不会出现的错误；•软件功能超出产品描述指明范围；•软件未达到产品描述虽未指出但应达到的目标；•软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。根据严重程度分类的缺陷1.轻微词语拼写错误2.中等误导或重复信息3.使人不悦被截断的名称，0.00美元账单4.影响使用有些交易没有处理5.严重丢失交易6.非常严重不正确的交易处理7.极为严重经常出现“非常严重”的错误8.无法忍受数据库破坏9.灾难性系统停机10.容易传染扩展到其他系统的系统停机PARETO原则PARETO原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。软件缺陷产生的主要原因需求分析系统设计编码其他软件缺陷产生的主要原因•用户和开发人员的沟通存在较大困难，对要开发的产品功能理解不一致；•由于软件尚未设计构造，完全靠想象去描述系统的实现结果，对系统特性不够清晰；•需求变化的不一致；•对需求规格说明书不够重视；•没有在整个开发团队中对需求规格说明书进行充分沟通。软件缺陷的修复成本020406080100需求设计编程测试发布成本软件测试员的目标•发现软件缺陷；•找出软件缺陷，尽可能早一点；•找出软件缺陷，尽可能早一点，并确保其得以修复。•以最少的时间和人力找出软件中潜在的各种错误和缺陷。软件测试的目的•基于不同的立场，存在着两种完全不同的测试目的。•从用户角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。•从软件开发人员角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的需求，确立人们对软件质量的信心软件测试的目的（2）•G.J.MYERS把软件测试的目的简单概括为：•软件测试是为了发现错误而执行程序的过程。•一个好的软件测试用例能够在第一时间发现程序中存在的错误。•一个好的测试是发现至今尚未发现的错误的测试。软件测试定义的诠释•使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差距。•简言之：软件测试就是为了发现错误而执行程序的过程。•换句话说，软件测试是是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入数据及预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。软件质量特性ISO9126•功能性：充分性、互操作性、正确性和安全性•可靠性：成熟度、故障容限、可恢复性•可用性：易懂易学、可操作、易接受、符合标准、惯例、风格向导或用户界面规定•效率•可维护性：可分析性、可变更性、稳定性以及易测性、•可移植性：适应性、易安装、一致性和可交换性软件测试的原则1应该尽早地和不断地进行软件测试；2测试用例应由测试输入条件和与之对应的预期输出结果组成，测试之前应根据测试要求正确选取需要执行的测试用例3程序员应该避免检查/测试自己的程序；4在设计测试用例时，应该包括合理的输入条件和不合理的输入条件；5充分注意程序测试中的群集现象（测试后程序中残余的错误数目与该程序已发现的错误数目成正比）；软件测试的原则（2）6严格执行测试计划，排除测试的随意性；7应对每一个测试结果做全面检查；8妥善保存测试计划、测试用例、出错统计和最终分析结果，为维护提供方便；9所有的测试应该追溯到用户需求；10测试应该从“小规模”开始，逐步向“大规模”即渐增式BUILD测试软件测试的对象•软件=程序+文档+服务•软件测试≠程序测试•软件测试应贯穿于软件开发的整个期间•需求分析、概要设计、详细设计以及编码各阶段所得到的文档.－需求规格说明书－概要设计说明书－详细设计说明书－源程序验证和确认（V&V）（1）•为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。•验证(VERIFICATION)，是指在软件生成的各个阶段保证软件正确地实现了某一特定功能的一系列活动，以及阶段间的逻辑协调性、完备性和正确性。（AREYOUBUILDINGTHEPRODUCTRIGHT?是否正确地构造软件？）验证和确认（V&V）（2）•有效性确认(VALIDATION)，是保证软件的实现满足用户需求的一系列的活动和过程。（AREYOUBUILDINGTHERIGHTPRODUCT?是否构造正确的软件？）•需求规格说明的确认•概要设计说明的确认•详细设计说明的确认•程序的确认(静态确认、动态确认)验证和确认（V&V）（3）V模型V模型•V模型：PAULROOK在20世纪80年代后期提出，最具有代表意义的测试模型，是软件开发瀑布模型的变体，反映了测试活动与分析和设计的关系。•两个特点：•展示了动态测试的全过程，并定义了动态测试与开发之间的关系。•动态测试的行为与开发过程的行为相对应，测试基础是对应开发阶段的文档。•三个缺点：•测试与开发文档之间很少有完美的一对一关系。•完全没有提及静态测试，忽略了代码审查、需求规格说明审查等重要的测试手段。•软件测试时间经常由于前期开发阶段进度的拖延而被挤占，甚至取消，从而使得测试质量得不到保证。W模型W模型•W模型：PAULHERZLICH在1993年提出，对V模型的改进，表明测试与开发的并行关系，充分体现测试贯穿于整个开发过程。•两个特点：•W是V的发展，强调测试应在整个开发周期进行。•W和V一样，开发行为与测试行为一一对应，但W并不主张动态测试必须要与开发阶段对应起来，W也不限制动态测试行为必须严格地基于开发行为产生的单一文档W模型•缺点：•在W模型中，需求、设计、编码等活动是串行的，测试和开发活动也保持一种线性的前后关系。只有上一个阶段完成之后，才能正式开始下一个阶段工作，从而无法支持迭代的开发模式。软件测试分类•按照测试技术划分：黑盒测试、白盒测试或静态测试、动态测试或人工测试、自动测试•按照开发阶段划分：单元测试、集成测试、确认测试、系统测试、验收测试•按照测试实施组织划分：开发方测试、用户测试、第三方测试软件测试方法•从测试是否针对系统的内部结构和具体实现算法的角度可以分为黒盒测试和白盒测试。•从测试是否需要执行被测软件的角度可以分为静态测试和动态测试。•从测试执行时是否需要人工干预的角度可以分为人工测试和自动测试。黒盒测试•这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。•黑盒测试又叫做功能性测试或数据驱动测试。IeInputtestdataOeOutputtestresultsSystemInputscausinganomalousbehaviourOutputswhichrevealthepresenceofdefects•黑盒测试在程序接口和用户界面进行测试，主要是为了发现以下错误:•是否有不正确或遗漏了的功能?•在接口上，能否正确接受输入数据，能否输出正确的结果?•是否有数据结构错误或外部信息(例如数据文件)访问错误?•性能上是否能够满足要求?•界面是否错误，是否不美观？•是否有初始化或终止性错误?白盒测试•此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。•通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构性测试或逻辑驱动测试。ComponentcodeTestoutputsTestdataDerivesTests白盒测试（2）•软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：•对程序模块的所有独立的执行路径至少测试一次；•对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；•在循环的边界和运行界限内执行循环体；•测试内部数据结构的有效性。静态测试•静态分析，对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行，采用人工检测和计算机辅助静态分析手段进行检测。•静态测试包括对各阶段的软件产品进行审查。动态测试•通过观察代码运行时的动作，来提供执行跟踪、测试覆盖率方面的信息。•通过有效的测试用例，对应的输入/输出关系来分析被测程序的运行情况。软件评审•30％－70％的缺陷是通过软件评审发现.•起源于20世纪50－60年代，由管理人员对文档进行的较简单的阅读和审批的质量控制实践.但是只抽查部分文档的评审不能引起开发人员对质量问题的深刻注意，故召集有关人员就文档开评审会议用于提高质量.1976年IBM开始采用软件评审方法，取得很好的效果.软件评审的优点•早发现错误早纠正，从而降低开发成本.•除了开发人员参加外，用户也要参与，这样可以兼容各家之长，从不同的视角考虑问题•发现的缺陷较显见，而软件测试是从迹象判断缺陷存在（实际输出与预期输出不符），再根据各种现象分析，才能判断造成缺陷的原因，这是一个困难的过程.•测试需对各个缺陷分别进行分析定位再纠正，而软件评审往往可以成批发现缺陷，同时也可以成批纠正缺陷，效率较高.•测试时发现缺陷，程序人员往往急于纠正，而不能冷静考虑修正方案，会导致错上加错.而软件评审在早期，软件开发人员往往能够从容对待，全面衡量选择修改方案.通用的评审过程•计划•概述•准备•评审会议•返工•跟踪低级审查•属性检查清单•完整、准确、精确、一致、贴切、合理、代码无关、可测试•术语检查清单•是否有绝对、肯定和切实认定的叙述，针对其设计用例•比较模糊的用语，某些、有时·····•功能清单是否有等等、诸如此类、依此类推，无法测试的词汇•在性能上不确定的说法•隐藏大量需要说明的功能•如果·····那么·····（没有否则）单元测试•对系统的最小单元模块或组件进行测试，在编码阶段进行，主要使用白盒测试方法，从程序的内部结构出发设计测试用例，检查模块或组件已实现的功能与定义的功能是否一致，编码是否存在错误。多个模块平行、独立地测试，•一般由编程人员和测试人员共同完成，除了采用动态测试方法之外，还会采取代码走查、静态分析等辅助手段。•是为了发现编码和详细设计阶段产生的错误。集成测试•在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目的是发现与接口有关的模块之间的问题。•集成方式（将模块组装起来形成一个可运行的系统）直接影响测试成本、测试计划、测试用例的设计、测试工具的选择等。常用的两种集成方式是一次性和增值式。•是为了发现概要设计阶段产生的错误。系统测试•软件最终要与系统中其他部分配套运行，将软件放在整个计算机环境中，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等。验收测试•验收测试是由用户通过试用系统而进行的测试。目的是从用户的角度实际操作运行软件系统而检验系统的可用性及与用户配合的程度。•经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，这时测试基本结束，将软件提交给用户。开发方测试•“验证测试”或“Α测试”•在软件开发环境下，由开发者检测与证实软件的实现是否满足设计说明或软件需求说明的要求。•在软件开发完成以后，开发方对要提交的软件进行全面