软件测试常见方法/问题

测试用例的八大要素

• 用例编号

  字符串组成，具有易于识别性和唯一性

• 测试项目（也就是所属模块)

  表示被测试的模块或者单元

• 用例标题

  表明测试点，要简洁明了

• 重要级别

  一般分为高、中、低，视具体的测试点而定

• 前置条件

  进行这个测试用例的前提条件

• 输入

要输入的一些内容或进行的操作

• 操作步骤

  要标明详细的测试步骤

• 预期结果

  标明预期应该要达到的结果

bug级别以及如何定级

bug的级别有致命、严重、一般、建议优化。

• 致命

主流程无法跑通，涉及到金钱等重要数据的严重计算错误，常规操作都能引起系统崩溃，系统异常退出等，这些属于致命bug，要紧急优先进行修改。

• 严重

主要功能存在缺陷或者是功能遗漏，但是不影响主流程测试；还有是数值等轻微的计算错误，数据无法正常更新，这些可以算是严重bug。

• 一般

兼容性不好，界面样式不美观这些界面或性能上的缺陷，影响用户交互体验的，可以算作一般bug，也是软件测试中最常遇到的一类bug

• 建议优化

需求文档上没提及的一些细节，提示语不清晰或者没有，文字排列不整齐，鼠标位置不对等这些界面或用户交互体验可以优化的，可以算是建议优化

工作中的测试流程

• 理解需求，分析需求点和风险点等，参加需求评审；

• 评审完经多方意见修改完善之后最终确认需求文档；

• 定好项目的提测和预期上线时间等；

• 开发给出设计文档；测试想好测试策略，输出测试用例；

• 测试用例发给开发和测试主管看，或者是进行用例评审，这看具体项目的情况；

• 提测之后,搭建环境，执行冒烟用例，通过之后执行测试用例，中间可能会进行补充用例；

• 测试提交bug到缺陷管理工具进行记录和跟进；

• 开发人员改bug；测试进行回归测试；

• 测试完毕后输出测试报告，产品验收，确认是否可以上线。

• 上线之后验证

怎么区分前后端bug

• 浏览器f12打开开发者工具，或者fiddler、charles抓包，postman调接口，看接口的请求和响应。

如果是请求数据的格式或内容有问题，前端bug；如果前端请求的接口和后端定义不一致，前端问题；如果是响应内容有问题，后端bug。如果响应内容没问题，页面显示有问题，前端bug。

• 页面样式问题，前端bug；兼容性问题，前端bug

• 看后端服务日志，如果页面进行操作或者调用接口时，如果日志没有输出信息，那可能这个功能就没有和后端进行交互；如果日志有输出，再去进一步分析有没有错误的日志信息，如果前端传参有误导致报错，则前端bug；如果请求参数正确，返回数据错误，则后端bug。

• 看数据库，如果数据库有正常更新，但是页面没正常显示，前端问题。如果数据库更新不正常，则抓包再深入分析定位bug

测试用例怎么设计

常用7种方法：

等价类划分法

要考虑有效等价类和无效等价类，保证软件具有更高的可靠性

• 有效等价类

  是指合理的，有意义的输入数据构成的集合。

  要尽可能多地覆盖那些尚未被覆盖的有效等价类，直到所有的有效等价类都被覆盖进去

• 无效等价类

  是不合理的或无意义的输入数据构成的集合

  每次仅覆盖一个无效等价类，直到所有的无效等价类都被覆盖

使用场景

• 有数据输入的地方，可以使用等价类划分法

根据测试用例的完整性区分

• 弱一般等价类

遵循单缺陷原则，用例覆盖每一个变量的一种有效值即可，不用考虑无效值

a有3个有效等价类(a1,a2,a3)，b有2个有效等价类（b1,b2)

那么可以设计（a1),(a2),(a3),(b1),(b2)

• 弱健壮等价类

在弱一般等价类的基础上，增加取值为无效值的情况。

在上面基础上，a有两个无效等价类（1a,2a),b有2个无效等价类(1b,2b)

