问题集

admin管理员组

文章数量:1130349

 

以下皆为收集各大佬内容整理

Web/App测试区别

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。 
系统架构方面： 
web项目，一般都是b/s架构，基于浏览器的 
app项目，则是c/s的，必须要有客户端，用户需要安装客户端。 
web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。

性能方面: 
web页面主要会关注响应时间 
而app则还需要关心流量、电量、CPU、GPU、Memory这些。 
它们服务端的性能没区别，都是一台服务器。

兼容方面： 
web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容 
app测试则要看分辨率，屏幕尺寸，还要看设备系统。 
web测试是基于浏览器的所以不必考虑安装卸载。 
而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 
此外APP还有一些专项测试：如网络、适配性。。。

APP测试特点

（除了按需求说明书外的 功能测试 之外还需要进行如下测试）

1： 适配性测试（也叫兼容性测试，不同的安卓版本，不同厂商，不同手机品牌）

2： 不同网络测试 （2G网络/3G网络/4G网络/WIFI网络）

3; 在线升级测试

4： 中断测试（电话、短中消息打扰）

5： 耗电量测试

6： 弱网测试（信号差，信号屏蔽实验室）

7： 安装卸载 （C/S）

8: 流量测试

 

测试报告包含内容

 

 

软件测试报告的组成：

一、概述

        包括项目背景、需求分析

二、测试时间、测试环境

三、测试过程

        评审记录、测试范围、测试用例

四、功能实现清单

        列出是否已经按照测试计划实现功能

五、缺陷统计

测试缺陷统计；
测试用例执行情况统计
六、测试统计情况

资源统计
执行情况
问题统计
问题列表
遗留的问题
七、测试总结

测试结论；（是否通过）
测试内容、测试用例的覆盖程度、bug的解决程度
八、测试风险
————————————————
版权声明：本文为CSDN博主「like_that」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn/like_that/article/details/102821357

 

安卓和IOS测试区别和注意点

区别：

1，操作系统：android操作系统较多，IOS较少只能升级不能降级，并且新的版本的资源库不能完全兼容旧版中系统中的应用，如果低版本应用调用了高版本的资源库，会导致系统崩溃

2，安装卸载测试：

              应用发布后：下载安卓包的平台和渠道很多：豌豆荚、应用宝、360手机助手等；IOS 主要有 App store、iTunes

              本地测试：安卓手机可以通过扫码或者直接安卓APK包安装测试包；IOS要安装测试包必须绑定手机的uuid才可以安装ipa测试包

3，按键操作测试：安卓手机针对每一款手机有不一样的操作；苹果手机操作习惯单一

4，开发语言：虽然同样的业务安卓和IOS的展示形式和业务一致，但是底层全完不一样。安卓的应用是有java语言实现的;iOS用objectC实现

App登录方式和测试重点总结

所有软件测试基础课程中，都会拿注册登录做例子，网上也能搜一堆，尤其是对于普通账户密码登录的情况，需要考虑账户密码的长度限制、字符类型、匹配判断等等。

 

目前市场上APP常用的登录方式有账密登录、手势登录，账密登录里又支持邮箱、账号、手机号登录。对于同时支持多种登录方式的APP，测试时除了考虑每种方式是否能够登录成功以外，特别需要考虑不同登录方式的优先级、对于用户习惯登录方式的设置和记忆、各种登录方式之间的切换、不同设备的不同方式登录等等。

 

今天与大家一起对App登录方式及测试重点进行梳理，主要关注一些特殊点，以及容易出现漏测的情况。

首先是账密登录的手机号支持，先了解下手机号登录的通用流程图： 

 

一、输入手机号

1．通用运营商覆盖。

国内主流的三大运营商，移动、联通和电信号段。

如果APP有海外版，那么要考虑海外的电话号码格式和运营商号段。

 

2．虚拟号段。

通常情况下测试人员都会考虑到不同运营商的手机号，但是会容易漏掉虚拟号段170和171，而170和171因为是虚拟号段，并无实名制，所以大肆被不法份子所利用的号段，更是容易被一些恶意用户用来薅羊毛。

 

3．新开放的号段。

随着政策变化，国家会时不时开放一些新号段，比如近期开通的联通166，移动198和电信199，也是测试人员容易忽略掉的。

 

二、输入验证码

短信验证码一般的原理是，前端APP通过短信接口提交一个请求，向服务端提供一个Token参数，服务端对这个Token参数进行校验，校验通过之后，再通过该接口向用户手机发送短信。

 

1．验证码时间限制

通常验证码有两个时间限制，一个是触发发送的时间，可以有效的避免对单用户的短信轰炸。通常的表现形式是，在界面上，一旦触发短信发送后，会设定一个一定时间的倒数，可以是60s，也可以是120s，以此来控制用户无法重复多次提交发送短信验证码的请求。

另一个是接收后的验证码有效时间限制。超过限制时间，校验时会提示该验证码已失效，需要重新获取。

 

2．验证码次数限制

对于连续获取验证码但不进行校验的手机号，应该要有防刷机制，系统可对该手机号进行保护。达到设定次数时提示超过上限，无法再次触发给该手机号发送验证码。

对使用同一个手机号在一天内获取验证码，也一般会有个最大值的限制。

 

3．验证码的内容

验证码的内容，一般是跟随验证码触发的场景的，比如注册验证码、交易验证码。另外验证码内容务必要包含品牌的标识，让用户一眼感知到这个验证码是来自什么APP，或者什么公司的。

不管是账密登录，还是手势录，安全都是接口测试和功能测试的重点，也是容易被很多测试人员所容易漏关注的。

 

三、安全的测试

1．登录时效。

登录成功之后的cookie是多久，会否超时自动下线等等。

 

2．登录冲突。

多个设备同时登录一个账户的处理机制。另外跨平台是否支持同一账户同时登录等等。

 

3．登录异常。

跨地域，非常见IP所在地登录的风险控制机制。长时间未登录，突然登录的检测机制等等。

 

4．密文传输。

会否对账户密码进行加密传输，日志脱敏等等。

APP消息推送如何测试？

消息推送功能是很多APP都有的功能，那测试过程需要注意哪些地方？

• 消息推送对象

消息推送一般可以自定义推送对象，有全部推送，精确推送，及安卓和IOS渠道推送，注意推送对象是否正确，推送之前确认自己是否在测试环境操作，以免造成生产问题。

• 消息简介

客户端收到消息推送有两种形式，客户端后台运行一般推送显示在通知栏，客户端前台运行一般弹出弹框，简介内容注意字数过多溢出情况。

• 消息详情

注意详情所支持的内容，包括文字、图片、表情包、换行以及链接跳转。

• 消息推送场景（支持定时推送）

（1）消息推送时间：

a)设置过去时间

b)未推送之前修改消息内容

c)删除消息，查看是否还会推送

（2）客户端运行状态

a)前台运行

b)后台运行

c)进程关闭状态

（2）特殊场景

a)多个提醒冲突

b)当天设置当天推送

c)当天设置隔几天起效

常见接口协议

TCP/IP协议成为基础的网络协议，涉及四层：应用层、传输层、网络层、网络接口层

TCP协议

TCP协议是在传输层中，一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP与UDP的区别

• TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景（通话等）
• UDP：不需要提前建立连接，实现简单，适用于实时性高的场景（视频传输、游戏传输等）

Restful软件架构风格（软件架构状态转换）

• 借助于http协议的基本请求方法代表资源的状态切换
• post：新增或者更新
• get：获取资源
• put：更新资源
• delete：删除资源

RPC协议

以本地代码调用的方式实现远程执行
Dubbo、gRPC（语言中立、平台中立的数据序列化框架）、Thrift均支持RPC协议

常见状态码

状态码	状态码英文名称	中文描述
100	Continue	继续。客户端应继续其请求
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求
300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy	使用代理。所请求的资源必须通过代理访问
306	Unused	已经被废弃的HTTP状态码
307	Temporary Redirect	临时重定向。与302类似。使用GET请求重定向
400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
409	Conflict	服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突
410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
412	Precondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed	服务器无法满足Expect的请求头信息
500	Internal Server Error	服务器内部错误，无法完成请求
501	Not Implemented	服务器不支持请求的功能，无法完成请求
502	Bad Gateway	充当网关或代理的服务器，从远端服务器接收到了一个无效的请求
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP Version not supported	服务器不支持请求的HTTP协议的版本，无法完成处理

 

接口测试原理、流程

接口测试的原理是模拟客户端向服务器发送报文请求,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的一个过程。
接口测试流程：

　　　　模拟客户端连接服务器(服务器提供的端口是否可访问)
　　　　　　　　↓
　　　　客户端发送报文请求
　　　　　　　　↓
　　　　服务器端接收请求并做处理
　　　　　　　　↓
　　　　检查返回的预期结果并与实际结果对比
　　　　　　　　↓
　　　 　　　　结束

 

如何编写接口测试用例

自动化始终只是辅助测试工作的一个手段，对于测试人员而言，测试基础和测试用例的设计才是核心。如果测试用例的覆盖率或者质量不高，那将这部分用例实现为自动化用例的意义也就不大了。

那么，接口测试用例应该怎么编写呢？

接口的定义 ：

    主要是子模块或者子系统间交互并相互作用的部分。

• 1

因此，可以分析，系统间的接口包含三部分：输入、处理逻辑、输出。

应该怎么分析一个接口？

获取接口文档：和黑盒测试一样，我们是从需求文档中去挖掘测试点，设计测试用例。对于接口测试，同样是有对应的接口文档的。

分析接口文档，提取测试点：
1）、输入： 接受哪些参数、参数的类型、可选参数和必选参数等；根据输入参数采用等价类、边界值分析法等进行设计；
2）、业务逻辑：对于一个接口，不同的输入参数或组合，流程或状态的转移是不同，可以根据业务逻辑画出流程图或状态转移图，确保每种状态至少被访问了一次；
3）、输出：根据文档规定的输出，反向设计测试数据，使所有的输出状态都被包含了；

测试用例：同时对输入、业务逻辑、输出进行考虑时，肯定会存在用例的冗余，在最大限度覆盖业务功能和规则下，选取最优用例集合。同时，需要考虑异常数据和场景。

怎么确定用例的覆盖率？

在没有特殊要求的情况下，至少需要考虑以下内容：
1）、业务功能覆盖是否完整
2）、业务规则覆盖是否完整
3）、参数验证是否达到要求（边界、业务规则）
4）、接口异常场景覆盖是否完整

如果接口需求还包含性能或者安全要求，还要对接口进行性能测试和安全测试，就需要考虑：性能指标是否满足要求、安全指标是否满足要求。

总结
对于接口测试，测试采用的方法是与黑盒测试一致的，可以把接口测试看作是没有界面的功能测试；

可以看看大师的文章：https://mp.weixin.qq/s/ZH6gyUe9U12vKGoASgsLvw，提升点点点技能

 

负载测试，并发测试，压力测试区别

负载测试

1、定义：
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。

2、目的：
不把系统搞挂的测试，使系统能够在最大的压力下可以正常运行。从而获取系统指标。

