测试流程

1.测试流程

　　

1、测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议。

2、测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。

3、测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。

4、测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束。

5、测试评估阶段：出测试报告，确认是否可以上线。

 

 

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

1、遇到问题就要提，测试的工作就是不放过任何一个bug，在提交的Bug描述中需要加上一句话，那就是复现概率，尝试20次，出现1次或者尝试10次，出现2次，开发会根据bug的复现概率，调整改bug的优先级。

2、尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现。

3、保留发生bug时的log，附加到提交的bug中，希望可以通过log中找到一些蛛丝马迹。

4、与开发人员配合，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题。

5、在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的bug。

通过以上的方法，仍然无法复现，根据bug的优先级，在上线之前对该bug进行处理，严重级别的bug，要召集项目组的成员，集合大家的力量尽可能的复现bug，不严重的bug，也不要关掉，上线后及时的关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将bug暂时关掉了，同时关掉的时候要进行评论说明并不是因为修复，而是经过x个版本后不复现了。

 

3.测试过程中遇到开发不认为是bug的bug时怎么办？

• 1.通过不同方式或者是不同的测试环境来对bug进行确认
• 2.根据需求文档对bug来进行判断
• 3.将bug的出现的频率，已经出现的方式和对应的操作步骤进行书写，将结果 截图或者是录屏
• 4.找对应的项目经理或者是客户经理来bug进行评审 5.将bug进行记录到测试总结中

 

4.经典用例设计

　　1：纸杯

　　　　

结构：用料是否环保?是否能平稳放在桌面上?放了水是否能平稳放在说面上?杯口是否光滑?。。。。。

 

　　功能：到进水是否不漏，是否不变形?拿起来是否能够不显著变形?水是不是能倒出来?

 

　　数据：放半杯水，放一整杯水，放冷水，放热水，放茶叶，放可乐

 

　　平台：能否放在桌子上不倒?手拿着是否不变形，不会感到不舒服?是否能放到杯架、套到别的杯子上?

 

　　操作：倒进水，喝水，再倒水，倒开水，捏变形，弹烟灰，丢弃

 

　　时间：看喝水的时候水是不是很快的能流出来

 

　　2：购物车

　　　　

　　　　1.界面测试

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

　　　　2.功能测试

        　　　未登录时：

• • • 将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加；
    • 点击购物车菜单，页面跳转到登录页面。

       　　　　登录后：

• • • 所有链接是否跳转正确；
    • 商品是否可以成功加入购物车；
    • 购物车商品总数是否有限制；
    • 商品总数是否正确；
    • 全选功能是否好用；
    • 删除功能是否好用；
    • 填写委托单功能是否好用；
    • 委托单中填写的价格是否正确显示；
    • 价格总计是否正确；
    • 商品文字太长时是否显示完整；
    • 店铺名字太长时是否显示完整；
    • 创新券商品是否打标；
    • 购物车中下架的商品是否有特殊标识；
    • 新加入购物车商品排序（添加购物车中存在店铺的商品和购物车中不存在店铺的商品）；
    • 是否支持TAB、ENTER等快捷键；
    • 商品删除后商品总数是否减少；
    • 购物车结算功能是否好用。

　　　　3.兼容性测试

        　　　　不同浏览器测试。

　　　　4.易用性测试

        　　　　删除功能是否有提示；是否有回到顶部的功能；商品过多时结算按钮是否可以浮动显示。

　　　　5.性能测试

       　　　　压力测试；并发测试。

 

　　3.电梯

