软件测试复习

软件测试技术与项目管理复习课程目标本课程是计算机或软件专业课程，重在培养我们的实践能力，适应软件企业的工作环境和业界标准，并和国际先进的软件开发理念和测试技术保持同步。通过本课程的学习，了解并掌握软件产品质量保证的基本思想和科学体系、软件测试技术的基本内容，以及软件测试的方法、技术和工具的使用，为全面掌握软件技术和软件项目管理打下坚实的基础

1.1软件测试的必要性1.2为什么要进行软件测试？1.3什么是软件测试？1.4软件测试与软件开发的关系1.5测试驱动开发的思想第一章引论软件的含义？1.1软件测试的必要性能够完成预定功能和性能的、可执行的指令(计算机程序)；使得程序能够适当地操作信息的数据结构；描述程序的操作和使用的文档。软件=程序+数据（库）+文档+服务软件的特点：

软件是逻辑的、知识性的产品集合，是对物理世界的一种抽象，或者是某种物理形态的虚拟化。

软件是硬件的灵魂，硬件是软件的基础软件，是智慧和知识的结晶软件不会“磨损”，而是逐步完善

.

软件产品可能毫无缺陷吗？1.1软件测试的必要性缺乏管理的软件的失控状态

1.1软件测试的必要性1.1.1迪斯尼并不总是带来笑声1.1.2一个缺陷造成了数亿美元损失1.1.3火星探测飞船坠毁1.1.4更多的悲剧1.1软件测试的必要性软件质量事故原因分析：迪斯尼并不总是带来笑声一个缺陷造成了数亿美元损失火星探测飞船坠毁千年虫、冲击波…………发生原因：测试不完备，没有足够测试。发生原因：对待缺陷的态度有问题，不重视测试报告发生原因：测试团队合作有问题，集成测试所需要的测试用例不完备发生原因：开发人员开发程序时使用“后门”或者逻辑缺陷为什么要进行软件测试?软件总存在缺陷。只有通过测试，才可以发现软件缺陷。也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。软件中存在的缺陷给我们带来的损失是巨大的，这也说明了软件测试的必要性和重要性测试是所有工程学科的基本组成单元，自然也是软件开发的重要组成部分。

测试人员水平越高，找到软件问题的时间就越早，软件就越容易更正，产品发布之后越稳定，公司赚的钱也越多，微软就是一个典型的例子。1.3什么是软件测试？1.3.1软件测试学科的形成1.3.2正反两方面的争辩1.3.3软件测试的定义1.3.4软件测试的其它观点正确的定义验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体软件测试的其它观点软件测试被认为是对软件系统中潜在的各种风险进行评估的活动。基于风险的软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现问题、报告问题测试的经济观点就是以最小的代价获得最高的软件产品质量。经济观点也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。1.4软件测试和软件开发的关系让人误解的瀑布模型需求分析和定义系统设计详细功能设计编码单元测试功能测试系统测试验收测试测试用户需求验证系统非功能特性验证功能验证代码验证构建过程验证过程软件测试的必要性为什么进行软件测试？什么是软件测试？软件测试与软件开发的关系？小结软件测试方法和技术

第2版

第2章软件测试的基本概念第2章软件测试的基本概念2.1软件缺陷2.2验证和确认2.3软件测试的分类2.4测试阶段2.5软件测试的工作范畴2.1软件缺陷2.1.1软件质量的内涵2.1.2软件缺陷的定义2.1.3软件缺陷的产生2.1.4软件缺陷的构成2.1.5修复软件缺陷的代价软件质量

的内涵IEEE：

质量是系统、部件或过程满足明确需求客户或用户需要或期望的程度不同软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和(ISO8492)软件质量：软件产品满足 使用要求的程度

产品质量的标准-功能性

Functionality-可用性

Usability(简单安装;轻松使用;友好界面)-可靠性

Reliability(用户使用的根本)-性能

Performance-容量

Capacity-可测量性

Scalability-可维护性

Servicemanageability-兼容性

Compatibility-可扩展性

Extensibility

功能：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。

可靠：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。

易用：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。

效率：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。

可维护：与进行指定的修改所需的努力有关的一组属性。

可移植：与软件从一个环境转移到另一个环境的能力有关的一组属性。

其中每一个质量特征都分别与若干子特征相对应。软件质量特征

(ISO9126)什么是Bug?Anyproblem/disfigurement/limitationinproductdesign&development

Featureorfunctioncan’tworkUnreasonabledesignPartlyrealizationinfunctionDataerrorRunerrorLimitationinfeaturesDifferencebetweenactualresultsandexpectedresultsUnfriendlyUI,LowperformanceOthers2.1.2软件缺陷的定义任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求

软件缺陷IEEE(1983)729软件缺陷一个标准的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

软件缺陷的主要类型/现象：功能、特性没有实现或部分实现设计不合理，存在缺陷实际结果和预期结果不一致运行出错，包括运行中断、系统崩溃、界面混乱数据结果不正确、精度不够用户不能接受的其他问题，如存取时间过长、界面不美观软件缺陷的产生

技术问题算法错误，语法错误，计算和精度问题，接口参数传递不匹配团队工作误解、沟通不充分软件本身文档错误、用户使用场合(userscenario)，时间上不协调、或不一致性所带来的问题系统的自我恢复或数据的异地备份、灾难性恢复等问题软件缺陷构成

