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