软件测试方法

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

今日在学习国内软件测试业界前辈的经验之谈时，碰巧遇到了有关回归测试的问题，结合自身的思考，做个简单的总结记录。 1、回归测试，无法回避的测试活动 从事软件测试的朋友可能有相同的体会，无论所参与的产品采用何种软件开发模型进行开发，在产品生命周期内，测试开展的活动中，必定不会缺少回归测试这项活动。 为什么这么说呢？我个人的理解如下。 不同的开发阶段，需要进行不同的测试活动。 无论所参与的产品采用何种软件开发模型进行开发，对于测试活动而言，在不同的开发阶段少不了要进行不同的测试活动，比如模块测试、集成测试、系统测试、验收测试等，开展这些测试活动时，测试的对象可能是完整产品的某个功能模块、或某几个功能模块的集成、或所有功能模块的集成等，实际执行测试的时候，可能相同的功能会重复执行多次，当然，每个阶段的测试深度可能会有所不同，这取决于采用的测试策略等。 软件质量很大程度上决定了某些测试活动的开展。 比如，集成测试或系统测试阶段，一轮测试结束后，某些功能模块仍存在缺陷，此时就需要按照缺陷管理流程，在缺陷生命周期内进行跟踪、流转，待研发人员将缺陷修复后，进行验证及确认，而后进行回归测试。 处于维护阶段的系统，部分功能发生变更后，需要进行回归测试，以确保功能变更对原有功能没有造成影响。 迭代更新的系统，新一轮迭代新增的功能构建到原有产品中后，需要对构建后整体的功能进行测试，此时也会涉及到回归测试。

1.测试计划的定义 描述了要进行的测试活动的范围、方法、资源和进度的文档； 是对整个信息系统应用软件组装测试和确认测试。 它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。 测试计划可以有效预防计划的风险，保障计划的顺利实施。 2.测试计划的目的 （1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。 （2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。 （3）开发有效的测试模型，能正确地验证正在开发的软件系统。 （4）确定测试所需要的时间和资源，以保证其可获得性、有效性。 （5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。 （6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。 3. 测试计划编写的6个要素 1）why—为什么要进行这些测试； 2) what—测试哪些方面，不同阶段的工作内容； 3) when—测试不同阶段的起止时间； 4) where—相应文档，缺陷的存放位置，测试环境等； 5) who—项目有关人员组成，安排哪些测试人员进行测试 6) how—如何去做，使用哪些测试工具以及测试方法进行测试。 4. 测试计划模板 可以参考这个 博客 和这个 博客 。 以下为我结合两个博客，做出的一个适合自己的测试计划模板： 4.1 引言 4.1

中国有句老话：过犹不及。软件开发中也有一个概念：“过度设计”，说的是为了实现一些简单的功能需求，设计出非常臃肿的结构，代码间的继承、依赖、调用非常复杂，开发工作量大并且难以维护。在软件测试工作中，也存在类似“过度设计”的问题，特别是大中型的软件企业，人数比较多，各方面工作流程趋于稳定和规范，问题更容易发生。 出现“过度测试”的原因非常简单：忽视了软件测试工作的终极目标与核心价值，而过于关注测试活动过程。这里我列出一些“过度测试”的案例，我们一起分析一下。 测试工作必须依赖完整规范的需求文档 回忆一下公司创业初期，那时做项目也没有特别规范的文档，一般就是几个Excel表格、一些Word说明，不过项目也都顺利完成了。可是现在好像如果没有规范的文档，测试工作就寸步难行了，为什么呢？我们经常看到测试工程师整天催PD和DEV把文档补全，催得很辛苦也很郁闷，看起来就像是测试团队要为文档的质量负责一样。有时甚至出现了，测试团队自己动手维护需求文档的现象。是不是测试团队不拿着一份完善的文档，就寝食难安呢？ 对于测试团队来说，需求文档确实很重要，但是我们真正的目标是，弄清用户的需求和开发的实现方案，然后便可以设计测试方案。阅读文档是方法之一，交流和讨论其实更重要，期待文档中能说明一切信息，是有点不实际的，特别是互联网公司，需求信息爆炸，创新层出不穷，文档更像是字典，只记录重要的原子信息

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

回归测试的定义： 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 1.回归测试是指重复以前的全部或部分的相同测试。 2.新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。 3.回归测试的重心，以关键性模组为核心。 回归测试的好处： 自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。 回归测试的存在意义： 在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。 回归测试的需求： 对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。 测试用例的选择： 对于一个软件开发项目来说

软件测试含义： 通过手动或者工具对被测对象进行测试操作，从而验证实际结果与预计结果之间是否存在差异。 软件测试作用： 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晚，（和瀑布模型的缺点一样）