点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快一、测试项目启动与研读需求文档一 组建测试团队1、测试团队中的角色2、测试团队的基本责任尽早地发现软件程序、系统或产品中所有的问题。督促和协助开发人员尽快地解决程序中的缺陷。帮助项目管理人员制定合理的开发和测试计划。对缺陷进行跟踪、分析和分类总结以便让项目的管理人员和相关的负责人能够及时、 清楚地了解产品当前的质量状态。帮助改善开发流程、提高产品开发效率。促进程序编写的规范性、易读性、可维护性等3、测试团队与开发团队的 3 种模式1以开发为核心测试只是开发队伍的一部分也就是开发团队中有测试人员但 没有形成独立的团队2以项目经理为核心开发小组和测试小组并存隶属于项目经理领导。3项目经理、开发组长和测试组长“三足鼎立”测试团队具有独立的、权威的地 位。二软件质量需求1、软件质量需求的分类软件质量需求用于确定测试目标。测试目标包括功能、性能、界面、易用性、兼容性、安全性、可用性/可靠性、可维 护性、可扩展性等。功能以外统称非功能。2、功能软件能做什么需要做什么怎么做是正确的哪些功能要测试、哪些功能不需要测试哪些功能重要哪些不重要哪些功能先实现或先测试3、性能反映软件运行时的效率和占用资源情况的能力。时间特性时间短、速度快、效率高。资源特性占用资源CPU、内存、硬盘、网络少。4、界面UI布局合理控件位置恰当文字没有乱码、字体大小合适颜色使用恰当图片、表格恰当、舒适、美观。5、易用性在指定条件下使用时软件产品被理解、学习、使用和吸引用户的能力。6、兼容性/可移植性指软件产品从一种环境迁移到另一个环境的能力反映一个软件与不同的硬件环境、操 作平台、其他软件的共同使用的能力包括与不同硬件、平台、软件自身不同版本、其他软件、数据的兼容。7、安全性指软件产品保护信息和数据的能力。8、可用性/可靠性指系统正常运行的能力或程度可用性正常运行时间/正常运行时间非正常运行时 间×100%可用性指标一般要求达到 4 个 9 即 99.99%全年 52 分钟不正常工作或 5 个 9 即 99.999%全年 5 分钟对一些军事系统可用性高达 7 个 999.99999%全年 失效时间不超过两秒。一般测试时间不足可以采用空间换时间的办法如在高负载情况下进 行为期一周 或一个月的测试以判断其可靠性。关注 MTTF平均无故障时间、MTTR平均恢复时间、MTBF平均失效间 隔时间。9、可维护性指软件产品可被修改的能力修改可能包括修正、改进或软件对环境需求和功能规格说明变化的适应。可维护性的软件应该是易改变的、稳定的、易测试的。10、可扩展性/可伸缩性测试通过很少的改动就能实现整个系统处理能力的增长如在部署两台服务器时测试系统性能容量即最大负载再部署四台、八台服 务器时分别进行系统容量的测试看其容量是否为上次两台、四台实验值的两 倍或接近两倍。如果是系统就具有良好的可伸缩性。三研读需求文档1、测试需求分析的过程收集与研读文档提出并解决问题整理需求信息功能拆分、功能描述/需求整理编写测试点需求评审2、研读需求文档2.1 研读文档主要任务提取有用的需求信息提出需求中不清晰、不理解、不明白的问题 和用户、业务人员、产品经理或产品设计人员、开发人员等沟通2.2 怎么研读文档分析思路 分析软件的用户群分析用户的实际需要 分析软件的开发环境、开发语言、数据类型 分析软件架构、软件的运行环境和平台、数据库类型 分析软件要实现哪些目标功能、性能、界面、易用性、兼容性、安全性以 及具体的要求是什么 分析软件有哪些功能每种功能要完成什么业务这些业务应该怎么实现业 务逻辑是什么业务流程是怎样的业务规则有何要求 分析功能或业务间的联系哪些业务更关键或重要 明确测试周期测试目标测试范围。细节上 分析每个模块或功能上实现的功能 设计的开发原理包括数据类型 从用户使用场景角度分析业务流程 记录业务规则实施 以情景再现的形式写出需求信息。2.3 研读需求文档案例拿到一个项目怎么入手即时贴程序部分需求说明便签的数量最多为 50 个便签标题字数最多为 40 个字节便签的正文文字数量最多为 200 个年份只能设置在 19002100 之间四需求评审1、意义对软件需求进行正确性的检查。保证软件需求的可测试性。通过产品需求文档的评审与市场、产品、开发等各部门相关人员沟通使得大家 认识一致避免在后期产生不同的理解引起争吵。通过产品需求文档的评审更好地理解产品的功能性和非功能性需求在需求文档评审通过后测试的目标和范围就确定了。虽然此后会有需求的变更 但可以得到有效的控制这样可降低测试的风险。评审是否完成是以需求文档获得多方“邮件确认”或“签字”通过为标志的。这不 应该只体现在“签字”形式上更重要的是达到下面的结果。所有参与方达成一致。已发现的问题被阐述清楚、被修正。2、需求评审的质量要求正确性完备性易理解性一致性可行性易修改性可测试性可追溯性3、需求评审的参加人员用户代表需求人员产品经理项目经理开发人员开发经理测试人员测试经理市场经理质量保证人员4、测试人员参与评审时的注意事项明确自己的角色和责任。熟悉评审内容为评审做好准备做细做到位。在评审会上针对问题阐述观点而不是针对个人。可以分别讨论主要的问题和次要的问题。在会议前或会议后可以就存在的问题提出自己建设性的意见。提高自己的沟通能力采取适当的、灵活的表述方式。对发现的问题跟踪下去。应该在需求形成的过程中进行分阶段的多次评审而不是一次评审。测试人员要善于提问多思考 这些需求都是用户提出来的吗 有没有画蛇添足的需求没有漏掉什么需求吗 和竞争对手的产品做过比较吗我们的产品优势体现在哪里 是否正确地描述了每个需求这条描述是否存在二义性的问题 我的理解和文档作者的理解一致吗二、测试需求分析与测试用例设计一 界面中的控件知识1、文本框和密码框2、单选按钮、组合列表框、数码框3、复选框4、列表框5、命令按钮6、其他界面元素三、测试需求分析与测试用例设计方法1、场景法1.1 测试点/检查点测试时应该考虑可以测试的诸多方面。1.2 场景法概述场景法模拟用户操作软件时的情景主要用于测试系统的业务流程。当拿到一个测试任务时我们先要关注它的主要功能和业务流程是否正确实现这 就需要使用场景法来完成测试。1.3 场景的定义场景用来描述软件操作的路径。基本流按照正确的业务流程来实现的一条操作路径模拟正确的操作流程。备选流导致程序出现错误的操作流程模拟错误的操作流程。1.4 场景法的分析步骤分析软件需求从用户使用情景角度写出业务流程和业务规则写出基本流场景和备选流场景1.5 场景法案例ATM 机取款步骤一分析业务流程可以绘制流程图步骤二描述程序的基本流及备选流1、基本流正确的流程1插入银行卡客户将银行卡插入 ATM 机的读卡器2验证银行卡ATM 机从银行卡的磁条中读取账户代码并检查它是 否属于可以接受的银行卡3输入密码ATM 机要求客户输入密码4验证密码确定该密码是否正确 5进入 ATM 主界面ATM 显示在本机中可用的各种选项6选择取款并输入金额客户选择“取款”并选择取款金额7ATM 机验证ATM 机进行验证账户余额是否满足以及总取款金额 是否满足要求验证 ATM 机内现金是否够用8更新账户余额、出钞验证成功更新账户余额输出现金提示 用户收取现金9返回主界面2、备选流各种错误情况1银行卡无效提示错误并退卡2密码错误提示错误并判断是否 3 次错误3密码 3 次错误吞卡4账户余额不足提示错误并退卡5总取款金额超出当日可取限额提示错误并退卡6ATM 机余额不足提示错误并退卡步骤三根据基本流和备选流生成不同的场景2、等价类划分2.1 案例引入测试两位数加法器学生思考、讨论、陈述2.2 等价类划分核心思想通过需求分析找出程序的输入域。将输入域划分成若干类。每一类中选取代表性数据等价于这一类中的其他值。2.3 等价类划分的步骤需求分析划分等价类根据需求有效等价类、无效等价类并细化根据计算机知识2.4 等价类划分案例步骤 1需求分析阅读文档  借助开发知识 与开发或用户沟通 了解用户群及行业知识写出需求 -99~99 之间的整数步骤 2划分等价类并细化有效类 -99 到 99 之中的整数 细化 负数、0 、正数无效类 超范围 -99 或 99 非法类型 浮点数 、 字符串2.5等价类划分注意事项不但要考虑有效等价类也要考虑无效等价类两块划成一块等价类划分过粗结果 遗漏一种测试情况一块划成两块等价类划分过细结果 冗余测试仔细划分审查划分 过于粗略可能会漏掉软件缺陷 积累经验3、边界值分析3.1 边界值分析的思想与步骤分析需求找出边界。写出边界值 最小值 小于最小值 最大值 大于最大值3.2边界值分析案例两位数加法计算器的边界值 -99 、-100、99 、1003.3 为什么分析边界值看看下面的代码有错误吗 输入或输出的边界最容易产生错误。4、决策表前面测试两位数加法计算器的测试没有考虑输入组合。4.1 决策表的分析步骤需求分析分析输入和输出 用等价类划分分析输入的各种情况、输出的各种情况画判定表分析与简化判定表4.2 决策表案例分析输入条件和输出条件输入输出 正确计算 错误提示原始决策表/判定表优化决策表优化策略 测试基本功能的保留 一个输入错误另外输入无所谓可以整合 所有输入都要错误过。最终的决策表4.3 决策表的局限性与优化策略导致测试量爆炸。5、错误推测5.1 测试若干原则回顾测试不是验证软件正确而是攻击软件发现错误。测试要时刻保持怀疑的态度具有缺陷预防意识。测试要寻求系统设计、功能设计的弱点。设计负面的、异常的测试如考虑错误的或者异常的输入往往可以发现更多的软件缺陷。5.2 什么是错误推测在测试程序时人们可以根据经验或直觉推测程序中可能存在的各种错误从而有针对 性地编写检查这些错误的测试方法。错误推测分类 输入数据测试方面 输出数据测试方面 数据结构测试方面 文件系统方面5.3 输入数据方面的错误推测输入非法数据一般用于键盘输入数据时。测试方法 输入非法类型 输入非法范围/长度 输入非法格式注意错误信息的检查需要额外考虑错误提示信息的内容错误信息和错误要对应一致错误信息不能为空错误信息的内容不能只是错误代码不能包含开发信息错误信息不能中英文混合5.4 错误推测输入非法类型输入非法范围数值输入非法长度个数输入非法格式输入默认值输入特殊字符输入合法数据的非法组合粘贴强制输入一个输入多个输出不要遗漏输出结果含数据库要正确上溢、下溢含结果操作数与操作符不符文件超载文件权限不足介质忙或不可用介质损坏输入默认值适用于有默认值的地方。测试方法 接受软件的默认值 键入空值 将默认值改为另外一个值 将默认值改为另外一个值再变为空值输入特殊字符集适用于不能输入有特殊含义的字符时。测试方法 根据被测软件所处的操作系统、程序设计语言、后台数据库以及具体业务 等信息列出表格进行讨论标明哪些需要测试哪些需要剔除。 了解具体行业知识具体问题具体分析。案例文件命名下列特殊字符33 个 不能使用\ /|“?com0-com9lpt0-lpt9prn、aux、nul、 con。思考 用户名有哪些特殊字符 QQ 昵称、聊天内容有哪些特殊字符输入合法数据的非法组合适用于输入值之间存在依赖关系时。测试方法 输入可能是出现问题的组合值。案例输出数据方面的错误推测1)同一个输入产生多种输出案例输入一个电话打来输出 状态一等待接听。 状态二占线。 状态三停机。 状态四无法接通。 状态五关机。 状态六空号。测试方法详细测试每一种输出不要有遗漏。熟悉被测软件业务知识阅读各种程序文档明确输入可能产生的输出 列出关于程序输入于输出的一个列表然后进行测试。2)验证输出结果的正确性测试方法不仅测试输入的正确性还要检查结果的正确性。测试人员要尽可能多地学习所涉及问题的领域。数据结构方面的错误推测1)数据结构溢出适用于程序中存在变量、数组等数据结构时。测试方法变量 上溢值太大下溢值太小数组 上溢数据量太多 下溢数据量太少2)计算结果溢出测试方法 输入非法值或很大与很小数据强制结果产生上溢或下溢。3)操作数和操作符不符适用于需要进行数值计算程序和图形操作程序的测试时如加、减、乘、除等。测试方法 找到程序中容易引起操作数和操作符不符的计算、表达式等文件系统方面的错误推测1)使文件系统超载适用于数据存储到硬盘中时。案例 假设“软件测试工程师管理系统”要保存 10000 个工程师信息则保存时 engineer.txt文件可能会有20M大小如果此时磁盘只有10M可用空间了 “软件测试工程师管理系统”会如何动作呢测试方法 创建满容量或近乎满容量的文件系统然后强制执行各种通过输入或输出 访问文件系统的操作。 打开足够多的文件文件打开时会强制创建备份副本从而占用双倍的存 储空间。 使用工具 CannedHeat模拟文件系统超载。2)更改文件访问权限适用于对文件进行读写的应用程序。测试方法不同的用户对相同文件具有不同的访问权限需要考虑登录同一台机器的 多个用户操作相同文件的权限问题。 打开一个文件在操作系统中修改该文件的访问权限。有些操作系统 允许权限高的用户控制一般用户已经打开的文件。两个应用程序打开关闭同一个文件。 如把同一应用程序的不同版本安装在同一机器上在不同版本的应用 程序中打开和关闭同一文件 试着在某个应用程序中打开在另一个程序中已打开的文件这可能会 导致文件访问权限上出现冲突。3)使介质忙或不可用适用于应用程序的运行需要消耗大量内存或运行时需求其他相关软件同时运 行的情况。 大多数操作系统能同时运行多个应用程序但相互切换时会有延迟但是 没有对错误响应。测试方法 通过启动大量应用程序强制它们都打开并保存文件来使文件系统处于忙 的状态或者同时下载大量文件也可以使后台拥挤。 使用一些测试工具来模拟磁盘的状况。4)介质损坏使用场合 损坏的介质可能使操作系统传回错误代码这些错误代码可能没有在应用 程序中编程处理。测试方法 损坏介质的方法使用不很多只有少数公司采用大多是开发操作系统、 设备驱动程序以及以安全为主的应用程序的公司会采用这种测试方法。确 定是否使用该方法主要要考虑数据对用户的重要性。 该方法可以使用实际损坏了的介质。检查应用程序对错误的处理能力应 用程序可以对错误进行处理或者将问题告诉用户并且要确保用户数据文 件不丢失、不损坏。 也可以通过软件模拟。6、编写测试点将测试点写入测试需求分析说明书或者 XMind 等留存下以供将来编写测试用例使用。四、编写测试用例1、编写测试用例一般公司都有固定模板2、测试用例的写作说明2.1 用例编号/序号简单、唯一。2.2 用例说明也称测试点、检查点、测试概述、用例概述、测试说明用一句话对测试用例进行概述可以总结测试目的可以用疑问句表示可以用“检查、验证、测试”等字眼如验证 QQ 默认安装最好看到这句话就能知道如何测试尽量唯一决策表可能会有重复的测试说明用例执行多轮时越往后执行可能越快如果用例写得好直接看概述就行。2.3 初始条件也称预置条件、前提条件初始条件要是一个状态而且是静态的如管理员已登录后台初始条件是第一步操作步骤之前的状态不能太远不用从头写到尾很多项目中不写预置条件。2.4 操作步骤若对数据要求高需要把数据分离出来步骤要都有序号每一步用分号分开最后用一个句号每一步必须换行参数前加冒号如用户名admin涉及按钮界面用【】、“”等成对符号间隔功能的详细用例步骤 4-6 步左右最后一步一定是个动作不能写结果。2.5 预期结果是一个状态如果参考文档中有描述原封不动的抄过来如果文档中没有具体要求则点要一 致可以有几个点如 QQ 默认安装应能启动、默认选项匹配等。2.6 用例状态通过、失败、阻塞、未执行、搁置、无效用例…初始条件达不到时一般用例状态设置为阻塞。看如何执行用例执行完关心什么来定。2.7 优先级用例的执行顺序。3、测试用例的评审和管理保证测试用例质量的方法 首先要对用户需求、服务质量要求、产品特性有深刻且全面的理解 其次采取正确、恰当的方法进行用例设计 再者按照测试用例的标准格式或规范的模板来书写测试用例 最后对测试用例的检查、评审也是提高测试用例质量的主要且有效的手段。五、提交缺陷报告一 软件缺陷的判定1、什么是缺陷软件存在着不符合质量需求或违背软件用户、客户、企业意愿的问题这就是软件缺陷 Defect又叫“Bug臭虫”。2、软件缺陷的判定准则软件未达到产品说明书标明的功能 产品说明书简称为说明spec或产品说明productspec是软件开发小组 的一个协定。它对开发的产品进行定义给出产品的细节、如何做、做什么、 不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。软件出现了产品说明书指明不会出现的错误 如金融软件 7*24 工作不能宕机软件功能超出产品说明书指明范围软件未达到产品说明书虽未指出但应达到的目标 如软件在断电时的意外处理软件测试员认为软件难以理解、不易使用、运行速度缓慢或者最终用户认为不好。 主要体现在易用性方面。3、软件缺陷的表现形式用户要求的功能、特性没有实现或部分实现。运行出错包括运行中断、系统崩溃、界面混乱等。数据结果不正确、精度不够、不完整或格式不统一。文字显示内容不正确或拼写错误。系统性能低下、系统资源浪费。4、分离和再现软件缺陷发现缺陷后应该做好分离和再现排查发现的“缺陷”是不是软件本身的问题 然后才能提交。再现 3 次 重现 复现5、避免提交缺陷的缺陷和重复缺陷缺陷的缺陷 是测试人员提交的不是缺陷的缺陷 是一种无效缺陷 此类缺陷常使测试人员遭受指责。怎么办 正确理解需求 做好复现。重复缺陷 同一个缺陷 A 测试工程师提交后B 测试工程师又提交或者自己提交的缺陷 与之前提交的缺陷相同或类似 是一种无效缺陷怎么办 尽量避免两个人同时测试同一模块 自己提交的缺陷与自己的重复提交前查找一下增强开发知识。6、处理无法再现的缺陷首先对这样的缺陷进行详细的记录使用不同办法去尝试复现。其次要合理地安排时间要考虑到测试项目的整体进度对一时难以再现的缺陷 可以暂时搁置以保证项目的正常进度并尽快提交给开发人员。最后在测试过程中对未再现缺陷予以关注。7、处理有争议的缺陷跟有关人员进行沟通、讨论搁置。二 提交缺陷报告1、什么是缺陷报告缺陷报告是对缺陷进行记录、分类和跟踪的文档。2、缺陷报告的读者对象软件开发人员 报告缺陷是为了缺陷得到修复。 希望获得缺陷的本质特征和复现步骤。质量管理人员、市场人员、技术支持人员 希望获得缺陷的严重程度和分布情况以及对市场和用户的影响程度。3、缺陷报告的写作准则5CCorrect准确 每个组成部分的描述准确不会引起误解Clear清晰 每个组成部分的描述清晰易于理解Concise简洁 只包含必不可少的信息不包括任何多余的内容Complete完整 包含复现该缺陷的完整步骤和其他本质信息Consistent一致 按照一致的格式书写全部缺陷报告。4、缺陷报告的组织结构缺陷的标题/缺陷摘要/缺陷概述/缺陷基本信息预处理复现步骤期望结果实际结果缺陷的严重程度缺陷的优先级测试的软件和硬件环境测试的软件版本缺陷的类型注释文字和缺陷截图5、缺陷报告的写作要求5.1 缺陷标题尽量按缺陷发生的原因与结果的方式书写 执行完 A 后发生 B 在什么地方做了什么事情出了什么结果使用“在…以后”“在…时候”或“在…期间”等连结词有助于描 述缺陷的原因和结果。避免使用模糊不清的词语为了方便搜索和查询尽量使用关键字为了便于他人理解避免使术语、俚语或过分具体的测试细节。5.2 复现步骤提供测试的预备步骤和信息步骤完整准确简短没有缺漏任何操作步骤没有任何多余的步骤将常见步骤合并为较少步骤简单地一步一步地引导复现该缺陷每一个步骤尽量只记录一个操作每一个步骤前使用数字对步骤编号尽量使用短语和短句避免复杂句型和句式 只记录各个操作步骤是什么不要包括每个步骤的执行结果。5.3 预期结果 软件应该具有的结果或者说正确结果应该是什么样子。5.4 实际结果实际结果的描述要列出具体的表现行为而不是简单的指出“不正确”或“不起作 用”。如果一个动作产生彼此不同的多个缺陷结果或者一个动作将产生一个结果而这 个结果又产生另一个结果。为了易于阅读这些结果应该使用数字列表分隔开来。 如实际结果 1.显示“命令代码行…错误” 2.显示“并且终止…服务”。5.5 注释/截图可以包含以下各方面的内容 截取缺陷特征图像文件 测试过程所使用的测试文件 测试附加的打印机驱动程序 再次描述重点避免开发人员将缺陷退回给测试人员补充更多信息 再次指明该缺陷是否在前一版本已经存在 多个平台之间是否具有不同表现 注释包含缺陷的隔离信息指出缺陷的具体影响范围。如缺陷的注释可能包含下面的内容 能在 Win2000 和 WinXP 文本框中显示文本内容但不支持 Win98 屏幕刷新后现象会消失。 使用二进制文件不存在该错误。 参见附加的使用说明书和测试文件。6、怎么提交高质量的缺陷报告尽早提交缺陷报告。清楚地说明此问题对用户价值的危害。  提供尽可能多的技术信息如包含复现该缺陷需要的环境变量或测试所用的数据文 件方便程序员调试。报告的软件缺陷进行了必要的隔离报告的缺陷信息具体、准确。易于搜索软件测试报告的缺陷。一个缺陷报告中只报告了一种缺陷。缺陷报告中不要提问题。避免常见的错误 我I、你You、他/她He/She 情绪化的语言和强调符号 似乎Seems、看上去可能Appearstobe 认为比较幽默的内容  不确定的测试问题Issues/不确定是否是缺陷三 缺陷的分类1、缺陷的分类标准2、根据缺陷类型对缺陷分类功能缺陷界面缺陷文档缺陷代码缺陷算法错误性能缺陷3、根据缺陷的等级对缺陷分类A 类—致命缺陷包括以下各种错误 由于程序所引起的死机非法退出 死循环 数据库发生死锁 因错误操作导致的程序中断 功能错误 与数据库连接错误 数据通讯错误B 类—严重缺陷包括以下各种错误 程序错误 程序接口错误 数据库的表、业务规则、缺省值未加完整性等约束条件C 类一般缺陷包括以下各种错误 操作界面错误包括数据窗口内列名定义、含义是否一致 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多的空字段D 类—较小缺陷包括以下各种错误 界面不规范 辅助说明描述不清楚 输入输出不规范 长操作未给用户提示 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志E 类—意见或建议4、根据缺陷处理的优先级对缺陷分类5、根据缺陷状态对缺陷分类四 缺陷报告的处理1、缺陷报告的简单处理流程/缺陷的生命周期软件测试人员提交缺陷报告测试负责人审核后将缺陷报告分配给相关的开发人员修改缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测返测通过的缺陷报告由负责人关闭返测未通过的缺陷报告直接返回开发人员重新 修改缺陷报告直到缺陷被修复以后才关闭关闭或已解决的缺陷报告可能会被阶段性的复审重新打开这些报告一旦被再次打 开应该立即处理。2、缺陷报告的标准处理流程正常缺陷重复缺陷无效缺陷推迟修改验证不通过描述不清楚3、缺陷跟踪管理系统/缺陷管理工具3.1 缺陷管理工具的功能缺陷提交缺陷跟踪缺陷分析 有效的缺陷分析不仅可以评价软件质量同时可以帮助项目组很好地掌握和评 估软件的研发过程进而改进研发过程未对缺陷进行分析就无法对研发流程 进行改进。 缺陷分析还能为软件新版本的开发提供宝贵的经验进而在项目开展之前指 定准确、有效的项目控制计划为开发高质量的软件产品提供保障。3.2 常见缺陷管理工具BugzillaBugfreeMantisJiraZenTao禅道QualityCenter/Application Lifecycle Management六、总结最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。