软件缺陷在不同阶段的分布在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现，而不能在需求分析一个阶段发现缺陷成本软件测试的原则所有测试的标准都是建立在用户需求之上。软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合。软件测试的原则（2）第三方进行测试会更客观，更有效。软件测试计划是做好软件测试工作的前提。测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）2.3软件测试的分类方法目标/特性单元测试系统测试验收测试性能测试强壮性测试功能测试白盒测试黑盒测试测试阶段或层次适用性测试可靠性测试集成测试安全性测试不同的分类按测试的对象或范围分类，如单元测试、文档测试、系统测试等按测试目的分类，如功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等根据测试过程中被测软件是否被执行，分为静态测试和动态测试根据是否针对系统的内部结构和具体实现算法来完成测试，可分为白盒测试和黑盒测试第3章软件测试的方法3.1白盒测试方法3.2黑盒测试方法3.3静态测试和动态测试3.4主动测试和被动测试3.5形式化测试方法3.6基于风险的测试3.7模糊测试方法3.8ALAC测试和随机测试方法方法论和具体方法从方法论看，更多体现了一种哲学的思想，例如辩证统一的方法，在测试中有许多对立统一体，如静态测试和动态测试、白盒测试和黑盒测试、自动化测试和手工测试等。软件测试的方法论来源于软件工程的方法论，例如有面向对象的开发方法，就有面向对象的测试方法；有敏捷方法，就有和敏捷方法对应的测试方法。黑盒子和白盒子功能测试数据驱动测试结构测试逻辑驱动测试

客户需求事件驱动输入输出静态的和动态的主持人作者记录员列席人员内审员技术专业人员用户代表不正式正式互审

走读审查会议运行程序自动测试和手工测试手工模拟用户操作3.1白盒测试方法3.1.1语句覆盖3.1.2判定覆盖3.1.3条件覆盖3.1.4判定条件覆盖3.1.5条件组合覆盖3.1.6路径覆盖3.1.7基本路径测试法白盒测试方法逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等基本路径测试：在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。3.1.1

语句覆盖语句覆盖法的基本思想是设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次如果是顺序结构，就是让测试从头执行到尾如果有分支、条件和循环，需要利用下面的方法，执行足够的测试覆盖全部语句3.1.2

判定覆盖判定覆盖法的基本思想是设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。一个判定往往代表着程序的一个分支，

所以判定覆盖也被称为分支覆盖。3.1.3

条件覆盖条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。对于第一个判定条件M，可以分割如下：条件a>0：取真（TRUE）时为T1，取假（FALSE）时为F1

条件b<0：取真（TRUE）时为T2，取假（FALSE）时为F2对于第二个判定条件N：条件a>1：取真（TRUE）时为T3，取假（FALSE）时为F3

条件c>1：取真（TRUE）时为T4，取假（FALSE）时为F43.1.4

判定条件覆盖判定-条件覆盖是判定和条件覆盖设计方法的交集，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次测试用例取值条件具体取值条件判定条件通过路径输入：a=2，b=1，c=6输出：a=2，b=1，c=5T1,T2T3,T4a>0,b>0,a>1，c>1M=.T.N=.T.P1（1-2-4）输入：a=-1，b=-2，c=-3输出：a=-1，b=-2，c=-5F1,F2F3,F4a<=0,b<=0,a<=1,c<=1M=.F.N=.F.P4（1-3-5）3.1.5

条件组合测试条件组合覆盖的基本思想是设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次3.1.6

路径测试顾名思义，路径覆盖就是设计所有的测试用例，来覆盖程序中的所有可能的执行路径。测试用例覆盖路径覆盖条件覆盖组合输入：a=2，b=1，c=6输出：a=2，b=1，c=5P1（1-2-4）T1，T2，T3，T41，5输入：a=1，b=1，c=-3输出：a=1，b=1，c=-2P2（1-2-5）T1，T2，F3，F41，8输入：a=2，b=-1，c=-2输出：a=2，b=-1，c=-2P3（1-3-4）T1，F2，T3，F42，6输入：a=-1，b=2，c=3输出：a=-1，b=2，c=6P3（1-3-4）F1，T2，F3，T43，7输入：a=-1，b=-2，c=-3输出：a=-1，b=-2，c=-5P4（1-3-5）F1，F2，F3，F44，83.1.7基本路径测试依据代码绘制流程图确定流程图的圈复杂度（cyclomaticcomplexity）确定线性独立路径的基本集合(basisset)设计测试用例覆盖每条基本路径控制流图控制流图是用来考察测试路径的有用工具。控制流图是程序控制结构的图形表示，实际上就是一种简化了的流程图。其基本元素是结点和控制流。图3显示了分别用程序流程图和控制流图来表示的程序基本控制结构。

…

…程序流程图和控制流图的对照图形

控制流图说明：（1）流程图中的一组顺序处理框，在控制流图中可以被映射成为一个单一结点，如图4；图4合并结点的控制流图（2）若判断中的条件表达式是复合条件时，需要改复合条件为一系列只有单个条件的判断，如图5；

图5分解为简单条件结点的控制流图A≥BQPA>BA=BQPP流程图的圈复杂度V(G)=区域数量(由节点、连线包围的区域，包括图形外部区域)V(G)=连线数量-节点数量+2V(G)=简单可预测节点数量+1圈复杂度（Cyclomaticcomplexity）:代码逻辑复杂度的

度量，提供了被测代码的路径数量。复杂度越高，出错的概率越大V(G)modules确定线性独立的路径集合