　　　　功能测试—单个功能：
　　　　　　1、电梯内分楼层键是否正常
　　　　　　2、电梯内开关门键是否正常
　　　　　　3、电梯内的报警键是否正常使用
　　　　　　4、电梯外的上下键是否正常
　　　　　　5、同时关注显示屏，电梯内外的显示屏显示的电梯层数、运行方向是否正常
　　　　　　6、有障碍物时，电梯门的感应系统是否有效
　　　　功能测试—逻辑业务/功能交互
　　　　　　1、功能与功能模块间的集成，可根据电梯当前状态是上行、下行还是停止来设计测试点，以保证覆盖率
　　　　　　电梯当前状态是上行时，有人在X楼按下上升/下降键，电梯是否会停止
　　　　　　电梯当前状态是下行时，有人在X楼按下上升/下降键，电梯是否会停止
　　　　　　在搭载满员的情况下，如有人在X楼按下上升/下降键，电梯是否会停止
　　　2、功能设备与设备间的集成，关注功能接口，比如：
　　　　电梯和大楼层，电梯和摄像头，电梯与空调，电梯和对讲机（报警装置），电梯与显示屏，电梯与其他电梯的协作能力

　　　　例如：一栋楼有2部电梯，一部停在2楼，一部停在4楼，有人1楼按电梯，是否2楼的电梯下降到1楼开
　　　界面测试
　　　　1、查看电梯的外观，按钮的图标显示，电梯内部张贴的说明（比如报警装置的说明、称重量等）
　　易用性测试
　　　　1、楼层按键高度（小孩和一些身高矮的用户会按键不方便）
　　　　2、电梯是否有地毯、夏天是否有空调、通风条件、照明条件、手机信号是否通畅
　　　　3、电梯是否有扶手，是否有专针对残疾人的扶手等等
　　兼容性测试
　　　　1、电梯的整体和其他设备的兼容性，与大楼的兼容，与海地隧道的兼容等等
　　　　2、不同类型的电压是否兼容
　　安全性测试
　　　　1、下坠时是否有制动装置
　　　　2、暴力破坏电梯时是否报警，超重是否报警
　　　　3、停电情况下电梯是否有应急电源装置
　　性能测试
　　　　1、测试电梯负载单人时的运行情况（基准测试）
　　　　2、多人时的运行情况（负载测试）
　　　　3、一定人数下较长时间的运作（稳定性测试）
　　　　4、更长时间运作时的运行情况（疲劳测试）
　　　　5、不断增加人数导致电梯报警（拐点压力测试）

 

　　4.登录框测试

功能测试

 

什么都不输入，直接点击提交按钮，看提示信息
输入正确的用户名和密码，点击提交按钮，看是否能登录成功
输入错误的用户名或者错误的密码，点击提交按钮，看提示信息
登陆成功之后能否正确的跳转到正确的页面
用户名太短或者太长时，应该怎么处理
密码太短或者太长时，应该怎么处理
用户名若含有特殊字符，字母，数字等不同于汉字的，应该怎么处理
密码若含有特殊字符，字母，数字，或者混合类型时，密码强度的变化
用户名和密码中间出现空格时，会怎么处理
用户名和密码前后出现空格时，会怎么处理
记住用户名或者记住用户名和密码的功能（比如刚刚登陆成功之后退出，再次登陆时是否有记录 ）
验证首次打开登录界面，鼠标的输入焦点是否在用户名的输入框以方便用户直接输入
密码的加密显示（如星号或者小黑点）
牵扯到验证码的登录时，要考虑图片上的数字是否扭曲过大导致看不清楚，数字的颜色（考虑色盲患者），验证码的刷新按钮是否有效
登录界面上的注册，忘记密码，退出登录点击后，链接是否有效
输入密码时，切换为大写时是否有提醒

 

界面测试

 

布局是否合理，两个文本框的位置是否对齐，按钮的位置是否合理
文本框的长度宽度是否合理，按钮的大小是否易于点击
界面是否简介易懂，是否有错别字

性能测试

 

打开该登录页面需要多久
登录成功跳转到正确的界面时需要多久

安全测试

 

用户名和密码是否通过加密的方式发给web服务器
用户名和密码是否是在服务端完成验证的，不能只在客户端调用JavaScript来进行验证
两个文本框应禁止输入脚本语言，防止XSS攻击
限制错误登录的次数，防止暴力破解
考虑多用户在一台机器上登录
考虑一用户在多台机器上登录

 

