软件测试工具

1. 什么情况下需要安装测试组专门进行安装测试？ 安装可以很简单，像一些简单的桌面应用程序，只是简单地复制一些文件，对于这种应用，不需要专门的安装测试组，安装测试能够和其他测试合并在一起。 安装也可以很复杂，需要支持多个操作系统平台，多种数据库，多个版本的中间件，多种网络服务器，多种拓扑结构等，这就要求测试人员具有较好的操作系统、数据库及网络服务器等知识。一般需要一个专门的安装测试组来进行相关测试。 一般来说，企业级Java EE应用都需要使用数据库软件。 2. 典型的拓扑结构是三层架构？ 前端是网络服务器，中间是应用服务器，后端是数据库服务器。 3. 安装测试应该完成哪些内容？ 确保待测产品能够在所有支持的操作系统、数据库、应用服务器中间件、网络服务器、拓扑结构等各种组合情况下，被正确地安装和卸载。 确保安装文档的正确性和易读性。 通俗来说，就是确保安装相关的代码和相关的安装配置文档的正确性。 4. 如何规划安装测试？——安装测试计划 每一个测试人员都需要认真仔细地阅读安装测试计划，并且按照这个文档的规定来进行具体的测试，这是对每一个测试人员最基本的要求。测试计划的主体部分详细描述了安装测试的测试配置和测试场景，这部分内容也最多。 5. 安装测试的基本流程？ 　　a. 学习测试计划和测试用例：在安装测试计划中，包含所有的测试用例，一般要求每个测试人员对所有测试用例有一个基本的了解

0.软件缺陷的产生 软件缺陷 - Software Defect - Bug； 缺陷 的存在会导致软件产品在 某种程度上不能满足用户的需要 。 IEEE729-1983 对缺陷的标准定义： 从 产品内部 看，缺陷是软件产品开发或维护过程中 存在的错误、毛病等各种问题 ； 从 产品外部 看，缺陷是系统所需要实现的 某种功能的失效或违背 。 在软件的开发测试过程中项目组会特别关注软件缺陷的状况，这是因为一方面软件缺陷状况是项目质量和状态的重要指示数据，另一方面越到软件生命周期的后期修复软件缺陷的成本越高。 1.常见的缺陷 功能没有实现或与需求规格说明不一致； 界面、消息、提示、帮助不够准确或误导用户； 屏幕显示、打印结果不正确； 软件无故退出或没有反应; 边界条件未做处理，输入错误数据没有提示和说明； 运行速度慢或占用资源过多； 与常用的交互软件不兼容； 有时把尚未完成的小 功能 也归属于 软件缺陷 2.产生原因 在软件开发的过程中，软件缺陷的产生是不可避免的， ” 零缺陷 ” 是软件产品很难达到 一个 状态。 导致 软件缺陷产生的原因也是多种多样的，软件工程过程中的人、过程、工具都有可能导致产生软件缺陷，过程中的每一个环节都有可能产生缺陷，概括来说这些原因可以归结为四大类。 软件本身的复杂性 和抽象性： 在产品真正完成之前，每个人对软件的理解都不完全相同

0.认识需求 1. 业务需求：组织或客户的高层次目标、 描述为什么要开发系统 (Why)，希望达到什么样的目标、 一般 2-5 条，记录在 《 软件愿景和范围 》 文档中。 2. 用户需求： 从 用户角度 ，描述 用户使用产品必须要完成什么任务； 用户能使用系统来做什么(What)；通过用户访谈、调查、对用户使用场景进行整理等方法获取。 3. 功能需求： 描述 开发 人员 在产品中实现的软件功能， 描述开发 人员如何设计具体的解决方案来实现这些 需求 ( how )， 数量 往往比用户需求高一个数量级， 属于 《 软件需求规格说明书 》 的一部分。 <0>软件需求规格说明书 其包括： 功能需求： 1. 用户需求 2. 系统需求： 用于描述包含多个子系统的产品 ( 即系统 ) 的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。 3. 业务规则： 业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。 非功能需求： 1. 质量属性：产品 必须具备的属性或品质

1.基本介绍 白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。 2.白盒测试方法 白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。 1）语句覆盖：就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这里的“若干个”，意味着使用测试用例越少越好。 2）判定覆盖：使设计的测试用例保证程序中每个判断的每个取值分支（ t or f ）至少经历一次。 3）条件覆盖：条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支。 4）判定条件覆盖：判定 - 条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件取值组合至少执行一次。 5）条件组合覆盖：在白盒测试法中，选择足够的测试用例，使所有判定中各条件判断结果的所有组合至少出现一次，满足这种覆盖标准成为条件组合覆盖。 6）路径覆盖：是每条可能执行到的路径至少执行一次。 3.白盒测试基本问题 1）测试中尽量先用自动化工具来进行静态结构分析。

