软件测试的生命周期：

V模型：与软件开发阶段呼应
- 软件开发：需求分析-->概要设计-->详细设计-->编码阶段
- 软件测试：单元测试-->集成测试-->系统测试-->验收测试
从基本流程的角度讲：
- 需求阶段：测试人员了解需求, 对需求进行分解, 得出测试需求
- 计划阶段：根据需求编写测试计划 / 测试方案
- 设计阶段：测试人员适当的了解设计, 对于设计测试用例是很有帮助的, 测试人员搭建测试用例框架, 根据需求和设计编写一部分测试用例
- 编码阶段：测试人员一般是不需要编码的, 但已经编码的模块, 专业的白盒测试人员可以计划执行单元测试, 完善, 细化测试用例以及调整测试计划和方案
- 测试阶段：测试阶段是软件测试人员最为重要的工作阶段, 根据测试用例和计划执行测试, 在执行的过程中记录, 管理缺陷, 测试完成后编写测试报告
- 运维阶段：测试人员需要参加项目的实施工作. 测试人员对项目产品的业务和操作非常了解, 加上测试人员的沟通表达能力一般都比较强, 所以测试人员可以参加用户使用软件的培训, 在试运行项目时收集问题并及时反馈给相关负责人

页面加载慢的原因

背景

记得以前有个培训班的老师过来宣传，他当时问了我们一个问题，“打开一个网页慢，你能说出10个原因么？”，我脑海里立刻就出现了网速慢、电脑卡等原因，但是发现自己能说出的不超过五个，自己还是学web的，GG。今天突然想到了这个问题，就总结下

带宽不足

首先想到的就是自己网速的问题，但是一般网速在1M以上的，打开网页一般不会是很慢的。网站服务器的带宽不够的话，当大量用户访问的时候，网页的加载也是很慢的，这就是网络的出口端和入口端两个方面

硬件配置低

本机的配置也会是一方面的，但是只要不是老赛扬单核+512M的配置，一般不会是电脑配置的问题。服务器端的配置也是同样的道理。

CPU或者是内存被占满

CPU或者是内存被占满的时候，打开网页很是会很慢的，因为整个电脑都很慢

DNS解析慢

域名的解析是需要专门的域名解析服务器来完成的，DNS解析包括往复解析的次数及每次解析所花费的时间，它们两者的积即是DNS解析所耗费的总时间，在http请求的过程中，域名解析和建立连接占的时间很多。

JS阻塞请求

写的js代码出现问题，解析就会花费很长时间，这两个js请求之间会出现一个很大的空隙，就会导致这段时间的资源加载都被阻塞住，

接受数据时间过长

http请求的大部分时间应该花在后面几个阶段，比如等待响应和接收数据。但是，如果接收数据的时间太长了，长到数百毫秒甚至以秒计算的时候，那也是有问题的。这种情况一般是因为下载的内容太重了，例如大图片、大脚本等。这类问题可以使用GZIP压缩、图片压缩或者JS/CSS的minify等手段来解决。

加载某个资源太慢

如果某个请求比其他的请求多出很多的时间，那么一般情况就是某个资源的加载太慢，导致了整个网页变慢，原因有可能是1)资源在第三方站点上，他们很慢；2)这个资源太大了；3)这个资源使用的域名有问题

后端代码问题

主要有代码冗余、数据库发生锁死、动态请求时间过长等，这就需要RD优化一切可以优化的东西了

前端页面请求的资源过多

onload之前如果有几百行，速度自然会慢的，如果请求的资源不存在，那么速度将会更慢

网页本身中包含了追踪或者是分析用户的工具

导致网页的加载时间变的慢，比如之前海盗湾中会给用户的电脑插入挖矿的js脚本

打开开发者工具看network里的瀑布图。

原因一：http请求次数太多

解决：减少http请求次数
①　图片地图：把多张图片整合到一张图片中，以位置定位超链接。
②　CSS Sprites合并图片，通过指定CSS的backgroud-image和backgroud-position来显示元素。
③　合并JS脚本和CSS样式表。
④　使用外部JS和CSS文件。

原因二：接收数据时间过长，如下载资源过大

解决：对HTTP传输进行压缩，即在js，css、图片等资源已经压缩的基础上，在HTTP传输过程中的再次压缩。客户端可以通过Accept-Encoding头来声明浏览器支持的压缩方式，服务端通过Content-Encoding来启用压缩，配置压缩的文件类型，压缩方式。gzip使用无损压缩，压缩效果最佳，已经成为使用最为普遍、支持的浏览器最多的数据压缩格式。

