软件工程-理论与实践（精装版）课件 13 软件测试、14 软件部署、15 软件维护与演化

软件测试内容软件测试概述软件测试的思想和原理软件测试的过程和策略软件测试的活动及实施的方法软件测试技术白盒和黑盒测试技术软件测试计划及输出测试计划制定及测试结果*示例：软件中存在缺陷，导致软件失效上传资源后资源数量没有变化查找以前上传的资源找不到示例：软件中存在缺陷，导致软件失效注册成功却无法登陆增加资源但没有显示......示例：软件需求中的潜在问题是否正确描述需求？是否一致描述需求？是否存在描述错误？示例：软件设计中的潜在问题是否正确实现需求？是否存在设计错误？示例：程序代码中的潜在问题是否正确实现功能？是否存在内在缺陷？需求和设计问题会带到代码中，编码时也会引入问题1.1软件缺陷的危害无法满足要求不能正常工作引发安全事故影响人员安全产生经济损失......尽可能减少软件缺陷非常重要1.2软件缺陷不可避免人总是会犯错误的软件工程师、用户等软件系统太复杂程序缺陷来自多个源头需求、设计、编码活动模型、文档、程序制品缺陷成常态化对于复杂软件系统而言缺陷不可避免很难做到无缺陷的软件你所使用的软件中是否发现有缺陷？思考和讨论如何应对软件缺陷？如何避免和减少缺陷？如何发现和修复缺陷？如何应对？能否不犯和少犯错误如何发现缺陷如何纠正缺陷……软件测试(SoftwareTesting)方法之一：找到软件缺陷，以排除缺陷1.3何为软件测试？运行软件或模拟软件的执行，发现软件缺陷的过程注意点软件测试通过运行程序代码的方式来发现程序代码中潜藏的缺陷，这和代码走查、静态分析形成鲜明对比。软件测试的目的是为了发现软件中的缺陷。它只负责发现缺陷，不负责修复和纠正缺陷在程序代码中找出软件缺陷程序是运行软件的载体通过执行代码运行软件通过软件运行发现缺陷程序是软件缺陷的载体缺陷分布在模型、文档和代码中最终会反映在程序代码上代码模型文档缺陷缺陷缺陷思考和讨论如何从程序代码中找出软件缺陷？1.4软件测试的原理程序本质上是对数据的处理设计数据(测试用例)

运行测试用例(程序来处理数据)

判断运行结果(是否符合预期结果)运行代码程序代码等测试数据结果评价预期结果软件缺陷为软件测试而设计的数据称为测试用例(TestCase)测试用例实际结果示例：软件测试的原理加法的功能A

=

B

+

C测试用例测试数据1,2预期结果3测试用例测试用例是一个四元偶输入数据：交由待测试程序代码进行处理的数据前置条件：程序处理输入数据的运行上下文，即要满足前置条件测试步骤：程序代码对输入数据的处理可能涉及到一系列的步骤，其中的某些步骤需要用户的进一步输入预期输出：程序代码的预期输出结果示例：测试用例的设计“用户登录”模块单元的测试用例设计输入数据：用户账号=“admin”，用户密码=“1234”前置条件：用户账号“admin”是一个尚未注册的非法账号，也即“T_User”表中没有名为“admin”的用户账号。测试步骤：首先清除“T_User”表中名为“admin”的用户账号；其次用户输入“admin”账号和“1234”密码；第三，用户点击界面的确认按钮；最后，系统提示“用户无法登录系统”的信息预期输出：系统将提示“用户无法登录系统”的提示信息1.5软件测试的任务软件测试待测试的程序代码测试用例软件缺陷报告，记录发现的软件缺陷软件测试任务2356417缺陷尽可能多找出软件中缺陷软件系统软件缺陷可能隐藏的比较深，难以发现采用这种方法能把软件中的所有缺陷都找出来吗？软件测试的目的目的发现软件中的缺陷最大限度、尽可能多的找到缺陷功效发现的缺陷越多

软件中遗留的缺陷越少

交付的软件质量越高

后期维护工作量就越少思考和讨论软件测试没有发现缺陷是否意味着软件就没有缺陷？为什么？软件测试能够用于证明软件无缺陷吗？1.6软件测试的步骤明确待测试对象什么粒度的程序代码设计测试用例

{<Data,Result>}可能有许多运行代码和测试用例输入和处理测试用例分析运行结果对比运行结果和预期结果，发现问题和缺陷示例:软件测试的步骤明确测试对象完成用户注册功能的程序模块（类）设计测试用例输入：UserID=xjmao,Psw=se预期：在数据库中有该用户密码的数据条目运行测试用例运行程序，输入数据分析运行结果用户数据库表中是否有该新用户的密码信息

1.7软件测试面临的主要挑战设计测试用例C1:如何设计有效的测试用例？提高软件测试的质量C2:如何确保测试用例的合理性：尽可能地发现缺陷？发现程序缺陷C3:如何运行程序和用例来发现缺陷？C4:如何采用工具来自动地发现缺陷：提高测试的效率？软件测试的前提和关键是要设计出有效的测试用例1.8软件测试工程师负责软件系统的测试工作，发现软件系统中的缺陷，协助软件开发工程师定位和修复缺陷服务于软件开发工程师，帮助他们理解和解决软件中的缺陷充当客户的技术代表，帮助客户发现软件中存在的各类问题，通过测试来演练客户验收内容软件测试概述软件测试的思想和原理软件测试的过程和策略软件测试的活动及实施的方法软件测试技术白盒和黑盒测试技术软件测试计划及输出测试计划制定及测试结果*思考和讨论软件缺陷会“潜伏”在程序代码的哪些地方？2.1程序构成及其缺陷的潜在位置程序模块程序模块程序模块程序模块程序模块程序模块程序模块内部程序模块接口程序模块间的交互整个软件系统发现和消除基本模块单元中缺陷2.2软件测试活动需求分析概要设计详细设计编码单元测试集成测试确认测试软件开发过程软件测试过程要对软件进行系统的测试2.3软件测试活动之间的关系单元测试单元测试集成测试确认测试其他测试(性能、安全、强度等)循序渐进、逐层递进地开展软件测试2.4软件测试过程制订软件测试计划调试修复回归测试评价测试有效性出现软件失效单元测试集成测试确认测试代码检查/走查评价测试效果2.4.1单元测试测试对象对软件基本模块单元进行测试过程、函数、方法、类测试方法大多采用白盒测试技术测试的内容模块接口测试模块局部数据结构测试模块独立执行路径测试模块错误处理通道测试模块边界条件测试在详细设计阶段就可以设计单元测试用例及计划单元测试的运行环境测试用例被测模块桩模块桩模块驱动程序测试结果产生测试用例执行测试程序生成测试报告<Data,

