测试面试题_测试面试题2020 - CSDN
精华内容
参与话题
  • 测试工程师常见面试题

    万次阅读 多人点赞 2018-12-17 16:33:53
    1、 测试人员在软件开发过程中的任务是什么?(初级)(5分) 答:1、寻找Bug; 2、避免软件开发过程中的缺陷; 3、衡量软件的品质; 4、关注用户的需求。 总的目标是:确保软件的质量。 2、 在您以往的工作中,一条...

    1、 测试人员在软件开发过程中的任务是什么?(初级)(5分)
    答:1、寻找Bug;
    2、避免软件开发过程中的缺陷;
    3、衡量软件的品质;
    4、关注用户的需求。
    总的目标是:确保软件的质量。
    2、 在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?(初级)(6分)
    答:一条Bug记录最基本应包含:编号、Bug所属模块、Bug描述、Bug级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等;要有效的发现Bug需参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认肯定,然后再向外发布如此才能提高提交Bug的质量。
     
    3、 界面测试题及设计题。请找出下面界面中所存在的问题并分别列出;用黑盒测试的任何一种方法设计出此登陆窗体的测试用例。(中级)(6分)

     
    答:1、窗体的标题栏中为空,没有给出标题。
    2、用户名和密码控件的字体不一致并且没有对齐。
    3、文本框的大小不一致没有对其。
    4、确定和取消按钮控件的大小不一致。
     
    4、 黑盒测试和白盒测试是软件测试的两种基本方法,请分别说明各自的优点和缺点!(中级)(5分)
    答:黑盒测试的优点有:
    1)比较简单,不需要了解程序内部的代码及实现;
    2)与软件的内部实现无关;
    3)从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题;
    4)基于软件开发文档,所以也能知道软件实现了文档中的哪些功能;
    5)在做软件自动化测试时较为方便。
    黑盒测试的缺点有:
    1)不可能覆盖所有的代码,覆盖率较低,大概只能达到总代码量的30%;
    2)自动化测试的复用性较低。
    白盒测试的优点有:
    帮助软件测试人员增大代码的覆盖率,提高代码的质量,发现代码中隐藏的问题。
    白盒测试的缺点有:
    1)程序运行会有很多不同的路径,不可能测试所有的运行路径;
    2)测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可能会漏掉一些功能需求;
    3)系统庞大时,测试开销会非常大。
    5、 根据自己的理解回答什么是软件测试,软件测试分为哪几个阶段。(初级)(5分)
    答:软件测试是一个为了寻找软件中的错误而运行软件的过程,一个成功的测试是指找到了迄今为止尚未发现的错误的测试。
    软件测试一般分为单元测试、集成测试和系统测试。
    6、 根据自己的理解什么是测试用例和测试规程,设计一个测试用例应当从哪几方面考虑?(中级)(10分)
    答:狭义的讲,一个测试用例就是测试人员用以测试被测软件的某个特性或特性组合的一组数据。这组数据可能是从用户处得来的实际的一组数据,也可能是测试人员专门设计出来的测试软件某些功能的一组数据。
    测试规程就是详细的对测试用例设计方法、测试方法、测试工具、测试环境和测试数据进行描述的文档,还可以包括能把某个或某一组测试用例应用到被测软件上完成某项测试的一系列的操作步骤。
    设计测试用例应当从以下几方面考虑:边界值,等价类划分,有效/无效值等。
    7、 什么是软件质量保证?软件质量保证人员与开发人员的关系如何?(高级) (10分)
    答:软件质量保证就是通过确保软件过程的质量,来保证软件产品的质量。
    软件质量保证人员和开发人员之间具有管理上的严格的独立性,两个小组的管理员都不能越权管理另一组,但都可以向更高层的管理者汇报软件开发中的问题
    四、 设计题
    1).输入三个整数,判断三个整数能否构成一个三角形,请用黑盒测试方法中的一种设计出相应的测试用例并详细说明所使用的黑盒测试方法。(中高级) (15分

     

    一、什么是软件测试

    软件测试是为了发现错误而执行程序的过程,为保证软件质量而采取的措施。
    或者说,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例(输入以及预期的输出结果),并利用这些测试用例去运行程序,以发现程序中的错误。
    二种思维:正向:验证程序是否正常执行以及是否达到用户预期的需求。
    反向:为发现错误或缺陷而进行的一系列活动。
    二、软件测试的目的

    发现软件缺陷,提高软件质量
    以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正错误和缺陷提高软件质量,回避因软件发布后由于潜在的缺陷和错误造成的隐患带来的商业风险。
    三、什么是需求文档测试

    需求文档是否符合用户要求、是否符合逻辑、技术是否能实现。
    四、什么是设计文档测试

    测试设计是否符合全部需求以及设计是否合理。
    五、α测试是什么

    是由一个用户在开发环境下进行的测试,可以是公司内部的用户在模拟实际操作环境下进行的受控测试,α测试不能由程序员和测试员完成。α测试发现的错误,可以在测试现场立即反馈给开发人员,由其分析和处理。目的是评价软件的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。可在编码结束/子模块测试完成之后开始。有关手册应该在测试前完成。
    六、β测试是什么

    是软件的多个用户在实际使用环境下进行的测试。开发者通常不在当前。不能由程序员和测试员来完成。因此是开发者无法控制的环境下进行的软件现场应用。同时,用户记录下所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者做修改,最终将软件产品交付给全体用户使用。Β测试更注重于产品的支持性,包括文档、客户培训和支持产品的生产能力。α测试ok后才开始β测试。
    七、什么是驱动模块

    驱动模块大多数称为是“主程序”,它接受测试数据并将数据传递到被测试模块,单元测试一个函数单元时,被测单元本身是不能独立运行的,需要为其传送数据,为此写驱动。
    驱动模块主要完成以下内容:
    1.接受测试输入
    2.对输入进行判断
    3.将输入传递给被测试单元,驱动被测单元执行
    4.接受被测单元执行结果,并对结果进行判断
    5.将判断结果作为用例执行结果输出测试报告
    八、什么是桩模块

    比如对函数A做单元测试时,被测的函数单元下还包含函数B,为了更好的定位错误,就要为函数B写桩,来模拟函数B的功能,保证其正确。
    总结:单元测试中,测试一个模块时,需要设计驱动模块和桩模块。
    运行被测试单元时,为了隔离单元,根据被测试的接口,开发相应的驱动程序和桩程序。
    驱动模块:为模拟被测试单元的上级模块,能调用被测试模块。
    桩模块:用以模拟被测模块工作过程中所调用的下层模块,桩模块由被测模块调用,一般只有很少的数据处理,以便于检测被测试模块下级模块的接口,他俩可以隔离被测试单元,又能使测试继续下去。
    九、什么是白盒测试,有几种方法

    又称为逻辑驱动测试,结构测试。知道产品内部的工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能。
    主要方法:逻辑驱动测试、基路测试
    白盒测试分为静态和动态测试2类:
    静态:不执行程序,静态结构分析法、代码检查法、静态质量度量法
    动态:基本路径测试、逻辑覆盖(语句覆盖、判断覆盖、条件覆盖、判断-条件覆盖、条件组合覆盖、路劲覆盖、)、域测试、符号测试等
    十、软件缺陷等级划分

    软件缺陷的等级可以用严重性和优先级来描述:
    严重性:衡量缺陷对客户满意度影响的满意程度,分为
    1.致命错误,可能导致本模块以及其他相关的模块异常,死机等问题;
    2.严重错误,问题局限在本模块,导致模块功能失常或异常退出;
    3.一般错误,模块功能部分失效;
    4.建议模块,有问题提出人对测试模块的改进建议;
    优先级:缺陷被修复的紧急程度;
    1.立即解决(P1级):缺陷导致系统功能几乎不能使用或者测试不能继续,需立即修复;
    2.高优先级(P2级):缺陷严重,影响测试,需优先考虑;
    3.正常排队(P3级):缺陷需要正常排队等待修复;
    4.低优先级(P4级):缺陷可以在有时间的时候被纠正;
    ---------------------
    作者:xiongluo0628
    来源:CSDN
    原文:https://blog.csdn.net/xiongluo0628/article/details/81363106
    版权声明:本文为博主原创文章,转载请附上博文链接!

     

    1)软件的概念?

    软件是计算机系统中与硬件相互依存的一部分,包括程序、数据以及与其相关文档的完整集合。

    2)软件测试的概念?

    使用人工或自动手段来运行或测试某个系统的过程, 其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

    3)测试人员和开发人员区别?

    ①人员不同

    测试:开发人员和测试人员   开发:只有开发人员

    ②所处阶段不同

    测试:贯穿整个软件开发生命周期

    调试:在软件开发编码阶段以及测试过程中对BUG进行调试

    ③对bug处理结果不同

    测试:只找出错误,不解决

    调试:找出错误并解决

    4)什么是需求?

    ①用户解决问题或达到目标所需的条件或权能,

    ②系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能

    5)测试生命周期模型?

    V模型、W模型、瀑布模型、 螺旋模型、敏捷H模型

        软件测试流程

        1、需求分析,需求评审

        2、制定测试计划、计划评审

        3、编写测试用例、用例评审

        4、测试实施阶段、执行测试用例

         按照设计好的用例、准备好的数据和制定的测试策略,实施进行具体的测试过程

        5、测试评估阶段

         测试总结、缺陷分析、过程评估

        7)V模型?

        8)W模型?

        9)瀑布模型?


        10)需求评审内容?

        ①对需求的描述是否易于理解?

        ②受否存在有二义性的需求?

        ③是否定义了术语表,对特定含义的术语给予了定义?

        ④最终产品的每个特征是用唯一的术语描述的吗?

        ⑤需求是中的条件和结果是不是合理,有没有遗漏一些异常因果关系?

        ⑥需求中有没有包含不确定行描述,如:大约、可能、等

        ⑦每个规格是不是都有明确说明?

        ⑧环境搭建是否可能或有困难?

        11)需求分类?

        ①业务需求  ②用户需求  ③系统需求

        12)什么是测试用例?

          为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。也就是解决要测什么、怎么测和如何衡量的问题

        13)什么是测试计划?

        软件测试计划就是在软件测试工作正式实施之前明确测试的对象,并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划,保证有效的实施软件测试。

        14)用例优先级?

        ② 高:最常执行以保证功能性是稳定的,目标的行为和能力可以正常的工作,和重要的错误和边界被测试的测试用例的集合。

        ③ 中:这是使给出的功能区域或功能变得更详细,检查功能的多数方面包括边界,错误和配置测试的测试用例。
        ④ 低:这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要,只是说他们在项目的生命期间里不是常常被运行,例如GUI,错误信息,可用性
        15)用例内容?

        主要分为三大部分:基本信息、用例主体、执行记录

        基本信息:项目名称、功能模块名、用例设计人、测试执行人、功能特性、测试目的、预置条件、参考信息

        用例主体:用例编号、测试对象、检查点、预置条件、用例说明、优先级、预期结果

        执行记录:测试结果、缺陷编号、备注

        16)用例执行结果?

        通过,不通过,未运行,无法运行

        17)测试计划内容?

        ①测试目的②测试背景 ③文件受众 ④术语和定义⑤测试参考文档

        ⑥测试提交文档  ⑦测试范围⑧测试策略⑨测试资源⑩测试进度里程碑

        ⑪系统错误、优先级⑫测试阶段进入退出标准和通过标准

        18)测试阶段?

        ①单元测试(组件测试)

        ②集成测试  :自顶向下集成测试  、 自底向上集成测试

                              集成策略:广度优先、深度优先

        ③系统测试

        ④验收测试

        19)黑盒测试方法?(写出15种以上)

        动态测试

        故障转移和恢复测试

        配置测试

        容量测试

        UI测试

        数据和数据库完整性测试

        易用性测试

        功能测试

        性能测试

        自动化测试

        健壮性测试

        稳定性测试

        场景测试

        逻辑测试

        随机测试

        集成测试

        系统测试

        验收测试

        冒烟测试

        兼容性测试

        逆向思维测试

        本地化测试

        接口测试

        回归测试

        Cookie测试

        Alpha测试

        Beta测试

        安全性和访问控制测试

        20)白盒和黑盒区别?

        白盒测试:是通过程序的源代码进行测试而不使用用户界面。

        黑盒测试:是通过使用整个软件或某种软件功能来严格地测试

        ①测试特点不同

        黑盒测试:测试功能

        白盒测试:测试程序接口与结构

        ②测试依据不同

        黑盒测试:需求规格说明书

        白盒测试:软件程序

        ③侧重点不同

        黑盒测试:关注功能逻辑实现

        白盒测试:关注内部代码结构

        21)测试类型?

        黑盒

        白盒

        灰盒

        22)回归测试?

        更新新版本以后确保老版本的功能依然可以使用

        23)alpha测试---内部测试(未公开)

        beta测试---用户公测

        24)冒烟测试?

        确保软件满足系统测试的要求

        25)系统测试标准?

        不存在致命或严重级别的BUG

        不存在优先级为P1的BUG

        遗留问题不能大于总BUG数的8%

        遗留问题不能明显影响用户使用

        26)集成模块?

        驱动模块、存根模块

        27)验收测试内容?

        合同验收测试、法规性验收测试、alpha测试、beta测试、确保实际效果与需求一致

        28)确认测试?

        缺陷修复后再对其进行测试,确保真正被修复

        29)设计用例原则?

        100%的覆盖需求

        编写测试用例的方法

        大纲法

        等价类

        边界值

        因果图

        场景法

        正交法

        错误推断法

        BUG的优先级

        P1应立即修复的问题

        P2在产品发布之前必须修复的问题

        P3如果时间允许应该修复的问题

        P4可以在发布版本中存在的问题

        P5可改可不改,无伤大雅

        32)BUG严重程度

        致命

        严重

        一般

        轻微

        建议

        33)常用的BUG管理工具

        禅道、JIRA、Bugfree、QC

        34)符合下边5个规则的才能叫做软件缺陷:

        ①软件未达到产品说明书标明的功能

        ②软件出现了产品说明书指明不会出现的错误

        ③软件功能超出产品说明书指明范围

        ④软件未达到产品说明书虽未指出但应达到的目标

        ⑤软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好

        35)缺陷产生的原因

        程序设计错误、文档不完善、需求不断变化、软件的复杂性、沟通交流不够、工期短,任务大、软硬件支持不完善

        36)判断发现的问题是否是缺陷的方法

        ①通过参考文档来确认缺陷

        ②通过了解软件产品的行业背景(或参考同类典型软件)来发现缺陷

        ③通过沟通来确认和识别缺陷

        37)缺陷报告原则

        ①Correct(准确):每个组成部分的描述准确,不会引起误解;
        ②Clear(清晰):每个组成部分的描述清晰,易于理解;
        ③Concise(简洁):只包含必不可少的信息,不包括任何多余的内容;
        ④Complete(完整):包含复现该缺陷的完整步骤和其他本质信息;
        ⑤Consistent(一致):按照一致的格式书写全部缺陷报告。

        38)缺陷报告的用途是什么?

        ①记录缺陷

        ②缺陷分类

        ③缺陷跟踪

        39)缺陷报告的生命周期(处理流程)

        激活、待确认、已解决、待确认、重新激活、已关闭

        40)缺陷报告内容

        三部分:基本信息、缺陷主体、跟踪记录

        ①基本信息:编号、版本号、软件名称、编译号、测试人员、日期、指定处理人、硬件平台、操作系统、严重程度、优先级

        ②缺陷主体:缺陷概述、预置条件、详细描述、预期结果、实际结果

        ③跟踪记录:处理报告、处理日期、修改记录、返测人、返测版本、返测日期、返测记录

        OSI网络7层协议

        物理层

        数据链路层

        网络层

        会话层

        传输层

        表示层

        应用层

         

        TCP/IP协议的四层分类

        APP的兼容性测试包含哪些?

        浏览器

        系统

        分辨率

        网络
    ---------------------
    作者:Johnny_Timmy
    来源:CSDN
    原文:https://blog.csdn.net/Johnny_Timmy/article/details/80496061
    版权声明:本文为博主原创文章,转载请附上博文链接!

    展开全文
  • 软件测试笔试面试题目完全汇总

    万次阅读 多人点赞 2019-03-22 22:41:43
    1、软件测试的流程 2、web测试和APP测试的区别 仅仅从功能测试的层面上来讲的话,在流程和功能测试上是没有区别的。那么区别在哪里呢? 由于载体不一样,所以系统测试和一些细节可能会不一样。 那么我们就要先...

    软件缺陷:

    1)软件未实现产品说明书要求的功能

    2)软件出现了产品说明书指明不应该出现的错误

    3)软件实现了产品说明书未提到的功能

    4)软件未实现产品说明书虽未明确提及但应该实现的目标

    5)软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好。

    软件测试:为了发现软件产品中的各种缺陷,而对软件产品进行验证和确认的活动过程,此过程贯穿整个软件开发生命周期。 简单的说,软件测试是以发现错误为目的而执行的一个程序或系统的过程。

    软件测试的目的:

    1.验证软件需求和功能是否得到完整实现
    2.验证软件是否可以发布
    3.尽可能多的发现软件中的bug
    4.尽可能早的发现软件中的bug
    5.对软件质量做出合理评估
    6.预防下个版本可能出现的问题
    7.预防用户使用可能出现的问题
    8.发现开发过程中的问题和风险

    软件测试的原则:

    1、所有测试的标准都是建立在用户需求之上 。
    2、合理控制测试深度与广度,完全测试不可能,测试的投入与产出要均衡。
    3、80-20原则,软件中80%的bug可以在分析、设计与评审阶段就能被发现与修正,16%的缺陷在系统的软件测试中发现,最后剩下的4%是用户长期使用的过程中才能暴露出来。
    4、尽可能早的开展测试,越早发现错误,修改的代价越小。
    5、发现错误较多的程序段,应进行更深入的测试。
    6、软件项目一启动,软件测试也就是开始,而不是等程序写完,才开始进行测试 。
    7、软件开发人员即程序员应当避免测试自己的程序
    8、严格执行测试计划,排除测试的随意性,以避免发生疏漏或者重复无效的工作

    软件测试的流程

    在这里插入图片描述

    web测试和APP测试的区别

    仅仅从功能测试的层面上来讲的话,在流程和功能测试上是没有区别的。那么区别在哪里呢?
    由于载体不一样,所以系统测试和一些细节可能会不一样。
    那么我们就要先来了解,web和app的区别。

    web项目,一般都是b/s架构,基于浏览器的,而app则是c/s的,必须要有客户端。那么在系统测试测试的时候就会产生区别了。

    首先从系统架构来看的话,web测试只要更新了服务器端,客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的,除非用户更新客户端。如果是app下修改了服务端,意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

    接着是性能方面,web页面可能只会关注响应时间,而app则还需要关心流量、电量、CPU、GPU、Memory这些了。至于服务端的性能是没区别,这里就不谈。

    相比较web测试,app更是多了一些专项测试:

    健壮性测试:

    一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断,来电,短信,关机,重启等。

    而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验,重点要考虑回退和刷新是否会造成二次提交。需要测试丢包,延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过,这里不再讲了。
      
    安装、卸载、更新:
      web测试是基于浏览器的所以不必考虑这些。而app是客户端的,则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件,更新的强制更新与非强制更新、增量包更新、断点续传、弱网,卸载后删除app相关的文件等等。
      
    就自动化来讲,web大多用的selenium、webdriver,而app则是appium。
    性能使用的工具web则是LR,app使用Jmeter要多一点

    如何提交高质量的缺陷报告单

    1、 缺陷的概要描述要清晰准确,要使相关开发负责人员能够一目了然问题是什么。
    2、 一个完整的缺陷报告单,必须包含其必要的元素信息,例如:概要描述,缺陷发现人,测试环境,浏览器,缺陷重现步骤,严重等级,指派人,所属功能模块等等,必要元素信息必须描述全面清楚。
    3、 缺陷的重现步骤必须描写清晰明了,使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷,使其定位缺陷的原因所在。
    4、测试数据,测试的数据作为重现缺陷的一个重要元素信息,一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
    5、附件截图信息,附件或截图信息能让开发人员能够一目了然的清楚问题的所在。
    在这里插入图片描述

    如何对web系统进行全面测试?

    原文地址:http://www.51testing.com/html/04/n-3727304.html
    一、 功能测试
      1、链接测试
      链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。 链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。
      2、表单测试
      当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
      3、Cookies测试
      Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。 如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。
      4、设计语言测试
      Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
      5、数据库测试
      在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。 在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。
    二、 性能测试
      1、连接速度测试
      用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。 另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。
      2、负载测试
      负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?
      3、压力测试
      负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。 进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。 压力测试的区域包括表单、登陆和其他信息传输页面等。
    三、 可用性测试
      1、导航测试
      导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助? 在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。 导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。 Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。
      2、图形测试
       在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。
      图形测试的内容有:
      (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
      (2)验证所有页面字体的风格是否一致。
      (3)背景颜色应该与字体颜色和前景颜色相搭配。
      (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。
      3、内容测试
      内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的拼音与语法检查功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓相关文章列表。
      4、整体界面测试
      整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致? 对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。 对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
    四、 客户端兼容性测试
      1、平台测试
      市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。 因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。
      2、浏览器测试
      浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,JavaScript是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
    五、 安全性测试
      Web应用系统的安全性测试区域主要有:
      (1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
      (2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
      (3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
      (4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。
      (5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

    测试用例设计经典面试题——电梯,杯子,笔,桌子,洗衣机

    原文地址:https://blog.csdn.net/slforeverlove/article/details/47080279

    优秀测试人员应具备的素质:

    1)沟通能力与表达能力
    2)好奇心与怀疑精神
    3)责任感与抗压能力
    4)自信心,坚持自己的观点
    5)耐心与细心
    6)逆向思维的能力
    7)善于学习与总结
    8)团队协作精神
    9)文档编写能力

    优秀测试人员应具备的技能:

    1)精通业务知识
    2)具备软件编程能力,比如C,C++,JAVA等。
    3)可以用脚本语言编写小测试工具
    4)主流操作系统应用与网络知识,可以搭建测试环境
    5)熟练掌握各种数据库知识
    6)精通软件测试理论与方法
    7)掌握常用测试与开发工具的使用
    8)优秀的文档编写能力

    软件测试的分类:

    1)按照是否执行被测试软件来分:

    静态测试:是指不运行软件,测试包括代码检查、静态结构分析、代码质量度量等,主要对软件需求说明书、设计说明书、软件源代码进行检查与分析。

    动态测试:指通过运行被测程序,检查运行结果与预期结果的差异,分析差异原因,并分析软件运行效率、健壮性等性能。 动态测试是目前公司主要的测试方式

    2)按照测试技术分为黑盒测试和白盒测试:

    黑盒测试:黑盒测试又叫功能测试或数据驱动测试,在完全不考虑程序内部结构和内部特性的情况下,通过软件的外部表现来发现其缺陷和错误。

    白盒测试:白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构进行测试程序,通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。

    3)按照测试手段来分,可以分为手工测试和自动化测试

    4)按照过程阶段来分,可以分为单元测试、集成测试、系统测试和验收测试

    单元测试:通过模块(类/方法/函数)测试,使代码达到设计要求 主要目的是针对编码过程中可能存在的各种错误,例如用户输入验证过程中的边界值的错误。

    集成测试:将经过单元测试的模块逐步组装成完整的程序。 主要目的是检查各单元与其它程序部分之间的接口是否存在问题,各模块功能之间是否有影响。

    系统测试:是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。 系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方 ,进行改正。

    验收测试:验收测试是在软件产品完成了单元测试、集成测试和系统测试之后,产品发布之前所进行的最后一次软件测试活动,也称为交付测试。 通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。

    软件开发流程(软件生命周期):

    计划-》需求分析-》设计-》程序编写-》测试-》运行/维护

    软件测试流程:

    测试计划-》需求分析-》测试用例-》测试用例执行-》提交bug-》回归测试

    软件开发模型:

    在这里插入图片描述

    软件测试模型:

    V模型:反映了测试与开发阶段之间一一对应的特点,测试在开发之后,出错后回归测试量大。
    在这里插入图片描述
    W模型:测试伴随整个开发周期,测试与开发同步进行,有利于尽早发现问题
    在这里插入图片描述
    H模型:软件测试活动完全独立,与其他流程并行。

    白盒测试方法

    白盒测试方法有 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

    1.语句覆盖每条语句至少执行一次。

    2.判定覆盖每个判定的每个分支至少执行一次。

    3.条件覆盖每个判定的每个条件应取到各种可能的值。

    4.判定/条件覆盖同时满足判定覆盖条件覆盖。

    5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

    6.路径覆盖使程序中每一条可能的路径至少执行一次。

    设计用例的方法、依据有那些?

    测试分为白盒测试和黑盒测试,回答时,要注意分开说。白盒测试用例设计有如下方法:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。依据就是代码结构。

    黑盒测试用例设计方法:基于用户需求的测试、等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验法、场景法。依据是用户需求规格说明书,详细设计说明书。

    一个测试工程师应具备那些素质和技能?

    一个好的测试工程师,不仅要基础扎实,对自身的性格、责任心都有非常高的要求。具体如下:(1)掌握基本的测试基础理论(2)本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现(3)可熟练阅读需求规格说明书等文档(4)以用户的观点看待问题(5)有着强烈的质量意识(6)细心和责任心(7)良好的有效的沟通方式(与开发人员及客户)(8)具有以往的测试经验(9)能够及时准确地判断出高危险区在何处.

    集成测试通常都有哪些策略?

    大致说四点即可,当然说全更好。集成测试有十种策略:(1)大爆炸集成(2)自顶向下集成(3)自底向上集成(4)三明治集成(5)分层集成(6)基干集成(7)基于功能的集成(8)基于消息的集成(9)基于风险的集成(10)基于进度的集成.

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

    兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行,即是通常说的软件的可移植性。

    兼容的类型,如果细分的话,有平台的兼容,网络兼容,数据库兼容,以及数据格式的兼容。

    兼容测试的重点是,对兼容环境的分析。通常,是在运行软件的环境不是很确定的情况下,才需要做兼容。根据软件运行的需要,或者根据需求文档,一般都能够得出用户会在什么环境下使用该软件,把这些环境整理成表单,就得出做兼容测试的兼容环境了。

    我现在有个程序,发现在Windows上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?

    1、检查系统是否有中毒的特征;

    2、检查软件/硬件的配置是否符合软件的推荐标准;

    3、确认当前的系统是否是独立,即没有对外提供什么消耗CPU资源的服务;

    4、如果是C/S或者B/S结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成的;

    5、在系统没有任何负载的情况下,查看性能监视器,确认应用程序对CPU/内存的访问情况。

    测试的策略有哪些?

    黑盒/白盒,静态/动态,手工/自动,冒烟测试,回归测试,公测(Beta测试的策略)

    正交表测试用例设计方法的特点是什么?

    用最少的实验覆盖最多的操作,测试用例设计很少,效率高,但是很复杂;

    对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来;但是更深的缺陷,更复杂的缺陷,还是无能为力的;

    具体的环境下,正交表一般都很难做的。大多数,只在系统测试的时候使用此方法。

    描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程?

    详见bugZilla使用指南

    在Bugzilla中,Bug报告状态分为以下几种状态,

    待确认的      unconfirmed
    
    新提交的      new
    
    已分配的      assigned
    
    问题未解决的 reopened
    
    待返测的       resolved
    
    待归档的       verified
    
    已归档的       closed
    

    Bug处理意见(Resolution)

    已修改的      fixed
    
    不是问题       nvalid
    
    无法修改       wontfix
    
    以后版本解决  later
    
     保留           remind
    
     重复           duplicate
    
     无法重现      workforme 
    

    在这里插入图片描述

    你觉得bugzilla在使用的过程中,有什么问题?

    界面不稳定;

    根据需要配置它的不同的部分,过程很烦琐。

    流程控制上,安全性不好界定,很容易对他人的Bug进行误操作;

    没有综合的评分指标,不好确认修复的优先级别。

    描述测试用例设计的完整过程?

    需求分析 + 需求变更的维护工作;

    根据需求 得出测试需求;

    设计测试方案,评审测试方案;

    方案评审通过后,设计测试用例,再对测试用例进行评审;

    单元测试的策略有哪些?

    单元的常见错误一般出现在以下五个方面,因此这五个方面是单元测试应该关注的重点。

    1、单元接口。

    2、局部数据结构。

    3、独立路径。

    4、出错处理。

    5、边界条件

    在单元测试时,由于单元本身不是一个独立的程序,一个完整的可运行的软件系统并没有构成,所以需要设置一些辅助测试单元,辅助测试单元有两种,一种是驱动单元,另外一种是桩单元。

    1、驱动单元(Driver):用来模拟被测单元的上层单元,相当于被测函数的主函数,如main函数。所以驱动单元主要完成以下4个步骤:

    (1)接受测试数据,包含测试用例输入和预期输出;

    (2)把测试用例输入传送给被测单元,驱动被测单元测试;

    (3)将被测单元的实际输出和预期输出进行比较,得到测试结果;

    (4)将测试结果输出到指定位置。

    2、桩单元(Stub):用来代替被测单元工作过程中调用的子单元。

    桩单元模拟的单元可能是自定义函数:这些自定义函数可能尚未编写完成,为了测试被测单元,需要构造桩单元来代替它们,可能存在错误,会影响测试结果,所以需要构造正确无误的桩单元来达到隔离的目的。

    驱动单元和桩单元都是额外的开销,虽然在单元测试的时候必须写,但是并不需要作为最终的产品提供给客户。

    单元测试策略

    一般的单元执行策略有三种:孤立的单元测试策略(Isolation Unit Testing),自顶向下的单元测试策略(Top Down Unit Testing)和自底向上的单元测试策略(Bottom Up Unit Testing)。需要注意的是:在集成测试中也有自顶向下和自底向上的测试策略,但是测试对象不同。

    1、孤立的单元测试策略(Isolation Unit Testing)

    方法:不考虑每个模块与其它模块之间的关系,为每个模块设计桩模块和驱动模块,每个模块进行独立的单元测试。

    优点:这个方法比较简单,最容易操作,可以达到很高的结构覆盖率,可以并行开展,该方法是纯粹的单元测试。

    缺点:桩函数和驱动函数工作量很大,效率低。

    2、自顶向下的单元测试策略(Top Down Unit Testing)

    方法:先对最顶层的单元进行测试,把顶层所调用的单元做成桩模块,其次对第二层进行测试,使用上面已经测试过的单元做驱动模块,以此类推,直到测试完所有模块。

    优点:可以节省驱动函数的开发工作,效率高。

    缺点:随着被测单元一个一个被加入,测试过程将变得越来越复杂,并且开发和维护的成本将增加。

    3、自底向上的单元测试策略(Bottom Up Unit Testing)

    方法:先对最底层的模块进行单元测试,将模拟调用该模块的模块设置为驱动模块,然后再对上面一层做单元测试,用下面已经测试好的模块做桩模块,以此类推,直到测试完所有模块。

    优点:可以节省桩函数的开发工作量,测试效率较高。

    缺点:不是纯粹的单元测试,底层函数的测试质量对上层函数的测试将产生很大影响。

    LoadRunner分哪三部分?

    脚本生成器;

    场景控制器;

    结果分析器。

    LoadRunner进行测试的流程?

    1、 测试设计

    2、 创建虚拟用户脚本

    3、 创建运行场景

    4、 运行场景

    5、 监视场景

    6、 分析测试的结果

    以上,最好是结合一个案例,根据以上流程来介绍。

    什么是并发?在lordrunner中,如何进行并发的测试?集合点失败了会怎么样?

    在同一时间点,支持多个不同的操作。

    LoadRunner中提供IP伪装,集合点,配合虚拟用户的设计,以及在多台电脑上设置,可以比较好的模拟真实的并发。

    集合点,即是多个用户在某个时刻,某个特定的环境下同时进行虚拟用户的操作的。集合点失败,则集合点的操作就会取消,测试就不能进行。

    TestDirector有些什么功能,如何对软件测试过程进行管理?

    需求管理

    n 定义测试范围

    n 定义需求树

    n 描述需求树的功能点

    测试计划

    n 定义测试目标和测试策略。

    n 分解应用程序,建立测试计划树。

    n 确定每个功能点的测试方法。

    n 将每个功能点连接到需求上,使测试计划覆盖全部的测试需求。

    n 描述手工测试的测试步骤

    n 指明需要进行自动测试的功能点

    测试执行

    n 定义测试集合。

    n 为每个测试人员制定测试任务和测试日程安排。

    n 运行自动测试。

    缺陷跟踪

    n 记录缺陷

    n 查看新增缺陷,并确定哪些是需要修正的

    n 相关技术人员修改缺陷

    n 回归测试

    n 分析缺陷统计图表,分析应用程序的开发质量。

    你所熟悉的软件测试类型都有哪些?请试着分别比较这些不同的测试类型的区别与联系(如功能测试、性能测试……)?

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Functional testing (功能测试),也称为behavioral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。
    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    1.和BUG对应的软件版本
    2.开发的接口人员,测试人员
    3.BUG的优先级
    4.BUG的严重程度
    5.BUG可能属于的模块
    6.BUG的标题
    7.BUG的描述
    8.BUG的截图
    9.BUG的状态
    10.BUG的错误类型(数据,界面。。。。)
    在这里插入图片描述

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

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试

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

    在正式的会议上将软件项目的成果(包括各阶段的文档、产生的代码等)提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷,并采取补救措施,以及找出在性能、安全性和经济方面的可能的改进。

    人员:用户、客户或有关部门开发人员,测试人员,需求分析师都可以,就看处于评审那个阶段

    阶段评审与项目评审有什么区别?

    阶段评审对项目各阶段评审:对阶段成果和工作

    项目评审对项目总体评审:对工作和产品

    什么是扇入?什么是扇出?

    参考答案:

    扇入:被调次数,扇出:调其它模块数目

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

    桩模块:被测模块调用模块

    驱动模块:调用被测模块

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

    软件测试计划就是在软件测试工作正式实施之前明确测试的对象,并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划,保证有效的实施软件测试;

    做好测试计划工作的关键:目的,管理,规范

    1、 明确测试的目标,增强测试计划的实用性
    编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确

    2.坚持“5W”规则,明确内容与过程
    “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。

    3.采用评审和更新机制,保证测试计划满足实际需求
    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。

    4、分别创建测试计划与测试详细规格、测试用例
    应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

    简述一下缺陷的生命周期?

    提交->确认->分配->修复->验证->关闭

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

    (1)用户认证机制:如数据证书、智能卡、双重认证、安全电子交易协议

    (2)加密机制

    (3)安全防护策略:如安全日志、入侵检测、隔离防护、漏洞扫描

    (4)数据备份与恢复手段:存储设备、存储优化、存储保护、存储管理

    (5)防病毒系统

    软件配置管理工作开展的情况和认识?

    软件配置管理贯穿于软件开发、测试活动的始终,覆盖了开发、测试活动的各个环节,它的重要作用之一就是要全面的管理保存各个配置项,监控各配置项的状态,并向项目经理及相关的人员报告,从而实现对软件过程的控制。

    软件测试配置管理包括4个最基本的活动:

    配置项标识

    配置项控制

    配置项状态报告

    配置审计

       软件配置管理通常借助工具来辅助,主要有MS SourceSafe、Rational ClearCase等
    

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

    缺陷密度值达到客户的要求
    

    引入测试管理的含义?

    风险分析,进度控制、角色分配、质量控制

    一套完整的测试应该由哪些阶段组成?

    参考答案:测试计划、测试设计与开发、测试实施、测试评审与测试结论

    单元测试的主要内容?

    模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

    集成测试也叫组装测试或者联合测试,请简述集成测试的主要内容?

    (1)在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;

    (2)一个模块的功能是否会对另一个模块的功能产生不利的影响;

    (3)各个子功能组合起来,能否达到预期要求的父功能;

    (4)全局数据结构是否有问题;

    (5)单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。

    简述集成测试与系统测试关系?

    (1)集成测试的主要依据概要设计说明书,系统测试的主要依据是需求设计说明书;

    (2)集成测试是系统模块的测试,系统测试是对整个系统的测试,包括相关的软硬件平台、网络以及相关外设的测试。

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

    用户手册

    安装和设置指导

    联机帮助

    指南、向导

    样例、示例和模板

    授权/注册登记表

    最终用户许可协议

    软件系统中除用户文档之外,文档测试还应该关注哪些文档?

    开发文档

    软件需求说明书

        数据库设计说明书
    
        概要设计说明书
    
        详细设计说明书
    
        可行性研究报告
    

    管理文档

        项目开发计划
    
        测试计划
    
        测试报告
    
        开发进度月报
    
        开发总结报告
    

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

    (1)读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位

    (2)术语。文档中用到的术语要适用与定位的读者群,用法一致,标准定义与业界规范相吻合。

    (3)正确性。测试中需检查所有信息是否真实正确,查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新,尝试链接是否准确,产品支持电话、地址和邮政编码是否正确。

    (4)完整性。对照软件界面检查是否有重要的分支没有描述到,甚至是否有整个大模块没有描述到。

    (5)一致性。按照文档描述的操作执行后,检查软件返回的结果是否与文档描述的相同。

    (6)易用性。对关键步骤以粗体或背景色给用户以提示,合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作,也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。

    (7)图表与界面截图。检查所有图表与界面截图是否与发行版本相同。

    (8)样例与示例。像用户一样载入和使用样例。如果是一段程序,就输入数据并执行它。以每一个模块制作文件,确认它们的正确性。

    (9)语言。不出现错别字,不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。

    (10)印刷与包装。检查印刷质量;手册厚度与开本是否合适;包装盒的大小是否合适;有没有零碎易丢失的小部件等等。

    单元测试主要内容是什么?

    单元测试大多数由开发人员来完成,测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试,大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。

    单元测试一般包括五个方面的测试:

    (1)模块接口测试:模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下,其他测试才有意义。模块接口测试也是集成测试的重点,这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素:

    -输入的实际参数与形式参数的个数是否相同;

    -输入的实际参数与形式参数的属性是否匹配;

    -输入的实际参数与形式参数的量纲是否一致;

    -调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;

    -调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;

    -调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;

    -调用预定义函数时所用参数的个数、属性和次序是否正确;

    -是否存在与当前入口点无关的参数引用;

    -是否修改了只读型参数;

    -对全程变量的定义各模块是否一致;

    -是否把某些约束作为参数传递。

    如果模块功能包括外部输入输出,还应该考虑下列因素:

    -文件属性是否正确;

    -OPEN/CLOSE语句是否正确;

    -格式说明与输入输出语句是否匹配;

    -缓冲区大小与记录长度是否匹配;

    -文件使用前是否已经打开;

    -是否处理了文件尾;

    -是否处理了输入/输出错误;

    -输出信息中是否有文字性错误。

    -局部数据结构测试;

    -边界条件测试;

    -模块中所有独立执行通路测试;

    (2)局部数据结构测试:检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确,局部功能是整个功能运行的基础。重点是一些函数是否正确执行,内部是否运行正确。局部数据结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误:

    -不合适或不相容的类型说明;

    -变量无初值;

    -变量初始化或省缺值有错;

    -不正确的变量名(拼错或不正确地截断);

    -出现上溢、下溢和地址异常。

    (3)边界条件测试:边界条件测试是单元测试中最重要的一项任务。众所周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。边界条件测试是一项基础测试,也是后面系统测试中的功能测试的重点,边界测试执行的较好,可以大大提高程序健壮性。

    (4)模块中所有独立路径测试:在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括:

    -误解或用错了算符优先级;

    -混合类型运算;

    -变量初值错;

    -精度不够;

    -表达式符号错。

    比较判断与控制流常常紧密相关,测试时注意下列错误:

    -不同数据类型的对象之间进行比较;

    -错误地使用逻辑运算符或优先级;

    -因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等;

    -比较运算或变量出错;

    -循环终止条件或不可能出现;

    -迭代发散时不能退出;

    -错误地修改了循环变量。

    模块的各条错误处理通路测试:程序在遇到异常情况时不应该退出,好的程序应能预见各种出错条件,并预设各种出错处理通路。如果用户不按照正常操作,程序就退出或者停止工作,实际上也是一种缺陷,因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题:

    -输出的出错信息难以理解;

    -记录的错误与实际遇到的错误不相符;

    -在程序自定义的出错处理段运行之前,系统已介入;

    -异常处理不当;

    -错误陈述中未能提供足够的定位出错信息。

    如何理解强度测试?

    强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。

    它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.

    强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\最小\平均)以及顺序指标等

    强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法

    如何理解压力、负载、性能测试测试?

    性能测试是一个较大的范围,实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。

    压力测试是对服务器的稳定性以及负载能力等方面的测试,是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试,主要是测试系统在一种或者集中极限条件下的相应能力,是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试,那么连续访问8个小时就可以认为负载测试,1000个用户连续访问系统1个小时也可以看作是负载测试。

    实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。

    什么是系统瓶颈?

    瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求,“特定”是指瓶颈会在某些条件下会出现,因为毕竟大多数系统在投入前。

    严格的从技术角度讲,所有的系统都会有瓶颈,因为大多数系统的资源配置不是协调的,例如CPU使用率刚好达到100%时,内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论:关键是看系统能否满足用户需求。在用户极限使用系统的情况下,系统的响应仍然正常,我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。

    因此我们测试系统瓶颈主要是实现下面两个目的:

    -发现“表面”的瓶颈。主要是模拟用户的操作,找出用户极限使用系统时的瓶颈,然后解决瓶颈,这是性能测试的基本目标。

    -发现潜在的瓶颈并解决,保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时,系统能够适应变化。满足用户目前需求的系统不是最好的,我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化,或者通过简单扩展系统就可以适应新的变化。

    文档测试主要包含什么内容?

    在国内软件开发管理中,文档管理几乎是最弱的一项,因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品,文档测试是必不可少的。文档测试一般注重下面几个方面:

    文档的完整性:主要是测试文档内容的全面性与完整性,从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。

    描述与软件实际情况的一致性:主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后,我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。

    易理解性:主要是检查文档对关键、重要的操作有无图文说明,文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的,应该附有图表使说明更为直观和明了。

    文档中提供操作的实例:这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富,提供的实例描述是否详细。只有简单的图文说明,而无实例的用户手册看起来就像是软件界面的简单拷贝,对于用户来说,实际上没有什么帮助。

    印刷与包装质量:主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成,过于粗糙,不易于用户保存。优秀的文档例如用户手册和技术白皮书,应提供商品化包装,并且印刷精美。

    配置和兼容性测试的区别是什么?

    配置测试的目的是保证软件在其相关的硬件上能够正常运行,而兼容性测试主要是测试软件能否与不同的软件正确协作。

    配置测试的核心内容就是使用各种硬件来测试软件的运行情况,一般包括:

    (1)软件在不同的主机上的运行情况,例如Dell和Apple;

    (2)软件在不同的组件上的运行情况,例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况;

    (3)不同的外设;

    (4)不同的接口;

    (5)不同的可选项,例如不同的内存大小;

    兼容性测试的核心内容:

    (1)测试软件是否能在不同的操作系统平台上兼容;

    (2)测试软件是否能在同一操作系统平台的不同版本上兼容;

    (3)软件本身能否向前或者向后兼容;

    (4)测试软件能否与其它相关的软件兼容;

    (5)数据兼容性测试,主要是指数据能否共享;

    配置和兼容性测试通称对开发系统类软件比较重要,例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。

    软件文档测试主要包含什么?

    随着软件文档系统日益庞大,文档测试已经成为软件测试的重要内容。文档测试对象主要如下:

    -包装文字和图形;

    -市场宣传材料、广告以及其它插页;

    -授权、注册登记表;

    -最终用户许可协议;

    -安装和设置向导;

    -用户手册;

    -联机帮助;

    -样例、示范例子和模板;

    -……

    文档测试的目的是提高易用性和可靠性,降低支持费用,因为用户通过文档就可以自己解决问题。因文档测试的检查内容主要如下:

    -读者对象——主要是文档的内容是否能让该级别的读者理解;

    -术语——主要是检查术语是否适合读者;

    -内容和主题——检查主题是否合适、是否丢失、格式是否规范等;

    -图标和屏幕抓图——检查图表的准确度和精确度;

    -样例和示例——是否与软件功能一致;

    -拼写和语法;

    -文档的关联性——是否与其它相关文档的内容一致,例如与广告信息是否一致;

    文档测试是相当重要的一项测试工作,不但要给予充分的重视,更要要认真的完成,象做功能测试一样来对待文档测试。

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

    这个问题是国内测试工程师经常遇到的问题,根源就是国内软件开发文档管理不规范,对变更的管理方法就更不合理了。实际上没有任何文档的时候,测试人员是能够进行黑盒测试的,这种测试方式我们可以称之为探索测试,具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能,进而发现缺陷。

    在这种做法基本上把软件当成了产品说明书,测试过程中要和开发人员不断的进行交流。尤其在作项目的时候,进度压力比较大,可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。

    ##3 测试中的“杀虫剂怪事”是指什么?
    “杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多,发现的缺陷就会越来越少的现象。就像老用一种农药,害虫就会有免疫力,农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉,形成思维定势。

    为了克服这种现象,测试人员需要不断编写新的测试程序或者测试用例,对程序的不同部分进行测试,以发现更多的缺陷。也可以引用新人来测试软件,刚刚进来的新手往往能发现一些意想不到的问题。

    在配置测试中,如何判断发现的缺陷是普通问题还是特定的配置问题?

    在进行配置测试时,测试工程师仍然会发现一些普通的缺陷,也就是与配置环境无关的缺陷。因此判断新发现的问题,需要在不同的配置中重新执行发现软件缺陷的步骤,如果软件缺陷不出现了,就可能是配置缺陷;如果在所有的配置中都出现,就可能是普通缺陷。

    需要注意的是,配置问题可以在一大类配置中出现。例如,拨号程序可能在所有的外置Modem中都存在问题,而内置的Modem不会有任何问题。

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

    软件测试初学者可能认为拿到软件后需要进行完全测试,找到全部的软件缺陷,使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因:

    -完全测试比较耗时,时间上不允许;

    -完全测试通常意味着较多资源投入,这在现实中往往是行不通的;

    -输入量太大,不能一一进行测试;

    -输出结果太多,只能分类进行验证;

    -软件实现途径太多;

    -软件产品说明书没有客观标准,从不同的角度看,软件缺陷的标准不同;

    因此测试的程度要根据实际情况确定。

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

    我们没有对软件进行完全测试,实际就是选择了风险,因为缺陷极有可能存在没有进行测试的部分。举个例子,程序员为了方便,在调试程序时会弹出一些提示信息框,而这些提示只在某种条件下会弹出,碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它,这将是代价昂贵的缺陷,因为交付后才被客户发现。

    因此,我们要尽可能的选择最合适的测试量,把风险降低到最小。

    发现的缺陷越多,说明软件缺陷越多吗?

    这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考,但是找到一个后,会接二连三的发现很多缺陷,颇有个人成就感。其中的原因主要如下:

    -代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误,反复拷贝同一代码意味可能也复制了缺陷。

    -程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象,因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。

    “缺陷一个连着一个”不是一个客观规律,只是一个常见的现象。如果软件编写的比较好,这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。

    所有的软件缺陷都能修复吗?所有的软件缺陷都要修复吗?

    从技术上讲,所有的软件缺陷都是能够修复的,但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队,要做的是对每一个软件缺陷进行取舍,根据风险决定那些缺陷要修复。发生这种现象的主要原因如下:

    -没有足够的时间资源。在任何一个项目中,通常情况下开发人员和测试人员都是不够用的,而且在项目中没有预算足够的回归测试时间,再加上修改缺陷可能引入新的缺陷,因此在交付期限的强大压力下,必须放弃某些缺陷的修改。

    -有些缺陷只是特殊情况下出现,这种缺陷处于商业利益考虑,可以在以后升级中进行修复。

    -不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理,这类问题可以以后有时间时考虑再处理。

    最后要说的是,缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复,不同角色的人员从不同的角度来思考,以做出正确的决定。

    软件测试人员就是QA吗?

    软件测试人员的职责是尽可能早的找出软件缺陷,确保得以修复。而质量保证人员(QA)主要职责是创建或者制定标准和方法,提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试,质量保证人员日常工作重要内容是检查与评审,测试工作也是测试保证人员的工作对象。

    软件测试和质量是相辅相成的关系,都是为了提高软件质量而工作。

    如何减少测试人员跳槽带来的损失?

    在IT行业里跳槽已经是一种司空见惯的现象,而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁,作为测试经理管理者,只有从日常工作中开始做起,最能最大限度的减少损失。建议我们从以下两个方面做起:

    -加强部门内员工之间的互相学习,互相学习是建立学习型组织的基本要求,是知识互相转移的过程。在此基础上,可以把个人拥有的技术以知识的形式沉积下来,也就完成了隐性知识到显性知识的转化。

    -通常情况下,企业能为员工提供足够大的发展空间时,如果不是待遇特别低,员工都不会主动离开企业。因此我们要想留住员工,管理者就应该把员工的个人成长和企业的发展联系起来,为员工设定合理发展规划并付诸实现。不过这项要求做起来比较,要有比较好的企业文化为依托.

    以windows对文件的复制粘帖功能为例,尽可能多地写出测试思路

    1、 基本功能测试: 文件的复制粘贴功能,首先关键字“文件”,文件有不同的分类(图片、视频、音频、文档等),每个分类又有不同的类型(文档类型:txt doc execl pdf等),每个文件又有不同的大小,而且文件还有很多权限,是不是隐藏,是不是只是管理员可执行。选择不同分类的不同类型,不同大小的文件做测试资源。比如:文档类型里面txt文件可以分为 1.KB的txt文件、1MB的txt文件、1GB的txt文件。。。。
    下一个关键字 复制粘贴 复制有多种方式 右击选择、Ctrl+C、 拖动复制,对应粘贴也有各种方式。然后从哪复制,粘贴到哪,比如 可以有本机硬盘、移动硬盘、优盘、内存卡、软盘、光盘、连接手机存储,复制到网络地址等等。复制粘贴后文件是不是可用,文件权限是不是有变化。复制过去容量不够怎么处理?复制过后有重名文件怎么处理?复制过程中取消、关机、拔优盘怎么处理?复制过程能不能执行文件?

    2.性能测试:复制粘贴功能性能怎么样?复制文件的速度可不可以接受?同时复制多个文件是不是可以完成?复制文件过程中占用CPU资源大不大,耗电量大不大?

    3.兼容性测试 Windows XP, Windows 7, Windows 8 , Windows 8.1, Windows 10等各种windos版本是不是都支持这个功能。

    4.交互测试; 复制粘贴文件时,使用windows存储的其他功能是否有影响?比如播放本地的音频、视频、等同时复制文件是不是有影响。一边复制,一边粘贴是不是有影响。

    粘贴的稳定性:粘贴完了大小会不会变化,内容格式会不会变化,粘贴不上,误操作以后还能不能找到复制的内容等

    粘贴的安全性:粘贴的内容粘贴好了以后会不会存在别处泄露等

    2.性能测试:(1)时间:复制粘贴的响应时间?页面的显示时间?(2)负载:多次重复进行复制粘贴是否有异常?复制粘贴容量很大的一个或多个文件是否能承受?(3)强度:保证容量足够的条件下,分别复制粘贴50GB,100GB,500GB,…大小的文件,看什么时候出现失败,失败后的表现,能否重新正常复制粘贴50G?(4)容量:在不同CPU资源条件下,持续复制粘贴5分钟,最多能复制粘贴多少容量的文件?

    5.界面测试:复制粘贴时进度条的显示界面是否与系统的设计风格一致?显示界面是否有文字性错误?显示界面的布是否合理?界面上的按钮是否可用(如:是否可以选择中止?是否可用最小化?)

    6.本地化测试:不同语言环境下的显示正常

    7.辅助性测试:高对比度下能否显示正常

    链接:https://www.nowcoder.com/questionTerminal/ad274cafadf64222bb8805df45828741?orderByHotValue=1&pos=3
    来源:牛客网

    1 、复制粘贴方法

    快捷键测试:测试 Ctrl+C ,是否正确执行复制、 Ctrl+v 是否支持粘贴功能

    右键测试:查看复制粘贴功能是否正确执行;

    在 cmd 命令行中使用复制粘贴命令;

    2 、文件大小测试

    源文件为空, 0 字节;

    源文件正常大小;

    源文件为超大文件: **G/ 等;

    3 、文件格式

    测试各种文件格式下是否正常复制粘贴:如:图片、声音、视频、压缩文件、办公文件: word\excel\ppt 等、二进制文件;

    测试共享文件、隐藏文件

    4 、复制和粘贴文件路径

    在系统不同文件路径下复制粘贴,

    测试相对路径和绝对路径下文件复制粘贴;

    测试文件夹下和另一个不同文件夹复制粘贴;

    测试不同 C\D\E 盘之间;

    测试复制粘贴至:移动硬盘、 U 盘、读卡器以及其它外部存储设备;

    5 、异常测试

    测试被损坏文件、不完整文件名称、禁止复制和粘贴的文件、超出规定大小文件等;

    同名称文件测试是否提醒替换或覆盖;

    6 、兼容性

    测试不同操作系统之间、不同应用程序(如: QQ );

    7 、性能测试:

    测试复制粘贴可支持最大文件大小;复制粘贴操作的相应速度、执行完毕时间;

    一次支持不同格式的文件同时操作;

    支持大量文件同时复制粘贴;

    登录界面测试用例设计

    一、界面测试点:

    1、界面的设计风格是否与UI的设计风格统一;

    2、界面中的文字简洁易懂;

    3、界面中没有错别字;

    二、用户名与密码在输入时,要考虑:

    1、正确的用户名与正确的密码;

    2、正确的用户名与错误的密码;

    3、错误的用户名与正确的密码;

    4、错误的用户名与错误的密码;

    5、空的用户名和空的密码;

    6、正确的用户名和空的密码;

    7、空的用户名和正确的密码;

    8、用户名的前/中/后含有空格;

    9、密码的前/中/后含有空格;

    10、用户名与密码使用的字符范围及位数限制的测试(等价类及边界值,会用到强制的复制与粘贴来实现不允许输入的字符,以及一些保留字的测试);

    11、牵扯到验证码的,还要考虑文字是否扭曲过度导致辨认难度大,考虑颜色(色盲使用者),刷新或换一个按钮是否好用;

    三、安全性测试:

    1、密码是否隐蔽显示;

    在这里插入图片描述

    3、不能直接输入,就copy,是否数据检验出错;

    还要准确定位每一个输入框的功能,每一种错误情况下,出现的错误提示要准确或者合适。

    四、兼容性测试:

      1.不同浏览器测试
      2.浏览器不同版本测试
    

    五、其他测试点:

    1、输入框之间考虑tab键是否支持;

    2、登录按钮要考虑回车键是否支持;

    3、取消后的默认位置(一般为空白的用户名输入框);

    4、登录后的跳转页面是否正确(一般为首页);

    5、要考虑多次点击登录和取消按钮的界面反应;

    6、考虑是否支持多用户在同一机器上登录;

    7、考虑一用户在多台机器上登录;

    8、登录页面中的注册等链接是否正确

    展开全文
  • 软件测试常见的经典面试题

    万次阅读 多人点赞 2018-09-25 10:27:33
    分析需求,分解需求→制定测试计划→设计测试用例→执行测试用例→提交bug→验证bug→测试报告→测试总结 具体的可根据自己公司的情况作删减。 2、测试用例设计的方法有哪些?平时工作中怎么运用? (1)等价类...

    1、介绍公司的测试流程?

    分析需求,分解需求→制定测试计划→设计测试用例→执行测试用例→提交bug→验证bug→测试报告→测试总结

    具体的可根据自己公司的情况作删减。

    2、测试用例设计的方法有哪些?平时工作中怎么运用?

    (1)等价类划分法:无效、有效,划分数据

    (2)边界值法:划分数据

    (3)错误推测法:凭借经验来感知bug高发区

    (4)因果图法:又称为组合法,条件组合

    (5)场景法

    3、给你一个案例,让你设计测试用例,例如:笔、杯子、电梯

    假设设计的是电梯的测试用例,回答思路是反问面试官电梯的用途,放在什么地方?容量是什么?如果面试官给出具体的需求,就按照需求设计,如果面试官说的是随便,就自己假设。假设是万达商城的电梯,12个人/800kg。

    重点是让面试官看到你的思路,关注需求是很重要的一点。

    4、公司的bug管理流程

    发现bug→确认是否是bug→定位bug→提交bug→验证bug→测试报告→bug总结

    5、在工作中发现了多少bug?哪些bug比较深刻?

    可以回答具体的记不太清了,但是有些印象深刻的bug。

    平时在发现的bug的时候多尝试着定位bug,而不是盲目的提bug,这样才会在脑海里产生印象深刻的bug。

    6、在一个版本的测试中,编写过多少测试用例/执行过多少测试用例?

    一个星期写一两百个测试用例很正常

    7、测试中发现bug,开发不认账,你怎么办?

    考核点:

    第一,bug管理流程;(发现bug→确认是否是bug→定位bug)

    第二,提供复现环境,是bug就一定要提,改不改是开发部门决定的,提不提是测试部门决定的,体现了你是个有原则的测试;

    第三,沟通技巧

     

     

    在测试的过程中,千万不要因为追求bug数,而忘记去深入了解bug,定位bug。这是作为一个测试人员提升的一个关键点。

    展开全文
  • 软件测试总结——常见的面试问题(一)

    万次阅读 多人点赞 2019-12-04 11:36:59
    1.软件测试级别? 单元测试:单元测试是...(测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试) 集成测试:(集成测试也称联合测试、组装测试,将程序模块采用适当的集成策略组装起...

    1.软件测试级别?

    单元测试:单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。Findyou又称为模块测试一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。(测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试


    集成测试:集成测试也称联合测试、组装测试,将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。测试内容:模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响


    系统测试:将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等


    验收测试:验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段,也称为交付测试。总结验收测试的目的是确保软件准备就绪,按照项目合同、任务书、双方约定的验收依据文档,向软件购买都展示该软件系统满足原始需求。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务即软件的功能和性能如同用户所合理期待的那样。测试内容:同系统测试(功能...各类文档等)

     

     

    2.软件测试类型?

    功能测试:也叫黑盒测试,功能测试指测试软件各个功能模块是否正确,逻辑是否正确。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面(GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。

    性能测试:指验证软件的性能可以满足系统规格给定的指定要求的性能指标。性能测试是一个比较大的范围,可以进一步衍生出负载测试、强度测试、压力测试、稳定性测试。通过自动化测试工具模拟多种正常、异常、峰值条件,对系统各项性能指标测试

    配置测试:用硬件来测试软件运行情况,1.软件在不同主机上运行的情况(Apple和Dell)2.在不同组件上运行情况(开发的拨号程序要测试不同厂商生产的Moden上运行情况)3.不同的外设、接口、内存的运行情况

    强度测试:强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

    负载测试通过在被测系统上不断加压,直到性能指标达到极限,例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    压力测试:压力测试方法测试系统在一定饱和状态下,例如cpu、内存在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误。测试出系统所能承受的最大极限。是指系统在极限下的压力情况,系统在什么样的压力下会导致系统得到失效,无法正常运行。100个用户连续访问1小时可以看做是压力测试,连续访问10小时可以认为是负载测试

    稳定性测试:压力测试方法测试系统在一定饱和状态下,例如cpu、内存在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误。一般是稍大于业务量的一个负载,对系统进行的一个持续的,长时间的测试,比如24*3,连续3天的施加压力,确定系统在较长运行时间的情况下,系统的稳定性情况

    网络测试:wifi、4G、3G、不同运营商网络测试、

    UI界面测试:UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等。

    分辨率测试:测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    安装测试:安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。

    内存测试:CPU测试、响应时间测试、唤醒率测试等,都属于性能测试。还有强度测试、容量测试、基准测试等。

    文档测试:文档测试是检验样品用户文档的完整性、正确性、一致性、易理解性、易浏览性。包括用户手册、使用说明、用户帮助文档等

    可靠性测试:这个主要是硬件方面的,比如高低温测试、防水防尘等测试

    安全测试:对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网管、关来访问。比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    兼容测试检查软件在不同软件、硬件平台是否可以正常运行。 主要查看在不同操作系统、浏览器、数据库、不同版本是否正常运行、向前兼容和向后兼容、、数据共享兼容

    浏览器兼容性测试:测试软件在不同产商的浏览器下是否能够正确显示与运行、比如测试IE,Natscape浏览器

    操作系统兼容性:测试软件在不同操作系统下是否能够正确显示与运行;比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?

    硬件兼容性

    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用。比如在INTER,舒龙CPU芯片下系统是否能够正常运行?

    并发测试并发测试方法通过模拟用户并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。也就是说,这种测试关注点是多个用户同时(并发)对一个模块或操作进行加压。

     

     

     

     

    3.测试方法:动态测试、静态测试;黑盒测试、白盒测试、灰盒测试。

    、黑盒测试方法:

    1>等价类划分:等价类划分是将系统的输入域划分为若干部分,然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类,设计测试用例的时候要考虑这两种等价类。

    2>边界值分析法:边界值分析法是对等价类划分的一种补充,因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上,如果边界附件取值不会导致程序出错,

    那其他取值出错的可能性也就很小。

      边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试,因此该方法要和等价类划分法结合使用。

    3>错误猜测法:错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法,从而设计测试用例

    3、白盒测试方法:

    1>语句覆盖:就是设计若干个测试用例,运行被测程序,使得每一个可执行语句至少执行一次。

    2>判定覆盖:使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。

    3>条件覆盖:条件覆盖是指选择足够的测试用例,使得运行这些测试用例时,判定中每个条件的所有可能结果至少出现一次,但未必能覆盖全部分支

    4>判定条件覆盖:判定-条件覆盖就是设计足够的测试用例,使得判断中每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果至少执行,即要求各个判断的所有可能的条件取值组合至少执行一次。

    5>条件组合覆盖:在白盒测试法中,选择足够的测试用例,使所有判定中各条件判断结果的所有组合至少出现一次,满足这种覆盖标准成为条件组合覆盖。

    6>路径覆盖:是每条可能执行到的路径至少执行一次

    灰盒测试
    定义:介于黑、白盒测试之间的,关注输出对于输入的正确性,同时也关注内部表现

    静态测试
    1,静态测试是指无需执行被测程序,而是通过评审软件文档或代码,度量程序静态复杂度,检查软件是否符合编程标准,借以发现编写的程序的不足之处,减少错误出现的概率


    动态测试
    1,动态测试是指通过运行被测程序,检查运行结果和预期结果的差异,并分析运行效率,正确性和健壮性等

    2,静态(看外观)和动态(发动车走一段路)可以用买车来说明


    手工测试
    由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。
    更适用针对深度的测试和强调主观判断的测试
    比如:众包测试和探索式测试

    自动化测试
    1.适用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。

    2.手工测试和自动化测试的区别?

    手动测试:优点:易发现缺陷、容易实施、灵活性     缺点:覆盖量低、重复测试效率低、可靠性低、人力资源依赖

    自动化测试:优点:高效率,速度快、高复用性、覆盖率高、准确可靠、不知疲劳     缺点:机械发现缺陷率低、一次性投入大

     安全测试

    安全测试是在IT软件产品的生命周期中,特别是产品开发基本完成到发布阶段,对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。

    Findyou觉现在对安全知识的普及,大家意识都提上来了。比如现在越来越多的不支持HTTP协议,转用HTTPS等。

    探索性测试

    探索性测试可以是一种测试思维技术。它没有很多实际的测试方法、技术和工具,但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性,抛弃繁杂的测试计划和测试用例设计过程,强调在碰到问题时及时改变测试策略

    随机测试

    随机测试主要是根据测试者的经验对软件进行功能和性能抽查。

    根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。

    冒烟测试

    关于冒烟测试,就是开发人员在个人版本的软件上执行目前的冒烟测试项目,确定新的程序代码不出故障。冒烟测试目的是确认软件基本功能正常,现基本执行对象为测试人员,在正规测试一个新版本之前,投入较少的人力和时间验证基本功能,通过则测试准入。

    α测试

    α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

    大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。

    β测试

    Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。

     

     

    4.alpha测试和beta测试的区别

    1、测试时间不同:

    Beta测试是软件产品完成了功能测试和系统测试之后,产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段。

    alpha测试简称“α测试”,可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

    2、测试的目的不同:

    α测试的目的是评价软件产品的(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试即为非正式验收测试。

    Beta测试是一种验收测试,通过了验收测试,产品就会进入发布阶段。

    测试人员及场所不同:

    α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,α测试不能由程序员或测试员完成。α测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。

    Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场,因Beta测试是软件在开发者不能控制的环境中的“真实”应用。

     

     

    5.测试设计方法:

    等价类划分、边界值、因果图划分、正交、场景、随机、错误推断、测试大纲

    等价类划分法: :  1:有效等价类:   2:无效等价类:

    案例:比如一个登陆输入框,规定只能输入中文,同时长度为6-10,

    通过等价类设计测试用例:

    测试用例中重要的三步: 输入 操作 预计结果 如果与预期结果不符合就是bug

    有效等价类: 输入:输入长度为6的中文,输入的为王小明,这就是有效等价类

    无效等价类:

    1: 输入长度为4的中文,输入位小名,点击登录,预计结果长度不符合要求

    2: 输入长度为6,但是是英文的,点击登录,预计结果 请输入中文

    3: 输入长度为4,而且不是中文的,是数字,1234,点击登录,预计结果请输入中文并且长度为6-10位

    4:输入长度为12而且不是中文的,比如qwertyuiopas,点击登录,预计结果请输入中文并且长度为6-10位

     

    二:边界值法:

    应用场景:边界值往往和等价类划分法一起使用,形成一套更为完善的测试方案,找到有效数据和无效数据的分界点,

    注解边界值一般和有效等价类划分法配合使用:

    案例:比如一个登陆输入框,规定只能输入中文,同时长度为6-10,

    上面输入框的边界的:如果固定大于等于6,并且小于等于10,

    那左边界就是 5和 6

    右边界是:10 和 11

    测试用例:

    1:输入的为王小明,这就是有效等价类和边界值的结合使用

    2:输入小名,这就是边界值为5,同时有效等价类

    3:输入欧阳致远家,这就是边界值10,同时等价类有效

    4:输入欧阳致远啦啦,这就是边界值为11,同时有效等价类

     

    三:因果图及判定表法:

     

    应用场景:在一个界面中有多个控件,如果控件之间有组合关系或者限制关系,不同的控件组合会产生不同的输入结果,为了弄清楚不同的输入组合会产生咋样的输出结果,可以使用因果图及判定表法:

    判断是儿童还是青年还是成年人:

    条件1:年龄 age

    条件2:身高height

    条件3:体重weight

    输入年龄5,体重80公斤,身高170,查无此人

    输入提高80,身高170,输入年龄20,成年人

    输入年龄5,体重30,身高60,小孩

     

    四:正交表:

    应用场景:在一个界面中有多个控件,每个控件有多个取值,测试时考虑不同的控件不同取值之间的多种组合,但组合数量巨大(>20种,20种以下一般考虑判定表因果图),没有必要全部测试,如何从所有的组合中挑选最少、最优的组合进行测试,可以使用正交排列法。

    正交表的测试思想特点:

    1)使用每个控件的每个取值参与组合的次数是基本相等的(均匀的)

    2)在所有的组合数据中,选取数据时,应该均匀的选取,而不能从局部选取。

    3)如果时间允许,尽可能的多测一些组合

    正交表:主要针对一个输入框里面可能有多个值,而且数量巨大

    年龄 体重 省 市 县

    比如:输入年龄 18,体重45,山西 大同 阳高

    五:测试大纲法

    适用场合:程序包含多个窗口,每个窗口中又有多个功能,这些功能之间又有一定的联系。为了梳理清楚窗口之间以及窗口不同功能之间的联系,使用测试大纲法。

    六:场景法

    适用场合:大多数的业务比较复杂的软件系统都适合使用场景法(便于将各个功能点串起来,便于形成完整的业务感觉)是一种基于软件业务的测试方法,把自己当成最终用户,尽可能的模拟用户在使用此软件的操作

    案例:

    场景一:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击支付,支付成功

    场景二:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击取消支付

    七: 错误推断法

    基于经验和直觉推测程序中所有可能存在的各种错误 , 从而有针对性的设 计测试用例的方法

    在进行灰盒测试的时候经常用到此方法

    八:随机测试

    随意测试,不考虑任何用例和需求,完全站在一个用户或者的角度对产品进行使用。

    适用场景:

    1) 所有之前设定的用例已经 执行完毕

    2)海量的条件组合无法一遍 历的时候

     

    6.软件测试风险:

    测试人员:业务不熟、人员变动、疲态、同化效应、定位效应

    测试材料:需求变更、质量标准不一样、测试用例或测试数据设计不充分

    测试环境:测试软件版本不统一、软件环境不统一、硬件环境不统一、硬件不到位

    测试时间:测试时间不足、测试时间延长

    测试方法:错误或缺失测试方法、场景缺失、测试用例实施不充分

     

     

    7.自动化测试软件作用(重点):

    一:jmeter: 纯java编写负载功能测试和性能测试开源工具, 支持接口自动化测试,录制、抓包、可进行压力测试(增加线程,考验服务器最大支持访问数)、弱网测试、添加请求、添加断言,查看断言、结果树,聚合报告,分析测试报告等

    聚合报告参数详解: 
    1. Label:每个 JMeter 的 element(例如 HTTP Request)都有一个 Name 属性,这里显示的就是 Name 属性的值 
    2. Samples:请求数——表示这次测试中一共发出了多少个请求,如果模拟10个用户,每个用户迭代10次,那么这里显示100 
    3. Average:平均响应时间——默认情况下是单个 Request 的平均响应时间
    4. Median:中位数,也就是 50% 用户的响应时间 
    5. 90% Line:90% 用户的响应时间 
    6. Min:最小响应时间 
    7. Max:最大响应时间 
    8. Error%:错误率——错误请求数/请求总数 
    9. Throughput:吞吐量——默认情况下表示每秒完成的请求数(Request per Second)
    10. KB/Sec:每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec

     

    :ant: 将软件编译、测试、部署等步骤联系在一起加以自动化的一个工具,并生成测试报告并发送

     

    三:jenkins: Jenkins是一个开源CI服务器,基于Web访问,jenkins是基于Java开发的一种持续集成工具,用于监控持续重复的工作,能实时监控集成中存在的错误,提供详细的日志文件和提醒功能,还能用图表的形式形象地展示项目构建的趋势和稳定性,拥有大量的插件:这些插件极大的扩展了Jenkins的功能,持续集成工具,所有工作都是自动完成的,无需太多的人工干预,有利于减少重复过程以节省时间和工作量;

     

    :monkey:它是Android SDK系统自带一个命令行工具,可以运行在模拟器里或者真是设备中运行。向系统发送伪随机的用户事件流,实现对正在开发的应用程序进行稳定性测试。

     

    五:charles: 1.抓包(http、https):设置手机HTTP代理、https  charles也需要证书

    2.弱网测试:通过Throttle Settings(网络控制)、Enable Throttling(启用设置)、Throttle preset(通过预设网络值来拟定网络)、设置网络带宽值等

    3.网络请求的截取并动态修改:

    4.压力测试:通过右键点击链接,Repeat Advanced(重复),选择Iterations(重复次数)Concurrency(并发数)

    5.数据替换:通过链接右键点击Map Local(本地位置)进入设置,选择替换数据文件,替换即可

     

    :selenium :web自动化测试框架(测试浏览器兼容性的自动化)selenium不支持桌面软件自动化测试。软件测试报告,和用例管理只能依赖第三方插件unittest优点:兼容更多的平台( Windows、Linux 、 Macintosh等)以及浏览器(火狐,IE,谷歌等)

    定位元素方式:id、name、class_name、tagname、link_text、partial_link_text、xpath、css_selector

    强制等待:sleep()强制等待,不管你浏览器是否加载完,程序都得等待

    显示等待:WebDriverWait,配合该类的until()和until_not()方法,就能够根据判断条件而进行灵活地等待了.它主要的意思就是:程序每隔多久查看一次,如果条件成立了,则执行下一步,否则继续等待,直到超过设置的最长时间,然后抛出TimeoutException

    隐式等待:implicitly_wait(),整个driver周期有效,如果在规定时间内网页加载完成,则执行下一步,否则一直等到时间截止

     

    :appium:开源测试自动化框架,可用于原生,混合和移动Web应用程序测试

    两大组件:

    一:Appium Server就是Appium的服务端——一个web接口服务,使用Node.js实现。

    二:Appium Desktop是一款适用于Mac,Windows和Linux的开源应用程序,提供Appium自动化服务器的强大功能。

    Appium GUI是Appium desktop的前身。 也就是把Appium server封装成了一个图形界面,降低了使用门槛。

    因为Appium是一个C/S结构,有了服务端的肯定还有客户端,Appium Clients就是客户端,它会给服务端Appium Server发送请求会话来执行自动化任务。

    Appium-desktop主界面包含三个菜单:

    Simple

    • host:设置Appium server的ip地址,本地调试可以将ip地址修改为127.0.0.1
    • port:设置端口号,默认是4723不用修改
    • start server:启动 Appium server

    Advanced:高级参数配置修改,主要是Android和iOS设备,log路径等相关信息的配置。

    Presets:将Advanced中的一些配置信息作为预设配置。
     

     

    :pytest:pytest是一个全功能的Python测试框架,

    优点:

    • 1、简单灵活,容易上手,文档丰富;
    • 2、支持参数化,可以细粒度地控制要测试的测试用例;
    • 3、能够支持简单的单元测试和复杂的功能测试,还可以用来做selenium/appnium等自动化测试、接口自动化测试(pytest+requests);
    • 4、pytest具有很多第三方插件,并且可以自定义扩展,比较好用的如pytest-selenium(集成selenium)、pytest-html(完美html测试报告生成)、pytest-rerunfailures(失败case重复执行)、pytest-xdist(多CPU分发)等;
    • 5、测试用例的skip和xfail处理;
    • 6、可以很好的和CI工具结合,例如jenkins

    编写规则:

    • 测试文件以test_开头(以_test结尾也可以)
    • 测试类以Test开头,并且不能带有 init 方法
    • 测试函数以test_开头
    • 断言使用基本的assert即可
    # -*- coding:utf-8 -*-
    import pytest
    
    @pytest.fixture(scope='function')
    def setup_function(request):
        def teardown_function():
            print("teardown_function called.")
        request.addfinalizer(teardown_function)  # 此内嵌函数做teardown工作
        print('setup_function called.')
    
    @pytest.fixture(scope='module')
    def setup_module(request):
        def teardown_module():
            print("teardown_module called.")
        request.addfinalizer(teardown_module)
        print('setup_module called.')
    
    @pytest.mark.website
    def test_1(setup_function):
        print('Test_1 called.')
    
    def test_2(setup_module):
        print('Test_2 called.')
    
    def test_3(setup_module):
        print('Test_3 called.')
        assert 2==1+1              # 通过assert断言确认测试结果是否符合预期

    fixture的scope参数

    scope参数有四种,分别是'function','module','class','session',默认为function。

    • function:每个test都运行,默认是function的scope
    • class:每个class的所有test只运行一次
    • module:每个module的所有test只运行一次
    • session:每个session只运行一次

    setup和teardown操作

    • setup,在测试函数或类之前执行,完成准备工作,例如数据库链接、测试数据、打开文件等
    • teardown,在测试函数或类之后执行,完成收尾工作,例如断开数据库链接、回收内存资源等
    • 备注:也可以通过在fixture函数中通过yield实现setup和teardown功能

     

    :unitest: unittest单元测试框架不仅可以适用于单元测试,还可以适用WEB自动化测试用例的开发与执行,该测试框架可组织执行测试用例,并且提供了丰富的断言方法,判断测试用例是否通过,最终生成测试结果

    unittest.TestCase:TestCase类,所有测试用例类继承的基本类:       class BaiduTest(unittest.TestCase)

    unittest.main():将一个单元测试模块变为可直接运行的测试脚本,main()方法使用TestLoader类来搜索所有包含在该模块中以“test”命名开头的测试方法并自动执行他们。

    unittest.TestSuite():unittest框架的TestSuite()类是用来创建测试套件的。

    unittest.TextTextRunner():unittest框架的TextTextRunner()类,通过该类下面的run()方法来运行suite所组装的测试用例。

    unittest.defaultTestLoader(): defaultTestLoader()类,通过该类下面的discover()方法可自动更具测试目录start_dir匹配查找测试用例文件(test*.py),并将查找到的测试用例组装到测试套件,因此可以直接通过run()方法执行discover。用法如下:discover=unittest.defaultTestLoader.discover(test_dir, pattern='test_*.py')

    unittest.skip():装饰器,当运行用例时,有些用例可能不想执行等,可用装饰器暂时屏蔽该条测试用例。一种常见的用法就是比如说想调试某一个测试用例,想先屏蔽其他用例就可以用装饰器屏蔽。

    TestCase类的属性:

    setUp():setUp()方法用于测试用例执行前的初始化工作。如测试用例中需要访问数据库,可以在setUp中建立数据库连接并进行初始化。如测试用例需要登录web,可以先实例化浏览器。

    tearDown():tearDown()方法用于测试用例执行之后的善后工作。如关闭数据库连接。关闭浏览器。

    assert*():一些断言方法:在执行测试用例的过程中,最终用例是否执行通过,是通过判断测试得到的实际结果和预期结果是否相等决定的。

    TestSuite类的属性:

    addTest(): addTest()方法是将测试用例添加到测试套件中,是将test_baidu模块下的BaiduTest类下的test_baidu测试用例添加到测试套件。   suite = unittest.TestSuite()                  suite.addTest(test_baidu.BaiduTest('test_baidu'))

    TextTextRunner的属性:

    run(): run()方法是运行测试套件的测试用例,入参为suite测试套件:    runner = unittest.TextTestRunner() runner.run(suite)

     

    微信朋友圈测试用例:

    这里写图片描述

     

    8.po模型?

    selenium自动用例脚本,相似功能地方,代码基本都是一样的,界面元素换个查找方式,把原来的使用 xpath方式,改为使用 id 查找,需要对每个用例脚本都要改,虽然几个用例看不出什么工作量,但是重复findElement的代码,已经让我们感到了代码的笨重。如果某些定位发生了改变,我们就得贯穿整个测试代码进行调整元素定位,这样就会导致我们的脚本在后期,难以维护。
    因此通过Page Object Model 我们可以创建更加健壮代码,并减少或者消除重复的测试代码,从而也能够提高代码的可读性,减少编写脚本的工作量。Page Object Model的实现,就是通过分离测试对象和测试脚本的抽象来实现的。简单来说就是代码的封装,将测试方法进行封装对外暴露方法实现调用,在调用界面直接调用某个方法输入具体元素值以及内容。

     

     

    9.Bug的生命周期?新建,提交,确认,分配,修复,验证,关闭

     

    10.软件开发过程中的角色分工?(测试的主要工作)

    测试配合开发等进行需求分析和讨论,根据需求说明书指定《项目测试计划》,编写测试用例,建立测试环境。

    测试负责新产品测试,原有产品的升级测试,负责软件问题解决过程跟踪,软件开发文档、开发工作的规范化,管理开发部        门的产品文档,制作用户手册、操作手册,产品上限测试,监督软件开发过程执行,提高软件质量。

     

    11.缺陷(bug)等级分类?       

    致命:测试过程死机、系统崩溃、数据跌势、功能没有实现

    严重:导致软件功能不稳定、功能实现错误、流程错误

    一般:校验错误、罕见故障、错别字,不影响功能,影响体验

    低级:没影响的小问题

     

    12.使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程?

     

    答:1) 测试人员或开发人员发现bug后,判断属于哪个模块的问题,填写bug报告后,系统会自动通过Email通知项目组长或直接通知开发者。
    2) 经验证无误后,修改状态为VERIFIED(已证实).待整个产品发布后,修改为CLOSED(关闭)
    3) 还有问题,REOPENED(重新打开),状态重新变为“New",并发邮件通知。
    4) 项目组长根据具体情况,重新分配给bug所属的开发者。
    5) 若是,进行处理,断言并给出解决方法。(可创建补丁附件及补充说明)
    6) 开发者收到Email信息后,判断是否为自己的修改范围。
    7) 若不是,重新分配给项目组长或应该分配的开发者。
    8) 测试人员查询开发者已修改的bug,进行重新测试。确认无误后,关闭该bug。

     

     

    13.缺陷报告由哪些组成?(测试报告,测试用例)

       缺陷编号、日期、缺陷标题、 缺陷优先程度、缺陷所属模块、缺陷所属版本、执行流程、预计结果、输出结果、缺陷分析、缺陷所属开发    人员、缺陷描述缺陷有限等级等。提高质量:要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认肯定,然后再向外发布如此才能提高提交 Bug 的质量。

    测试报告:项目说明 测试依据 人员及进度 测试概要 测试环境 测试用例 测试方法 覆盖分析 需求覆盖 测试覆盖

     

    14.如何设计测试用例?

          测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。检验是否满足客户需求;度量测试人员的工作量;展现测试用例的思路。

         测试用例包含:

         用例编号    唯一的编号。
         用例标题    当前测试用例的用途
         测试背景    这个用例属于哪个项目
         前置条件    用例执行前应该满足哪些条件
         重要级别    定义优先级,分为高低级别
         测试数据     具体输入内容
         测试步骤    每步做些什么
         预期结果     需求文档要求结果
         实际结果     实际输出结果
         备注     

         测试用例编写流程:需求分析--》提取测试点--》测试用例编写--》测试用例评审

         测试用例常用设计方法:等价类划分法、  边界值分析法、因果图法、场景法、正交表、测试大纲法、错误推断法、随机测试

       

    15.测试计划编写:

    编写测试计:      测试环境准备、     第一次功能测试、   性能测试、  回归测试、    测试报告总结  

    1. 测试目标:根据xxx需求,提炼测试功能点、制定测试策略、评估测试 风险,预估编写测试用例、执行功能测试和回归测试的工作量,进行人员和进度 安排。

    2. 测试范围:功能模块:(需要结合实际情况)

    3. 测试策略:对需求中的功能改进进行完整测试,并根据应用场景和并发数考虑兼容性和性能测试方案。 并需要指定出测试工具

    3.1 功能测试:见测试用例表

    3.2 性能测试
    3.3 系统兼容性测试
    4. 测试资源
    4.1 人员安排
    4.2 测试环境
    4.3 bug管理
    5试进度安排:任务    时间    执行人员    工作量         
    5.2输出文档:测试计划、测试报告
    6测试验收标准:1.完成所有类型测试 ,没有影响到用户业务使用的bug ,bug数量少于一定数量  , 功能业务,性能指标符合需求

    6.2 产品上线标准:产品 checkelist

    1. 已按照交互文档、需求文档完全的实现需求;
    2.  符合交互稿的交互设计规范、符合视觉要求,已经通过设计评审;
    3.  允许遗留可能会对用户正常使用造成一定影响的正常级缺陷,但应在发布前告知项目组,并经风险评估同意发布后方可发布

    7. 风险说明
    主要包括三个方面:1.测试范围风险 (测试遗漏,需求变更)、2.测试进度风险(预估量不准确,测试人员变动,其他业务工作,)、3.产品质量风险(代码质量,测试人员能力)

     

    16.软件测试的原则:

    1.测试软件存在缺陷。证明测试对象是有缺陷的。

    2.测试尽早介入,缺陷发现越早,修复成本越小。

    3.不可进行穷尽测试(无意义测试)。

    4.缺陷集群性(2/8原则)80%的缺陷发现在20%的模块中。

    5.杀虫剂悖论,如果一直使用相同的测试方法或手段,可能无法发现新的bug。

    6.测试环境的特殊新,测试活动依赖测试内容,不同的行业,测试活动的开展都有所不同,比如测试技术、测试工具的选择,测试流程都不尽相同,所以软件测试的活动开展依赖于所测试的内容

    7.不存在缺陷谬论,软件测试不仅是找出缺陷,同时也需要确认软件是否满足需求。

     

    17.简述集成测试的环境?

    1.硬件环境: 集成测试时,要尽可能的考虑用户使用的实际环境;当实际环境难以达到的时候,模拟环境考虑到与实际环境之间                        可能存在的差异。

    2.操作系统环境:考虑到不同的操作系统版本,对于可能使用的操作系统环境,要尽可能的测试到。

    3.数据库环境:数据库的选择合乎实际情况。容量,性能,版本等多方面考虑。

    4.网络环境:一般的网络环境可以使用以太网、wifi、3G、4G。

     

    18.集成测试通常都有那些策略?

    大爆炸集成
    2、自顶向下集成
    3、自底向上集成
    4、三明治集成适应于大部分软件开发项目
    5、基干集成
    6、分层集成
    7、基于功能的集成
    8、基于消息的集成
    9、基于风险的集成
    10、基于进度的集成

     

    19.测试策略:

    功能测试,性能测试,压力测试,容量测试,安全性测试,GUI测试,可用性测试,安装测试,配置测试,
    异常测试,备份测试,健壮性测试,文档测试,在线帮助测试,网络测试,稳定性测试
    在:正常情况下测试;非正常情况下测试;边界测试;非法,极端测试;

     

    20.什么是测试脚本?

    测试脚本是为了进行自动化测试而编写的脚本,测试脚本的编写必须对应相应的测试用例

    测试脚本是一段代码不假。但是这段代码可能是为了执行某一条,或很多条测试用例而写的。也有可能 ,本身就是一条用例。

    用例本身并不局限,在基于功能。脚本和用例没有并列的可比性。脚本可能是用例,也可能是执行用例用的功能。用例也可能是脚本。

     

    21.软件产品质量特性是什么? ?


    功能性:适应性、准确性、互操作性、依从性、安全性。
    可使用性:易理解性、易学习性、易操作性。
    效率:时间特性、资源特性。
    可维护性:易分析性、易变更性、稳定性、易测试性。
    可移植性: 适应性、易安装性、遵循性、易替换性。

     

    22. 一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压,有什么区别?

    300个用户在一个客户端上,会占用客户机更多的资源,而影响测试的结果。线程之间可能发生干扰,而产生一些异常。300个用户在一个客户端上,需要更大的带宽。
    IP地址的问题,可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。
    所有用户在一个客户端上,不必考虑分布式管理的问题;而用户分布在不同的客户端上,需要考虑使用控制器来整体调配不同客户机上的用户。同时,还需要给予相应的权限配置和防火墙设置。

     

     

    23.使用QTP做功能测试,录制脚本的时候,要验证多个用户的登录情况/查询情况,如何操作?

    分析用户登录的基本情况,得出一组数据,通过性测试/失败性测试的都有(根据TC来设计这些数据),然后录制登录的脚本,将关键的数据参数化,修改脚本,对代码进行加强,调试脚本。

    QTP中的action主要是用来管理代码的,Action的作用 1)用Action可以对步骤集进行分组 2)步骤重组,然后被整体调用 3)拥有自己的sheet 4)组合有相同需求的步骤,整体操作 5)具有独立的对象仓库

     

     

    24.TestDirector有些什么功能,如何对软件测试过程进行管理?

    管理测试需求,测试计划以及缺陷跟踪分析,主要有五个模块:1.服务测试管理器、2.需求管理器、3.测试实验室、4.缺陷管理器、5.测试计划  保证各阶段之间顺畅的信息流,完全基于Web。

    业务分析员:定义应用程序需求和测试目标

    QA测试员:运用手动和自动测试,报告执行测试结果,输入缺陷

    开发人员:数据库查看和解决缺陷

    测试经理和项目经理:设计测试计划,开发测试案例

    产品经理:决定是否准备发布应用

     

     

    25.测试自动化和自动化测试的区别?

    什么是测试自动化:这是一种让测试过程脱离人工的一次变革。对于控制成本,控制质量,回溯质量和减少测试周期都有积极影响的一种研发过程。


    什么是自动化测试:通过将测试执行部分部分或者全部交由机器执行的一种测试,叫做自动化测试。这种测试不需要人的实时参与。同时这种测试在小规模应用时会比手动测试昂贵许多。
    自动化测试可以看作测试自动化的一部分。


    一个自动化工程师,会比较专注于测试工具的研发。最主要的是这个工程师会从成本的角度去考虑问题。这一点比较像PM。他所做的一切是为了减少自己或者团队的工作量,尽可能的将重复的,有规律可循的工作代码化,自动化。

    一个自动化测试工程师,会比较专注于测试代码的开发,以及测试结果的分析。对于被测设备本身非常感兴趣。他们比较倾向于一种完美主义者,追求的是高质量而经常忽略成本。这一点更像开发人员。

     

    26.公司的测试环境?

    开发环境:开发环境是程序猿们专门用于开发的服务器,配置可以比较随意, 为了开发调试方便,一般打开全部错误报告。

    测试环境:一般是克隆一份生产环境的配置,一个程序在测试环境工作不正常,那么肯定不能把它发布到生产机上。

    生产环境:是指正式提供对外服务的,一般会关掉错误报告,打开错误日志。可以理解为包含所有的功能的环境,任何项目所使用的环境都以这个为基础,然后根据客户的个性化需求来做调整或者修改。

    三个环境也可以说是系统开发的三个阶段:开发->测试->上线,其中生产环境也就是通常说的真实环境。

    UAT环境:UAT,(User Acceptance Test),用户接受度测试 即验收测试,所以UAT环境主要是用来作为客户体验的环境。

    仿真环境:顾名思义是和真正使用的环境一样的环境(即已经出售给客户的系统所在环境,也成为商用环境),所有的配置,页面展示等都应该和商家正在使用的一样,差别只在环境的性能方面。

     

    27.公司做安全测试是怎么进行的?

    软件安全性测试主要包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

    详细的测试点:
    1.跨网站脚本攻击:通过脚本语言的缺陷模拟合法用户,控制其账户,盗窃敏感数据
    2.注入攻击:通过构造查询对数据库、LDAP和其他系统进行非法查询
    3.恶意文件执行:在服务器上执行Shell 命令Execute,获取控制权
    4.伪造跨站点请求:发起Blind 请求,模拟合法用户,要求转账等请求
    5.不安全对象引用:不安全对象的引入,访问敏感文件和资源,WEB应用返回敏感文件内容
    6.被破坏的认证和Session管理:验证Session token 保护措施,防止盗窃session
    7.Session的失效时间限制:Session的失效时间设置是否过长,会造成访问风险
    8.不安全的木马存储:过于简单的加密技术导致黑客破解编密码,隐秘信息被盗窃,验证其数据加密
    9.不安全的通讯:敏感信息在不安全通道中以非加密方式传送, 敏感信息被盗窃,验证其通讯的安全性
    10.URL访问限制失效:验证是否通过恶意手段访问非授权的资源链接,强行访问一些登陆网页,窃取敏感信息
    11.信息泄露和不正确错误处理测试:恶意系统检测,防止黑客用获取WEB站点的具体信息的攻击手段获取详细系统信息
    12.注册与登录测试:验证系统先注册后登录、验证登录用户名和密码匹配校验,密码长度及尝试登录次数,防止 非法用户登录
    13.超时限制:验证WEB应用系统需要有是否超时的限制,当用户长时间不做任何操作的时候,需要重新登录才能使用
    14.日志文件:验证服务器上日志是否正常工作,所有事务处理是否被记录
    15.目录文件:验证WEB服务器目录访问权限或者每个目录访问时有index.htm,防止 WEB 服务器处理不适当,将整个目录暴露
    16.身份验证:验证调用者身份、数据库身份、验证是否明确服务账户要求、是否强制式试用账户管理措施
    17.授权:验证如何向最终用户授权、如何在数据库中授权应用程序,确定访问系统资源权限
    18.会话:验证如何交换会话标识符、是否限制会话生存期、如何确保会话存储状态安全
    19.配置管理:验证是否支持远程管理、是否保证配置存储安全、是否隔离管理员特权
    20.备份与恢复:为了防止系统意外崩溃造成的数据丢失,验证备份与恢复功能正常实现、备份与恢复方式是否满足Web系统安全性要求
    21.数据库关键数据是否进行加密存储,是否在网络中传递敏感数据
    22.在登录或注册功能中是否有验证码存在,防止恶意大批量注册登录的攻击
    23.Cookie文件是否进行了加密存储,防止盗用cookie内容
    24.密码强度提醒:建议对密码的规则进行加强设置
    25.密码内容禁止拷贝粘贴

     

    用户身份认证安全的测试要考虑问题:
    1.明确区分系统中不同用户权限
    2.系统中会不会出现用户冲突
    3.系统会不会因用户的权限的改变造成混乱
    4.用户登陆密码是否是可见、可复制
    5.系统的密码策略,通常涉及到隐私,钱财或机密性的系统必须设置高可用的密码策略。
    5.是否可以通过绝对途径登陆系统(拷贝用户登陆后的链接直接进入系统)
    6.用户推出系统后是否删除了所有鉴权标记,是否可以使用后退键而不通过输入口令进入系统

    系统网络安全的测试要考虑问题:
    1.测试采取的防护措施是否正确装配好,有关系统的补丁是否打上
    2.模拟非授权攻击,看防护系统是否坚固
    3.采用成熟的网络漏洞检查工具检查系统相关漏洞(即用最专业的黑客攻击工具攻击试一下,现在最常用的是 NBSI系列和 IPhacker IP )
    4.采用各种木马检查工具检查系统木马情况
    5.采用各种防外挂工具检查系统各组程序的客外挂漏洞


    数据库安全考虑问题:
    1.系统数据是否机密(比如对银行系统,这一点就特别重要,一般的网站就没有太高要求)
    2.系统数据的完整性(我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整,对于这个系统的功能实现有了障碍)
    3.系统数据可管理性
    4.系统数据的独立性
    5.系统数据可备份和恢复能力(数据备份是否完整,可否恢复,恢复是否可以完整)

    浏览器安全
    同源策略:不同源的“document”或脚本,不能读取或者设置当前的“document”
    同源定义:host(域名,或者IP),port(端口号),protocol(协议)三者一致才属于同源。
    要注意的是,同源策略只是一种策略,而非实现。这个策略被用于一些特定的点来保护web的安全。
    <script>,<img>,<iframe>,<link>等标签都可以跨域加载资源,不受同源策略的限制。
    XMLHttpRequest,DOM,cookie受到同源策略的限制。
    网站可以通过提供crossdomain.xml来允许某些源跨域访问自己的资源。
    google chrome使用了多进程来隔离代码运行的环境,从而起到提高web安全的作用
    Q & A
    Q:cookie为什么需要同源策略?
    A:cookie有同源策略是必须的,这样可以保证A网站的用户(识别)信息不会被B网站获取到
    Q:XMLHttpRequest为什么需要同源策略?
    A:两个例子:
    (1)加入没有同源策略,某个网站的某张页面被你写入了一些js ,这些js有些ajax操作,如果某个用户访问了这张页面,你的js就可以获得用户的某些信息(cookie,本地文件等)然后通过ajax发送回你的服务器。 这就是安全问题,信息泄漏。
    (2)先假设浏览器没有限制跨域,A站的xhr请求B站的一个url,那么浏览器是要带上谁家的cookie一起请求呢?(每次http请求都要带上该站下的所有cookie)显然是B家的。假设B家的网站当前用户已经登录,那么cookie里自然记录下了sessionId相关的东西以标识当前用户的身份,那么本次xhr请求很easy的通过了身份认证,然后后果就是不堪设想的。
    这个就很正确,如果A可以用xhr跨站访问B,带着B的cookie自然可以通过B网站的验证,从而获取到敏感数据。所以这点是关键。

    web安全测试方法:
    工具扫描
    目前web安全扫描器针对OSinjection, XSS、SQL injection 、OPEN redirect 、PHP File Include漏洞的检测技术已经比较成熟。
    商业软件web安全扫描器:有IBM Rational Appscan、WebInspect、Acunetix WVS 、burp suite免费的扫描器:W3af 、Skipfish 根据业务资金,可以考虑购买商业扫描软件,也可以使用免费的,各有各的好处。
    首页可以对网站进行大规模的扫描操作,工具扫描确认没有漏洞或者漏洞已经修复后,再进行以下手工检测。


    关于越权操作的问题
    例如A用户的个人资料ID为1 B用户个人资料ID为2,我通过登陆B用户,把ID修改为1 就可以查看到用户A的个人资料,这就是越权。
    测试方法:通过查看URL的get参数对那些类似明显的顺序数字 进行修改,看是否能越权访问。


    关于登陆安全的问题
    除了SQL注入,还有找回密码功能会出现安全问题
    邮箱找回密码测试方法:
    先从邮箱参数修改开始,看填入用户名和自己修改的邮箱账号,看是否能收到邮箱,收到后是否能修改。
    如果不能修改邮箱参数那么,我们就让它邮箱找回,接着点击邮箱内修改密码的链接,看链接的邮箱参数是否可以修改,用户名是否可以修改,加密的urlcode 是否可以逆向解密。
    如果是手机找回密码功能:则测试手机收到的验证码是否是纯数字、纯字母的,如果是请修改为字母与数字的组合。

    关于用开源程序的问题
    关注网上你所用的开源程序的官网更新情况和安全事件。


    关于上传:
    1.上传文件是否有格式限制,是否可以上传exe文件;
    2.上传文件是否有大小限制,上传太大的文件是否导致异常错误,上传0K的文件是否会导致异常错误,上传并不存在的文件是否会导致异常错误;
    3.通过修改扩展名的方式是否可以绕过格式限制,是否可以通过压包方式绕过格式限制;
    4.是否有上传空间的限制,是否可以超过空间所限制的大小,如将超过空间的大文件拆分上传是否会出现异常错误。
    5.上传文件大小大于本地剩余空间大小,是否会出现异常错误。
    6.关于上传是否成功的判断。上传过程中,中断。程序是否判断上传是否成功。
    7.对于文件名中带有中文字符,特殊字符等的文件上传。

     

    28.移动端测试:

    Android手机和IOS手机,系统有什么区别?
    1、两者运行机制不同:IOS采用的是沙盒运行机制,安卓采用的是虚拟机运行机制。
    2、两者后台制度不同:IOS中任何第三方程序都不能在后台运行;安卓中任何程序都能在后台运行,直到没有内存才会关闭。
    3、IOS中用于UI指令权限最高,安卓中数据处理指令权限最高。
     

    Android:

    1:使用灰盒进行功能测试

    2:使用fiddler或者Charles进行抓包测试

    3:兼容性测试,Android 从4.0版本的手机测试到9.0版本手机

    4:各大品牌的手机都的进行测试,比如:小米小米9 小米8 小米7 小米6 note 红米系列 7红米5,华为: 华为mate20 华为mate10,华为荣耀: 荣耀10,9,8 ,vivo: x21,27,23,oppo: R7,R9,R11,三星手机: note9, 8,7 S9,8。

    5:稳定性测试: 使用monkey命令进行稳定性测试

    6:专项测试,使用腾讯专项测试工具进行,测试耗电量,流量,CPU占用率

    7:性能测试,对app的接口进行性能测试,使用工具jmeter或者loadrunner

    8:对app接口进行接口测试,使用postman或者Jmeter都行

    9:如果有时间写自动化脚本

    ios:

    1:使用灰盒进行功能测试

    2:使用fiddler或者Charles进行抓包测试

    3:兼容性测试:ios版本测试从9-12,手机型号从4S测试到xmax

    4:性能测试接口和安卓的是一样的所以只需要进行一次就可以了

    5:专项测试:使用腾讯专项测试工具进行,测试耗电量,流量,CPU占用率

    6:编写自动化脚本

     

    29.web端测试:

    前端 :

    1:web也使用灰&测试方法

    2:兼容性测试:IE浏览器7-12,火狐浏览器 35-最新的,谷歌浏览器,别的浏览器有时间就可以测试

    3:对web端页面进行性能测试,使用jmeter或者loadrunner

    后端

    1:测试http接口

    2:测试https接口

    3:测试tcp接口

    4:测试dubbo接口

    5:对后台代码进行代码审核,进行白盒测试


     

    30.软件测试模型?

     

    1,传统的瀑布模型

    这里写图片描述

    瀑布模型的优缺点

    这里写图片描述

    2,V模型

    这里写图片描述

    3,W模型

    这里写图片描述

    4,X模型

    这里写图片描述

     

     

     

    31.在Windows上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?

    1、检查系统是否有中毒的特征                  2、检查软件/硬件的配置是否符合软件的推荐标准

    3、如果是C/S或者B/S结构的软件,需要检查是不是因为与服务器的连接问题或者访问问题造成的

    4、确认当前的系统是否是独立,是否存在负载,无对外提供消耗CPU资源的服务,查看性能监视器,确认应用程序对CPU/内存的访问情况

     

     

    32.MySQL外连接、内连接的区别?

    内连接 :连接的数据表相对应的匹配字段完全相等的连接。连接关键字是 inner join

    外连接:分为左外连接与右外连接、全连接。

    左连接的结果集包括指定的左表全部数据与匹配的右表数据,右表中没匹配的全为空值.关键字 left join

    右连接的结果集包含指定的右表全部数据与匹配的左边数据,左边中没匹配的全为空值.关键字 right join

    全连接返回左右数据表的所有行.关键字 full join

     

    33.测试通过的标准是什么?


    从微观上来说,在测试计划中定义,比如系统在一定性能下平稳运行 72 小时,目前 Bug
    Tracking System 中,本版本中没有一般严重的 BUG,普通 BUG 的数量在 3 以下,BUG 修复
    率 90%以上等等参数,然后由开发经理,测试经理,项目经理共同签字认同版本 Release。

     

    34.测试退出标准:

    单元测试退出标准

    1) 单元测试用例设计已经通过评审
    2) 核心代码100% 经过Code Review
    3) 单元测试功能覆盖率达到100%
    4) 单元测试代码行覆盖率不低于80%
    5) 所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准
    6) 不存在A、B类缺陷
    7) C、D、E类缺陷允许存在
    8) 按照单元测试用例完成了所有规定单元的测试
    9) 软件单元功能与设计一致


    集成测试退出标准

    1) 集成测试用例设计已经通过评审
    2) 所有源代码和可执行代码已经建立受控基线,纳入配置管理受控库,不经过审批不能随意更改
    3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
    4) 达到了测试计划中关于集成测试所规定的覆盖率的要求
    5) 集成工作版本满足设计定义的各项功能、性能要求
    6) 在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准
    7) A、B类BUG不能存在
    8) C、D类BUG允许存在,但不能超过单元测试总BUG的50%。
    9) E类BUG允许存在

    系统测试退出标准

    1) 系统测试用例设计已经通过评审
    2) 按照系统测试计划完成了系统测试
    3) 系统测试的功能覆盖率达100%
    4) 系统的功能和性能满足产品需求规格说明书的要求
    5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
    6) 系统测试后不存在A、B、C类缺陷
    7) D类缺陷允许存在,不超过总缺陷的5%
    8) E类缺陷允许存在,不超过总缺陷的10%
    注:这只是一套比较理想化的退出标准,但在实际工作中不可能达到这种程度,尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况了。

     

    39.查看LINUX进程内存占用

    1、lsof -i:端口号

    2、netstat -tunlp|grep 端口号都可以查看指定端口被哪个进程占用的情况

    查看所有端口、进程的使用情况:netstat -tunlp

    查看某一端口的使用情况:  netstat -tunlp|grep 5560

    在命令行中输入 “top”

      即可启动 top, top 的全屏对话模式可分为3部分:系统信息栏、命令输入栏、进程列表栏。

      第一部分 -- 最上部的 系统信息栏 :

      第一行(top):“00:11:04”为系统当前时刻;“3:35”为系统启动后到现在的运作时间;

        “2 users”为当前登录到系统的用户,更确切的说是登录到用户的终端数 -- 同一个用户同一时间对系统多个终端的连接将被视为多个用户连接到系统,这里的用户数也将表现为终端的数目;

        “load average”为当前系统负载的平均值,后面的三个值分别为1分钟前、5分钟前、15分钟前进程的平均数,一般的可以认为这个数值超过 CPU 数目时,CPU 将比较吃力的负载当前系统所包含的进程;

      第二行(Tasks):

        “59 total”为当前系统进程总数;

        “1 running”为当前运行中的进程数;

        “58 sleeping”为当前处于等待状态中的进程数;

        “0 stoped”为被停止的系统进程数;

        “0 zombie”为被复原的进程数;

      第三行(Cpus):分别表示了 CPU 当前的使用率;

      第四行(Mem):分别表示了内存总量、当前使用量、空闲内存量、以及缓冲使用中的内存量;

     

    35.数据库:mysql语句

        大型数据库   Oracle  Db2
          中型数据库    sqlserver  
          小型数据库    mysql
          微型数据库    sqlite

    增:Insert  into 表名 value 值

    删:Delect from 表名  where  值

    改:Update 表名 set 字段=字段 where 字段;

    查:Select * from 表名

    自增  auto_increment       
    主键  primary key
    非空  not null
    唯一 unique
    默认值  default
    外键  foreign key 

    1. # 查看所有的数据库: SHOW DATABASES ;

    2. # 创建一个数据库: CREATE DATABASE k;

    3. # 删除一个数据库: DROP DATABASE k;

    4. # 使用这个数据库  USE k;

    1. # 查看所有的表  SHOW TABLES ;

    2. # 创建一个表  CREATE TABLE n(id INT, name VARCHAR(10));

    3. CREATE TABLE m(id INT, name VARCHAR(10), PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES n(id), UNIQUE (name));

    4. CREATE TABLE m(id INT, name VARCHAR(10));

    5. # 直接将查询结果导入或复制到新创建的表 : CREATE TABLE n SELECT * FROM m;

    6. # 新创建的表与一个存在的表的数据结构类似:  CREATE TABLE m LIKE n;

    7. # 临时表将在你连接MySQL期间存在。当断开连接时,MySQL将自动删除表并释放所用的空间。也可手动删除。

    8. CREATE TEMPORARY TABLE l(id INT, name VARCHAR(10));

    9. # 直接将查询结果导入或复制到新创建的临时表  CREATE TEMPORARY TABLE tt SELECT * FROM n;

    10. # 删除一个存在表  DROP TABLE IF EXISTS m;

    11. # 更改存在表的名称

    12. ALTER TABLE n RENAME m;

    13. RENAME TABLE n TO m;

    14. # 查看表的结构(以下五条语句效果相同)

    15. DESC n; # 因为简单,所以建议使用

    16. DESCRIBE n;

    17. SHOW COLUMNS IN n;

    18. SHOW COLUMNS FROM n;

    19. EXPLAIN n;

    20. # 查看表的创建语句

    21. SHOW CREATE TABLE n;

    表的结构

    1. # 添加字段: ALTER TABLE n ADD age VARCHAR(2) ;

    2. # 删除字段: ALTER TABLE n DROP age;

    3. # 更改字段属性和属性:ALTER TABLE n CHANGE age a INT;

    4. # 只更改字段属性:ALTER TABLE n MODIFY age VARCHAR(7) ;

    表的数据

    1. # 增加数据

    2. INSERT INTO n VALUES (1, 'tom', '23'), (2, 'john', '22');

    3. INSERT INTO n SELECT * FROM n; # 把数据复制一遍重新插入

    4. # 删除数据:DELETE FROM n WHERE id = 2;

    5. # 更改数据:UPDATE n SET name = 'tom' WHERE id = 2;

    6. # 数据查找 : SELECT * FROM n WHERE name LIKE '%h%';

    7. # 数据排序(反序) :SELECT * FROM n ORDER BY name, id DESC ;

    1. # 添加主键:ALTER TABLE n ADD PRIMARY KEY (id);

    2. # 删除主键:ALTER TABLE n DROP PRIMARY KEY ;

    3. # 添加外键

    4. ALTER TABLE m ADD FOREIGN KEY (id) REFERENCES n(id); # 自动生成键名m_ibfk_1

    5. ALTER TABLE m ADD CONSTRAINT fk_id FOREIGN KEY (id) REFERENCES n(id); # 使用定义的键名fk_id

    6. # 删除外键:ALTER TABLE m DROP FOREIGN KEY `fk_id`;

    7. # 修改外键:ALTER TABLE m DROP FOREIGN KEY `fk_id`, ADD CONSTRAINT fk_id2 FOREIGN KEY (id) REFERENCES n(id); # 删除之后从新建

    联接

    1. # 内联接:SELECT * FROM m INNER JOIN n ON m.id = n.id;

    2. # 左外联接 :SELECT * FROM m LEFT JOIN n ON m.id = n.id;

    3. # 右外联接:SELECT * FROM m RIGHT JOIN n ON m.id = n.id;

    4. # 交叉联接: SELECT * FROM m CROSS JOIN n; # 标准写法

    5. # 类似全连接full join的联接用法

    6. SELECT id,name FROM m

    7. UNION

    8. SELECT id,name FROM n;

    函数

    1. # 聚合函数

    2. SELECT count(id) AS total FROM n; # 总数

    3. SELECT sum(age) AS all_age FROM n; # 总和

    4. SELECT avg(age) AS all_age FROM n; # 平均值

    5. SELECT max(age) AS all_age FROM n; # 最大值

    6. SELECT min(age) AS all_age FROM n; # 最小值

    7. # 数学函数

    8. SELECT abs(-5); # 绝对值

    9. SELECT bin(15), oct(15), hex(15); # 二进制,八进制,十六进制

    10. SELECT pi(); # 圆周率3.141593

    11. SELECT ceil(5.5); # 大于x的最小整数值6

    12. SELECT floor(5.5); # 小于x的最大整数值5

    13. SELECT greatest(3,1,4,1,5,9,2,6); # 返回集合中最大的值9

    14. SELECT least(3,1,4,1,5,9,2,6); # 返回集合中最小的值1

    15. SELECT mod(5,3); # 余数2

    16. SELECT rand(); # 返回0到1内的随机值,每次不一样

    17. SELECT rand(5); # 提供一个参数(种子)使RAND()随机数生成器生成一个指定的值。

    18. SELECT round(1415.1415); # 四舍五入1415

    19. SELECT round(1415.1415, 3); # 四舍五入三位数1415.142

    20. SELECT round(1415.1415, -1); # 四舍五入整数位数1420

    21. SELECT truncate(1415.1415, 3); # 截短为3位小数1415.141

    22. SELECT truncate(1415.1415, -1); # 截短为-1位小数1410

    23. SELECT sign(-5); # 符号的值负数-1

    24. SELECT sign(5); # 符号的值正数1

    25. SELECT sqrt(9); # 平方根3

    26. SELECT sqrt(9); # 平方根3

    27. # 字符串函数

    28. SELECT concat('a', 'p', 'p', 'le'); # 连接字符串-apple

    29. SELECT concat_ws(',', 'a', 'p', 'p', 'le'); # 连接用','分割字符串-a,p,p,le

    30. SELECT insert('chinese', 3, 2, 'IN'); # 将字符串'chinese'从3位置开始的2个字符替换为'IN'-chINese

    31. SELECT left('chinese', 4); # 返回字符串'chinese'左边的4个字符-chin

    32. SELECT right('chinese', 3); # 返回字符串'chinese'右边的3个字符-ese

    33. SELECT substring('chinese', 3); # 返回字符串'chinese'第三个字符之后的子字符串-inese

    34. SELECT substring('chinese', -3); # 返回字符串'chinese'倒数第三个字符之后的子字符串-ese

    35. SELECT substring('chinese', 3, 2); # 返回字符串'chinese'第三个字符之后的两个字符-in

    36. SELECT trim(' chinese '); # 切割字符串' chinese '两边的空字符-'chinese'

    37. SELECT ltrim(' chinese '); # 切割字符串' chinese '两边的空字符-'chinese '

    38. SELECT rtrim(' chinese '); # 切割字符串' chinese '两边的空字符-' chinese'

    39. SELECT repeat('boy', 3); # 重复字符'boy'三次-'boyboyboy'

    40. SELECT reverse('chinese'); # 反向排序-'esenihc'

    41. SELECT length('chinese'); # 返回字符串的长度-7

    42. SELECT upper('chINese'), lower('chINese'); # 大写小写 CHINESE chinese

    43. SELECT ucase('chINese'), lcase('chINese'); # 大写小写 CHINESE chinese

    44. SELECT position('i' IN 'chinese'); # 返回'i'在'chinese'的第一个位置-3

    45. SELECT position('e' IN 'chinese'); # 返回'i'在'chinese'的第一个位置-5

    46. SELECT strcmp('abc', 'abd'); # 比较字符串,第一个参数小于第二个返回负数- -1

    47. SELECT strcmp('abc', 'abb'); # 比较字符串,第一个参数大于第二个返回正数- 1

    48. # 时间函数

    49. SELECT current_date, current_time, now(); # 2018-01-13 12:33:43 2018-01-13 12:33:43

    50. SELECT hour(current_time), minute(current_time), second(current_time); # 12 31 34

    51. SELECT year(current_date), month(current_date), week(current_date); # 2018 1 1

    52. SELECT quarter(current_date); # 1

    53. SELECT monthname(current_date), dayname(current_date); # January Saturday

    54. SELECT dayofweek(current_date), dayofmonth(current_date), dayofyear(current_date); # 7 13 13

    55. # 控制流函数

    56. SELECT if(3>2, 't', 'f'), if(3<2, 't', 'f'); # t f

    57. SELECT ifnull(NULL, 't'), ifnull(2, 't'); # t 2

    58. SELECT isnull(1), isnull(1/0); # 0 1 是null返回1,不是null返回0

    59. SELECT nullif('a', 'a'), nullif('a', 'b'); # null a 参数相同或成立返回null,不同或不成立则返回第一个参数

    60. SELECT CASE 2

    61. WHEN 1 THEN 'first'

    62. WHEN 2 THEN 'second'

    63. WHEN 3 THEN 'third'

    64. ELSE 'other'

    65. END ; # second

    66. # 系统信息函数

    67. SELECT database(); # 当前数据库名-test

    68. SELECT connection_id(); # 当前用户id-306

    69. SELECT user(); # 当前用户-root@localhost

    70. SELECT version(); # 当前mysql版本

     

    36.Linux命令:

    mv 移动文件夹
    source  更新    
    tar -vxzf     解压
    cd /home       进入 '/ home' 目录' 
    cd ..              返回上一级目录 
    cd ../..           返回上两级目录 
    cd                 进入个人的主目录 
    cd ~user1    进入个人的主目录 
    cd -              返回上次所在的目录 
    pwd             显示工作路径 
    ls                查看目录中的文件 

    vi        编辑

    wq          编辑保存
    ls -F            查看目录中的文件 
    ls -l             显示文件和目录的详细资料 
    ls -a            显示隐藏文件 
    ls *[0-9]*     显示包含数字的文件名和目录名 
    tree            显示文件和目录由根目录开始的树形结构
    lstree          显示文件和目录由根目录开始的树形结构
    mkdir dir1   创建一个叫做 'dir1' 的目录' 
    mkdir dir1 dir2 同时创建两个目录 
    mkdir -p /tmp/dir1/dir2 创建一个目录树 
    rm -f file1 删除一个叫做 'file1' 的文件' 
    rmdir dir1 删除一个叫做 'dir1' 的目录' 
    rm -rf dir1 删除一个叫做 'dir1' 的目录并同时删除其内容 
    rm -rf dir1 dir2 同时删除两个目录及它们的内容 
    mv dir1 new_dir 重命名/移动 一个目录 
    cp file1 file2 复制一个文件 
    cp dir/* . 复制一个目录下的所有文件到当前工作目录 
    cp -a /tmp/dir1 . 复制一个目录到当前工作目录 
    cp -a dir1 dir2 复制一个目录 
    ln -s file1 lnk1 创建一个指向文件或目录的软链接 
    ln file1 lnk1 创建一个指向文件或目录的物理链接 
    文件搜索 
    find / -name file1 从 '/' 开始进入根文件系统搜索文件和目录 
    find / -user user1 搜索属于用户 'user1' 的文件和目录 
    find /home/user1 -name \*.bin 在目录 '/ home/user1' 中搜索带有'.bin' 结尾的文件 
    find /usr/bin -type f -atime +100 搜索在过去100天内未被使用过的执行文件 
    find /usr/bin -type f -mtime -10 搜索在10天内被创建或者修改过的文件 
    find / -name \*.rpm -exec chmod 755 '{}' \; 搜索以 '.rpm' 结尾的文件并定义其权限 
    find / -xdev -name \*.rpm 搜索以 '.rpm' 结尾的文件,忽略光驱、捷盘等可移动设备 
    locate \*.ps 寻找以 '.ps' 结尾的文件 - 先运行 'updatedb' 命令 
    whereis halt 显示一个二进制文件、源码或man的位置 
    which halt 显示一个二进制文件或可执行文件的完整路径 

     

     

    37.adb命令:

    adb 使用的端口号,5037

    adb devices , 获取设备列表及设备状态

    adb get-state , 获取设备的状态

    adb install 用于安装

    adb uninstall 用于卸载

    adb push 命令将PC机上的文件推到 DLT-RK3288 机器上

    adb pull  命令将DLT-RK3288机器上的文件拉到PC机上

    ls, cd, rm, mkdir, touch, pwd, cp, mv, ifconfig, netstat, ping, ps, top等,进入adb shell即可执行,与linux相似

    打印默认日志数据adb logcat

    需要打印日志详细时间的简单数据adb logcat -v time

    需要打印级别为Error的信息adb logcat *:E

    • adb help, 列出所有的选项说明及子命令
    • adb devices , 获取设备列表及设备状态
    • adb get-state , 获取设备的状态,设备的状态有 3 钟,device , offline , unknown,其中device:设备正常连接,offline:连接出现异常,设备无响应,unknown:没有连接设备
    • adb kill-server , adb start-server , 结束 adb 服务, 启动 adb 服务,通常两个命令一起用,设备状态异常时使用 kill-server,然后运行 start-server 进行重启服务
    • adb logcat , 打印 Android 的系统日志    adb logcat -c,清除日志
    • adb bugreport , 打印dumpsys、dumpstate、logcat的输出,也是用于分析错误,输出比较多,建议重定向到一个文件中,如adb bugreport > d:\bugreport.log
    • adb install , 安装应用,adb install -r 重新安装
    • adb uninstall , 卸载应用,后面跟的参数是应用的包名,请区别于 apk 文件名
    • adb pull , 将 Android 设备上的文件或者文件夹复制到本地,如例如复制 Sdcard 下的 pull.txt 文件到 D 盘:adb pull sdcard/pull.txt d:\,重命名:adb pull sdcard/pull.txt d:\rename.txt
    • adb push , 推送本地文件至 Android 设备,如推送 D 盘下的 push.txt 至 Sdcard:adb push d:\push.txt sdcard/   sdcard 后面的斜杠不能少
    • adb reboot , 重启 Android 设备,    adb reboot recovery,重启到Recovery界面    adb reboot bootloader,重启到bootloader界面
    • adb root , adb remount,可以直接已这两个命令获取 root 权限,并挂载系统文件系统为可读写状态
    • adb get-serialno,返回设备序列号SN值    adb get-product,获取设备的ID
    • adb forward tcp:5555 tcp:8000,做为主机向模拟器或设备的请求端口
    • adb shell,进入设备shell
    • adb shell pm list package,列出所有的应用的包名
    • adb shell screencap -p /sdcard/screen.png ,截屏,保存至 sdcard 目录
    • adb shell screenrecord sdcard/record.mp4,执行命令后操作手机,ctrl + c 结束录制,录制结果保存至 sdcard
    • adb shell wm size,获取设备分辨率
    • adb shell pm dump 包名,列出指定应用的 dump 信息
    • adb shell pm path 包名, 列出对应包名的 .apk 位置
    • adb shell monkey –p 程序包 –v 测试次数 ,比如“adb shell monkey –p com.htc.Weather –v 20000”意思是对com.htc.Weather 这个程序包单独进行一次20000次的monkey测试,其中程序包名称可以在串口终端这句命令获得:ls data/data 显示所有程序包
    • adb shell ps | grep [process],找出对应的进程pid  adb shell dumpsys meminfo [pid],根据进程pid查看进程占用的内存    或者  adb shell dumpsys meminfo<package_name>,package_name 也可以换成程序的pid,pid可以通过 adb shell top | grep app_name 来查找
    • adb shell ps, 查看当前终端中的进程信息
    • ls // 查看目录   
    • date // 打印或设置当前系统时间   
    • cat /proc/meminfo // 查看内存信息   
    • cat /proc/cpuinfo // 查看CPU信息

    抓取App报错的log日志:

    按住win+r打开cmd,cd到安装adb的目录下,然后输入指令:adb logcat -v time > D:\\logcat.log(可以换成其他磁盘) ,输入完成之后敲击回车,这个时候在D盘下会生成一个logcat日志并且将近期的崩溃记录到这个日志当中。Ctrl+C以结束截取操作。

    1.adb logcat *:V           不过滤地输出所有调试信息,显示所有日志信息

    1.adb logcat *:D            Debug来表达调试信息,能输出Debug、Info、Warning、Error级别的Log信息。

    1.adb logcat *:I              Info来表达一些信息,能输出Info、Warning、Error级别的Log信息。

    1.adb logcat *:W            Warning表示警告,查找崩溃问题一般用:能输出Warning、Error级别的Log信息

    2.adb logcat *:E             Error表示出现错误,能输出Error级别的Log信息。

     

     

     

    40.Monkey命令

    查看设备的链接情况:adb devices

    手机里面的软件随机点击:adb shell monkey 1000

    查看包名(-s只查找系统包名,-3只查看第三方包,-f输出包和包相关联的文件-e只输出启用的包,-i只输出包和安装信息,-u只输出包和未安装包信息都不加显示所有,):adb shell pm list packages -s

    启动一个指定包名:adb shell monkey -p com.dyhoa.school 1000

    操作日志:adb shell monkey -p com.tencent.mobileqq -v -v 100

    1 参数: -p       用于约束限制,用此参数指定一个或多个包(Package,即App)。指定包之后,monkey将只允许系统启动指定的APP,如果不指定包,将允许系统启动设备中的所有APP.

    * 指定一个包: adb shell monkey -p cn.emoney.acg 10

    * 指定多个包:adb shell monkey -p cn.emoney.acg –p cn.emoney.wea -p cn.emoney.acg 100

    * 不指定包:adb shell monkey 100

     

    2 参数: -v用于指定反馈信息级别(信息级别就是日志的详细程度),总共分3个级别,分别对应的参数如下表所示:

    日志级别 0

    示例 adb shell monkey -p cn.emoney.acg –v 100

    说明缺省值,仅提供启动提示、测试完成和最终结果等少量信息

    日志级别1

    示例 adb shell monkey -p cn.emoney.acg –v -v 100

    说明提供较为详细的日志,包括每个发送到Activity的事件信息

    日志级别 2

    示例 adb shell monkey -p cn.emoney.acg –v -v –v 100

    说明最详细的日志,包括了测试中选中/未选中的Activity信息

     

    3 参数: -s

    用于指定伪随机数生成器的seed值,如果seed相同,则两次Monkey测试所产生的事件序列也相同的。

    Monkey 测试1:adb shell monkey -p cn.emoney.acg -s 10  100

    Monkey 测试2:adb shell monkey -p cn.emoney.acg –s 10 100

    两次测试的效果是相同的,因为模拟的用户操作序列(每次操作按照一定的先后顺序所组成的一系列操作,即一个序列)是一样的。


    4 参数: --throttle<毫秒>用于指定用户操作(即事件)间的时延,单位是毫秒;

    adb shell monkey -p cn.emoney.acg --throttle 5000 100

     

    5 参数: --ignore-crashes     用于指定当应用程序崩溃时(Force& Close错误),Monkey是否停止运行。如果使用此参数,即使应用程序崩溃,Monkey依然会发送事件,直到事件计数完成。

    adb shell monkey -p cn.emoney.acg --ignore-crashes 1000        测试过程中即使程序崩溃,Monkey依然会继续发送事件直到事件数目达到1000为止

    adb shell monkey -p cn.emoney.acg 1000          测试过程中,如果acg程序崩溃,Monkey将会停止运行

     

    6 参数: --ignore-timeouts                        用于指定当应用程序发生ANR(Application No Responding)错误时,Monkey是否停止运行。如果使用此参数,即使应用程序发生ANR错误,Monkey依然会发送事件,直到事件计数完成。

    adb shellmonkey -p cn.emoney.acg --ignore-timeouts 1000

     

    7 参数: --ignore-security-exceptions        用于指定当应用程序发生许可错误时(如证书许可,网络许可等),Monkey是否停止运行。如果使用此参数,即使应用程序发生许可错误,Monkey依然会发送事件,直到事件计数完成。

    adb shellmonkey -p cn.emoney.acg --ignore-security-exception 1000


    8 参数: --kill-process-after-error             用于指定当应用程序发生错误时,是否停止其运行。如果指定此参数,当应用程序发生错误时,应用程序停止运行并保持在当前状态。应用程序仅是静止在发生错误时的状态,系统并不会结束该应用程序的进程

    adb shellmonkey -p cn.emoney.acg --kill-process-after-error 1000


    9 参数: --monitor-native-crashes         用于指定是否监视并报告应用程序发生崩溃的本地代码。

    adb shellmonkey -p cn.emoney.acg --monitor-native-crashes 1000

     

    10 参数: --pct-{+事件类别}{+事件类别百分比}用于指定每种类别事件的数目百分比(在Monkey事件序列中,该类事件数目占总事件数目的百分比)
    示例:
    --pct-touch{+百分比}
    调整触摸事件的百分比(触摸事件是一个down-up事件,它发生在屏幕上的某单一位置)

    adb shell monkey -p cn.emoney.acg --pct-touch 10 1000
    --pct-motion {+百分比}
    调整动作事件的百分比(动作事件由屏幕上某处的一个down事件、一系列的伪随件机事和一个up事件组成)

    adb shell monkey -p cn.emoney.acg --pct-motion 20 1000
    --pct-trackball {+百分比}
    调整轨迹事件的百分比(轨迹事件由一个或几个随机的移动组成,有时还伴随有点击)

    adb shell monkey -p cn.emoney.acg --pct-trackball 30 1000
    --pct-nav {+百分比}

    调整“基本”导航事件的百分比(导航事件由来自方向输入设备的up/down/left/right组成)

    adb shell monkey -p cn.emoney.acg --pct-nav 40 1000
    --pct-majornav {+百分比}
    调整“主要”导航事件的百分比(这些导航事件通常引发图形界面中的动作,如:5-way键盘的中间按键、回退按键、菜单按键)

    adb shell monkey -p cn.emoney.acg --pct-majornav 50 1000

     

    七、输出monkeylog

    跑monkey的时候或者想抓程序log导出时,有时会提示:cannot create D:monkeytest.txt: read-only file system

    为什么有时候可以有时候不可以?

    后来发现跟使用使用习惯不一样,一会是先进入adb shell 再用命令,一会是直接命令进入。

    进入adb shell后再用命令就会失败~

    正确方法:退出shell或者执行命令时先不要进shell

    C:\Documents and Settings\Administrator>adb shell monkey -p 包名 -v 300  >e:\text.txt

    进入adb shell后就相当于进入linux的root下面,没有权限在里面创建文件~

     

     

    48.保证测试的覆盖率 ?

    测试需求分析分两步:

    1、测试需求的获取    需求的来源:

    显式需求:1.原始需求说明书   2.产品规格书   3.软件需求文档   4.有无继承性文档   5.经验库   6.通用的协议规范

    隐式需求:用户的主观感受,市场的主流观点,专业人士的评价分析

    2,需求的分析,产生测试需求文档

    将不同的需求来源划分成一个个需求点,针对每一点进行测试分析:界定测试范围,利用各种测试设计的方法产生测试点

    在测试方法方面,可做如下注意:

    其一,分析出口入口。从入口分析,将可能出现的环境,条件,操作等内容分类组合,然后根据各位测试达人的方法进行整合,逐一验证。从出口分析,将可能出现的结果进行统计,根据结果的不同追根溯源,再找到不同的操作以及条件等内容,统计成文档,逐一验证。

    其二,多种测试手法的学习和使用。大家可能更多的关心测试方法,但是具体操作的手法也是需要注意的。毕竟测试方法比较容易找到,各位达人都很熟悉。如果将每个人不同的测试手法总结出来并在自己的测试实施中加以使用,可能会收到意想不到的成果。

    二、当测试需求分析完成,并且形成文档后,要进行测试需求评审,保证需求的准确性以及完整性。

    三、测试需求完成以后,可以根据测试需求设计测试用例。

    要保证测试用例能够全面覆盖测试需求,要包含所有的情况。

    测试用例设计上划分为单功能测试用例和测试场景设计,单功能测试覆盖的需求中的功能点,测试场景覆盖需求中的业务逻辑。

    在设计测试用例的时候,可以使用多种测试用例设计方法。

    ●首先进行等价类划分,包括输入条件和输出条件的等价类划分,合理设置有效等价类和无效等价类,这是减少工作量和提高测试效率最有效的方法。

    ●必须使用边界值分析,经验表明,这种方法设计出的用例能发现很多程序错误。

    ●可以使用错误推测法追加一些测试用例,这需要依靠您的智慧和经验。

    ●对照程序逻辑检查已设计出的测试用例的逻辑覆盖度,如果没有达到覆盖标准应当再补充足够的测试用例。

    ●如果程序的功能说明中含有输入条件的组合情况,一开始就可选因果图和判定表驱动法。

    ●对于参数配置类的软件,要用正交试验法选择较少的组合方式达到最佳效果。

    ●对于业务流清晰的系统,可以利用场景法贯穿整个测试方案过程,在案例中综合使用各种测试方法。

    当测试用例设计完成后,要组织测试用例的评审,这样可以吸取别人的意见,减少遗漏,补全测试用例。

    四、测试用例编写完成后,就是测试执行

    1.测试用例执行100%覆盖。2.在测试执行过程中,要继续对测试用例补充完善,确保提高测试覆盖率。

    五、在整个测试过程中,需求都是不可能不变的,所以要及时的更新测试需求、测试用例。

    六、要将测试需求、测试用例以及发现的bug关联起来,便于管理和跟踪,同时也便于查看覆盖率。

     

     

    49.测试用例评审?

    1. 评审就是对测试用例进行检查

    2. 评审类型:同行评审、小组评审、部门评审、三方评审

    3. 评审目的:发现测试用例不足,方便测试人员改进测试用例,提高测试质量

    4. 评审过程:循环执行 “测试用例评审--》改进测试用例”

     

     

    50.做好测试(用例)计划的关键?

    1.明确测试计划

    2.明确测试内容、测试过程、测试目的

    3.测试范围与测试内容高度覆盖

    4.测试结果的直观性、准确性

    5.测试开始与结束时间

    6.测试方法与测试工具的实用性

    7.测试文档与测试软件

    8.采用评审和更新机制

    9.保证测试计划满足实际需求

     

    51.完整的测试组成?

    1.测试设计:需求分解,细化执行测试过程,为每个测试过程选择合适的测试用例

    2.测试计划:根据需求和性能指标说明,定制相应测试计划,安排测试测试人员,测试内容,测试时间以及测试需要的资源

    4.测试执行:建立自动化测试,对发现bug跟踪管理,按步骤测试(单元测试,集成测试,系统测试,验收测试)

    5.测试评估:结合量化测试覆盖域以及bug跟踪,对软件质量,开发进度,工作效率等综合评价

     

    52.所有的软件缺陷都可修复吗,都要修复吗?

    理论上软件的缺陷是可修复的,不过有的修复成本比较高,不能追求软件的完美,根据风险来确定是否修复缺陷

    1.没有足够的时间,在项目中没有足够时间修改缺陷可能会引出其他缺陷,导致项目的推迟

    2.有些缺陷只在特殊环境下出现,这种缺陷处于项目的利益考虑可以放在以后版本中进行修复升级

    3.不是缺陷的缺陷。缺陷的是否修改应该由测试人员、项目经理、程序员共同讨论决定,以确保项目的正常运行

     

     

     

     

     

     

    展开全文
  • 测试面试问题总汇

    万次阅读 多人点赞 2018-12-17 20:51:24
    给你一个全新的软件,你就是负责人,你怎么去开展测试工作 参考回答: 第一步:需求分析:我会对这个全新的软件需求进行全面分析,主要的分析点有:1.软件的版本需求合理性,是否可测试;2.项目人员配置(遇到什么...
  • 面试必备----测试用例笔试分享

    千次阅读 多人点赞 2018-02-27 20:02:55
    以下的面试题,给大家分享一下希望小伙们看完以后可以做到举一反三如图:截图实在过于模糊,现在给大家重新用文字整理一遍:用例题目有一个流程的功能描述如下,请运用系统测试用例设计方法,设计相应的系统测试用例...
  • 软件测试测试基础面试题(不断更新)

    万次阅读 多人点赞 2019-01-25 20:28:53
    1.问:什么是兼容型测试?兼容性测试侧重哪些方面? 答:兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行,即是通常说的软件的可移植性。 兼容的类型,如果细分的话,有平台的兼容...
  • 软件测试经典面试题(小题汇总)

    万次阅读 多人点赞 2020-07-01 14:54:36
    整理收集一些大家的,自己来作答,回答不妥或者不全的还请大家指正 网络 (一)简单描述下TCP协议 TCP:传输控制协议,是传输层通信协议。它有面向连接、可靠、字节流传输等特点 TCP建立连接时,需要三次握手协议 ...
  • 软件测试常见笔试面试题(二)

    万次阅读 多人点赞 2018-08-02 18:02:30
    一、什么是静态测试?动态测试? 二、什么是回归测试? 三、如果能够执行完美的黑盒测试,还需要进行白盒测试吗(黑盒和白盒的区别?) 四、软件测试分几个阶段?各阶段重点测试什么?各个阶段的含义? 五、针对...
  • 2019年互联网企业软件测试面试题(常考)

    万次阅读 多人点赞 2019-04-22 09:32:26
    很多软件测试工程师在面试互联网企业的时候都会遇到考官给的几道面试题,这也反应了测试工程师对企业的重要性,今天传智播客整理了一份2019年的互联网企业软件测试面试题,希望能帮助到大家。 2019年互联网企业软件...
  • 软件测试面试题(面试前准备篇)

    千次阅读 多人点赞 2019-09-27 10:42:53
    目录 一、问题预测 让简单介绍下自己(每次面试开场) ...为什么做测试,觉得自己做测试有哪些优势?(有问到) 知道哪些Bug系统 9.测试用例的基本要素是? 二、介绍一下公司项目 三、技能...
  • 软件测试面试题合集【乐搏TestPRO】

    万次阅读 多人点赞 2020-03-20 16:28:26
    又到了金九银十跳槽求职旺季。...以下是“大佬”本人从乐搏学院VIP学员面试经验中收集的,然后分门别类整理了这套面试题,很具备参考性,毕竟都是企业真实面试题目。 接下来,针对以下知识类型列出具体的面试点(其中...
  • 【软件测试】初级软件测试面试题汇总

    万次阅读 多人点赞 2018-11-03 16:20:31
    初级软件测试面试题 1.请描述如何划分缺陷与错误严重性和优先级别? 给软件缺陷与错误划分严重性和优先级的通用原则: (1)表示软件缺陷所造成饿危害和恶劣程度。 (2)优先级表示修复缺陷的重要程度和次序。 严重...
  • 接口测试面试题

    千次阅读 多人点赞 2019-06-01 11:45:36
    1.什么是接口测试? 接口测试:是测试系统组件间接口的一种测试方法 接口测试的重点:检查数据的交换,数据传递的正确性,以及接口间的逻辑依赖关系 接口测试的意义:在软件开发的同时实现并行测试,减少页面层测试...
  • 测试面试题

    万次阅读 2018-03-01 17:14:33
    软件测试原则1 good enough2 80-20原则3 尽早的进行测试4 集群性5 交叉测试 进程和线程的区别1、根据自己的理解什么是测试用例和测试规程,设计一个测试用例应当从哪几方面考虑? 2、 什么是软件质量保证?软件...
  • 中级测试面试题

    千次阅读 2019-12-02 10:30:05
    1.接口测试,post和get的区别 2.什么时候做接口测试? 3.集成测试有什么策略? 4.通过接口能干那些事情?什么工具适合做接口测试?接口压测呢? 5.我有一个网站,我想知道我的网站能容纳多少人?--负载测试...
  • 问:软件测试的原则? 答:https://blog.csdn.net/weixin_30363263/article/details/102986878 问:你在测试中发现了一个 bug ,但是开发经理认为这不是一个 bug ,你应该怎样解决。 1、将问题提交到缺陷...
  • APP测试面试题

    万次阅读 多人点赞 2018-02-27 19:55:22
    年后肯定有不少小伙伴要换工作的额,... 4、你觉得为什么要在一个团队中开展软件测试工作,测试的价值提现在哪里? 二、技术方面: 1、代码能力: 1.1、请用自己最擅长的编程语言,将一个字符串反转并输出? ...
  • 接口自动化测试面试题(1)

    万次阅读 多人点赞 2019-08-14 15:27:29
    根据网络资料,总结了以下一些常见的接口测试面试题: 为什么要做接口测试? 接口测试能发现哪些问题? 接口测试怎么测? 用什么工具测接口? WebService接口是如何测试的? 没有接口文档如何做接口测试? 在...
  • Java基础知识面试题(2020最新版)

    万次阅读 多人点赞 2020-05-06 14:13:40
    文章目录Java概述何为编程什么是Javajdk1.5之后的三大版本JVM、JRE和JDK的关系什么是跨平台性?原理是什么Java语言有哪些特点什么是字节码?采用字节码的最大好处是什么什么是Java程序的主类?应用程序和小程序的...
1 2 3 4 5 ... 20
收藏数 107,788
精华内容 43,115
关键字:

测试面试题