那么可以设计（a1),(a2),(a3),(1a),(2a),(b1),(b2),(1b),(2b)

• 强一般等价类

  遵循多缺陷原则，要求覆盖每个变量的每种取值之间的笛卡儿乘积，即要取到所有变量的有效值的所有组合。

  例如，a变量有3个有效等价类（a1，a2，a3),b变量有2个有效等价类（b1，b2)，那么设计测试用例的时候，就是一共6个测试用例(a1,b1)、(a2,b1)、(a3,b1)、(a1,b2)、(a2,b2)、(a3,b2)

• 强健壮等价类

  在强一般等价类的基础上，增加对无效值的取值情况。

  例如以上的场景，a还有(1a,2a)2个无效等价类，b有(1b,2b)两个无效等价类，那么还要增加（a1,1b),(a1,2b),(a2,1b),(a2,2b),(a3,1b),(a3,2b),(1a,b1),(1a,b2),(2a,b1),(2a,b2),(1a,1b),(1a,2b),(2a,1b),(2a,2b)这几种测试用例

优点缺点

• 优点：减少了穷举法带来的大量测试用例，保证测试效果和测试效率

• 缺点：输入和输出的关系考虑较少，可能会产生一些逻辑错误，需要用其他的用例设计方法进行补充

举例

• 邮箱名输入框，要求6~18个字符，可使用字母、数字、下划线，要以字母开头

等价类表:

测试用例:

边界值分析法

对输入输出的边界值进行测试，通常边界值分析法是作为等价类划分法的补充。

边界值与等价类的区别：

• 边界值分析不是从某个等价类中随便挑一个，而是把这个等价类的每个边界都作为测试条件

• 边界值分析不仅考虑输入条件，还要考虑输出结果产生的测试情况

场景设计法

通过运用场景来对系统的功能点或业务流程的描述。

基本流：通过用例的最简单的路径（无任何差错，从开始直接执行到结束）

备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不加入基本流中。

判定表

是分析和表达多逻辑条件下执行不同操作的情况的工具

• 条件桩： 在左上部，列出问题的所有条件

• 动作桩： 在左下部，列出问题规定可能采取的操作

• 条件项： 在右上部，列出针对它左列条件的取值

• 动作项： 在右下部，列出在条件项的各种取值情况下应该采取的动作

判定表：

因果图

利用图解法分析输入的各种组合情况，适用于检查程序输入条件的各种组合情况

产生背景

等价类划分法和边界值分析法都是着重考虑输入条件，但是没有考虑输入条件的各种组合情况、各种输入条件之间的相互制约关系。这样虽然输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视

错误推测法

靠经验或者直觉推测程序中可能存在的各种错误

get请求和post请求区别

1. 请求方式： get请求的内容只能放在请求头，通过url进行传递。而post请求的内容既能放在请求头，也能放在请求体

2. 请求内容长度：get能传输的请求内容长度较短，而post请求对长度没有限制

3. 缓存： get请求会被缓存，而post请求不会被缓存

4. 安全性：post请求比get请求安全。get请求的参数会直接显示在url上，页面会被浏览器缓存，容易泄漏数据

5. 编码方式：get请求只支持url编码，而post支持多编码方式

http协议和https协议的区别

1. http协议是超文本传输协议，是明文传输的，端口是80

2. https协议是安全版的SSL/TLS传输协议，传输数据是加密的，比较安全，端口是443

3. http请求与响应速度比https要快，https更消耗服务器资源

抓包时发现抓到的请求是乱码的，怎么办

很可能是数据编码的问题，可以在fiddler响应数据页面那点击decode进行解码后正常显示数据

poatman里面body请求有哪些格式

postman中的请求格式可以分为两个大类，一个是params,另一个是body

params: 在这里设置了参数会以?参数1=参数1的值&参数2=参数2的值显示在URL上

body则是将请求参数放在请求体中

body中的请求格式有以下几种：

1. multipart/form-data

   以键值对的格式输入，主要特点是可以上传文件

