测试(一)

测试流程

  • 测试需求分析阶段:阅读需求,理解需求,主要就是对业务的学习,分析需求点,参与需求评审会议
  • 测试计划阶段:主要任务就是编写测试计划,参考软件需求规格说明书,项目总体计划,内容包括测试范围
    (来自需求文档),进度安排,人力物力的分配,整体测试策略的制定。风险评估与规避措施有一个制定。
  • 测试设计阶段:主要是编写测试用例,会参考需求文档(原型图),概要设计,详细设计等文档,用例编写完成之后会进行评审。
  • 测试执行阶段:搭建环境,执行冒烟测试(预测试)-然后进入正式测试,bug管理直到测试结束
  • 测试评估阶段:出测试报告,确认是否可以上线

总结

  • 测试流程:了解用户需求--》参考需求规格说明书--》测试计划(人力物力时间进度的安排)--》编写测试用例--》评审用例--》搭建环境--》测试包安排预测(冒烟测试)-正式测试-bug-测试结束出报告--》版本上线--》面向用户

测试过程中遇到了不能复现的bug的时候你怎么办.

  • 一、一定要提交。

1. 记得有这么个缺陷,以后再遇到的时候可能就会了解发生的原因。

2. 尽力去查找出错的原因,比如有什么特别的操作,或者一些操作环境等。

3. 程序员对程序比测试人员熟悉的多,也许你提交了,即使无法重新,程序员也会了解问题所在。

4. 无法重现的问题再次出现后,可以直接叫程序员来看看问题。

5. 对于测试人员来说,没有操作错误这条.既然遇到,就是问题。即使真的操作错了,也要推到程序员那里,
既然测试人员犯错误,用户也可能会犯同样的错误。错误发生的时候,Tester最大。

  • 二、程序不是测试人员写的,出问题也不是测试人员的原因。
  • 至于无法重现,可能的原因很多,因为测试人员看到的只是程序的外部,无法深入程序内部,
    所以把责任推给测试人员是不对的。测试人员的任务只是尽力重现问题,而不是必须重现。
  • 三、下次再遇到的时候,拉他们来看就可以了。

因为问题如果无论如何无法重现,程序员确实也没有什么好的解决方法。而且此类问题即使程序员说修改了,
测试员也没有好的方法去验证是不是。

  • 四、你可以告诉程序员,测试过程是没有错误的。

测试人员只是检查程序中可能存在的问题,虽然测试人员使用一定的手段方法努力去覆盖所有的情况,但这些都是理论的推测。
在实际中,可能因为人员、环境、配置等种种原因出现各种各样的问题,在测试人员这里发现问题是公司内部的事情
,程序发到外面可就是公司的形象问题了。

  • 五、问题无法重现,也要提出,程序员那里可以回复无法再现。问题放在那里,等到再次出现的时候,
    就立刻叫程序员过来查看。实在没有再次出现,最后可以写到报告中,说出现了什么现象,但无法再现
    (比较严重的问题才如此处理,小问题经理之间商量商量可能就算了)。
  • Bug英文单词,本意是臭虫、缺陷、损坏、犯贫、小虫等意思。现在人们将在电脑系统或程序中,
    隐藏着的一些未被发现的缺陷或问题统称为bug(漏洞)。 由于现在社会的发展,bug另有一种引申意义,
    用来形容某事物厉害的超乎想象,BUG可以使电脑系统崩溃、容易被施诈者攻击,现有修复漏洞的工具。

测试过程中遇到开发不认为是bug的bug你怎么办

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

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

3、整理bug的复现的步骤和出现的频率

4、开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug

5、将客户经理 测试 测试经理和项目经理进行确认会来判定是否为bug

6、测试人员需要将bug整理并写入测试总结中

经典用例设计(纸杯、购物车、电梯、登录框、多部电梯具有联动性、视频播放器测试点,三角形的测试设计点、朋友圈点赞的测试用例的设计点、视频播放器测试点、微信发红包)

纸杯测试用例

冒烟测试:杯子是否能盛水
功能测试:
1.能否盛水,能否喝水
2.能否加热,冷藏