3、方法：
不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点）。系统负载压力包含并发用户数、持续运行时间、数据量等。其中并发用户数是负载压力的重要指标。

并发测试

1、定义：
1、目的：检查系统是否有并发问题，例如内存泄漏、线程锁、资源争用等问题。
2、方法：确定用户并发数，必须知道系统所承载的在线用户数。然后在单位时间内(S)同时发起一定量的请求。
3、确定并发用户数的方法：
例如：公司OA系统账号或者总用户有2000人；最高峰在线500人；但是这500人并不是作为并发用户存在的概念。即并不表示服务器实际承载的压力；有可能40%关注的是首页新闻公告板之类（注意看新闻这个阶段是不能造成服务器的压力）；20%用户在查询资料或者操作表格；20%用户在发呆；20%在页面之间跳转；在这种情况下，只有真正20%用户在对服务器造成实质的影响。
我们将这个查询、操作表格作为一个业务范畴来说；直接将这部分业务并发用户称为并发用户数：
1.计算平均并发用户数：C=NL/T
2.并发用户峰值数：C’ ≈ C+3根号C
公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
假设有一个OA系统，该系统有3000个用户，（可以看注册信息）平均每天大约有400个用户要访问该系统，（日志文件查看）对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
C = 4004/8 = 200
C’≈200+3根号200 = 242
但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值，2或者3.
假如说用户要求系统每秒最大可以处理100个登陆请求，10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候，响应时间还在允许范围呢，就要加大用户数，例如120 等 。个人理解这个用户数就是我们经常说的等价类和边界值法来设定。

压力测试

1、定义：
是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。

2、目的：
把系统搞挂的测试。

3、方法：以负载测试或者并发测试为依据，给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。

 

需要验证系统是否满足性能指标（比如最大响应时间，最大并发用户数，典型处理时间，吞吐率等）的时候需要性能测试。
性能测试一般来说需要构造近似的用户使用场景，模拟用户请求调用，有时候需要单独测试的话，还可以用mock。

 

测试分析

测试分析的过程，就是明确需求的目的和价值、分析需求的可行性以及评估需求的优先级，最终明确测试对象和测试范围，测试的重点和难点。

步骤	目的
1. 理解需求、分析需求的价值。	理解需求的目的和价值。
2. 分析需求的可行性。	评估实现方案的可行性，是否可以做。
3. 评估需求的优先级。	评估做不做，什么时候做。
4. 测试分析。	1. 明确测试对象、测试范围； 2. 明确测试的重点、难点。

 

性能测试一般流程

step1 分析 性能测试需求
step2 编写 性能测试计划
step3 编写 性能测试用例
step4 编写 测试脚本
step5 设计 测试场景
step6 执行 场景
step7 监控 场景运行
step8 分析 测试结果
step9 系统性能 调优
step10 性能测试总结

ps:重复5-9步直到测试计划完成、结果满意。

 

如何定位性能瓶颈

1、着手在测试前：理清数据流向，数据流程分解

　　通过绘制数据流向图，以便清晰的列出所有可能出现瓶颈的位置，避免在分析过程中遗漏可能的瓶颈点。

  系统架构分解——水池模型

　　要查找瓶颈，首先要对系统的架构有详细的了解，清楚知道所有可能成为瓶颈的位置。只有这样才能在遇到问题是合理的设计测试用例，对流程的各个步骤进行逐一排查。

　　举个例子，家里厨房的水池下水堵了，我们要找原因，首先得知道水池的下水道都有哪些部分：

　　简单的看，可以把下水道分解为水漏、上连接管、回水弯、下连接管最后接入地漏。再查找堵塞位置时，我们就可以将水直接导入回水弯，排除水漏和上连接管道堵塞的可能。

　　应用在测试中，我们也可以利用直接向应用中间件发请求，来排除Web代理层的瓶颈。

　　通过绘制流向图，可以更清晰的展现系统中数据流向，帮助我们在定位瓶颈的过程始终能迅速的分析预计到下一个可能的瓶颈位置。

 

　　如上图，就是在play一个Mobile game时的数据流向图。

　　2、最直观的指征：检索日志中的异常

　　日志是系统异常的最直接反映，通过客户端(负载工具端)、服务器端的日志，可以迅速确定瓶颈可能存在的方向。一些在大用户量大并发情况下的功能问题，也会在错误日志中体现。

　　在性能测试过程中，一般情况是不把全部日志打开的，而是尽量保持与生产环境的设置相同，生产环境开启什么样的日志级别，在性能测试环境中也应该开启同样的级别。

　　但是往往在生产环境出于性能考虑，并不会把日志级别开的非常高，所以在发现系统存在性能问题时，我们可以适当调高日志级别，以便获得更多的信息。

　　在日志中，我们可以由一些关键字直接推断出系统的问题所在，比如：

　　· Too many open files

　　Linux下存在句柄数限制，系统的默认值较小，在测试前应该优化，另外还要怀疑是否程序存在打开句柄却在某些情况下没有关闭。

　　· OutOfMemoryError/Cannot allocate memory

　　Java环境的虚拟内存异常，往往需要关注是否有溢出。

　　· SQLException

　　数据库语句执行异常，一般日志中还会有数据库返回的信息。

　　· Connection closed/connection refused

　　连接被关闭被拒绝，一般是连接数限制不能承担当前的压力。

　　3、最底层的反映：分析硬件资源占用

　　硬件资源也是系统性能达到瓶颈点的重要指征，如果没有在日志中找到异常，那么通过监控硬件资源消耗，往往可以发现系统的资源瓶颈。

　　3.1 CPU占用率

　　CPU的高占用，并不一定表示有问题，因为实现最优性能的一方面就是充分发挥当前的硬件资源能力。

　　但是如上图这样CPU长期出于满负荷，就很值得我们关注，至少说明在大多数情况下，系统已经是在耗用最大的计算能力进行计算，运算能力已经成为瓶颈。

　　另外还要注意CPU是消耗在User还是Sys还是Wait, 如果是Wait，还要观察其他硬件资源，查看CPU是在等待什么。

　　3.2 内存占用

　　内存在性能测试中是被重点关注的指标，因为它是反映重大缺陷——内存泄露的最直接指标，但是我们应该注意到，在JAVA框架中的内存泄漏是发生在虚拟内存中的。

　　观察内存/虚拟内存的占用情况，尤其是在压力消失后的内存占用恢复情况，是比较直接的判断内存泄漏的依据。

　　如果观察到如上图的内存使用情况，在每次Full GC后，占用的内存都没能恢复到原来的水平，如果在压力撤除一段时间后，内存依旧不能恢复，那么十有八九当前系统存在内存泄漏。

　　3.3 磁盘I/O

　　通常情况下，磁盘是计算机中速度最慢的一个子系统，因此很多情况中，磁盘I/O会成为系统的瓶颈。实际上在设计高性能系统的时候，会把避免磁盘I/O作为一个首要准则。

　　虽然当前的技术发展让存储系统的读写速度不断提升，但高昂的成本使得大多数情况下，高速存储会使用在数据库或文件服务器上，而不会使用在应用服务器中。所以在我们进行性能测试时，要更多的注意应用服务器的磁盘使用情况。

3.4 网络I/O

　　很多时候大家都容易忽略网络对系统的影响，实际上网络带宽在一些情况下也会成为系统的瓶颈。一旦在业务的请求和响应中包含较大的数据传输时，往往会遇到网络瓶颈。因为更多的时候服务器采用的还是以太网卡，1000M网卡在全双工模式下传输速率也只有80M/s，如果响应中包含报表、图片之类的大尺寸数据，很有可能在性能测试中出现网络瓶颈。

　　还有一点就是不要忽略回环地址传输的影响，比如一些应用访问本地监听的其他服务，都会受到网卡的传输速率限制的影响。

　　4、软件性能软肋：数据库的监控分析

　　对于Web系统，超过七成的瓶颈都出现在数据库子系统，因此在进行之前几步不能明确瓶颈位置的时候，应优先进行数据库的监控分析。

　　Oracle数据库监控工具

　　Oracle本身提供了ASH，AWR等Report来帮助进行性能分析，但是对于测试人员来说，掌握这些需要较深入的数据库知识学习，不是一朝一夕可以达成的。而一些第三方提供的工具，通过图形界面，可以更加直观的帮助我们进行Oracle数据库的监控和分析。

　　Lab128就是国内开发的一块很不错的共享软件，而且它还提供无限期的试用key，可以免费试用。

　　Oracle中的等待事件

　　判断Oracle中的瓶颈，了解Oracle中的等待事件Wait event，对于查找瓶颈有很大的帮助。在Oracle中，处理SQL的过程，会产生一系列的等待事件。

　　有等待事件并不代表数据库存在瓶颈，正常的处理也会有等待事件，但如果发现等待事件激增，或者SQL执行缓慢，这时候等待事件中排名靠前的事件将会直接反映出瓶颈所在。

　　上图是在测试中的某一时刻，log sync的等待事件突然增高，同时数据库的吞吐率大幅下降，原本正常的SQL执行速度也突然变长。

　　因为压力并没有突然改变，很有可能是写log的过程出现了问题，或者是在传输过程，或者是在存储子系统。后来经过排查，发现是存储集群的一个存储单元出现故障导致写入速度变慢致使出现大量等待。

　　5、最后的大杀器：应用服务器监控及代码分析

　　如果没能在其他位置发现瓶颈，那么软件程序所运行的平台——应用服务器很可能是最大的潜在瓶颈点，进行应用服务器的监控与分析将是我们最后的大杀器。

　　5.1 常见的软件资源种类

　　相对于硬件资源，软件资源往往容易被忽略，它不像CPU占用率那么让人更直观的和性能联系起来，但是实际上，软件资源同样限制着软件系统能达到什么样的性能。

　　软件资源不论是在Web层，应用层还是在数据库层，都可以按“入口”、“内部”、“出口”来划分。对于常见的原因中间件，“入口”就是如HTTP连接池之类，是数据来源方向的相关设置，比如连接数限制，超时时间，连接回收策略等等；“内部”就是处理请求的各项资源，不如线程数，线程调度策略，虚拟内存设置，GC策略等等；“出口”则是向后端交互的各项资源，如数据库连接池的配置。

　　5.2 应用中间件监控

　　要了解软件资源是否成为瓶颈，我们就需要监控这些软件资源指标。以JAVA环境为例，Weblogic 本身就有控制台，提供了各种计数器。

　　上图显示的是Execute Threads的计数器，对请求的处理就在这些Thread中进行。

　　Tomcat也有开源的控制台，常用的像PSI-Probe，提供了Tomcat服务器各项资源的图形化监控。如下图中对JVM的监控。

　　5.3 应用中间件剖析

　　仅仅监控只能初步判断问题的方向，例如发现ExecuteThreads持续的增加，我们虽然知道这个现象不正常，但是想要确定是程序中的哪个方法导致了当前问题，我还需要其他的工具进行深入剖析。

　　对于Java程序，最常用的工具有JProfiler，YourKit，jvisualvm，他们的原理类似，都是要把一个小插件挂在到应用服务器上，以获取需要的程序运行信息。