2. application/x-www-form-urlencoded

   也是以键值对的格式输入，但是不支持文件传输

3. raw

   还可以细分为:json、text、html、javascript、xml等格式

• json

  选择json，则请求头是application/json, 请求参数以json格式进行传输

• text

选择text,则请求头是text/plain

• html

选择html，则请求头为text/html

• javascript

选择javascript,则请求头为application/javascript

• xml

选择xml，则请求头为application/xml

1. binary

   相当于Content-Type:application/octet-stream,只可上传二进制数据，由于没有键值，每次只能上传一个文件

2. GraphQL

   支持使用正文创建和发送GraphQL查询。基本不使用这个

multipart/form-data与application/x-www-form-urlencoded区别

• applicaton/x-www-form-urlencoded是post的默认请求格式，能简洁地将key：value进行分割；而form-data使用长长的分隔符进行分隔。对于多字节的数据会因为编码造成字节量暴增，但是对于单字节或少量数据时，x-www-form-urlencoded是方便划算的

• form-data适合大文本传输，传输文件等

测试水杯/行李箱/鼠标

水杯

• 功能测试

是否能正常装水，正常喝水；是否有盖子，盖子是否适合；水杯是否有保温功能，保温功能是否正常；水杯是否会漏水，盖住盖子之后是否会漏水

• 界面测试

外观是否完整，是否舒适；颜色搭配是否美观；大小是否适中，形状是否合适；是否有图案，图案是否易磨损

• 易用性测试

水杯装水是否方便，喝水是否方便，倒水是否方便；是否防滑；装低温或高温水的时候，是否让手感到不适

• 性能测试

水杯装满水之后，是否会露出来；水杯的最大可使用次数；水杯装高温水时，是否会破裂；水杯装低温水时，是否会破裂；水杯保温性是否能达到要求，水杯掉落之后，是否能正常使用；水杯长时间放置时，是否会发生泄漏

• 兼容性测试

  水杯是否能装其他液体

• 可移植性测试

将水杯放在常温环境，使用是否正常；放在零下环境，使用是否正常；放在高于正常温度的环境，使用是否正常

• 安全性测试

材质是否无毒，装满热水后，是否烫手或者释放有毒物质；放在零下环境，是否会产生有毒物质，放在高温环境，是否会产生有毒物质

行李箱

• 功能测试

拉杆箱大小，厚度、容量、以及各个面的承重情况，超出承重超出容量会有什么影响；拉杆的伸缩是否灵活，开锁解锁是否方便安全

• 界面测试

  考虑箱子的颜色，样式，形状是否符合要求，箱子logo等图案是否符合正确

• 易用性测试

拉杆手把是否防滑，拉链是否顺滑，脚轮是否灵活

• 兼容性测试

是否支持在平地、沙地、楼梯、泥土地等场景使用，还有不同温度下的使用情况

• 安全测试

材质是否无毒；遇高温、下雨等是否会释放有毒物质，边角是否光滑，无棱角，没有危害。

• 压力测试

承重30公斤，脚轮是否正常无磨损，拉链是否正常；提起拉杆使负重箱子处于悬空状态，拉杆是否正常，箱体是否变形，拉链是否正常，将箱子从1米高度扔下，各个面是否正常无磨损，拉杆是否正常展开收回，重复进行压力测试，看什么时候会有磨损以及使用不正常的情况

鼠标

• 功能测试

  鼠标的左键、右键、滚轮键的功能是否正常；是无线鼠标还是有线鼠标；有限鼠标插上电是否能正常使用；是否能正常插拔；线长度是否符合要求；无线鼠标放置上电池是否能正常使用；是否是静音鼠标，使用过程是否有声音

• 界面测试

  鼠标的颜色是否舒适、大小形状是否合适

• 易用性测试

  鼠标按键、滚轮是否易用，线是否容易插拔；使用手感是否舒适，使用是否静音；使用时间过长是否会发热，是否需要频繁更换电池；使用寿命是否长

• 兼容性测试

  在不同的电脑或者主机上使用是否正常