性能测试:
1.杯子的容量是多少
2.能否盛开水,冰水
3.能承受多高温度的水,多低温度的水
4.长时间放置是否容易渗水
5.是否容易变形,掉色,保温
6.杯底是否容易脱落

界面测试:
1.界面是否美观
2.杯口杯壁是否圆整

兼容性测试:
1.是否可以盛放酒精,碳酸饮料,牛奶等其他液体,固体

压力测试:
1.使用多大压力杯子会产生严重形变
2.可以堆叠多少纸杯
3.是否容易摔破

安全测试:
1.材质是否无毒,易燃
2.存放其他液体是否会产生化学反应
3.装热水的时候是否会烫伤人
4.长时间放置材质是否会溶解

易用性测试
1.杯子尺寸是否合理
2.是否方便握持,携带,运输
3.是否有隔热/防滑措施
4.是否方便清洗,回收
5.是否方便老人小孩使用

界面是否满足需求文档
尺寸是否满足需求文档

购物车测试用例

界面测试
界面布局、排版是否合理
文字是否显示清晰
不同卖家的商品是否区分明显

功能测试

  • 未登录时
    将商品加入购物车,页面跳转到登录页面,登陆成功后购物车数量增加
    点击购物车菜单,页面跳转到登陆页面
  • 登录后
    所有连接是否跳转正确
    商品是否可以成功加入购物车
    购物车总数是否有限制
    商品总数是否正确
    全选功能是否好用
    删除功能是否好用
    价格总计是否正确
    商品文字太长时是否显示完整
    店铺名字太长时是否显示完整
    购物车中下架的商品是否有标注
    新加入购物车商品排序(添加购物车中存在店铺的商品和购物车中不存在店铺的商品)
    是否支持TAB/ENTER等快捷键
    商品删除后商品总数是否减少
    购物车结算功能是否好用
    将商品移入收藏夹功能是否好用

兼容性测试
不同浏览器测试
pc端和移动端
ios和安卓

易用性测试
删除功能是否有提示
是否有回到顶部功能

性能测试
打开购物车页面要多久
网络环境测试
3G,4G,WIFI网络环境下应用的各功能可以正常运行。
网络异常时,数据交换失败是否会有提醒。
有网切换到无网时,数据是否可以自动回复,正常加载。
只允许内网访问的APP,在连接到外网时是否会有提示。

异常测试
没有内存时,app是否能正常响应。
横屏竖屏切换显示。
APP运行时网络中断。
不断点击和刷新,是否会出现闪退。
APP运行时拨入电话、短信、微信或者其他信息

电梯测试用例

1.功能:上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等;

2.性能:速度、反应时间、关门时间等;

3.压力:超载、尖锐物碰撞电梯壁等;

4.安全:停电、报警装置、轿箱停靠位置、有人扒门时的情况等;

5.可用性:按键高度、操作是否方便、舒适程度等;

6.UI:美观程度、光滑程度、形状、质感等;

7.稳定性:长时间运行情况等;

8.兼容性:不同电压是否可工作、不同类型电话是否可安装等。

登录测试用例

界面UI测试
1.布局是否合理,输入框,按钮对齐方式
2.输入框和按钮的高度,长度是否符合要求
3.界面的设计风格是否与UI的设计风格统一
4.界面的文字简洁易懂,没有错别字

功能测试
1.用户名,密码输入为空,点击查看提示信息
2.输入正确的用户名和密码,点击验证登录成功
3.登录成功后,验证是否跳转到正确的页面
4.用户名,密码如果过长,过短,是否有提示
5.用户名和密码前后有空格的处理
6.用户名和密码中有特殊字符或其他非英文的情况
7.记住用户名的功能
8.登录失败后,不能记住密码的功能
9.密码是否加密显示
10.登录页面的注册,忘记密码,登出等用另一账号登录链接是否正确
11.输入密码时,大写键盘开启是是否有提示信息
12.输入错误的用户名和密码,查看提示信息

性能测试
1.打开登录页面,需要几秒
2.输入正确的用户名和密码,登录成功不超过5s