原因三：JavaScript脚本过大，阻塞了页面的加载

解决：将JavaScript脚本放在标签前。script没有async和defer时，JS文件将在下载后立即执行。这种情况下，script放在顶部会阻塞页面呈现，在网速慢的情况下会导致“白屏”，直到脚本下载完毕才继续呈现页面。因此，script放在底部可以让页面尽快呈现。

原因四：CSS、JavaScript、图片等需要重复加载

解决：静态资源统一放在一个静态域名上，减轻重复下载静态资源的负担。

原因五：cookie影响

解决：减小cookie的影响
①　去除没有必要的cookie，如果网页不需要cookie就完全禁掉。
②　将cookie的大小减到最小：减小HTTP请求报文的大小，提高响应速度。
③　设置合适的过期时间：cookie信息将存储到硬盘上，即使浏览器退出cookie还会存在，只要cookie未被清除且还在过期时间内，该cookie就会在访问对应域名时发送给服务器。
④　通过使用不同的domain减少cookie的使用：cookie在访问对应域名下的资源时都会通过HTTP请求发送到服务器，但在访问一些资源，如js，css和图片时，大多数情况下cookie是多余的，可以使用不同的domain来存储这些静态资源，这样访问这些资源时就不会发送多余的cookie，从而提高响应速度。

原因六：网页资源过多

解决：使用CDN部署网络以提高下载速度，可以先通过免费的CDN供应商来分发网页资源。
原因：DNS解析速度
DNS解析是从域名到IP的解析。DNS解析包括往复解析的次数及每次解析所花费的时间，它们两者的积即是DNS解析所耗费的总时间。许多人无视了DNS解析的因素，其实它对网站解析速度也是十分重要的。可以更换延迟比较低的DNS服务器。

测试应该什么时候介入

为避免软件缺陷造成的高成本支出或损失，软件测试越早介入越可以帮助规避风险。

一个项目中，测试工作如何介入？

项目前期：跟进需求，充分理解功能需求
项目开发阶段：准备测试素材，如测试用例，测试数据，测试自动化等。
项目测试阶段：执行测试
验收阶段：准备环境给产品负责人验收
上线后：进行线上验证。

软件测试与软件开发的异同

工作和产出
- 软件开发是通过写代码来生成一个软件，也就是从无到有的过程。
- 软件测试则是测试一个软件有没有问题，能不能上线，也就是把软件变得更好，起到把关质量的作用。
- 软件开发是有产品产出的，而软件测试则没有，但是这并不影响软件测试的重要性。
  　　
工作内容和压力
- 软件开发需要写大量的代码，要有很多的创造力，比较费脑。
- 软件测试代码则较少，相对来讲轻松一些，只要耐心、细心就可以胜任。
- 软件开发从业者随着年龄的增长，可能会因为脑力和体力跟不上而被迫转行。
- 但软件测试则不会，因为它是一个需要很多经验，越老越吃香的行业。
- 软件开发人员有时为了赶项目进度常常需要加班熬夜，软件测试人员则不需要加班，正常跟着进度工作就可以了。
  　　
行业开发与测试人员比例分析
- 软件开发行业通常以男性为主导，软件测试行业则没有性别歧视，男女比例基本相当。
- 国外企业软件开发与测试人员的比例为1:1到1:2.5，国内企业的比例却是4:1甚至是10：1，可见软件测试行业的人才缺口相当大。
- 软件测试的薪资水平相比于开发也不低，刚入行的软件测试人员起薪一般都在8000元左右。

为什么选择软件测试

- 1 在接触软件测试过程中，觉得对测试很感兴趣，愿意去学习一些相关知识，而没有排斥的感觉；
- 2 目前的求职的行业选择是互联网IT行业，经过深入了解软件测试行业以后觉得还是比较有发展前景的；
- 3 研发相比测试来说，需要技术上的深度研究，并且工作量更大更累，相比之下，我的技术水平和职业追求更适合测试；
- 4 对比自身的技术水平和性格特点，比如认真踏实、耐心等，觉得我自己更适合测试岗

软件测试岗位的理解+职业规化

职业认识