Web测试 验证软件是否正确实现了需求规格说明书中明确定义的需求 验证软件是否遗漏了需求规格说明书中明确定义的需求 验证软件是否将需求规格说明书中未定义的需求实现 验证软件是否对异常情况进行了处理，容错性好 验证软件是否满足用户的使用需求 功能测试： 1.链接测试： 超链接与说明文字相匹配 超链接对应的URL地址存在 超链接未连接到任何地址，什么都不做 链接的描述须精简有效 主要借助工具或脚本遍历链接 2.表单测试： 表单界面内容显示正确性 页面是否有不该有的源代码 下拉列表的选择性和可填性 单选框的独选型 长文本的滚动条 文本框的格式化 页面缩放带来的文字环绕 每个字段的类型和实际所接受的数据类型 界面输入框的可承载长度，超过最长长度是否不显示 3.Cookie测试： Cookie的作用域是否合理 用于保存一些关键数据的Cookie是否被加密 Cookie过期时间是否正确 有选择性地拒绝Cookie 4.Session测试： Session不能过度使用，会加重服务器维护Session的负担 Session的过期时间设置是否合理 Session的建值是否对应 Session过期后客户端是否生成新的SessionID Session与Cookie是否存在冲突 5.脚本测试： 对客户端脚本（JavaScript）和服务器脚本（PHP）进行测试 从应用层关注相应的脚本功能

软件测试含义： 通过手动或者工具对被测对象进行测试操作，从而验证实际结果与预计结果之间是否存在差异。 软件测试作用： 1、发现和修复软件中存在的缺陷 2、记录软件运行过程中产生的数据，为以后的决策提供数据支持。 3、降低同类型产品开发遇到问题的风险。 软件测试原则： 测试证明软件存在缺陷 不能进行穷尽测试 缺陷存在集群现象 某些测试依赖特殊的执行环境 测试应该尽早介入：为了发现和更好的解决软件中的缺陷 杀虫剂现象：同样的测试用例不能重复的进行多次，软件会产生免疫 任何软件不可能是完美的 软件生命周期： 软件计划与可行性研究 需求分析 软件设计（概要设计和详细设计） 编码 软件测试 软件生存周期 软件生存周期 运行与维护 测试级别： 单元测试：软件的底层代码结构，类、函数、组件等 集成测试：将多个单元模块组合，验证他们之间的沟通桥梁是否能正常工作，重点测试不同模块的接口部分。 系统测试：由测试人员充当用户，对软件主体进行测试，以需求说明书为指导 验收测试： α测试：内测，软件是初步完成品，不对用户进行开放，α测试不能由程序员或测试人员完成，发现的错误可以在现场立刻反馈给开发人员，由开发人员及时分析和处理。α测试可以从软件产品编码结束后开始 β测试：公测，软件有了较大的改进后进行的测试 γ测试：针对正式版本的候选版本。 其他： 回归测试：修改代码后

软件测试环境是进行软件测试所必需的工作平台和前提条件，包括硬件环境和软件环境，硬件环境指进行测试所必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境则指被测软件运行时的操作系统、数据库及其他应用软件等构成的环境。本文主要阐述在构建测试的软件环境中所用到的一些“复用”技术。 　　软件测试环境就象是一个舞台，可让所有的被测软件在这个舞台上各显其能，尽情“表演”，而我们的测试工程师们就像是一个个评委，对每个被测软件的“表演”打分、评判。因而，软件测试环境构建的是否合理、稳定和具有代表性，将直接影响到软件测试结果的真实性、可靠性和正确性，所以千万不可小窥了软件测试环境的搭建工作，它是测试实施的一个重要阶段和环节，其重要性是不言而喻的；另一方面，不同（版本）的操作系统、不同（版本）的数据库，不同（版本）的网络服务器、应用服务器，再加上不同的系统架构等的组合，使得要构建的软件测试环境多种多样、不胜枚举；而且现在随着软件运行环境的多样性、配置各种相关参数的“浩大工程”和测试软件的兼容性等方面的需要，使得构建软件测试环境的工作变得较为复杂和频繁，如果我们再按照以前那种按部就班地来搭建测试环境的方法，可真有点落伍了，不仅效率低下，而且灵活性、可复用性也较差。那么出路何在呢？ 　　在软件的开发过程中，创建可复用的软件构件库的技术