　　而Sun在JDK1.7后版本整合了继承自JRockit的MissionControl，也提供了很强大的分析监控功能，而且开销较小，确实是个不错的选择。

　　它们提供的内存泄漏检测工具可以对对象的创建进行趋势分析，帮你找到最有可能出现泄漏的对象，

　　再通过展开剖析工具中的invoke tree（调用树），找出创建该对象的方法，可以更细致的定位问题的原因。

　　同时，方法视图也可以依据CPU时间进行分析，找到在虚拟机中消耗最高的方法。

性能测试常见指标

• 吞吐量：每秒钟系统能够处理的请求数、任务数。

• 响应时间：服务处理一个请求或一个任务的耗时。

• 错误率：一批请求中结果出错的请求所占比例。

• QPS（TPS）：每秒钟request/事务 数量

• 并发数： 系统同时处理的request/事务数

• 响应时间：  一般取平均响应时间

如何区分前端bug还是后端bug？

软件测试工程师的职责是发现BUG，此外，如何体现个人价值？那么我们试想，只提出问题而不去解决，问题就永远得不到闭环。所以，一个资深的测试人员的基本功应该是这样的：深挖业务和功能需求，找出BUG，定位BUG，提出解决方案。这里我们就来说说，当我们找到了BUG，应该把BUG提交给谁去解决，这属于BUG定位的问题。
试想:
根据需求，用户头像应是圆形，但结果是方形，是谁的BUG？
保存用户信息时，无法保存成功，也没有错误提示，最可能是谁的BUG？
显然，工作过程中，我们不可能把这些BUG提交给同一个人去解决。我们应该至少区分出是前端还是后端BUG，就好像时下流行的词“垃圾分类”，经过BUG分类处理，整个团队的效率都会有所提高。
一.什么是前端/后端？
目前多数互联网项目都是前后端分离开发的，那么什么是前端？什么是后端？简言之，前端侧重于页面设计，后端侧重于服务开发。
比如要保存一个用户信息，前端把界面显示给用户，让用户按需填写，当用户点击“保存”按钮时，数据会通过网络被提交给后端服务，由后端服务处理是否需要进一步运算，并且把数据保存在哪一个数据库的哪一张表里。
二.为什么要区分前端/后端BUG？
目前多数项目都是多人协作开发的，如果不能明确这个BUG是谁造成的，容易提交给错误的开发人员，会大大降低BUG的解决效率。
另外，如果团队规模较大，或者由各地的项目组拼凑而成，势必会增加沟通成本，这更需要我们在类似禅道或者Jira等项目管理软件中提交BUG时，先指明是谁的BUG，避免互相踢皮球的现象。
所以，为了提高团队效率，测试人员尤其要做好BUG分类。
三.如何定位前端/后端BUG?
对于一个优秀的软件测试工程师来说，区分BUG属于前端还是后端是尤为重要的。
页面请求过程
弄清楚如何定位和分类BUG之前，需要了解一下页面请求的过程，以 http 请求为例，请求过程如下：
用户在前端页面操作，如点击某个功能
页面携带数据进行请求，访问具体功能接口
由后端服务执行该接口相应的业务逻辑，如涉及数据，再去请求并组装数据返回给前端
前端页面进行渲染和展示对应的页面和数据
前后端BUG各有什么样的特点？
前端BUG
– 界面相关
– 布局相关
– 兼容性相关
后端BUG
– 业务逻辑相关
– 性能相关
– 数据相关
– 安全性相关
定位BUG属于前端还是后端，有什么方法？
这里提供了几个方法，可以给大家一个思路，让大家能在学习和工作中了解如何去区分BUG属于前端还是后端。
经验法
软件测试人员应不断精进自己的技能，负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类BUG了。
例如：
网页上的某个图片的分辨率不对，如果我们了解实现过程，可以想到一般情况下，是根据某个地址去服务器取图片的，数据库一般只保存地址，那么图片能正确显示，就说明后端的基本功能是满足需求的。如果具体图片分辨率有误，最可能的原因是前端显示过程出了差错。
日志查看法
当我们发现一个BUG，并不确定这个BUG属于前端还是后端，可以查看后端服务的日志，复现BUG时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析。
接口查看法
这种方法常用于查看是后端返回给前端的数据有误，还是前端显示有误。
大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。
通过Chrome看到的接口情况如下

可以在Response中查看响应数据

我们需要对比通过后端接口拿到的数据和前端显示的数据，来确认问题出在哪里。如果数据错了，页面显示是错的，也是正常的，先从后端入手去解决。如果数据对了，但是显示错了，就需要问问前端的开发人员了。
四.经验和总结
沟通很重要
我们在定位BUG的过程中，最不能忽略的一个问题是和开发人员的沟通，有时候忙活半天，不如一问一答。经验和技术的成长也都离不开合理高效的沟通。
经验和小结
出现样式的问题基本都是CSS的BUG
出现文本的问题基本上都是html的BUG
出现交互类的问题基本上都是Javascript的BUG
其他问题先沟通，再定位

给你一个网站如何测试

1.寻找相关文档，如需求说明书、网站设计文档等 ；

2.测试工作开展前需要确认以下几个方面的问题：
制定测试计划、制定测试策略及测试边界、确定测试人力资源、确定测试环境配置、确认测试工具、确认测试方法包括不限于以下：功能测试、界面测试、易用性测试、兼容性测试、安全测试、数据库测试、压力测试、负载测试、性能测试

3.设计测试用例时，需要分两部分：
3.1 后台管理功能测试 一般主要功能有：
功能测试、界面测试、易用性测试、兼容性测试、性能测试、安全测试、数据库测试等
3.2 用户功能测试 一般主要功能有：
功能测试、界面测试、易用性测试、兼容性测试、性能测试、安全测试、数据路测试等
-功能测试主要关注：
浏览、操作、切换、跳转、注册登录等
-界面测试主要关注：
页面布局、分类显示、文字描述、图片显示、多媒体播放、标点符号使用等
-易用性测试主要关注；
浏览操作是否简单、方便、易懂 注册登录是否简单、方便、易懂
-兼容性测试主要关注：
操作系统、浏览器、数据库、软件平台等兼容性
-性能测试：
压力测试、负载测试、并发测试等
-安全测试： 登录的安全检查 是否存在溢出，导致安全泄露等 相关开发语言的安全性测试 数据库的读取及保存等安全性测试
-数据库测试： 数据库的读取、保存、并发等测试
4.测试执行
4.1 搭建测试环境
4.2 人力合理分配
4.3 测试管理工具
4.4 按计划执行测试，并记录BUG
4.5 建立风险管理，预防人力不足、需求变更、时间太短等情况发生
4.6 建立测试文档管理工作
4.7 定期组织评审、回溯、难点分享、业务学习等工作 测试结束： 统计缺陷数据、汇报版本质量、性能测试结论、按轮次输出测试报告等

 

提交bug时，应该说明哪些信息？

提交bug时，应该说明哪些信息？
**1.**所属项目，测试平台，系统版本，严重程度，优先级，简述标题，详细描述（问题描述，重现步骤，重现条件，期望结果，实际结果）日志截图，指派给对应开发

2.问题要尽量定位到准确复现步骤或错误原因，一般提交bug包含：主题，详情描述（前置条件，步骤，预期结果，实际结果），所属平台，指派人，能辅助直观查看问题的附件，比如日志截图，信息包，界面功能截图）
不能重现或者不能定位原因步骤的问题，要尽量提供bug所在的环境，曾经操作步骤，及目前的外在条件，并协助研发人员查找。

3服务端：测试环境-测试模块-复现步骤-接口url-入参-出参-错误日志-期望值
前端：测试环境-测试模块-复现步骤-截图-期望效果

4说明当前操作环境以及所属模块，影响的版本，指派给谁，bug的类型，bug 的等级，bug的标题，重现步骤最好能有截图和视频类附件，以及导致的结果，预期结果

5
1)测试的环境
2)bug的标题
3)复现步骤
4)预期结果
5)实际结果
6)影响范围
7)图片视频等附件
8)bug的严重程度
9)修改bug的优先级

6
1环境 在什么情况下出现的bug，例如用WiFi或用数据的情况下，等
2步骤 如何发现bug的过程步骤，可用录屏等操作
3确定 确认bug的必然性，偶然性，可复性
4证明 需给予证明，时间，截图，log文件，录屏等
5定级 确认bug登记，缺点，错误，故障等
6结果 将bug的结果用显目颜色标识，提交的时候，写好标题，附上证明，写上姓名，便于找到
7)硬件测试需要提交硬件相关信息，硬件所在软件环境，如系统信息，fw信息，driver信息等等。然后是问题的复制手法或者详细步骤，发生的概率，尽量提供问题的根本原因，所以需要一定的分析问题的功底。最后就是提交问题相关的log文件

 

描述一个测试活动完整的过程。

详细的描述一个测试活动完整的过程。（供参考，本答案主要是瀑布模型的做法）

项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

测试用例完成后，测试和开发需要进行评审。

测试人员搭建环境

开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

如果有客户反馈的问题，需要测试人员协助重现并重新测试。

web与APP（移动端）测试的区别

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。

根据两者载体不一样，则有如下区别：

系统结构方面

Web项目，是b/s架构的，基于浏览器的，Web测试只要更新了服务器端，客户端就会同步会更新；

App项目，是c/s结构的，必须要有客户端，App 修改了服务端，则客户端所有核心版本都需要进行回归测试一遍（因为并不是所有用户都会更新客户端）；

性能方面

Web项目 需监测 响应时间、CPU、Memory；

App项目 除了监测 响应时间、CPU、Memory外，还需监测 流量、电量等；

兼容方面

Web项目： 

web是基于浏览器的，所以更倾向于浏览器、电脑硬件、操作系统，不过一般还是以浏览器的为主：

1. 一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）；

2. 操作系统（Windows：Win7、Win8、Win10；Mac；Linux等）；

App项目：

App的测试则必须依赖Phone或者是Pad，不仅要看分辨率，屏幕尺寸，还要看设备系统、运营商等,系统一般来说分为Android和IOS，不过Android系统定制的比较多，可能会出现兼容性问题：

1. 设备系统:：IOS、Android

IOS：ipad、iphone；

常见版本：11.0、10、9.0；

Android系统：常见品牌有华为（EMUI）、小米（miui）、OPPO、VIVO、三星等；

常见系统版本：9.0、8.0、7.0等

2. 分辨率不同

常见分辨率：

2960*1440、2560*1440、2436 * 1125、2340*1080、2280*1080、2246*1080、2244*1080、2244*1080、2220*1080、1920 x 1080 、1334 x 750、960*540；

3、运营商

主要运营商：移动、联通、电信

相对于 Wed 项目，APP有专项测试

1. 干扰测试：中断，来电，短信，关机，重启等

2. 弱网络测试（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等）

3. 安装、更新、卸载

安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况；

卸载：需考虑 卸载后是否删除app相关的文件；

更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新；

4. 界面操作：关于手机端测试，需注意手势，横竖屏切换，多点触控，前后台切换；

5. 安全测试：安装包是否可反编译代码、安装包是否签名、权限设置，例如访问通讯录等；