• 安全测试

  材质是否安全，使用时间过长是否会发热烫手，是否会散发有毒物质；长时间不使用是否会耗电，散发有毒物质；使用是否顺滑不割手；砸到人是否危险；从高度摔下是否有磨损或功能是否能正常使用；高温环境下使用，电池是否会膨胀或爆炸

• 压力测试

  在高温下使用，按键功能是否正常；在低温下使用，按键功能是否正常;从高度摔落，什么时候会有磨损，功能无法正常使用

app后台杀死进程之后还能保持登录状态的方法

• 一种可以说是localstorage技术实现的，也就是本地缓存。第一次登录之后会把登录信息存储在localstorage中，杀死进程也不会清除掉localstorage。下次再打开app时，判断localstorage是否存在，如果存在就直接不用登录进行系统。

• token方式

  app初始登录的时候，提交帐号和密码给服务端，服务端根据定义的策略生成一个token字符串，token字符串中包含用户信息、设备ID等信息以保证用户的唯一性。服务端会对token设置一定的有效期。服务端把生成的token发送给客户端，客户端保存token字符串，并在接下来的请求中带上这个字符串。安全性相对更高一点。

• cookie方式

  把sessionId和有效期保存在cookie中，客户端每次请求都会带这个cookie给服务器端进行验证。验证不成功（失效或者其他原因），用户才需要重新登录，否则可以一直保持登录状态

APP测试、PC客户端测试、web测试的区别

• 系统架构方面

  web项目是B/S架构，是基于浏览器的。只要服务器端更新了，浏览器端就会同步更新

  而app、pc客户端是C/S架构，是需要下载专门的客户端进行使用的，如果服务器端更新了，相应的客户端所有的核心版本都要进行回归测试。如果客户端更新了，还要进行升级安装等操作

• 兼容性不同

  web项目要考虑不同操作系统、不同浏览器的兼容性

  pc客户端要考虑不同操作系统的兼容性

  app需要考虑安卓和IOS不同机型、不同版本、不同分辨率的兼容性

• 发布流程不同

  web项目每次更新发布，替换线上的包为最新的包，重启服务即可

  而app需要向应用市场发布，安卓发布的市场像应用宝、小米应用商店等，每个应用市场都要单独审核才能上架；IOS端就需要在appstore进行发布。从提交到审核以及发布，要花费几天的时间。

• 专项测试

  app有一些专项测试：

  1. 安装、卸载、升级测试（pc客户端也需要）

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

  卸载需要考虑是否删除app相关的文件

  升级：分为强制升级、非强制升级、弱网状态下升级等

  1. 交叉/干扰测试（当有电话、闹钟、短信、电量不足提示，关机、重启等外部事件中断时）

  2. 操作测试（手势测试、横屏竖屏测试，多点触控，前后台切换）

  3. 网络测试（弱网和网络切换测试，回退和刷新是否会造成二次提交)，网络切换测试（网络断开后重连，3g切换到4g/wifi等）

  4. 升级测试(升级测试的提醒机制，升级是不是强制性的，如果不升级影不影响原有功能的正常使用，升级后用户数据是否被清空）

  5. 安全测试： 安装包是否可反编译代码，安装包是否签名，权限设置（访问通讯录、相机权限、存储权限等）

  6. 边界测试： 手机的可用存储空间少，飞行模式，系统时间有误，有没有第三方依赖以及是否正常（qq、微信）

  7. 权限测试：是否可以获取访问通讯录、相机、存储等权限

• 性能方面

  web项目需要检测响应时间、cpu、内存等

  app项目除了检测响应时间、cpu、内存等，还要检测流量、电量等。

• 测试工具方面

  ui自动化： app测试一般使用appinum,web一般用selenium

  性能测试：app一般用perfdog，web一般用jmeter,loadrunner

  app可以使用monkey进行压力测试，通过monkey模拟用户触摸屏幕、滑动、按键等操作来对设备上的程序进行压力测试，检测程序多久会发生异常