灰盒测试 灰盒测试，是介于 白盒测试 与 黑盒测试 之间的一种测试，灰盒测试多用于 集成测试 阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。 定义 灰盒 测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于 黑盒测试 以增强测试效率、错误发现和错误分析的效率。 学术含义 灰盒 (Gray Box)是一种程序或系统上的工作过程被局部认知的装置。灰盒 测试，也称作灰盒分析，是基于对程序内部细节有限认知上的 软件调试 方法。测试者可能知道 系统组件 之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解。对于内部过程，灰盒测试把程序看作一个必须从外面进行分析的 黑盒 。 灰盒 测试通常与web服务应用一起使用，因为尽管应用程序复杂多变，并不断发展进步， 因特网 仍可以提供相对稳定的接口。由于不需要测试者接触 源代码 ，因此灰盒测试不存在侵略性和偏见。开发者和测试者间有明显的区别，人事冲突的风险减到最小。然而，灰盒测试相对 白盒测试 更加难以发现并解决潜在问题，尤其在一个单一的应用中，白盒测试的内部细节可以完全掌握。 灰盒测试结合了白盒测试和 黑盒测试 的要素。它考虑了用户端、特定的系统知识和操作环境。它在

＃1）Alpha测试 它是软件行业中最常用的测试类型。该测试的目的是在将其发布到市场或用户之前，确定所有可能的问题或缺陷。 Alpha测试在软件开发阶段的最后但Beta测试之前进行。尽管如此，作为此类测试的结果，可能会进行较小的设计更改。 Alpha测试是在开发人员的网站上进行的。可以为这种类型的测试创建内部虚拟用户环境。 ＃2）验收测试 的验收测试是由客户端和验证结束系统的流量到底是否是按照业务需求或不执行，如果是按照最终用户的需求。仅当所有功能部件均按预期工作时，客户端才接受该软件。 这是测试的最后阶段，此后该软件将投入生产。这也称为用户验收测试（UAT）。 ＃3）临时测试 名称本身表明该测试是在临时基础上执行的，即不参考测试用例，也没有针对此类测试的任何计划或文档。 该测试的目的是通过执行应用程序的任何流程或任何随机功能来发现缺陷并破坏应用程序。 临时测试是一种发现缺陷的非正式方法，项目中的任何人都可以执行。没有测试用例就很难识别缺陷，但是有时可能无法使用现有的测试用例来识别临时测试期间发现的缺陷。 ＃4）辅助功能测试 可访问性测试的目的是确定残疾人是否可以访问该软件或应用程序。 在这里，残疾是指聋哑，色盲，智障，盲人，老年和其他残疾群体。进行各种检查，例如用于视觉障碍的字体大小，用于色盲的颜色和对比度等。 ＃5）Beta测试 Beta测试是由客户执行的正式类型的软件测试

1. 软件测试的生命周期 需求分析–>测试计划–>测试设计、测试开发–>测试执行、测试评估 2.软件的生命周期 需求分析 计划 设计 编码 测试 运行维护 3.开发模型和测试模型： 瀑布模型： 特点 ：串行的，适合于需求比较稳定的项目 缺点 ：测试阶段比较晚，发现缺陷的时机比较晚 螺旋模型： 特点 ：渐进式的，适合庞大，复杂，风险比较大的项目 缺点 ：风险投入的时间，人员，资金多 增量，迭代： 特点 ：适合较大的项目，降低项目的风险 传统的开发模型和敏捷的区别 （十二宣言）： 个体与交互重于过程和工具 （强调人与人之间的沟通） 可用的软件重于完备的文档 （轻文档）–>对文档的依赖降低了 客户协作重于合同谈判 （客户参与） 响应变化重于遵循计划 （拥抱变化） 在每对比对中，后者并非全无价值，但我们更看重前者 敏捷： 也是一种开发模型，新研制的开发模型 特点 ：敏捷（快） 1.周期比较短，最快一周，最多一个月 2.团队的人数一般不超过10个人 3.每一天都要开晨会 4.晨会的时间一般不超过10分钟 scrum(一种敏捷模式) scrum由product owner(产品经理)，scrum master(项目经理) team(研发团队)组成 敏捷中的挑战 ： 挑战1：轻文档 挑战2：快速迭代 4.测试的模型： （一）V模型： 发现bug晚，（和瀑布模型的缺点一样）