6. 边界测试：可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖（QQ、微信登录）等；

7. 权限测试：设置某个App是否可以获取该权限，例如是否可访问通讯录、相册、照相机等；

测试工具方面

自动化工具：APP 一般使用 Appium; Web 一般使用 Selenium

性能测试工具：APP 一般使用 JMeter; Web 一般使用 LR、JMeter

 

灰度发布

我理解的灰度发布，主要是按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈（如：微博、微信公众号留言或者产品数据指标统计、用户行为的数据埋点）以及对新版本功能、性能、稳定性等指标进行评论，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。

1、什么是灰度发布，有哪些好处？

答：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。

在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。（来源于百度百科）

好处：

1. 提前获得目标用户的使用反馈；
2. 根据反馈结果，做到查漏补缺；
3. 发现重大问题，可回滚“旧版本”；
4. 补充完善产品不足；
5. 快速验证产品的 idea。

2、那么灰度发布的流程是咋样的呢？

相关解释：

• 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
• 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
• 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
• 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

 

 

软件测试之 【移动端测试】——安装与卸载

软件测试之 【移动端测试】——安装与卸载

•  

安装

1.正常安装测试，检查是否安装成功。
2.APP版本覆盖测试。例如：先安装一个1.0版本的APP,再安装一个高版本(1.1版本)的APP，检查是否被覆盖。
3.回退版本测试。例如：先装一个2.0版本的APP,再安装一个1.0版本的APP,正常情况下版本是不可以回退的。
4.安装时内存不足，弹出提示。
5.根据安装手册操作，是否正确安装。
6.安装过程中的意外情况（强行断电、断网、来电话了、查看信息）等等，检查会发生的情况。
7.通过‘同步软件’，检查安装时是否同步安装了一些文件。
8.在不同型号、系统、屏幕大小、分辨率上的手机进行安装。
9.安装时是否识别有SD卡，并默认安装到sd卡中。
10.安装完成后，能否正常启动应用程序。
11.安装完成后，重启手机能否正常启动应用程序。
12.安装完成后，是否对其他应用程序造成影响。
13.安装完成后，能否添加快捷方式。
14.安装完成后，杀毒软件是否会对其当做病毒处理。
15.多进程进行安装，是否安装成功。
16.在安装过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。
17.安装之后，是否自动启动程序。
18.是否支持第三方安装。(华为 oppo 小米 百度应用市场 豌豆荚 应用宝 /.....)
19.在安装中点击取消。(进行安装之后不能取消的)

卸载

1.用自己的卸载程序进行卸载，检查是否卸载干净。
2.用第三方工具，检查是否卸载干净。
3.在卸载过程中，点击取消按钮，看是否正常退出卸载程序，检查软件是否还能继续正常使用。
4.卸载过程中，出现意外（比如手机关机，没电，查看信息，接打电话），程序是否还能运行。
5.在卸载过程中，突然重启设备，再次访问程序，是否还能运行。
6.在没用使用程序时，删除目录文件，看程序是否能运行。
7.在使用过程中，直接删除目录文件，程序是否还能运行。
8.不同系统、硬件环境、网络环境下进行卸载。
9.卸载成功后，是否对其他程序有影响。
10.卸载后再次安装，是否正常使用。
11.在卸载过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。

---------------------------------------------PC电脑上-------------------------------------------------------
PC电脑安装
没安装过的PC中进行安装 缺省项安装功能验证
存在老版本且正在打开该软件 存在老版本且并没有打开该软件 存在更新版本，相同路径安装 存在更
新版本，不同路径安装 存在相同版本，相同路径安装 存在相同版本，不同路径安装 卸载后重新安装 删
除文件后安装
安装目录下磁盘空间不足 存在金山、360等杀毒软件 启动该安装多个安装进程 静默安装

安装完成

1.控制面板显示信息正常，包括名称、发布者、版本、支持链接、帮助链接 
2.点击桌面快捷方式，可正常打开该软件 
3.开始菜单有生成相应的快捷方式，可正常打开该软件 
4.HKLM\Software\Seewo\下的注册表信息正常写入 
5.防火墙白名单正常设置 
6.若是卸载安装，则旧安装目录下文件被正常删除 
7.若依赖Flash、k-lite、EasiUpdate和.NET，这些软件安装版本正确无误 
8.若配套安装Seewo其他软件，该软件版本正确 
9.若该软件为双签名，检查软件应为双签名 
10.若该软件为开机自启动，重启PC，软件自启动 
11.若该软件覆盖安装前为已注册软件，覆盖安装后仍为注册状态 
12.安装后重启PC，该软件能正常运行

•  

卸载

1.通过开始菜单上的卸载程序卸载普通软件，此安装时写了系统注册表，软件的所有文件是否完全删除

2.通过开始菜单上的卸载程序卸载普通软件，安装时写了系统注册表，软件的文件删除的同时注册表是否能够完全删除，注册
表删除时是否有提示信息

3.通过开始菜单上的卸载程序卸载普通软件，软件安装后使用过程中下载和保存了个性信息，软件的文件删除的同时是否能够
删除个性信息，在删除个性信息是否提示用户做出选择：删除或保留

4.对安装时写了注册表的普通软件，不使用软件提供的卸载程序，而是直接查找到程序文件，直接删除文件，用以检查是否能
够删除此程序

5.对安装时没有写注册表的程序，使用开始菜单上的卸载程序，执行卸载，完成检查能否完成删除程序文件

6.对安装时没有写系统注册表的普通软件，不使用软件提供的卸载程序，而是直接查找到程序文件，直接删除文件，用以检查
是否能够删除此程序

7.对通过IE下载的组件，安装后通常没有在开始菜单增加控件卸载程序，此类软件执行卸载时选择控制面板- 卸载或更改程序
，查找到对应的程序，执行卸载完成后检查是否卸载正确。在IE加载组件中检查是否还存在

8.对通过IE下载的组件，安装后通常没有在开始菜单增加控件卸载程序，使用一段时间后存在下载用户个性数据的此类软件执
行卸载时选择控制面板-》卸载或更改程序，查找到对应的程序，执行卸载时删除个性信息是否提示用户做出选择 删除或保留
完成后在IE加载组件中检查是否还存在，同时检查个性数据是否完全删除

9.对在开始菜单存在程序菜单，但是已经删除了程序文件的程序，执行卸载，检查系统执行情况

10.对在控制面板的删除和修改程序列表中存在程序名称，但是已经删除了实际程序文件的程序，执行卸载 检查系统执行情况

11.卸载后，再进行老版本的软件安装，检查是否能正常安装并正常使用

12.卸载后，再进行升级版本软件的安装，检查是否能正常安装并正常使用

13.如果当前程序正在运行过程，进行卸载，检查是否进行卸载提示

14.如果是C/S或B/S系统，要检查在客户端程序正在运行过程，是否能进行服务器端程序的卸载

15.在卸载过程中如果出现异常（例如某个服务还没有停止，或后台某个文件还在占用状态时，或安装文件改变了目录等）程序
是否会进行正确检测，在异常排除后，是否能再次成功卸载

16.在卸载过程中出现环境异常（机器重启，死机，断电等情况）时，恢复后，能否进行成功卸载

17.是否可以进行远程卸载操作，如果可以进行远程卸载操作，若在卸载过程中出现网络异常，卸载过程中断 等网络恢复后是否
能再次卸载成功

18.卸载过程是否支持用户进行卸载选择，即只卸载部分内容 如果支持要逐一检查只卸载部分内容对其他功能的使用是否有影响

19.检查卸载后是否系统保存重要数据进行一并删除（而不是放到垃圾箱中），例如登录文件，安全密钥。后台数据库文件或后台
数据文件等

20.对安全性有特殊要求的软件（例如网银个人版系统），在卸载后，要检查对应的网银验证文件是否一并被删除，防止有其他人
安装网银后，又可以继续非法使用他人账户信息

 

一台客户端三百个客户与三百个客户端三百个客户相比对服务器施压的区别

只有一个客户端，三百个用户肯定不能同时进行操作，假设每次一人操作客户端对服务器施压，服务器承受的压力小但持续时间长

 

假设三百个客户端同时进行操作对服务器施压，就要求服务器带宽能够承受三百人同时在线操作，且服务器短时间内承受压力大但持续时间短

在windows下保存一个文件会弹出一个对话框框，为文件名设计一个测试用例用等价类划分

单字节，如A；

双字节， AA、我我；

特殊字符 /‘。‘；、=-等；

保留字，如com；

文件格式为8.3格式的；

文件名格式为非8.3格式的；

/,,*等九个特殊字符。

 

web自动化中常见定位元素方式

id定位

通过了解HTML可以知道id是唯一表示，通过查找id的方法进行查找

name定位

name在HTML中通常指元素的名称

class定位

通过HTML了解到class是指元素的类名

link_text定位

link_text从字面意思上了解到是通过文本的形式进行定位的

xpath定位

xpath定位有多种定位策略，可以通过很多方法进行定位如：name，text，class等，后面可以单独进行写一篇关于Xpath的定位方法

 

简述延时等待方式

强制等待   sleep

程序执行到该位置必须等待所设置时间

隐性等待   wait

隐形等待是设置了一个最长等待时间,如果在规定时间内网页加载完成,则执行下一步,否则一直等到时间截止,然后执行下一步.

显性等待  WebDriverWait

第三种办法就是显性等待,WebDriverWait,配合该类的until()和until_not()方法,就能够根据判断条件而进行灵活地等待了.它主要的意思就是:程序每隔x秒看一眼,如果条件成立了,则执行下一步,否则继续等待,直到超过设置的最长时间,然后抛出TimeoutException

自动化测试用例覆盖率 一般占百分之三十到四十

自动化测试完整运行一遍用例的时间一般是半个小时左右

分层自动化是对产品的不同的阶段都进行自动化测试

α测试

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。

β测试

β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。 只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。

静态测试

 

静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。

包括对代码测试、界面测试和文档测试三个方面：

    对于代码测试，主要测试代码是否符合相应的标准和规范。

    对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。

    对于文档测试，主要测试用户手册和需求说明是否符合用户的实际需求。

动态测试

 动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

    黑盒测试有可能是动态测试（运行程序，看输入输出），也有可能是静态测试（不运行，只看界面）

    白盒测试有可能是动态测试（运行程序并分析代码结构），也有可能是静态测试（不运行程序，只静态察看代码）

    动态测试有可能是黑盒测试（运行，只看输入输出），也有可能是白盒测试 （运行并分析代码结构）

    静态测试有可能是黑盒测试（不运行，只察看界面），也有可能是白盒测试（不运行，只察看代码）

黑盒测试

黑盒测试又称功能测试，数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。测试人员一般吧被测程序当作一个黑盒子。 黑盒测试主要测到的错误类型有：不正确的或遗漏的功能；接口，界面错误；性能错误；数据结构或外部数据访问错误；初始化或终止条件错误等。 **特点：**

白盒测试

是指实际运行被测程序，通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法、溢出、路径和条件等方面的缺点或者错误，进而加以修正。白盒测试把测试对象看作一个打开的盒子。

 

