怎么做网站快捷方式,有没有在网上做ps赚钱的网站,亚马逊雨林女性部落,国内跨境电商公司排行榜个人总结#xff0c;仅供参考#xff0c;欢迎加好友一起讨论 文章目录 架构 - 系统测试与维护考点摘要软件测试软件测试 - 测试类型软件测试 - 静态测试软件测试 - 动态测试软件测试 - 测试阶段软件测试 - 测试阶段 - 单元测试软件测试 - 测试阶段 - 集成测试软件测试 - 测试… 个人总结仅供参考欢迎加好友一起讨论 文章目录 架构 - 系统测试与维护考点摘要软件测试软件测试 - 测试类型软件测试 - 静态测试软件测试 - 动态测试软件测试 - 测试阶段软件测试 - 测试阶段 - 单元测试软件测试 - 测试阶段 - 集成测试软件测试 - 测试阶段 - 系统测试软件测试 - 测试阶段 - 配置项测试软件测试 - 测试阶段 - 确认测试软件测试 - 测试阶段 - 回归测试软件测试 - 面向对象的测试软件测试 - 系统测试步骤软件调试系统转换计划 - 遗留系统演化策略系统转换计划 - 新旧系统的转换策略系统转换计划 - 数据转换和迁移系统运行与维护 架构 - 系统测试与维护
考点摘要
软件测试概念★★测试方法及阶段★★★★软件开发环境与工具★可维护性因素★★维护类型★★
第二版架构新教材里将测试的部分内容放到了对应第5.4节内容也筛减了不少内容测试用例方面的内容和维护阶段的内容都筛减了但是个人觉得还是把这块内容列出一篇进行单独梳理也许论文会出现测试和维护的方向论文题目。
软件测试
尽早、不断的进行测试程序员避免测试自己设计的程序既要选择有效、合理的数据,也要选择无效、不合理的数据修改后应进行回归测试尚未发现的错误数量与该程序已发现错误数成正比
软件测试 - 测试类型 这里个人认为只需要关注什么类型和具体分类即可详细细节无需掌握 软件测试 - 静态测试
桌前检查由程序员检查自己编写的程序。程序员在程序通过编译之后进行单元测试设计之前对源程序代码进行分析和检验并补充相关的文档目的是发现程序中的错误。检查项目包括检查变量的交叉引用表检查标号的交叉引用表检查子程序、宏、函数等值性检查常量检查标准检查风格检查比较控制流选择、激活路径对照程序的规格说明详细阅读源代码补充文档。由于程序员熟悉自己的程序和自身的程序设计风格这种桌前检查可以节省很多检查时间但应避免主观片面性。代码审查代码审查是由若干程序员和测试人员组成一个会审小组通过阅读、讨论和争议对程序进行静态分析的过程。代码走查代码走查与代码审查基本相同但开会的程序与代码会审不同不是简单地读程序和对照错误检查单进行检查而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例提交给走查小组。走查小组开会集体扮演计算机角色让测试用例沿程序的逻辑运行一遍随时记录程序的踪迹供分析和讨论使用。
软件测试 - 动态测试 白盒测试
白盒测试也称为结构测试主要用于软件单元测试阶段。它的主要思想是将程序看作是一个透明的白盒测试人员完全清楚程序的结构和处理算法按照程序内部逻辑结构设计测试用例检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。
控制流测试控制流测试根据程序的内部逻辑结构设计测试用例常用的技术是逻辑覆盖即使用测试数据运行被测程序考察对程序逻辑的覆盖程度。主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。 ① 语句覆盖。语句覆盖是指选择足够多的测试用例使得运行这些测试用例时被测程序的每个语句至少执行一次。很显然语句覆盖是一种很弱的覆盖标准。 ② 判定覆盖。判定覆盖也称为分支覆盖它是指不仅每个语句至少执行一次而且每个判定的每种可能的结果分支都至少执行一次。判定覆盖比语句覆盖强但对程序逻辑的覆盖程度仍然不高。 ③ 条件覆盖。条件覆盖是指不仅每个语句至少执行一次而且使判定表达式中的每个条件都取得各种可能的结果。条件覆盖不一定包含判定覆盖判定覆盖也不一定包含条件覆盖。 判定覆盖只关心判定表达式的值真/假而条件覆盖涉及到判定表达式的每个条件的值真/假。 ④ 条件/判定覆盖。同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是选取足够的测试用例使得判定表达式中每个条件的所有可能结果至少出现一次而且每个判定本身的所有可能结果也至少出现一次。 ⑤ 条件组合覆盖。条件组合覆盖是指选取足够的测试用例使得每个判定表达式中条件结果的所有可能组合至少出现一次。显然满足条件组合覆盖的测试用例也一定满足判定/条件覆盖。因此条件组合覆盖是上述5种覆盖标准中最强的一种。然而条件组合覆盖还不能保证程序中所有可能的路径都至少遍历一次。 ⑥ 修正的条件/判定覆盖。修正的条件/判定覆盖需要足够的测试用例来确定各个条件能够影响到包含的判定结果。首先每个程序模块的入口和出口点都要考虑至少要被调用一次每个程序的判定到所有可能的结果值至少需要转换一次其次程序的判定被分解为通过逻辑操作符and和or连接的布尔条件每个条件对于判定的结果值是独立的。 ⑦ 路径覆盖。路径覆盖是指选取足够的测试用例使得程序的每条可能执行到的路径都至少经过一次如果程序中有环路则要求每条环路路径至少经过一次。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合并不能代替条件覆盖和条件组合覆盖。数据流测试数据流测试使用控制流程图对变量的定义和引用进行分析可以发现的错误包括引用未定义的变量、未曾使用的定义、对未使用变量再次赋值、数组越界或条件判断中的条件错误、不正常的程序执行路径、不可执行的代码等。 进行数据流测试通常首先将程序流程图转换成控制流图在每个链路上标注对有关变量的数据操作的操作符号或符号序列然后选定数据流测试策略根据测试策略得到测试路径最后根据测试路径确定测试用例。程序变异测试程序变异测试是一种错误驱动测试是针对某类特定程序错误的测试。经过多年的测试理论研究和软件测试的实践人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决办法是将错误的搜索范围尽可能地缩小以利于专门测试某类错误是否存在。错误驱动测试主要有两种即程序强变异和程序弱变异。 程序变异测试方法有排错能力强和自动化程度高等优点但它也存在两大弱点。一是要运行所有的变异体从而成倍地提高了测试的成本开销大二是决定程序与其变异体是否等价是一个不可判定的命题。
黑盒测试
黑盒测试也称为功能测试主要用于集成测试、确认测试和系统测试阶段。黑盒测试将软件看作是一个不透明的黑盒完全不考虑或不了解程序的内部结构和处理算法而只检查软件功能是否能按照SRS的要求正常使用软件是否能适当地接收输入数据并产生正确的输出信息软件运行过程中能否保持外部信息例如文件和数据库等的完整性等。
黑盒测试根据SRS需求规格说明书所规定的功能来设计测试用例一般包括功能分解、等价类划分、边界值分析、判定表、因果图、状态图、随机测试、错误推测和正交试验法等。
功能分解功能分解是将SRS中的每个功能加以分解确保各个功能被全面测试。首先使用程序设计中的功能抽象方法把程序分解为功能单元然后使用数据抽象方法产生测试每个功能单元的数据。 功能抽象是将程序看成一种抽象的功能层次每个层次可标识被测试的功能层次结构中的某一功能由下一层功能定义。按照功能层次进行分解可以得到众多的最低层次的子功能并以这些子功能为对象设计测试用例在数据抽象中数据结构可以由抽象数据类型的层次图来描述每个抽象数据类型有其取值集合。程序的每个输入和输出的取值集合用数据抽象来描述。等价类划分在设计测试用例时等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合对于一个等价类中的输入值来说它们揭示程序错误的作用是等效的。也就是说如果等价类中的一个输入数据能检测出一个错误那么等价类中的其他输入数据也能检测出同一个错误反之如果等价类中的一个输入数据不能检测出某个错误那么等价类中的其他输入数据也不能检测出这一错误除非这个等价类的某个子集还属于另一个等价类。边界值分析经验表明软件在处理边界情况时最容易出错。设计一些测试用例使软件恰好运行在边界附近暴露出软件错误的可能性会更大一些。通常每一个等价类的边界都应该着重测试选取的测试数据应该恰好等于、稍小于或稍大于边界值。例如对于条件“10 x 30”的测试可以选取x的值为91030和31作为测试数据。 在实际测试工作中将等价类划分法和边界值分析法结合使用能更有效地发现软件中的错误。判定表判定表最适合描述在多个逻辑条件取值的组合所构成的复杂情况下分别要执行哪些不同的动作。 某商店业务处理系统中基本加工“检查订货单”的描述为:若订货单金额大于 5000 元 且欠款时间超过 60 天则不予批准若订货单金额大于 5000 元,且欠款时间不超过 60 天 则发出批准书和发货单若订货单金额小于或等于 5000 元则发出批准书和发货单若欠款时间超过 60 天则还要发催款通知书。因果图因果图法根据输入条件与输出结果之间的因果关系来设计测试用例它首先检查输入条件的各种组合情况并找出输出结果对输入条件的依赖关系然后为每种输出条件的组合设计测试用例。状态图一个程序的功能说明通常由静态说明和动态说明组成。前者描述输入条件与输出条件之间的对应关系后者描述输入数据的次序或迁移的次序。逻辑功能模型适合于描述静态说明该模型中输出数据仅由输入数据决定。但对于较复杂的程序由于存在大量的组合情况仅根据静态的逻辑功能模型设计测试用例往往是不够的。在状态图中由输入数据和当前状态共同决定输出数据和后续状态。根据状态图设计测试用例可以弥补静态逻辑功能模型的不足。随机测试随机测试是指测试输入数据是在所有可能输入值中随机选取的测试人员只需规定输入变量的取值区间在需要时提供必要的变换机制使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难多用于可靠性测试和系统强度测试中。错误推测使用等价类划分和边界值分析技术有助于设计出具有代表性的、容易暴露软件错误的测试方案。但是不同类型的软件通常有一些特殊的容易出错的地方。错误推测法主要依靠测试人员的经验和直觉从各种可能的测试用例中选出一些最可能引起程序出错的用例。正交实验法正交实验法是从大量的实验点中挑出适量的、有代表性的点应用正交表合理地安排实验的一种设计方法。利用正交实验法设计测试用例时首先要根据被测软件的SRS找出影响功能实现的操作对象和外部因素并将其当作因子而把各个因子的取值当作状态生成二元的因素分析表。然后利用正交表进行各因子的状态组合构造有效的测试输入数据集并由此建立因果图。这样得出的测试用例数目将大大减少。
灰盒测试
灰盒测试是一种介于白盒测试与黑盒测试之间的测试它关注输出对于输入的正确性。同时也关注内部表现但这种关注不像白盒测试那样详细且完整而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。灰盒测试结合了白盒测试和黑盒测试的要素考虑了用户端、特定的系统知识和操作环境在系统组件的协同性环境中评价应用软件的设计。
软件测试 - 测试阶段 单元测试模块测试模块功能、性能、接口等。集成测试模块间的接口。系统测试真实环境下验证完整的软件配置项能否和系统正确连接。确认测试验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试验收测试。回归测试测试软件变更之后,变更部分的正确性对变更需求的符合性。
软件测试 - 测试阶段 - 单元测试
单元测试又称为模块测试是针对软件设计的最小单位程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例多个模块可以平行地独立进行单元测试。
单元测试根据详细设计说明书包括模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试单元测试通常由开发人员自己负责。而由于通常程序模块不是单独存在的因此常常要借助驱动模块相当于用于测试模拟的主程序和桩模块子模块完成。单元测试的计划通常是在软件详细设计阶段完成的。
另外单元测试策略主要包括自顶向下的单元测试需要桩模块、自底向上的单元测试需要驱动模块、孤立测试和综合测试策略都需要。测试一个模块时可能需要为该模块编写一个驱动模块和若干个桩Stub模块。顶层模块测试时不需要驱动模块底层模块测试时不需要桩模块。 软件测试 - 测试阶段 - 集成测试
集成测试的目的是检查模块之间以及模块和已集成的软件之间的接口关系并验证已集成的软件是否符合设计要求。集成测试的技术依据是软件概要设计文档集成测试计划通常在软件概要设计阶段完成。除应满足一般的测试准入条件外进行集成测试前还应确认待测试的模块均已通过单元测试。
集成策略可分为非渐增式和渐增式两种。非渐增式集成测试也称大突击测试或一次性集成测试是先测试所有的模块然后一次性把所有模块集成到一起将程序作为一个整体来测试。这种测试方法的出发点是可以“一步到位”但测试人员面对众多的错误现象往往难以分清哪些是“真正的”错误哪些是由其他错误引起的“假性错误”诊断定位和改正错误也十分困难。
非渐增式一次性组装集成只适合于维护型项目即以前的产品已经很稳定只有极少数构件被修改或者软件规模非常小并经过了充分的单元测试或者项目采用严格的净室软件工程过程开发质量与单元测试质量非常高。
渐增式集成测试是将单元测试和集成测试合并到一起它根据模块结构图按某种次序选一个尚未测试的模块把它与已经测试好的模块组合在一起进行测试每次增加一个模块直到所有模块被集成在程序中。这种测试方法比较容易定位和改正错误在业界得到普遍采用。渐增式集成又可分为自顶向下集成和自底向上集成。自顶向下集成先测试上层模块再测试下层模块自底向上集成先测试下层模块再测试上层模块。
这两种集成方法各有利弊一种方法的优点恰好对应于另一种方法的缺点在实际测试工作中可灵活选用最适当的方法也可将两种方法混合使用。混合的增量式集成也称为三明治集成测试时将系统划分成三层先对最上面的一层使用自顶向下的集成对最下面的一层使用自底向上的集成最后在中间层会合。
软件测试 - 测试阶段 - 系统测试 系统测试的对象是完整的、集成的计算机系统系统测试的目的是在真实系统工作环境下验证完整的软件配置项能否和系统正确连接并满足系统/子系统设计文档和软件开发合同规定的要求。系统测试的技术依据是用户需求或开发合同除应满足一般测试的准入条件外在进行系统测试前还应确认被测系统的所有配置项已通过测试对需要固化运行的软件还应提供固件。
系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等其中最重要的工作是进行功能测试与性能测试。性能测试主要验证软件系统在承担一定负载的情况下所表现出来的特性是否符合客户的需要主要指标有响应时间、吞吐量、并发用户数和资源利用率等。
软件测试 - 测试阶段 - 配置项测试
配置项测试的对象是软件配置项配置项测试的目的是检验软件配置项与SRS的一致性。配置项测试的技术依据是SRS含接口需求规格说明。除应满足一般测试的准入条件外在进行配置项测试之前还应确认被测软件配置项已通过单元测试和集成测试。
软件测试 - 测试阶段 - 确认测试
确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度通常包括以下4种类型
内部确认测试。内部确认测试主要由软件开发组织内部按照SRS进行测试。Alpha测试和Beta测试。对于通用产品型的软件开发而言Alpha测试是指由用户在开发环境下进行测试通过Alpha测试以后的产品通常称为Alpha版Beta测试是指由用户在实际使用环境下进行测试通过Beta测试的产品通常称为Beta版。一般在通过Beta测试后才能把产品发布或交付给用户。验收测试。验收测试是指针对SRS在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是在真实的用户工作环境下检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外在进行验收测试之前应确认被测软件系统已通过系统测试。
软件测试 - 测试阶段 - 回归测试
回归测试的目的是测试软件变更之后变更部分的正确性和对变更需求的符合性以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
回归测试的对象主要包括以下4个方面
未通过软件单元测试的软件在变更之后应对其进行单元测试。未通过配置项测试的软件在变更之后首先应对变更的软件单元进行测试然后再进行相关的集成测试和配置项测试。未通过系统测试的软件在变更之后首先应对变更的软件单元进行测试然后再进行相关的集成测试、配置项测试和系统测试。因其他原因进行变更之后的软件单元也首先应对变更的软件进行单元测试然后再进行相关的软件测试。
软件测试 - 面向对象的测试
算法层单元测试包括等价类划分测试、组合功能测试基于判定表的测试、递归函数测试和多态消息测试。类层模块测试包括不变式边界测试、模态类测试和非模态类测试。模板层/类树层集成测试包括多态服务测试和展平测试。系统层系统测试
软件测试 - 系统测试步骤 软件调试
软件调试的方法
蛮力法主要思想是“通计算机找错”低效耗时。回溯法从出错处人工沿控制流程往回追踪直至发现出错的根源。复杂程序由于回溯路径多难以实施。原因排除法主要思想是演绎和归纳用二分法实现。
软件测试软件调试目的是找出存在的错误目的是定位错误并修改程序以修正错误从一个已知的条件开始使用预先定义的过程有预知结果从一个未知的条件开始结束的过程不可预计测试过程可以事先设计进度可以事先确定调试不能描述过程或持续时间
系统转换计划 - 遗留系统演化策略
遗留系统Legacy System是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。
对遗留系统评价的目的是为了获得对遗留系统的更好的理解这是遗留系统演化的基础是任何遗留系统演化项目的起点。主要评价方法包括度量系统技术水准、商业价值和与之关联的企业特征其结果作为选择处理策略的基础。 改造策略高水平、高价值区即遗留系统的技术含量较高本身还有极大的生命力。系统具有较高的业务价值基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短称这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求对遗留系统本身不做改变数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。继承策略低水平、高价值区即遗留系统的技术含量较低已经满足企业运作的功能或性能要求但具有较高的商业价值目前企业的业务尚紧密依赖该系统。称这种遗留系统的演化策略为继承。在开发新系统时需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性新老系统必须并行运行一段时间再逐渐切换到新系统上运行。集成策略高水平、低价值区即遗留系统的技术含量较高但其业务价值较低可能只完成某个部门或子公司的业务管理。这种系统在各自的局部领域里工作良好但对于整个企业来说存在多个这样的系统不同的系统基于不同的平台、不同的数据模型形成了一个个信息孤岛对这种遗留系统的演化策略为集成。淘汰策略低水平、低价值区即遗留系统的技术含量较低且具有较低的业务价值。对这种遗留系统的演化策略为淘汰即全面重新开发新的系统以代替遗留系统。完全淘汰是一种极端性策略一般是企业的业务产生了根本变化遗留系统已经基本上不再适应企业运作的需要或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价发现将遗留系统完全淘汰开发全新的系统比改造旧系统从成本上考虑更合算。
系统转换计划 - 新旧系统的转换策略 在实施新旧系统转换时转换的策略通常有三种
直接转换策略适用于新系统不太复杂或现有系统完全不能使用的场合新系统在转换之前必须经过详细而严格的测试。并行转换策略新系统和现有系统并行工作一段时间经过这段时间的试运行后再用新系统正式替换下现有系统。分段转换策略分段转换策略也称为逐步转换策略这种转换方式是直接转换方式和并行转换方式的结合采取分期分批逐步转换。一般比较大的系统采用这种方式较为适宜它能保证平稳运行费用也不太高或者现有系统比较稳定能够适应自身业务发展需要或新旧系统转换风险很大例如在线订票系统、银行的中间业务系统等也可以采用分段转换策略。分段转换策略的优点是新旧系统的转换震动比较小用户容易接受。但由于是采用渐进方式导致新旧系统的转换周期过长同时由于需求的变化给新系统的稳定造成比较大的影响。而且分段转换策略对系统的设计和实现都有一定的要求在转换过程中需要开发新旧系统之间的接口还需要制订阶段性的转换目标和计划。
系统转换计划 - 数据转换和迁移
数据迁移的主要方法大致有三种分别是系统切换前通过工具迁移、系统切换前采用手工录入和系统切换后通过新系统生成。 数据迁移的实施可以分为三个阶段分别是数据迁移前的准备、数据转换与迁移和数据迁移后的校验。其中准备工作要做好以下7个方面的工作
待迁移数据源的详细说明包括数据的存放方式、数据量和数据的时间跨度。建立新旧系统数据库的数据字典对现有系统的历史数据进行质量分析以及新旧系统数据结构的差异分析。新旧系统代码数据的差异分析。建立新旧系统数据库表的映射关系对无法映射字段的处理方法。开发或购买、部署ETL工具。编写数据转换的测试计划和校验程序。制定数据转换的应急措施。
在数据迁移完成后需要对迁移后的数据进行校验。数据迁移后的校验是对迁移质量的检查同时数据校验的结果也是判断新系统能否正式启用的重要依据。可以通过以下两种方式对迁移后的数据进行校验
对迁移后的数据进行质量分析。新旧系统查询数据对比检查。
系统运行与维护
软件的维护并不只是修正错误为了满足用户提出的增加新功能修改现有功能以及一般性的改进要求和建议需要进行完善性维护他是软件维护的重要组成部分。
改正性维护也称正确性维护指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误【修正bug、错误】。适应性维护指使应用软件适应环境变化【外部环境、数据环境】而进行的修改。完善性维护扩充功能和改善性能而进行的修改。预防性维护为了适应未来的软硬件环境的变化应主动增加预防性的新的功能,以使系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能以适应将来报表格式的变化。
软件测试不可能揭露旧系统中所有潜在的错误所以这些程序在使用过程中还可能发生错误诊断和更正这些错误的过程称为改正性维护。
为了改进软件未来的可维护性或可靠性或者给未来的改进提供更好的基础而对软件进行修改这类活动称为预防性维护。
被动调整是适应性维护。
为了更好的适应而进行的主动调整是预防性维护。
增加功能改进某某功能改善某某算法就是完善性维护。
重构代码改善代码通用性是使系统的适应性更强它属于预防性维护。
