软件测试–复习

• 按开发阶段划分
• • 单元测试(Unit Testing)
  • 集成测试
  • 系统测试(System Testing)
• 测试用例
• 测试人员应具备的素质
• 软件测试的生命周期
• 开发模型和测试模型
• • 瀑布模型
  • 螺旋模型
  • 迭代、增量模型
  • 软件测试V模型
  • 软件测试W模型
• BUG
• • 什么是bugli>
  • bug的等级
  • 如何描述一个bugli>
  • bug的生命周期
  • 如果测试人员提了一个bug，开发人员已经修改了，但是测试人员测试的时候，发现bug依旧存在，有哪些原因li>
  • 如果碰到bug和开发人员产生冲突怎么办li>
• 手工测试(Manual testing)
• 自动化测试
• • 什么是自动化测试
  • 自动化测试的适用对象
  • 自动化测试的分类
  • 自动化测试的优缺点
  • 什么是selenium
  • • 元素的定位（find_element_by_什么）
  • 元素的定位
  • • 添加等待（智能等待和sleep）
    • 操作测试对象
    • 断言assertion：
• 性能测试
• • 为什么要进行性能测试
  • 概念和术语介绍
  • 性能测试分类介绍
  • • 性能测试
    • 负载测试（Load Testing）
    • 压力测试（StressTesting）
    • 并发测试（Concurrency Testing）
    • 可靠性测试（Reliability Testing）
    • 失效恢复测试（Failover Testing）

按开发阶段划分

单元测试(Unit Testing)

单元测试是对软件组成单元进行测试（测试某一个功能模块）。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

• 测试阶段：编码后或者编码前（TDD）
• 测试对象：最小功能模块
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：代码和注释+详细设计文档测试方法：白盒测试
• 测试内容：模块接口测试（按照接口设计文档，参数，输出）、局部数据结构测试、路径测试、错误处理测试、边界测试

Junit三部曲

1. 在Maven项目的pom文件中先添加依赖（根据不同的版本导入对应的依赖）
2. 在file-settings-Plugins搜索Junit并安装
3. 开始单元测试（选中要进行单元测试的类的类名，Ctrl + shift）

集成测试

**集成测试也称联合测试（联调）、组装测试，**将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。（）

• 测试阶段：一般单元测试之后进行
• 测试对象：模块间的接口
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：单元测试的模块+概要设计文档测试方法：黑盒测试与白盒测试相结合
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系 统的影响

系统测试(System Testing)

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统 测试执行阶段，包括回归测试和冒烟测试。

• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）
• 测试人员：黑盒测试工程师
• 测试依据：需求规格说明文档测试方法：黑盒测试
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

回归测试
回归测试是指修改了旧代码后或添加了新功能后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测 试将大幅降低系统测试、维护升级等阶段的成本。

冒烟测试（只测试核心的功能）
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。也可以理解为该种测试耗时短，仅用一袋烟功夫足够了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能和核心功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

验收测试
验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始
需求。

• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）。
• 测试人员：主要是最终用户或者需求方。
• 测试依据：用户需求、验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试(功能…各类文档等)

测试用例

测试用例（Test Case）是向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。（测试方式、标题、重要性、优先级、功能模块等），测试用例是伴随我们软件测试一生的东西，写好的测试用例是一个软件测试人员追求的目标。

测试人员应具备的素质

对软件测试感兴趣，有过硬的专业技能，良好的沟通能力，团队协作能力，发散性思维，具有责任感和压力感。

软件测试的生命周期

需求分析—->测试计划—->测试设计/开发—->执行测试—->测试 告—>运行维护

• 需求分析：分析需求，细化需求，验证需求的正确性和合理性
• 制定测试计划：规划测试人员数量，规划测试时间、范围和目的
• 测试设计/开发:分析需求，从细化的需求中提炼功能点，设计测试用例
• 测试执行：执行测试用例，记录bug
• 测试 告：测试的范围，有多少测试用例执行了，余留了多少测试用例，发现了多少bug，修改了多少bug（验证通过确定修改了），遗留的bug和解决方案
• 运行维护

开发模型和测试模型

开发模型有五种常用的，瀑布模型，螺旋模型，敏捷模型，迭代、增量模型

瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是 线性顺序进行的软件开发模式。

• 优点：强调软件的质量，每一次迭代进行严格的风险分析，讨论项目是否有必要进行下去
• 缺点：引入风险管理，会投入大量的人力物力
• 应用场景：前期需求不是很明确，并且有风险，项目比较庞大的系统开发

