软件测试技术知识点整理39198.pdf

-一、软件测试的定义 软件测试是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。1软件测试与调试的区别？1测试是为了发现软件中存在的错误；调试是为证明软件开发的正确性。2测试以条件开场，使用预先定义的程序，且有预知的结果，不可预见的仅是程序是否通过测试；调试一般是以不可知的部条件开场，除统计性调试外，结果是不可预见的。3测试是有方案的，需要进展测试设计；调试是不受时间约束的。4测试经历发现错误、改正错误、重新测试的过程；调试是一个推理过程。5 测试的执行是有规程的；调试的执行往往要求开发人员进展必要推理以至知觉的飞跃。6测试经常是由独立的测试组在不了解软件设计的条件下完成的；调试必须由了解详细设计的开发人员完成。7大多数测试的执行和设计可以由工具支持；调式时，开发人员能利用的工具主要是调试器。2对软件测试的理解？软件测试就是说要去根据客户的要求完善它.即要把这个软件还没有符合的或者是和客户要求不一样的，或者是客户要求还没有完全到达要求的局部找出来。1首先要锻炼自己软件测试能力，包括需求的分析能力，提取能力，逻辑化思想能力，即就是给你一个系统的时候，能够把整个业务流程很清晰的理出。2学习测试理论知识并与你锻炼的能力相结合。3想和做。想就是说你看到任何的系统都要有习惯性的思考；做就是把实际去做练习，然后提取经历。总结测试用例，测试方案固然重要，但能力和思想一旦到位了，才能成为一名合格的软件测试工程师。二、软件测试的分类 1按照测试技术划分 1白盒测试：通过对程序部构造的分析、检测来寻找问题。检查是否所有的构造及逻辑都是正确的，检查软件部动作是否按照设计说明的规定正常进展。-构造测试 2黑盒测试：通过软件的外部表现来发现错误，是在程序界面处进展测试，只是检查是否按照需求规格说明书的规定正常实现。-性能测试 3灰盒测试：介于白盒测试与黑盒测试之间的测试。-2按照是否让备测软件运行划分 1静态测试 2动态测试 3按照开发阶段划分 1单元测试：模块测试，检查每个程序单元嫩否正确实现详细设计说明中的模块功能等。2集成测试：组装测试，将所有的程序模块进展有序、递增的测试，检验程序单元或部件的接口关系 3系统测试：检查完整的程序系统能否和系统包括硬件、外设和网络、系统软件、支持平台等正确配置、连接，并满足用户需求。4确认测试：证实软件是否满足特定于其用途的需求，是否满足软件需求说明书的规定。5验收测试：按工程任务或合同，供需双方签订的验收依据文档进展的对整个系统的测试与评审，决定是否承受或拒收系统。4按照测试实施组织划分 1开发方测试 2用户测试 3第三方测试 三、软件测试的原则 1测试用例中一个必需局部是对预期输出或结果的定义；2程序员应当防止测试自己编写的程序；3编写软件的组织不应当测试自己编写的程序；4应该彻底检查每个测试的执行结果；5测试用例的编写不仅应当根据有效和预期的输入情况，也应当根据无效和未预料到的输入情况；6检查程序是否未做其应该做的仅是测试的一半，测试的另一半是检查程序是否做了不应该做的；7应防止测试用例用后既弃，除非软件本身就是一个一次性的软件；8方案测试工作时不应默许假定不会发现错误；9程序*局部存在更多错误的可能性，与该局部已发现错误的数量成正比；10软件测试是一项极富创造性、极具智力挑战性的工作。-四、测试用例的设计 1测试用例的定义 1测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。2测试用例是执行的最小实体。2特征：1最有可能抓住错误的；2不是重复的、多余的；3一组相似测试用例中最有效的；4既不是太简单，也不是太复杂。3设计测试用例的根本准则 测试用例的代表性、测试结果的可判定性、测试结果的可再现性。五、黑盒测试 1等价类划分法 等价类划分法的设计方法：是把所有可能的输入数据，即程序的输入域划分成假设干局部 子集，然后从每一个子集中选取少量具有代表性的数据作为测试用例。等价类是指*个输入域的子集合。在该子集合中各个输入数据对于揭露程序中错误都是等效的。并合理地假定：测试*等价类的代表值就等于对这一类其他值的测试。有效等价类：对于程序的规格说明来说是合理的、有意义的输入数据构成的集合 无效等价类：对软件规格说明而言，是无意义的、不合理的输入数据所构成的集合 等价类对于测试有两个重要的意义：完备性无冗余性 等价类划分法的原则 a按照区间划分：一个有效等价类和两个无效等价类。b按照数值划分：n 个有效等价类和一个无效等价类 c按照数值集合划分一个有效等价类和一个无效等价类 d按照限制条件或规则划分：可确定一个有效等价类和假设干个无效等价类 e细分等价类 等价类划分法的步骤 a确定等价类 b建立等价类表，列出所有划分出的等价类-c从划分出的等价类中按以下的 3 个原则设计测试用例：为每一个等价类规定一个唯一的编号 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。确定等价类的方法 a先考虑输入数据的类型合法型和非法型；b再考虑数据围合法型中的合法区间和非法区间；c最后考虑输出结果，逆向设定输入。2边界值分析法 边界值分析法就是对输入或输出的边界值进展测试 特点：具有很强的发现程序错误的能力；测试用例来自等价类的边界；根本原理：故障往往发生在输入定义域和输出值域的边界上，而不是在其部。方法：a首先应确定边界情况.b选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据 标准边界值：min、min+、nom、ma*-、ma*强健边界值：min、min+、nom、ma*-、ma*min-ma*+例：对于一个含有 n 个变量的程序，只让其中一个变量取极值，让其余的变量取正常值，被保存的变量依次取 min、min+、nom、ma*-、ma*值，对每个变量都重复进展。n 个变量的程序，边界值分析测试程序会产生 4n+1 个测试用例。3决策表法 概述：决策表法是黑盒测试方法中最为严格、最具有逻辑性的测试方法。什么时候使用？程序输入输出比拟多，输入之间、输出之间相互制约的条件比拟多时，可以清楚地表达它们之间的各种复杂关系。决策表通常由四局部组成：规则 条件桩：列出问题的所有条件 条件项：针对条件桩给出的条件列出所有可能的取值 动作桩：给出问题规定的可能采取的操作 动作项：与条件项严密相关，指出在条件项的各组取值情况下应采取的动作 规则：项中的每一列是一条规则，每一条规则是一组测试用例。决策表的化简 a合并：如果一个条件项(表中*列中的条件值)和另外一个条件项所产生的动作是一样的,且两个条件项对应的每一行的值只有一个是不同的,则可以将其合并.合并的项除了不同值变成不关心条目外,其余不变 条件桩 条件项 动作桩 动作项 X Y abd有两个变量x、y的程序的输入域c-b包含：如果两个条件项的动作是一样的，对任意条件 1 的值和条件 2 中对应的值，如果满足：如果条件 1 的值是 T(F),则条件 2 中的值也是 T(F).如果条件 1 的值是-(不关心),则条件 2 中的值是 T,F,-,称条件 1 包含条件 2,条件 2可以撤去.重复 A,B 就可以得到精简的决策表.合并包含 构造决策表的步骤：a确定规则的个数；b列出所有的条件桩和动作桩；c填入输入项；d填入动作项,得到初始的决策表；e对初始的决策表化简。决策表测试法的适用围 aif-then-else 逻辑突出；b输入变量之间存在逻辑关系；c涉及输入变量子集的计算；d输入和输出之间存在因果关系。4因果图方法 概述：如果输入之间有关系，测试时必须考虑输入条件的各种组合，考虑适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。适合于检查程序输入条件的各种组合情况。因果图法的根本思想：首先从程序规格说明书的描述中,找出因(输入条件)和果(输出结果或者程序状态的改变),然后通过因果图转换为判定表,最后为判定表中的每一列设计一个测试用例.根本符号原因结果 通常在因果图中用 Ci 表示原因，用 Ei 表示结果，各结点表示状态，可取值0或1。0表示*状态不出现，1表示*状态出现。N N N Y Y N Y N Y N N Y Y N Y -恒等：c1 为 1,则 e1 也为 1,否则 e1 为 0.非：假设 c1 是 1,则 e1 为 0,否则 e1 是 1.或：假设 c1 或 c2 或 c3 是 1,则 e1 是 1,假设三者都不为 1,则 e1 为 0.与：假设 c1 和 c2 都是 1,则 e1 为 1,否则假设有其中一个不为 1,则 e1 为 0.约束：实际问题中,输入状态之间可能存在*些依赖关系.E 约束(异)：a,b 最多有一个可能为 1,不能同时为 1.I 约束(或)：a,b,c 中至少有一个必须为 1,不能同时为 0.O 约束(惟一)：a 和 b 必须有一个且仅有一个为 1 R 约束(要求)：a 是 1 时,b 必须是 1,即 a 为 1 时,b 不能为 0 M 约束：对输出条件的约束,假设结果 a 为 1,则结果 b 必须为 0.因果图生成测试用例的根本步骤 a找出原因和结果。b画出因果图。c增加约束。d把因果图转化为判定表，并化简。e把判定表的每一列拿出来作为依据，设计测试用例。例题 a原因：C1：第一个字符是 A；C2：第一个字符是 B；C3：第二个字符是一个数字字找。结果：E1：给出信息 L；E2：修改文件；E3：给出信息 M。b因果图。c决策表。1 2 3 4 5 6 7 8 C1 C2 C3 10 1 1 1 1 1 0 1 0 1 1 1 0 0 1 0 1 1 1 0 1 0 1 0 0 1 0 0 0 0 0 E1 E2 E3 不可能 测试用例 A3 A5 AM A&B3 B5 BM B*C2*6 CM D*d设计测试用例 测试用例 1：输入数据：A3 预期输出：修改文件 测试用例 2：输入数据：AM 预期输出：给出信息 M 测试用例 3：输入数据：B3 预期输出：修改文件 测试用例 4：输入数据：B*预期输出：给出信息 M 测试用例 5：输入数据：C2 预期输出：给出信息 L 测试用例 6：输入数据：CM 预期输出：给出信息 LM C2 c1-因果图法的优点：a考虑了多个输入之间的相互组合、相互制约关系；b能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题。六、白盒测试 1白盒测试概述：白盒测试也称构造测试或逻辑驱动测试。2方法：程序构造分析；逻辑覆盖测试；根本路径测试。3原则：1保证一个模块中所有独立路径至少被测试一次；2所有逻辑值均需测试真True和假False两种情况；3检查程序的部数据构造，保证其构造的有效性；4在取值上、下边界，即可操作围运行所有循环.4逻辑覆盖测试:主要是测试覆盖率，以程序在逻辑构造为根底的测试。6 种：语句覆盖判断覆盖条件覆盖判定-条件覆盖条件组合覆盖路径测试.语句覆盖：在测试时，首先设计假设干个测试用例，然后运行被测程序，使程序中的每个可执行语句至少执行一次。判定：整体控制。包括：a、单一条件判定；b、符合条件覆盖 语句覆盖率：已执行的可执行语句占程序中可执行语句总数的百分比 判定覆盖：设计足够多的测试用例，使程序中的每个判定至少都获得一次真值或假值。条件覆盖:构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。满足条件覆盖的不一定满足判定覆盖，反之亦然。两者无直接关系。判定/条件覆盖：设计足够的测试用例，使得判定中每个条件的所有可能(真/假)至少出现一次，并且每个判定本身的判定结果(真/假)也至少出现一次 组合条件覆盖MCC：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。满足组合条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定/条件覆盖。修正条件判定覆盖(MCDC)：需要足够的测试用例来确定各个条件能够影响到包含的判定的结果，即要求满足两个条件。七、静态测试 1静态测试不实际运行软件，主要对软件的编程格式、构造等方面进展评估。可以有人工进展，也可借助软件工具自动进展。2静态测试的方法 1代码检查：代码审查代码走查桌面检查同行评分略 2代码审查：通常由 4 人组成，其中一人是协调人，一人是程序的编写者，其他人员通常是程序的设计人员以及测试专家。优点和作用：错误列表、高效、会后修正、增加修改错误清单、较早发现错误。3代码走查：为测试员的人会带着一些书面的测试用例参加会议-4桌面检查：a完全没有约束b开发人员测试自己的程序c没有展示自己能力，缺乏良好的效应。效果远远逊于代码审查和代码走查 3静态构造分析：主要是以图形的方式表现程序的部构造。4代码质量度量：功能性可靠性可用性|有效性可维护性轻便性 八、单元测试 1单元测试的定义 单元测试又称模块测试，是最小单位的测试，其依据是详细设描述，对模块所有重要的控制路径设计测试用例，以便发现模块部的错误。单元测试多采用白盒测试技术 2单元测试的对象 构造化程序，单元测试的单元是指单个子程序、函数或过程 面向对象程序，单元测试的单元是指类或方法通常为类。3单元测试的目的 将模块的功能与定义模块的功能规格说明或接口规格说明进展比拟，提醒出模块与其规格说明之间存在的矛盾。4单元测试的人员:开发人员 5单元测试的针对的问题 1模块接口:检查进出程序单元的数据流是否正确。2局部数据构造:必须测试模块部的数据能否保持完整性。3边界条件测试：主要检查临界数据是否正确处理。4独立路径测试：发现由于不正确的判定或不正常的控制流而产生的错误。5出错处理：要求能预见出错的条件，并设置适当的处理对象，保证其路径的正确性。6单元测试的流程 方案单元测试设计单元测试执行单元测试评估单元测试 7.方案单元测试 1驱动模块(Drive)：用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。2 桩模块(Stub)：用来模拟被测模块工作过程中所调用的模块。它们一般只进展很少的数据处理。8设计单元测试 1需要的信息 模块的规格说明：模块的输入和输出以及模块的功能。模块的源代码。2测试用例的设计方法 模块测试总体上是面向白盒测试的静态、动态 后续测试针对较大的元素不易进展白盒测试。后续测试着眼于发现其他类型的错误，不一定与程序逻辑构造有关。使用一种或多种白盒测试方法分析模块的逻辑构造，然后使用黑盒测试方法对照模块的规格说明补充测试用例。9.执行单元测试 1设置测试环境 2将测试环境初始化-3执行测试过程。10.评估单元测试 1测试完备性评估 2)代码覆盖率评估 九、集成测试 1集成测试的定义 集成测试又称组装测试，集成测试是在单元测试的根底上，将所有模块按照设计要求组装成子系统或系统进展的测试活动。2集成测试的目的 确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，所测试的容包括单元间的接口以及集成后的功能。3集成测试的层次 1模块集成测试 2子系统集成测试 3子系统间集成测试 4集成测试的流程 5集成测试的方法 1静态测试：只要指对概要设计的测试。2动态测试：以黑盒测试为主，需要了解部细节时结合白盒测试 6集成测试策略 1非增量式集成：对所有模块进展个别的单元测试后，按照程序构造图将各模块连接起来，把连接后的程序当作一个整体进展测试。关键模块的特征：满足*些软件需求；在程序的模块构造中位于较高的层次高层控制模块；较复杂、较易发生错误；有明确定义的性能要求。2增量式集成：逐次将未曾集成测试的模块和已经集成测试的模块或子系统结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。方法：自顶向下增量式测试：深度优先、广度优先。自底向上增量式测试 混合增量式测试 7不同集成测试方法的比拟 十、系统测试 1系统测试的目的 将系统或程序与其初始目标进展比拟，这意味着系统测试并不局限于系统，系统测试是一个-试图说明程序作为一个整体是如何不满足其目标的过程。如果产品没有一组书面的、可度量的目标，系统测试也无法进展。2系统测试的类型 能力测试，容量测试，强度测试，易用性测试，平安性测试，性能测试，存储测试，配置测试，兼容性/配置/转换测试，安装测试，可靠性测试，可恢复性测试，适用性测试，文档测试，过程测试 1能力测试 判断目标文档提及的每一项能力以区别功能测试中的功能是否都确实已经实现。通常是通过人工检查目标文档中定义了要做什么。2容量测试 是程序经受大容量数据的检验，目的是证明程序不能处理目标文档中规定的数据容量。容量测试需要大量的资源，不可进展过多。如何使操作系统的作业队列到达饱和容量。3强度测试 使程序承受高负载或强度的检验。所谓高强度是指在很短的时间间隔到达的数据或操作的数量峰值。要与容量测试相区分 强度测试涉及时间因素，适用于在可变负载下运行的程序以及交互式程序、实时程序和过程控制程序。基于 Web 的应用程序也是最常承受强度测试的软件之一。如，1.在很短的时间是操作系统的作业队列到达峰值;2.web 应用程序要处理一定容量的并发用户。注：强度测试是对强度的界定很重要。4易用性测试 每个用户界面是否都根据用户的智力、教育程度和环境要求进展了调整？程序的输出是否有意义、不模糊且无计算机杂乱信息？错误诊断信息是否直接，非计算机专业用户是否能够理解这要求对错误进展准确的预测和详细的分类？整体的用户界面是否在语法、惯例、语义、格式、风格和缩写等方面展现出了相当程度的完整性、一致性和同一性？系统是否包含过多或不太可能用到的选项？对于所有输入，系统是否返回了即时确认信息？程序是否易于使用？如区分大小写的要求用户是否清楚，不同层次菜单之间的浏览是否容易等。5平安性测试 设计测试用例来突破程序平安检查。例如，可以设计测试用例来躲避操作系统的存保护机制、破坏数据库管理系统的数据平安机制等。常用的测试用例设计方法是研究类似系统中的平安问题，然后生成测试用例，暴露被测系统中的类似问题 基于 Web 的应用程序常常比绝大多数程序所需的平安测试级别更高，对于电子商务尤其如此。6性能测试 很多软件都有特定的性能或效率目标，这些特性描述为在特定负载和配置环境下程序的响应时间和吞吐率。应设计测试用例来说明程序不能满足其性能目标。7存储测试 软件偶尔会有存储目标，例如描述程序使用的存和辅存的容量以及临时文件或移出文件的-大小。应设计测试用例来证明这些存储目标没有得到满足。8配置测试 很多软件都支持多种硬件配置，可以运行在多种操作系统下，使用多种 web 浏览器。通常可能的配置数量非常之大，以至于无法全面测试，但应该尽可能测试各种配置。9兼容性/配置/转换测试 很多软件不是全新的，而是为了替换*些已有的系统。这样的软件往往涉及与已有系统的兼容以及从已有系统的转换过程，如升级数据库管理系统。10安装测试 有些软件的安装过程非常复杂，测试安装过程是系统测试的一个重要局部。11可靠性测试 所有测试都是为了提高软件的可靠性，但如果软件的目标中包含了对可靠性的特别描述，就必须设计专门的可靠性测试用例。12适用性测试 对于软件的适用性和可维护性目标也必须测试。13可恢复性测试 诸如 OS、DBMS 等软件通常都有可恢复性目标，说明系统如何从硬件失败和数据错误中恢复过来。系统测试的一个目标是证明这些恢复机制不能正确发挥作用。可以成心将程序错误植入个系统中，判断系统是否可以从中恢复。这些系统的设计目标之一是平均恢复时间MTTR最小，测试目标之一就是证明系统不能满足 MTTR 的要求。13文档测试 系统测试也需要检查用户文档的正确性和清晰性。14过程测试 很多软件系统不是完全自动化的，其中包括了很多人员操作过程。在系统测试中，必须对所有已规定的人工过程，如系统操作员、最终用户、数据库管理员的操作过程进展测试。十一、验收测试 是将程序与其最初的需求及最终用户当前的需要进展比拟的过程 通常是由程序的客户或最终用户来进展，一般不认为是软件开发机构的职责 最好的方法是设计测试用例，尽力证明程序没有满足合同要求；假设这些测试用例都通过了，就可以承受该程序。