以下皆为收集各大佬内容整理

Web/App测试区别

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。 
系统架构方面： 
web项目，一般都是b/s架构，基于浏览器的 
app项目，则是c/s的，必须要有客户端，用户需要安装客户端。 
web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。

性能方面: 
web页面主要会关注响应时间 
而app则还需要关心流量、电量、CPU、GPU、Memory这些。 
它们服务端的性能没区别，都是一台服务器。

兼容方面： 
web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容 
app测试则要看分辨率，屏幕尺寸，还要看设备系统。 
web测试是基于浏览器的所以不必考虑安装卸载。 
而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 
此外APP还有一些专项测试：如网络、适配性。。。

APP测试特点

（除了按需求说明书外的 功能测试 之外还需要进行如下测试）

1： 适配性测试（也叫兼容性测试，不同的安卓版本，不同厂商，不同手机品牌）

2： 不同网络测试 （2G网络/3G网络/4G网络/WIFI网络）

3; 在线升级测试

4： 中断测试（电话、短中消息打扰）

5： 耗电量测试

6： 弱网测试（信号差，信号屏蔽实验室）

7： 安装卸载 （C/S）

8: 流量测试

 

测试报告包含内容

 

 

软件测试报告的组成：

一、概述

        包括项目背景、需求分析

二、测试时间、测试环境

三、测试过程

        评审记录、测试范围、测试用例

四、功能实现清单

        列出是否已经按照测试计划实现功能

五、缺陷统计

测试缺陷统计；
测试用例执行情况统计
六、测试统计情况

资源统计
执行情况
问题统计
问题列表
遗留的问题
七、测试总结

测试结论；（是否通过）
测试内容、测试用例的覆盖程度、bug的解决程度
八、测试风险
————————————————
版权声明：本文为CSDN博主「like_that」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn/like_that/article/details/102821357

 

安卓和IOS测试区别和注意点

区别：

1，操作系统：android操作系统较多，IOS较少只能升级不能降级，并且新的版本的资源库不能完全兼容旧版中系统中的应用，如果低版本应用调用了高版本的资源库，会导致系统崩溃

2，安装卸载测试：

              应用发布后：下载安卓包的平台和渠道很多：豌豆荚、应用宝、360手机助手等；IOS 主要有 App store、iTunes

              本地测试：安卓手机可以通过扫码或者直接安卓APK包安装测试包；IOS要安装测试包必须绑定手机的uuid才可以安装ipa测试包

3，按键操作测试：安卓手机针对每一款手机有不一样的操作；苹果手机操作习惯单一

4，开发语言：虽然同样的业务安卓和IOS的展示形式和业务一致，但是底层全完不一样。安卓的应用是有java语言实现的;iOS用objectC实现

App登录方式和测试重点总结

所有软件测试基础课程中，都会拿注册登录做例子，网上也能搜一堆，尤其是对于普通账户密码登录的情况，需要考虑账户密码的长度限制、字符类型、匹配判断等等。

 

目前市场上APP常用的登录方式有账密登录、手势登录，账密登录里又支持邮箱、账号、手机号登录。对于同时支持多种登录方式的APP，测试时除了考虑每种方式是否能够登录成功以外，特别需要考虑不同登录方式的优先级、对于用户习惯登录方式的设置和记忆、各种登录方式之间的切换、不同设备的不同方式登录等等。

 

今天与大家一起对App登录方式及测试重点进行梳理，主要关注一些特殊点，以及容易出现漏测的情况。

首先是账密登录的手机号支持，先了解下手机号登录的通用流程图： 

 

一、输入手机号

1．通用运营商覆盖。

国内主流的三大运营商，移动、联通和电信号段。

如果APP有海外版，那么要考虑海外的电话号码格式和运营商号段。

 

2．虚拟号段。

通常情况下测试人员都会考虑到不同运营商的手机号，但是会容易漏掉虚拟号段170和171，而170和171因为是虚拟号段，并无实名制，所以大肆被不法份子所利用的号段，更是容易被一些恶意用户用来薅羊毛。

 

3．新开放的号段。

随着政策变化，国家会时不时开放一些新号段，比如近期开通的联通166，移动198和电信199，也是测试人员容易忽略掉的。

 

二、输入验证码

短信验证码一般的原理是，前端APP通过短信接口提交一个请求，向服务端提供一个Token参数，服务端对这个Token参数进行校验，校验通过之后，再通过该接口向用户手机发送短信。

 

1．验证码时间限制

通常验证码有两个时间限制，一个是触发发送的时间，可以有效的避免对单用户的短信轰炸。通常的表现形式是，在界面上，一旦触发短信发送后，会设定一个一定时间的倒数，可以是60s，也可以是120s，以此来控制用户无法重复多次提交发送短信验证码的请求。

另一个是接收后的验证码有效时间限制。超过限制时间，校验时会提示该验证码已失效，需要重新获取。

 

2．验证码次数限制

对于连续获取验证码但不进行校验的手机号，应该要有防刷机制，系统可对该手机号进行保护。达到设定次数时提示超过上限，无法再次触发给该手机号发送验证码。

对使用同一个手机号在一天内获取验证码，也一般会有个最大值的限制。

 

3．验证码的内容

验证码的内容，一般是跟随验证码触发的场景的，比如注册验证码、交易验证码。另外验证码内容务必要包含品牌的标识，让用户一眼感知到这个验证码是来自什么APP，或者什么公司的。

不管是账密登录，还是手势录，安全都是接口测试和功能测试的重点，也是容易被很多测试人员所容易漏关注的。

 

三、安全的测试

1．登录时效。

登录成功之后的cookie是多久，会否超时自动下线等等。

 

2．登录冲突。

多个设备同时登录一个账户的处理机制。另外跨平台是否支持同一账户同时登录等等。

 

3．登录异常。

跨地域，非常见IP所在地登录的风险控制机制。长时间未登录，突然登录的检测机制等等。

 

4．密文传输。

会否对账户密码进行加密传输，日志脱敏等等。

APP消息推送如何测试？

消息推送功能是很多APP都有的功能，那测试过程需要注意哪些地方？

• 消息推送对象

消息推送一般可以自定义推送对象，有全部推送，精确推送，及安卓和IOS渠道推送，注意推送对象是否正确，推送之前确认自己是否在测试环境操作，以免造成生产问题。

• 消息简介

客户端收到消息推送有两种形式，客户端后台运行一般推送显示在通知栏，客户端前台运行一般弹出弹框，简介内容注意字数过多溢出情况。

• 消息详情

注意详情所支持的内容，包括文字、图片、表情包、换行以及链接跳转。

• 消息推送场景（支持定时推送）

（1）消息推送时间：

a)设置过去时间

b)未推送之前修改消息内容

c)删除消息，查看是否还会推送

（2）客户端运行状态

a)前台运行

b)后台运行

c)进程关闭状态

（2）特殊场景

a)多个提醒冲突

b)当天设置当天推送

c)当天设置隔几天起效

常见接口协议

TCP/IP协议成为基础的网络协议，涉及四层：应用层、传输层、网络层、网络接口层

TCP协议

TCP协议是在传输层中，一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP与UDP的区别

• TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景（通话等）
• UDP：不需要提前建立连接，实现简单，适用于实时性高的场景（视频传输、游戏传输等）

Restful软件架构风格（软件架构状态转换）

• 借助于http协议的基本请求方法代表资源的状态切换
• post：新增或者更新
• get：获取资源
• put：更新资源
• delete：删除资源

RPC协议

以本地代码调用的方式实现远程执行
Dubbo、gRPC（语言中立、平台中立的数据序列化框架）、Thrift均支持RPC协议

常见状态码

状态码	状态码英文名称	中文描述
100	Continue	继续。客户端应继续其请求
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求
300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy	使用代理。所请求的资源必须通过代理访问
306	Unused	已经被废弃的HTTP状态码
307	Temporary Redirect	临时重定向。与302类似。使用GET请求重定向
400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
409	Conflict	服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突
410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
412	Precondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed	服务器无法满足Expect的请求头信息
500	Internal Server Error	服务器内部错误，无法完成请求
501	Not Implemented	服务器不支持请求的功能，无法完成请求
502	Bad Gateway	充当网关或代理的服务器，从远端服务器接收到了一个无效的请求
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP Version not supported	服务器不支持请求的HTTP协议的版本，无法完成处理

 

接口测试原理、流程

接口测试的原理是模拟客户端向服务器发送报文请求,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的一个过程。
接口测试流程：

　　　　模拟客户端连接服务器(服务器提供的端口是否可访问)
　　　　　　　　↓
　　　　客户端发送报文请求
　　　　　　　　↓
　　　　服务器端接收请求并做处理
　　　　　　　　↓
　　　　检查返回的预期结果并与实际结果对比
　　　　　　　　↓
　　　 　　　　结束

 

如何编写接口测试用例

自动化始终只是辅助测试工作的一个手段，对于测试人员而言，测试基础和测试用例的设计才是核心。如果测试用例的覆盖率或者质量不高，那将这部分用例实现为自动化用例的意义也就不大了。

那么，接口测试用例应该怎么编写呢？

接口的定义 ：

    主要是子模块或者子系统间交互并相互作用的部分。

• 1

因此，可以分析，系统间的接口包含三部分：输入、处理逻辑、输出。

应该怎么分析一个接口？

获取接口文档：和黑盒测试一样，我们是从需求文档中去挖掘测试点，设计测试用例。对于接口测试，同样是有对应的接口文档的。

分析接口文档，提取测试点：
1）、输入： 接受哪些参数、参数的类型、可选参数和必选参数等；根据输入参数采用等价类、边界值分析法等进行设计；
2）、业务逻辑：对于一个接口，不同的输入参数或组合，流程或状态的转移是不同，可以根据业务逻辑画出流程图或状态转移图，确保每种状态至少被访问了一次；
3）、输出：根据文档规定的输出，反向设计测试数据，使所有的输出状态都被包含了；

测试用例：同时对输入、业务逻辑、输出进行考虑时，肯定会存在用例的冗余，在最大限度覆盖业务功能和规则下，选取最优用例集合。同时，需要考虑异常数据和场景。

怎么确定用例的覆盖率？

在没有特殊要求的情况下，至少需要考虑以下内容：
1）、业务功能覆盖是否完整
2）、业务规则覆盖是否完整
3）、参数验证是否达到要求（边界、业务规则）
4）、接口异常场景覆盖是否完整

如果接口需求还包含性能或者安全要求，还要对接口进行性能测试和安全测试，就需要考虑：性能指标是否满足要求、安全指标是否满足要求。

总结
对于接口测试，测试采用的方法是与黑盒测试一致的，可以把接口测试看作是没有界面的功能测试；

可以看看大师的文章：https://mp.weixin.qq/s/ZH6gyUe9U12vKGoASgsLvw，提升点点点技能

 

负载测试，并发测试，压力测试区别

负载测试

1、定义：
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。

2、目的：
不把系统搞挂的测试，使系统能够在最大的压力下可以正常运行。从而获取系统指标。

