测试重点_app测试流程和重点 - CSDN
精华内容
参与话题
  • 功能测试重点总结

    千次阅读 2016-04-17 19:56:50
    答:测试需求分析要了解测试的规模、复杂程度、可能的风险 流程理解:站在测试人员的角度,首先理解系统流程 功能理解:在流程理解的前提下理解功能,主要是系统包含那些功能,每个功能的期望值是什么 界面...

    第一章
    1、软件需求的三个层次是什么
    答:业务需求、用户需求、系统需求
    2、软件功能测试需求分析
    答:测试需求分析要了解测试的规模、复杂程度、可能的风险
    流程理解:站在测试人员的角度,首先理解系统流程
    功能理解:在流程理解的前提下理解功能,主要是系统包含那些功能,每个功能的期望值是什么
    界面美观性的需求理解:页面美观差会使用户的感官性差,时间长了出现厌倦情绪
    易用性的需求理解:使用户用起来顺手
    3、测试需求的特性
    答:
    制定的测试需求项必须是可核实的,即有可观察、可评测的结果
    测试需求应指明满足需求的正常前置条件,不满足需求时的出错条件
    测试需求不涉及具体的测试数据
    4、测试需求的评审形式
    答:相互评审、轮查、走查、小组评审、审查
    相互评审、交叉评审:同一项目组,不用工作内容的两人之间相互检查
    轮查:作者将需要评审的内容发给各个评审员,并收集反馈意见
    走查:作者将测试需求在现场向一组同事介绍,进行现场讨论,并收集大家意见
    小组评审:有计划和结构化的评审方式
    审查:最正式的评审方式
    5、黑盒测试方法
    答:等价类划分法、边界值分析法、因果图法、场景法
    第二章
    1、软件测试过程
    答:测试前期准备、测试计划制定、测试设计与开发、测试执行与缺陷追踪
    第三章
    1、手工测试和自动化测试的比较
    手工测试的缺点:①软件功能测试的重复性容易使人产生厌倦的心理,②准确性不高,③效率比较低
    手工测试不可替代的地方:①测试用例的设计,②界面和用户的体验测试,③正确性的检查
    手工测试的局限性:①现在软件复杂程度不断加深,手工测试力不从心,②无法执行回归测试
    自动化测试局限性:①可能降低效率,②技术问题,③缺乏测试经验,如果测试组织差,文档较少或不一致,自动化测试效果比较差,④不能代替手工
    手动测试与自动化测试适应的场合
    手工测试:测试很少执行的项目中
    软件运行仍然不稳定
    测试结果很容易通过人验证
    测试项目中涉及物理交互比较多
    自动测试:软件维护时使用回归测试
    执行压力测试
    配置和兼容性测试
    2、功能测试自动化要点
    答:何时开始使用自动化测试,如何开展自动化测试,自动化测试项目的流程,自动化测试方案的制定,自动化脚本的设计方法
    3、自动化脚本的设计方法有哪些
    答:线性脚本编写法、结构化脚本编写法、共享脚本编写法、数据驱动脚本编写法、关键字驱动脚本编写法
    4、软件自动化测试工具选型
    答:测试工具评估、测试工具试用、自动化测试工具培训
    第四章
    1、UFT工具简介
    答:UFT基本功能:创建测试、检验数据、增强测试、运行测试脚本、分析测试结果、维护测试
    2、UFT安装的环境部署
    答:Web应用程序、ActiveX控件
    第五章
    1、关键字视图与专家视图的区别
    答:关键字视图的每一步都在视图中记录成一行,专家视图必须定位到业务操作最终对象,并且每一句的结束,以其最终对象的业务行完毕为基准。
    第六章
    1、UFT自动化测试识别对象的步骤
    封装真实被测对象并转换成UFT对象到对象库
    对比对象库中的对象鉴别属性和运行时的真实被测对象的鉴别属性
    对比结果一致,说明对象成功匹配并可以对该真实被测对象进行后续操作,如果两者不一致,则报错,提示为对象无法识别
    2、RO与TO对象的含义与区别
    答:RO(run object运行对象):实行运行过程中捕获的对象,为动态
    TO( test object测试对象):对象存储库中的对象,为静态值

    GetToProperty用于取得测试对象的某一属性的值
    GetRoProterty用于取得运行时对象的某个属性的值
    3、共享对象库与本地对象库适用的场合
    答:共享对象库用于存储和维护测试对象的首选库类型
    默认情况下,测试对象存储在本地对象库中,这些测试对象会关联一个指定的操作,其他的操作都不能使用这些对象。
    共享对象库包含能够在多个操作中使用的测试对象,通过共享对象库与操作关联,可使该库中的测试对象用于该操作中。
    第七章
    1、关键字驱动测试主要关键字包括哪三类
    答:被操作对象(item)、操作(operation)、值(value)
    2、步骤生成器可以添加的内容
    答:测试对象方法和属性(test objects)
    实用程序方法和属性(utility objects)
    对函数库、VBScript函数和内部脚本函数的调用(Functions)
    3、使用步骤生成器定义新步骤的过程是什么
    (1)选择要添加的步骤的类型
    (2)指定参数值
    (3)返回值的设定
    (4)查看关键字视图中的步骤文档
    (5)在专家视图中查看生成的步骤
    (6)Insert another step 选项
    第八章
    1、标准检查点的插入步骤
    (1)选择insert|checkpoint|standard checkpoint,UFT窗口将最小化,且鼠标指针变为指向手
    (2)单机要检查的对象
    (3)从显示的对象树中选择检查的项目
    (4)单机OK按钮,打开checkpoint Properties对话框。
    (5)为检查点指定设置,
    (6)单机OK按钮关闭对话框,在关键字视图中,将为选定的对象添加一个检查点语句。
    2、什么是自定义检查点
    使用内部VBScript语句来验证运行值和期望值是否一致。
    3、怎么插入自定义检查点
    定义变量-赋值-if比较
    If XXX then
    Reporter.reporterevent micPass,”custom checkpoint”,”登录按钮存在”
    Else
    Reporter.reporterevent micFail,”custom checkpint”,”登录按钮不存在”
    End if
    4、UFT内嵌式检查点的问题
    检查点并不是非常灵活
    检查点不能在运行是创建
    检查点的改名与删除有局限性
    检查点使用一种二进制专用格式保存在对象存储库中,并且它们是不可见得
    已存在的检查点不能从一个Action复制到另一个Action中
    5、标准检查点、自定义检查点的优缺点

    6、检查点的类型都是有哪几种,都是在什么情况下使用
    标准检查点:检查应用程序或网页中对象的属性值。会检查个对象的状态,检查按钮是否激活,检查编辑字段的值,所以加载项环境中使用
    文本检查点:检查文本或字符串是否显示在应用程序或网页的适当位置。在所有环境中录制测试时都可以使用。
    位图检查点:检查位图格式的网页或应用程序区域,可以为所以受支持的测试环境创建位图检查点
    数据库检查点:检查由你的程序访问的数据库内容,所以环境
    可访问性检查点:依据“W3C Web内容可访问性规则”找到网页中特别需求注意的区域。可以项测试或组件中的每个页面添加
    XML检查点:检查XML文件中的XML文档的数据内容,或检查Page和Frame中的XML文档的数据内容。XML Checkpoint(From Application/From Resource)在Web环境中受支持,XML检查点(文件)在所以环境中支持
    第九章
    1、简述UFT参数化类型并分别对几种类型进行描述
    测试、操作或组件参数:使用从测试或组件中传递的值,或者来自测试中其他操作的值,Action与Action之间的传参
    数据表参数化:通过数据表参数化可以创建使用你所提供的数据多次运行的数据驱动测试。
    环境变量参数:让UFT从某个外部文件读取用于填写Web表单的所以值
    随机数字参数:可以插入随机数字作为测试或组件的值。
    2、数据驱动器的使用方法

    第十章
    列出对Action的几种操作并简述内容
    Call to New Action(调用新操作)
    Call to Copy of Action(调用副本操作)
    Call to Existing Action(调用现有操作)
    第十二章
    1、什么是专家视图?什么是关键字视图
    答:关键字试图是通过添加、修改执行步骤命令、操作值等参数由UFT自动生成脚本语句,
    专家试图显示的是整条命令语句
    2、关键字视图中主要分为那几列
    答:项(item)。操作(operation)、值(value)、文档(documentation)、注释(comment)
    3、使用关键字视图进行测试具有哪些优点和哪些缺点
    优点:测试脚本的创建、维护阶段更加有效,结构更加清晰;测试脚本的可读性更强、更易于修改
    缺点:缺乏更强大的和灵活的编码支持;当测试场景复杂时,脚本维护需要花费较长的时间;绝大多数复杂操作都无法在关键字试图中实现
    第十三章
    考察点:sub过程编写,select case,或if…else…嵌套。For循环、命名常量、变量的方法。
    例如:
    1、请编写一个function函数,计算从9到180之间所有奇数的和,并通过调用函数显示求和结果
    Function a
    For b = 9 To 180 Step 2 c=b+c
    Next
    msgbox c

    End Function
    Call a
    2、编写一个Sub过程,用来确定比赛成绩的等级,具体功能如下:先请求输入一个考试成绩,然后根据判断确定其等级并输出成绩和等级(大于等于90分的为优,大于等于60小于90的为良,小于60为不及格)
    Sub b

    c=inputbox ("请输入整数  ")
    If c<=100 and c>=90 Then
        msgbox "lianghao"
        ElseIf c<90 and c>=0 Then
    
        msgbox "buhao"
        else
        msgbox "qingshuruyouxiaoshuzi"
    End If
    

    End Sub
    b
    第十四章
    掌握直接描述性编程、Description描述性编程、ChildObject方法
    第十五章
    掌握 Check方法, CaptureBitMap方法的使用
    CaptureBitMap:将对特定对象所捕获的屏幕图像内容保存为.png或.bmp格式的图像

    展开全文
  • 作为一个测试新手,以下内容你不能不知道!!! 一、什么是测试用例?  测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求.(通俗的讲:就是...

    作为一个测试新手,以下内容你不能不知道!!!

    一、什么是测试用例?
         测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求.(通俗的讲:就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。)
    二、写测试用例有什么好处?
        1:理清思路,避免遗漏
            这里是我们认为最重要的一点,假如我们测试的项目大而复杂,我们可以把项目功能细分,根据每一个功能通过编写用例的方式来整理我们测试系统的思路,避免遗漏掉要测试的功能点。
        2:跟踪测试进展
            通过编写测试用例,执行测试用例,我们可以很清楚的知道我们的测试进度。
        3:历史参考
            在我们所做的项目中,也许会有很多功能是相同或相近的,我们对这类功能设计了测试用例,便于以后我们遇到类似功能的时候可以做参考依据。
        4:重复性
            我们测试一个系统不是一个人测一遍就算测完的,需要多人反复的进行测试,那么我们就需要测试用例来规范和指导我们的测试行为。
    三:测试用例的方法?

        这个内容我在之前的博文里面已经详细的介绍过了(需要了解可点击http://blog.csdn.net/sxl19960914/article/details/78850482,http://blog.csdn.net/sxl19960914/article/details/78879178)

    四:我们在什么时候可以设计测试用例?

           当根据客户的需求整理出项目需求分析文档时,我们就可以根据需求文档来编写测试用例了。但是,一般我们(国内大多小公司)项目需求文档都非常“简陋”,所以,很难根据需求文档设计测试用例。 我们只有等到项目开发人员把项目开发出来,给我们系统文档、部署环境、数据库结构(如果系统牵涉到数据库的话),我们根绝这些文档来设计测试用例。

    五:测试用例的评审与更新?

         我们设计的测试用例设计完成之后,是否完整?是否符合系统?符合客户要求?对用例做一个评审是必不可少。关于评审的方式,不同的公司有不同的流程。我们编写的测试用例也不是经过评审之后就不变了,随着需求的变更、功能的改进,测试用例当然也需要更新和变动。

    六:什么情况下不适合写测试用例

      1: 文件时间
       如果一个功能我很快就测试完了,而且只需要测试一遍,但我们设计测试用例时却比较麻烦,花时间也长。这个时候就没必要编写测试用例了。
      2: 需求变动大且频繁
       需求的功能变动非常频繁,而且变动很大,之前编写的测试用例根本没法使用,必须要重新编写,这个时候也没必要去设计测试用例了。

    七:测试用例的格式与要素

           一个测试用例应该包括:编号,标题,测试场景,测试步骤,预期结果。当然还可加入一些它选项,如:优先级、测试阶段...

        下面是一个测试用例的例子:


    作为测试人员,凡是不符合需求文档的都需要当问题点提出。

    展开全文
  • 软件测试重点

    千次阅读 2018-07-05 11:09:35
    课本为《软件测试》第2版 佟伟光主编 人民邮电出版社1...(3) 类簇测试:类簇也叫子系统,由若干个类所组成,类簇测试重点测试一组协同操作类之间的相互作用。(4) 系统测试:系统测试检验所有类和整个软件...

    课本为《软件测试》第2版 佟伟光主编   人民邮电出版社

    1.   面向对象软件测试的不同层次P178

    (1)    方法测试:方法测试是指对类中的各个方法进行单独的测试。

    (2)    类测试:类测试的重点是类内方法间的交互和其对象的各个状态。

    (3)    类簇测试:类簇也叫子系统,由若干个类所组成,类簇测试的重点是测试一组协同操作类之间的相互作用。

    (4)    系统测试:系统测试检验所有类和整个软件系统是否符合需求。

    2.   面向对象程序主要具有封装性、继承性、多态性等几大特征。P176

    3.   报告软件缺陷的基本原则P135

    (1)   尽快报告软件缺陷:软件缺陷发现得越早,留下修复的时间就越多。

    (2)   有效地描述软件缺陷:一个好的描述需要使用简单、准确、专业的语言来抓住软件缺陷的本质。

    (3)   在报告软件缺陷时不做任何评价:软件缺陷报告中应不带有倾向性以及个人观点。

    (4)   补充和完善软件缺陷报告:优秀的测试人员发现并随时记录许多软件缺陷,还应继续监视其修复的全过程。

    4.    一个最简单的软件缺陷生命周期为:打开修复关闭P131

    5.   按照一般的定义,只要符合下面5个规则中的一个,就叫做软件缺陷。 P125

    (1)   软件未达到软件规格说明书中规定的功能;

    (2)   软件超出软件规格说明书中指明的范围;

    (3)   软件未达到软件规格说明书中指出的应达到的目标;

    (4)   软件运行出现错误;

    (5)   软件测试人员认为软件难于理解,不易使用,运行速度慢,或者最终用户认为软件使用效果不好。

    6.   α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试;P95

    β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并要求用户报告异常情况,提出批评意见。

     所以,一些软件开发公司把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试,而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。

    回归测试是指软件系统被修改或扩充后重新进行的测试。P96

    回归测试一般采用黑盒测试技术来测试软件的高级需求,而无须考虑软件的实现细节,也可能采用一些非功能测试来检查系统的增强或扩展是否影响了系统的性能特性,以及与其他系统间的互操作性和兼容性问题。

    设计和引入回归测试数据的重要原则是,应保证数据中可能影响测试的因素与未经修改扩充的原软件上进行测试时的那些因素尽可能一致。

    7.   集成测试实施方案P83

    非增式集成测试、增量式集成测试和其他(三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试)

    (1)    非增式测试方法

    概括来说,非增式测试方法是采用一步到位的方法来进行测试,即对所有模块进行个别的单元测试后,按程序结构图将各模块连接起来,把连接后的程序当做一个整体进行测试。图4-4给出的是采用这种非增式的集成测试方法的一个经典例子

    (2)    增式测试方法

    自顶向下增式测试:可以有深度优先和广度优先两种集成策略。

    自底向上增式测试:

    8.   在进行单元测试时,需设置若干辅助测试模块。辅助模块有两种:P78

    (1)    驱动模块,用以模拟被测试模块的上级模块。 驱动模块在单元测试中,接受测试数据,把相关的数据传送给被测模块,启动被测模块,并打印出相应的结果。

    (2)    被调用模拟子模块,用以模拟被测模块工作过程中所调用的模块。被调用模拟子模块由被测模块调用,它们一般只进行很少的数据处理,以便于检验被测模块与其下级模块的接口。

    9.   白盒测试方法又可分为静态测试动态测试。其区别为:P38

    (1)    静态测试是一种不通过执行程序而进行测试的技术,其关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。它瞄准的是纠正软件系统在描述、表示和规格上的错误,是任何进一步测试的前提。

    (2)    动态测试需要软件的执行,当软件系统在模拟的或真实的环境中执行之前、之中和之后,对软件系统行为的分析是动态测试的主要特点。动态测试主要验证一个系统在检查状态下是正确还是不正确。动态测试技术主要包括程序插桩、逻辑覆盖和基本路径测试。

    10.软件测试的定义P11

    软件测试就是为了发现错误而执行程序的过程。(软件测试是一个找错的过程,测试只能找出程序中的错误,而不能证明程序无错。软件测试要求以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷,以保证软件的质量。)

     

     


    展开全文
  • 测试知识点

    千次阅读 2019-03-22 10:54:39
    你所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用 答:有黑盒和白盒两种测试种类,黑盒有等价类划分法,边界分析法,因果图法和错误猜测法。白盒有逻辑覆盖法,...

    你所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

    答:有黑盒和白盒两种测试种类,黑盒有等价类划分法,边界分析法,因果图法和错误猜测法。白盒有逻辑覆盖法,循环测试路径选择,基本路径测试。
    例子:在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则,首先利用等价划分法,可以一个或多个结果是OK的测试用例,然后确认多个NG的测试用例,然后利用边界值分析法,可以对结果分别是OK和NG的测试用例进行扩展和补充。

    你认为做好测试用例设计工作的关键是什么?

    答:测试用例设计工作的关键是对可行的和不可行的都要考虑。
    1、输入
    2、详细的操作步骤
    3、预期输出
    4、实际输出

    您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?

    答:性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能,性能测试常常需要和强度测试结合起来,并常常要求同时进行软件和硬件的检测。

    性能测试主要的关注对象是响应时间,吞吐量,占用内存大小(辅助存储区),处理精度等。

    在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    答:检测时间,系统环境,硬件环境,严重程度,程式版本,确认人,功能模板,问题描述,详细操作步骤,是否会重现。
    测试时间、环境、严重程度、影响版本、确认人、功能模块、问题描述、详细步骤、是否稳定复线、个人分析、备注
    问题描述和详细操作步骤要尽可能详细。Bug应该尽量用书面语,对于严重程度比较高的缺陷要在相同环境下测试一遍。
    在C\S模式下,如果条件满足可以使用替换法来确认是client端的问题还是server端的问题。

    你对测试最大的兴趣在哪里?为什么?

    答:最大的兴趣就是具有挑战性。
    因为我并不知道哪里会出现bug,在找到一个bug后会很高兴。并且测试需要很强的耐心和细心。我可以很容易的找到一些细节问题。

    测试活动中,如果发现需要文档不完善或者不准确,怎么处理?

    答:要及时的与项目经理进行沟通协调。要在邮件中详细的把不完善不准确的地方描述出来,并提出自己的意见

    你认为做好测试计划工作的关键是什么?

    答:首先,要有一个明确的目标,详细的阅读需求文档说明
    其次,要对整个测试人员、测试时间、测试进度进行一个预估,并预先进行管理
    最后,要对整个测试流程设定一个规范,所有测试人员都按着规范做事,不能随心所欲的测试。

    你觉得软件测试通过的标准应该是什么样的?

    答:测试用例完全执行,测试用例覆盖到所有的测试点,并且缺陷的密度达到客户的需求

    软件测试的文档测试应当贯穿于软件生命周期的全过程,其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些?

    答:用户安装文档、用户配置文档、用户使用手册、联机指导模板示例用户许可协议等。

    简述软件系统中用户文档的测试要点?

    完整性:用户文档中功能的描述要完整的。不能让用户产生疑问。
    一致性:用户文档中的功能描述要与实际软件中的功能一致。不能描述过盛。
    **易使用性:**用户文档描述的内容要方便用户阅读并且能够让用户很清楚的知道如何操作。
    **图表:**有的时候用图表描述会很明了。
    什么是系统瓶颈?
    系统瓶颈就是软件在一定的并发量、访问量下无法达到用户的需求。
    比如说用户需要在10s内完成一个访问,但是每一次都要12s才能完成,这个就是性能瓶颈,有可能是程序本身的问题,也有可能和操作系统、软件相关。

    没有产品说明书和需求文档地情况下能够进行黑盒测试吗?

    可以。
    这个情况下我们就要进行探索性测试,把软件当成用户需求,一步步进行测试。凭借经验判断功能正确与否,有的时候还可以与项目经理、开发人员一起进行交流沟通,从而进行更好的测试

    完全测试程序是可能的吗?

    不可能
    测试人员对程序进行测试,只能找出程序中的bug,但是并不能保证程序是没有bug的
    完全的测试要花费很多的人力财力,并且测试的数据量过大,很浪费时间。测试的结果还很多,有的都是类似的,没有必要进行相同的测试。所以完全测试是不可能的。

    软件测试的风险主要体现在哪里?

    主要体现在没法完全测试。有些问题可能隐藏在没有测到的地方。这样子就被忽略了。客户使用的时候并不熟悉软件是如何操作的。可能有的时候会误点点出问题。这样子的话我们就要承担很大的风险了。

    你能不能说下你的3-5年的职业规划?

    首先,要巩固自己的测试基础知识,在基本知识扎实的情况下提高理解需求文档地能力。
    其次,学习自动化测试工具,并将它运用到测试中。
    然后,在测试技术达到一定程度后,要学会如何带领一个测试团队
    最后,争取在最快的时间内达到测试经理的水平

    一个缺陷测试报告的组成?

    环境(软硬)、模块、人(监督人、开发人)、版本、bug相关(编号、标题、优先级、输入、输出、复现步骤)
    缺陷编号、缺陷标题、缺陷描述、缺陷的优先级、缺陷的重要程度、缺陷所述的模块、缺陷所属的版本、缺陷所属的开发人员、输入数据、输出结果、缺陷分析等。

    软件的评审一般由哪些人员参加?其目的是什么?

    参加人员:客户、项目经理、开发人员、测试人员
    目的:查看软件在未正式投入运行前是否还存在问题。对于不同软硬件平台能否正常运行,是否有与客户理解不一致的地方,同时可以对一些可以改进的地方再多加改进。

    **什么是兼容性测试?

    兼容性测试是检查软件在不同软件平台,硬件平台上是否可以正常运行的测试。主要查看软件在不同操作系统、浏览器、数据库中是否运行正常。

    **?当测试过程发生错误时,有哪几种解决办法?

    答:
    1)跳转到别的测试过程
    2)调用一个能够清除错误的过程
    3)退出过程,启用另一个
    退出过程和应用程序,重新启动Windows,在失败的地方重新开始测试

    怎样做好测试计划?

    明确目标、计划、测试点(重难点)、安排(时间、人)、标准、测试技术
    答:
    1)理解系统。从整个系统的高度了解被测系统必须满足的功能和非功能性需求。利用涉及整个系统的文档,形成对系统的整体了解。
    2)及早介入。为了深入了解项目,测试人员应该在系统的开始阶段介入,可以增加对客户需求,客户问题,潜在风险以及最重要的功能方面的理解
    3)测试期望。程序员的期望是什么?客户的期望是什么?销售对测试的期望又是什么?测试目标必须是绝对的,以免说不清是否达到目标。
    4)吸取教训。把以前工作中学习到的经验教训运用过来,对确定测试策略很有作用。
    5)工作量的大小。完成测试需要多少工作量?需要多少人员?
    6)技术选择。系统会采取什么技术?系统会采用什么架构?这些信息有助于确定测试策略和测试工具。
    7)时间表。系统开发和测试分配的时间有多长?截止日期是什么时候?

    测试用例如何设计的?

    PRD、开发技术文档、分模块细致、脑图、详细、测试方法
    答:在测试用例的设计之前首先要仔细阅读开发的详细设计文档,充分了解产品的详细功能,不清楚的地方与开发人员进行沟通,搞懂每个功能,尽量详细到输入框、按钮等小功能,功能点清楚之后按照功能模块分类进行用例编写。在具体的用例设计中会运用到等价类边界值等黑盒测试方法

    ** 什么是bug?

    答:软件的bug指的是软件中(包括程序和文档)不符合用户需求的问题。
    常见的软件bug分为以下三类:
    没有实现的功能
    完成了用户需求的功能,但是运行时会出现一些功能或性能上的问题
    实现了用户不需求的多余功能

    ***请问功能测试和性能测试的区别是什么?

    答:
    1)测试目的:
    功能测试:检测实际软件的功能是否符合用户需求,测功能是不是全部实现,某个实现是不是有BUG。主要为了发现以下几类错误:
    A、是否有不正确或遗漏的功能?
    B、功能实现是否满足用户需求和系统设计的隐藏需求?
    C、能否正确接收输入?能否正确输出结果?

    性能测试:验证软件质量的三个质量特性,可靠性,正确性和效率。主要是测试产品的健壮性
    2)测试方式:
    功能测试按照系用例,按照系统需求说明书和测试用例,对产品的功能一步步进行测试。找出产品功能是否全部实现
    性能测试:一般都使用性能工具对产品的健壮性进行评估。通过创建场景和虚拟用户模拟真实环境,进行压力测试和负载测试

    **什么是兼容性测试?兼容性测试侧重哪些方面?

    主要检验的是软件的可移植性,检查软件在不同的硬件平台软件平台上是否可以正常的运行。
    细分会有:平台的兼容,网络兼容,数据库兼容,数据格式的兼容等。

    白盒测试和黑盒测试的区别?

    黑盒测试是功能性测试,一般采用穷举输入测试,不会考虑内部的逻辑和实现。包括兼容性测试,安全性测试,压力测试,性能测试
    白盒测试是结构测试,一般是穷举路径测试,检测内部逻辑驱动结构。 – 语句覆盖 – 判定覆盖 – 条件覆盖 – 判定-条件覆盖 – 条件组合覆盖 – 路径覆盖。

    静态测试和动态测试有什么区别?

    静态测试是指不运行程序本身,仅通过分析程序文档结构,软件执行过程,检测程序的正确性,主要有变量,借口,递归等。
    动态方法是指运行程序,检查运行结果与预期结果对比差异,并分析抗压性,健壮性等,这种测试包括三部分:构造测试实例,执行程序,分析程序输出结果。
    区别一:静态测试是用于预防的,动态测试是用于矫正
    区别二:多次的静态测试比动态测试要效率和效益高
    区别三:静态测试综合测试程序代码
    区别四:在相当短的时间里,静态测试的覆盖度能达到100%,而动态测试经常是只能达到50%左右,原因动态测试发现的bug大部分只是在测试实际执行的那部分代码
    区别五:动态测试比静态测试更花时间
    区别六:静态测试比动态测试更能发现 bug
    区别七:静态测试的执行可以在程序编码编译前,动态测试只能在编译后才能执行
    区别八:静态测试能发现动态测试所不能发现的一些错误,比如:”Syntax error,code that hard to maintain,code that hard to test,code that does not confirm to coding standard, and ANSI violations”

    ***什么是loadrunner

    是一个自动化负载测试工具,通过模拟上千万用户实施并发负载及实时性能检测,他能预测系统行为并评估系统性能,原理是通过代理方式获得客户端与服务器端的数据流。分为用户动作设计,场景设计,测试数据设计三个部分。

    Beta测试与Alpha测试有什么区别?

    Beta是用户实际使用的测试,没有开发者在场,Alpha测试是公司内部测试,有开发者监控。

    工作版本的定义

    一般一个软件在不断的升级优化中会产生不同的版本号,每一次变化较大或有重大特点出现的时候,会升级版本号第一个号,比如1.x,2.x,版本发布后一般会有bug修复的版本,这时候就是1.x,2.x等。

    ****什么是桩模块?什么是驱动模块?

    集成测试前要为被测模块编辑一些模拟其下级功能的子模块的替身,以代替被测模块的借口,接受或者传递数据,这些假模块被称为桩模块。
    驱动模块一般为主程序,它接收测试数据并将这些数据传递到被测试模块。

    ***什么是扇入和扇出?

    扇入是指该模块被调用的次数,扇入大,说明该模块的复用性好。
    扇出是指该模块调用其他模块的个数,扇出大,说明该模块的业务逻辑复杂

    你认为做好测试工作的的关键是什么?

    目的,管理,规范。

    1. 明确测试的目标,增强测试计划的实用性
    2. 坚持“5W”规则,明确内容与过程
    3. 采用评审和更新机制,保证测试计划满足实际需求
    4. 分别创建测试计划与测试详细规格、测试用例

    软件的安全性应该从哪几个方面去测试?

    1. 用户认证机制,
    2. 加密机制
    3. 安全防护策略,安全日志等,
    4. 数据备份和恢复
    5. 防病毒系统

    单元测试,集成测试,系统测试的区别?

    测试方法不同
    单元测试属于白盒测试,集成测试属于灰盒测试,系统测试属于黑盒测试。
    考察范围测试重点不同
    单元测试注重单元内部的数据结构,逻辑控制,异常处理。
    集成测试注重模块之间的接口及接口之间的数据传递,
    系统测试注重满足需求。
    基准不同
    单元测试主要的逻辑覆盖,集成测试主要是接口覆盖,系统测试是测试用例对需求规格的覆盖率。

    测试与调试的区别

    目的不同–测试的任务是发现程序中的缺陷;调试的任务是定位并且解决程序中的问题
    参与角色不同–测试主要是由测试人员和开发人员来执行,黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。调试由开发人员完成
    执行的阶段不同–测试贯穿整个软件开发生命周期,调试一般在开发阶段

    测试人员应该具备的素质

    逆向思维。相当于开发盖房子,测试拆房子
    案例:手机中有两条通话记录,进行删除。删除为0后,继续删除。
    发散性思维:探求多项答案
    案例:测试一台自动售票机。正向,逆向,边界,压力,性能,耗电量,断电,外观,没零钱……
    对测试感兴趣
    性格特征,有好奇心,成就感,敏感,不浮躁 ,善于怀疑,有批判性思维

    能力,快速学习能力,沟通能力,文字能力,开发能力
    责任感和承受压力的能力

    责任感:测试往往是产品的最后一个检验者;测试的工作成效很难衡量,测试用例执行、bug数目的多少都无法说明产品是否能够交给用户使用。所以,责任感是最重要的测试必备素质之一。
    压力:来自开发人员、用户、上级、自己的压力。

    一个合格的bug描述应当包括:

    发现问题的版本
    开发人员需要知道出现问题的版本,才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量
    问题出现的环境
    环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器版本,客户机操作系统等,如果是app项目,需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
    错误重现的步骤
    描述问题重现的最短步骤。
    预期行为的描述
    要让开发人员指导怎么样才是正确的,尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障,能写明需求的来源是最好的。
    错误行为的描述
    描述错误的现象。crash等可以上传log,UI问题可以有截图。
    其他
    某些公司会有一些其他的要求,例如故障的分类:功能故障,界面故障,兼容性故障等。有些有优先级的分类,严重影响测试需要开发人员优先修改的,可以设置优先级为高。
    注意:不要把多个bug放到一起。在无法确认是同一段代码造成的故障时,不要将bug放在一起提交。

    产生争执怎么办(处理人际关系)

    遇到争执不要怕,记住批判性思维:清楚–准确、切题–深刻,有意义,有逻辑性–公正、全面
    先检查自身,是否bug描述不清楚 沟通
    如果能正确地、高质量地录入一个Bug,那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的时候,这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后, 好像还有很多关于Bug的信息没有表达出来,或者很难用书面语言表达出来时,就应该在提交Bug后,马上找相关的程序员解释刚才录入的Bug,确保程序员明白Bug描述的意思,而不要等待开发人员找自己了解更多的信息。
    站在用户角度考虑问题。应该让开发人员了解到Bug对用户可能造成的困扰,这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时,可以问一句:如果你是用户,你可以接受么?
    BUG定级要有理有据
    BUG定级时,不仅要参考BUG级别,还要考虑BUG是否会影响到流程,往往用户的BUG级别和我们的是有区别的,需站在用户的角度考虑定位级别。
    提高自身的技术和业务水平。不光要提出问题, 最好也能提出解决方案或思路,这样才能更让人信服。
    开发人员不接受时,不要争吵
    可能你已经经过了多轮沟通,但是开发人员仍然拒不接受。此时
    可以发起Bug评审。

    Bug评审

    要注意的问题:缺陷的评审应该包括以下两个层面,决定如何处理Bug和分析缺陷产生的原因,找出预防的对策
    解释:
    决定如何处理Bug。
    这一方面评审需要项目组各个方面的代表参加,通常不可缺少的是测试代表、开发代表、产品代表。
    (1)测试代表主要从Bug的具体表现、严重程度等方面提供信息,并提出自己对Bug的处理意见。需要注意的是,测试人员不应该一味地要求对Bug进行修改,因为修改可能带来回归的风险,同时带来的是回归测试的工作量,如果时间比较紧迫,修改后剩余的时间若不足以做一次有效的回归测试,可能不修改是个明智的选择。
    (2)开发代表主要从修改缺陷的难度和风险出发,考虑缺陷修改需要付出的代价,以及可能影响的范围、可能引发的风险等,如果决定要修改,还要讨论出修改的初步方案。
    (3)产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。 这在微软的做法叫“Bug三方讨论会”,参加者一般是测试人员、开发人员和项目经理。
    分析缺陷产生的原因,找出预防的对策。 (原因、预防)
    缺陷评审还应该包括原因分析,找出Bug出现的原因,尤其是那些重复 出现的Bug。应该找出出现错误的根源,并且制定出相应的预防措施,确保同类型的Bug不再出现。 例如:有些 Bug出现的原因不是简单的“引用为空”之类,而是开发人员的编码不规范或者编程习惯不好而导致,所以必须建立起正确的编程方式才能预防这些错误的出现,否则只是在玩无聊地重复发现相同的Bug的游戏。

    禅道是什么

    禅道项目管理软件集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款功能完备的项目管理软件,完美地覆盖了项目管理的核心流程,是第一款国产的开源项目管理软件。
    禅道项目管理软件的主要管理思想是基于敏捷项目管理方式——Scrum。
    禅道在遵循其管理方式基础上,又融入了国内研发现状的很多需求, 比如bug管理,测试用例管理,发布管理,文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具,更是一款完备的项目管理软件。基于scrum,又不局限于scrum。
    禅道还首次创造性的将产品、项目、测试这三者的概念明确分开,产品人员、开发团队、测试人员,这三者分立,互相配合,又互相制约,通过需求、任务、bug来进行交相互动,最终通过项目拿到合格的产品

    软件的生命周期

    软件的生命周期应该为:
    问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段
    但其与瀑布型生命周期模型及其衍生模型(比如V模型,W模型)相符合,而与迭代为基本特征的生命周期模型是不符合的。
    随着新的面向对象的设计方法和技术的成熟,新的情况应当是把迭代加入到阶段当中。

    软件测试的生命周期

    软件项目测试计划,测试需求分析,测试用例设计,测试用例执行,BUG提交Bug评审五个阶段,并行与软件的生命周期。

    衡量软件质量的标准

    我们需要关注以下几点:
    正确性:实现的功能达到设计规范并满足用户需求的程度
    可靠性:在规定的时间和条件下,维持其性能水准的程度
    易用性:用户掌握软件操作所要付出的时间及努力程度
    效率:软件执行某项功能所需的计算机资源和时间的有效程度
    可维护性:当环境改变或者软件发生错误时,执行修改或者修复所作的努力地程度
    可移植性:从一个系统/环境移到另一个系统/环境的容易程度
    负面反馈/所有反馈
    客户报告的Bug/所有发现的Bug
    修复Bug成本/开发总成本
    需求变化量/需求总量
    具体的要求如下:
    功能性的质量指标
    功能的正确性:系统功能和用户的实际需求、已定义的产品规范一致
    功能的准确性:系统产生的结果在精度允许的误差范围内
    功能的完整性:所有功能及其定义清楚、可用
    可用性的质量指标
    可操作性:容易使用和操作,包括理解用户界面、适应一些特殊用户的可选项等
    通用性:数据显示、网络通信接口和用户界面等都遵守已有的软件标准
    一致性:在软件开发整个生命周期内建立和使用相同的标准,保证全局变量、数据类型、出错处理的命名和使用一致
    可靠性的质量指标
    自我恢复能力:当系统的某个功能失效发生时,系统在当前环境下能实现故障自动转移,重新自动配置、继续执行的能力,软件系统具有自我检测、容错、备份等机制,尽量做到独立于硬件的编码、硬件设备之间的通信协议一致等。
    健壮性:各种恶劣环境(大数据量、大用户量)下系统能正常工作。
    分布性:软件系统的某些子功能或子系统被定位于不同的处理主机、存储设备。
    性能的质量指标
    有效性:系统在通信、处理、存储等方面占有很少资源或者对所使用的资源进行了优化。
    完整性:系统具有良好的安全管理,能防止不安全存取系统、防止数据丢失病毒入侵等。
    易存取性:对系统的存取权限设置清楚,存取操作方便,存取操作有记录。
    可维护性的质量指标
    模块化:指讲一个复杂的软件系统分解为分别命名并具备最小耦合性、很强凝聚性、结构化的组件。
    灵活性:容易为系统增加一个新功能或者新的数据而不需要进行大量的代码修改或者设计修改。
    可测试性:测试软件组件或者集成产品时查找缺陷的简易程度。
    可追溯性:对一个特殊需求容易找出相应的代码,反之,也可以根据代码找出特定的需求。
    兼容性:软件、硬件、通信系统之间协调及兼容其他系统的能力。
    可解释性:相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当,容易理解和定位。
    可移植性质量指标
    适应性:系统不依赖于环境,即系统不做修改或作很少的修改即可运行在其他环境下。
    易安装性:与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
    可重用性:一个软件组件除了在最初开发的系统之外应用于其他系统的能力。
    互操作性:软件系统与其他系统交换数据和服务的难易程度。
    可替换性:与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性

    展开全文
  • 测试需要关注的重点

    千次阅读 2017-04-05 16:35:41
    1,测试了什么,怎么测试,观察到了什么 2,哪些内容打算测试还没有测试 3,还有哪些内容不打算测试 如何把测试做的更好 1,测试的成本和风险有哪些 2,产品的可测试性怎么样 3,测试需要哪些帮助 4,测试对...
  •  是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试,测试重点是系统的模块,包括子程序的正确性验证等。  集成测试  也叫组装测试...
  • 单元测试与集成测试的区别: 单元测试与集成测试相比,测试对象有所区别: ►集成测试的被测对象是单元间的组合,这里,不同模块往往是分配给不同的人员开发。集成测试主要关注不同单元模块之间的接口和配合 ...
  • 测试优先级 与 重点测试的讨论

    千次阅读 2005-05-31 17:55:00
    高优先级 - 必须测试 中优先级 - 应该测试,只有在测试完所有 高优先级 项后才进行测试 低优先级 - 可能会测试,但只有在测试完所有 高优先级 和 低优先级 项后才进行测试 重点测试的部分:同一个优先级中需要重点...
  • 重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点重点:gamebench为了防止国人换马甲,升级后的gamebench应该是绑定了硬件设备号和用户账号,只要发现...
  • 测试人员必知必会的数据库知识01

    万次阅读 2012-11-05 19:57:49
    我们介绍的数据库知识是针对测试人员的,所以我们的重点在SQL的增删改查语句,其中查询使我们的重点中的重点。这部分我会用实例来讲解介绍,最后给大家一些关于SQL查询的习题。 这部分先介绍SQL Server 2005,我们...
  • 测试策略模板

    万次阅读 2018-03-29 19:08:45
    1.测试策略测试策略提供了对测试对象进行测试的推荐方法。对于每种测试,都应提供测试说明,并解释其实施的原因。制定测试策略时所考虑的主要事项有:将要使用的技术以及判断测试何时完成的标准。1.1功能测试测试...
  • 软件测试体系介绍

    千次阅读 多人点赞 2020-01-02 09:12:46
    软件测试体系,我经过两个月时间的研讨,重新阅读了“软件测试实战”、“测试架构师修炼之道”、“软件测试介绍”等测试类书籍,并结合自己的项目实践,汇总成测试体系。后续还会对整个体系持续完善,主要的方向有...
  • 面试题——Web测试重点

    千次阅读 2018-11-17 17:04:18
    功能测试:链接测试、表单测试、Cookies测试、设计语言测试、数据库测试、 性能测试:连接速度测试、负载测试、压力测试 可用性测试:导航测试、图形测试、内容测试、整体界面测试 客户端兼容性测试:操作系统...
  • 零基础学软件测试V2.0

    万次阅读 多人点赞 2015-01-09 13:15:20
    关于本教程  本系列是在之前的基础上进行了修改更新,原来的内容显得过于简单,但都是重点,这次对于过于简单...本教程的重点是黑盒测试基础知识和数据库部分的内容,其他部分也会介绍一些。 学习方法 软件测试工程
  • 在开发过程中,都要经过由小到大、由内至外、循序渐进测试过程,根据不同的测试阶段可以分为:单元测试、集成测试、确认测试、系统测试、验收测试...测试重点: (1)系统的模块,子程序的正确性验证等 (2)白盒测试
  • 测试方案和测试策略的区别

    万次阅读 2019-06-04 12:56:48
    测试方案:侧重测试的方法,测试环境的...测试计划:制定项目测试过程中的测试重点,各个阶段的任务分配以及时间进度安排,并提出对各项任务的评估,风险分析,可以包括测试策略。 测试用例:根据测试计划,制定...
  • 小程序测试注意要点

    千次阅读 2019-05-28 14:35:15
    转载一篇感觉写的很不错的小程序测试方案
  • 测试人员的SQL语言 系列

    万次阅读 多人点赞 2013-03-15 15:36:51
    测试过程中经常会涉及到数据库的数据检查,那么掌握SQL语言对测试来讲是必不可少的了,所以在此开本系列。本系列主要是讲解数据库的增删改查功能,我们的重点放在了查询上。 数据库基础 对数据库的操作 ...
  • web测试和app测试重点

    万次阅读 多人点赞 2017-07-31 13:23:42
    WEB测试重点 1.功能测试:所实现的功能是否和需求一致; 2.界面测试:界面是否美观,文字内容是否正确; 3.链接测试:打开链接速度是否合理;是否链接到正确的页面;是否有空白页面; 4.性能测试:系统能支持多少...
  • 测试方案模板

    万次阅读 2019-07-16 09:52:43
    (iwebshop项目)测试方案 (仅供参考) 文档版本控制 文档版本号 日期 作者 审核人 说明 V1.0 2017/11/24 陈.. ...
1 2 3 4 5 ... 20
收藏数 353,190
精华内容 141,276
关键字:

测试重点