可用性测试

 

输入用户名和密码时常用快捷键在输入文本框中能否使用（ctrl+c，ctrl+v，ctrl+a等）
输入正确的用户名和文本框之后按回车是否可以登录
输入用户名之后按Tab键是否可以转到密码输入框

兼容性测试

 

在主流的浏览器上是否可以正常使用（如IE，谷歌等）
在不同的平台上是否可以正常使用
在移动设备上是否可以正常使用（iPhone，Android）

 

　　5.视频播放测试点

 

功能测试

 

什么都不输入，直接点击提交按钮，看提示信息
输入正确的用户名和密码，点击提交按钮，看是否能登录成功
输入错误的用户名或者错误的密码，点击提交按钮，看提示信息
登陆成功之后能否正确的跳转到正确的页面
用户名太短或者太长时，应该怎么处理
密码太短或者太长时，应该怎么处理
用户名若含有特殊字符，字母，数字等不同于汉字的，应该怎么处理
密码若含有特殊字符，字母，数字，或者混合类型时，密码强度的变化
用户名和密码中间出现空格时，会怎么处理
用户名和密码前后出现空格时，会怎么处理
记住用户名或者记住用户名和密码的功能（比如刚刚登陆成功之后退出，再次登陆时是否有记录 ）
验证首次打开登录界面，鼠标的输入焦点是否在用户名的输入框以方便用户直接输入
密码的加密显示（如星号或者小黑点）
牵扯到验证码的登录时，要考虑图片上的数字是否扭曲过大导致看不清楚，数字的颜色（考虑色盲患者），验证码的刷新按钮是否有效
登录界面上的注册，忘记密码，退出登录点击后，链接是否有效
输入密码时，切换为大写时是否有提醒

 

界面测试

 

布局是否合理，两个文本框的位置是否对齐，按钮的位置是否合理
文本框的长度宽度是否合理，按钮的大小是否易于点击
界面是否简介易懂，是否有错别字

 

性能测试

 

打开该登录页面需要多久
登录成功跳转到正确的界面时需要多久
安全测试
用户名和密码是否通过加密的方式发给web服务器
用户名和密码是否是在服务端完成验证的，不能只在客户端调用JavaScript来进行验证
两个文本框应禁止输入脚本语言，防止XSS攻击
限制错误登录的次数，防止暴力破解
考虑多用户在一台机器上登录
考虑一用户在多台机器上登录

 

可用性测试

 

输入用户名和密码时常用快捷键在输入文本框中能否使用（ctrl+c，ctrl+v，ctrl+a等）
输入正确的用户名和文本框之后按回车是否可以登录
输入用户名之后按Tab键是否可以转到密码输入框

 

兼容性测试

 

在主流的浏览器上是否可以正常使用（如IE，谷歌等）
在不同的平台上是否可以正常使用
在移动设备上是否可以正常使用（iPhone，Android）

 

 

本地化测试

 

不同语言环境下能否正常运行

 

　　6.三角形的测试点

一、等价类划分：三角形三条边A、B、C的数据类型不同
二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，那么边界值分析就不用了
三、因果图法：三角形的三条边数据输入组合
我们看一下三角形的流程图：