3、方法：
不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点）。系统负载压力包含并发用户数、持续运行时间、数据量等。其中并发用户数是负载压力的重要指标。

并发测试

1、定义：
1、目的：检查系统是否有并发问题，例如内存泄漏、线程锁、资源争用等问题。
2、方法：确定用户并发数，必须知道系统所承载的在线用户数。然后在单位时间内(S)同时发起一定量的请求。
3、确定并发用户数的方法：
例如：公司OA系统账号或者总用户有2000人；最高峰在线500人；但是这500人并不是作为并发用户存在的概念。即并不表示服务器实际承载的压力；有可能40%关注的是首页新闻公告板之类（注意看新闻这个阶段是不能造成服务器的压力）；20%用户在查询资料或者操作表格；20%用户在发呆；20%在页面之间跳转；在这种情况下，只有真正20%用户在对服务器造成实质的影响。
我们将这个查询、操作表格作为一个业务范畴来说；直接将这部分业务并发用户称为并发用户数：
1.计算平均并发用户数：C=NL/T
2.并发用户峰值数：C’ ≈ C+3根号C
公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
假设有一个OA系统，该系统有3000个用户，（可以看注册信息）平均每天大约有400个用户要访问该系统，（日志文件查看）对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
C = 4004/8 = 200
C’≈200+3根号200 = 242
但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值，2或者3.
假如说用户要求系统每秒最大可以处理100个登陆请求，10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候，响应时间还在允许范围呢，就要加大用户数，例如120 等 。个人理解这个用户数就是我们经常说的等价类和边界值法来设定。

压力测试

1、定义：
是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。

2、目的：
把系统搞挂的测试。

3、方法：以负载测试或者并发测试为依据，给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷。

 

需要验证系统是否满足性能指标（比如最大响应时间，最大并发用户数，典型处理时间，吞吐率等）的时候需要性能测试。
性能测试一般来说需要构造近似的用户使用场景，模拟用户请求调用，有时候需要单独测试的话，还可以用mock。

 

测试分析

测试分析的过程，就是明确需求的目的和价值、分析需求的可行性以及评估需求的优先级，最终明确测试对象和测试范围，测试的重点和难点。

步骤	目的
1. 理解需求、分析需求的价值。	理解需求的目的和价值。
2. 分析需求的可行性。	评估实现方案的可行性，是否可以做。
3. 评估需求的优先级。	评估做不做，什么时候做。
4. 测试分析。	1. 明确测试对象、测试范围； 2. 明确测试的重点、难点。

 

性能测试一般流程

step1 分析 性能测试需求
step2 编写 性能测试计划
step3 编写 性能测试用例
step4 编写 测试脚本
step5 设计 测试场景
step6 执行 场景
step7 监控 场景运行
step8 分析 测试结果
step9 系统性能 调优
step10 性能测试总结

ps:重复5-9步直到测试计划完成、结果满意。

 

如何定位性能瓶颈

1、着手在测试前：理清数据流向，数据流程分解

　　通过绘制数据流向图，以便清晰的列出所有可能出现瓶颈的位置，避免在分析过程中遗漏可能的瓶颈点。

  系统架构分解——水池模型

　　要查找瓶颈，首先要对系统的架构有详细的了解，清楚知道所有可能成为瓶颈的位置。只有这样才能在遇到问题是合理的设计测试用例，对流程的各个步骤进行逐一排查。

　　举个例子，家里厨房的水池下水堵了，我们要找原因，首先得知道水池的下水道都有哪些部分：

　　简单的看，可以把下水道分解为水漏、上连接管、回水弯、下连接管最后接入地漏。再查找堵塞位置时，我们就可以将水直接导入回水弯，排除水漏和上连接管道堵塞的可能。

　　应用在测试中，我们也可以利用直接向应用中间件发请求，来排除Web代理层的瓶颈。

　　通过绘制流向图，可以更清晰的展现系统中数据流向，帮助我们在定位瓶颈的过程始终能迅速的分析预计到下一个可能的瓶颈位置。

 

　　如上图，就是在play一个Mobile game时的数据流向图。

　　2、最直观的指征：检索日志中的异常

　　日志是系统异常的最直接反映，通过客户端(负载工具端)、服务器端的日志，可以迅速确定瓶颈可能存在的方向。一些在大用户量大并发情况下的功能问题，也会在错误日志中体现。

　　在性能测试过程中，一般情况是不把全部日志打开的，而是尽量保持与生产环境的设置相同，生产环境开启什么样的日志级别，在性能测试环境中也应该开启同样的级别。

　　但是往往在生产环境出于性能考虑，并不会把日志级别开的非常高，所以在发现系统存在性能问题时，我们可以适当调高日志级别，以便获得更多的信息。

　　在日志中，我们可以由一些关键字直接推断出系统的问题所在，比如：

　　· Too many open files

　　Linux下存在句柄数限制，系统的默认值较小，在测试前应该优化，另外还要怀疑是否程序存在打开句柄却在某些情况下没有关闭。

　　· OutOfMemoryError/Cannot allocate memory

　　Java环境的虚拟内存异常，往往需要关注是否有溢出。

　　· SQLException

　　数据库语句执行异常，一般日志中还会有数据库返回的信息。

　　· Connection closed/connection refused

　　连接被关闭被拒绝，一般是连接数限制不能承担当前的压力。

　　3、最底层的反映：分析硬件资源占用

　　硬件资源也是系统性能达到瓶颈点的重要指征，如果没有在日志中找到异常，那么通过监控硬件资源消耗，往往可以发现系统的资源瓶颈。

　　3.1 CPU占用率

　　CPU的高占用，并不一定表示有问题，因为实现最优性能的一方面就是充分发挥当前的硬件资源能力。

　　但是如上图这样CPU长期出于满负荷，就很值得我们关注，至少说明在大多数情况下，系统已经是在耗用最大的计算能力进行计算，运算能力已经成为瓶颈。

　　另外还要注意CPU是消耗在User还是Sys还是Wait, 如果是Wait，还要观察其他硬件资源，查看CPU是在等待什么。

　　3.2 内存占用

　　内存在性能测试中是被重点关注的指标，因为它是反映重大缺陷——内存泄露的最直接指标，但是我们应该注意到，在JAVA框架中的内存泄漏是发生在虚拟内存中的。

　　观察内存/虚拟内存的占用情况，尤其是在压力消失后的内存占用恢复情况，是比较直接的判断内存泄漏的依据。

　　如果观察到如上图的内存使用情况，在每次Full GC后，占用的内存都没能恢复到原来的水平，如果在压力撤除一段时间后，内存依旧不能恢复，那么十有八九当前系统存在内存泄漏。

　　3.3 磁盘I/O

　　通常情况下，磁盘是计算机中速度最慢的一个子系统，因此很多情况中，磁盘I/O会成为系统的瓶颈。实际上在设计高性能系统的时候，会把避免磁盘I/O作为一个首要准则。

　　虽然当前的技术发展让存储系统的读写速度不断提升，但高昂的成本使得大多数情况下，高速存储会使用在数据库或文件服务器上，而不会使用在应用服务器中。所以在我们进行性能测试时，要更多的注意应用服务器的磁盘使用情况。

3.4 网络I/O

　　很多时候大家都容易忽略网络对系统的影响，实际上网络带宽在一些情况下也会成为系统的瓶颈。一旦在业务的请求和响应中包含较大的数据传输时，往往会遇到网络瓶颈。因为更多的时候服务器采用的还是以太网卡，1000M网卡在全双工模式下传输速率也只有80M/s，如果响应中包含报表、图片之类的大尺寸数据，很有可能在性能测试中出现网络瓶颈。

　　还有一点就是不要忽略回环地址传输的影响，比如一些应用访问本地监听的其他服务，都会受到网卡的传输速率限制的影响。

　　4、软件性能软肋：数据库的监控分析

　　对于Web系统，超过七成的瓶颈都出现在数据库子系统，因此在进行之前几步不能明确瓶颈位置的时候，应优先进行数据库的监控分析。

　　Oracle数据库监控工具

　　Oracle本身提供了ASH，AWR等Report来帮助进行性能分析，但是对于测试人员来说，掌握这些需要较深入的数据库知识学习，不是一朝一夕可以达成的。而一些第三方提供的工具，通过图形界面，可以更加直观的帮助我们进行Oracle数据库的监控和分析。

　　Lab128就是国内开发的一块很不错的共享软件，而且它还提供无限期的试用key，可以免费试用。

　　Oracle中的等待事件

　　判断Oracle中的瓶颈，了解Oracle中的等待事件Wait event，对于查找瓶颈有很大的帮助。在Oracle中，处理SQL的过程，会产生一系列的等待事件。

　　有等待事件并不代表数据库存在瓶颈，正常的处理也会有等待事件，但如果发现等待事件激增，或者SQL执行缓慢，这时候等待事件中排名靠前的事件将会直接反映出瓶颈所在。

　　上图是在测试中的某一时刻，log sync的等待事件突然增高，同时数据库的吞吐率大幅下降，原本正常的SQL执行速度也突然变长。

　　因为压力并没有突然改变，很有可能是写log的过程出现了问题，或者是在传输过程，或者是在存储子系统。后来经过排查，发现是存储集群的一个存储单元出现故障导致写入速度变慢致使出现大量等待。

　　5、最后的大杀器：应用服务器监控及代码分析

　　如果没能在其他位置发现瓶颈，那么软件程序所运行的平台——应用服务器很可能是最大的潜在瓶颈点，进行应用服务器的监控与分析将是我们最后的大杀器。

　　5.1 常见的软件资源种类

　　相对于硬件资源，软件资源往往容易被忽略，它不像CPU占用率那么让人更直观的和性能联系起来，但是实际上，软件资源同样限制着软件系统能达到什么样的性能。

　　软件资源不论是在Web层，应用层还是在数据库层，都可以按“入口”、“内部”、“出口”来划分。对于常见的原因中间件，“入口”就是如HTTP连接池之类，是数据来源方向的相关设置，比如连接数限制，超时时间，连接回收策略等等；“内部”就是处理请求的各项资源，不如线程数，线程调度策略，虚拟内存设置，GC策略等等；“出口”则是向后端交互的各项资源，如数据库连接池的配置。

　　5.2 应用中间件监控

　　要了解软件资源是否成为瓶颈，我们就需要监控这些软件资源指标。以JAVA环境为例，Weblogic 本身就有控制台，提供了各种计数器。

　　上图显示的是Execute Threads的计数器，对请求的处理就在这些Thread中进行。

　　Tomcat也有开源的控制台，常用的像PSI-Probe，提供了Tomcat服务器各项资源的图形化监控。如下图中对JVM的监控。

　　5.3 应用中间件剖析

　　仅仅监控只能初步判断问题的方向，例如发现ExecuteThreads持续的增加，我们虽然知道这个现象不正常，但是想要确定是程序中的哪个方法导致了当前问题，我还需要其他的工具进行深入剖析。

　　对于Java程序，最常用的工具有JProfiler，YourKit，jvisualvm，他们的原理类似，都是要把一个小插件挂在到应用服务器上，以获取需要的程序运行信息。