迭代、增量模型

迭代和增量模型一般配合使用，例如，一个系统有四个功能，ABCD四个模块，要在两周之内完成

• 迭代模型：第一周开发人员完成ABCD四个模块的基础功能，第二周，在基础功能之上进行细化和完善（迭代模型的的抗风险能力更强）
• 增量模型：第一周完成AB模块，第二周完成CD模块

敏捷模型是现在主流的模型，它轻文档，轻流程，看重目标和质量，可以适应需求的变化，目标是交付一个高质量可用的软件
scrum是现在主流的敏捷开发的一种形式，它主要包含三部分的成员，crum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

• PO：产品经理product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• SM：项目经理scrum master 负责召开各种会议，协调项目，为研发团队服务，负责保证整个敏捷流程的顺利实施
• ST：scrun Team研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付高质量的产品。

scrum的流程

1. 发布计划会议
2. 迭代计划会议
3. 开发过程中的每日站会
4. 产品演示评审会
5. 回顾会议

• 优点：左边开发的每一个阶段和右边测试的每一个阶段一一对应，同时也是有右边每一个测试的依据
• 缺点：测试介入晚，前期的错误和风险到后期才发现，会失去及时纠正的机会

软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试 与开发过程，图中明确表示出了测试与开发的并行关系。

如果测试人员提了一个bug，开发人员已经修改了，但是测试人员测试的时候，发现bug依旧存在，有哪些原因h2>

• 测试人员忘记拉取最新的代码到测试环境进行发布（先从自身找问题）
• 开发人员没有吧代码更新到测试环境
• 开发人员没有修改好

如果碰到bug和开发人员产生冲突怎么办h2>

• 先检查自己的bug是否描述清楚
• 检查bug的定级是否按照公司的标准来的
• 站在用户的角度去说服开发人员
• 不断提高自己的业务水平和技术水平
• 和开发人员，产品经理商量bug的解决方案

但这些都是套话啦，现实中情商高一点，多和开发人员走动走动搞好关系，出了bug一起解决岂不美哉！

手工测试(Manual testing)

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。

• 优点：灵活、发散性测试
• 缺点：执行效率慢，量大易错。

但要记住一点：

自动化测试

什么是自动化测试

自动化测试指软件测试的自动化，在预设状态下运行应用程序或者系统，预设条件包括正常和异常，最后评估运行结果。将人为驱动的测试行为转化为机器执行的过程。

自动化测试的适用对象

实施自动化测试的前提条件：需求变动不频繁、项目周期足够长、自动化测试脚本可重复使用

• 1需求变动频繁的项目，自动化脚本不能重复使用，维护成本太大，性价比低
• 2项目周期短，自动化脚本编制完成后使用次数不多，性价比低
• 3交互型较强的项目，需要人工干预的项目，自动化无法实施

自动化测试的分类

• UI自动化
  项目比较稳定，界面要稳定，在项目后期做UI自动化测试、用例维护量大
• 接口自动化
  项目前期就可以介入
  测试用例维护量较少
  接口稳定
• 性能自动化

自动化测试的优缺点

优点

• 在极短的时间内执行大量的测试用例
• 错误率低
• 完成手工测试难以完成的一些场景：多线程、高并发、死锁、稳定性（程序运行一个月之类）

缺点

• 开发成本和难度大
• 手工测试发现的缺陷更多
• 项目必须稳定，不能随便修改

什么是selenium

Selenium是ThroughtWorks公司一个强大的开源Web功能测试工具系列，支持多平台、多浏览器、多语言去实现自动化测试，Selenium2将浏览器原生的API封装成WebDriver API，可以直接操作浏览器页面里的元素，甚至操作浏览器本身（截屏，窗口大小，启动，关闭，安装插件，配置证书之类的）,所以就像真正的用户在操作一样。

Selenium已经从之前的1.0(RC)进化到了现在Selenium2(Selenium1+WebDriver)。

元素的定位（find_element_by_什么）

元素的定位

对象的定位应该是自动化测试的核心，要想操作一个对象，首先应该识别这个对象。一个对象就是一个人一样，他 会有各种的特征（属性），如比我们可以通过一个人的身份证 ,姓名，或者他住在哪个街道、楼层、门牌找到这 个人。

那么一个对象也有类似的属性，我们可以通过这个属性找到这对象。注意：不管用那种方式，必须保证页面上该属性的唯一性