我们再分析一下三角形的等价类：
有效等价类：
输入3个正整数或正小数：
1、两数之和大于第三数，如A<B+C；B<C+A；C<A+B
2、两数之和不大于第三数
3、两数相等，如A=B或B=C或C=A
4、三数相等，如A=B=C
5、三数不相等，如A！=B，B！=C，C！=A
无效等价类：
1、空
2、负整数
3、非数字
4、少于三个数
三角形测试用例类别
输入条件 有效等价类 无效等价类
是否是三角形
(A>0) (1)
(B>0) (2)
(C>0) (3)
(A+B>C) (4)
(B+C>A) (5)
(C+A>B) (6) (A<=0) (7)
(B<=0) (8)
(C<=0) (9)
(A+B<=C) (10)
(B+C<=A) (11)
(C+A<=B) (12)
是否是等腰三角形
(A=B) (13)
(B=C) (14)
(C=A) (15) (A!=B)and(B!=C)and(C!=A) (16)
是否是等腰直角三角形 :
(A=B)and(A^2+B^2=C^2) (17)
(B=C)and(B^2+C^2=A^2) (18)
(C=A)and(C^2+A^2=B^2) (19)
是否是等边三角形 :
(A=B)and(B=C)and(C=A) (20)
(A!=B) (21)
(B!=C) (22)
(C!=A) (23)
三角形测试用例：
序号 [A,B,C] 覆盖等价类 输出
1 [3,4,5] (1)(2)(3)(4)(5)(6) 是三角形
2 [0,1,2] (7) 非三角形
3 [1,0,2] (8) 非三角形
4 [1,2,0] (9) 非三角形
5 [1,2,3] (10) 非三角形
6 [1,3,2] (11) 非三角形
7 [3,1,2] (12) 非三角形
8 [3,3,4] (1)(2)(3)(4)(5)(6)(13) 等腰三角形
9 [3,4,4] (1)(2)(3)(4)(5)(6)(14) 等腰三角形
10 [3,4,3] (1)(2)(3)(4)(5)(6)(15) 等腰三角形
11 [2√2,2√2,4] (1)(2)(3)(4)(5)(6)(17) 等腰直角三角形
12 [4,2√2,2√2] (1)(2)(3)(4)(5)(6)(18) 等腰直角三角形
13 [2√2,4,2√2] (1)(2)(3)(4)(5)(6)(19) 等腰直角三角形
14 [3,4,5] (1)(2)(3)(4)(5)(6)(16)(20)(22)(23)(24) 是三角形
15 [3,3,3] (1)(2)(3)(4)(5)(6)(16)(21) 等边三角形
16 [,,,] 无效等价类 错误提示
17 [-3,4,5] 无效等价类 错误提示
18 [a,3,@] 无效等价类 错误提示
19 [3,4] 无效等价类 错误提示

 

　　6.朋友圈点赞的测试点

功能测试

1.给某个好友点赞，点赞数+1，点赞栏显示具体点赞人的名字 ，该用户手动点赞回馈
2.点完赞后，共同好友在点赞区能看到该人是不是点赞
了，非共同好友看不到
3.两个头像一样的人点赞，能否正确显示
4.点完赞后，在点击点变成点赞取消
5.取消点赞--不通知用户
6.点赞后，通知用户，取消，在点赞，此时不通知用户
7.多个用户同时对其点赞，点赞数正常
8.最多能点多少个赞--边界值测试
9.可以从点击点赞区头像，进入相应人的主页查看
10.点赞是否按照时间顺序排序
11.点赞后是否能够正常评论

app端测试

1.弱网情况下，点赞能否实时更新
2.点赞时，有短信或者电话进来，能否显示点赞情况
3.耗电量，耗流量关注

性能测试

1大量用户并发点赞时，该接口的响应时间，最大承受的qps
2.大量用户并发点赞时，此时界面进行点赞，点赞功能是否正常

兼容性测试

1.不同手机型号，点赞功能，显示功能是否正常

 

　　7.微信发红包测试

1、功能测试

1）发给单个好友
①　正确的金额+无留言+无表情
②　错误的金额+无留言+无表情
③　正确的金额+有留言+无表情
④　错误的金额+有留言+无表情
⑤　正确的金额+无留言+有表情
⑥　错误的金额+无留言+有表情
⑦　正确的金额+有留言+有表情
⑧　错误的金额+有留言+有表情
其中，金额（0.01-200）可以测试以下数据