软件测试的意义
- 尽早、尽量用最少的测试发现尽可能多的问题，以保证软件产品的质量。
什么是测试工程师？
- 以软件开发为例，宏观上说测试工程师就是软件质量的把关者，在一个软件开发流程中测试人员要与开发人员一起对软件的研发进行负责，软件进行质量把关，开发进行功能实现，相辅相成。
- 测试又分为传统的测试工程师和测试开发工程师，测试开发工程师（以下简称测开）就要在上述的基础上最少在掌握一门脚本语言，两门及以上更好，脚本语言包括但不局限于Python，golang，shell等等因为测试开发工程师其实是造轮子的，换言之就是开发测试用的各种工具；测试工程师对代码要求较测开低一些，但不是一窍不通（我面试的时候都会遇到代码问题），不懂代码层次的问题的话其实就不好进行测试分析这个后面再解释为什么。
测试开发工程师的工作职责和内容
- 测试工程师简单点说就是找bug，然后反馈给开发人员，不要小看这个工作。
- 首先很明显的bug开发人员有时候自己就能找到，测试人员要有比开发人员更加全面的想法才能找到深层次的问题点，
- 其次，要端正一个态度就是测试人员不是一个电脑小白，相反国外顶级的测试开发工程师同时也是顶级的开发工程师甚至更厉害，所以作为一个测试工程师一定要有继续学习的精神和心态，然后明白测试工程师要会写测试用例，要会使用自动化工具，甚至白盒测试工程师要懂代码，要具备广阔的知识面。
自动化测试
- 首先说一下自动化测试是什么？自动化测试从职能上讲就是去在一定的框架下去开发一些自动化测试脚本来实现QA所做不到的事情，拿fgo来举栗子比较合适，众所周知fgo核心玩法之一就是抽卡，这个抽卡是有概率的（欧皇请自动左滑），而QA是不可能去抽几十万次甚至上百万次来验证概率问题，这时候就要自动化脚本来模拟抽卡去抽，看看概率算法是否有问题，本来自动化测试其实在某种意义上是一种灰盒测试，但是现在很多公司会把自动化测试归到测开里面去，所以现在自动化就偏白盒一些。
- 第二个要说的就是语言，现在自动化测试流行的语言就是Python，shell，golang，（据说要是cpp厉害的也可以），不是很死板，但主流一定是脚本语言。
- 游戏QA的话要求会更高，因为传统软件测试要看的方面游戏要测试，而传统软件不作为重点的地方游戏也要测试，所以游戏测试工程师相对来说是工作量会大一些。
技术向的晋升路线
- 初级测试工程师：测试计划、测试文档、测试执行、结果整理等，门槛不高。
- 测试开发工程师：核心-编程能力、自动化能力。
- 测试架构师：在整个测试架构上参与和管理测试，更强调测试流程管理和质量监管，以及白盒测试能力，对测试工具和平台的开发等
提升核心竞争力
- 技术：编程、自动化、技术架构能力
  - 语言：java和Python等脚本语言。学生的能力。
  - 自动化：测试领域生产力，基础能力。3-5年核心。
  - 架构：更深入的能力，流程管理和白盒测试能力等。5年以上核心。
- 领域知识：领域架构能力、业务领域、数据意识。
  - 数据：核心。
- 软实力：沟通、管理
测试工程师的核心业务
- 前端UI测试：web，app，gui
- 后端接口测试：sdk，restful，rpc
- 非功能质量：性能，安全
- 流程管理：持续集成，持续交付，devops
- 数据分析：监控平台，数据分析平台，ai辅助平台

职业规划

《软件测试质量保证》所述职业规划
- [1～2年]，测试技能：熟悉整个测试过程及产品业务领域，学习和掌握自动测试工具，学习测试自动化编程技术；开发和执行测试脚本，承担系统测试实施任务；学习编程语言、操作系统、网络与数据库方面的技能。
- [3～4年]，测试过程：深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；进一步了解产品业务领域，改进测试自动化编程技术，能指导初级测试工程师；加强编程语言、操作系统、网络与数据库方面的技能。
- [4～5年]，测试组织工作：管理1～3名测试工程师，担任任务估算、管理及进度控制；进一步培养在软件项目管理及支持工具方面的技能。
- [5～6年]，技术管理：管理4～8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划冰制定测试计划；研究测试的技术手段，保持使用项目指导及支持工具的技能；用大量的时间为其他测试工程师提供技术及过程方面的指导；开始与客户打交道并做演示推介。
- [6～12年]，测试管理：管理8名以上测试工程师，负责一个或多个项目的测试工作，与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。
发展取决于三点：业务技能、专业技能(测试技能)、管理技能。
- 通过对自己这三方面的评估，综合选择自己要走的道路。
- 测试岗位路线
  - 管理：IT做管理，技术深度与广度都会有一定要求，基本管理技能为主，专业技能、业务技能为辅。管理者不懂技术，很难服众。
  - 技术：有技术不愁没工作，当然人品还是要的。
  - 建议技术高薪方向：白盒测试、自动化测试、性能测试、安全测试，当然有机会走管理也别放过机会，毕竟管理薪资不低哈。