独立路径：

至少引入一系列新的处理语句或条件的任何路径

基本集：

由独立路径构成的集合

由基本集导出的测试用例，保证每行代码语句至少被执行一次基本集合不一定唯一目标:在循环内部及边界上执行测试循环测试－11.简单循环(迭代次数n)

完全跳过循环

只经过循环一次经过循环两次经过循环m（m<n）次

分别经过循环n-1,n,n+1次循环测试－22.嵌套（Nested）循环在最里面的循环完成前面所述的简单循环测试，同时设定外部循环的最小迭代次数逐步向外循环进行直到所有循环被测试循环测试－3其它非结构循环重新设计!3.串行连接的循环独立循环

可以分别看着简单循环测试依赖性循环可以看着是嵌套循环3.2黑盒测试方法3.2.1等价类划分法3.2.2边界值分析法3.2.3判定表方法3.2.4因果图法3.2.5正交试验法3.2.6功能图法3.2.7错误推测法3.2.1等价类划分方法将程序可能的输入数据分成若干个子集，从每个子集选取一个代表性的数据作为测试用例，等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的分为有效等价类和无效等价类。有效等价类是有意义的、合理的输入数据，可检查程序是否实现了规格说明中所规定的功能和性能。无效等价类与有效等价类的意义相反在分析需求规格说明的基础上划分等价类，列出等价类表设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。经过正反的测试才能确保软件具有更高的可靠性。allinputsi1i4i2i3确定等价类的方法在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类inrangegreaterthanrangelessthanrangevaluegreaterthanvaluelessthanvalue在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类确定等价类的方法（2）notmemberofsetmemberofsetBooleanNon-Boolean确定等价类的方式(3)在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。根据等价类创建测试用例的步骤建立等价类表，列出所有划分出的等价类：为每个等价类规定一个唯一的编号；设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类重复c)，最后使得所有有效等价类均被测试用例所覆盖；设计一个新的测试用例，使其只覆盖一个无效等价类。重复e)使所有无效等价类均被覆盖。输入条件有效等价类无效等价类………………3.2.2边界值分析方法程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以发现不少程序缺陷。BVA–BoundaryValueAnalysis设计方法：确定边界情况（输入或输出等价类的边界）选取正好等于、刚刚大于或刚刚小于边界值作为测试数据确定边界值的方法如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。abab确定边界值的方法（2）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。TestcasesforABS(x):classx<0,arbitraryvalue: x=-10classx>=0,arbitraryvalue x=100classesx<0,x>=0,onboundary: x=0classesx<0,x>=0,belowandabove: x=-1,x=1一些特殊的边界值数值字符位置数量速度位置体积First/last，First-1/Last+1Min/Max，Min-1/max+1Star/Finish，Start-1/Finish+1Empty/FullLessthanempty/morethanfullSlower/FasterLargest/SmallestOver/Under，justOver/JustUnderShortest/Longest……3.2.3判定表方法在实际应用中，许多输入是由多个因素构成，而不是单一因素，这时就需要多因素组合分析。对于多因素，有时可以直接对输入条件进行组合设计，不需要进行因果分析，即直接采用判定表方法。一个判定表由“条件和活动”两部分组成，也就是列出了一个测试活动执行所需的条件组合，所有可能的条件组合定义了一系列的选择，而测试活动需要考虑每一个选择。判定表元素条件桩，列出问题的所有条件动作桩：列出可能针对问题所采取的操作条件项：针对所列条件的具体赋值动作项：列出在条件项（各种取值）组合情况下应该采取的动作。规则：任何一个条件组合的特定取值及其相应要执行的操作。判定表方法步骤列出所有的条件桩和动作桩；填入条件项；填入动作项，制定初始判定表；简化、合并相似规则或者相同动作3.2.4因果图法多种输入条件的组合，产生多种结果设计测试用例。设计方法：分析软件规格说明文档描述的哪些是原因（输入条件），哪些是结果（输出条件），给每个原因和结果赋予一个标示符。找出原因与结果，原因与原因之间的对应关系，划出因果图在因果图上标上哪些不可能发生的因果关系，表明约束或限制条件根据因果图，创建判定表，将复杂的逻辑关系和多种条件组合很具体明确的表示出来把判定表的每一行作为依据设计测试用例。为什么要采用正交试验法？打印范围分：全部、当前幻灯片、给定范围打印内容分：幻灯片、讲义、备注页、大纲视图打印颜色/灰度分:彩色、灰度、黑白打印效果分：幻灯片加框和幻灯片不加框。在许多应用系统的测试工作中，不会象判断三角形那样简单，输入条件的因素很多，而且每个因素也不能简单用“是”和“否”来回答。比如，微软Powerpoint程序的打印测试，也需要考虑4个因素，每个因素也有多个选项测试组合会变得很多，如果按照传统的测试方法，会导致很大的测试工作量

