51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3953|回复: 0
打印 上一主题 下一主题

[原创] 小白选手必看的软件测试基础

[复制链接]
  • TA的每日心情
    无聊
    昨天 09:34
  • 签到天数: 1052 天

    连续签到: 2 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2021-1-4 13:45:44 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
     1.1软件测试背景
      软件测试在软件生命周期中占据重要的地位,软件测试慢慢的独立发展成为一个行业,并且在迅猛发展。
      1.2软件缺陷与软件故障
      一,软件缺陷与软件故障案例
      美国迪斯尼公司的狮子王游戏软件BUG
      2.火星登陆事故
      3.跨世纪“千年虫”问题
      其他一些例子
      二,软件缺陷的定义
      1.软件未达到产品说明书的功能 《需求文档》
      2.软件出现了产品说明书指明不会出现的错误
      软件功能超出产品说明书指明范围
      软件未达到产品说明书虽未指出但应达到的目标
      软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好
      三、 软件缺陷的特征
      软件的特殊性决定了缺陷不易看到,即“看不到”;
      发现了缺陷,但不易找到问题发生的原因所在,即“看到但是抓不到”。
      面试题:1.测试发现bug 开发不认为是bug的时候你怎么办?
      1.测试人员在根据需求文档或者是规格说明书/原型图来进行匹配
      2.测试人员根据不同的测试环境来进行多测尝试来确认bug 并将bug的复现步骤进行记录
      3.如果开发仍旧认为不是bug 需要的测试主管来进行讨论 确认是否bug
      4.需要找产品经理和项目经理进行讨论是否bug
      5.如果认为是bug测试人员将bug进行记录并提交测试总结中
      软件缺陷从哪来?第一大原因就是软件产品规格说明书,很多情况下,说明书没有写,或写的不够全面,经常更改,或者开发小组没有很好的沟通,造成对说明书理解的不一致。第二大原因是软件设计,没有做设计或设计不好,经常变动等和产品规格说明书一样的问题,第三个原因才是编写代码和其它原因;前两个原因至少占了 80%以上。如图1-1所示

     通过大量的测试理论研究及测试实践经验的积累,典型的软件缺陷产生的原因被归纳为以下几种类型:
      (1)需求解释有错误;
      (2)用户需求定义错误;
      (3)需求记录错误;
      (4)设计说明有误;
      (5)编码说明有误;
      (6)程序代码有误;
      (7)数据输入有误;
      (8)测试错误;
      (9)问题修改不正确;
      不正确的结果是由于其他的缺陷而产生。
      2.1软件测试定义
      狭义:测试的定义:“程序测试是为了发现错误而执行程序的过程”。这个定义,被业界所认可,经常被引用。
      广义:为了更早地发现问题,所以将测试延伸到需求评审、设计审查活动中去,也就是将“软件质量保证”的部分活动归为测试活动。实际上,在软件开发实际操作中,常常将软件测试和质量保证——这两种努力(efforts)合并起来。延伸后的软件测试,被认为是一种软件测试的广义概念。
      软件测试的定义:软件测试是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程,其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
      2.2测试流程
      项目发布立项会的时候测试人员进行参与需求讨论并生成<需求文档》测试会在根据需求文档编写测试计划,然后uI会根据需求文档进行设计原型图,后台开发对数据库的设计,然后后台开发通过需求文档和原型图进行编码,同时测试人员进行编写测试用例,开发编码结束后测试对主要功能进行冒烟测试,如果冒烟测试执行通过,根据编写好的测试用例进行执行,发现bug后进行
      提交bug; 开发进行修改bug,开发修改后的bug进行回归测试上线后需要对项目的进行<测试总结>

    3.1 测试分类

      4.1黑盒,白盒和灰盒
      黑盒测试 :已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
      白盒测试 :已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
      灰盒测试,是介于白盒测试与黑盒测试之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

    最后,经典基础测试用例
      水杯

    电梯
      一、如果给你一台电梯,请问你如何测试它,分析如下
      1.功能:上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等;
      2.性能:速度、反应时间、关门时间等;
      3.压力:超载、尖锐物碰撞电梯壁等;
      4.安全:停电、报警装置、轿箱停靠位置、有人扒门时的情况等;
      5.可用性:按键高度、操作是否方便、舒适程度等;
      6.UI:美观程度、光滑程度、形状、质感等;
      7.稳定性:长时间运行情况等;
      8.兼容性:不同电压是否可工作、不同类型电话是否可安装等。
      其实在简单分析的过程中,发现许多东西根本测试不全,比如电话、灯光、材质、调度程序、可维修性等,当发现在一个用例中无法说清楚时,这些应该拆分开来分别测试。可以告诉主考官,你需要模块化地测试电话、灯光等。再有在一起的组装测试。
      二、下面是详细的测试点:
      需求测试: 查看电梯使用说明书、安全说明书等
      界面测试: 查看电梯外观
      功能测试
      1.测试电梯能否实现正常的上升和下降功能。
      2.电梯的按钮是否都可以使用。
      3.电梯门的打开,关闭是否正常。
      4.报警装置是否可用。
      5.与其他电梯之间是否协作良好。
      6.通风状况如何。
      7.突然停电时的情况。
      8.上升途中的响应。
      1)电梯本来在1楼,如果有人按18楼,那么电梯在上升到5楼的时候,有人按了10楼,这时候是否会在10楼先停下来;
      2)电梯下降到10层时显示满员,此时若8层有人等待电梯,是否在8层停。
      9.是否有手机信号。
      可靠性:
      1.门关上的一刹那出现障碍物。
      2.同时按关门和开门按钮。
      3.点击当前楼层号码。。
      4.多次点击同一楼层号码
      5.同时按上键和下键。
      易用性:
      电梯的按钮的设计符合一般人的习惯吗。
      用户文档:
      使用手册是否对电梯的用法、限制、使用条件等有详细的描述。
      压力测试
      1.看电梯的最大承重量,在负载过重时报警装置是否有提醒;
      2.在一定时间内不断让电梯上升、下降。
      稳定性测试:
      看电梯在最大负载下平稳运行的最长时间。



    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏1
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-28 02:02 , Processed in 0.064756 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表