- 转岗其他路线
  - 方向选择：很多入行测试只是过渡。由测试岗位的锻炼，涉及到软件各个岗位的接触。此时转岗容易不少。
  - 比如业务技能强、市场敏感度、洞察力厉害的建议产品经理、运营方向；
  - 比如喜欢编码加班，咳咳，是喜欢与机器打交道建议研发、运维方向等；
  - 喜欢与机器打交道的可以走运维、研发路线。
  - 喜欢与人沟通的可走销售、HR路线。

软件测试概述/对测试的理解

=====================================================

概述

简单认识软件测试，可以从四个方面理解
- 软件测试概述
- 测试用例概述
- 测试分类概述
- 软件质量评估

=======================================================

1-软件测试概述

对软件测试的理解

软件测试是软件工程中的一个重要组成部分，基本与开发并行，开发写代码，测试测代码。
软件测试工程师通过多种测试方法，和代码管理工具、自动化工具等，对软件产品的多个模块，如功能和性能等进行测试，以检查软件产品是否有bug，来保证产品的质量。

软件测试的作用

确保软件产品质量：软件测试是软件产品质量保证的重要措施之一
术业有专攻：软件测试人员比其他人做软件测试测试工作，效率更高，效果更好；

软件测试的关键点

尽早发现缺陷：伴随软件开发的各个环节，及时发现问题解决问题，避免最后问题堆积导致无法解决或解决工程量巨大。
用尽量少的测试用例发现尽可能多的缺陷
提升发现缺陷的效率

软件测试的定义

测试定义
- 通过设计和运行测试用例，来校验被测系统的实际输出与预期输出是否一致，最终目标是保证系统应符合需求。
  - 根本目的：确保被测系统符合用户需求
  - 基本手段：设计测试用例
  - 执行方式：手工/自动化
  - 测试策略：动态运行/静态审阅
  - 通用流程：计划、设计、实施、评估
- 软件测试以需求为中心。
- 需求：定义需求(委托方)--分析需求(双方)--实现需求(研发)--校验需求(测试)。
测试分类：
- 软件测试包括动态测试和静态检查两类方法；
- 测试的执行包括人工和自动化两类策略。

=======================================================

2-测试用例概述

定义

基于风险最低、效率最高、分而治之的测试设计原则；
能代表需求的小的测试单元，描述用户预期输出，反映系统实际执行结果。

测试用例组成

输入+输出+测试环境
- 输入：测试数据和操作步骤
- 输出：系统预期执行结果
- 测试环境：是系统环境设置，即进行软件测试所必需的工作平台和前提条件
具体：
- 分为9个方面：用例编号/测试项/测试标题/用例属性/重要级别/预置条件/测试输入/操作步骤/预期结果/实际输出
  　- 一般情况下分为以上几项可根据公司要求进行增删

测试用例的基本属性

典型性：
- 能揭示最有可能存在缺陷的地方，能代表和覆盖合理与不合理、合法或不合法的情况。
可测试性：
- 一个测试用例的预期输出必须是可以检验的，可以根据相关开发文档得到明确的、可判定的结论。
可重现性：
- 对于相同的测试用例，系统的预期执行结果应该完全相同；
- 否则，如果系统预期输出存在不确定性，一旦实际运行该测试用例，也无法进行校验。
独立性：
- 测试用例应尽量独立

=======================================================

3-测试分类概述

不同角度的测试分类

从测试阶段或对象的角度：
- 单元测试、集成测试、系统测试和验收测试；
从测试技术的角度：
- 黑盒测试、白盒测试和灰盒测试；
从测试目标的角度：
- 回归测试、功能测试、性能测试、 Alpha测试、Beta测试、压力测试、负载测试、安全性测试、配置测试、安装测试、可用性测试、可恢复性测试等。
从测试执行方式的角度：
- 手动测试、自动化测试和半自动化测试。

从测试阶段或对象的角度

V模型：与软件开发阶段呼应
- 软件开发：需求分析-->概要设计-->详细设计-->编码阶段
- 软件测试：单元测试-->集成测试-->系统测试-->验收测试
单元测试
- 是针对每个单元的测试。
- 用于验证一个单元模块的功能是否正常。
- 一个单元模块可以包括几行或上百行代码。
- 单元测试与编码过程是紧密联系的，单元测试有时也认为是编码阶段的一个活动。
集成测试：
- 是将不同单元模块组合在一起，形成更大组件的过程。
- 用于查找单元或组件间的接口错误，其关注的重点是那些在单元测试中不能被发现的缺陷。
系统测试：
- 检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。
- 用于评估整个系统的行为并确保系统行为符合用户需求，并评估系统与硬件设备、运行环境和应用程序等之间的接口。
验收测试：
- 部署软件之前的最后一个测试操作。
- 测试范围类似系统测试，通常由系统提供者和客户共同完成的。
- 验收测试使客户确信应用程序具有所需的特性并且能够正确的运行。