3.3静态测试和动态测试将需求和设计的评审也纳入测试的范畴，可以看作是广义测试静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。3.4主动测试和被动测试主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据.3.6基于风险的测试测试就是“对软件系统中潜在的各种风险进行评估的活动基于风险的测试是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做软件产品的风险度可以通过出错的影响程度和出现的概率来计算现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。是一种面向用户的软件测试方法，严格意义上来说属于黑盒测试，但是在实际的应用中多由流程图导出场景。扩展：场景分析法用例场景：是通过描述流经用例路径来确定的过程。这个流经过程要从用例开始到结束遍历其中所有的基本流和备选流。基本流：采用直黑线表示，是经过用例的最简单的路径。（无任何错，程序从开始直到执行到结束）备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入基本流中。（各种错误情况）扩展：场景分析法遵循图中每个经过用例的可能路径，可以确定以下用例场景：场景1：基本流场景2：基本流备选流1场景3：基本流备选流1备选流2场景4：基本流备选流3场景5：基本流备选流3备选流1场景6：基本流备选流3备选流1备选流2场景7：基本流备选流4场景8：基本流备选流3备选流4

扩展：场景分析法用场景分析法设计测试用例的步骤：根据说明，描述出程序的基本流及各项备选流；根据基本流和各项备选流生成不同的场景；对每一个场景生成相应的测试用例；对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值。扩展：场景分析法举例：用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这是需要使用账号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。第一步：确定基本流和备选流基本流：登录在线网站—>选择物品—>登录账号—>付款—>生成订单；备选流1：账户不存在备选流2：账户密码错误；备选流3：用户账户余额不足；备选流4：用户账户没钱。扩展：场景分析法第二步：根据基本流和备用流确定场景场景1（成功购物）：基本流；场景2（账户不存在）：基本流备选流1场景3（账户密码错误）：基本流备选流2场景4（账户余额不足）：基本流备选流3场景5（账户没钱）：基本流备选流4扩展：场景分析法第三步：对每一个场景生成测试用例扩展：场景分析法测试用例ID场景/条件账户密码账户余额预期结果1场景1：成功购物VVV成功购物2场景2：账户不存在In/an/a提示账号不存在3场景3：账户密码错误VIn/a提示账号密码错误，返回基本流步骤34场景4：账户余额不足VVI提示用户账户余额不足，请充值5场景5：账户没钱VVI提示用户账户没钱，请充值注：V（有效）：用于表明这个条件必须是有效的才可执行基本流；I（无效）：用于表明这种条件下将激活所需备选流；n/a（不适用）：表明这个条件不使用于测试用例第四步：设计测试数据扩展：场景分析法测试用例ID场景/条件账户密码账户余额预期结果1场景1：成功购物User11111800成功购物2场景2：账户不存在aan/an/a提示账号不存在3场景3：账户密码错误User1n/a提示账号密码错误，返回基本流步骤34场景4：账户余额不足User1111150提示用户账户余额不足，请充值5场景5：账户没钱User111110提示用户账户没钱，请充值

第5章单元测试在实际项目的测试过程中，我们会面对许多复杂的问题和具体的困难，不仅要采用前面所学的方法，还要拥有很好的技术，熟悉业务领域知识，深入系统架构、设计模式和开发框架，灵活运用测试工具，才能真正解决问题。第二篇软件测试的技术第5章单元测试第6章集成测试和系统测试第7章验收测试第8章面向对象软件的测试第9章基于应用服务器的测试第五章单元测试5.1什么是单元测试5.2单元测试的目标和任务5.3静态测试5.4驱动程序和桩程序5.5调试与评估5.6单元测试的管理5.7单元测试工具5.1什么是单元测试测试的4个阶段：单元测试集成测试系统测试验收测试按阶段进行测试是一种基本的测试策略单元测试的定义定义:单元测试是对软件基本组成单元进行的测试。时机:一般在代码完成后由开发人员完成,QA人员辅助.概念:模块,组件,单元

测试计划测试设计测试执行测试记录缺陷跟踪测试总结分析完毕目标:

单元模块被正确编码信息能否正确地流入和流出单元；在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。在为限制数据加工而设置的边界处，能否正确工作。单元的运行能否做到满足特定的逻辑覆盖。单元中发生了错误，其中的出错处理措施是否有效。5.2单元测试的目标和任务任务１：模块独立执行通路测试检查每一条独立执行路径的测试。保证每条语句被至少执行一次。Checklist:误解或用错了算符优先级。混合类型运算。变量初值错。精度不够。表达式符号错。其它任务2：模块局部数据结构测试检查局部数据结构完整性Checklist:不适合或不相容的类型说明。变量无初值。变量初始化或默认值有错。不正确的变量名或从来未被使用过。出现上溢或下溢和地址异常。其它任务３：模块接口测试检查模块接口是否正确，checklist:输入的实际参数与形式参数是否一致。个数、属性、量纲调用其他模块的实际参数与被调模块的形参是否一致。个数、属性、量纲全程变量的定义在各模块是否一致。外部输入、输出文件、缓冲区、错误处理其它任务４：模块边界条件测试检查临界数据处理的正确性Checklist:普通合法数据的处理。普通非法数据的处理。边界值内合法边界数据的处理。边界值外非法边界数据的处理。其它任务5：模块的各条错误处理通路测试预见、预设的各种出错处理是否正确有效。Checklist:输出的出错信息难以理解。记录的错误与实际不相符。程序定义的出错处理前系统已介入。异常处理不当。未提供足够的定位出错的信息。其它5.3静态测试技术的运用静态测试技术：不运行被测试程序，对代码通过检查、阅读进行分析。三步曲：走查（WalkThrough）。审查（Inspection）。评审（Review）编码的标准和规范标准：建立起来必须遵守的规则。规范：建议最佳做法，推荐更好方式。实施标准和规范的原因：可靠性。可读性和可维护性。可移植性。走查（WalkThrough）定义：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。注意：引导小组成员在走查前通读设计和编码。限时，避免跑题。发现问题适当记录，避免现场修改。检查要点是代码是否符合标准和规范，是否有逻辑错误。审查（Inspection）定义：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。注意：以会议形式，制定会议目标、流程和规则，结束后要编写报告。按缺陷检查表逐项检查。发现问题适当记录，避免现场修改。发现重大缺陷，改正后会议需要重开。检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。评审（Review）定义：通常在审查会后进行，审查小组根据记录和报告进行评估。注意：充分审查了所规定的代码，并且全部编码准则被遵守。审查中发现的错误已全部修改。5.4驱动程序和桩程序动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。白盒测试黑盒（灰盒）测试驱动程序和桩程序运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。5.5调试与评估调试与测试的对象及采用的方法有很大程度上的相似，调试还用到断点控制等排错方法，但其目的却完全不同。测试是为了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。软件单元功能与设计需求一致。

