为您推荐:
精华内容
最热下载
问答
  • 5星
    178.06MB guoruibin123 2021-06-25 13:54:42
  • 1、软件测试概述 **软件测试的IEEE定义:**使用人工或自动的手段来运行或测量软件系统的过程,目的是检验软件系统是否满足规定的需求,并找出与预期结果之间的差异。软件测试的发展趋势: ① 测试工作将进一步前移...

    1、软件测试概述

    **软件测试的IEEE定义:**使用人工或自动的手段来运行或测量软件系统的过程,目的是检验软件系统是否满足规定的需求,并找出与预期结果之间的差异。软件测试的发展趋势:

    ① 测试工作将进一步前移。软件测试不仅仅是单元测试、集成测试、系统测试和验收测试,还对需求的精确性和完整性的测试技术、对系统设计的测试技术将成为新的研究热点。

    ② 软件架构师,开发工程师,QA人员,测试工程师将进行更好地融合

    ③ 测试职业将得到更充分的尊重。

    ④ 设置独立的软件测试部门将成为未来软件公司的共识。

    ⑤ 测试外包服务将快速增长,和软件开发外包一样,软件测试外包将成为全球化的趋势。
    在这里插入图片描述

    软件测试工程师的素质:

    责任心;沟通能力;团队合作精神;耐心、细心和信心;保持怀疑的态度,有缺陷预防的意识;不断学习的能力。

    合格的测试工程师应具有的能力:

    ① 一般能力:包括表达、交流、协调、管理、质量意识、软件开发过程方法、软件工程等;

    ② 测试技能及方法:包括测试基本概念及方法、对测试工具的掌握、对专业测试标准的熟悉程度等;

    ③ 测试规划能力:包括风险分析及防范能力、测试目标及计划的制定能力等;

    ④ 测试执行能力:包括测试数据/脚本/用例的制定能力、测试比较及分析能力、缺陷记录及处理能力;

    ⑤ 测试分析、报告和改进能力:包括测试度量、统计技术、测试报告、过程监测及持续改进能力。

    测试工程师的职责:

    测试人员要了解项目需求内容,从用户的角度提出自己的测试看法;

    测试人员要编写合理的测试计划并与项目整体计划有机地整合在一起;

    测试人员要编写覆盖率高的测试用例;测试人员要认真仔细地实施测试工作,并提交测试报告以供项目参考;

    测试人员要进行缺陷跟踪和分析。

    2、软件测试基础软件的概念

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

    软件的特点:

    ① 软件是一种逻辑体,而不是具体的物理体,因而它具有抽象性;

    ② 软件的生产与硬件不同,它没有明显的制造过程,对软件质量的控制,必须在开发方面下功夫;

    ③ 在软件运行和使用期间,没有硬件那样的机械磨损和老化问题,然而它存在退化问题,必须进行多次的修改和维护;

    ④ 软件的开发和运行常常受计算机系统的制约,对计算机系统有着不同程度的依赖性,为了解除这种依赖性,在软件开发过程中提出了软件移植问题。

    ⑤ 软件本身是复杂的,软件的复杂性可能来自它所反映问题的复杂性,也可能来自程序逻辑结构的复杂性。

    ⑥ 软件成本的昂贵。软件的研制工作需要投入大量的、复杂的、高强度的脑力,它的成本比较高。

    软件的分类:

    按照功能划分:

    系统软件:如操作系统、数据库管理系统,各种驱动软件等

    应用软件:如Office、金山词霸、QQ等

    按照技术结构划分:

    单机版本:如Office,画图工具等

    C/S结构软件:如QQ、MSN等

    B/S结构软件:如新浪、搜狐、google等

    按照用户划分:

    产品软件:Office、财务处理软件、金山毒霸等

    项目软件:如为企业定制的OA系统等

    按照开发规模划分:

    类别 参与人数 开发时间

    小型 10人以下 1-4个月

    中型 10-100人 1年以下

    大型 100人以上 1年

    软件测试的概念:

    软件测试就是为了发现错误而执行程序的过程(狭义观点)。

    使用人工或自动的手段,来运行或测试软件系统的过程,目的是检验软件系统是否满足规定的需求,并找出与预期结果之间的差异。(标准定义IEEE )

    软件测试就是为了证明程序有错,而不是证明程序无错误(辨证观点) 。

    测试被定义为“对软件系统中潜在的各种风险进行评估的活动”。(风险观点)软件测试就是“验证(Verification)”和“有效性确认(Validation)”活动构成的整体,即软件测试V&V 。(标准观点)

    要完整理解软件测试,就要从不同方面去审视软件测试,概括起来,软件测试就是贯穿整个软件开发生命周期,对软件产品(包括阶段性产品)进行验证和确认的活动过程,其目的是尽快尽早地发现在软件的缺陷。

    软件测试的对象:

    ① 源程序/目标代码

    ② 各开发阶段的文档(需求规格说明、概要设计说明、详细设计说明及其它相关文档)

    软件测试的目的:

    从用户角度看的目的:通过软件测试发现隐藏的错误和缺陷,考虑是否可以接受该产品。从开发者角度看的目的:表明软件产品不存在错误,验证软件实现了所有用户的要求。从测试人员角度看的目的:发现错误,预测错误,提供软件可靠性错误,对软件做出评价。

    ① 帮助开发人员、测试工程师发现问题、分析问题。

    ② 减少软件的缺陷数目或者降低软件缺陷的密度。

    ③ 提高软件的可靠性

    ④ 评估软件的性能指标。

    ⑤ 增加用户对软件的信心。

    ⑥ 测试的最终目的是尽快尽早地发现在软件中的缺陷,通过修正各种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

    软件测试的原则:

    ① 所有测试的都应追溯到用户需求。

    ② 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。

    ③ 由于软件的复杂性和抽象性,在软件生命周期各个阶段都可能产生错误,所以不应把软件测试仅仅看作是软件开发的一个独立阶段的工作,而应当把它贯穿到软件开发的各个阶段中。在软件开发的需求和设计阶段就应开始测试工作,编写相应的测试文档。

    ④ 完全测试是不可能的,测试需要终止。

    ⑤ 想要进行完全的测试,在有限的时间和资源条件下,找出所有的软件缺陷和错误 使软件趋于完美是不可能的主要有三个原因: ① 输入量太大; ② 输出结果太多;③ 路径组合太多。

    ⑥ 测试无法显示软件潜在的缺陷:进行测试是可以查找并报告发现的软件缺陷和错误,但不能保证软件缺陷和错误全部找到。

    ⑦ 充分注意集试中群集现象(二八定理):经验表明,在所测试程序段中,若发现的错误数目多,则残存的错误数目也较多。缺陷的二八定理指的是,一般情况下,80%软件缺陷出现在20%的功能区域,在测试过程中,投入主要的人力和精力重点测试这20%的功能区域。

    ⑧ 开发人员应避免检查自己的程序:基于心理因素,揭露自己程序中的问题总不是一件愉快的事,不愿否认自己的工作;由于思维定势,人们难于发现自己的错误。因此为达到测试的目的,应由客观、公正、严格的独立的测试部门或独立的第三方测试机构进行测试。

    ⑨ 尽量避免测试的随意性:应从工程的角度理解测试,它是有组织、有计划、有步骤的活动。

    软件测试误区:

    误区一:如果发布出去的软件有质量问题,都是软件测试人员的错。

    误区二:软件测试技术要求不高,至少比编程容易多了。

    误区三:有时间就多测试一些,来不及就少测试一些。

    误区四:软件测试是测试人员的事,与开发人员无关。

    误区五:根据软件开发瀑布模型,软件测试是开发后期的一个阶段。

    3、软件测试分类

    在这里插入图片描述
    在这里插入图片描述](https://img-blog.csdnimg.cn/20210522164153971.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pqdGR5,size_16,color_FFFFFF,t_70)

    单元测试:

    单元测试又称模块测试,针对软件设计中的最小单位——程序模块,进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

    单元定义:

    C中指一个函数,Java中指一个类,在图形化的软件中,单元一般指1个窗口,1个菜单。如何进行单元测试:单元测试主要用白盒测试,先静态地检查代码是否符合规范,然后动态运行代码,检查其实际运行结果,检查程序的运行结果是否正确是一个最基本的要求,还要关注容错处理,程序的边界值处理等。

    集成测试:

    集成测试又叫组装测试,通常在单元测试的基础上,将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。

    系统测试:

    指将整个软件系统看为一个整体进行测试,包括对功能、性能、以及软件所运行的软硬件环境进行测试。

    验收测试:

    验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收或拒收系统。在系统测试的后期,以用户测试为主或有测试人员等质量保证人员共同参与的测试。

    **α测试:**指的是指的是由用户,测试人员、开发人员等共同参与的内部测试。

    **β测试:**指的是内测后的公测,即完全交给最终用户测试验收测试的重要性:验收签字,收钱。

    在这里插入图片描述

    **静态测试:**指不实际运行被测软件,而只是静态地检查程序代码、界面和文档中可能存在的错误的过程。

    **动态测试:**指实际运行被测程序,输入相应的测试数据,检查实际输出结果与预期结果是否相符。(动态测试方法为结构和正确性测试;动态测试工具Robot、QTP等)

    **黑盒测试:**指的是把被测的软件看做一个黑盒子,我们不关心盒子里面的结构是什么样子的,只关心软件的输入数据和输出

    **白盒测试:**指的是把盒子打开,去研究里面的源代码和程序结构。软件公司中,往往采用黑盒测试&白盒测试相结合的方式。

    静态黑盒测试:看文档,看页面等
    静态白盒测试:开源代码等
    动态黑盒测试:使用软件等
    动态白盒测试:运行源代码等
    灰盒测试:是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。

    **功能测试:**是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。

    逻辑功能测试(functiontesting)

    界面测试(UItesting)

    易用性测试(usability testing)

    安装测试(installationtesting)

    兼容性测试(compatibilitytesting)

    **性能测试:**是软件测试的高端领域,通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。时间性能(事务响应时间等)空间性能(系统资源消耗)一般性能测试可靠性测试负载测试压力测试

    **回归测试:**指对软件的新版本测试时,重复执行上一个版本测试时的用例。

    **冒烟测试:**是指在对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测试性。

    **随机测试:**是指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。

    **软件测试的过程:**从软件开发的过程按阶段划分有:需求验证、单元测试、集成测试、确认测试、系统测试、验收测试

    4、白盒测试用例设计方法

    测试用例(英文为TestCase,缩写为TC):指的是在测试执行之前设计的一套详细的测试方案,包括测试环境、测试步骤、测试数据和预期结果。测试用例可以针对黑盒测试设计用例,也可以针对白盒测试设计用例。编写测试用例的唯一标准就是用户需求,具体的参考资料是《需求规格说明书》。

    设计测试用例的原因:软件测试是一项有组织、有计划、有步骤的活动,为了将软件测试的行为转换为可管理的、具体量化的模式,需要创建和设计测试用例。

    测试用例的四性:

    代表性:能够代表并覆盖各种合理的和不合理合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。

    针对性:对程序中的可能存在的错误有针对性地测试。

    可判定性:测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。

    可重现性:对同样的测试用例,系统的执行结果应当是相同的。

    测试用例的基本原则:

    利用成熟的测试用例设计方法来指导设计

    测试用例的针对性

    测试用例的代表性

    测试用例的可判定性

    测试用例的可重现性足够详细、准确和清晰的步骤

    测试用例必须符合内部的规范的要求

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

    判定覆盖(也称为分支覆盖):设计若干个测试用例运行所测程序使程序中每个判断的取真分支和取假分支至少执行一次;

    条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每 条件覆盖设计足够多的测试用例 行所测程序使程序中每个判断的每个条件的每个可能取值至少执行一次;

    判定-条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的所有可能取值至少执行一次,并且每个可能的判断结果也至少执行一次,换句话说,即是要求各个判断的所有可能的条件取值组合至少执行一次;

    条件组合测试:设计足够多的测试用例,运行所测程序,使程序中每个判断的所有可能的条件取值组合至少执行一次;

    路径测试:设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径。

    主要测试技术:分支条件覆盖,基本路径测试

    5、黑盒测试用例设计方法

    主要测试技术:等价类划分(边界值分析),因果图法,(正交实验法)

    6、缺陷管理软件缺陷

    软件缺陷:

    是指存在于软件(程序、数据、文档)中的那些不符合用户需求的问题。

    软件缺陷的来源:

    需求说明书:需求说明书的错误或不清楚引起的错误,是缺陷第一大的来源。

    设计文档:设计文档描述不准确、以及与需求说明书不一致,是缺陷的第二大来源。

    编码:纯粹是由编码的问题引起。

    其它:可能是系统集成、测试引起。

    软件缺陷的根源:交流不充分(客户与开发人员、开发人员与测试人员等)软件的复杂性(功能复杂、开发复杂、测试复杂)开发人员的错误(对需求的理解、开发压力、能力与经验)需求的变化(需求说明书设计文档 程序的变更)进度压力(项目周期比较紧)

    软件缺陷的发现手段:同行评审、测试、管理评审、QA发现、项目组内部发现、客户反馈为了便于缺陷的定位、跟踪和修改,要对所发现的缺陷,按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

    二八定理:80%的软件问题总是发生在大约20%的功能模块中。

    缺陷密度:基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的,其测量单位是defects/KLOC。

    常见寻找bug的方法:色彩、功能结构布局、图片、页面大小、字体、窗体大小、界面文字、容错处理(也为功能缺陷,所谓容错,就是容忍错误的能力。当用户在使用软件过程中发生错误后,软件应该能给出引导信息,指应用户进行正确的操作)、数据转换(增删改查)、性能缺陷(黑盒测试)。

    Web测试:

    Web测试即测试网站系统在不同客户端(浏览器)的运行情况及兼容性。

    Selenium:

    Selenium是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中,就像真正的用户在操作一样。

    共勉:【可能给予你助力的教程】

    这些资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。
    在这里插入图片描述
    在这里插入图片描述

    关注我的微信公众号【程序媛木子】免费获取~

    展开全文
    zjtdy 2021-05-22 16:39:12
  • 软件原则软件测试基本流程demo实例二.黑盒测试方法1,等价类划分法等价类划分概述等价类划分demo2.边界值分析法边界值分析法概述边界值分析法demo3.因果图方法因果图设计方法因果图设计demo4.决策表方法决策表概述...

    软件测试的基本理论


    由于长时间专项某一项工作,现在整理归纳下测试过程与理论知识,此资料作为工作级基础资料都有自己的理解,如有错误请指正,谢谢

    一. 软件测试概述

    1.软件概述

    相对于硬件而言,按照一定顺序组织计算机数据与指令的集合。

    软件测试周期

    软件产品从‘出生‘到’消亡‘过程叫做软件生命周期;
    生命周期分为6个阶段:

    问题定义-需求分析-软件设计-软件开发-软件测试-软件维护

    各个阶段涉及的问题:
    问题定义:由软件开发与需求方共同讨论,主要是开发目标与设计的可行性;

    需求分析:对软件需求进行深入分析,划出软件要实现的功能,并制定成需求文档,即需求文档说明书;

    软件设计:在需求分析基础上,对系统进行设计,如,软件架构设计、数据库设计等;

    软件开发:在软件设计基础上,选择一种语言进行开发编程,此处关注的是代码规范、程序可读性、以维护、可移植

    软件测试:该阶段涵盖各个阶段,前期对需求文档测试、开发期间可白盒测试、软件开发过程中尽可能多的发现问题的缺陷与不足;
    软件测试过程:包括需求文档测试、单元测试、集成测试、系统测试
    软件测试方法:黑盒测试、灰盒测试、白盒测试;

    软件维护:软件发布使用后需要对软件进行维护升级与修复bug等,包括纠错性维护、改进性维护并且耗时最久;

    软件开发模型

    软件开发模型:规定了软件开发遵循的步骤;是软件开发的导航图,能够清晰表法在开发的全过程、以及每个阶段进行的活动与要完成的任务;
    模型:瀑布模型、快速原型模型、迭代模型、螺旋模型、敏捷模型

    a:瀑布模型

    阶段:计划-需求分析-软件设计-软件设计-编码-测试-维护
    瀑布模型整个过程线性过程,优缺点明显
    瀑布模型优点
    1)为项目提供了按阶段划分的检查点。
    2)当前一阶段完成后,您只需要去关注后续阶段。
    3)可在迭代模型中应用瀑布模型。
    增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
    4)它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
    瀑布模型缺点
    1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4)瀑布模型的突出缺点是不适应用户需求的变化
    ![瀑布模型](https://img-blog.csdnimg.cn/20210604003859643.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjkxNDcwNg==,size_16,color_FFFFFF,t_

    b:快速原型模型

    快速建立一个能反映用户主要需求的原型系统,完成软件核心功能,通过实践来了解目标系统的概貌.

    在这里插入图片描述
    与瀑布模型相比,客服需求不明带来风险,适用于不能预先确定需求的软件项目,准确设计出软件有的难度,因为不利于对产品的扩展;

    c:迭代模型(增量模型或演化模型)

    迭代模型,摒弃了传统的需求分析,设计,编码,测试的流程,而是将整个生命周期变成若干个冲刺(Sprint)阶段,而每一个阶段都是由以上若干或者全部传统的流程组成,在每一个阶段中,都会包含下面四个阶段:初始阶段,细化阶段,构建阶段,交付阶段。在初始阶段中,确认本次冲刺的范围,边界,系统选择的架构,计划,以及所需要的资源等信息

    在这里插入图片描述
    在这里插入图片描述

    d:螺旋模型

    在软件开发过程中及时识别和分析风险,并且采取适当措施以消除或减少风险的危害。构建原型是一种能使某些类型的风险降至最低的方法
    在这里插入图片描述
    螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:
    四种象限
    (1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
    (2)风险分析:分析评估所选方案,考虑如何识别和消除风险;
    (3)实施工程:实施软件开发和验证;
    (4)客户评估:评价开发工作,提出修正建议,制定下一步计划。
    螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。

    e:敏捷模型

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
    敏捷模型2种开发模式: Scrum 与 Kanban

    a:Scrum
    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作,其模式含义是-就是响应变化,它能够尽快地响应变化
    Scrum开发流程中的三大角色:

    产品负责人(Product Owner)
    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果.

    流程管理员(Scrum Master)
    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    开发团队(Scrum Team)
    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    进行Scrum开发过程:
    1)确定一个Product Backlog(按优先顺序排列的一个产品需求列表-Product Owner 负责)
    2)Scrum Team根据Product Backlog列表,做工作量的预估和安排
    3)Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog
    4)Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)
    5)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)
    6)做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;
    7)当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议
    8)最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    Kanban (看板)
    Kanban是一种高效管理软件开发过程的新技术;
    将工作细分成任务,将工作流程显示在“看板卡”上,每个人都能及时了解自己的工作任务及工作进度。
    每个成员都可以在“看板”上了解自己的工作任务及整个团队的工作进度。项目开始之后,从目前执行的任务和过程开始,团队会针对每个成员的工作做出持续、增量、渐进式的改变。
    在这里插入图片描述
    几乎每个开发团队都在搞“敏捷”,很多团队都声称自己做的是Scrum,实际上他们做的介于Scrum和Kanban之间

    软件质量的概述

    1,软件质量的概念

    指软件产品满足基本需求和隐式需求的程度。基本需求指能满足软件开发时所规定的需求特性-对软件产品最基本的质量要求;隐式需求指界面更美观、用户操作更简洁等;
    从软件质量规定:
    满足需求规定、满足用户需求、满足用户隐式需求;

    2,软件质量模型

    全面客观的评价一个产品的质量并不容易;下面我们介绍下ISO/IEC 9126:1991来评价 一个软件的质量;
    不仅对软件质量进行了定义,而且还定制了软件测试的规范流程;
    ISO/IEC 9126 (1991年发布)是一个软件质量的评估标准,后来被最新的软件质量标准ISO/IEC 25010:2011(2011年发布)取代

    1,ISO/IEC9126软件质量模型是一种评价软件质量的通用模型,包括3个层次:

    质量特性
    质量子特性
    度量指标

    2,ISO9126包含了质量模型的六大特性和27个子特性
    (1)功能性(Functionality):功能性是指与软件所具有的各项功能及其规定性质有关的一组属性,包括:

    a:适合性(Suitability):与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。适合程度的例子是面向任务系统中,由子功能构成功能是否合适、表容量是否合适等。

    b:准确性(Accuracy):于能否得到正确或相符的结果或效果有关的软件属性。此属性包括计算值所需的准确程度。

    c:互操作性(互用性,Interoperability):与同其他指定系统进行交互的能力有关的软件属性。为避免可能与可替换性的含义相混淆,此处用互操作性(互用性)而不用兼容性。

    d:依从性(Compliance):使软件遵循有关的标准、约定、法规及类似规定的软件属性。

    e:安全性(Security):以防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。

    (2)可靠性(Reliability):可靠性是指在规定运行条件下和规定时间周期内,与软件维护其性能级别的能力有关的一组属性。可靠性反映的是软件中存在的需求错误、设计错误和实现错误而造成的失效情况:

    包括:

    a:成熟性(Maturity):与由软件故障引起失效的频度有关的软件属性。

    b:容错性(Fault Tolerance):与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性。指定的性能水平包括失效防护能力。

    c:可恢复性(Recoverability):与在失效发生后重建其性能水平并恢复直接受影响数据的能力,以及为达此目的所需的事件和努力有关的软件属性。

    (3)可用性(Usability):可用性是指根据规定用户或隐含用户的评估所做出的关于与使用软件所需要的努力程度有关的一组属性。包括:

    a:可理解性(Understandability):与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。

    b:易学性(Learnability):与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。

    c:可操作性(Operability):与用户为操作和运行控制所需的努力有关的软件属性。

    (4)效率(Efficiency):效率是指在规定条件下,与软件性能级别和所使用资源总量之间的关系有关的一组属性。包括:

    a:时间特性(Time Behaviour):与软件执行其功能时响应和处理事件及吞吐量有关的软件属性。

    b:资源特性(Resource Behaviour):与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。

    (5)可维护性(Maintainability):可维护性是指与软件进行修改的难易程度有关的一组属性。包括:

    a:可分析性(Analysability):与为诊断缺陷 或失效原因及为判定待修改的部分所需努力有关的软件属性。

    b:可改变性(Changeability):与进行修改、排除错误或适应环境变化所需努力有关的软件属性。

    c:稳定性(Stability):与修改所造成的未预料结果的风险有关的软件属性。

    d:可测试性(Testability):与确认已修改软件所需的努力有关的软件属性。此子特性的含义可能会被研究中的修改加以改变。

    (6)可移植性(Portability):可移植性是指与一个软件从一个环境转移到另一个环境运行的能力有关的一组属性。包括:

    a:适应性(Adaptability):与软件无须采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性。

    b:可安装性(Installability):与在指定环境下安装软件所需努力有关的软件属性。

    c:依从性(一致性,Conformance):使软件遵循与可移植性有关的标准或约定的软件属性。

    d:可替换性(Replaceability):与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性。为避免和互用性的含义混淆,此处用可替换性而不用兼容性。

    3,影响软件质量的因素

    需求模糊、软件开发缺少规范性文件指导、软件开发人员、缺少软件质量控制管理与资源等都有相关影响

    2.软件缺陷管理

    是指对bug的管理。

    1,软件缺陷产生原因

    总结归纳主要有以下几点
    1)需求不明确;需求不清或不明确开发无法理解导致偏离客户需求目标造成的软件功能和特性上的缺陷;
    2)软件结构复杂;结构复杂很难设计出很好的架构层次或组件框架,导致开发、维护、扩充上困难;
    3)编码问题;team成员的水平、开发缺少有效的沟通,会导致软件中存在很多缺陷;
    4)项目期限短;项目资源有限、时间成本与team压力都会是导致缺陷的潜在因素;
    5)新技术的运用;使用未健全或未获得充分实践的技术

    2,软件缺陷的分类

    1)测试种类
    界面、功能、性能、安全性类兼容性
    2)严重程度
    严重、一般、次要、建议
    3)优先级
    立即解决、高优先级、正常排序、低优先级
    4)发生阶段
    需求阶段、架构阶段、设计阶段、编码阶段、测试阶段

    3,软件缺陷处理流程

    在这里插入图片描述
    1)提交:测试人员发现bug后,将缺陷提交给测试组长;
    2)分配:测试组长确认后可打回或移交到开发软件,一般为开发接口人统一分配
    3)确认;开发人员或开发owner分配移交流程,并商讨如何解决缺陷;
    4)拒绝/延期:商议后可定位缺陷性质;非问题走回归、或缺陷安排解决根据优先级安排任务;
    5)处理:开发人员修改缺陷
    6)复测:修复后开发人员进行回归测试、复测
    7)关闭:经过测试重新测试,可进行关闭

    4,缺陷测试报告

    软件缺陷报告

    缺陷ID20210505-!@#¥%
    测试软件名称某客户端
    软件测试版本V2.9.1
    缺陷发现日期20210605
    测试人员xxx
    缺陷描述1,打开客户端,输入用户名、输入密码;2,点击登陆;3,提示用户名不存在
    附件截图或者报错信息
    缺陷类型功能性
    缺陷严重程度严重
    缺陷优先级立即解决
    测试环境处理器、内存、系统(一般为测试依赖的环境配置信息)
    重现步骤1,注册后 2,重新登陆 3,提示用户名不存在
    备注测试缺陷相关测试内容

    3.软件测试的概述

    测试目的

    结合软件开发、软件测试、客户需求归纳为以下几点:
    1)对于开发人员通过测试找到问题缺陷帮助开发定位、分析、解决问题预防下次缺陷的产生;
    2)对于测试,使用最少的资源尽可能多的找出软件存在缺陷保证软件的质量,为以后测试积累经验;
    3)对于客户,测试能够检验软件是否符合客户需求,对软件质量进行评估与度量,为客户评审软件提供有力证据;

    测试分类

    1,测试阶段分类

    1)单元测试:软件开发的第一步测试,目的验证软件单元是否符合软件设计需求,大多为开发自测
    2)冒烟测试:软件版本初步建成后,对系统的核心、基本功能测试,重点是否完成了程序主要功能;
    测试结果关系到是否继续测试或重新修正,冒烟测试是对新构建版本进行的最基本测试;
    3)集成测试:在冒烟测试后,将已经测试过的单元组件和在一起测试之间接口,用于验证软件是否满足设计要求;
    4)系统测试:将经过测试的软件在实际环境中运行,并于其他系统成分-数据库-硬件-操作人员等组合在一起进行测试;
    5)验收测试:主要对软件产品说明进行验证,逐行逐字对照说明书的描述对软件进行测试,确保其符合客户的各项需求要求;

    2,测试技术分类

    黑盒测试、灰盒测试、白盒测试(透明盒测试)

    3,软件质量特性分类

    1)功能测试
    测试软件功能是否满足客户需求,包括准确性、易用性、适合性、
    2)性能测试
    软件性能是否满足客户需求,性能测试包括负载测试、压力测试、兼容性测试、可移植性测试、健壮性测试等

    4,自动化程序分类

    1)手工测试
    测试人员一条一条执行代码完成测试,比较耗费时力
    2)自动化测试
    自动化是借助脚本、自动化测试工具等完成相应的测试工作,需要人工的参与,把操作步骤写成代码,通过脚本完成测试

    5,测试类型分类

    1)界面类测试
    验证软件界面是否符合客户需求,包括界面布局、按钮齐全等问题
    2)安全性测试
    测试软件在没有授权的内部或外部用户的攻击和恶意破坏时如何进行处理,如何保证软件和数据的安全
    3)文档测试
    以需求分析、软件设计、用户手册、安装手册为主,主要验证文档说明与实际软件之间是否存在差异。

    6,其他分类

    1)α测试
    软件上线前,开发人员、测试人员协助测试
    α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试;
    目的:是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
    注意!α测试不能由程序员或测试员完成。
    2)β测试
    用户在不同场所进行测试。软件发布上线后
    β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。
    3)回归测试
    测试人员发现缺陷后,提交到开发人员修改完成,回到测试人员手里重新对软件进行测试,
    目的:确认软件缺陷已经消除并没有引入新的问题的缺陷,这个过程叫回归测试。
    4)随机测试
    随机测试是在没有测试用例、检查列表、脚本或者指令的测试;主要根据自己的经验对软件的功能和性能进行抽查。是测试手段的补充,保证测试覆盖完整性的有效方式的过程。

    7,根据软件开发版本周期分类

    预览版本preview测试、内部测试版本Alpha测试、公测版本beta测试、候选版本Release测试,这些测试完成后软件版本就可以上线了。

    4.测试与开发

    测试与开发关系

    软件 缺陷并不一定都是编码引起的,可能由前期的需求分析、软件设计阶段引入的,所以软件测试贯穿整个测试过程非常有必要。
    软件测试在各个阶段发挥作用:
    1)项目规划阶段:负责从单元测试到系统测试的整个测试阶段的监控。
    2)需求分析阶段:确定测试需求分析,即确定项目中需要测什么,同时制定系统的测试计划
    3)概要设计与详细设计阶段:制定单元测试计划和集成测试计划
    4)编码测试:开发相应的测试与脚本测试。
    5)测试阶段:实施测试并提交相应的测试报告。
    软件测试与软件开发过程相反,自底向上,逐步集成过程,首先进行单元测试,排除模块间内部逻辑与功能上缺陷,然后按照软件设计需求进行集成测试排除子系统与模块上的错误,最后进行系统测试,检查其是否满足软件需求。

    常见软件测试模型

    软件测试模型对软件测试由指导作用,对测试结果和质量有很大影响;

    1,V模型

    V模型中的过程从左到右,描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
    在这里插入图片描述
    单元测试:是模块测试,验证软件的基本组成单位的正确性,是白盒测试
    集成测试:是模块间的测试,测试接口(软件各模块之间的接口和软件与硬件之间的接口)是否正确,是灰盒测试(白盒和黑盒结合)
    系统测试:系统测试包括:冒烟测试 系统测试 回归测试
    1)冒烟测试:主干流程测试,确认软件的基本功能正常,可以进行后续的测试工作
    2)系统测试:是检测系统的功能、质量、性能能否满足系统的要求,包括功能、性能、界面、可靠性、兼容性等等,是黑盒测试
    3)回归测试:修改了旧代码之后重新进行测试,确认修改后的代码没有引入新的错误或导致其他代码产生新的错误
    验收测试:是确保软件的实现能否满足用户的需求或合同的要求

    局限性:V模型是基于瀑布模型的,V模型有一个缺点,就是将测试放在整个开发的最后阶段,没有让测试今早介入开发,没有在需求阶段就进入测试。
    测试与开发串行

    2,W模型

    W模型是由两个V模型组成,一个是开发阶段,一个测试阶段
    W模型中开发和测试是并行的关系
    在这里插入图片描述
    优点:测试与开发并行,让测试今早介入开发环节,使测试今早发现问题今早解决。
    局限性:虽然开发与测试并行了,但是在整个开发阶段,仍然是串行的,上一阶段未完全完成无法进入下一阶段,不支持敏捷模式的开发。

    3,H模型

    H 模型将测试活动分离出来,形成一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来
    在这里插入图片描述
    H 模型提倡者认为测试是一个独立的过程中,所以在H 模型中并没有看到关于开发的过程,而是测试的一个流程,H 模型演示了在整个生命周期中某个层次上一次软件测试的“微循环”。
    在测试H 模型中有一个测试就绪点,也就是测试有一个准入条件

    通常情况下判断测试是否达到准入条件,应该检查以下几部分内容是否已经完成:
    该开发流程对应的测试策略是否完成;

     测试方案是否完成;
     测试用例是否完成;
     测试环境是否搭建好;
     相关输入件、输出件是否明确。

    也就是说,通常我们要检查上面一些内容是否完成,再确定我们是否需要进入下一个阶段的测试。当测试条件成熟,并且测试准备工作已经完成,进入了测试就绪点,测试执行活动才可以进行。

    H 模型的核心是将软件测试过程独立出来,并贯穿产品的整个生命周期,与开发流程并行进行,不需要等到程序全部开发完成才开始执行测试,这充分体现了软件测试要尽早准备、尽早执行的原则。

    H 模型具有以下特征

    1)测试是一个独立的过程;
    2)测试达到准入条件,才可以执行;
    3)测试对象是整个产品包,而不仅仅是程度、需求或相关说明书;

    4,X模型

    X 模型提倡探索性测试,指不进行事先计划的特殊类型的测试,这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误,避免把大量时间花费在编写测试文档上,导致真正用于测试的时间减少。
    左侧:
    X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后将进行频繁的交接,通过集成最终成为可执行的程序,然后再对这些可执行程序进行测试
    右侧:
    X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费,对测试员的熟练程度要求比较高。
    在这里插入图片描述
    X 模型具有以下特征:

    1)公司可以根据自身的情况确定是否要做单元测试,还是直接做系统测试;

    2)测试应该是一个不断迭代的过程,直到封版发布;

    3)提倡探索性测试

    5.软件测试原则

    公认的6个基本原则

    1)测试应基于客户需求:测试工作都应该建立在满足客户需求的基础上,从客户角度来看,最严重的错误就是软件无法满足要求。

    2)测试要尽早进行:软件的错误存在于软件生命周期的各个阶段,尽早开展测试工作,把软件测试贯穿到软件生命周期的各个阶段中,这样测试人员能够尽早地发现和预防错误,降低错误修复的成本,尽早地开展测试工作有利于帮助测试人员了解软件产品的需求和设计,从而预测测试的难度和风险,制订出完善的计划和方案,提高测试的效率

    3)穷尽测试是不可能的:由于时间和资源的限制,进行完全(各种输入和输出的全部组合)的测试是不可能的测试人员可以根据测试的风险和优先级等确定测试的关注点,从而控制测试的工作量,在测试成本、风险和收益之间求得平衡

    4)遵循GoodEnough原则:GoodEnough原则是指测试的投入与产出要适当权衡,形成充分的质量评估过程,这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量,但测试投入过多会造成资源的浪费

    5)测试缺陷要符合“二八”定理:缺陷的“二八”定理也称为Pareto原则、缺陷集群效应,一般情况下,软件80%缺陷会集中在20%模块中,缺陷并不是平均分布的。

    6)避免缺陷免疫:试用例被反复使用,发现缺陷的能力就会越来越差;测试人员对软件越熟悉越会忽略一些看起来比较小的问题,发现缺陷的能力也越差,这种现象被称为软件测试的“杀虫剂”现象。

    克服这种情况,就要不断对测试用例进行修改和评审,不断增加新的测试用例,同时,测试人员也要发散思维,不能只是为了完成测试任务而做一些输入和输出的对比

    软件测试基本流程

    为了是测试工作标准化、规范化、并且加速、高效、高质量的完成测试工作,需要定制具体的测试流程。

    1,软件测试流程

    **基本测试流程:**分析测试需求–制定测试计划–设计测试用例–执行测试–编写测试报告

    a:分析测试需求

    测试前拿到产品需求文档,进行需求分析及需求评审前先对需求文档进行详细的阅读,明确测试对象及测试工作的范围和测试重点。(获取些测试数据作为后面测试计划基本依据)
    此过程即软件需求测试,发现软件需求中不合理;如需求不清晰、需求优先级等,
    一般是根据软件开发需求文档制作软件需求规格说明书检查列表

    序号检查项检查结果说明
    1是否覆盖客户提出所有需求是【】否【】NA【】
    2用词是否清晰、用词是否存在歧义是【】否【】NA【】
    3是否清晰描述软件需要做什么及不做什么是【】否【】NA【】
    4是否描述了软件目标环境是【】否【】NA【】
    5是否对需求合理编号是【】否【】NA【】
    6需求前后一致,互不冲突是【】否【】NA【】
    7是否清楚描述软件每个输入、输出格式,以及输入输出关系是【】否【】NA【】
    8是否清晰的描述软件系统的性能要求是【】否【】NA【】
    9需求优先级分配是否合理是【】否【】NA【】
    10是否描述了各种约束条件是【】否【】NA【】
    b:制定测试计划

    测试工作贯穿于整个软件开发生命周期,需要定制一个完善且详细的测试计划指导书;测试计划是整个测试工作导航图,测试计划是个根据需求不断完善、不断调整的过程。
    工作安排:
    1)确定测试范围:对哪些是需要测试,哪些不需要测试
    2)制定测试策略:将测试内容划分为不同的优先级,并确定测试重点;是测试计划中最重要部分;
    3)安排测试资源:通过衡量测试难度、时间、工作量等因素对测试资源进行合理分配,包括人员、工具配置等
    4)安排测试进度:根据软件开发计划、产品整体计划安排工作进度与各部分工作的变化并预留缓冲时间
    5)预估测试风险:罗列出测试过程中可能出现的不确定因素,并制定应对策略;

    c:设计测试用例-test case

    测试用例是指一整套完整的测试方案;包括测试环境、测试步骤、测试数据、测试预期。
    用例原则:尽量以最少的用例达到最大的测试覆盖率。

    d:执行测试

    按照测试用例执行的过程,这是测试人员最主要活动阶段,执行测试时,根据测试优先级进行测试,每个用例都有可能出现缺陷,要做好测试记录与跟踪,衡量缺陷质量并编写报告;

    e:编写测试报告

    报告是对测试活动与项目测试过程的归纳,对测试数据进行统计,对项目质量进行客观的评价。
    测试报告包含:
    1)引言:描述测试报告编写目的、报告中出现的专业术语解释及参考资料
    2)测试概要:介绍项目背景、测试时间、测试地点人员信息
    3)测试内容及执行情况:描述本次测试模块的版本、类型、测试用例设计方法及测试通过率,依据测试通过率提供对策是执行过程的评估结论并给出测试活动的改进建议,以供后续测试执行活动的借鉴参考
    4)缺陷统计与分析:统计本次测试返现缺陷数目、类型等,分析缺陷产生原因,给出规避措施及建议,同时还要记录残留缺陷与为解决问题;
    5)测试结论及建议:从需求符合度、功能正确性、性能指标多个维度对质量进行整体的评估,给出具体明确的结论;

    2,测试准入标准与准出标准

    不同公司标准不同,一般标准
    1)测试准入标准
    开发人员编码结束,并已完成单元测试
    需求说明书规定的功能或开发人员提交的功能说明书的功能均已实现
    被测系统的基本流程可以走通,界面上的功能均实现,符合设计文档规定的功能。
    开发人员提交被测系统的最新版本,安装测试通过。
    开发人员向测试部提交《测试申请》。
    2)测试准出标准
    项目进度达到项目规定的上线时间或下个阶段时间
    项目过程中Bug的提交数量和修复率满足要求
    严重的Bug全部修复,其他Bug评估不解或可以遗留到下个阶段解决
    测试未通过,但项目和产品经理特批上线

    3,软件测试暂停、停止标准

    1)测系统在进行系统测试时,发现程序存在重大bug,堵塞测试
    2)被测项目需暂停以进行调整时,测试应随之暂停,并备份暂停点数据
    3)存在其他优先级更高的任务时,可向领导申请暂停测试
    4)被测项目在其开发生命周期内出现重大估算、进度偏差,需暂停或终止时,测试应随之暂停或终止,并备份暂停或终止点数据归档
    5)被测系统经过系统测试,达到系统测试准出标准,可以停止测试
    6)被测系统经过系统测试,并已产出系统测试总结报告,可以停止测试

    demo实例

    单车app开锁用车功能测试流程

    在这里插入图片描述

    1,骑行、分析测试需求

    测试功能:开锁用车
    方式:扫码与输入编号
    夜间:需要使用手电筒功能
    测试内容:
    a:扫二维码开锁
    b:输入编号开锁
    c:调用手电筒

    2,制定测试计划

    测试计划的安排,制定测试计划书。
    单车开锁功能测试计划(表格测试计划其中一部分)

    软件版本V2.2.1
    模块开锁用车
    负责人测试组长
    测试人员测试人员1、2
    测试计划2021.6.6-2-21.7.6
    测试用例001–12
    回归测试时间2021.7.7-2021.7.13

    3,设计测试用例

    实际用法场景,
    1)白天:扫码
    2)白天:输入编码
    3)夜里:扫码+手电筒
    4)夜里:输入编码+手电筒
    对于订单正在使用考虑三个状态:正在骑行,未支付,未使用状态
    单车app开锁功能

    序号用例说明前置操作操作预期结果备注
    001开锁无运行订单、无待支付订单白天+扫码进入解锁界面
    002开锁正在运行订单白天+扫码无法开锁,提示正在骑行并支付
    003开锁待支付订单白天+扫码无法开锁,提示支付
    004开锁无运行订单、无待支付订单白天+输入编码进入解锁界面
    005开锁正在运行订单白天+输入编码无法开锁,提示正在骑行并支付
    006开锁待支付订单白天+输入编码无法开锁,提示支付
    007开锁无运行订单、无待支付订单夜里+扫码+手电筒进入解锁界面
    008开锁正在运行订单夜里+扫码+手电筒无法开锁,提示正在骑行并支付
    009开锁待支付订单夜里+扫码+手电筒无法开锁,提示支付
    010开锁无运行订单、无待支付订单夜里+输入编码+手电筒进入解锁界面
    011开锁正在运行订单夜里+输入编码+手电筒无法开锁,提示正在骑行并支付
    012开锁待支付订单夜里+输入编码+手电筒无法开锁,提示支付

    4,执行测试用例

    执行测试用例,对测试过程记录与跟踪。对于缺陷整理成缺陷报告。上述012 测试为符合预期,即整理成缺陷报告
    单车app开锁功能测试缺陷报告

    缺陷ID20210505-app-open-lock-012
    测试软件名称单车app
    软件测试版本V2.2.1
    缺陷发现日期20210606
    测试人员XXX
    缺陷描述前置条件:有待支付订单,1,夜里+输入编码+手电筒,2,提示锁已打开
    附件截图或者报错信息
    缺陷类型功能性
    缺陷严重程度严重
    缺陷优先级立即解决
    测试环境手机版本、手机配置、操作系统
    重现步骤有未完成订单,1,进入app扫码开锁 2,输入编码+手电筒 ,点击使用开锁 ,提示锁已打开

    5,编写完整的测试报告

    本次测试结束后(包含回归测试),需要编写一个完整的测试报告,
    注意:一般为很多页的word或者在软件测试管理工具里写

    单车app用车测的测试报告

    • 一:引言
      • 1,目的
      • 2,术语
      • 3,参考资料
    • 二:测试概要
      • 1,项目简介
      • 2,测试环境
      • 3,测试时间、地点、人员
    • 三:测试内容及执行情况
      • 1,测试目标
      • 2,测试范围
      • 3,测试用例使用情况
      • 4,回归测试
    • 四:缺陷统计与分析
      • 1,缺陷数目与类别
      • 2,缺陷解决情况
      • 3,缺陷趋势分析
    • 五:测试分析
      • 1 ,测试覆盖率分析
      • 2,需求符合度分析
      • 3,功能正确性分析
      • 4,产品质量分析
      • 5,测试局限性
    • 六:测试总结
      • 1,遗留问题
      • 2,测试经验总结
    • 七:附件
      • 1,测试用例清单
      • 2,缺陷清单
      • 3,交付的测试工作产品
      • 4,遗留问题报告
    题外话:什么是Sprint?

    Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint

    Scrum的几个名词?

    backlog: 可以预知的所有任务, 包括功能性的和非功能性的所有任务。

    sprint:一次跌代开发的时间周期,一般最多以30天为一个周期.在这段时间内,开发团队需要完成一个制定的backlog,并且最终成果是一个增量的,可以交付的产品。

    sprint backlog:一个sprint周期内所需要完成的任务。

    scrumMaster: 负责监督整个Scrum进程,修订计划的一个团队成员。

    time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

    sprint planning meeting: 在启动每个sprint前召开。一般为一天时间(8小时)。该会议需要制定的任务是:产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块,确定好这个Product Backlog的任务优先级。另外,该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

    Daily Scrum meeting:开发团队成员召开,一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目:今天完成了什么? 是否遇到了障碍? 即将要做什么?通过该会议,团队成员可以相互了解项目进度。

    Sprint review meeting:在每个Sprint结束后,这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

    Sprint retrospective meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时

    补充:测试理论知识

    软件测试的基本理论-黑盒测试-1

    展开全文
    weixin_42914706 2021-06-03 01:16:01
  • 软件测试,听起来好像是很简单的一门技术,但是通过这两天的学习,才发现软件测试不止是要懂得软件测试的定义,更要去掌握一些开发的语言,不然你在这一行只会不进反退,得不到任何的提升,而我们在懂得开发的语言...
    		                  学习软解测试第二天
    软件测试,听起来好像是很简单的一门技术,但是通过这两天的学习,才发现软件测试不止是要懂得软件测试的定义,更要去掌握一些开发的语言,不然你在这一行只会不进反退,得不到任何的提升,而我们在懂得开发的语言之前,我们首先要懂得软件测试的定义。
    所谓软件测试的定义,即使用人工或自动手段,来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
    而测试要做的事情就是找bug,也就是我们所谓的找茬,而我们历史上留名的万虫之母,是1947年9月9日下午3点45分,Grace Murray Hopper在她的记录本上记下了史上第一个计算机Bug—— 在Harvard Mark II计算机里找到的一只飞蛾,她把蛾贴在日记本上,并写道”First actual case of bug being found”。这个发现奠定了Bug这个词在计算机世界的地位。从这个案例中可以看出,bug不止会让程序员崩溃,甚至会让整个程序都崩溃,所以对于一个软件而言,今早找到bug有多重要,也可以看出测试有多重要。
    而我们所使用的软件中都存在一定的缺陷,而产生这些缺陷的原因,最主要还是在于缺少沟通或者不进行沟通,也说明要做测试必须要有一定的沟通技巧,这样才能在这一行做得更好。
    
    展开全文
    fairyhl 2021-04-13 18:22:28
  • 三、软件测试工程师的工作内容四、常见的软件生命周期模型五、软件开发的几个阶段六、软件bug的五个要素七、软件测试的分类八、什么是测试用例九、测试用例几大要素【面试理论知识】1、你的测试职业发展是什么?...

    文章目录

    一、什么是软件?

    软件是计算机系统中的程序和相关文件或文档的总称。

    二、什么是软件测试?

    说法一:使用人工或自动的手段来运行或测量软件系统的过程,以检验软件系统是否满足规定的要求,并找出与预期结果之间的差异。

    说法二:软件测试就是利用一定的方法对软件的质量或者使用性进行判断和评估的过程。

    三、软件测试工程师的工作内容

    1.寻找软件中的bug,并且越早发现越好

    2.确认bug的可重复性以及bug产生的步骤

    3.确认bug是否被解决

    4.测试方法,测试计划,测试平台,测试代码,测试用例,测试文档,测试报告的确定、编写和执行。

    四、常见的软件生命周期模型

    1.大爆炸模型:优点:简单,不用学习就会。缺点:产品质量无法保障,尽量避免使用

    2.边做边改模型:优点:快速得到可运行的版本。缺点:计划有些缺乏,导致版本前后变化较大

    3.瀑布模型:优点:计划周密,专业,按部就班实现。缺点:相对难于做到快速开发,以抢占市场,可选择的模型之一

    4.螺旋模型:优点:计划变化同事考虑。

    五、软件开发的几个阶段

    1.项目启动阶段:了解客户需求、配置相关资源

    2.项目设计阶段:明确客户需求,确立软件开发、测试的方法

    3.项目执行阶段:开发与测试阶段

    4.项目竣工阶段:软件的上市、后期维护与技术支持

    六、软件bug的五个要素

    1.软件没有实现说明书中所列出的功能

    2.软件出现了说明书中提到不应该出现的事情

    3.软件没有实现说明书中没有提到但应该实现的事情

    4.软件非常难于学习、使用,运转速度很慢,用户认为无法达到预期

    七、软件测试的分类

    1.黑盒测试:对软件内部如何实现不了解,以外部的视角来视察软件。

    黑盒测试方法:等价类边界值,因果图,判定表,错误推测法

    2.白盒测试:白盒测试与黑盒测试相反,需要了解软件中的结构。白盒测试也叫结构化测试,玻璃盒测试。

    黑盒测试与白盒测试的优缺点

    黑盒测试,优点:不需要了解软件实现细节,软件内部实现机制更改时,一般不必修改用例实现相对简单,以用户角度出发

    缺点:无法保证软件代码内各主要路径都被覆盖到,容易导致测试不很完全

    白盒测试,优点:针对软件代码和路径进行测试,相对易于调试,容易发现bug产生的原因

    缺点:对测试人员的编程能力要求高,软件实现代码改变,测试用例一般也需要改变。

    3.功能测试

    4.兼容性测试

    5.性能测试

    6.安全测试

    7.压力测试

    八、什么是测试用例

    测试用例是描述输入实际值和预期输出行为或者结果的文档,他同时也标识了测试过程结果与约束。

    九、测试用例几大要素

    标识符,测试内容,输入条件,预期结果,测试环境信息,与其他测试用例的依赖关系,测试用例需要被开发、审阅、使用、维护和保存。

    软件测试方法分类

    1)白盒、黑盒、灰盒

    2)单元测试、集成测试、系统测试、验收测试、回归测试、Alpha 测试、Beta 测试

    3)静态测试和动态测试

    设计测试用例的主要方法

    1)等价类划分

    2)边界值分析法

    3)因果图法

    4)场景法

    【面试理论知识】

    1、你的测试职业发展是什么?

    测试经验越多,测试能力越高。所以我的职业发展是需要时间积累的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年积累测试经验,按如何做好测试工程师的要点去要求自己,不断更新自己改正自己,做好测试任务。

    2、你认为测试人员需要具备哪些素质

    做测试应该要有一定的协调能力,因为测试人员经常要与开发接触处理一些问题,如果处理不好的话会引起一些冲突,这样的话工作上就会不好做。还有测试人员要有一定的耐心,有的时候做测试很枯燥乏味。除了耐心,测试人员不能放过每一个可能的错误。有好奇心,乐于探索软件功能,乐于尝试新的软件产品。具备一定的程序开发经验。

    3、你为什么能够做测试这一行

    虽然我的测试技术还不是很成熟,但是我觉得我还是可以胜任软件测试这个工作的,因为做软件测试不仅是要求技术好,还有有一定的沟通能力,耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。

    4、测试的目的是什么?

    测试的目的是找出软件产品中的错误,是软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的。

    5、测试分为哪几个阶段?

    一般来说分为5个阶段:单元测试、集成测试、确认测试、系统测试、验收测试

    6、单元测试的测试对象、目的、测试依据、测试方法?

    测试对象是模块内部的程序错误,目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计,测试方法是采用白盒测试。

    7、怎样看待加班问题

    加班的话我没有太多意见,但是我还是觉得如果能够合理安排时间的话,不会有太多时候加班的。

    8、结合你以前的学习和工作经验,你认为如何做好测试。

    根据我以前的工作和学习经验,我认为做好工作首先要有一个良好的沟通,只有沟通无障碍了,才会有好的协作,才会有更好的效率,再一个就是技术一定要过关,做测试要有足够的耐心,和一个良好的工作习惯,不懂的就要问,实时与同事沟通这样的话才能做好测试工作。

    9、你为什么选择软件测试行业

    因为之前了解软件测试这个行业,觉得他的发展前景很好。

    10、根据你以前的工作或学习经验描述一下软件开发、测试过程,由哪些角色负责,你做什么

    要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执行测试用例。

    11、根据你的经验说说你对软件测试/质量保证的理解

    软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果),并根据这些测试用例去运行程序,以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。

    12、软件测试的流程是什么?

    需求调查:全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。

    制定初步的项目计划。

    测试准备:组织测试团队、培训、建立测试和管理环境等。

    测试设计:按照测试要求进行每个测试项的测试设计,包括测试用例的设计和测试脚本的开发等。

    测试实施:按照测试计划实施测试。

    测试评估:根据测试的结果,出具测试评估报告。

    13、你对SQA的职责和工作活动(如软件度量)的理解?

    SQA就是独立于软件开发的项目组,通过对软件开发过程的监控,来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案,必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入,从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划,参与阶段产物的评审,进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等。

    14、说说你对软件配置管理的理解

    项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制,配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大,配置管理就越显得重要。还有在配置管理中,有一个很重要的概念,那就是基线,是在一定阶段各个配置项的组合,一个基线就提供了一个正式的标准,随后的工作便基于此标准,并只有经过授权后才能变更这个标准。配置管理工具主要有CC,VSS,CVS,SVN等,我只用过SVN,对其他的工具不是很熟悉。

    15、怎样写测试计划和测试用例

    简单点,测试计划里应有详细的测试策略和测试方法,合理详尽的资源安排等,至于测试用例,那是依赖于需求(包括功能与非功能需求)是否细化到功能点,是否可测试等。

    16、说说主流的软件工程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的大致情况及对他们的理解

    CMM:SW Capability Maturity Model软件能力成熟度模型,其作用是软件过程的改进、评估及软件能力的评鉴。

    CMMI:Capability Maturity Model Integration能力成熟度模型集成 CMMI融入了大部分最新的软件管理实践,同时弥补了SW-CMM模型中的缺陷。

    RUP:rational unified process是软件工程话过程。

    XP:extreme program,即极限编程的意思,适用于小型团队的软件开发,像上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性,强调测试(重点是单元测试)先行的理念。编程可以明显提高代码的质量,持续集成对于快速定位问题有好处。

    PSP,TSP分别是个体软件过程和群体软件过程。大家都知道,CMM只是告诉你做什么但并没有告诉你如何做,所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做,PSP强调建立个人技能(如何制定计划、控制质量及如何与其他人相互协作等等)。而TSP着重于生产并交付高质量的软件产品(如何有效的规划和管理所面临的项目开发任务等等)。总之,实施CMM,永远不能真正做到能力成熟度的提升,只有将实施CMM与实施PSP和TSP有机结合起来,才能发挥最大的效力。因此,软件过程框架应该是CMM/PSP/TSP的有机集成。

    17、你是怎样保证软件质量的,也就是说你觉得怎样才能最大限度的保证软件的质量?

    测试并不能够最大限度的保证软件的质量,软件的高质量是开发和设计出来的,而不是测试出来的,它不仅要通过对软件开发流程的监控,使得软件开发的各个阶段都要按照指定的规程进行,通过对各个阶段产物的评审,QA对流程的监控,对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式,是软件质量保证工程的一个重要组成部分。

    18、基于目前中国的国情,大多数公司的项目进度紧张、人员较少、需求文档根本没有或者很不规范,你认为在这种情况下怎样保证软件的质量?(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量,因为这些公司一般就是这种情况–既不想投入过多又想保证质量)

    出现以上的情况,如果仅仅想通过测试来提高软件质量,那几乎是不可能的,原因是没有足够的时间让你去测试,少而不规范的文档导致测试需求无法细化到足够且有针对行的测试。所以,作为公司质量保证的因该和项目经理确定符合项目本身是和的软件生命周期模型(比如RUP的建材,原型法),明确项目的开发流程并督促项目组按照此流程开展工作,所有项目组成员(项目经理更加重要)都要制定出合理的工作计划,加强代码的单元测试,在客户既定的产品交付日期范围内,进行产品的持续集成等等,如果时间允许可以再配合客户进行必要的系统功能测试。

    19、一个测试工程师应该具备哪些素质和技能?

    1-掌握基本的测试基础理论

    2-本着找出软件存在的问题的态度进行测试,不要以挑刺的形象出现

    3-可熟练阅读需求规格说明书等文档

    4-以用户的观点看问题

    5-有强烈的质量意识

    6-细心和责任心

    7-良好的有效的沟通方式(与开发人员及客户)

    8-具有以往的测试经验能够及时准确的判断出高危险区在何处

    20、做好软件测试的一些关键点

    1-测试人员必须经过测试基础知识和理论的相关培训

    2-测试人员必须熟悉系统功能和业务

    3-测试要有计划,而且测试方案要和整个项目计划协调好

    4-必须实现编写测试用例,测试执行阶段必须根据测试用例进行

    5-易用性,功能,分支,边界,性能等功能行和非功能性需求都要进行测试

    6-对于复杂的流程一定要进行流程分支,组合条件分析,再进行等价类划分准备相关测试数据

    7-测试设计的一个重要内容是要准备好具体的测试数据,清楚这个测试数据是测试那个场景或分支的。

    8-个人任务平均每三个测试用例至少应该发现一个BUG,否则只能说明测试用例质量不好

    9-除了每天构建的重复测试可以考虑测试自动化外,其他暂时都不要考虑去自动话

    21、软件测试员自身素质培养

    1-首先,应对软件测试感兴趣和对自己有自信,如果具备了这两点,那么在开发过程中不管遇到什么样的困难,相信一定能克服

    2-善于怀疑,实际上没有绝对正确的,总有错误的地方,具有叛逆心理,别人认为不可能发生的事情,我却认为可能发生,别人认为是对的,我却认为不是对的。

    3-打破沙锅问到底的精神,对于只出现过一次的BUG一定要找出原因,不解决誓不罢休。

    4-保持一个良好的心情,否则可能无法把测试做好。不要把生活中的不愉快的情绪带到工作中来。

    5-做测试时要细心,不是所有的BUG都能很容易找出,一定要细心才能找到这些BUG。

    6-灵活一些,聪明一点,多造一些容易产生BUG的例子。

    7-在有条件的情况下,多和客户沟通,他们身上有你所需要的。

    8-设身处地为客户着想,从他们的角度去测试系统。

    9-不要让程序员,以“这种情况不可能发生”这句话说服你,相反,你应该去说服他,告诉他在客户心理,并不是这样的

    10-考虑问题要全面,结合客户的需求,业务流程和系统的架构等多方面考虑问题。

    11-提出问题不要复杂化,这点和前面矛盾,如果你是一个新手,暂时不要管这点,因为最终将有你的小组成员讨论解决。

    12-追求完美,对于新测试员来说,努力追求完美,这对你很好,尽管有些事情无法做到,但你应该尝试。

    13-幽默感,能和开发小组很好的沟通是关键,试着给你的开发小组找一个BUG杀手,或对他们说“我简直不敢相信,你写的程序居然到现在没有找到BUG”。

    22、为什要在一个团队中开展测试工作?

    因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量认证,这个时候就需要在团队中开展软件测试的工作。在测试的过程中发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。

    23、你所熟悉的软件测试类型有哪些?

    测试类型有:功能测试、性能测试、界面测试

    功能测试在测试工作中占有比例最大,功能测试也叫黑盒测试。

    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。

    界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。

    区别在于,功能测试关注产品的所有功能,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容,用户使用该产品的时候是否已用,是否易懂,是否规范(用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)。做某个性能测试的时候,首先它可能是个功能点,首先要保证她的功能是没有问题的,然后再考虑性能的问题。

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

    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结构。黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题。软件的黑盒测试意味着测试要在软件的接口处进行,这种方法是把测试对象看作是一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或者数据驱动测试。黑盒测试主要是为了发现以下几类错误:、

    1-是否有不正确或遗漏的功能

    2-在接口上,输入是否能正确的接受?能否输出正确的结果。

    3-是否有数据结构错误或外部信息(例如数据文件)访问错误

    4-性能上是否能够满足要求

    5-是否有初始化或终止性错误

    软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子,它允许测试人员利用程序内部的逻辑结构和有关信息,设计或者选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一直。因此白盒测试又称为结合测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:

    1-对程序模块的所有独立的执行路径至少测试一遍。

    2-对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。

    3-在循环的边界和运行的界限内执行循环体。

    4-测试内部数据结构的有效性,等等。

    25、请详细介绍一下各种测试类型的含义

    1-单元测试(模块测试)是开发者编写的一小段代码,用于检验被测试代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。

    2-集成测试(也叫组装测试、联合测试)是单元测试的逻辑扩展。它最简单的形式是:两个已经经过测试的单元组合成一个组件,并且测试它们之间的接口。从这一层上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。

    3-系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中制定功能的有效方法。(常见的联调测试)。系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求而遵循系统设计。

    4-验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让用户将其执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预订要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。

    26、测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?

    软件测试计划是知道测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法(最好能先评审)。

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

    1-明确测试的目标,增强测试计划的实用性

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

    2-坚持“5W”规则,明确内容与过程

    “5W”规则指的是“WHAT(做什么)”、“WHY(为什么做)”、“WHEN(何时做)”、“WHERE(在哪里)”、“HOW(如何做)”。利用“5W"规则创建软件测试计划,可以帮助测试团队理解测试的目的(WHY),明确测试的范围和内容(WHAT),确定测试的开始和结束日期(WHEN),指出测试的方法和工具(HOW),给出测试文档和软件存放的位置(WHERE)。

    3-采用评审和更新机制,保证测试计划满足实际需求

    测试计划完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。

    4-分别创建测试计划与测试详细规格、测试用例

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

    28、当开发人员说不是BUG时,你如何应付?

    开发人员说不是BUG,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动。3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的一句是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是BUG,我也只是建议的方式写进测试文档中,如果开发人员不修改也没有大问题。如果不是BUG的话,一定要坚持自己的立场,让问题得到最后的确认。

    29、你自认为测试的优势在哪里?

    优势在于我对测试坚定不移的信心和热情,虽然经验还不足,但测试需要的基本技能我有信心在工作中得以发挥。

    30、什么是系统瓶颈?

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

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

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

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

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

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

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

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

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

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

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

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

    32、功能测试用例需要详细到什么程度才是合格的?

    这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来,目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子:欧美、日本等软件外包文档都是这样做的。

    另外一种观点就是主张写的粗些,类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范,变动十分频繁,因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护,可以让测试执行人员有更大的发挥空间。

    实际上,软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子:“用户登陆系统”的测试用例可以不写出具体的执行数据,但是至少要写出五种以上情况(),如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点,而是要写出功能点的各个方面(如果组合情况较多时可以采用等价划分)。

    另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后,编写较详细的测试用例是不现实的,因为根本没有那么大的资源投入,当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求,如果进度较紧张的情况下,是根本没有时间写出高质量的测试用例的,甚至有些时候测试工作只是一种辅助工作,因而不编写测试用例。

    因此,测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨,力争在不断提高测试用例编写水平的同时,不断地提高自身能力。

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

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

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

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

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

    (3)不同的外设;

    (4)不同的接口;

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

    兼容性测试的核心内容:

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

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

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

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

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

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

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

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

    -包装文字和图形;

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

    -授权、注册登记表;

    -最终用户许可协议;

    -安装和设置向导;

    -用户手册;

    -联机帮助;

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

    -……

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

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

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

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

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

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

    -拼写和语法;

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

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

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

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

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

    36、测试中的“杀虫剂怪事”是指什么?

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

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

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

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

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

    38、为什么尽量不要让时间有富裕的员工去做一些测试?

    表面上看这体现了管理的效率和灵活性,但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心,善于学习、思考和发现问题,细心有条理,总结问题,如果具备这样的优点,做其它工作同样也会很出色,因此这里还有一个要求,就是要喜欢测试这项工作。如果他是专职的,那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员,两者工作性质不同,待遇不同,地位不同,对自我实现的价值的认识也不同,这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务,或者发现了几个问题就觉得满意了,这在任何其它工作中都是不行的。

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

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

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

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

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

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

    -软件实现途径太多;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    43、软件测试人员就是QA吗?

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

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

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

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

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

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

    45、测试产品与测试项目的区别是什么?

    习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品,也就是可以买“卖拷贝”的软件,例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目,软件项目是一种个性化的产品,可以是按照用户要求全部重新开发,也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点,决定我们测试产品和测试项目仍然会有很多不同的地方:

    -质量要求不同。通常产品的质量要高一些,修复发布后产品的缺陷成本较高,甚至会带来很多负面的影响。而做项目通常面向某一用户,虽然质量越高越好,但是一般只要满足用户要求就可以了。

    -测试资源投入多少不同。做软件产品通常是研发中心来开发,进度压力要小些。同时由于质量要求高,因此会投入较多的人力、物力资源。

    -项目最后要和用户共同验收测试,这是产品测试不具有的特点。

    此外,测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同,测试管理者应该结合具体的环境,恰如其分的完成工作。

    46、和用户共同测试(UAT测试)的注意点有哪些?

    软件产品在投产前,通常都会进行用户验收测试。如果用户验收测试没有通过,直接结果就是那不到“Money”,间接影响是损害了公司的形象,而后者的影响往往更严重。根据作者的经验,用户验收测试一定要让用户满意。

    实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下,我们向用户展示我们软件的优点,最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项:

    (1)用户现场测试不可能测试全部功能,因此要测试核心功能。这需要提前做好准备,这些核心功能一定要预先经过测试,证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多,不应该进行演示。

    (2)如果某些模块确实有问题,我们可以演示其它重要的业务功能模块,必要时要向用户做成合理的解释。争得时间后,及时修改缺陷来弥补。

    (3)永远不能欺骗用户,蒙混过关。道理很简单,因为软件是要给用户用的,问题早晚会暴露出来,除非你可以马上修改。

    和用户进行测试还要注意各种交流技巧,争取不但短期利益得到了满足,还要为后面得合作打好基础。

    47、如何编写提交给用户的测试报告?

    随着测试工作越来越受重视,开发团队向客户提供测试文档是不可避免的事情。很多人会问:“我们可以把工作中的测试报告提供给客户吗?”答案是否定的。因为提供内部测试报告,可能会让客户失去信心,甚至否定项目。

    测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档,反映了测试工作的实施情况,这里不过多讨论,读者可以参考相关教材。这里主要讨论一下外部测试报告的写法,一般外部测试报告要满足下面几个要求:

    -根据内部测试报告进行编写,一般可以摘录;

    -不可以向客户报告严重缺陷,即使是已经修改的缺陷,开发中的缺陷也没有必要让客户知道;

    -报告上可以列出一些缺陷,但必须是中级的缺陷,而且这些缺陷必须是修复的;

    -报告上面的内容尽量要真实可靠;

    -整个测试报告要仔细审阅,力争不给项目带来负面作用,尤其是性能测试报告。

    总之,外部测试报告要小心谨慎的编写。

    48、测试工具在测试工作中是什么地位?

    国内的很多测试工程师对测试工具相当迷恋,尤其是一些新手,甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用,一般用来提高测试效率。自动化测试弥补了手工测试的不足,减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的,而一些诸如性能测试等自动化测试也是手工所不能完成的。

    对于自动测试技术,应当依据软件的不同情况来分别对待,一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具,或者自己开发测试程序。一定不要为了使用测试工具而使用。

    49、常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

    1-等价类划分

    常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

    2-边界值分析法

    边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

    使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

    3-错误推测法

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

    错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例-例如, 在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.

    4-因果图方法

    前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等-考虑输入条件之间的相互组合,可能会产生一些新的情况-但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多-因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例-这就需要利用因果图(逻辑模型)-因果图方法最终生成的就是判定表-它适合于检查程序输入条件的各种组合情况.

    5-正交表分析法

    有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。

    6-场景分析方法

    指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。

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

    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题

    51、详细的描述一个测试活动完整的过程。

    1-项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后sqa进入项目,开始进行统计和跟踪

    2-开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。

    3-测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

    4-测试用例完成后,测试和开发需要进行评审。

    5-测试人员搭建环境

    6-开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现bug后提交给bugzilla。

    7-开发提交第二个版本,包括bug fix以及增加了部分功能,测试人员进行测试。

    8-重复上面的工作,一般是3-4个版本后bug数量减少,达到出货的要求。

    9-如果有客户反馈的问题,需要测试人员协助重现以及回归测试。

    52、以往是否曾经从事过性能测试工作?请尽可能的详细描述您以往的性能测试工作的完整过程。

    曾经做过一套网管系统的性能测试,主要测试该软件在同时管理大量终端的情况下,在响应时间,cpu/磁盘/内存等参数是否满足要求。

    也曾经做过软交换系统的呼叫性能测试,主要是测试软交换系统在有大量呼叫的情况下,响应时间,呼叫成功率,cpu/磁盘/内存等参数是否满足设计要求。

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

    1-在传统的bugzilla中,bug描述应该包括以下的信息

    2-和bug产生对应的软件版本

    3-开发的接口人员

    4-bug的优先级

    5-bug的严重程度

    6-bug可能属于的模块,如果不能确认,可以用开发人员来判断

    7-bug标题,需要清晰的描述现象

    8-bug描述,需要尽量给出重新bug的步骤

    9-bug附件中能给出相关的日志和截图。

    高质量的bug记录就是指很容易理解的bug记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。

    54、您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

    测试网管系统中,使用的mimic来模拟终端,能够大量的节省成本。

    测试软交换系统的时候,使用的prolab来模拟终端并发送呼叫软交换,他完成了同时数百人才能完成的摘机拨号工作,主要工作原理是产生一些符合要求的ip包并发送给软交换系统,同时对软交换系统的回应进行处理,决定下一步动作。

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

    主要是保障在大量用户的情况下,服务能正常使用。

    56. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

    黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
      白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
      软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
    黑盒测试主要是为了发现以下几类错误:
      1、是否有不正确或遗漏的功能?
      2、在接口上,输入是否能正确的接受?能否输出正确的结果?
      3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
      4、性能上是否能够满足要求?

    57、是否有初始化或终止性错误?

    软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:
      1、对程序模块的所有独立的执行路径至少测试一遍。
      2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。
      3、在循环的边界和运行的界限内执行循环体。
      4、测试内部数据结构的有效性,等等。
      单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
      单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
      集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:
      两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。
      系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)
      系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
      验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
      验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。

    58、测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?

    软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试
      实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
      测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
      所以其中最重要的是测试测试策略和测试方法(最好是能先评审)

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

    1. 明确测试的目标,增强测试计划的实用性
      编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
      2.坚持“5W”规则,明确内容与过程
      “5W”规则指的是“What (做什么)”、“Why (为什么做)”、“When (何时做)”、“Where(在哪里)”、“How (如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why ),明确测试的范围和内容(What ),确定测试的开始和结束日期(When ),指出测试的方法和工具(How ),给出测试文档和软件的存放位置(Where )。
      3.采用评审和更新机制,保证测试计划满足实际需求
      测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
      4. 分别创建测试计划与测试详细规格、测试用例
      应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

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

    1.等价类划分
      划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的
      输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
      2.边界值分析法
      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
      3.错误推测法
      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况.
      输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
      4.因果图方法
      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的
    组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

    61、您以往是否曾经从事过性能测试工作?如果有请尽可能的详细描述您以往的性能测试工作的完整过程。

    是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2 个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。
      性能测试类型包括负载测试,强度测试,容量测试等
      负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
      强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况
      容量测试:确定系统可处理同时在线的最大用户数
      在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比),
      Web 服务器指标指标:
      * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数;
      * Successful Rounds:成功的请求;
      * Failed Rounds :失败的请求;
      * Successful Hits :成功的点击次数;
      * Failed Hits :失败的点击次数;
      * Hits Per Second :每秒点击次数;
      * Successful Hits Per Second :每秒成功的点击次数;
      * Failed Hits Per Second :每秒失败的点击次数;
      * Attempted Connections :尝试链接数;

    62、系统测试是什么?需要考虑哪些方面?

    1)系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起,进行信息系统的各种组装测试和确认测试,其目的是通过与系统的需求相比较,发现所开发的系统与用户需求不符或矛盾的地方,从而提出更加完善的方案.。

    2)它的的任务是尽可能彻底地检查出程序中的错误,提高软件系统的可靠性,其目的是检验系统"做得怎样?"。这阶段又可分为三个步骤:模块测试,测试每个模块的程序是否有错误;组装测试,测试模块之间的接口是否正确;确认测试,测试整个软件系统是否满足用户功能和性能的要求。该阶段结束应交付测试报告,说明测试数据的选择,测试用例以及测试结果是否符合预期结果。

    3)测试发现问题之后要经过调试找出错误原因和位置,然后进行改正。是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。

    4)系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不相符合或与之矛盾的地方。

    系统测试的对象不仅仅包括需要测试的产品系统的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此,必须将系统中的软件与各种依赖的资源结合起来,在系统实际运行环境下来进行测试

    63、怎样才能成为一个合格的软件测试工程师?

    1)计算机专业技能

    2)测试专业技能

    3)软件编程技能

    4)网络、操作系统、数据库、中间件等知识

    5)较强的责任心,对待测试工作要有不厌其烦的态度,与需求人员、研发人员多交流多沟通

    64、一名军官要求24名士兵站成6排,每排都是5人,士兵们全犯傻了。最后一名士兵终于想出了一个好办法。他是怎样安排的?

    只要排成一个六边形即可

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

    了解项目或系统的业务需求

    和项目经理协调好,了解项目的进度计划安排情况

    66、软件测试的流程是什么?

    需求调查: 全面了解您的系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等

    根据系统概况进行项目所需的人员、时间和工作量估计及项目报价。

    制定初步的项目计划: 在与您充分共同和协商的基础上制定我们的测试计划。

    测试准备: 组织测试团队、培训、建立测试和管理环境等。

    测试设计: 按照测试要求进行每个测试项的测试设计,包括测试用例的设计及测试脚本的开发等。

    测试实施: 按照测试计划进行实施测试。

    测试评估: 根据测试的结果,出具测试评估报告。

    67、最后的图文总结

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    Over~在这里插入图片描述

    展开全文
    weixin_43750377 2021-02-25 10:47:13
  • weixin_39563823 2021-07-23 05:21:06
  • weixin_39994296 2021-07-23 14:04:23
  • qq_42434318 2021-01-05 16:10:40
  • liboshi123 2021-02-14 11:11:59
  • guiyin1150 2021-01-23 17:00:59
  • qq_44239848 2021-07-22 17:25:25
  • drift_yu 2021-08-24 22:05:04
  • yutian8233 2021-07-05 10:11:39
  • weixin_31136061 2021-07-23 07:20:44
  • weixin_43757056 2021-03-21 13:39:04
  • lucylily11 2021-05-09 16:55:12
  • weixin_39883670 2020-12-21 07:44:17
  • u010098760 2021-01-05 15:50:44
  • m0_58026506 2021-09-02 15:00:56
  • xuyandics 2020-12-29 08:37:18
  • weixin_44006992 2021-04-27 17:19:38
  • Franciz777 2021-02-22 09:07:44
  • q22q1 2021-01-13 20:39:45
  • feng8403000 2021-03-27 23:44:30
  • zhangmingcai 2021-03-19 20:26:37
  • qq_39291028 2021-09-03 15:50:22
  • jiangjunsss 2021-08-09 21:22:37
  • qq_44844993 2021-02-02 10:17:11
  • weixin_42511177 2021-07-23 13:30:41
  • m0_53918927 2021-06-15 15:26:10

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 80,906
精华内容 32,362
关键字:

软件测试基本理论知识

友情链接: 紫日2037源代码.zip