兼容性测试
1.主流浏览器是否显示成功(IE8,9,10,11,Firefox,Chrome,Safafi)
2.不同的平台是否能显示成功(Mac,Windows)
3.移动设备上是否显示成功(Android,IOS)
4.不同的分辨率

可用性测试
1.是否支持全键盘操作,是否有快捷键
2.输入用户名和密码,按回车,是否可以登录
3.输入框能否可以Tab键切换

安全测试
1.登录成功后生成的Cookie,是否是Http only
2.用户名和密码是否通过加密的方式发给Web服务器
3.用户名和密码的验证,应该是在服务器端,而不是在Javascript前端
4.用户名和密码的输入框,应该屏蔽SQL注入
5.用户名和密码的输入框,应该禁止输入脚本
6.错误登录的次数限制
7.考虑是否支持多用户在同一机器上登录
8.考虑一用户在多台机器上登录

多部电梯具有联动性测试用例

界面测试:
外观(里面、外面)美观性
电梯空间尺寸是否和设计尺寸一致
按钮是否清晰和易懂
显示楼层的显示屏是否安装
是否联系外界的电话、紧急电话
设备检测说明书
安全规范说明书

标识的承重和人数
扶手
镜子
仅提供可到达楼层的按钮
电梯制作的材料

功能测试:
测试电梯能否实现正常的上升和下降功能,每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯
电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候,是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用,三列按钮。
电梯的楼层选择是否可以取消
电梯门的打开,关闭是否正常关闭(自动关闭)。
报警装置是否可用。(满载)
超重时是否能强制关门
超重时重新挪动一下人员是否可以上下行
与另外一部电梯之间是否协作良好。(算法)
电梯的灯光是否满足看书的要求
联系外界的电话是否可用
通风状况如何,人多的时候是否会很热,通风不畅(排气扇)
电梯里面的摄像头是否可用,拍摄是否清晰
门不夹人
伸手的话,应该不会强制关门
管理员可以和内部人通话
在各种场合下,可以强制开门
运行中时,不能按开门键,不会强制开门
在不同情况下(如:有人挡着、马上关门的时候、停电的时候、没有请求的时候…),一直按开门键和关门键
从电梯外部可以强制开门
不同温度下的测试
进入电梯,拨打手机,是否有信号
进入电梯喊话,外面是否能听到
楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
两台电梯能否同时使用(或停用)
其中一台使用,另一台是否可以停用
A电梯按上行,B电梯按上行
A电梯按上行,B电梯按下行
A电梯按上行,B电梯按上下行
A电梯按上行,B电梯按下上行
A电梯按下行,B电梯按下行
A电梯按下行,B电梯按上下行
A电梯按下行,B电梯按下上行
A电梯按上下行,B电梯按上下行
A电梯按上下行,B电梯按下上行
电梯空时如何运转
电梯门开时不进电梯
进入电梯后不做任何操作
电梯门开的时间多长,超过时间后是否自动关门
电梯门开的时间超时后关门到最后2厘米,是否可以撬开门
电梯门关闭后还未上升时,电梯外按下上行(或下行)按钮,电梯门是否会打开
电梯最底层是否有下行按钮
电梯最顶层是否有上行按钮

停靠算法测试:
2部均空闲时,采取就近原则,离乘电梯人最近的电梯优先运行;
有1部运行时,以同行方向且顺路的电梯优先运行,否则安排空闲电梯;
2部均运行时,以方向通行且顺路的电梯优先运行;
每部电梯,在电梯内部每层在上升和下降过程中,再电梯内部均申请每层停靠
每部电梯,在电梯内部每层在上升和下降过程中,再内部没有任何申请的情况下,在电梯外部均申请每层停靠
每部电梯,在电梯内部每层在上升和下降过程中,再电梯内部均申请每层停靠,在电梯外部也申请每层停靠
电梯本来在1楼,如果有人按18楼,那么电梯在上升到5楼的时候,有人按了10楼,这时候是否会在10楼先停下来
电梯下降到10层时显示满员,此时若8层有人等待电梯,是否在8层停。
类似7、8测试步骤地随机测试,在电梯内部和外部均有不同组合申请的情况下,验证楼层停靠是否准确和合理。
电梯的平稳性,是否会上升过快或者下降过快,造成人体不适应反应