软件单元接口与设计需求一致。能够正确处理输入和运行中的错误。在单元测试中发现的错误已经得到修改并且通过了测试。达到了相关的覆盖率的要求。完成软件单元测试报告

第6章集成测试和系统测试第6章集成测试和系统测试6.1系统集成的模式与方法6.2功能测试6.3回归测试6.4非功能性测试6.1系统集成的模式与方法6.1.1集成测试前的准备6.1.2集成测试的模式6.1.3自顶向下和自底向上集成方法6.1.4大棒与三明治集成方法6.1.5持续集成6.1.1集成测试前的准备

人员安排

测试计划

测试内容

集成模式

测试方法6.1.2集成测试的模式渐增式测试模式与非渐增式测试模式非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。各自的优缺点自顶向下法(Top-downIntegration)

自顶向下法的主要优缺点自底向上法(Bottom-upIntegration)

自底向上法的主要优缺点混合策略(ModifiedTop-downIntegration)

混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合

6.1.4大棒集成方法(Big-bangIntegration)采用大棒集成方法,先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试。因为所有的模块一次集成的，所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用，适合在规模较小的应用系统中使用。三明治集成方法(SandwichIntegration)

采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是：在真正集成之前每一个独立的模块没有完全测试过。改善的三明治集成方法改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。6.1.5持续集成通常系统集成都会采用持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现Bug，避免集成中大量Bug涌现

而且容易定位Bug、修正Bug，最终提高软件开发的质量与效率6.2功能测试

目的和内容

程序安装、启动正常，有相应的提示框、错误提示等每项功能符合实际要求系统的界面清晰、美观菜单、按钮操作正常、灵活，能处理一些异常操作能接受正确的数据输入，对异常数据的输入有提示、容错处理等数据的输出结果准确，格式清晰，可以保存和读取功能逻辑清楚，符合使用者习惯系统的各种状态按照业务流程而变化，并保持稳定支持各种应用的环境能配合多种硬件周边设备软件升级后，能继续支持旧版本的数据与外部应用系统的接口有效功能测试的方法

等价类划分法边界值分析法错误推测法因果图法组合分析法我要测试所有的功能回归测试的目的所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；不影响软件原有功能的正确性。

回归测试的方法

再测试全部用例基于风险选择测试基于操作剖面选择测试再测试修改的部分6.3回归测试

回归测试的组织和实施6.4非功能性测试6.4.1性能测试 6.4.2压力测试6.4.3容量测试 6.4.4安全性测试6.4.5可靠性测试6.4.6容错性测试6.4.1性能测试

性能测试(Performancetest)通过测试以确定系统运行时的性能表现，如得到运行速度、响应时间、占有系统资源等方面的系统数据。性能测试目的和需求目的：

为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。性能测试需求：

用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）主要的性能指标：

服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间性能测试方法负载模拟

并发用户+思考时间+每次请求的数据量+负载模式性能测试步骤

确定性能测试需求根据测试需求，选择测试工具和开发相应的测试脚本建立性能测试负载模型，就是确定并发虚拟用户的数量、每次请求的数据量、思考时间、加载方式和持续加载的时间等执行性能测试结果分析，并提交性能测试报告性能测试的方法和技巧

两种负载类型“flat”测试ramp-up测试 对于企业级的系统，性能测试的方法主要有：基准测试性能规划测试渗入测试峰谷测试两种负载类型

“Flat”测试:

对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。虚拟用户的数量两种负载类型

Ramp-up测试:

用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。其优点是，可以看出随着系统负载的改变，测量值是如何改变的据此选择要运行的flat测试的范围。性能规划测试

性能规划类型的测试其目标是找出在特定的环境下，给定应用程序的性能可以达到何种程度。例如，如果要以5秒或更少的响应时间支持8,000个当前用户，需要多少个服务器？要确定系统的容量，需要考虑几个因素:用户中有多少是并发与服务器通信的。每个用户的请求间时间间隔是多少。渗入测试

渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。

建议运行两次测试——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。峰谷测试

兼有容量规划ramp-up测试和渗入测试的特征,目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。6.4.2压力测试压力测试(Stresstest)，也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。压力测试类型

并发性能测试（重点）疲劳强度测试大数据量测试在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。从本质上来说，测试者是想要破坏程序。并发性能测试考察客户端应用的性能，测试的入口是客户端并发性能测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发虚拟用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。ramp-up测试

疲劳强度测试通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。疲劳强度测试案例制定的原则是保证系统长期不间断运行的业务量，并且应该尽量去满足该条件。