Result>……代码运行支撑2.4.2集成测试测试对象对软件模块之间的接口进行测试过程调用、函数调用、消息传递、远程过程调用测试技术采用黑盒测试技术集成测试的内容过程调用函数调用消息传递远程过程调用网络消息集成测试方法自顶向下集成深度优先或者广度优先的策略把各个模块进行组装和测试自底向上集成自底向上进行组装和测试M1M2M3M4M5M6M7M8M9M10在概要设计阶段就可以设计集成测试用例及计划自顶向下集成测试的过程以软件主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代依据集成策略(深度优先或广度优先)，每次只替代一个桩模块每集成一个模块立即测试一遍只有每组测试完成后，才着手替换下一个桩模块为避免修改引入新错误，须不断进行回归测试（即全部或部分地重复已做过的测试）从步骤（2）开始循环执行上述步骤，直至整个程序结构集成完毕自底向上集成测试的过程把低层模块集成起来形成实现某个子功能的模块群(cluster)开发一个测试用驱动模块，控制测试数据的输入和测试结果的输出对每个模块群进行测试删除测试使用的驱动模块，用实际开发的高层模块代替并形成能完成更大功能的新模块群从步骤（1）开始循环执行上述各步骤，直至整个程序集成完毕2.4.3确认测试测试对象对软件的功能和性能进行测试判断目标软件系统是否满足用户需求依据和标准软件需求规格说明书测试技术采用黑盒测试技术在需求分析阶段就可以设计确认测试用例及计划测试和测试测试软件开发公司组织内部人员模拟各类用户行为对即将面市的软件产品（称为α版本、内部测试版）进行测试，发现错误并修正尽可能逼真地模拟实际运行环境和用户对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式经α测试并进行修改后的软件产品称为β版本（也称外部测试版）

