关于测试的相关知识

最新推荐文章于 2022-10-05 21:33:31 发布

一起去梵蒂冈

最新推荐文章于 2022-10-05 21:33:31 发布

阅读量224

点赞数

本文链接：https://blog.csdn.net/weixin_57802385/article/details/118310671

版权

1、测试流程

a: 测试首先需要分析

第一：阅读需求，理解需求，分析需求

第二：参与需求评审

b: 其次测试需要计划

第一：编写测试计划，参考'软件需求'规格说明书

第二：项目总体计划，测试范围，进度安排，人物力分配

第三：整体测试策略制定，风险评估与规避措施制定

c: 测试设计

第一：编写测试用例，参考需求文档，概要设计

第二：详细设计，编写之后进行评审

d: 测试执行

第一：搭建环境，执行冒烟测试

第二：进入正步测试，bug管理直到测试结束

e: 测试评估

出测试报告，确实是否可以上线

2、测试过程中遇到不能复现的bug怎么做？

第一：为什么会出现不能复现的bug？

a ：测试阶段，执行了一个用例末覆盖的场景，或是随机测试，盲目点，一旦产生bug，

很容易忘记之前是怎么操作的。面对这种情况，根据bug的现象和当前操作页面，

大概推断出进行哪些操作，尝试几次可能路径会找到缺陷步骤

b ：已经提交给开发的bug，在开发环境不能复现，开发要求关闭该bug。分析提交给开发的bug描述是否准确，有没有必要的前置条件，操作步骤是否详细，是否提供必要截图。排查测试和开发环境配置是否相同，要求开发在测试环境中验证成功关闭该 bug

第二：怎么做？

a: 遇到非必然重现的bug，必提bug，而且在bug单中说明重复概率

b: 发现bug时，分析产生原因，多尝试出现的步骤，排除环境和自己电脑配置，例如浏览器和系统的版本，“必要时寻找开发的帮忙”，让开发在代码对应地方检察一下，是否可以从代码层面找出问题

c: 如果还不能复现，在接下来的测试随时保持关注，每次执行相同步骤的时候看是否出现复现的bug

d: 一直未能复现的bug，需要 ‘测试经理’ 定期汇总，选择极高的陷进，组织开发和测试人员投入复现问题，如果经过这样的复现还不能复现，可以降低问题的优先级。在项目前期，至少要跟踪3个版本，还不能复现，暂时关闭该bug，备注说明并不是因为修复关闭，而是经过x个版本后不能复现了

e: 如果项目周期紧张，不能跟踪多个版本，bug就不能关闭，上线后及时关注用户的反馈，假如持续3-4个版本没有出现bug，可以把bug暂时关掉，并且进行备注说明

3、测试中遇到开发不认为是bug的bug怎么做？

a: 找到需求文档或者是原型图进行匹配

b: 尝试多种测试环境和多种测试方法来确认是否为bug

c: 整理bug的复现的步骤和出现频率

d: 开发坚持不认为找项目经理沟通

e: 讲客户经理测试测试经理和项目经理进行确认判断是否为bug

f: 测试人员需要讲bug整理并且写入总结中

4、经典用例设计(纸杯，购物车，电梯，登录框，多部电梯具有联动性)

第一：纸杯

a: 功能

装不同液体(冷热)，形状，容量，材质，是否漏水

b: 界面

颜色、图案、logo、杯口壁是否完整

c: 性

能

是否容易变色、掉色、保温，装水之后多长时间漏水，装热水或者是冷水的时间，杯底是否脱落

d: 易用

尺寸，携带运输握持，隔热防滑，清洗回收，老少皆宜

e: 安全

材质是否无毒、易燃？存放其他液体是否会产生化学反应，装热水是否会烫伤人，长时间存放是材质是否会被溶解

第二：登录框

                        界面布局是否符合人的审美标准及使用习惯
                        字符长度大于用户名限制
                        用户名不允许特殊字符
                        用户名为空
                        用户名、密码不包含OS保留字（*？/\’:”<>|）
                        用户名前有空格是否可以进入（一般可以）
                        用户名末尾有空格，用户名中间有空格
                        用户名支持复制，粘贴
                        密码为空
                        密码小于或大于长度限制
                        密码不用明文显示
                        密码不支持复制，粘贴
                        密码不支持有空格
                        用户名、密码是否区分大小写
                        用户名、密码长度边界值测试
                        合法用户名、密码成功进入
                        合法用户名、不合法密码不能进入，并给出合理提示
                        不合法用户名、合法密码不能进入，并给出合理提示
                        不合法用户名和密码不能进入，并给出合理提示
                        TAB键的使用是否正确
                        上下左右键是否正确
                        若支持ESC键，看是否正常
                        输入回车键后，光标是否正常跳至下一栏
                        验证必填项为空是否可以进入
                        登录次数是否有限制（安全问题）
                        对全角/半角符号的测试
                        不同版本浏览器测试(浏览器兼容性)
                        登录失败，不能正确跳转页面
                        登录失败，给出正确提示信息
                        登录成功时，已经输入的用户名和密码需要清空还是保留
                        登陆不成功时，已经输入的用户名和密码需要清空还是保留
                        用户在两个页面同时登录，怎么处理信息覆盖情况
                        用户登录成功退出后重新登录
                        密码是明文保存吗？
       第三：购物车

界面测试：

　　打开页面后，页面的布局是否合理，显示是否完整；

　　· 鼠标浮动在购物车按钮，迷你购物车界面

显示是否正常；

　　· 不同卖家的商品在不同的table区域显示，区分明显；

　　· 页面的tooltips能正常显示；

　　功能测试：

　　· 所有页面链接功能正常，可以点击到正确页面；