Flat测试大数据量测试独立的数据量测试

针对某些系统存储、传输、统计、查询等业务进行大数据量测试

综合数据量测试

和压力性能测试、负载性能测试、并发性能测试、疲劳性能测试相结合的综合测试方案6.4.3容量测试

容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。安全性测试

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

想方设法截取或破译口令；专门开发软件来破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。6.4.5可靠性测试

可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。规定的时间

规定的环境条件规定的功能6.4.6容错性测试

容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面：输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。故障转移测试Failover测试:故障转移(Failover)和故障恢复(Failback).服务器的Failover测试的目的:检查系统是否具备某种灾难性恢复的手段.当系统局部或全部出错时,能否在指定时间内修正错误.具有良好故障恢复的系统,当遇到软件原因或无法克服的自然原因时,能够进行故障的转移与恢复.使用户最低限度的感受到故障的发生.在服务器的Failover测试中,将包括多种情况,如:客户机或服务器掉电;客户机与服务器网络中断;服务器相关的程序CRASH;系统中全部或部分CORESERVER出现掉电/网络中断情况.软件测试方法和技术

第2版

第7章验收测试第7章验收测试7.1验收测试的过程和主要内容7.2产品规格说明书的验证7.3用户界面和可用性测试7.4兼容性测试7.5可安装性和可恢复性测试7.6文档测试什么是验收测试验收测试(AcceptanceTest):在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段,也称为交付测试。

7.1验收测试的过程和主要内容前提:系统或软件产品已通过了系统测试的软件系统。测试内容: 验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容。验收标准和注意事项验收测试完成标准:完全执行了验收测试计划中的每个测试用例。在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待下一版本中修改。

完成软件验收测试报告。注意事项：必须编写正式的、单独的验收测试报告验收测试必须在实际用户运行环境中进行由用户和测试部门共同执行。如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行。7.3用户界面和可用性测试用户界面的7个要素:符合标准和规范。直观性。一致性。灵活性。舒适性。

正确性。实用性。易用性测试没有具体量化的指标，主观性较强。符合标准和规范通常标准是已经确立的，多数用户已经熟悉并接受了这些标准和规范、或已经认同了这些信息所代表的意义。例：如果软件在某一个平台上运行，就需要把该平台的标准和规范作为产品规格说明书的补充内容，在建立测试案例时和产品规格说明书一样作为依据

直观性和一致性直观性：-首先了解所需的功能或期待的响应应该明显，并在预期的地方出现。-其次要考虑用户界面的组织和布局是否合理。一致性：-包括软件本身的一致性，以及软件与其他软件的一致性。直观性例子灵活性用户喜欢可以灵活选择的软件，软件可以选择不同的状态和方式，完成相应的功能。但灵活性也可能发展为复杂性，太多的状态和方式的选择增加的不仅仅是用户理解和掌握的困难程度。多种状态之间的转换，增加了编程的难度，更增加了软件测试人员的工作量。例：舒适性、正确性、实用性舒适性：恰当的表现、合理的安排、必要的提示或更正能力等是要考虑的因素，包括容错处理和性能。正确性：

正确性的问题一般都很明显，比较容易发现。

实用性：

实用性不是指的是软件本身是否实用，而仅仅指的是具体特性是否实用。大型软件的开发或周期较长经过几次反复的软件开发中容易产生一些没有实用性的功能。

简单性

1-clickNextNextNext…7.4兼容性测试软件兼容性测试是指验证软件之间是否正确地交互和共享信息。

注意：从项目管理的角度出发，使平台清单在满足客户要求的前提下尽可能的小是十分重要的，否则将会给编码和测试带来巨大的工作量。

兼容性包括：硬件兼容。软件之间兼容。数据之间兼容。多版本的测试一个庞大而又艰巨的任务，需要对所有可能的软件组合等价分配，验证软件之间正确交互的最小有效集合。

通常我们的做法是：将软件分类。例如：字处理，电子表格，数据库，图形处理，游戏等。从每种类型中选择部分测试软件。按软件的流行程度选择较流行的软件。按年份，选取一定年份内的程序和版本。可安装性测试安装测试注意事项:是否需要专业人员安装。安装说明书有无对安装环境做限制和要求。过程是否简单、易掌握。过程中是否有明显的、合理的提示信息。是否会出现不可预见或不可修复的错误。安装程序是否占用系统资源与原系统冲突，是否会影响原系统安全性。软件安装的完整性和灵活性。许可证号码与注册号码的验证。升级安装后原有程序是否可正常运行。卸载测试。可恢复性测试

恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误或重新启动系统。

恢复测试首先要通过各种手段，让软件强制性地发生故障，然后验证系统是否能尽快恢复。

对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；

对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。验收测试报告和用户验收测试α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。验收测试报告，也称为发布报告（ReleaseReport）软件测试方法和技术

第2版

第8章面向对象软件的测试

第八章：面向对象软件的测试

8.1面向对象软件测试概述8.2面向对象的单元测试8.3面向对象的集成测试8.4基于客户角度的Java测试分层与增量

派生类D是C的子类，那么所有的用于C的基于规范的测试用例也都适用于D。引入术语“继承的测试用例”来代表从父类测试用例中选取出来的、用于子类的测试用例。可以通过增量变化分析来确定继承的测试用例中哪些在测试子类时必须执行、哪些可以不执行。

合理的分析，有利于找出更有价值的测试用例。