测试软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，或为对外进行宣传而将β版本免费赠送给典型用户（很多情况下，β版本可以通过Internet免费下载，也可以向软件公司索取），并要求用户报告异常情况、提出批评意见β测试是在与开发者无法控制的环境下进行的软件现场应用2.4.4面向对象软件测试OO软件的构成基础与传统结构化程序设计不同OO软件中数据和方法的隐藏与封装OO编程中存在继承、多态等多种机制OO开发过程和分析、设计的重点有所不同，并且关注于对象的交互与集成多视点的分析和设计模型、以及与代码之间存在的映射，使得尽早测试成为可能需要专门针对面向对象软件的测试方法类测试的前提需要开发测试驱动程序创建类实例、运行测试用例、向类实例（对象）发送消息根据响应的值、对象状态来判断是否有缺陷类方法的测试采用白盒测试方法类方法测试的过程Step1.设置测试消息的参数、全局变量为希望的取值Step2.设置被测对象为希望的状态（设置属性值）Step3.从测试驱动程序向被测对象实例发送测试消息Step4.测试检查（1）把被测方法返回值与期望值进行比较，若不同记录未通过（2）对被测对象的状态期望的进行比较，若不同记录未通过（3）捕获所有异常，假如是期望的异常，确定它是否正确。假如无异常或有一个不正确的异常，记录未通过（4）假如必要，对全局变量的结果与期望的值进行比较，若不同记录未通过Step5.假如发生任何未通过，则诊断和修正该问题交互测试的前提测试驱动程序实例化参与交互的类实例发送消息序列判断结果交互完成后的输出交互过程中各个对象的状态注意事项消息的内容、消息的次序正常的消息序列和不正常的消息序列继承的测试可以先测试父类，再测试子类重用父类的测试用例来进行子类的测试2.4.5非功能性测试性能测试强度测试配置和兼容性测试安全性测试可靠性测试用户界面测试本地化测试Web测试安装测试……在需求分析阶段就可以设计非功能测试用例及计划性能测试用例示例用例标识：KCZC-XN-1测试项：课程注册管理系统的性能能否支持同时有100个用户登陆使用。并且平均响应时间少于1.5秒。测试输入：由模拟软件模拟100个用户使用系统。前提条件：软件系统已经完成并且在服务器上安装成功。环境要求：使用1台服务器，配置为××××；使用5台微机作为客户机，配置为××××；模拟软件在客户机安装；网络通畅。测试步骤：(1)启动服务器系统；(2)由模拟软件在每个客户机分别依次发送20个用户登陆请求，并模拟选课过程；(3)监控程序把每个用户的请求和服务器响应过程、时间记录在日志中；(4)对记录结果进行处理，判断是否每个用户均获得成功的服务，并计算平均响应时间。预期输出：每个模拟用户都得到正确服务，且对请求的平均响应时间小于1.5秒。强度测试强度测试可被视为性能测试一部分性能测试是为测试软件系统在正常使用时是否能够达到一定性能指标强度测试则是对系统不断施加更大的压力和使用强度，确定系统瓶颈或者不能接受性能点，来获得系统能提供最大服务能力强度测试示例机票预订系统同时500个用户使用情况下正常运行属于性能测试把测试场景定为上千用户、甚至上万用户同时使用，那么就是一种强度测试了，以判断系统能够承受最大的强度是多少强度测试适用于在可变负载系统中运行的软件强度测试可与性能测试一起进行，但需对测试用例中定义的测试环境、条件、输入、步骤等内容进行调整，以适应强度测试安全性测试设计测试用例来暴露软件安全漏洞的过程如设法破坏数据库管理系统的数据安全机制、突破重要领域软件系统的用户访问控制等安全性测试的过程明确潜在的安全隐患，包括容易遭受攻击的内容、可能作为潜在入侵者的人员角色等明确潜在的入侵行为及时机，例如事务初始化、系统输入、执行存储和检索操作等时候列出每种潜在安全隐患可能遭到的入侵行为及其可能性确定风险较高的入侵点，这可通过对包括发生可能性、后果严重程度等因素进行分析得到根据风险的顺序，设计测试用例来实施安全性测试用户界面测试也称易用性测试，测试用户界面是否易于使用且具有较强实用性是否把常用的按钮或菜单项放在醒目的位置软件的输出是否清晰、有序错误信息是否直观和易于理解软件错误顺序是否符合用户的业务过程界面的风格是否一致Web测试基于Web软件利用浏览器通过超链接把各个网页联系在一起，满足用户对信息的获取需要测试大量的对象文本测试，对其中的术语、题目、内容素材、电子邮件地址、电话号码等信息的准确度、时效性方面进行检查，文字的拼写是否有误也要经常进行检查由于窗口缩放会引起文字段落改变，应测试是否会导致格式混乱测试超级链接测试图片和视频测试表单2.5软件测试的后续工作软件测试软件产品测试数据、工具测试评价预期结果软件调试缺陷修复软件缺陷修复后的软件测试是为了发现错误，从而跟错误信息来纠正错误，提高软件质量回归测试修改程序可能会引入新的错误原先“正常”的程序现在变得“不正常”回归测试目的验证软件新版本是否从正常状态回归/退化到不正常状态方法重新进行测试，再次运行所有的测试用例来发现缺陷回归测试最好能够自动化单元测试是回归测试的基础测试、调试和排错目的测试发现缺陷调试定位缺陷排错纠正错误独立性不同测试由独立的测试小组进行调试和排错由开发人员完成测试的重要性和特殊性软件测试是软件质量保证活动中关键步骤对SRS、设计规格说明书以及编码的最后复审其工作量往往占软件开发总工作量的40%以上确保软件质量的一种有效和可操作的重要手段软件测试有其特殊性和规律软件是逻辑产品软件有其复杂性2.6软件测试原则(1/2)测试应该有计划在开发初期就应制定测试计划，测试计划应该在测试之前就应该制定所有的测试都应该追溯到用户需求将Pareto原则应用于软件测试80%的错误都可以在大概20%的模块中找到根源测试应该从“微观”开始，逐步转向“宏观”穷举测试是不可能的每个测试用例都必须定义预期的输出或结果尽量避免程序的开发人员来测试他自己编写的代码尽量避免程序开发组织测试其自己开发的程序软件测试原则(2/2)应详细检查每次测试的结果。测试用例中不仅要说明合法有效的输入条件，还应该描述那些不期望的、非法的输入条件。检查一个程序没有完成希望它做的事情只是测试的一半任务，还应检查程序是否执行了不希望它做的事情。避免随意舍弃任何测试用例，即使非常简单的测试用例。不应在事先假设不会发现错误的情况下来制定测试计划。一个程序模块存在更多错误的可能性与该模块已经发现的错误数量成正比。测试是一个具有相当创新性和智力挑战的活动。内容软件测试概述软件测试的思想和原理软件测试的过程和策略软件测试的活动及实施的方法软件测试技术白盒和黑盒测试技术软件测试计划及输出测试计划制定及测试结果*思考和讨论如何来设计测试用例？要设计多少个测试用例？如何才能做到充分的软件测试？即通过设计足够多的测试用例来发现软件尽可能多的缺陷3.1程序单元测试测试对象-程序单元基本模块单元基本类方法、函数和过程测试内容-四个方面执行路径错误处理模块接口边界条件测试依据-设计文档程序流程程序单元是构成软件系统的基本要素，必须对其进行测试以发现缺陷程序单元测试的依据和对象测试依据：设计文档测试对象：模块代码程序模块功能、接口和流程示例：程序单元的设计描述-用户注册获取用户信息：ID和密码连接用户数据库分析用户ID合法性分析用户密码合法性将用户ID和密码信息写到数据库数字和字符组合不与已有的重复数字和字符组合不少于4个字符合法合法不合法不合法用流程图描述的软件设计示例：程序单元的设计描述-用户登录用流程图描述的软件详细设计信息3.2程序单元测试需要解决的问题如何设计测试用例？根据设计文档设计测试用例设计多少个测试用例测试用例的有效性：发现问题测试用例的简练性：不冗余，造成重复测试如何运行程序单元来发现缺陷？程序单元的运行程序单元对测试数据的处理根据什么来发现缺陷设计程序单元的测试用例运行程序单元和测试用例以发现缺陷3.3软件测试技术如何设计和运行测试用例白盒测试技术基于程序内部的执行流程来设计测试用例黑盒测试技术基于程序的外在功能和接口来设计测试用例程序功能盒子对应于基本模块单元（如类方法、函数、过程等），测试基本对象3.4软件测试技术-白盒测试设计测试用例思想根据程序单元内部工作流程来设计测试用例发现程序单元缺陷运行待测试的程序，检验程序是否按内部工作流程来运行的，如果不是则存在缺陷特点必须了解程序的内部工作流程才能设计测试用例模块内部流程白盒测试用例设计的指导原则如何设计测试用例？内部执行流程生成测试数据设计多少测试用例?遵循覆盖原则测试用例覆盖准则语句覆盖分支覆盖路径覆盖基本路径覆盖12367845语句覆盖分支覆盖路径覆盖基本路径覆盖基本路径测试的思想思想路径

