美文网首页
测试介绍

测试介绍

作者: 杨小呆yyy | 来源:发表于2019-04-13 17:41 被阅读0次

    开发模型--瀑布模型
    优点:开发阶段,各个阶段比较清晰;强调早早期计划及需求调查;适合稳定需求的产品开发
    改良:每个阶段都可以融入小的迭代工作!
    开发快速原型模型:适合做小型产品
    实现一个基本原型,让用户对原型进行评价,逐步调整,使其满足用户最终需求
    优点:适合不能确定需求的软件
    缺点:不适合开发大型系统
    螺旋模型

    软件测试模型:v模型 w模型  h模型

    v模型:需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试

    1、单元测试:又称模块测试,针对单一的程序模块进行的测试
    2、集成测试:又叫组装测试,在单元测试的基础上,对所有模块进行测试
    3、系统测试:将整个软件看做一个整体来进行测试,包括功能、性能、兼容性
    4、验收测试:
        (1)内测版(alpha)内部交流版本,可能存在很多bug,不建议用户安装
        (2)公测版(beta)面向所有用户,通过用户的反馈再去修改细节
        (3)候选版(gamma)与正式软件相差无几

    v模型优缺点
    1、优点:包含了底层测试(单元测试)和高层测试(系统测试);清楚的标识了开发和测试的各个阶段;自上而下逐步求精,每个阶段分工明确,便于整体项目的把控
    2、缺点:自上而下的顺序导致了测试工作在编码工作之后,就导致错误不能及时的进行修改;实际工作中,需求经常变化,导致v模型步骤,反复执行,返工量很大,灵活度较低。
    改良:每个步骤都可以进行小的迭代工作。

    w模型
    开发流程:需求分析、概要设计、详细设计、编码、集成、实施、交付
    测试流程:验收/系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试
    优点:伴随着整个开发周期,需求和设计同样要测试;更早的介入测试,可以发现初期的缺陷,修复成本低;分阶段工作,方便项目整体管理
    缺点:开发和测试依然是线性的关系,需求的变更和调整依然不方便;如果没有文档,根本无法执行w模型;对于项目组成员的技术要求更高
    定义:开发一个v ,测试一个v组合起来的模型;w模型也叫双v模型
    总结:v模型适用于中小企业,w模型适用于中大型企业(因为人员要求高),h模型人员要求非常高,很少有公司使用。

    H模型

    软件测试分类

    一、按是否查看源代码:黑盒测试 白盒测试 灰盒测试

    黑盒测试:又称数据驱动测试,完全不考虑从内部结构和特性,只注重软件的功能需求(不管代码)

    白盒测试:把盒子打开研究里面的程序结构和源代码

    黑盒测试分类

    ️功能测试:逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试

    ️性能测试:时间性能、空间性能、一般性能、稳定性、负载测试、压力测试

    灰盒测试

    二、按是否运行分类:静态测试、动态测试

    三、其它测试:回归测试、冒烟测试、随机测试、验收测试

    随机测试:针对重要功能、新增加的功能、特殊情况、以前发现过重大bug的模块进行二次测试;也叫探索测试,可以结合回归测试进行。

    四、是否自动化:人工测试、自动测试

    五、按测试阶段划分:单元测试、集成测试、系统测试

    测试用例

    测什么  怎么测

    等价类划分法

    属于黑盒测试,它将不能穷举的测试过程进行分配,从而保证完整性和代表性;
    思考步骤:
        1、确定有效等价类和无效等价类
        2、有效等价类划分(题目条件,还要注意边界值/极值,中间再随意找个值)
        3、无效等价类划分(跟有效等价类相反,其它特殊情况(中文、英文、特殊符号、空格、空))
    注意:两个框要一个正确,一个错误,这样才能准确的判断;一定要根据需求来判断预期结果

    等价类细节:1、考虑输入长度 2、考虑输入类型  3、组成规则  4、是否为空  5、是否区分大小写  6、是否重复  7、是否去除空格

    边界值

    我们在测试过程中,一定要小心边界值(极值)。因为在程序中这些边界嘴容易出问题;
    具体测试用例书写思路,找到边界值和它两端的值,分别进行测试
    总结:边界值思想应该是选到边界和刚超过的值,来进行测试,也要根据实际情况来选择;边界值和等级类是相辅相成的关系,是配合使用的。

    案例:1-100整数加法、qq账号、电话号码、登陆界面

    因果图法

    因:输入条件
    果:输出条件、出结果
    适用于输入条件之间有相互制约 相互依赖的情况;
    因果图基本符号:1 恒等-有因就有果,没有因就没有果;2 非-有因没有果,没有因有果;3 或-条件有一个是真,结果就是真,条件都是假结果才是假;4  且(与)-条件都为真结果才是真,一个条件为假,结果就是假

    因果图中的约束条件:互斥 包含 屏蔽 唯一 要求

    因果图案例:交通一卡通充值

    判定表法:因果图只是一种辅助工具,通过分析得到判定表。根据因果图来制作判定表(因果图可以不画)
        1、条件桩:所有条件
        2、动作桩:所有结果
        3、条件项:针对条件桩的取值
        4、动作项:针对动作桩的取值
    书写步骤:
        1、列出所有条件和动作桩
        2、填写条件和动作桩之昂的项目
        3、简化判定表
    判定表法案例:好学生判断
    注意:如果出现"-"代表此选项不影响最终结果

    场景法
    主要用来测试业务流程:分为基本流(正确流程)备选流(错误流程)
    注意:还要补充一些异常情况
    在冒烟测试主要采取场景法来测试
    案例:QQ登陆,根据业务流程写用例(产品经理会提供出来)

    流程分析法
    适用于有先后顺序的测试;常用于业务流程、安装流程等等。每一个流程就是一条测试用例,它只是在测试整体流程是否正确,细节还需要使用等价类、边界值等方法进行完善。
    案例:使用ATM机取款,根据业务流程写用例(产品经理会提供出来)

    错误推测法
    凭着直觉和经验来设计测试用例,它是根据之前项目相关的bug数据总结来的

    正交排列表
        从全面试验中挑选出油代表性的点进行测试(均匀分散,整齐可比);高效率、快速、经济。
    案例:字符属性设置程序、114查询系统、
    正交表使用方法:
        1、根据控件和取值数选择一个合适的正交表
        2、列举取值并编号,生成取值表
        3、把取值表与选择的正交表进行映射
    混合正交表工具:allpairs
        在实际工作中,很多情况都是因素(控件个数)和水平(每个控件的可选)不同,我们在现成的正交表中找不到对应的表格,此时我们就需要使用混合正交表工具来生成混合正交表
    使用步骤:
        1、制作取值表(不需要编号,列出数据即可)
        2、复制表格中的数据放在一个新建的txt文本文档中,保存到allpairs文件夹中(例如:test2.txt)
        3、win+r再输入cmd进入控制台界面
        4、使用控制台代码进入allpairs文件夹中(例如:  e: 回车    cd 复制文件夹路径  回车)
        5、再输入allpairs.exe test2.txt>chenggong.txt    (test2.txt是我们刚新建的文件,chenggong.txt是我们最终生成出来的正交表文件)

    测试用例方法总结

    1、如果测试功能和流程,要使用场景法;
    2、如果需要输入数据的地方,我们要使用等价类划分法,要注意边界值法来做详细测试,(包括输入条件和输出条件的等价划分,将无限测试变为有限测试)
    3、如果有条件组合的情况,我们要使用因果图制作出判定表;
    4、配置类软件,组合比较多的,我们要使用正交表来科学的选择测试用例;
    5、如果没有达到覆盖标准,就要增加一些测试用例;
    6、依靠经验追加一些测试用例(错误推断法)

    测试用例的力度

    软件缺陷
    定义:缺陷就是软件的问题,最终表现为没有满足用户的需求

    哪些属于软件缺陷
    1、软件未达到规格说明书表名的功能
    2、软件出现了规格说明说指明不会出现的错误
    3、软件功能超出了规格说明书指明的范围
    4、软件未达到规格说明说虽未指明但应该达到的目标
    5、软件测试人员或用户觉得不好

    软件缺陷的表现形式
    1、功能、特性没有实现或部分实现
    2、设计不合理、功能不明确、逻辑不清楚或存在矛盾
    3、实际结果和期望结果不同
    4、没有达到规格说明书要求的性能指标
    5、运行出错、崩溃、中断、界面混乱
    6、数据不正确、精度不够、不完整或格式不统一
    7、用户不能接受的其它问题,如存取时间、界面不美观
    8、硬件或软件存在其它问题

    缺陷的根源、费用
    缺陷产生的原因:需求解释或者记录错误、用户需求定义错误、设计说明存在错误、编码说明 程序代码错误、硬件或软件系统上存在错误、其他 文档 或代码拼写错误
    软件缺陷根源:交流不充分、软件的复杂性、开发人员的错误、需求的改变、进度压力
    软件缺陷修复的费用:缺陷发现越早费用越少

    软件缺陷分类——缺陷状态:
    提交(submited)测试人员提交了一个缺陷给程序员;
    打开(open)待处理
    拒绝(rejected)
    程序员认为不是缺陷或重复  就可以修改状态为拒绝
    修复(resolved)
    程序员修复缺陷后提交的一个状态;
    关闭(closed)测试人员经过回归测试后 认为此缺陷已经解决 将其关闭;
    推迟(later)可以放在后续版本解决的问题,但是要详细写出修复的日期或版本

    软件缺陷严重程度的划分
    5-critical系统瘫痪、异常退出、死循环、严重的计算错误 
    4-veryhigh频繁死机 大部分功能不使用 
    3-high功能点未实现 不符合用户需求 导致数据丢失 
    2-medium影响一个相对独立功能、仅仅发生在特定条件上、与需求定义不一致、断断续续出问题 
    1-low 表面性错误,如错别字

    软件缺陷的优先级(优先修复顺序):
    5–导致系统几乎不可用
    4–影响系统,产生严重影响
    3–会制约开发和测试的进行 需要在发布之前修改
    2–不会延迟开发 会在以后修复
    1–时间和资源允许情况下修复

    软件缺陷的分类——bug分类:系统缺陷;数据缺陷;数据库缺陷;接口缺陷;功能缺陷;安全性缺陷;兼容性缺陷;性能错误;界面缺陷;建议

    缺陷报告注意事项:
    1、尽量保证缺陷可以重现
    2、简洁、准确、完整
    3、一个缺陷报告只写一个缺陷(不便于分配、不便于验证)

    缺陷报告书写规范
    1、标题简洁、提供缺陷的本质信息即可
    2、复现的步骤要详细,用数字编号
    3、实际结果要描述清楚复现后的结果
    4、列出期望结果
    5、提供附件
    6、提供严重性属性和其他公司需要填写的属性
    注意:要避免一些常见错误
        (1)避免使用情绪化语言和强调标点符号
        (2)避免使用模糊的词语
        (3)避免使用自认为幽默的语言,直接描述问题即可
        (4)避免提交不确定的缺陷

    缺陷处理流程:

    缺陷的跟踪:新提交的缺陷为“新建”状态,在确认有效之后改为“打开”状态,开发人员修改后变为“已修复”状态,此时测试人员需要回归测试,如果验证问题已解决,状态为“已解决”,如果问题依然存在,状态为“打开”;如果开发人员认为此缺陷可以延期修改,状态为“延期”;注意此时必须由项目相关人员讨论确认后,才可以延期,否则状态继续为“打开”

    缺陷密度:
    每千行代码的缺陷数:
    缺陷密度=1000*缺陷个数/代码行数

    缺陷数据分析

    常用的寻找缺陷的方法

    不同软件组织的缺陷管理过程

    SVN版本管理软件
    SVN:一个开源的版本管理软件;可架设在Apache上,最常用的客户端为TortoiseSVN(简称SVN)
    安装说明:
        1、安装 TortoiseSVN-1.9.7.27907-x64.msi
        2、安装 Languagepack_1.9.7.27907-x64-zh_CN.msi
        3、重启电脑
        4、设置中文 (找到你想要设置成公共文档的文件夹,右键点击后选择TortoiseSVN再选择setting按钮;选择中文即可)
    TSVN随时可以打开
    SVN的基本操作

    添加文件:找到随便一个受svn控制的文件夹,在里面放你的文件,然后在这个受控制的文件上右键,提交即可实现
    删除文件:右键选择文件,点击删除(是tsvn的删除按钮),必须返回上级文件夹右键-提交;
    改名字:文件—右键—tsvn的改名,然后回到上级文件夹右键—提交
    文件的移动:右键找到tsvn的“版本库浏览器”,随意拖拽文件的位置即可实现文件的移动效果;(注意:如果是在服务器的版本库浏览器设置,直接可以实现一个默认的提交,如果不是在服务器的版本浏览器设置,就必须回到上级目录点击提交才可以)
    更新至版本:必须是受svn控制的文件夹,右键—更新至版本—显示日志—找到想要的版本,点击确定即可;

    相关文章

      网友评论

          本文标题:测试介绍

          本文链接:https://www.haomeiwen.com/subject/orsrwqtx.html