从测试技术的角度

黑盒测试：
- 关注的是与产品的外部行为相关的缺陷，此时并不考虑产品的内部结构或运行逻辑。
白盒测试：
- 关注的是与代码内部结构相关的缺陷，因此，需要测试人员掌握一定的编程技术。
灰盒测试：
- 是综合运用黑盒测试和白盒测试技术的一种混合测试方法。

从测试目标的角度

功能测试：
- 针对软件功能需求进行测试，目的是检查应用程序的行为是否符合预期。
性能测试：
- 用于验证系统是否满足规格说明的性能需求，例如容量和响应时间等。
Alpha测试（ α测试）：
- 在软件发布前，有时会让小规模、有代表性的潜在用户试用软件;
- 如果由开发机构人员来模拟潜在用户开展测试，则称为α测试。
Beta测试（ β测试）：
- 软件的早期版本被发布给具有代表性用户群来测试，称为β测试。
- β测试常被用于面向大众市场的系统、计算机游戏和类似的应用程序。
回归测试：
- 是软件版本修改后的重新测试，可应用于所有测试级别;
- 目的是确保被修改组件的行为没有改变，不会造成意外结果.
压力测试：
- 以设计的最大负载或超过最大负载来运行软件，用于确定系统运行的负载界限。
负载测试：
- 通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。
安全性测试：
- 是对产品进行检验，以验证产品符合安全需求定义和产品质量标准的过程。
- 用于测试系统在遭遇未授权访问、计算机犯罪和破坏时是否能保护自己
配置测试：
- 当开发的系统需要应用于多种环境配置时，需要对每种配置进行测试，以检测系统行为是否符合规格要求。
- 包含硬件配置和软件配置。
安装测试：
- 在目标环境中通过安装来验证软件及其安装过程。
- 目的是确保该软件在正常或异常情况的不同条件下都能进行安装，且安装后可立即正常运行。
可用性测试：
- 用于评估系统使用的简易程度，交互是否具有人机工程学设计以及用户文档使用的有效性。
可恢复性测试：
- 用于检验系统在灾难或意外宕机后的重启能力。

从测试执行方式的角度

手动测试：
- 人工执行测试。
- 即根据测试用例中描述的规程，不借助特殊的软件工具，人工来运行被测系统，观察系统实际输出是否符合测试用例的预期输出。
自动化测试：
- 软件测试的自动化，是一个将以人为驱动的测试行为转化为机器执行的过程。
- 目的是节省人力、时间或硬件资源，并提高测试效率。

=======================================================

4-软件质量评估

狭义和广义的软件质量

狭义的软件质量：软件的内部质量，即软件无“故障”；
广义的软件质量：产品质量、过程质量和客户满意度

软件测试和软件质量

- 软件测试是软件质量保证的关键步骤。
- 但提高软件质量的途径是改进软件开发过程的质量，而不是提高软件测试。

功能测试

1、链接测试　　
（1）、测试所有链接是否按指示的那样确实链接到了该链接的页面；
（2）、测试所链接的页面是否存在；
（3）、保证Web应用系统上没有孤立的页面(所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问)。

2、表单测试
（1）、注册、登陆、信息提交等，必须测试提交操作的完整性，以校验提交给服务器的信息的正确性；
（2）、用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等；
（3）、检验默认值的正确性；
（4）、如表单只能接受指定的某些值，测试时跳过这些字符，看系统是否会报错。

3、Cookies测试(session测试同)
（1）、Cookies是否起作用；
（2）、Cookies是否按预定的时间进行保存；
（3）、刷新对Cookies有什么影响。

4、设计语言测试
（1）、使用哪种版本的HTML；
（2）、验证不同的脚本语言。例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等。

5、数据库测试
（1）、数据一致性错误：主要是由于用户提交的表单信息不正确而造成的；
（2）、输出错误：主要是由于网络速度或程序设计问题等引起的。

性能测试

1、连接速度测试
（1）、Web系统响应时间；
（2）、超时的限制。

2、负载测试
（1）、某个时刻同时访问Web系统的用户数量；
（2）、也可以是在线数据处理的数量。