基本路径

基本路径测试基本路径至少引入一个新语句或者新判断的程序通道前提软件模块的逻辑结构（流程图）据此可掌握模块的基本路径如何设计测试用例实现基本路径覆盖哪些基本路径

流图

流程图基本路径测试可实现基本路径的测试覆盖步骤1:根据程序逻辑画出流程图voidFunc(intnPosX,intnPosY){ while(nPosX>0){ intnSum=nPosX+nPosY; if(nSum>1){ nPosX减一;nPosY减一; } else{ if(nSum<-1)nPosX-=2; elsenPosX减四; } } //endofwhile}注意流程图的正确画法！软件模块设计细节示例：程序流程图获取用户信息：ID和密码连接用户数据库分析用户ID合法性分析用户密码合法性将用户ID和密码信息写到数据库数字和字符组合不与已有的重复数字和字符组合不少于4个字符合法合法不合法不合法用户注册模块的流程图步骤2:将流程图转换为流图(1/2)何为流图流图刻画程序控制结构但不涉及程序过程性细节节点形式过程块结合点判定点12,34,567891011注意流图正确画法！步骤2:将流程图转换为流图(2/2)判定点过程块结合点12,34,56789101110911流图中的判定点不应含复合条件否则按下列方式增加判定点abXYcXIfaorbThenXElseYEndIfFTFT步骤3:确定基本路径集合基本路径的数量流图Cyclomatic复杂度V(G)=E(dges)–N(odes)+2V(G)=11-9+2=41-111-2,3-6-7-9-10-1-111-2,3-4,5-10-1-111-2,3-6-8-9-10-1-1112,34,5678910114条基本路径步骤4:针对测试路径设计测试用例1-11nPosX取-1,nPosY取任意值1-2,3-4,5-10-1-11nPosX取1,nPosY取11-2,3-6-7-9-10-1–11nPosX取1,nPosY取-11-2,3-6-8-9-10-1-11nPosX取1,nPosY取-3voidFunc(intnPosX,intnPosY){ while(nPosX>0){ intnSum=nPosX+nPosY; if(nSum>1){ nPosX减一;nPosY减一; } else{ if(nSum<-1)nPosX-=2; elsenPosX减四; } } //endofwhile}12,34,567891011描述每一个测试用例用例标识：对该测试用例赋予一个唯一标识用例开发者：谁编写的本用例用例开发日期：编写用例的日期测试项：描述将被测试的具体特征、代码模块等对象测试输入：测试时为程序提供的输入数据前提条件：执行测试时系统应处于的状态或要满足的条件等环境要求：执行测试所需的软硬件环境、测试工具、人员等测试步骤：(1)…；（如点击“文件”菜单中的“新建”菜单项）(2)…；（如在“testcase”目录下选择“test5.dat”文件）……预期输出：希望程序运行得到的结果用例间的依赖性：该测试用例依赖或受影响的其它测试用例步骤5:运行程序检验测试用例运行待测试的程序代码逐个输入测试用例分析程序的运行路径如果运行路径与期望路径不一样，则存在缺陷程序单元测试的运行环境测试用例被测模块桩模块桩模块驱动程序测试结果产生测试用例执行测试程序生成测试报告<Data,

Result>……单元测试工具C/C++语言-C++Test、Cunit、CppTest.Net开发-NunitJava语言–JunitPython语言-

PyUnit3.5JUnitJUnit是一个Java语言的单元测试框架由KentBeck和ErichGamma建立开源软件JUnit的提出者1997年ErichGamma和KentBeck为Java语言创建了一个简单有效的单元测试框架ErichGamma《设计模式》作者之一KentBeck提出软件开发方法“极限编程”《重构:改善既有代码的设计》作者在Eclipse中使用JUnit建立一个被JUnit测试的类建立对应的JUnitTest类针对自动生成的代码进行修改执行测试用例3.5.1建立一个被JUnit测试的类被测试的程序单元：类方法addString（）被测试的对象3.5.2建立对应的JUnitTest类编写测试类类似于主控模块及桩模块Assert方法（测试用例预期输出）assertArrayEquals判断两个数组是否相等assertEquals判断两个对象是否相等assertFalse和assertTrue判断布尔变量是否为False或TrueassertNotNull和assertNull判断一个对象是否为空assertNotSame判断两个引用是否指向同一个对象Fail让测试用例失败用于判断预期结果与实际结果是否一致3.5.3针对自动生成的代码进行修改编写桩模块代码桩模块代码3.5.4测试用例执行通过GreenBarKeepthebargreentokeepthecodeclean测试用例执行失败JUnit的优势使测试代码与产品代码分开针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试开源软件，可以进行二次开发方便地对JUnit进行扩展与开发环境Eclipse相互集成3.6基于CASE的软件测试测试数据产生器运行测试程序产生测试报告谁负责开展程序单元测试？单元测试必须由最熟悉代码的人来写程序单元代码的编写者完成程序单元测试程序员必须保证自己编写程序的质量谁写的代码谁自己来负责单元测试单元测试的结果是什么？程序单元测试报告测试用例的设计程序单元的运行运行结果情况是否与预期相符一致谁负责撰写该报告程序员程序单元测试报告什么时候实施单元测试？根据设计文档，在程序代码编写之前设计测试用例程序单元测试计划程序代码写完之后开展程序单元测试设计测试用例、制定测试计划与实际开展测试可在不同的阶段来开展！3.7单元测试的基本原则由程序设计人员来完成应在基本功能/参数上验证程序的正确性应该产生可重复、一致的结果具有独立性，单元测试运行/通过/失败不依赖于别的测试应该覆盖所有代码路径应该集成到自动测试的框架中必须和产品代码一起保存和维护思考和讨论测试用例的设计是否必须在编码阶段来完成讨论3.8黑盒测试思想根据已知的程序功能和性能(而非内部细节)，设计测试用例并通过测试检验程序的每个功能和性能是否正常依据程序的功能和性能描述特点知道程序功能和性能，不必了解程序内部结构和处理细节模块外在功能黑盒测试发现的错误类型测试软件系统是否满足功能要求不正确或遗漏的功能界面错误数据结构或外部数据库访问错误性能错误初始化和终止条件错误黑盒测试的特点黑盒测试与软件如何实现无关，如果软件实现发生变化，测试用例仍然可以使用黑盒测试用例的开发可以与软件实现并行进行，能够缩短软件开发周期黑盒测试-等价分类法思想把程序的输入数据集合按输入条件划分为若干个等价类每一个等价类对于输入条件而言为一组有效或无效的输入为每一个等价类设计一个测试用例优点减少测试次数，不丢失发现错误的机会每个等价类中的数据具有相同的测试特征等价分类法的基本原则输入条件为一范围划分出三个等价类(1)有效等价类(在范围内)，(2)大于输入最大值，(3)小于输入最少值输入条件为一值划分为三个等价类(1)有效，(2)大于，(3)小于输入条件为集合划分二个等价类(1)有效(在集合内)，(2)无效(在集合外)输入条件为一个布尔量划分二个等价类(1)有效(此布尔量)，(2)无效(布尔量的非)等价分类法示例z=func(x,y):当0<x<1024且y=0,z=-1否则，z=x*lg(y)关于x的等价类(0,1024)(-#,0][1024,+#)关于y的等价类{0}(-#,0)(0,+#)X=1,y=0,z=-1X=1,y=-1,z=**X=1,y=1,z=**X=0,y=1,z=**X=0,y=-1,z=**X=0,y=1,z=**X=2000,y=0,z=**X=2000,y=-100,z=**X=2000,y=200,z=**测试用例9个黑盒测试-边界值分析法输入条件是一范围(a,b)a,b以及紧挨a,b左右的值应作为测试用例输入条件为一组数选择这组数最大者和最小者，次大和次小者作为测试用例如果程序的内部数据结构是有界的应设计测试用例使它能够检查该数据结构的边界边界值分析法示例z=func(x,y):当0<x<1024且y=0,z=-1否则，z=x*lg(y)关于x的等价类-6个-1,0,11023,1024,1025关于y的等价类-3个-1,0,1X=1,y=0,z=-1X=1,y=-1,z=**X=1,y=1,z=**X=0,y=0,z=**X=0,y=-1,z=**X=0,y=1,z=**X=-1,y=0,z=**X=-1,y=-100,z=**X=-1,y=200,z=**……测试用例18个内容软件测试概述软件测试的思想和原理软件测试的过程和策略软件测试的活动及实施的方法软件测试技术白盒和黑盒测试技术软件测试计划及输出测试计划制定及测试结果*4.1成立软件测试组织软件测试是一项独立性的工作成立单独的软件测试小组成员由各个软件测试工作师组成高效的开展软件测试，确保软件测试工作的权威性软件测试小组也不受软件开发小组的管理，以确保软件测试的独立性和结果的客观性需在软件开发早期就成立软件测试小组以便他们尽早地介入到软件测试工作之中，包括开展必要培训、了解软件项目的整体情况、掌握软件需求、制定软件测试计划等4.2制定和实施软件测试计划（1/2）标识符：用以标识本测试计划简介：介绍测试的对象、目标、策略、过程和进程等方面的内容测试项：描述接受测试的软件元素，包括代码模块或质量属性待测软件特征：说明接受测试的软件特征，如软件需求等免测软件特征：说明无需接受测试的软件特征，如软件需求等测试策略和手段：说明对软件进行测试的策略和手段测试项成败标准：说明每个测试项通过软件测试的标准测试暂停/停止的标准：说明软件测试暂停或停止的决策依据制定和实施软件测试计划（2/2）测试交付物：说明测试过程中或完成之后应该交付的软件测试制品测试任务：描述测试的主要任务测试环境：描述测试所需建立的环境职责：说明每项测试任务的主要负责人或团队及其职责进度安排：描述测试的过程及时间安排成本预算：估算软件测试的成本风险与意外：描述测试过程中可能存在的风险和可能发生的意外4.3软件测试的输出软件测试计划软件测试报告，记录软件测试情况以及发现的缺陷软件单元测试报告软件集成测试报告软件确认测试报告系统测试报告等每个报告详细小结软件测试是为了发现软件中的缺陷原理是设计和运行测试用例软件测试方法是设计测试用例、运行测试代码、发现问题白盒测试、黑盒测试软件测试的活动、过程和策略单元测试、集成测试、确认测试基于测试的结果来进行纠错测试、调试和纠错综合实践一任务：对编写的代码进行软件测试，发现所维护的代码中存在的缺陷方法在维护开源软件过程中，针对所编写的代码，设计测试用例，开展软件集成测试和确认测试要求针对软件设计文档和需求文档来设计测试用例，确保软件测试覆盖所有的功能结果：反馈通过测试发现的软件缺陷综合实践二任务：对编写的程序代码进行软件测试，发现所开发的软件中存在的代码缺陷方法针对所编写的程序代码，设计测试用例，开展软件集成测试和确认测试要求针对软件设计文档和需求文档来设计测试用例，确保软件测试覆盖所有的功能结果：反馈通过测试发现的软件缺陷问题和讨论思考和讨论如何改进和完善软件测试方法，提高发现软件缺陷的能力？软件部署内容软件及其环境软件运行环境及其变化何为软件部署软件部署的概念和原则软件部署的方式和方法单机和分布式部署、多种软件部署方法软件部署的CASE工具Fatjar、InstallerProjects、Jenkins等1.1软件运行环境软件运行所依赖的上下文，它为软件系统的运行提供必要的基础服务和功能、必须的数据和基本的计算能力

软件系统环境OS第三方软件中间件或开发框架软件与其运行环境环境是软件赖以生存的场所环境为软件运行提供各种要素，包括数据、计算、服务等等软件需要与环境进行持续的交互软件通过环境获得基础服务和计算能力，环境通过软件获得相应的运行进程和数据等软件系统的运行环境可以表现为多种形式既可以是物理和硬件设备（如计算机、服务器、机器人等），也可以是不同抽象层次的软件系统软件系统的运行环境不仅包括纵向层次的基础软件及平台，还包括横向层次上与其运行相关的其他软件系统1.2软件间的关系纵向的层次性依赖于支撑其运行的基础软件系统横向的相关性需要与其他的软件系统进行交互软件部署需要考虑到依赖的其他软件系统相关的其他软件系统虚拟机软件OS软件中间件软件应用软件其他系统交互接口协同集成互操作重用访问...1.3软件运行环境的变化119大中小型机的计算平台基于局域网的分布计算平台基于互联网的计算平台基于PC的计算平台无处不在的计算从前端的PC终端、可穿戴设备、智能手机到后端的云中心、高性能计算中心从孤立、独立、局域和可控的计算环境到分布、开放、动态、难控、无处不在计算环境内容软件及其环境软件运行环境及其变化何为软件部署软件部署的概念和原则软件部署的方式和方法单机和分布式部署、多种软件部署方法软件部署的CASE工具Fatjar、InstallerProjects、Jenkins等2.1何为软件部署软件部署是指将目标软件系统（包括软构件、配置文件、用户手册、帮助文档等）进行收集、打包、安装、配置和发布到运行环境的过程涉及二方面的工作安装和配置运行环境安装和配置软件系统2.1.1安装和配置运行环境运行环境是目标软件系统运行赖以生存的上下文在将软件系统部署到运行环境之前，软件开发工程师首先需要安装和配置好运行环境，包括构成运行环境的各类软硬件系统以及它们之间的相关性软构件运行环境2.1.2安装和配置软件系统收集和打包目标软件系统中需要安装的软件要素，然后将这些软件要素安装到目标计算平台中，并进行必要配置包括软构件、所依赖软件包、软件文档和必要的数据软件系统2.2软件部署的原则最小化原则只需安装、部署和配置支撑软件运行和服务提供的最少软硬件要素，以提高软件系统和运行环境的精简性，提升目标软件系统的运行效率，减低运行和维护成本相关性原则部署的运行环境和软件系统要素均与系统建设相关联，剔除不想关的软硬件要素，防止将无关的软件要素部署到计算平台之中，以简化软件系统的部署和配置，降低软件运行和维护的复杂度适应性原则当软件系统的运行环境发生变化时，目标软件系统的部署也要随之发生变化，以确保目标软件系统部署的灵活性，提高目标软件系统的健壮性，提升软件部署和运维的自动化程度内容软件及其环境软件运行环境及其变化何为软件部署软件部署的概念和原则软件部署的方式和方法单机和分布式部署、多种软件部署方法软件部署的CASE工具Fatjar、InstallerProjects、Jenkins等3.1单机部署方式将软件的各个要素（如可运行软构件、数据、文档等）集中部署到某个单一的计算设备上软件的运行环境只依赖于单一的计算设施不同软构件之间不存在网络通讯计算设施不仅仅是指各种计算机，如个人计算机、笔记本电脑或服务器等，还包括智能手机、智能手环等嵌入式计算设施典型示例小米便签、闹钟和时钟、光盘刻录软件、扫雷游戏软件3.2分布式部署将软件的各个要素（如可运行的软构件、数据和文档等）分散部署在多个计算设备上的部署方式基于C/S的部署方式基于客户端-应用服务器-数据库服务器的部署方式基于互联网的软件部署方式典型示例空巢老人看护、Google搜索引擎、淘宝和中国铁路“12306”3.3软件部署方法软件部署的目标平台（如计算机、服务器、移动智能终端等）操作系统层（如Windows、Linux、MacOS等计算机操作系统，及Android、IOS、鸿蒙等移动智能终端操作系统）

软件中间件软件开发框架软件容器基于软件中间件、开发框架和容器部署的软件基于操作系统部署的软件3.3.1基于操作系统的部署软件系统直接部署在目标计算设施的操作系统之上运行软件的运行仅依赖于计算设施上的操作系统及其提供的基础服务（如文件操作和管理、窗口界面的创建和操作等）操作系统构成了软件运行的上下文环境典型示例移动端APP软件部署在移动端的操作系统之上，如智能手机、平板电脑等中的Android、IOS等桌面端软件主要部署在计算机上，常见的操作系统有Windows、Linux、MacOS等3.3.2基于软件开发框架的部署软件开发框架软构件目标硬件平台操作系统层可重用开发包待部署的目标软件系统

调用调用3.3.3基于软件中间件的部署待部署的目标软件系统软件中间件操作系统层目标硬件平台基础服务1基础服务n软构件访问3.3.4基于容器和镜像的部署容器是一个视图隔离、资源可限制、具有独立文件系统的进程集合容器作为软件运行的上下文容器具有独立文件系统，包括二进制文件、配置文件以及依赖容器运行时所需要的所有文件集合称之为容器镜像，又叫做rootfs对于容器镜像而言，它打包的不仅仅是应用代码，而且还包括应用运行所需要的所有依赖文件容器镜像就是容器的文件系统，有了容器镜像，就可以构建该镜像的多个容器实例容器部署流程选定基础镜像编写Dockfile脚本根据Dockfile脚本创建软件镜像基于软件镜像创建并运行Docker容器3.4基于部署图来搭建环境和部署软件设计阶段的部署图计算节点，通信方式，节点的运行环境，所要部署的软构件基础软件如OS软构件内容软件及其环境软件运行环境及其变化何为软件部署软件部署的概念和原则软件部署的方式和方法单机和分布式部署、多种软件部署方法软件部署的CASE工具Fatjar、InstallerProjects、Jenkins等4.1Fatjar部署工具支持Java程序代码的打包、安装和部署将Java程序的所有资源（包括源代码、调用的第三方库、图片、项目配置文件等）进行打包，生成可直接安装部署的jar文件能脱离Eclipse环境灵活部署到目标计算平台上是一个开源软件，托管在SourceForge开源社区中Eclipse集成开发环境的一个组件Fatjar软件工具生成部署文件的过程

可运行Java文件依赖的第三方库命名部署文件选择主类文件导入程序文件生成jar文件4.2InstallerProjects部署工具用于创建MicrosoftWindows应用安装程序和安装包设置软件图标和快捷方式、设置软件安装路径、增加或删除安装包中的文件等，采用图形化的方式对软件进行打包作为MicrosoftVisualStudio的一个扩展组件基本步骤将应用程序文件和图标导入到MicrosoftVisualStudio项目；在“解决方案”中使用“SetupProject”模板添加项目设置程序作者信息、描述信息、版本号和默认安装路径等参数将图标、程序依赖的动态链接库DLL文件、可执行程序及其快捷方式添加到“ApplicationFolder”应用文件夹设置应用图标和快捷方式执行打包操作，分别生成以.msi和.exe为后缀名的安装包4.3Jenkins部署工具针对Java应用、实现持续集成和部署的软件工具它允许其它的工具以插件的方式加入到Jenkins软件之中，为自动化的构建和部署提供多样化的服务拉取Git仓库中的变更代码对项目进行编译打包将包上传到目标服务器执行启动脚本运行软件小结软件需要部署和运行在特定的环境中环境包括硬件、基础软件、中间件和其它软件系统等软件部署是指将目标软件系统进行收集、打包、安装、配置和发布到运行环境的过程单机部署和分布式部署软件部署的方法多样化，取决于软件的运行环境基于操作、基于中间件、基于开发框架、基于容器支持软件部署的CASE工具针对不同的编程语言和环境，提供不同的支持综合实践一任务：对维护后的开源软件进行安装和部署方法根据开源软件的安装和部署要求，准备好开源软件的运行环境，随后将维护后的开源软件部署到目标运行环境之中要求将维护后的开源软件安装和部署完成之后，该软件系统能够正常运行，并能为用户提供功能和服务结果：可运行和可展示的开源软件系统综合实践二任务：安装和部署目标软件系统方法对照目标软件系统的部署模型和安装要求，准备好目标软件系统的运行环境，随后将目标软件系统安装和部署到目标运行环境之中要求将目标软件系统安装和部署完成之后，该软件系统能够正常运行，并能展示功能和演示服务结果：可运行和可展示的目标软件系统问题和讨论思考和讨论软件部署的主要问题和挑战在哪里？软件维护与演化目录软件维护与演化软件维护的形式和挑战软件演化的概念及法则软件逻辑老化逻辑老化的表现和原因解决逻辑老化的方法软件维护的过程与技术软件维护技术软件维护过程物理设备的维护问题物理设备在使用过程中会出现故障，需要进行维护软件是否也会出故障？为什么？出了故障怎么办？1.1软件也需要进行维护出故障，不可正常工作潜在的缺陷产生软件错误需要对这些缺陷进行纠正服务变化，需要升级软件需求发生了变化需要增强软件的功能和服务运行环境变化，需要适应需要改变软件以在新的环境中运行1.2何为软件维护软件在交付使用后，由于应用需求和环境变化以及自身问题，对软件系统进行改造和调整的过程软件自身问题，发现了一些新的缺陷运行环境变化，从WindowsLinux软件需求变化，需要增加一些新的需求小米便签软件的维护设置便签访问密码解除便签访问密码根据密码访问便签改善程序代码质量1.3软件维护的形式纠正性维护完善性维护适应性维护预防性维护纠正性维护何为纠正性维护纠正软件中的缺陷和错误起因用户在使用软件过程中一旦发现缺陷，他们会向开发人员提出纠正性维护的请求目的诊断和改正软件系统中潜藏的缺陷为什么软件在使用时还有缺陷存在？适应性维护何为适应性维护?对软件进行改造以便适应新的运行环境和平台起因软件运行于一定的环境(硬件、OS、网络等)之上，运行环境发展很快，出现了变化目的适应环境变化和发展而对软件进行维护为什么软件需要适应环境的变化?改善性维护何为改善性维护?对软件进行改造以增加新的功能、修改已有的功能起因在软件系统运行期间，用户可能要求增加新的功能、建议修改已有功能或提出其他改进意见目的满足用户日益增长的各种需求而对软件系统进行的改善和补充小米便签维护中是否涉及完善性维护？做了哪些完善性工作预防性维护何为预防性维护?对软件结构进行改造以便提高软件的可靠性和可维护性等起因为进一步改善软件系统的可维护性和可靠性，为以后的软件改进奠定基础的维护活动目的获取软件结构，重新改善软件结构小米便签需要做预防性维护吗？1.4软件维护的特点同步性软件维护需要与软件使用同步进行周期长软件维护周期会更长，一些软件会服役十几年甚至几十年的时间费用高维护成本高达总成本80%以上，维护费用是开发费用的3倍以上难度大充分理解待维护软件的架构、设计和代码，这极困难。尤其是在软件设计文档缺失的情况下，这一问题更为突出50%-90%的时间被消耗在理解程序上1.5软件维护工程师负责完成软件维护的各项工作，具备多方面的能力和素质阅读理解能力，阅读待维护软件的相关文档和代码，以此来掌握软件的架构和相关设计需要有非常强的掌握新技术能力，以此来指导软件维护洞察和分析能力，根据软件缺陷的症状快速定位缺陷所在代码的可能位置，能够针对增强的软件需求明确要对软件的哪些部分进行重设计沟通能力，与客户、用户和软件工程师进行沟通的能力1.6软件演化及其特点软件演化是指针对软件的大规模功能增强和结构调整，以实现变化的软件需求，或者提高软件系统的质量功能增强粒度大，软件演化针对的是粗粒度需求变化及功能增强主动应对变更，基于对用户需求及其变化的理解，综合考虑软件各项功能实现的时间投入及开发成本，规划软件系统的整体演化，并以此开展功能增强等维护活动持续性，预先规划好软件演化的路线图，完成当前软件演化工作后，软件维护团队随后将连续性的进入到另一项软件演化工作引发版本变化，每一次演化结束后通常会产生一个新的软件版本软件演化与软件维护概念功能增强粒度应对变化方式持续性或间隔性版本变化软件演化粗粒度主动持续性是软件维护细粒度被动间隔性不一定1.7软件演化法则（1/2）大型闭源软件的演化特点和规律持续变化法则除非系统持续不断地被修改以满足用户的需求，否则系统将变得越来越不实用增加复杂性法则除非有额外的工作来明显降低软件系统的复杂性，否则软件系统会变得越来越复杂自我调节法则在软件演化过程中，软件产品和过程的测量遵循正态分布，演化过程是自我可调节的组织稳定性守恒法则在整个生命周期中，产生一个新版本所需的平均额外工作量几乎是相同的软件演化法则（2/2）熟悉度守恒法则在一个不断演化的系统中，平均增量增长几乎相同功能持续增长法则在软件的生命周期中，软件功能必须持续增加，否则用户的满意度会降低质量衰减法则软件的质量会随代码的不断变更而呈现出整体逐渐下降的趋势。如果没有严格的维护和适应性调整，使得软件适应运行环境的变化，软件的质量必然会随着软件演化而逐渐下降反馈系统法则系统的演化过程包括多回路的活动和多层次的反馈。软件工程师必须识别这些复杂的交互，以持续演化现有系统，提供更多的功能和更高的质量目录软件维护与演化软件维护的形式和挑战软件演化的概念及法则软件逻辑老化逻辑老化的表现和原因解决逻辑老化的方法软件维护的过程与技术软件维护技术软件维护过程2.1何为软件逻辑老化软件在维护和演化的过程中出现的用户满意度降低、质量逐渐下降、变更成本不断上升这样一种现象这些现象发生在逻辑层面，而非发生在物理层面时间软件质量及用户满意度维护活动软件重构软件会出现物理老化现象吗？2.2软件逻辑老化的现象（1/2）质量下降在对软件进行完善性维护的同时，尽管增加了新的功能，但也会带来对软件架构的破坏，从而引入新的软件问题，使得整个软件不易于维护，软件架构变得脆弱变更成本增加随着软件规模的不断增大、软件质量的下降，对软件进行变更的成本也会随之不断增加需要阅读更多的文档和代码才能理解待维护的软件系统软件系统架构的脆弱性意味着软件维护工程师不得不对软件进行更多的“缝缝补补”才能实现新的软件功能软件逻辑老化的现象（2/2）用户满意度降低随着对软件认识不断深入，用户会逐步发现软件中存在的缺陷用户对软件的满意度会逐步降低软件逻辑老化是一种必然的现象，不可避免如果对软件逻辑老化的现象置之不理，必然会导致软件“不可救药”，最终走向死亡解决软件逻辑老化的有效方法之一就是对软件进行重构，重构意味着给软件注入“强心针”，使得软件在一定程度上“返老还童”2.3软件逻辑老化的原因缺乏变更当外部环境发生变化时，软件也应随之发生变化，进行必要的变更，否则软件就会进入老化如果软件运行的操作系统已经发生了变化，软件就需要进行适应性的维护，否则就会被运行环境抛弃如果软件不能适应外部环境变化，缺乏必要变更，就会加速老化负面变更软件变更不总是积极和正面的，有时候它会带来负面和消极影响通过变更引入了新的、更为严重的缺陷；破坏了软件结构，使得软件架构更为脆弱负面变更会破坏软件的结构和质量，进而增加维护的成本和难度2.4软件逻辑老化的表现设计恶化是指软件维护过程中由于设计变更而导致的软件可变性显著降低的现象。设计僵化，软件不易于变更，模块之间存在连带效应设计脆弱，一些“小规模”的软件变更会带来“大范围”的软件变更，甚至会破坏软件系统的整体架构模块间紧耦合，软件内部的多个模块之间关系过于密切，软件铁板一块，难以对其中的模块进行变更晦涩的软件设计，软件设计方案不易于理解设计恶化会导致软件出错率上升，软件变更成本增高目录软件维护与演化软件维护的形式和挑战软件演化的概念及法则软件逻辑老化逻辑老化的表现和原因解决逻辑老化的方法软件维护的过程与技术软件维护技术软件维护过程3.1代码重组在不改变软件功能的前提下，对程序代码进行重新组织，使得重组后的代码具有更好的可维护性，能够有效支持对代码的变更代码读入程序代码程序代码内部表示代码转换易于维护的代码3.2逆向工程基于低抽象层次软件制品，通过对其进行理解和分析，产生高抽象层次的软件制品通过对程序代码进行逆向的分析，产生与代码相一致的设计模型和文档基于对程序代码和设计模型的理解，逆向分析出软件系统的需求模型和文档典型应用场景分析已有程序，寻求比源代码更高层次的抽象形式（如设计甚至需求）3.3设计重构如果一个软件的设计文档缺