zoukankan      html  css  js  c++  java
  • 浅谈软件测试思维

                              浅谈软件测试思路

        

    软件测试思路不能太局限,测试不能局限于功能,其他方面,比如UI、易用性、效果、性能、兼容性及可靠性其实都是一些非常重要的方面,具体测试过程中我们需要开动脑筋,考虑全面,下面从举几个测试案例帮来拓展测试思路。

     

    Eg1、发短信入口

    发送短信入口

    序号

    主入口

    分支

    分支

    分支

    分支

    01

    信息

    直接编辑

    回复

    转发

    草稿箱

    02

    快捷图标

    直接发送短信快捷图标

     

     

     

    03

    电话本

     

     

     

     

    04

    通话记录

    已接

    未接

    已拨

     

    05

    彩信

    短信回复

     

     

     

    06

    网页

    选中-分享

     

     

     

    07

    文件选项

    选中-分享

     

     

     

    08

    照相机

    照相机-图片-分享-转短信

     

     

     

    09

    我的文档

    文件分享

     

     

     

    10

    快捷联系人图标

     

     

     

    11

    搜索联系人

    搜索-联系人-短信

     

     

     

    12

    拒接电话

    快速回复/拒接回复

     

     

     

    13

    非默认语言

     

     

     

    14

    STK

    STK菜单

     

     

     

    15

    第三方

    点播短信等

     

     

     

    16

    飞信

     

     

     

     

    17

    X发送

     

     

     

     

    18

    ……

     

     

     

     

     

    Eg2、拨打电话入口

    拨打电话入口

    序号

    主入口

    分支

    分支

    分支

    分支

    01

    号码盘

    正常拨号

    IP方式

     

     

    02

    电话薄

    SIM

    群组

    手机

    查找联系人

    03

    通话记录

    已拨

    已接

    未接

     

    04

    紧急拨号

    锁键盘紧急拨号

     

     

     

    05

    搜索—联系人

     

     

     

     

    06

    自动重拨

     

     

     

     

    07

    蓝牙拨打

     

     

     

     

    08

    快捷图标

    联系人1

    联系人2

    直接拨打

     

    09

    快捷键

    数字快捷键

     

     

     

    10

    SIM2

     

     

     

     

    11

    语音拨号

    语音命令

     

     

     

    12

    非默认语言

    ……

     

     

     

    13

    ……

     

     

     

     

     

    说明:发送短信和拨打电话都是一些非常基本的功能,都是非常常用的功能项,不少同学平时测试时可能就局限于几种入口,但实际我们仔细想想,其实可以有很多种方式,如果再预置一些不同的条件,比如充电,收听FMmp3之类的,再进行诸如此类的操作,同时再加上操作中的各种正常/非常正时间的冲突、干扰等,可能会延伸出几百种的测试情况,当然,也许我们实际测试中不会如此操作,但关键问题是:你都有考虑到这些情况吗?

     

    继续一个案例

    Eg3、来电处理方式

    来电处理方式

    序号

    分类

    操作

    01

    接听

    正常触屏接听

    02

    任意键接听

    03

    自动接听

    04

    蓝牙接听

    05

    耳机接听

    07

    不接听

    直接挂断

    08

    置之不理

    09

    静音操作

    10

    蓝牙拒接

    13

    其他操作

    低电量关机

    14

    掉电

    15

    插拔耳机、 充电器等

    16

    闹钟响铃、自动开关机时间到

    17

    回到待机界面

    18

    蓝牙耳机连接、断连

    19

    ……

     

    由上三个例子,我们可以看出测试的复杂性,测试的时间、人力比较有限,如何在不同版本采取不同的测试策略或者说用尽可能少的测试来尽可能最大化的去发现问题,这又是需要我们考虑的一个问题了。

    拓展一点,实际测试中,也许某个项目也就那么几个人测试,久而久之,思路僵化,如何拓展思路呢?或许,这个时候把把人提交的bug拿过来,在自己的项目上验证一遍其实也是一个很好的选择,学会借用别人的思想还是比较明智的。

     

     

  • 相关阅读:
    java反射注解妙用-获取所有接口说明
    npm设置和查看仓库源
    正则表达式-linux路径匹配
    在vue中使用echarts图表
    设计模式-简单工厂模式
    设计模式
    Redis实现世界杯排行榜功能(实战)
    开发十五、k3cloud单据的附件自动上传到钉钉的审批单中
    微盟与金蝶k3cloud、erp库存对接
    开发一、k3cloud内服务工单过滤在库批号
  • 原文地址:https://www.cnblogs.com/itest/p/2774976.html
Copyright © 2011-2022 走看看