　　而Sun在JDK1.7后版本整合了继承自JRockit的MissionControl，也提供了很强大的分析监控功能，而且开销较小，确实是个不错的选择。

　　它们提供的内存泄漏检测工具可以对对象的创建进行趋势分析，帮你找到最有可能出现泄漏的对象，

　　再通过展开剖析工具中的invoke tree（调用树），找出创建该对象的方法，可以更细致的定位问题的原因。

　　同时，方法视图也可以依据CPU时间进行分析，找到在虚拟机中消耗最高的方法。

性能测试常见指标

• 吞吐量：每秒钟系统能够处理的请求数、任务数。

• 响应时间：服务处理一个请求或一个任务的耗时。

• 错误率：一批请求中结果出错的请求所占比例。

• QPS（TPS）：每秒钟request/事务 数量

• 并发数： 系统同时处理的request/事务数

• 响应时间：  一般取平均响应时间

如何区分前端bug还是后端bug？

软件测试工程师的职责是发现BUG，此外，如何体现个人价值？那么我们试想，只提出问题而不去解决，问题就永远得不到闭环。所以，一个资深的测试人员的基本功应该是这样的：深挖业务和功能需求，找出BUG，定位BUG，提出解决方案。这里我们就来说说，当我们找到了BUG，应该把BUG提交给谁去解决，这属于BUG定位的问题。
试想:
根据需求，用户头像应是圆形，但结果是方形，是谁的BUG？
保存用户信息时，无法保存成功，也没有错误提示，最可能是谁的BUG？
显然，工作过程中，我们不可能把这些BUG提交给同一个人去解决。我们应该至少区分出是前端还是后端BUG，就好像时下流行的词“垃圾分类”，经过BUG分类处理，整个团队的效率都会有所提高。
一.什么是前端/后端？
目前多数互联网项目都是前后端分离开发的，那么什么是前端？什么是后端？简言之，前端侧重于页面设计，后端侧重于服务开发。
比如要保存一个用户信息，前端把界面显示给用户，让用户按需填写，当用户点击“保存”按钮时，数据会通过网络被提交给后端服务，由后端服务处理是否需要进一步运算，并且把数据保存在哪一个数据库的哪一张表里。
二.为什么要区分前端/后端BUG？
目前多数项目都是多人协作开发的，如果不能明确这个BUG是谁造成的，容易提交给错误的开发人员，会大大降低BUG的解决效率。
另外，如果团队规模较大，或者由各地的项目组拼凑而成，势必会增加沟通成本，这更需要我们在类似禅道或者Jira等项目管理软件中提交BUG时，先指明是谁的BUG，避免互相踢皮球的现象。
所以，为了提高团队效率，测试人员尤其要做好BUG分类。
三.如何定位前端/后端BUG?
对于一个优秀的软件测试工程师来说，区分BUG属于前端还是后端是尤为重要的。
页面请求过程
弄清楚如何定位和分类BUG之前，需要了解一下页面请求的过程，以 http 请求为例，请求过程如下：
用户在前端页面操作，如点击某个功能
页面携带数据进行请求，访问具体功能接口
由后端服务执行该接口相应的业务逻辑，如涉及数据，再去请求并组装数据返回给前端
前端页面进行渲染和展示对应的页面和数据
前后端BUG各有什么样的特点？
前端BUG
– 界面相关
– 布局相关
– 兼容性相关
后端BUG
– 业务逻辑相关
– 性能相关
– 数据相关
– 安全性相关
定位BUG属于前端还是后端，有什么方法？
这里提供了几个方法，可以给大家一个思路，让大家能在学习和工作中了解如何去区分BUG属于前端还是后端。
经验法
软件测试人员应不断精进自己的技能，负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类BUG了。
例如：
网页上的某个图片的分辨率不对，如果我们了解实现过程，可以想到一般情况下，是根据某个地址去服务器取图片的，数据库一般只保存地址，那么图片能正确显示，就说明后端的基本功能是满足需求的。如果具体图片分辨率有误，最可能的原因是前端显示过程出了差错。
日志查看法
当我们发现一个BUG，并不确定这个BUG属于前端还是后端，可以查看后端服务的日志，复现BUG时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析。
接口查看法
这种方法常用于查看是后端返回给前端的数据有误，还是前端显示有误。
大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。
通过Chrome看到的接口情况如下

可以在Response中查看响应数据

我们需要对比通过后端接口拿到的数据和前端显示的数据，来确认问题出在哪里。如果数据错了，页面显示是错的，也是正常的，先从后端入手去解决。如果数据对了，但是显示错了，就需要问问前端的开发人员了。
四.经验和总结
沟通很重要
我们在定位BUG的过程中，最不能忽略的一个问题是和开发人员的沟通，有时候忙活半天，不如一问一答。经验和技术的成长也都离不开合理高效的沟通。
经验和小结
出现样式的问题基本都是CSS的BUG
出现文本的问题基本上都是html的BUG
出现交互类的问题基本上都是Javascript的BUG
其他问题先沟通，再定位

给你一个网站如何测试

1.寻找相关文档，如需求说明书、网站设计文档等 ；

2.测试工作开展前需要确认以下几个方面的问题：
制定测试计划、制定测试策略及测试边界、确定测试人力资源、确定测试环境配置、确认测试工具、确认测试方法包括不限于以下：功能测试、界面测试、易用性测试、兼容性测试、安全测试、数据库测试、压力测试、负载测试、性能测试

3.设计测试用例时，需要分两部分：
3.1 后台管理功能测试 一般主要功能有：
功能测试、界面测试、易用性测试、兼容性测试、性能测试、安全测试、数据库测试等
3.2 用户功能测试 一般主要功能有：
功能测试、界面测试、易用性测试、兼容性测试、性能测试、安全测试、数据路测试等
-功能测试主要关注：
浏览、操作、切换、跳转、注册登录等
-界面测试主要关注：
页面布局、分类显示、文字描述、图片显示、多媒体播放、标点符号使用等
-易用性测试主要关注；
浏览操作是否简单、方便、易懂 注册登录是否简单、方便、易懂
-兼容性测试主要关注：
操作系统、浏览器、数据库、软件平台等兼容性
-性能测试：
压力测试、负载测试、并发测试等
-安全测试： 登录的安全检查 是否存在溢出，导致安全泄露等 相关开发语言的安全性测试 数据库的读取及保存等安全性测试
-数据库测试： 数据库的读取、保存、并发等测试
4.测试执行
4.1 搭建测试环境
4.2 人力合理分配
4.3 测试管理工具
4.4 按计划执行测试，并记录BUG
4.5 建立风险管理，预防人力不足、需求变更、时间太短等情况发生
4.6 建立测试文档管理工作
4.7 定期组织评审、回溯、难点分享、业务学习等工作 测试结束： 统计缺陷数据、汇报版本质量、性能测试结论、按轮次输出测试报告等

 

提交bug时，应该说明哪些信息？

提交bug时，应该说明哪些信息？
**1.**所属项目，测试平台，系统版本，严重程度，优先级，简述标题，详细描述（问题描述，重现步骤，重现条件，期望结果，实际结果）日志截图，指派给对应开发

2.问题要尽量定位到准确复现步骤或错误原因，一般提交bug包含：主题，详情描述（前置条件，步骤，预期结果，实际结果），所属平台，指派人，能辅助直观查看问题的附件，比如日志截图，信息包，界面功能截图）
不能重现或者不能定位原因步骤的问题，要尽量提供bug所在的环境，曾经操作步骤，及目前的外在条件，并协助研发人员查找。

3服务端：测试环境-测试模块-复现步骤-接口url-入参-出参-错误日志-期望值
前端：测试环境-测试模块-复现步骤-截图-期望效果

4说明当前操作环境以及所属模块，影响的版本，指派给谁，bug的类型，bug 的等级，bug的标题，重现步骤最好能有截图和视频类附件，以及导致的结果，预期结果

5
1)测试的环境
2)bug的标题
3)复现步骤
4)预期结果
5)实际结果
6)影响范围
7)图片视频等附件
8)bug的严重程度
9)修改bug的优先级

6
1环境 在什么情况下出现的bug，例如用WiFi或用数据的情况下，等
2步骤 如何发现bug的过程步骤，可用录屏等操作
3确定 确认bug的必然性，偶然性，可复性
4证明 需给予证明，时间，截图，log文件，录屏等
5定级 确认bug登记，缺点，错误，故障等
6结果 将bug的结果用显目颜色标识，提交的时候，写好标题，附上证明，写上姓名，便于找到
7)硬件测试需要提交硬件相关信息，硬件所在软件环境，如系统信息，fw信息，driver信息等等。然后是问题的复制手法或者详细步骤，发生的概率，尽量提供问题的根本原因，所以需要一定的分析问题的功底。最后就是提交问题相关的log文件

 

描述一个测试活动完整的过程。

详细的描述一个测试活动完整的过程。（供参考，本答案主要是瀑布模型的做法）

项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

测试用例完成后，测试和开发需要进行评审。

测试人员搭建环境

开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

如果有客户反馈的问题，需要测试人员协助重现并重新测试。

web与APP（移动端）测试的区别

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。

根据两者载体不一样，则有如下区别：

系统结构方面

Web项目，是b/s架构的，基于浏览器的，Web测试只要更新了服务器端，客户端就会同步会更新；

App项目，是c/s结构的，必须要有客户端，App 修改了服务端，则客户端所有核心版本都需要进行回归测试一遍（因为并不是所有用户都会更新客户端）；

性能方面

Web项目 需监测 响应时间、CPU、Memory；

App项目 除了监测 响应时间、CPU、Memory外，还需监测 流量、电量等；

兼容方面

Web项目： 

web是基于浏览器的，所以更倾向于浏览器、电脑硬件、操作系统，不过一般还是以浏览器的为主：

1. 一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）；

2. 操作系统（Windows：Win7、Win8、Win10；Mac；Linux等）；

App项目：

App的测试则必须依赖Phone或者是Pad，不仅要看分辨率，屏幕尺寸，还要看设备系统、运营商等,系统一般来说分为Android和IOS，不过Android系统定制的比较多，可能会出现兼容性问题：

1. 设备系统:：IOS、Android

IOS：ipad、iphone；

常见版本：11.0、10、9.0；

Android系统：常见品牌有华为（EMUI）、小米（miui）、OPPO、VIVO、三星等；

常见系统版本：9.0、8.0、7.0等

2. 分辨率不同

常见分辨率：

2960*1440、2560*1440、2436 * 1125、2340*1080、2280*1080、2246*1080、2244*1080、2244*1080、2220*1080、1920 x 1080 、1334 x 750、960*540；

3、运营商

主要运营商：移动、联通、电信

相对于 Wed 项目，APP有专项测试

1. 干扰测试：中断，来电，短信，关机，重启等

2. 弱网络测试（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等）

3. 安装、更新、卸载

安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况；

卸载：需考虑 卸载后是否删除app相关的文件；

更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新；

4. 界面操作：关于手机端测试，需注意手势，横竖屏切换，多点触控，前后台切换；

5. 安全测试：安装包是否可反编译代码、安装包是否签名、权限设置，例如访问通讯录等；