3、压力测试
（1）、压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
（2）、压力测试的区域包括表单、登陆和其他信息传输页面等。

可用性测试

1、导航测试
（1）、导航是否直观
（2）、Web系统的主要部分是否可通过主页存取
（3）、系统是否需要站点地图、搜索引擎或其他的导航帮助
（4）、Web应用系统的页面结构、导航、菜单、连接的风格是否一致
（5）、Web应用系统导航帮助要尽可能地准确。Web应用系统的层次一旦决定，就要着手测试用户导航功能。

2、图形测试
一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）、要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间；
（2）、Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面；
（3）、验证所有页面字体的风格是否一致；
（4）、背景颜色应该与字体颜色和前景颜色相搭配；
（5）、图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

3、内容测试
检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。

4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？当然，对界面的整体测试并不能单靠个人直觉来评定；每个人的审美观、专业角度、系统面向的行业及用户、甚至性别与年龄等等，都是可能导致对界面作出不同评价的因素。所以要明白在对整体界面的测试过程中，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

兼容性测试

1、平台测试
在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

2、浏览器测试
（1）、浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
（2）、测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

安全性测试

（1）、现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等；
（2）、Web应用系统是否有超时的限制，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用；
（3）、为了保证Web应用系统的安全性，需要测试相关信息是否写进了日志文件、是否可追踪；
（4）、当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性；
（5）、服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
（6）、通过模拟攻击的形式拷贝Web应用程序的某个功能点的url地址，然后打开新的页面输入该url地址看其是否能跨过系统的登录模块直接进入该功能点。
（7）、服务器端IIS是否设置了默认文档功能。
（8）、IIS服务器的主目录应该与操作系统的安装路径设置在不同的盘符下。

性能测试

是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。

压力测试（Stress Testing）

压力测试的主要任务就是获取系统正确运行的极限，检查系统在瞬间峰值负荷下正确执行的能力。
例如，对服务器做压力测试时就可以增加并发操作的用户数量；或者不停地向服务器发送请求；或一次性向服务器发送特别大的数据等。看看服务器保持正常运行所能达到的最大状态。
人们通常使用测试工具来完成压力测试，如模拟上万个用户从终端同时登录，这是压力测试中常常使用的方法。

负载测试（Volume Testing）

用于检查系统在使用大量数据的时候正确工作的能力，即检验系统的能力最高能达到什么程度。
例如，对于信息检索系统，让它使用频率达到最大；对于多个终端的分时系统，让它所有的终端都开动。
在使整个系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。
是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。

压力测试和负载测试

100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。

自动化测试原理与框架

自动化测试

概述
- 自动化测试，就是把以人为驱动的测试行为转化为机器执行的过程。
- 自动化测试往往通过一些测试工具或框架，编写自动化测试用例，来模拟手工测试过程。
- 阶段：一般落后于新功能的手工测试阶段，可以在手工用例执行完成或功能上线后，再补充。
分类
- 自动化测试广义说法包括，白盒自动化测试，GUI自动化测试，性能自动化测试
- GUI自动化测试的原理：通过软件模拟用户实际的鼠标和键盘操作，实现自动化执行和操作的过程。
- 性能自动化测试的原理：通过客户端模拟多个虚拟用户并发请求，来检验服务器的性能行为是否满足系统要求。
自动化测试的优点：
- 1、通过录制，编写脚本执行测试，减少回归测试
- 2、执行手工测试困难，或不可能做得测试，（模拟多个用户并发测试）
- 3、更好的利用资源，（将繁琐的任务自动化，利用晚上或周末的时间进行执行自动化测试）
- 4、测试具有一致性和可重复性，（重复多次相同的测试，在不同配置下执行，可以在不同的操作系统测试）
- 5、测试的复用性
- 6、缩短测试的时间和周期
自动化测试局限：
- 1、不能取代手工测试：手工测试比自动化测试发现的bug要多；
- 2、自动化测试对测试人员的要求相对更高；
- 3、测试用例需要根据版本迭代进行更新，有一定维护成本；
- 4、工具本身不具有想象力
- 5、对测试质量的依赖性极大
希望借助自动化流程解决的问题
- 1、测试时间紧张，手工测试可能覆盖不全，容易错过某些边界情况；
- 2、模块间强耦合时，单纯从页面进行测试时，比较难深入发现问题；
- 3、回归测试时，需要投入较大的人力和工时；
- 4、实现手工测试无法达成的测试任务，如并发；
- 5、通过编写测试用例，加深对业务/数据的认知，有助于下阶段迭代中发现隐藏的问题。
引入自动化测试的前提条件
- 项目周期长，需求变动不频繁；
- 自动化测试脚本可重复使用；
- 测试任务手工测试难以实现；
做自动化测试需要具备的能力
- 编码能力；
- 熟悉被测系统；
- 掌握一个自动化测试框架/工具；
- 不断学习；
自动化测试用例设计原则
- 保持case的独立性；
- 保持case的可迁移性；
- 提升case的执行效率；

