软件测试总结(全)_软件测试工作总结
软件测试总结(全)由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“软件测试工作总结”。
软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。
测试的目的就是为了保证软件质量
使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
软件缺陷
软件缺陷是对软件产品预期属性的偏离现象 1.对产品规格说明的偏离
2.对用户期望的偏离，即用户要求未体现在产品中（可能是规格说明有疏漏，也可能是实现中的问题）
注意：软件缺陷不可能完全避免
软件质量
软件需求是衡量软件质量的基础
规定了的标准是软件开发必须遵循的准则
如果已开发的软件已经满足了那些明文规定的需求，却没有满足隐含的需求，软件产品的质量仍然是有问题的
测试目的测试是程序执行的过程，目的在于发现错误（缺陷）
好的测试用例能有效地发现别的测试用例未发现的错误（缺陷）成功的测试是发现了未曾发现的错误
确保软件的功能符合用户的需求，把尽可能多的问题在发布或交付前发现并改正： 确保软件完成了它所承诺或公布的功能 确保软件满足性能的要求
确保软件是健壮的和适应用户环境的
一些原则：
一个好的测试用例具有较高的发现过去未被发现过的错误的概率； 自己不能测试自己编写的程序；
对期望结果的描述是每个测试用例的必要组成部分； 杜绝不能重现或匆忙的测试；
既要编写使用有效输入条件的测试用例，也要编写使用非法输入条件的测试用例； 深入细致地审查测试结果 充分注意测试中的集群现象：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比；
让最优秀的人员去完成测试；
保证软件的可测试性是软件设计的一个重要目标； 不要为了测试方便而修改程序；
测试工作必须在任务建立之初就确定目标。Good-enough: 一种权衡投入/产出比的原则； 保证测试的覆盖程度，但穷举测试是不可能的； 所有的测试都应该追朔到用户需求；
越早测试越好，测试过程与开发过程应该是相结合的； 测试的规模由小而大，从单元测试到系统测试；
为了尽可能多的发现错误，应该由独立的第三方来测试； 不能为了便于测试修改程序
既应该测试软件该做什么，也应该测试软件不该做什么
测试方法
（1）测试方法分类：
根据软件测试的策略分类：
黑盒测试与白盒测试（功能性测试和结构性测试）,静态测试与动态测试,手工测试与自动测试
根据测试的阶段分类: 单元测试,集成测试,系统测试
（2）功能性测试和结构性测试 A、功能性测试 基本观点：任何程序都可以看作是将从输入定义域取值映射到输出值域的函数（工程中的黑盒）。
测试在软件的接口处进行，测试人员完全不考虑程序内部的逻辑结构和内部特征，只根据程序的需求规格说明书，检查程序的功能是否符合它的功能说明（也称“数据驱动测试”）。
黑盒测试一般为了发现以下几类错误： 是否有不正确或遗漏的功能？
在接口上，输入能否正确地接受？能否输出正确的结果？ 是否有数据结构错误或外部信息（如数据文件）访问错误？ 性能上是否能够满足要求？ 是否有初始化或终止行错误？ „„
常用方法：边界值分析，健壮性分析，最坏情况分析，特殊值测试，输入（输出）等价类，基于决策树的测试„„
功能性测试的优点：
功能性测试与软件如何实现无关，所以如果实现发生变化，测试用例仍然有效； 测试用例开发可以与实现并行，可以压缩总的项目开发时间。缺点：
测试用例的冗余
B 结构性测试
对软件的过程性细节做细致的检查，对所有的逻辑路径进行测试（也称逻辑驱动测试）。结构性测试一般对程序模块做如下的检查：
对程序模块的所有独立的执行路径至少测试一次；
对所有的逻辑判定，取“真”与“假”的情况都能至少测试一次； 在循环的边界和运行界限内执行循环体； 测试内部数据的有效性 „„
（3）功能性测试与结构性测试的比较 测试用例的基础：
功能性测试：需求规格说明
结构性测试：程序源代码（实现）两种方法单独使用都是不充分的如果所有已描述行为都没有被实现，结构性测试永远也发现不了； 如果程序实现了没有被描述的行为，功能性测试用也发现不了；
测试级别与功能性和结构性测试存在现实的关系： 结构性测试最适合在单元级别上进行； 功能性测试最适合在系统级别上进行；
完全测试程序是不可能的: 原因： 输入量太大 输出结果太多 软件实现途径太多
软件说明书没有客观标准
边界值分析 程序与函数: 程序的输入——定义域 程序的输出——值域 程序中变量的值域: 强类型语言 非强类型语言
边界值测试的基本原理: 错误更可能出现在输入变量的极值附近.单缺陷假设：失效极少由两个（或多个）缺陷的同时发生引起的。Min、min＋、nom、max-和max。
次边界条件：
有些边界条件在软件内部，最终用户几乎看不到，但是软件测试仍有必要检查。这样的边界条件称为次边界条件或者内部边界条件。如2的乘方和ASCⅡ。
边界值分析的特点和局限性
对于一n个变量函数，边界值分析会产生4n＋1个测试用例。边界值的取值取决于变量本身的性质。边界值分析对布尔变量没有什么意义。边界值分析假设变量是完全独立的。
边界值分析的问题 测试用例存在大量冗余 存在不完备现象 等价类测试
希望进行完备性测试 同时又希望避免冗余 等价类测试考虑的因素 单/多缺陷假设 健壮性
等价类划分：
把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。希望进行完备性测试 同时又希望避免冗余
等价类测试步骤
使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。（1）划分等价类
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。等价类的划分有两种不同的情况：
① 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。② 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。
(2）等价类测试--等价类划分原则 ①如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。
②如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。
③如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。④如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。
⑤如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
（3）等价类测试—选取测试用例 在确立了等价类之后，建立等价类表，列出所有划分出的等价类。再从划分出的等价类中按以下原则选择测试用例： ① 为每一个等价类规定一个唯一编号；
② 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；
③ 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
基于决策表的测试
在所有功能测试方法中，基于决策表的测试方法是最严格的，因为决策表具有逻辑严格性。
决策表很适合描述不同条件集合下采取行动的若干组合的情况。
决策表的组成条件桩：列出了问题的所有条件。
动作桩：列出了问题规定可能采取的操作。
条件项：列出针对它所列条件的取值，在所有可能情况下的真假值。动作项：列出在条件项的各种取值情况下应该采取的动作。规则：任何一个条件组合的特定取值及其相应要执行的操作。在决策表中贯穿条件项和动作项的一列就是一条规则。
功能性测试的选择规则
如果变量引用的是物理量，可采用定义域测试和等价类测试。如果变量是独立的，可采用定义域测试和等价类测试。如果变量不是独立的，可以采用决策表测试。
如果可保证是单缺陷假设，可以采用边界值分析和健壮性测试。
如果可保证是多缺陷假设，可采用最坏情况测试、健壮最坏测试和决策表测试。如果程序包含大量例外处理，可采用健壮性测试和决策表测试。如果变量引用的是逻辑量，可以采用等价类测试用例和决策表测试。
结构性测试 静态测试: 括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
检查项： * 代码风格和规则审核 * 程序设计和结构的审核 * 业务逻辑的审核
静态白盒测试是在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。好处：
尽早发现软件缺陷。
DD路径测试
该测试方法的突出特点，是它们都基于被测程序的源代码，而不是基于定义。由于这种绝对化的基础，结构性测试方法支持严格定义、数据分析和精确度量。
程序图 定义
给定一个采用命令式程序设计语言编写的程序，其程序图是一种有向图，其中：节点是程序语句，边表示控制流。从节点i到节点j有一条边，当且仅当对应节点j的语句可以立即在节点i对应的语句之后执行。
DD路径
决策到决策的路径（DD-路径）是指语句的一个序列，从决策语句的“出路”开始，到下一个决策语句的“入路”结束。在这种序列中没有内部分支，因此对应的节点像排列起来的一行多米诺骨牌，当第一块牌推倒后，序列中的其他牌也会倒下。
链是一条起始节点和终止节点不同的路径，并且每个节点都满足内度＝１、外度＝１。初始节点与链中的所有其他节点有２－连接，不会存在１－连接或３－连接。(P55, 4.2.6)有一种长度为０的退化链情况，即链有一个节点和０条边组成。
DD路径测试定义 定义
DD-路径是程序图中的一条链，使得：
情况1：由一个节点组成，内度=0。
情况2：由一个节点组成，外度=0。
情况3：由一个节点组成，内度≥2或外度≥2。
情况4：由一个节点组成，内度=1并且外度=1。
情况5：长度≥1的最大链。
对于给定的程序，可以使用多种不同的程序图，所有这些程序图都可以简化为惟一的DD-路径。
DD-路径图定义
给定采用命令式语言编写的一段程序，其DD-路径图是有向图。其中，节点表示其程序图的DD-路径，边表示连续DD-路径之间的控制流。
实际上DD-路径图是一种压缩图，在这种压缩图中，2-连接组件被压缩为对应情况5 DD-路径的单节点。
如果每条DD-路径都被遍历（C1指标），则我们知道每个判断分支都被执行，这要求遍历DD-路径图中的每一条边。
较长的DD-路径一般代表复杂计算，可以合理地认为是单独的函数。对于这样的DD-路径，应用多个功能性测试可能比较合适，尤其是边界值和特殊值。
DD-路径的依赖对偶
DD-路径对偶之间的最常见得依赖关系是定义/引用关系，其中变量在一个DD-路径中定义（接受值），在另一个DD-路径中引用。这种依赖关系的重要性在于，它们与不可行路径问题有关。
定义/使用测试覆盖指标
T是拥有变量集合V的程序P的程序图G（P)中的一个路径集合。定义
集合T满足程序P的全定义准则，当且仅当所有变量v∈V，T包含从v的每个定义节点到v的一个使用的定义清除路径。定义
集合T满足程序P的全使用准则，当且仅当所有变量v∈V，T包含从v的每个定义节点到v的所有使用，以及到所有USE（v,n）后续节点的定义清除路径。定义
集合T满足程序P全谓词使用/部分计算使用准则，当且仅当所有变量v∈V，T包含从v的每个定义节点到v的所有谓词使用的定义清除路径，并且如果v的一个定义没有谓词使用，则定义清除路径导致至少一个计算使用。定义
集合T满足程序P全计算使用/部分谓词使用准则，当且仅当所有变量v∈V，T包含从v的每个定义节点到v的所有计算使用的定义清除路径，并且如果v的一个定义没有计算使用，则定义清除路径导致至少一个谓词使用。定义
集合T满足程序P的全定义-使用路径准则，当且仅当所有变量v∈V，T包含从v的每个定义节点到v的所有使用，以及到所有USE（v,n）后续节点的定义清除路径，并且这些路径要么有一次的环经过，要么没有环路。
单元测试
单元测试时对软件基本组成单元进行的测试，这里的基本单元不一定是指一个具体的函数或一个类的方法。
单元具有一些基本属性，如：明确的功能、规格定义，与其他部分明确的接口定义等，可以清晰地与同一程序的其他部分单元划分开来。
单元测试的目的验证代码是与设计相符合的； 跟踪需求和设计的实现；
发现设计和需求中存在的错误； 发现在编码过程中引入的错误。
对单元测试的错误认识
单元测试浪费了太多的时间；
单元测试仅仅是证明这些代码做了什么； 很棒的编程人员的工作不需要单元测试； 不管怎样，集成测试将会抓住所有的bug； 单元测试的成本效率不高。
单元测试应坚持的原则
对全新的代码或修改过的代码进行单元测试； 对被测试单元需达到的一定的代码覆盖率要求； 当程序进行了修改，要进行回归测试。
集成测试
也叫做组装测试、联合测试、子系统测试和部件测试。是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，进行集成测试。
集成测试关注的重点
在把各个模块连接起来时，穿越模块接口的数据是否会丢失。各个子功能组合起来，能否达到预期要求的父功能。
一个模块的功能是否会对另一个模块的功能产生不利的影响。全局数据结构是否有问题，会不会被异常修改。
单个模块的误差积累起来，是否会放大，从而达到不可以接受的程度。
集成测试策略
功能分解法，调用图法，MM路径法
基于功能分解的集成测试：
自顶向下集成，自底向上集成，三明治集成，大爆炸集成
自顶向下集成自顶向下集成从主程序（树根）开始。所有被主程序调用的下层单元都作为“桩”出现，桩就是模拟被调用单元的一次性代码。
自底向上集成自底向上集成是自顶向下顺序的“镜像”，不同的是，桩由模拟功能分解树上一层单元的驱动器模块替代。需要编写驱动器。
三明治集成三明治是自顶向下和自底向上集成的组合。
桩和驱动器的开发工作都比较小，不过代价是有大爆炸的后果。
大爆炸集成这种方法最容易：这种集成将所有单元在一起编译并进行一次性测试。这种方法的缺点是，当发现缺陷时，没有多少线索能够用来帮助确定缺陷位置。
因果图是从用自然语言书写的程序规格说明的描述中找到因（输入条件）和果（输出或程序状态的改变），通过因果图转化为判别表。因果图方法最终生成的就是判定表。因果图的适用范围
如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
用因果图生成测试用例的基本步骤:(1)分析软件规格说明描述中，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。
(2)分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系? 根据这些关系，画出因果图。
(3)由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。(4)把因果图转换成判定表。
(5)把判定表的每一列拿出来作为依据，设计测试用例。