6. 边界测试：可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖（QQ、微信登录）等；

7. 权限测试：设置某个App是否可以获取该权限，例如是否可访问通讯录、相册、照相机等；

测试工具方面

自动化工具：APP 一般使用 Appium; Web 一般使用 Selenium

性能测试工具：APP 一般使用 JMeter; Web 一般使用 LR、JMeter

 

灰度发布

我理解的灰度发布，主要是按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈（如：微博、微信公众号留言或者产品数据指标统计、用户行为的数据埋点）以及对新版本功能、性能、稳定性等指标进行评论，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。

1、什么是灰度发布，有哪些好处？

答：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。

在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。（来源于百度百科）

好处：

1. 提前获得目标用户的使用反馈；
2. 根据反馈结果，做到查漏补缺；
3. 发现重大问题，可回滚“旧版本”；
4. 补充完善产品不足；
5. 快速验证产品的 idea。

2、那么灰度发布的流程是咋样的呢？

相关解释：

• 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
• 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
• 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
• 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

 

 

软件测试之 【移动端测试】——安装与卸载

软件测试之 【移动端测试】——安装与卸载

•  

安装

1.正常安装测试，检查是否安装成功。
2.APP版本覆盖测试。例如：先安装一个1.0版本的APP,再安装一个高版本(1.1版本)的APP，检查是否被覆盖。
3.回退版本测试。例如：先装一个2.0版本的APP,再安装一个1.0版本的APP,正常情况下版本是不可以回退的。
4.安装时内存不足，弹出提示。
5.根据安装手册操作，是否正确安装。
6.安装过程中的意外情况（强行断电、断网、来电话了、查看信息）等等，检查会发生的情况。
7.通过‘同步软件’，检查安装时是否同步安装了一些文件。
8.在不同型号、系统、屏幕大小、分辨率上的手机进行安装。
9.安装时是否识别有SD卡，并默认安装到sd卡中。
10.安装完成后，能否正常启动应用程序。
11.安装完成后，重启手机能否正常启动应用程序。
12.安装完成后，是否对其他应用程序造成影响。
13.安装完成后，能否添加快捷方式。
14.安装完成后，杀毒软件是否会对其当做病毒处理。
15.多进程进行安装，是否安装成功。
16.在安装过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。
17.安装之后，是否自动启动程序。
18.是否支持第三方安装。(华为 oppo 小米 百度应用市场 豌豆荚 应用宝 /.....)
19.在安装中点击取消。(进行安装之后不能取消的)

卸载

1.用自己的卸载程序进行卸载，检查是否卸载干净。
2.用第三方工具，检查是否卸载干净。
3.在卸载过程中，点击取消按钮，看是否正常退出卸载程序，检查软件是否还能继续正常使用。
4.卸载过程中，出现意外（比如手机关机，没电，查看信息，接打电话），程序是否还能运行。
5.在卸载过程中，突然重启设备，再次访问程序，是否还能运行。
6.在没用使用程序时，删除目录文件，看程序是否能运行。
7.在使用过程中，直接删除目录文件，程序是否还能运行。
8.不同系统、硬件环境、网络环境下进行卸载。
9.卸载成功后，是否对其他程序有影响。
10.卸载后再次安装，是否正常使用。
11.在卸载过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。

---------------------------------------------PC电脑上-------------------------------------------------------
PC电脑安装
没安装过的PC中进行安装 缺省项安装功能验证
存在老版本且正在打开该软件 存在老版本且并没有打开该软件 存在更新版本，相同路径安装 存在更
新版本，不同路径安装 存在相同版本，相同路径安装 存在相同版本，不同路径安装 卸载后重新安装 删
除文件后安装
安装目录下磁盘空间不足 存在金山、360等杀毒软件 启动该安装多个安装进程 静默安装

安装完成

1.控制面板显示信息正常，包括名称、发布者、版本、支持链接、帮助链接 
2.点击桌面快捷方式，可正常打开该软件 
3.开始菜单有生成相应的快捷方式，可正常打开该软件 
4.HKLM\Software\Seewo\下的注册表信息正常写入 
5.防火墙白名单正常设置 
6.若是卸载安装，则旧安装目录下文件被正常删除 
7.若依赖Flash、k-lite、EasiUpdate和.NET，这些软件安装版本正确无误 
8.若配套安装Seewo其他软件，该软件版本正确 
9.若该软件为双签名，检查软件应为双签名 
10.若该软件为开机自启动，重启PC，软件自启动 
11.若该软件覆盖安装前为已注册软件，覆盖安装后仍为注册状态 
12.安装后重启PC，该软件能正常运行

•  

卸载

1.通过开始菜单上的卸载程序卸载普通软件，此安装时写了系统注册表，软件的所有文件是否完全删除

2.通过开始菜单上的卸载程序卸载普通软件，安装时写了系统注册表，软件的文件删除的同时注册表是否能够完全删除，注册
表删除时是否有提示信息

3.通过开始菜单上的卸载程序卸载普通软件，软件安装后使用过程中下载和保存了个性信息，软件的文件删除的同时是否能够
删除个性信息，在删除个性信息是否提示用户做出选择：删除或保留

4.对安装时写了注册表的普通软件，不使用软件提供的卸载程序，而是直接查找到程序文件，直接删除文件，用以检查是否能
够删除此程序

5.对安装时没有写注册表的程序，使用开始菜单上的卸载程序，执行卸载，完成检查能否完成删除程序文件

6.对安装时没有写系统注册表的普通软件，不使用软件提供的卸载程序，而是直接查找到程序文件，直接删除文件，用以检查
是否能够删除此程序

7.对通过IE下载的组件，安装后通常没有在开始菜单增加控件卸载程序，此类软件执行卸载时选择控制面板- 卸载或更改程序
，查找到对应的程序，执行卸载完成后检查是否卸载正确。在IE加载组件中检查是否还存在

8.对通过IE下载的组件，安装后通常没有在开始菜单增加控件卸载程序，使用一段时间后存在下载用户个性数据的此类软件执
行卸载时选择控制面板-》卸载或更改程序，查找到对应的程序，执行卸载时删除个性信息是否提示用户做出选择 删除或保留
完成后在IE加载组件中检查是否还存在，同时检查个性数据是否完全删除

9.对在开始菜单存在程序菜单，但是已经删除了程序文件的程序，执行卸载，检查系统执行情况

10.对在控制面板的删除和修改程序列表中存在程序名称，但是已经删除了实际程序文件的程序，执行卸载 检查系统执行情况

11.卸载后，再进行老版本的软件安装，检查是否能正常安装并正常使用

12.卸载后，再进行升级版本软件的安装，检查是否能正常安装并正常使用

13.如果当前程序正在运行过程，进行卸载，检查是否进行卸载提示

14.如果是C/S或B/S系统，要检查在客户端程序正在运行过程，是否能进行服务器端程序的卸载

15.在卸载过程中如果出现异常（例如某个服务还没有停止，或后台某个文件还在占用状态时，或安装文件改变了目录等）程序
是否会进行正确检测，在异常排除后，是否能再次成功卸载

16.在卸载过程中出现环境异常（机器重启，死机，断电等情况）时，恢复后，能否进行成功卸载

17.是否可以进行远程卸载操作，如果可以进行远程卸载操作，若在卸载过程中出现网络异常，卸载过程中断 等网络恢复后是否
能再次卸载成功

18.卸载过程是否支持用户进行卸载选择，即只卸载部分内容 如果支持要逐一检查只卸载部分内容对其他功能的使用是否有影响

19.检查卸载后是否系统保存重要数据进行一并删除（而不是放到垃圾箱中），例如登录文件，安全密钥。后台数据库文件或后台
数据文件等

20.对安全性有特殊要求的软件（例如网银个人版系统），在卸载后，要检查对应的网银验证文件是否一并被删除，防止有其他人
安装网银后，又可以继续非法使用他人账户信息

 

一台客户端三百个客户与三百个客户端三百个客户相比对服务器施压的区别

只有一个客户端，三百个用户肯定不能同时进行操作，假设每次一人操作客户端对服务器施压，服务器承受的压力小但持续时间长

 

假设三百个客户端同时进行操作对服务器施压，就要求服务器带宽能够承受三百人同时在线操作，且服务器短时间内承受压力大但持续时间短

在windows下保存一个文件会弹出一个对话框框，为文件名设计一个测试用例用等价类划分

单字节，如A；

双字节， AA、我我；

特殊字符 /‘。‘；、=-等；

保留字，如com；

文件格式为8.3格式的；

文件名格式为非8.3格式的；

/,,*等九个特殊字符。

 

web自动化中常见定位元素方式

id定位

通过了解HTML可以知道id是唯一表示，通过查找id的方法进行查找

name定位

name在HTML中通常指元素的名称

class定位

通过HTML了解到class是指元素的类名

link_text定位

link_text从字面意思上了解到是通过文本的形式进行定位的

xpath定位

xpath定位有多种定位策略，可以通过很多方法进行定位如：name，text，class等，后面可以单独进行写一篇关于Xpath的定位方法

 

简述延时等待方式

强制等待   sleep

程序执行到该位置必须等待所设置时间

隐性等待   wait

隐形等待是设置了一个最长等待时间,如果在规定时间内网页加载完成,则执行下一步,否则一直等到时间截止,然后执行下一步.

显性等待  WebDriverWait

第三种办法就是显性等待,WebDriverWait,配合该类的until()和until_not()方法,就能够根据判断条件而进行灵活地等待了.它主要的意思就是:程序每隔x秒看一眼,如果条件成立了,则执行下一步,否则继续等待,直到超过设置的最长时间,然后抛出TimeoutException

自动化测试用例覆盖率 一般占百分之三十到四十

自动化测试完整运行一遍用例的时间一般是半个小时左右

分层自动化是对产品的不同的阶段都进行自动化测试

α测试

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。

β测试

β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。 只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。

静态测试

 

静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。

包括对代码测试、界面测试和文档测试三个方面：

    对于代码测试，主要测试代码是否符合相应的标准和规范。

    对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。

    对于文档测试，主要测试用户手册和需求说明是否符合用户的实际需求。

动态测试

 动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

    黑盒测试有可能是动态测试（运行程序，看输入输出），也有可能是静态测试（不运行，只看界面）

    白盒测试有可能是动态测试（运行程序并分析代码结构），也有可能是静态测试（不运行程序，只静态察看代码）

    动态测试有可能是黑盒测试（运行，只看输入输出），也有可能是白盒测试 （运行并分析代码结构）

    静态测试有可能是黑盒测试（不运行，只察看界面），也有可能是白盒测试（不运行，只察看代码）

黑盒测试

黑盒测试又称功能测试，数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。测试人员一般吧被测程序当作一个黑盒子。 黑盒测试主要测到的错误类型有：不正确的或遗漏的功能；接口，界面错误；性能错误；数据结构或外部数据访问错误；初始化或终止条件错误等。 **特点：**

白盒测试

是指实际运行被测程序，通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法、溢出、路径和条件等方面的缺点或者错误，进而加以修正。白盒测试把测试对象看作一个打开的盒子。

本文标签：