数字：测试0, 0.009, 0.01，0.011, 01， 199.99, 200, 200.01这些边界值
中文、英文、特殊字符或者这几种的组合
是否支持复制黏贴
为空/包含空格
金额的增删查改
留言可以测试以下数据

数字、中文、英文、特殊字符、表情或者他们的组合
输入超长文本时，是否会给出相应的限制或提示
包含空格
是否支持复制黏贴
留言的增删查改
表情可以测试以下数据

选择收藏的表情测试（动图/静图）
选择下载的表情测试（动图/静图）
录制表情，并添加进行测试
表情的增删查改
⑨　点击塞钱进红包，选择零钱付款，此时需要考虑金额＞零钱，金额＜零钱，金额=零钱三种情况
⑩　点击塞钱进红包，选择已添加的银行卡付款，此时同样需要考虑金额＞银行卡余额，金额＜银行卡余额，金额=银行卡余额三种情况
⑪　点击塞钱进红包，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额＞新卡余额，金额＜新卡余额，金额=新卡余额三种情况
⑫　使用指纹确认付款（正确的/不正确的指纹）
⑬　使用密码确认付款（正确的/不正确的密码 ）
⑭　发送成功之后，对应的途径会减少相应的金额
⑮　发送者/接受者可以点击红包查看到红包的具体信息，且金额，留言，表情均能正确显示
⑯　好友点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息
⑰　24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱。24小时后好友点击红包，显示红包已过期，无法查看到红包的余额
⑱　右上角的红包记录中，可以查看刚刚发出的红包的金额
⑲　检测帮助中心中链接是否均可以正常跳转，查看
20 当红包超过24小时之后，则无法查看红包被每个人领取的详细信息

2）发送群红包（与发给好友的测试点相似，以下仅写出不同的部分）
①　选择为拼手气红包时，群中每个人收到的金额随机（但加起来为红包的总金额），为普通红包时，群中每个人收到的金额相同
②　红包个数（1-100）：0，1，2，大于群成员人数，小于群成员人数，等于群成员人数，99，100，101，小数，中文、英文、特殊字符、表情或者他们的组合
③　但红包没有被抢完时，此时首次点击该红包的人可以抢到一定金额的红包，不是首次点击该红包的人只能查看该红包的信息；当红包抢完时，所有人只能查看该红包的信息。
④　在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为最佳手气（若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气）；若没有被完全抢完，则没有最佳手气，且余额会退还到原账户
⑤　群中所有人均可以抢红包（包括自己），每个人最多只有一次抢该红包的机会
⑥　测试当红包个数使得每个红包分到钱小于0.01，即总金额为0.02，而红包个数为3时的情况

 

2、兼容性测试

 

1）苹果手机和安卓手机
2）苹果手机的不同版本
3）安卓手机不同的机型
4）不同分辨率

 

3、性能测试

 

1）打开红包的响应时间不能超过三秒，高并发场景下不能超过5秒
2）耗电量
3）消耗流量的多少
4）所占内存
等

4、UI测试&易用性测试

 

1）界面的设计风格是否统一
2）界面中文字是否简洁，没有错别字
3）是否易操作，易学习，易理解

5、中断测试：前后台切换，网络异常，低电量，断电，来电，短信等
6、网络测试

1）网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信
2）无网测试
3）弱网：延时&丢包

 

 

　　8.token cookie session 三者的区别？

cookies

用户登录以后，在浏览器端生成一个文件，保存在浏览器的客户端
一般存储用户的身份信息
可以删除，删除后重新登录可以再次生成
使用不同的浏览器，电脑登录同一网站，会产生不同的cookies
有的系统会通过cookies存储用户行为习惯
session

登录后服务器端发送一个随机的ID值，来进行用户身份的识别
session的有效性，是在代码中进行设计的，一般是30分钟
session只针对一个应用服务器有效
token

登录后，服务器端发送一个token令牌
token也有时效性
token可以支持多平台访问

 

　　9.性能测试的指标有哪些？

　　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繁忙程度、数据库监控。