自动化框架

概述
- 定义：为解决某些特定问题而约束边界，支撑整个问题解决方案，配套了一些解决问题的组件而构成的工具。
- 特定问题：什么问题？——自动化测试
- 约束边界：为什么约束？——明确测试范围和目的
- 解决方案：用什么方案解决问题？——编程语言+工具+其他
- 构成工具的组件：哪些组件？—— 用例、脚本、数据、日志、报告、通知
- 工具：特点是什么？—— 灵活性、可扩展性、高内聚低耦合
图示

组件
- Log：日志记录和管理功能，针对不同的情况，设置不同的日志级别，方便定位问题；
- Report：测试报告生成和管理以及即时通知，测试结果快速响应；
- Source：配置文件、静态资源的管理，遵循高内聚低耦合原则；
- Common：公共函数、方法以及通用操作的管理，遵循高内聚低耦合原则；
- TestCase：测试用例管理功能，一个功能点对应一个或者多个case，尽可能的提高覆盖率；
- TestData：测试数据管理功能，数据与脚本分离，降低维护成本，提高可移植性；
- TestSuite：测试组件管理功能，针对不同场景不同需求，组装构建不同的测试框架，遵循框架的灵活性和扩展性；
- Statistics：测试结果统计管理功能，每次执行测试的结果统计、分析、对比以及反馈，数据驱动，为软件优化和流程改进，提供参考；
- Continuous：持续集成环境，即CI环境，包括测试文件提交、扫描编译、执行测试、生成报告及时通知等功能，持续集成是自动化测试的核心！

常见的自动化测试框架

1、接口自动化框架：
- ①、java+testNG/Junit+Maven/Ant/Gradle+Jenkins+MySQL+testlink/redmine
- ②、python+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
- ③、python+rebot framework+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
- ④、jmeter+Maven/Ant+Jenkins+MySQL+testlink/redmine
2、UI自动化测试框架
- ①、java+selenium/appium+testNG/Junit+Maven/Ant/Gradle+Jenkins+MySQL+testlink/redmine
- ②、python+selenium/appium+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
- ③、python+rebot framework+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
总结
- 它们都拥有共同特性：编程语言+单元测试框架+扫描编译工具+持续集成工具+数据库+项目管理工具。
- 编程语言：编写测试脚本、日志记录和输出；
- 单元测试框架：提供测试脚本运行、异常校验等一些列的配置；
- 扫描编译工具：测试文件扫描编译，一般配合持续集成工具使用效果更佳；
- 持续集成工具：Jenkins，经典的持续集成工具；
- 数据库：测试数据管理；
- 项目管理工具：测试结果统计管理；
面试总结
- 框架：6项 -- 编程语言+单元测试框架+扫描编译工具+持续集成工具+数据库+项目管理工具。
- 具体：10项
  - 日志记录和管理功能；测试报告；配置文件、静态资源；公共函数、方法以及通用操作；测试用例；测试数据；测试组件；测试结果统计；持续集成环境。

自动化测试的流程

分析自动化测试需求，一般在手工测试之后开始；
根据项目的特点、选择合适的自动化测试工具，并搭建测试环境
测试用例设计和开发：设计测试用例；或提取手工测试的测试用例，转化为自动化测试用例
开发自动化软件测试框架和测试脚本
执行：通过工具、代码实现自动化的构造输入、自动检测输出结果是否满足预期
生成自动测试报告
持续改进、脚本优化

游戏自动化测试的思考

自动化测试工具脑图

软件测试的测试用例思路

软件测试主要从以下 16 种类型进行测试：

一：功能测试(10 个方面)

面向需求
菜单、工具栏、快捷键、下拉框、按钮、单选按钮、复选按钮、切换、链接、触发键

二：界面测试

登陆界面、总界面、输入界面(增、删、改、查)、处理界面、输出界面、报表界面、提示界面

三：容错测试

数据长度、数据类型、非法此操作

四：接口测试

接口测试也叫业务流程测试(包括功能模块之间、模块与模块之间、子系统之间)
- 内部接口：例如：导入、导出(通俗的讲是接口就是调用)
- 外部接口：

五：性能测试