　　· 页面关联本地软件阿里旺旺的icon点击后，能打开软件；

　　· 从商品信息页面添加的商品能显示在购物车中；

　　· 购物车页面打开的同时，在其他页面添加了商品，购物车页面刷新后，新的商品能显示；

　　· 若未登录，点击购物车，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式；

　　· 商品未勾选的状态下，结算按钮是灰色无法点击的；

　　· 勾选商品后，已选商品的总价会显示，结算按钮变高亮可点击工作；

　　· 勾选商品，点击结算按钮后，进入确认订单信息页面；

　　· 购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功；

　　· 卖家在线的时候，旺旺icon高亮，反之，灰色；

　　· 购物车有商品降价或者库存告急的，那么点击对应的tab，降价或者告急商品会归类后显示；

　　· 购物车能添加的商品种类是有数量上限的；

　　不要的商品，可以删除；

　　性能测试：

　　· 打开购物车页面要多久；

　　可用性测试：

　　快捷键功能知否支持

　　兼容测试：

　　· 不同浏览器上的测试功能是否正常；

　　· app上测试

第四：电梯

a: 功能测试 - 单个功能

1、电梯内各楼层键是否正常

2、电梯内开关门键是否正常

3、电梯内的报警键是否正常使用

4、电梯外的上下键是否正常

5、同时关注电梯内外的显示屏显示的电梯层数和运行方向

6、有障碍物时，电梯门的感应系统的有效情况

功能测试 - 模块交互

1.电梯当前状态是上行时，有人在X楼按下上升/下降键，电梯是否会停止

2电梯当前状态是下行时，有人在X楼按下上升/下降键，电梯是否会停止

3.在搭载满员的情况下，如有人在X楼按下上升/下降键，电梯是否会停止

b: 接口测试:

1、电梯和楼层

2、电梯和摄像头

3、电梯与空调

4、电梯和报警装置

5、电梯与显示屏

6、电梯与其他电梯的协作能力

c: 界面测试

1、查看电梯的外观

2、查看按钮的图标显示，大小

3、查看电梯内部张贴的说明（比如报警装置的说明、称重量等）

d: 易用性测试

1、楼层按键高度（小孩和一些身高矮的用户会按键不方便）

2、楼层按键上是否有盲文显示

3. 电梯是否有地毯、夏天是否有空调、通风条件、照明条件、手机信号是否通畅

4、电梯是否有扶手，是否有专针对残疾人的扶手等等

e: 安全性测试

1、下坠时是否有制动装置

2、暴力破坏电梯时是否报警，

3、超重是否报警

4、超时是否自动开门

5、火灾报警后，是否允许就近停靠

6、停电情况下，电梯是否有应急电源装置

f: 兼容性测试

1、电梯的整体和其他设备的兼容性，与大楼的兼容，与海底隧道的兼容等等

2、不同类型的电压是否兼容

g: 性能测试

1、测试电梯负载单人时的运行情况（基准测试）

2、测试电梯承载多人时的运行情况（负载测试）

3、测试电梯在承载一定人数下较长时间的运作（稳定性测试）

4、测试电梯在更长时间运作时的运行情况（疲劳测试）

5、测试不断增加电梯内的人数导致电梯报警情况（拐点压力测试）

h: 验收测试

1.大量用户从1楼上电梯，去向不同的楼层的情况。

2.大家从不同的楼层上电梯，一起到一楼的情况。

5、token cookie session 区别

cookie: 浏览器能“永久”储存的数据，仅仅是浏览器实现的一种数据储存。由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件，下一次请求同一网站把该cookie发送给服务器。由于cookie是存在客户端的，浏览器加入了一些'限制' 确保cookie不会被恶意使用，并且不会占用太多磁盘空间，每个域的cookie是有限的

session: 你和一个人交流，你怎么知道这个谁具体是谁，对方肯对会有某种特征证明他是谁。服务器要知道当前谁发请求给自己。给每个客户端分配不同的身份标识，之后客户端每次向服务器发请求时，带上“身份标识” 就知道谁访问服务器了。对于浏览器客户端，默认采用cookie方式

token: 客户端频繁向服务端请求数据，服务端频繁去数据库查询用户名和密码并对比，判断用户名和密码正确，做出提示。

Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。

使用Token的目的：Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。

cookie与session的区别

1、cookie数据存放在客户端上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5、将登陆信息等重要信息存放为SESSION，其他信息如果需要保留，可以放在COOKIE中

.session与token的却别

1、SSESION：我发给你一张身份证，但只是一张写着身份证号码的纸片。你每次来办事，我去后台查一下你的 id 是不是有效。
2、TOKEN ：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人

6、性能测试的指标有哪些？

        RT：响应时间
        TPS：每秒完成事务数
        CPU性能指标：利用率、负载
        Mem：内存性能指标，可用物理内存、虚拟内存使用率
        Disk：磁盘性能指标，Disk Time、IO等待
        NetWork：网络指标，带宽使用率、任务队列长度
        TCP连接数，可以用netstat命令统计得到
        中间件建立的线程池，监控线程状态
        JVM性能指标，GC情况、Heap使用情况
        CPU负载队列长度
        服务器与中间件之间建立的连接数及连接状态
        一般性能分析的过程
        序号步骤名称说明
        1 检查RT 客户端响应时间
        2 检查TPS TPS大时RT小，说明性能良好
        3 检查负载机资源消耗检查CPU使用率
        4 检查被压服务器的资源消耗 CPU 、内存、磁盘IO、带宽、响应时间
        5 检查中间件配置确定是否有配置参数问题
        6 数据库服务器 CPU、内存、IO繁忙程度、数据库监控