webdriver 提供了一系列的对象定位方法，常用的有以下几种

• id （常用如果有id那么一定唯一）
• name

id 和name 是我们最最常用的定位方式，因为大多数控件都有这两个属性，而且在对控件的id 和name 命名时一般使其有意义也会取不同的名字。通过这两个属性使我们找一个页面上的属性变得相当容易。

• class name
• link text (有时候不是一个输入框也不是一个按钮，而是一个文字链接，我们可以通过link text来定位）
• link text partial（通过部分链接定位，这个有时候也会用到）
• tag name
• xpath (可以唯一确定一个元素)
• css selector

添加等待（智能等待和sleep）

定时等待
我们需要引入time 包，就可以在脚本中自由的添加休眠时间了

智能等待
通过添加implicitly_wait() 方法就可以方便的实现智能等待；
implicitly_wait(30)的用法应该比time.sleep() 更智能，前者等到则直接继续向下执行，后者则必须等满这个时间

操作测试对象

前面讲到了不少知识都是定位元素，定位只是第一步，定位之后需要对这个原素进行操作。鼠标点击呢还是键盘输 入，这要取决于我们定位的是按钮还输入框。
一般来说，webdriver 中比较常用的操作对象的方法有下面几个：

• click 点击对象
• send_keys 在对象上模拟按键输入
• clear 清除对象的内容，如果可以的话
• submit 点击提交
• text 用于获取元素的文本信息

断言assertion：

断言assert：验证应用程序的状态是否同所期望的一致。

断言被用于三种模式: assert、verify、waitfor

• Assert 失败时，该测试将终止。
• Verify 失败时，该测试将继续执行，并将错误记入日显示屏。也就是说允许此单 验证通过。确保应用程序在正确的页面上。
• Waitfor用于等待某些条件变为真。可用于AJAX(异步)应用程序的测试。（如果该条件为真，他们将立即成功执行。如果该条件不为真，则将失败并暂停测试。直到超过当前所设定的超时时间。 一般跟setTimeout时间一起用）

断言常用的有：

assertLocation（判断当前是在正确的页面）、

assertTitle（检查当前页面的title是否正确）等

性能测试

为什么要进行性能测试

• 应用程序是否能够很快的响应用户的要求li>
• 应用程序是否能处理预期的用户负载并有盈余能力li>
• 应用程序是否能处理业务所需要的事务数量li>
• 在预期和非预期的用户负载下，应用程序是否稳定li>
• 是否能确保用户在真正使用软件时获得舒服的体验li>

概念和术语介绍

• 并发数

系统用户数：简单地说就是该系统的注册用户数。例如，BestTest论坛里存在6666个注册用户，他们可以是活跃 的，也可以是僵尸的。

• 响应时间（Reponse Time）

又叫请求响应时间：TTLB（time to last byte）对请求作出响应所需要的时间
络传输（请求）时间+服务器处理（一层或多层）时间+ 络传输（响应）时间。

• 事务响应时间（Transaction Reponse Time）

事务是指一组密切相关的操作组合。例如一次登录可能包含了多次HTTP请求，如：判断用户是否存在是否正确已登录个HTTP请求。
该数值对用户的意义更直观

• 每秒事务通过数（Transaction Per Second）

TPS 是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。
当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的增减而改变。

• 点击率（Hit Per Second）

每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。点击率越大，服务器压力越大。这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。

• 吞吐量（Throughput）

单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力，一般来说用请求数/秒或是页面数/秒 来衡量，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从 络的角度来说，也可以用字节 数/天来衡量。

• 思考时间（Think Time）

思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。 资源利用率
不同系统资源的使用情况。CPU,Memory，磁盘， 络。

性能测试分类介绍

性能测试

是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能能否满足生产系统要求。Performance Testing是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。该测试是一种正常的测试，主要是测试系统正常使用时是否满足要求。

负载测试（Load Testing）

负载测试是在被测系统上不断增加压力，直到各项指标达到饱和，例如“响应时间”超过预定指标或者某种资源使用 已经达到饱和状态。这种测试方法可以找到系统的处理极限，为系统调优提供数据。

压力测试（StressTesting）

压力测试是测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系 统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景-例如增加用户数 对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等。

并发测试（Concurrency Testing）

并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在死锁 或者其他性能问题。

可靠性测试（Reliability Testing）

可靠性测试是通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

失效恢复测试（Failover Testing）

• 失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障， 用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。
• 一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出 现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常 发挥作用
• 不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统