(TPS 吞吐量、响应速度、cpu 占用率、内存占用率)
平均吞吐量：单位时间内处理事务的个数
平均响应速度：做一个事务处理所用时间
- 例如：界面操作效率测试;报表输出及查询效率测试

六：负载测试

(压力测试、强度测试、容量测试)
压力测试即就是大用户测试(针对 B/S 而言)
容量测试即就是大数据量测试

七：并发测试

指多个用户在同一时间对同一条数据的删除或者修改等处理

八：稳定性测试

例如：1 小时触发 600 条信息，那么 8 个、10 个等发信息的条数测试

九：恢复测试

突然断电(系统触发正常启动;数据包要在断电的地方继续进行处理)

十：配置测试

最低配置：
推荐配置：大多数用户所用的配置

十一：安装测试

安装过程;
卸载过程

十二：文档测试

交给用户的文档。
例如：系统帮助、用户使用手册、用户安装手册

十三：可用性测试(纯粹靠经验)

十四：初始化测试

是指系统刚刚安装完成后，在数据位空的情况下，如果被调用的模块为空，点击调用模块的时候，是否进行容错的测试。

十五：数据完整性测试

是指当主表的某一条件信息被删除后，和这一条相关的从表的信息都应该被删除。
如果某些数据的主键是由数据库本身而实现的，可以不用删除，如果有些主从表是由程序员写的代码而实现，则要进行数据完整性的测试。

黑盒测试

定义：
- 黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用。
- 在测试过程中，将程序看成不能打开的黑盒子，不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。
- 不需要了解具体代码，对测试工程师要求不高。
测试用例与依据
- 黑盒测试用例设计方法：基于用户需求的测试、等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验法、场景法。
- 依据：用户需求规格说明书，详细设计说明书。
方法细节
- 等价类划分：是把程序的输入域划分成若干部分，然后从每个部分中取少数具有代表性数据作为测试用例。
- 边界值分析法: 是对输入或输出的边界值作为测试用例
- 错误推测设计方法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
- 因果图法：利用图解法分析输入的各种组合关系，写出判定表，从而设计相应的测试用例
- 判定表驱动：是把作为条件的所有输入的各种组合值以及对应输出值都列出来形成的表格称为判定表
- 正交试验设计：从大量的实验数据中挑选适量的、有代表性的点来设计测试用例

白盒测试

定义：
- 白盒测试也称为结构测试，主要用于检测软件编码过程中的错误。
- 程序员的编程经验、对编程软件的掌握程度、工作状态等因素都会影响到编程质量，导致代码错误。
- 对测试人员要求高：测试人员需要具备一定的编程经验；白盒测试工程师需要具备广博的知识面
测试用例与依据
- 白盒测试用例设计有如下方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
- 依据：代码结构。
方法细节
- 覆盖：至少执行一次
- 语句覆盖每条语句至少执行一次。
- 判定覆盖每个判定的每个分支至少执行一次。
- 条件覆盖每个判定的每个条件应取到各种可能的值。
- 判定/条件覆盖同时满足判定覆盖条件覆盖。
- 条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
- 路径覆盖使程序中每一条可能的路径至少执行一次。
静态白盒测试
- 不需要实际运行被测软件，而是直接对软件形式和结构进行分析。
- 静态白盒测试主要包括：代码检查、静态结构分析、代码质量度量等。
ps：

灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试
灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

辨析

简单辨析：
- 黑盒测试：关注程序的功能是否正确，面向实际用户；
- 白盒测试：关注程序源代码的内部逻辑结构是否正确，面向编程人员；
- 灰盒测试：介于白盒测试与黑盒测试之间的一种测试。
具体辨析
- 测试目标和依据：
  - 黑盒面对的是产品设计，白盒针对的是程序功能的实现，灰盒针对兼而有之，既要考虑产品设计要求，又考虑到功能实现的效果。
- 实现者：
  - 黑盒在意的是客户的角度，白盒测试针对的研发人员。
- 测试模块颗粒度：
  - 白盒在意的是代码实现层面，而灰盒更加侧重模块之间，颗粒度大于白盒。
- 版本：
  - 白盒测试一般发生在debug版本，灰盒大多一般在release版本进行。
- 测试效果：
  - 大量的bug在黑盒测试阶段测试出来，而白盒和灰盒测试的bug数目相对较少。
- 耗时：
  - 在同等时间内，一般白盒和灰盒的耗时长，bug数量少，一般表现为时间产出比较低，很难大范围普及白盒。
  - 黑盒相对bug时间投入产出比较高。
- 入门：
  - 黑盒入门较为容易，其次是灰盒，白盒入门门槛教黑盒高很多。