D的接口中添加新的操作，并且有可能是D中的一个新方法实现的新操作。新操作引入了新的功能/代码，这些都需要测试。在D中改变那些在C中声明的操作规范，需要为操作添加新的基于规范的测试用例。附加的测试用例提供了符合其前置条件的新输入，并且对由任何加强了的后置条件导致的新的期望结果进行检查。在D中覆盖那些在C中实现了某个操作并且被D继承了的方法，可以复用于该方法的所有继承来的基于规范的测试用例。在D中添加新的实例变量来实现更多的状态和/或属性，最有可能与新的操作和/或重载方法中代码有关，而且关系到对测试的处理。在D中改变类常量。类常量累计成每个测试用例的附加的后置条件。分层与增量

-测试用例选择8.2面向对象的单元测试类测试的方法通过代码检查或执行测试用例能有效地测试一个类的代码。面向对象的单元测试类测试的组成部分

作为每个类，决定是将其作为一个单元进行独立测试，还是以某种方式将其作为系统某个较大部分的一个组件进行独立测试，需要基于以下因素进行决策：这个类在系统中的作用，尤其是与之相关联的风险程度。这个类的复杂性（根据状态个数、操作个数以及关联其他类的程度等进行衡量）开发这个类测试驱动程序所需的工作量。面向对象的单元测试构建测试用例

从类说明中确定测试用例根据类实现引进的边界值来扩充附加的测试用例。

根据前置/后置条件来构建测试用例的总体思想是：为所有可能出现的组合情况确定测试用例需求。创建测试用例来表达这些需求、包括特定输入值（包括常见值和边界值），并确定它们的正确输出。增加测试用例来阐述违反前置条件所发生的情况。面向对象的单元测试类测试系列的充分性三个常用标准是基于状态的覆盖率，测试覆盖了多少个状态转换为依据。基于约束的覆盖率，有多少对前置/后置条件被覆盖来表示充分性。基于代码的覆盖率。当所有的测试用例都执行结束时，确定实现一个类的每一行代码或代码通过的每一条路径至少执行了一次8.3面向对象的集成测试主要是两个方面：类的线性测试，交互测试。类的独立性测试（跨平台）方面测试。面向对象的程序是由若干对象组成的，这些对象互相协作以解决某些问题。对象的协作方式决定了程序能做什么，从而决定了这个程序执行的正确性。因此，一个程序中对象的正确协作----即交互----对于程序的正确性是非常关键的。8.3面向对象的集成测试分布式对象测试中需要注意的情况

局部故障超时结构的动态性线程同步空指针保护8.4基于客户角度的Java测试格式化数据错误8.4基于客户角度的Java测试字符串或数组越界错误8.4基于客户角度的Java测试资源不合理使用8.4基于客户角度的Java测试不当使用synchronized导致系统性能下降8.4基于客户角度的Java测试调用不当方法导致结果出错方法重载与方法重用的混用，某个方法在主类中已有定义，但由于某种原因，需要重载父类中的方法，子类中这个重载的方法已做了定义。同名方法，分不清是方法重载还是方法重用，那么对于刚接触这个程序或者需要开发新功能的开发人员来说，可能会由于父类中此方法，而主观的认为子类中的方法是对父类方法的重写，这样就可能会出现错误的参数列表调用不当的方法。

8.4基于客户角度的Java测试解决方案：足够、清晰的注释软件测试方法和技术

第2版

第9章基于应用服务器的测试第9章基于应用服务器的测试9.1基于Web服务器应用的测试9.2基于数据库应用服务器的测试9.3基于JavaEE应用服务器的测试9.1基于Web服务器应用的测试9.1.1Web服务器功能测试 9.1.2Web安全性测试9.1.3Web性能测试9.1.4性能测试工具Flood常用的Web元素功能测试页面链接页面是否存在页面是否正确设计脚本不同的脚本语言相同的脚本语言在不同浏览器中的表现Web图形表单9.1.2

Web服务器的安全测试登录、身份验证超时、Cookie和Session输入验证（防止脚本语言)数据加密、SSL(安全套接字)SQL注入XSS日志文件目录9.1.3Web服务器的性能测试基于Web应用系统的在线用户和响应时间来度量系统性能，基于Web应用系统的吞吐量和响应时间来度量系统性能/benchmarks.html#webWeb服务器性能测试要点如何确定在线用户数量呢？由于时间和资源限制，不可能对Web应用系统的所有功能进行性能测试，而是根据业务的实际操作情况和技术的角度来分析，选择关键业务如果是基于在线用户的性能测试需求，可以将录制脚本时记录的思考时间作为基准，以此将思考时间设置成一定范围内的随机值。基于吞吐量的性能测试需求，可以把思考时间设置为零9.1.4性能测试工具FloodApacheHTTP工程包含了一个名为HTTPD-Test的子工程——Apache的通用测试工具包，它包含了不少测试工具而其中Flood（/test/flood/）是人们经常使用的一个Web性能测试工具具体操作安装设置Flood实例扩展9.2基于Web服务器应用的测试9.2.1数据库服务器性能测试9.2.2数据库并发控制测试9.2.1数据库服务器性能测试大数据量测试：10万、100万、千万条记录大容量测试：某些字段存储10M、100M、1G等大体积数据。

数据库服务器典型性能问题数据库服务器性能问题及原因分析

单一类型事务响应时间过长

数据库服务器负载

糟糕的数据库设计

事务粒度过大

批任务对普通用户性能的影响