可靠性:
无任何申请的时候,可以长时间停留在某层,并且门是关闭的
门关上的一刹那出现障碍物。
长期有障碍物在门口堵住,电梯应该也不会关门或上升和下降
同时按关门和开门按钮。
快速交替按关门开门按钮
点击当前楼层号码。
快速点击不同楼层
上升到顶层后,电梯中的原有下楼请求均会被取消
下降到负楼层后,电梯中的原有上楼请求均会被取消
电梯外部同时按上键和下键会怎样。
长按打开按钮,电梯门是否持续打开
突然停电或超载时的情况,电梯(停靠、正在上升、正在下降)不会坠落,电梯门可以通过外力打开,并且紧急电话可用
电梯运行中,申请马上要经过的楼层停靠,电梯应该不会停靠。
在电梯里面蹦跳,电梯不会出现不稳定的情况。
电压不稳定的情况下的电梯运行情况
电梯不能正常工作的时候是否有监控系统自动报警
电梯不能正常工作的时候,是否有流程可以精确的指定到人进行所有故障解决的高效处理

易用性:
电梯的按钮的设计符合一般人使用的习惯吗.
按钮是否考虑残疾人和小孩儿
楼层显示屏是否处于电梯的上部,方便别人看到
可维护性
是否有方便维修和维护电梯的工作条件(竖井通道、统一断电等)
电梯的常用配件是否容易更换
电梯的维修成本如何
电梯的安装、维护、测试
超过维修年限,是否可以正常运转

...... 等

性能测试的指标有哪些?

资源使用率cpu 内存io 70-75%
TPS
响应时间 2-5-8
电压 电流的损耗 FTP
FTP
响应成功率

所在部门有多人以及分工以及测试如何分工的。。

项目组  前端  后台  移动端  测试

部门负责人的简称,

SA (System Analyst) 系统分析师
在软体开发团队中,属于中高阶的基层管理者与领导者。除了须具备优秀的文字、语言沟通能力之外,还要有良好的分析、组织、逻辑思考能力。当然也需要有良好的人际关系,以及深厚的技术背景与知识。

SD (System Designer) 系统设计师SA
所建构的是属于偏向于领域的概念模型;而SD 则是根据领域模型,再配合实体的平台,考量其效能、稳定、分散与安全性等,所建构而得的软体规格模型。可以以两句话来说明分析与设计的关系 "Do the right thing (分析)" and "Do the thing right (设计)"。

RD (Research and Development engineer) 研发设计工程师
一般有可能会遇到二种RD:一种是会不断发问的RD,一种是都没有问题的RD。然而,常问问题的人大多数是公司重要的人物。会问问题代表着学习心强,表达能力良好。

PG (Programmer) 码农
基本上你必须要具备几项基本的资讯技术才得以胜任多数的资讯工作职位1.必须至少专精一种编程语言C,C++,Java都可以. 2. 必须熟悉Linux操作系统(管理管理服务器). 3. 了解数据库. 4. 熟悉网路架构. 5. 要能读懂英文的技术文件。

PM (Project Manager) 项目经理
一般而言,数据比较大的公司才会有项目管理部(Project Management Department)。负责解决新机种生产、还有新产品研发过程中所有的问题。作为一个好的PM,必须 1.熟悉该产业的生产制造流程. 2.对市场敏感. 3.有好的沟通协调、管理能力。

DBA (Database Administrator) 数据库设计与管理人员
数据库设计与管理人员,最好本身也有写代码的能力,这样在管理数据库上会如虎添翼。

QA (Quality Assurance) 品质保证工程师
就是测试工程师。通过建立和维持质量管理体系来确保产品质量没有问题。

OP (Operator) 操作员 管理员
Sales 业务
专门做销售行销的工作者,负责将公司之产品销售给客户。

posted @ 2021-06-28 19:51  叁年py  阅读(96)  评论(0)    收藏  举报