并发处理能力差

锁冲突严重

资源锁定造成的数据库事务超时

数据库死锁

数据库服务器典型性能问题数据库性能问题的一般解决办法

监视性能相关数据；定位资源占用较大的事务并做出必要的优化或调整；定位锁冲突，修改锁冲突发生严重的应用逻辑；对规模较大的数据或者无法通过一般优化解决的锁冲突进行分布。9.2.2数据库并发控制测试数据库并发控制测试数据库并发能力:多个应用请求的并发处理过程.并发主要考虑的几个方面:数据丢失不可重复数据读脏数据数据库的锁并发测试的设计过程并发流程分析并发控制测试设计软件测试方法和技术

第2版

第12章组建测试队伍

Question

软件测试团队的任务是什么？测试团队在开发中所占的比重有多大？测试测试团队有哪些角色构成？如何组建一支新的测试团队？优秀软件测试工程师应具备什么样的素质？测试人员的职业发展方向在哪里？第12章组建测试队伍

12.l测试队伍的地位和责任12.2测试团队的构成12.3如何从零开始12.4测试团队的管理和发展12.5优秀软件测试工程师的必备素质12.1.1软件测试团队的任务发现软件程序、系统或产品中所有的问题；尽早地发现问题；督促开发人员尽快地解决程序中的缺陷；帮助项目管理人员制定合理的开发计划；并对问题进行分析、分类总结和跟踪帮助改善开发流程、提高产品开发效率；提高程序编写的规范性、易读性、可维护性等。软件测试和质量保证合二为一以开发为核心的组织模型

开发经理测试人员开发人员文档人员管理人员以项目经理为核心的组织模

项目经理测试组长开发组长文档人员以三国鼎立的组织模型

项目经理测试经理开发经理12.2测试团队的构成12.2.1测试团队的基本构成12.2.2测试人员的责任12.2.3测试团队的组织模型12.2.1测试团队的基本构成QA/测试经理：人员管理，资源调配、测试方法改进等；实验室管理人员：设置、配置和维护实验室的测试环境内审员：审查流程，建立测试模板，跟踪缺陷测试报告的质量等；测试组长：负责项目的管理、测试计划、测试用例、任务安排等；测试设计人员/资深测试工程师，产品设计规格说明书的审查、测试用例的设计、技术难题的解决、培训和指导、实际测试任务的执行；一般（初级）测试工程师，执行测试用例和相关的测试任务。按技术领域来组建团队

测试团队Web技术组Java技术Windows技术网络通讯组多媒体组项目组一项目组二项目组三按产品线来组建团队

测试团队产品B组产品F组产品A组项目一项目二项目三……项目一项目二项目一项目二项目三12.3.2优秀测试工程师的素质高度的责任感

非常好的沟通能力、幽默感技术能力、自信心、耐心

怀疑一切的精神、勤奋精神

洞察力、适度的好奇心

反向思维和发散思维能力、记忆力自我学习能力、创新能力等

第14章测试用例的设计

本章要解决的问题为什么我们要使用测试用例?测试用例有哪些基本元素组成?测试用例编写和设计时需要遵循哪些基本的原则?白盒测试用例和黑盒测试用例设计的基本方法测试用例设计，组织和测试过程组织之间的关系和实践过程。跟踪和维护测试用例。第14章软件测试用例的设计14.1测试用例构成及其设计14.2测试用例的组织和跟踪

14.1测试用例构成及其设计14.1.1测试用例的重要性14.1.2测试用例设计书写标准14.1.3测试用例设计考虑因素14.1.4测试用例设计的基本原则测试用例可以独立进行测试执行的最小单元测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例测试用例就是将软件测试的行为活动转化为规范化的文档什么是测试用例如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障

14.1.1测试用例的重要性标志符（Identification）测试项（TestItems）测试环境要求输入标准（InputCriteria）输出标准（OutputCriteria）测试用例之间的关联14.1.2测试用例设计书写标准测试用例的元素可以最大程度地找出软件隐藏的缺陷可以最高效率的找出软件缺陷可以最大程度地满足测试覆盖要求既不过分复杂、也不能过分简单使软件缺陷的表现可以清楚的判定测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了不包含重复的测试用例测试用例内容清晰、格式一致、分类组织良好测试用例的特征14.1.3测试用例设计考虑因素具有代表性、典型性寻求系统设计、功能设计的弱点测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分析怎样使得这样的错误或者异常能够发生考虑用户实际的诸多使用场景14.1.4测试用例设计的基本原则尽量避免含糊的测试用例尽量将具有相类似功能的测试用例抽象并归类尽量避免冗长和复杂的测试用例覆盖率。依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。易用性。测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的测试用例执行顺畅。易维护性。应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，也有助于易维护性。粒度适中。既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据输入的测试要求，提高测试用例的可维护性。整体测试用例的质量要求用例执行的跟踪:跟上进度？测试人员每天能执行多少个测试用例？“通过、未通过以及未测试的”各占多少？不能被执行的原因是什么？测试用例覆盖率的跟踪14.2.3跟踪测试用例软件测试方法和技术

-Ch.15报告所发现的软件缺陷

第十五章报告所发现的软件缺陷15.1软件缺陷的描述

15.1.1软件缺陷的基本描述15.1.2软件缺陷属性15.2软件缺陷相关的信息15.2.1软件缺陷的图片、记录信息15.2.2分离和再现软件缺陷15.3软件缺陷的处