2017-09-28 17:05:53 mcfnhm 阅读数 471
  • 从零学习selenium2(WebDriver)自动化测试系列视频...

    通过案例讲解及其演示,掌握使用java语言开发测试脚本的技术,包括数据驱动脚本、关键字驱动脚本等,如何对自动化测试脚本进行有效管理和维护; 让学员正确地、全面地理解“软件测试框架自动化框架”概念,并基本掌握其各个部分的设计、实现及其应用场合; 清楚如何在自己团队实施自动化测试的工作,从组织、流程、技术等多个方面来保证自动化测试的成功实施,终掌握如何构建自动化测试框架及平台。

    10878 人正在学习 去看看 任健勇

定义

  • 在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。

  • 测试就是发现错误而执行程序的过程。


原则

  1. 保证测试的覆盖度,但是穷举测试是不可能的。

  2. 所有的测试都应该追溯到用户。

  3. 越早测越好,测试过程与开发过程应该是互相结合的。

  4. 测试的规模 从小到大,从单元测试到系统测试。

  5. 不能为了便于测试而擅自修改程序。

  6. 既应该测试软件能做什么,也应该测试软件不能做什么。


度量

  • 测试覆盖率

  • 缺陷发现率

  • 测试成功率(或者说用例通过率)

测试做到什么程度并没有一个固定答案。只要满足两个显式条件和一个隐含条件就要一直进行。

显式条件:

  • 项目风险

  • 项目经费

隐含条件:

  • 老板们从当前的测试结果已经获得了足够的信心,或者彻底摧毁了信心。只要他们还在犹豫咱就得继续干活。


测试的原则

测试只是展示缺陷

测试只能表明缺陷存在,却不能证明没有缺陷。测试能降低未发现缺陷留存的概率,却 不能证明软件是绝对正确的。 正如某些数学命题,你可以穷举 1-n,证明其正确,却依然无法证明对于 n+1 仍然正确。


穷尽测试是不可能的

测试所有的输入和条件组合是不可能的,除非是极其简单的情况。可以取而代之的是基 于风险和优先级的测试。 当不懂装懂的老板要求你彻底测试一个软件的时候,这是你反驳的最好支持,当然要说 的委婉一点。


早期测试

要较早发现缺陷,就要在软件周期尽可能早的时候开始测试,而且要专注于已定义的测 试目标。 尽早开始测试!这句话估计早就把大家的耳朵磨起茧了。为什么要早?因为越早发现问 题,解决的代价就越小。


缺陷簇生

要对缺陷发现率高的模块投入更多的测试。少量的模块往往隐藏了大部分的缺陷。 这不仅仅是所谓的物以类聚。缺陷发现率高的模块往往于需求不清,设计不当,编码复 杂度高等内在原因关联,所以从风险的角度来看必然较高,多花些时间绝对值得。


杀虫剂悖论

相同的测试再重复多次后就无法再找到缺陷了。要克服“杀虫剂悖论”,测试用例要不断评审修改,不断添加新的和不同的测试,就有可能找到更多缺陷。 随着对系统的加深理解,必然会有更多的测试用例产生。另外缺陷本身也是新用例的很 好来源。


测试是上下文相关的

测试在不同上下文环境中的执行是不同的。比方说 安全关键系统 (safety critical system)和电子商务网站的测试方法就有很大不同。 这个原理相对难理解。这里其实强调的是不能用相同的态度和手段来测试不同类型的系 统。安全关键系统的概念要到高级大纲中才出现,指的是对系统安全要求苛刻的系统, 较之一般的电子商务系统的测试要求更为严苛。


无错谬论

假如建立的系统不稳定或不能满足用户需要和期望,那么发现和修复缺陷就毫无帮助了。 缺陷数量往往用来评估某软件的质量,但要是系统本身背离了用户要求,那就算缺陷再 少也没用,因为没有人会去用它。所以测试时要注意验证(verification)和确认(validation)的区别。需求规格说明和其他文档只是需求的不完全载体。文字说明必然有遗漏和偏差, 而各人的理解更有可能出错。要不断通过各种途径保证所生产的的确就是用户需要的。 常用的方式就是邀请领域专家或用户尽可能多地参与到开发活动来,特别是需求评审和 演示(Demo)。


测试的标准

  • 测试的标准是用户的需求。

所有的软件测试都应该追溯用户的需求,测试人员要始终站在用户的角度去看问题、去判断的软件缺陷的影响,系统最严重的错误是那些导致程序无法满足用户需求的缺陷。

测试主要步骤

  • 计划与控制

  • 分析与设计

  • 实施与执行

  • 评估出口准则和报告

  • 测试结束活动


测试流程

  1. 熟悉产品/项目

  2. 需求评审

  3. 测试需求

  4. 测试计划

  5. 测试用例

  6. 预测试

  7. 第一轮测试

  8. 第二轮回归测试

  9. 第三轮测试

  10. 测试报告

  11. 测试总结


为什么要避免测试自己的程序?

由于心理因素,人们潜意识都不希望找到自己的错误。基于这种思维定势,人们难于发现自己的错误。


软件测试的要素

  • 质量:

软件质量是软件测试的目标,也是软件测试工作的中心,一切从质量出发,也就是一切从客户需求出发。任何违背质量的东西都是问题,测试就是要找出这些问题。

  • 人员:

人是决定的因素,测试人员的态度、素质、能力决定着测试的效果,对测试产品的质量也有很大的影响。测试人员因素包括测试组织结构、角色和责任的定义。

  • 技术:

软件测试技术,包括方法、工具。

  • 资源:

主要是指测试环境中所需要的硬件设备、网络环境,甚至包括测试数据。另外一个重要因素就是测试时间,时间也是测试的资源,但测试人员不能看做资源,每个人的能力千差万别,不同的测试人员担任不同的角色,不能相互代替。这也是软件图书的经典之作——《人件》的作者反对将人作为资源对待的原因。

  • 流程:

从测试计划和测试用例的创建、评审到测试的执行、报告,设定每个阶段的进出标准。


软件质量

软件产品质量评价国际标准ISO 14598 把软件质量定义为:软件特性的总和,软件满足规定或潜在用户需求的能力。上述定义反应如下3个方面的问题:

  • 软件需求是度量软件质量的标准;

  • 软件人员必须遵循软件过程过程的规范;

  • 如果软件只是满足规定的需求,而不能满足可能存在的隐含需求,软件质量也不能保证。


软件团队的责任

  • 发现软件程序、系统或产品中“所有”的问题

  • 尽早地发现问题

  • 督促和协助开发人员尽快地解决程序中的缺陷

  • 帮助项目管理人员制定合理的开发计划

  • 对缺陷进行跟踪、分析和分类总结,以便让项目的管理人员和相关的负责人员能够及时、清楚地了解产品当前的质量状态

  • 帮助改善开发流程、调高产品开发效率

  • 促进程序编写的规范性、易读性、可维护性等


缺陷发现率

缺陷发现率DDP是另一个衡量测试工作效率的软件质量成本的指标。



缺陷发现率DDP=Bugs(tester)/ (Bugs(tester)+ Bugs(customer))

缺陷发现率越高,也就是测试者发现的错误多,发布后客户发现的错误就越少,降低了外部故障不一致成本,达到节约总成本的目的,可获得较高的测试投资回报率。


测试分类

黑盒测试

  • 又称功能测试或数据驱动测试,是针对软件的功能需求/实现进行测试,通过测试来检测每个功能是否符合需求,不考虑程序内部的逻辑结构。

  • 方法:

  1. 功能划分

  2. 等价类划分

  3. 边界值划分

  4. 因果图(鱼骨图)

  5. 错误推测


白盒测试

  • 白盒测试也称结构测试或逻辑驱动测试,必须知道软件内部工作过程,通过测试来检测软件内部是否按照需求、设计正常运行。

  • 方法:

对应于程序的一些主要结构:语句、分支、逻辑路径、变量;

  1. 语句覆盖方法

  2. 分支覆盖方法

  3. 逻辑覆盖方法


单元测试

  • 定义: 又称模块测试,是针对软件设计的最小单位程序模块进行正确性检查的测试工作;可以从程序的内部结构出发设计测试用例,多个模块测试可以平行地独立进行测试;

  • 目的:发现模块内部可能存在的差错;

  • 内容:模块接口测试(数据流入流出)、局部数据结构测试、路径测试、错误处理测试、边界测试。

  • 步骤:利用设计文档设计测试用例;创建被测模块的桩模块或驱动模块;利用被测试模块、驱动模块和桩模块来建立测试环境,进行测试。


集成测试

  • 定义:又称组装测试或联合测试,在单元测试的基础上,将所有模块按概要设计和详细设计进行组装。

  • 目的:发现模块连接中的接口可能存在的各种差错

  • 内容:

    1. 穿越模块之间的数据是否会丢失;

  1. 一个模块组装后是否会对另一模块或其他模块存在影响

  2. 各个子功能组装在一起是否会达到预期的父功能

  3. 全局数据结构是否有问题;

  4. 单个模块的错误累积起来是否会放在。

  • 组装方法:包括一次性组装方式、增殖式组装方式两种组装方法

  • 完成标志:成功地执行了测试计划中规定的所有测试用例;修正了所发现的错误;测试结果通过专门小组的评审


系统测试

  • 目的:验证和确认系统是否达到其原始目标,而对集成的硬件和软件系统进行的测试

  • 测试内容:在真实或模拟系统运行环境下,检查完整的程序系统能否和系统(硬件设备、网络、系统软件)正确配置、连接,满足用户需求


验收测试

  • 测试目的:在用户环境中进行测试,以确定系统和产品是否能够满足合同或用户所规定的需求

  • 测试内容:根据任务书或合同、供需双方约定的验收依据文档进行对整个系统的测试与评审,确认是否接收或拒绝系统


Alpha测试

  • 属于验证测试。模拟运行。由开发人员与测试的测试人员。

Beta测试

  • 属于验收测试。由软件的最终用户在一个或多个用户场所来进行的,开发者通常不在现场,用户记录测试中遇到的问题并报告给开发者。


静态测试

  • 静态测试又称为静态分析技术,不执行被测试软件,对需求分析说明书、软件设计说明书、源程序做结构检测、流图分析、符号执行等找出软件的错误。


动态测试

  • 通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序,而达到发现程序错误的过程。

如何进行单元测试

  • 完成最小的软件设计单元——模块验证工作。

  • 确保模块的正确编码

  • 使用过程设计描述作为指南,对重要的控制路径进行测试以发现模块内错误。

  • 通常情况下面向白盒的

  • 对代码风格和规则、程序设计结构、业务逻辑等进行静态测试,及早地发现和解决不易显现的错误。

  • 单元测试的内容

  • 接口测试

  • 内部数据结构

  • 全局数据结构

  • 边界

  • 语句覆盖,错误路径


自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

  • 在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试的概念。


手工和自动化

  • 手工测试缺点在于测试工作量大,重复多,回归测试难以实现


  • 自动测试利用软件测试工具自动实现全部或部分测试工作:管理、设计、执行和报告;节省大量的测试开销,并能够完成一些手工测试无法实现的测试


  • 手工完成测试的全部过程无法保证测试的科学性与严密性:

  • 修改缺陷越多,回归测试约困难

  • 没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率

  • 反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一

  • 测试花费的时间越长,测试的严格性也就越低

  • 自动测试将测试人员从反复、烦杂的测试执行中解放出来,用更多的时间进行测试设计和结果分析

  • 软件测试不可能全部自动化

  • 不能完成所有手工测试任务

  • 无创造性,且灵活性差,不能改进测试的有效率

  • 过程中可能会遇到很多想不到的问题,尤其是在软件不稳定的情况下

  • 测试脚本的维护高


测试用例设计原则

  • 单个用例最小化原则

    • 这条原则是所有这四条原则中的“老大“,也是在工程中最容易被忘记和忽略的,它或多或少的都影响到其它几条原则。

  • 测试用例的覆盖边界定义更清晰,则测试结果对产品问题的指向性更强。

  • 测试用例间的耦合度最低,则彼此之间的干扰也就越低。

  • 上述这些优点所能带来直接好处是,测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单,只验证你所要验证的内容。

  • 测试用例替代产品文档功能原则

  • 通常我们会在开发的初期(Scrum每个Sprint的头两天)用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息,勾勒将要实现功能的样貌,便于团队进行交流和细化,并在团队内达成对产品功能共识。但随着产品开发深入,团队会对产品的功能有更新的认识,产品功能也会被更具体细化,在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复,在不断倾听和吸收用户的反馈,多个迭代过后,原本被描述为A的功能很可能最终变为了Z。这是时候再去看看曾经的Word文档和OneNote页面,它们仍然记录的是A。之所以会这样 ,是因为很少有人会去以及能够去不断地去更新那些文档,以准确地反映出功能当前准确的状态。

  • 单次投入成本和多次投入成本原则

  • 成本永远是任何项目进行决策时所要考虑的首要因素,项目中的测试也是如此,对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。

  • 测试中的成本按其时间跨度可以分为:单次投入成本和多次投入成本。例如:编写测试用例可以看作是单次投入成本,因为编写测试用例一般是在测试的计划阶段进行(Scrum每个Sprint的开始阶段)的,虽然后期会有小的改动,但绝大多数是在一开始的设计阶段就基本上成型了;

  • 使测试结果分析和调试最简单化原则

  • 这条原则实际上是单次投入成本和多次投入成本原则 – 针对自动化测试用例的扩展和延续。在编写自动化测试代码时,要重点考虑如何使得测试结果分析和测试调试更为简单,包括:用例日志、调试辅助信息输出等。


测试用例方法

  • 等价类划分

  • 等价类划分

  • 错误推测

  • 因果图

  • 判定表驱动分析

  • 正交实验设计

  • 场景设计法

  • 状态转换图


测试用例内容

测试用例主要包括用例编号、用例描述、前提条件、输入数据、测试步骤和期望结果6项关键内容:

  • 用例编号

用例的组织要方便测试人员执行测试用例,应设计一套良好的用例编号体系。

  • 用例描述

用例描述应使用最精简的文字,描述出用例的全貌。让测试人员不用看测试步骤,只看这个描述就可以知道这个用例是描述哪个场景、哪个功能点。

  • 前提条件

一个测试用例一般是针对一个特点的场景,而需要测试的场景发生时通常会有一些铺垫场景,即测试用例的前提,如软硬件环境配置、权限设置,数据准备。

  • 输入数据

一个测试用例可以有一个或多个输入数据,也可以无输入数据。

  • 测试步骤

测试步骤是测试用例的主体,一个测试用例由一个或多个步骤组成,每个步骤之间有一定的前后关系。每个步骤必须表述详细,描述清晰,用于规范、严谨而又客观,最基本的要求是能够使其他人理解,并能正确的执行编写者希望的操作。

  • 期望结果

期望结果是测试执行对执行结果进行对比的标尺,是测试是否通过的判断依据。测试结果必须保证其正确性。

测试计划

根据项目相关文档,需要定义测试范围、测试策略、人员分配、软硬件配置、进度表以及测试过程每个阶段需要达到的目标。

查询遗漏问题的方法

  • 说明书是基础和标准

    测试的执行,通常按测试用例来进行,但测试用例的设计编写是依据产品规格说明书、需求规格说明书、界面设计规范等。写测试用例时难免有考虑不到的地方,因此反复阅读说明文档,也许会有一些新的思路和启发。在项目后期,回归测试阶段,容易思维定势、疲惫,这是可以把这些文档拿出来,再看一下功能点是否覆盖,覆盖到的是不是和需求一致,没有偏差。

  • 相关变动邮件,讨论记录

    变动是一个项目过程中不可少的部分,而这些变动,通常是通过讨论的方式定下来的,因此会有一些文档记录和邮件。反复阅读这些邮件和文档记录,可以更深入的理解项目。

  • 不定期阅读别人的缺陷

    每个人的思路、考虑的角度和操作习惯各不相同,因此发现的问题就会不一样。多阅读别人的缺陷可以拓宽思路,看多了,也会不自觉把多种思路集中到一起,慢慢得应用到测试实践中了。

  • 多和开发人员沟通

    功能测试对测试人员来说大多是黑盒测试,只有开发人员最清楚哪个函数调用哪个函数、哪块单元测试不够充分、哪个逻辑结构比较复杂,多和他们沟通,可以知道哪里还需要多关注一下。

  • 有选择的重新验证以前的缺陷

    特别在回归测试、验收测试阶段,除了验证前面发现的缺陷,还要重视那些与缺陷相关的模块。一个底层参数的变动,可能会引起很多相关功能的问题,继而造成缺陷的遗漏。

  • 关注变化

    一段代码的改动,需要开发人员和测试人员去识别。开发人员知道改动的地方会被哪些模块调用或者会引起哪些模块的变化,但由于时间紧、任务重、很难做好单元测试,因此开发人员要通知测试人员需要关注的测试点。

  • 简单思维方式,一主线为主,减少大遗漏

    一个项目的成功不是把缺陷全报出来,而是在有限的代价下达到预期的质量。按计划进行的项目,主要功能的质量在一定程度上决定了产品的好坏。在项目工期紧张时,全部走完所有测试用例是很难的,可以基本功能为主线,做好相关测试用例的执行,保证不会发生大的质量事故。

    在测试后期,测试人员可能对质量已经很有信心,受思维和经验的局限性,可能仅限于此。若此时,在产品发布之前,调动其他组的员工参与限时测试并给予奖励,必然能有效减少软件缺陷带来的风险,提高产品质量。


软件缺陷(bug)

软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其应有功能的缺陷。一般定义缺陷有以下5条原则:

  • 软件未实现产品说明书要求的功能。

  • 软件出现产品说明书指明不应该出现的错误。

  • 软件实现了产品说明书未说明的功能。

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

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

提交缺陷(bug)的要求



Bug描述的基本要求是分类准确、叙述简洁、步骤清楚、实际结果描述准确、复杂问题有据可查(截图或其他形式的附件)。基本要求如下:

  • 问题描述一般格式:模块或功能点=>测试步骤=>期望结果=>实际结果=>其他信息

  • 单一:尽量一个bug只针对一个软件缺陷

  • 简洁:每个步骤尽量简单明了

  • 再现:问题必须能在自己机器上重现方可上报(个别严重问题重现不了也可上报,但必须标明)

  • 复杂问题:附截图补充说明或直接通知指定的修改人,截图文件格式建议用JPG或GIF

  • 报告中不允许使用抽象的词语:“有错误”,“有时候”之类的不确定语句




-The Ene-


QQ群:330374464

分享该篇文章,获取更多资源

2018-08-11 08:56:33 zimingzim 阅读数 1024
  • 从零学习selenium2(WebDriver)自动化测试系列视频...

    通过案例讲解及其演示,掌握使用java语言开发测试脚本的技术,包括数据驱动脚本、关键字驱动脚本等,如何对自动化测试脚本进行有效管理和维护; 让学员正确地、全面地理解“软件测试框架自动化框架”概念,并基本掌握其各个部分的设计、实现及其应用场合; 清楚如何在自己团队实施自动化测试的工作,从组织、流程、技术等多个方面来保证自动化测试的成功实施,终掌握如何构建自动化测试框架及平台。

    10878 人正在学习 去看看 任健勇

 

本文介绍下软件测试的基本概念,以使大家对软件测试行业有一个基本的了解。

主要分三部分介绍:发展综述、职业发展、核心技能。

第一部分:发展综述

1、BUG/Defect的由来

“Bug”的创始人赫柏的报告格蕾丝.郝柏Grace Murray Hopper),是一位为美国海军工作的电脑专家,也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字,正是由赫柏所取的。1945年的一天,赫柏对Harvard Mark II设置好17000个继电器进行编程后,技术人员正在进行整机运行时,它突然停止了工作。于是他们爬上去找原因,发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾,这显然是由于飞蛾受光和热的吸引,飞到了触点上,然后被高电压击死。所以在报告中,赫柏用胶条贴上飞蛾,并把“bug”来表示“一个在电脑程序里的错误”,“Bug”这个说法一直沿用到今天。

2、软件缺陷事件回顾:

事件1:WINDOWS操作系统蓝屏--多版本之间的兼容性 ;

事件2:迪士尼的狮子王CD光盘不能使用--PC机器之间的兼容性 ;

事件3:Android 5.0臭名昭著的内存泄露Bug--性能测试的重要性;

事件4:HP100款笔记本电脑软件暴露严重漏洞--安全测试的重要性;

事件5:美F-22机群系统瘫痪,软件质量威胁国家安全 ;

事件6:一个 bug ,45分钟损失了 4.65 亿美金,直接导致破产;

事件7:致命的辐射治疗,医疗设备电力软件的Bug,3人直接死亡;

事件8:一架吉努克型直升飞机坠毁,29名乘客全部罹难;

事件9:2011 年温州7.23 动车事故-- 由于温州南站信号设备在设计上存在严重缺陷,遭雷击发生故障后,导致本应显示为红灯的区间信号机错误显示为绿灯;

事件10:一触即发的第三次世界大战: 1980年,北美防空联合司令部曾报告称美国遭受导弹袭击,后来证实,这是反馈系统的电路故障问题,但反馈系统软件没有考虑故障问题引发的误报;1983年,苏联卫星报告有美国导弹入侵,但主管官员的直觉告诉他这是误报,后来事实证明的确是误报;

3、软件测试简史

国外软件测试发展简史介绍:

 

1968,软件工程概念诞生;测试也逐步发展;1975,测试先驱在IEEE发表了软件数据选择的原理,将软件测试定义为一种研究方向,此时软件测试被定义为“证明软件的工作是正确”的活动,理念为“证实”;1979,软件测试艺术一书,认为测试是“发现错误而执行的活动”,理念为“证伪”;1983,软件测试完全指南指出“测试是以评价一个程序或者系统属性为目标的任何一种活动,测试是对软件质量的度量”,测试应该走向前端,进行缺陷预防;1996,提出“测试成熟度模型”“测试能力成熟度模型”等;2002,测试是为了度量和提高被测软件的质量,对测试软件进行工程设计、实施和维护的整个生命周期的过程;

国内软件测试发展简史介绍:

 

1、第一代测试人员很大一部分是直接从软件程序员转岗的,有一定的编码基础,对系统的实现细节理解深入;2、校园招聘中学生对于测试的岗位非常模糊,有些被动选择做测试;软件管理认为测试就是找BUG,不理解测试策略、测试设计等的意义;3、软件测试入门简单,但是对整个系统有深入的把握,软件测试比开发更难深入;中国软件测试人员经验缺乏,大部分为0-3年;

4、软件测试行业对比

谷歌:SET,帮助开发更快更好的测试;帮助产品更好地采集使用信息和用户反馈;安全性、可靠性、性能等专项测试;TE,重点评估对用户的影响及软件产品整体目标上的风险;

微软:SDET,保证质量;提升研发效率;

腾讯:业务上线之前尽可能地发现导致商业目标无法达成的缺陷;独立的体验测试团队;QQ平台很传统;

华为:保证质量;交付;公司平台的流程、工具、技术更新;

第二部分:职业发展

1、技术发展方向

软件测试主要分为管理和技术两个大方向。管理类职位较少,比重也较低,对管理感兴趣的同学可以考虑,另外也需要一定的机会。技术类发展方向多样:产品测试专家/专项测试专家/交付测试工程师等。

详细信息看下图所示:

2、职业发展方向

由于软件测试人员的职业特点,接触的东西非常广且全,非常有利于职业的转型和发展。

从测试职业来看,可以有:测试开发、专项测试、质量管理、产品交付等;

从工作类别来看,可以转型的方向有:开发、产品、售前/售后、其它(市场/销售/咨询等)等

从工作趋向来看,可以转型的方向有:测试创业(围绕测试行业的创业,如测试培训、测试咨询、测试技术类公司等)、跨行测试(比如从传统公司到互联网、银行、AI智能等)、自由创业(与测试不是强相关的创业,科技行业/餐饮行业/零售业等)、自由独立(财务自由)等

第三部分:核心技能

1、软件测试的核心是什么?

常见的有如下一些观点:

观点1、测试用例是测试核心?

观点2、测试策略是测试核心?

观点3、自动化测试和工具是测试核心?

观点4、用户需求及验收标准是测试核心?

观点5、手工测试是测试的核心?

这些观点都是仁者见仁、智者见智,任何东西都没有太绝对的。就我的理解来看,我比较倾向于观点2,也就是说测试策略是软件测试的核心。

我认为软件测试的核心原则就是:合理调度和分配有限的资源,保证正确的时间做正确的事,进行“刚刚好”的测试,最大程度保证产品质量。

2、软件测试的价值是什么?

借用”软件测试价值提升之路“一书,并结合自己的理解。我认为软件测试分为三个阶段:

起点:打破思路、匹配业务、面向商业、问题改进;

测试人员要把目光放在产品的商业成功上,面向服务用户,结合业务需求,打破常规思路,以“问题”为出发点,不断的使得开发流程体系持续改进和提高,从而推进产品质量的不断提高,促进企业在商业和社会上的成功。

飞跃:拦截缺陷、提供数据、过程可控、基本价值;

测试人员要把拦截软件缺陷、监控测试过程、提供测试数据作为测试工作的三大“法宝”,这也是测试的基本价值,也是我们必须要守护的领地。

升华:质量屏障、交付先锋、额外价值、拓展价值;

测试人员除了守护自己领地之外,还能做非常多的额外工作,以拓展测试人员的价值,我们可以是质量的屏障,可以是产品交付的先锋,可以是公司体系流程建设的推进者和改革者。一切的一切都建立在测试人员要做好自己的本职工作,同时随时做好准备,扩充自己的技能包,迎接更大的困难和挑战,为企业不断服务并做出更大的贡献。

3、软件测试的核心能力

想做好软件测试,确实需要一些能力,如下列举了一些核心的要求:

技能包1、业务知识快速学习能力;

技能包2、测试用例的编写和设计;

技能包3、自动化测试及编程基础;

技能包4、测试的基本理论与知识;

技能包5、测试工具的使用与开发;

技能包6、测试策略的制定与实施;

技能包7、解决问题的思路及沟通;

技能包8、自我的测试体系及模型;

技能包9、全面的质量分析及把控;

技能包10、仔细耐心认真踏实勤奋;

……

希望大家不断实践、不断提高、不断总结,提高软件测试的能力。

 

2019-11-24 21:32:05 qq_41569732 阅读数 17
  • 从零学习selenium2(WebDriver)自动化测试系列视频...

    通过案例讲解及其演示,掌握使用java语言开发测试脚本的技术,包括数据驱动脚本、关键字驱动脚本等,如何对自动化测试脚本进行有效管理和维护; 让学员正确地、全面地理解“软件测试框架自动化框架”概念,并基本掌握其各个部分的设计、实现及其应用场合; 清楚如何在自己团队实施自动化测试的工作,从组织、流程、技术等多个方面来保证自动化测试的成功实施,终掌握如何构建自动化测试框架及平台。

    10878 人正在学习 去看看 任健勇

软件测试基础-概念篇

记录 - 慕课网 imooc 软件测试基础-概念篇

简介:系统介绍什么是软件测试,从软件测试的定义、原则以及测试阶段、测试模式、测试手段和测试类型分别详细说明软件测试中的各种测试概念,帮助你深入、清晰地理解软件测试。

文章目录

第1章 课程介绍

本章主要对软件测试有一个概要的介绍,然后介绍本课程的学习目标,让大家从0开始学测试。

在这里插入图片描述

软件质量 重大事故

那些软件Bug引发的惨案

软件故障

千年虫bug ,全球损失超5000亿( 计算机2000年问题,又叫做“千年虫”、“电脑千禧年千年虫问题”或“千年危机”。缩写为“Y2K”。是指在某些使用了计算机程序的智能系统(包括计算机系统、自动控制芯片等)中,由于其中的年份只使用两位十进制数来表示,因此当系统进行(或涉及到)跨世纪的日期处理运 算时(如多个日期之间的计算或比较等),就会出现错误的结果,进而引发各种各样的系统功 能紊乱甚至崩溃。因此从根本上说千年虫是一种程序处理日期上的bug(计算机程序故障),而非病毒。 )

在这里插入图片描述

惨兮兮 哆唆唆

什么软件测试呢? 就是找Bug吗? 我之前上软件测试外教课的时候回答错了

给软件挑刺?

单元测试、集成测试、白盒测试、黑盒测试、性能测试等等各种各样的概念

刚接触的朋友 不知道怎么入手 入行的朋友 问? 软件测试需要学什么?

在这里插入图片描述

怎么把软件测试做好呢?

课程目标

了解软件测试的含义

软件测试遵循的准则

软件测试有哪些分类?分别是什么概念?

在这里插入图片描述

何时开始测试?测试方案如何设计?

测试流程是怎样的?怎么提Bug?怎么写报告?

为什么要做自动化?怎么做?

在这里插入图片描述

做一个系统的阐述

软件测试的历史

在这里插入图片描述

保证软件能够正确的运行

TMM是测试成熟度模型,TDD是测试驱动开发理论

TMM即软件能力成熟度模型, Test Maturity Model,它描述了测试过程, 是项目测试部分得到良好计划和控制的基础,它的主要目的在于帮助企业组织改进和评估其软件测试过程。TMM是一个采用分级方法确定软件组织的软件测试能力成熟度的参考模型,可以指导软件组织提高其软件测试能力。TMM将测试划分为五个级别,分别是:初始级、阶段定义级、集成级, 管理和测量级.

测试驱动开发(TDD):要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行;有助于编写简洁可用和高质量的代码,并加速开发过程.

什么是软件测试?

早期定义

​ 软件测试是对程序能够按预期运行建立起一种信心。

经典定义

​ 测试是为发现错误而执行程序的过程。

测试的目的是为了发现错误,手段是执行程序。

在这里插入图片描述

在这里插入图片描述

规定的要求 预期结果 找出差异

软件测试的测试对象

软件研发生命周期的方方面面

在这里插入图片描述

五大要素和两个目标

质量 人员 资源 流程 技术

软件质量最重要

人是决定的因素

技术包括软件测试技术、软件测试方法、使用的工具

技术是手段

流程是一个规范

资源 硬件 网络 测试数据 测试周期 时间 测试资源

目标 保证软件的质量

提高测试覆盖率 保证软件质量

提高效率 更好完成测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c2K6IXeB-1574602053474)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\10-五大要素和两个目标.png)]

软件测试所遵循的原则

一、测试显示缺陷的存在,但不能证明系统不存在缺陷。

二、穷尽测试是不可能的,应设定及时终止的条件。

三、测试应该尽早进行。

软件度量[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m6N1vmQP-1574602053476)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\11-软件度量.png)]

缺陷软件研发的前期出现 到后期修复缺陷的成本高

尽可能在研发的前期发现缺陷,修复好。

四、缺陷具备群集特性

缺陷 集群特性 越是发现问题多的模板 越是要重点关注

五、测试的杀虫剂悖论

测试用例、测试方法应不定期的评审修改, 不同的测试方法 测试用例来测试软件的不同部分,从而发现更多软件缺陷。

六、测试的二八原则

测试的时间、资源是有限的,要找出软件中所有的错误和缺陷是不可能的,测试总是存在风险,二八原则,我们应该把80%的时间用在20%的重点模板上,重点测试重要模板。

七、测试活动依赖于测试背景。

测试背景进行的测试活动是不同的

测试活动依赖于不同测试场景进行定义和设计

第2章 软件测试阶段、手段、模式

本章主要让大家明白在软件测试中有哪些阶段,哪些手段以及哪些模式,从而为以后的软件测试工作打下结实的理论基础。

软件测试阶段

软件测试的分类

按测试阶段来分类

单元测试 集成测试

系统测试 验收测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9IKHgvEp-1574602053478)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\12-按测试阶段来分类.png)]

单元测试

什么是单元测试?

对软件中的最小可测试单元进行检查和验证。

最小可测试单元???

C语言可以是函数 Java面向对象语言可以看作单元为每一个类

针对一些有界面的功能软件 ,单元可以看作具体的功能项 菜单项目

单元测试的原则

1、尽可能保证各个测试用例是相互独立的

public void testlogin(){
    String username,password;
    username = "test";
    password = getpassFromDB(username);
    Boolean result = app.login(username,password);
    assertTrue(result);
}

getpassFromDB() 错误的做法,在这个测试方法中调用了依赖的类,导致这条测试用例失败的时候,很难判断login这个被测试方法出问题,还是调用的依赖出现的问题。写单元测试的时候尽量避免这种使用依赖的方法。

正确的做法应该是编写一个模拟的方法来取代使用依赖的方法,对于这些必须使用依赖的关系,我们可以放在后面的集成测试来做。

2.一般由代码的开发人员来实施,用来检验所开发的代码功能符合自己的设计要求。

单元测试 相当程度的了解

单元测试的益处

1、能尽早发现缺陷

2、有利于重构

3、简化集成

4、文档

5、用于设计

单元测试 稳定性 、正确性 为之后的集成测试奠定的基础

测试驱动开发

代码即文档

单元测试 设计的本身可以用来验证设计的

单元测试的限制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zAJthr0R-1574602053482)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\13-单元测试的限制.png)]

投入和产出在一个平衡点

单元测试框架

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vit3pmcn-1574602053484)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\14-单元测试框架.png)]

JUnit

UnitTest

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qzd73MiQ-1574602053486)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\15-添加JUnit类库.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9P57PzM8-1574602053488)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\16-添加JUnit1.png)]

​ Calculator.java

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oqCyeyHC-1574602053492)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\17-添加测试类.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5oHORWEB-1574602053496)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\18-测试类创建.png)]

选择需要测试的方法[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZrDlavSi-1574602053499)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\19-选择需要测试的方法.png)]

测试用例

运行[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2RORhq48-1574602053500)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\20-测试用例运行.png)]

Junit 单元测试的实施

集成测试

是在单元测试的基础上 组装

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kk1iaTCx-1574602053501)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\21-集成测试定义.png)]

集成测试的主要实施方案

1、Big Bang

一次性集成 所有的东西组装好一起做测试

2、自顶向下

逐层向下来集成

3、自底向上

常用的,从程序的底层模块开始组装测试

比较好的锁定软件故障的

4、核心系统集成

核心到外围

5、高频集成

持续集成

单元测试&集成测试

1、测试的对象不同

单元 软件的基本单元

集成 模块 子系统 接口关系

2、测试的依据不同

单元 软件的详细设计

集成 软件的概要设计

3、测试的方法不同

集成测试 接口集成

单元测试 关注于单元的内部

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6F03CXuH-1574602053502)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\22-单元测试&集成测试.png)]

系统测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3nkv405P-1574602053503)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\23-系统测试定义.png)]

系统测试是在集成测试基础上

真实的运行环境测试

功能测试 性能测试 稳定性测试

测试 流程 测试方法

关注点

关注系统本身的使用

关注系统与其他相关系统间的连通

关注系统在不同使用压力下的表现

关注系统在真实使用环境下的表现

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-657OLeC7-1574602053504)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\24-系统测试关注点.png)]

软件实际运行环境

系统测试 & 集成测试

测试对象

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o6ThJmr9-1574602053505)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\25-系统测试 & 集成测试测试对象.png)]

测试时间

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oCO6mKW2-1574602053506)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\26-系统测试&集成测试测试时间.png)]

测试内容

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Z4Mo4s71-1574602053506)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\27-系统测试&集成测试-测试内容.png)]

测试角度

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oDfoLuuZ-1574602053507)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\28-系统测试&集成测试-测试角度png)]

验收测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yumpmu6v-1574602053509)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\29-验收测试定义.png)]

正式的 用户来决定

细分

用户验收测试

运行验收测试 运维

合同和规范验收测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uLpUl8j1-1574602053510)(C:\Users\x1c\AppData\Roaming\Typora\typora-user-images\image-20191124181727076.png)]

alpha测试

开发者所提供场景来运行 用户来执行 一般场景是开发者来执行的

Beta测试

完全的脱离了开发者环境 在我们用户提供的环境下来测试

alpha版本

开发者环境下 使用

Beta版本

脱离了开发者 完全是在用户

release 版本

正式 可供交付的

验收测试

验收测试驱动开发 测试驱动开发

开发功能代码

问题

我自己做过开发实训项目,我的理解就是:

开发阶段,方法->单元测试(Junit测试有无预期结果)

合并阶段,功能->集成测试(有无实现)

整理阶段,整体运行->系统测试(各部分功能有没有冲突,会不会报错)

试用阶段,多运行几次->验收测试(检查有无概率性bug)

Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试,主要目的是为了发现缺陷

用户验收测试是以用户为主的测试,软件开发和QA人员也应该参加,测试一般在用户所在地进行,由用户验证软件

产品是否满足了所有的需求的一系列的验收测试工作,主要目的是为了验证需求实现

Beta测试属于验收测试的一种测试策略(内容摘自网络整理)

单元测试是什么

单元测试概念是什么

单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。

单元测试就是对一个代码模块进行测试,一般都是开发做的,你只用了解是什么意思就行了

α测试和β测试分贝是开发环境和客户环境,但和实际环境是什么关系?

α测试和β测试分贝是开发环境和客户环境,但和实际环境是什么关系?

实际环境是参考的环境定义,这样吧,就好比是容器的形状的关系,你见到的第一人称所面对的测试环境。客观点说就是当面对的是

α测试 它的容器就好比是 实验室的培养容器,这个时候的实际环境就是开发环境。

β测试 它的容器就好比是 客户环境的有限定义类型的闭口环境,这个时候的实际环境就是客户环境。

主要还是看你是站在什么人称环境来测试,总的来说是应需而产生的环境。常言道“境随心转”。

关于集成测试的一些理解

集成测试:主要是测试各个单元之间的接口,各个功能模块的衔接。

方案

1、Big Bang 是不是可以理解为软件最后是否能正常运行。

2、自底向上 和 自顶向下,个人选择使用 自底向下比较好,因为每个层次关系都是建立在底层之上的, 所以找起BUG位置会比较准确。

3、核心系统集成 :针对系统中的核心功能去向高层或底层查找 Bug ,这里是不是会去进行单元测试呢?

4、高频集成 :这个没有什么自己的理解,是为了系统潜在的问题么?

如果拿到一个系统,是不是先用Big Bang 方案测试出系统的可用性,然后进行系统的核心集成,最后通过自底向上 或 自顶向下去寻找出 Bug ?

这些只是理论上的概念而已,也就是为了理解知识和面试时候用,真正工作的时候这些概念的界定都是很模糊的。

现在主要涉及的是概念,那软件测试相关方法以及代码的开发是后面介绍吗?

  1. 软件测试相关方法 后面有讲解,也是概念性的。
  2. 代码的开发 该视频是测试基础,不涉及代码开发部分,后面没有讲解。

测试相关问题

老师,请问测试工程师必须要学会多种语言吗?

最好能做到比较精通一门语言,对测试工作会很有帮助。各种语言基本的用法原理也差不多,需要用的时候再根据情况学习一下,不用一开始就特别去学习多种语言

好的,蟹蟹。还想问一下,对于初学者,怎样着手学习软件测试?我之前是学前端的。

最好的学习肯定还是实践。还没有工作的话,可以考虑参与到一些开源社区的项目,提交bug也是很好的贡献啊

不好意思,这位朋友刚刚看到。蟹蟹你的建议。

基本上最好会C吧

好,我在学习C#

好,阿里嘎多。

1、单元测试

     概念: 对软件中的 最小可测试单元   进行检查和验证。

     原则: (1)尽可能测试用例相互独立     (2)一般由代码开发人员实施     

     好处:(1)能尽早发现缺陷     (2)利于重构     (3)简化集成(为集成测试奠定基础)     (4)单元测试规范很大程度上减少文档编写     (5)用于设计

     限制:(1)穷尽测试不可能     (2)一行代码需要3~5行测试代码

     单元测试框架:PHPUnit     CppUnit     JUnit     nunit(针对.net)


2、集成测试

     概念:在单元测试基础上,将单元组装测试,关注接口

     集成测试实施方案:(1)Big Bang     (2)自顶向下     (3)自底向上     (4)核心系统集成(先测试核心部分)     (5)高频测试
     2、3常用于以前的瀑布模型,4、5常用于现在的敏捷开发

3、系统测试(主要用黑盒测试)

     概念:将集成测试的软件与系统中其他部分结合起来,在 实际运行环境  中测试 ,偏于业务角度的验证
 
     关注点:(1)系统本身使用     (2)系统与其他系统的连通     (3)在不同压力下的表现     (4)真实使用环境下的表现


4、验收测试

     概念:交付测试。用户进行测试

     细分:alpha测试:用户在开发者提供的环境下测试     beta测试:完全脱离开发者


软件测试手段

按测试手段来分类

黑白分明 一静一动

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SXbjuIdF-1574602053511)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\30-按测试手段来分类.png)]

黑盒测试

黑盒测试主要测试什么

黑盒不可见的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t9VbS5nu-1574602053535)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\31-黑盒测试主要测试什么.png)]

黑盒测试的主要设计方法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GFaf4Lta-1574602053537)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\32-黑盒测试的主要设计方法.png)]

具体应用

边界点

白盒测试

结构化测试 透明测试

逻辑覆盖率

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QmB3KqFh-1574602053539)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\33-白盒测试输入输出.png)]

主要的逻辑单位

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ihrR7bhC-1574602053540)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\34-白盒测试主要的逻辑单位.png)]

语句覆盖

每条语句至少执行一次

系统深入理解

白盒测试的优缺点

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lEQN64Qp-1574602053543)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\35-白盒测试的优缺点.png)]

缺点

较高覆盖率

成本很高

代码层面上

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qmi19a66-1574602053545)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\36-白盒测试的缺点.png)]

白盒测试的主要测试方法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BjyVZgPX-1574602053546)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\37-白盒测试的主要测试方法.png)]

代码

测试者 使用测试工具

质量标准

基本路径 程序控制流图

灰盒测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4lUz0DjW-1574602053548)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\38-灰盒测试.png)]

静态测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FF9zCIGj-1574602053549)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\39-静态测试定义.png)]

我的程序不被运行

直接来看代码

静态的检查

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xO6Yt6uB-1574602053551)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\40-静态测试过程.png)]

程序员相互检查 一个小组 会议

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vioUZaS8-1574602053552)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\41-静态测试过程1.png)]

动态测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GWc9Ibh2-1574602053553)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\42-动态测试定义.png)]

例子

生活中买车

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tDKSLBlV-1574602053554)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\42-静态动态测试生活中买车.png)]

买车 验车

车的外观

汽车发动起来 开一段路

手工测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0QEAAfKV-1574602053554)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\43-手工测试.png)]

自动化测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bndpiZZD-1574602053557)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\44-自动化测试.png)]

手工测试&自动化测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WntR2Md2-1574602053557)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\45-手工测试&自动化测试.png)]

按测试手段来分类

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NllMw9hY-1574602053558)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\46-按测试手段来分类.png)]

静态 动态

运行起来

手动 自动化

人 第三方测试工具

2-2 软件测试手段

1、分类
     根据测试可见度:黑盒、白盒、灰盒
     状态:静态、动态
     测试方式:手工、自动化

黑盒:
     优点:(1)容易实施,无需关注内部     (2)更贴近用户视角
     缺点:(1)测试覆盖率较低,一般只有40%     (2)黑盒自动化测试复用率低,维护成本较高
     主要测试什么?(1)不正确or遗漏功能     (2)接口上,输入输出是否正确     (3)是否有数据结构错误或外部信息(比如数据文件)访问错误     (4)系统性能是否满足要求
     主要设计方法:(1)等价类划分法     (2)边界值分析法(比较重点关注)     (3)错误推断法     (4)因果图法     (5)正交试验分析法     (6)状态迁移图法     (7)流程分析法

白盒:结构化测试,逻辑测试,透明测试
     优点:(1)迫使测试人员理解软件原理     (2)覆盖率较高,可以检测每条分支和路径     (3)能发现隐藏在代码的错误     (4)对代码测试比较彻底
     缺点:(1)成本高     (2)无法检测遗漏路径     (3)无法检测数据敏感性错误     (4)无法直接验证需求正确性
     主要测试方法:(1)代码检测法     (2)静态结构分析法     (3)静态质量度量法     (4)逻辑覆盖法(6种):语句、路径、判定、条件、判定/条件、条件组合覆盖。     (5)基本路径测试法


静态测试:
     不执行被测程序,通过评审软件文档、代码、程序复杂度、检查是否符合编程标准,来发现程序不足之处。
     有些白盒是静态测试。
     方法:     互审:程序员互相检查;走查:小组集体检查;会议:召开会议检查

动态测试:
     运行被测程序,比较运行结果与预期结果,分析运行效率、正确性、健壮性等。
     黑盒大部分是动态测试。


手工测试:众包测试、探索式测试
     优点:容易发现缺陷,容易实施、创造性、灵活性
     缺点:不一致性、可靠性低、依赖人力资源、重复测试效率低、覆盖量不容易度量

自动化测试:
     用单独的测试工具软件,控制测试的自动化执行,并对预期和结果进行自动检查。
     单元、接口、性能多用该测试。
     优点:高效高速、准确可靠、高复用性、覆盖量容易度量
     缺点:机械、发现缺陷率低、一次性投入较大


按测试模式来分类

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h1S0M9FY-1574602053560)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\46-按测试模式来分类.png)]

传统的瀑布模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oKMICyC4-1574602053561)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\46-传统的瀑布模型.png)]

按顺序的 下落的

每一个阶段 上一个输出 一个输入

瀑布模型的优缺点

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lweh9WWg-1574602053562)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\47-瀑布模型的优缺点.png)]

大量文档

软件测试的地位和价值 研发的后期

V模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NM43aPWy-1574602053563)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\48-V模型.png)]

W模型 双V模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gUYO0FMu-1574602053564)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\49-W模型双V模型.png)]

软件开发各个阶段

需求 设计 都要测试

尽早发现问题

及时了解项目的风险

需求 设计 编码 仍是串行的

线性的 测试 开发

迭代不能很好支持

X模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x77WS1j3-1574602053565)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\50-X模型.png)]

H模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JHsXcAhh-1574602053567)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\51-H模型.png)]

并发执行

软件 设计 编码 测试

进展

2-3 软件测试模式之瀑布模型

按测试模式分类:瀑布模型、敏捷测试、基于脚本测试、基于风险测试、探索式测试等

瀑布模型、v模型、W模型、x模型、H模型

软件测试模式-敏捷测试

敏捷测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ysprv5CE-1574602053568)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\52-敏捷测试.png)]

敏捷宣言

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3o2z3DcT-1574602053569)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\52-敏捷宣言.png)]

结果 客户 拥抱变化

敏捷测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QQjeUoAv-1574602053570)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\53-敏捷测试强调.png)]

敏捷测试VS传统测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oGQEePrm-1574602053571)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\54-敏捷测试VS传统测试.png)]

开发 和 测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cM6QKfXn-1574602053572)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\55-敏捷测试VS传统测试2.png)]

基于脚本的测试-SBT

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qcnn00ez-1574602053574)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\56-基于脚本的测试-SBT.png)]

探索式测试(ET)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AUCJ9r7c-1574602053574)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\57-探索式测试(ET)].png)

ET和ST使用

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UTiG4umI-1574602053575)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\58-ET和ST使用.png)]

ST Vs ET

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ul9Eig8D-1574602053577)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\59-ST Vs ET.png)]

探索式测试的优点

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pSmAI7yc-1574602053578)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\60-探索式测试的优点.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DyxTdDmx-1574602053579)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\61-探索式测试的优点1.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cLYO1okq-1574602053580)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\62-探索式测试的优点2.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1EgsBhB9-1574602053581)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\63-探索式测试的优点3.png)]

探索式的优点和缺点

局部探索式测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FKOujscx-1574602053583)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\64-局部探索式测试.png)]

全局探索式测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FQ4foZbt-1574602053584)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\65-全局探索式测试.png)]

漫游测试法

执行探索式测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BSRnfXja-1574602053585)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\66-执行探索式测试.png)]

基于风险的测试-RBT

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-G5LtrLad-1574602053586)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\67-基于风险的测试-RBT.png)]

哪些是风险?

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cO5q1ViK-1574602053587)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\68-哪些是风险.png)]

识别风险

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WjKYHuaO-1574602053588)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\69-识别风险.png)]

RBT的优点

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MTZG66fU-1574602053589)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\70-RBT的优点.png)]

基于模型的模式-MBT

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kNL6ORfW-1574602053590)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\71-基于模型的模式-MBT.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4Bx94ICF-1574602053591)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\72-基于模型的模式-MBT1.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NquxrWhF-1574602053593)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\73-基于模型的模式-MBT2.png)]

主要的MBT工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DsCGLTMv-1574602053594)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\74-主要的MBT工具.png)]

MBT工具

问题

完全没有接触过软件测试 该如何系统学习 从哪开始学 学到那种程度可以找工作了
麻烦大神仔细解答一下

如果自控能力,学习能力强的,自己学习就好,不需要去培训班。可以从下面几个方向入手,功能测试,主要是测试用例设计的那一块是最重要的,去买本教程看看测试理论的东西,虽然有点枯燥,但是这也是为你将来的测试思维打下基础,后面还需要掌握一些数据库的知识,常用的SQL命令会了就行,还有Linux的一些常用的命令,掌握这些基本找个功能测试的工作没有说明问题,后面的就是根据工作中需要用的再去针对性的学习,那样效率会高一些

想请问一下,软件测试跟英语关联大吗,自身英语很薄弱本人是入了行的菜鸟,建议是最好能有实践机会,就是去找能接受菜鸟的测试工作。没机会的话,考虑花钱去上培训班,如果要自学,先学些基础知识吧,搭起一个知识框架,然后不断深入学习去填充,概念性的学完之后就可以更深入的去接触性能测试、数据库等等,这些在功能测试里也是基础。最后,有了这些准备工作,再去找工作机会。
有关et的问题
说优点的时候说ET有利于自动化,说缺点的时候说难进行自动化??

有一点歧义

ET本身是难以直接实施自动化的(缺点)

但是我们ET过程中所做的积累是有利于后续自动化实施的(优点)

一个是从技术实现上来说,一个是从测试内容上来说

非常感谢!

2-4 敏捷测试、基于脚本测试、基于风险的测试

敏捷测试特点:
强调从客户角度进行测试
重点关注迭代测试新功能,不再强调测试阶段
尽早测试,不间断测试,具备条件即测试
强调持续反馈
预防缺陷重于发现缺陷。

敏捷测试VS传统测试

 
基于脚本测试-SBT     Script-based Testing

脚本测试-ST     Scripted Testing
探索式测试-ET     Exploratory Testing
ET完全抛开测试脚本的测试。它是一种测试风格、思维而不是一种测试技。
优点:
     1.更能激发测试人员的创造性和工作乐趣
     2.增加了发现新的或较深入Bug的可能性
     3.在较短时间内找到更多Bug以及对SUT做一个快速的评估
     4.有利于更加有效的实施自动化
     5.更加适用于敏捷项目
     6.减少了在简单、繁复上用例的无谓编写时间
缺点:
     1.测试管理上有局限性,较难协调和控制
     2.对于Bug的重复利用和重复上作用有限
     3.对测试人员的测试技能和业务知识深度依赖较大
     4.只有在被测系统已完全可用的前提下才更有作用
     5.ET的生产率很难定义
     6.ET本身较难进行自动化
ET测试方法:局部、全局
               局部探索式测试:输入、状态、代码路径、用户数据、执行环境。
               全局探索式测试:漫游测试法—–商业区、旅馆区、历史区、旅游区、娱乐区、破旧区。

ET和ST要结合使用     ET应用比如说,问几个问题猜出你心中的答案的应用



基于风险测试-RBT     Risk-based Testing
     风险有:质量风险、管理风险、风险级别=风险可能性*风险严重度
     
基于模型的测试-MBT     model-based testing
     根据需求建模,借助工具建模然后执行,偏向于自动化测试。主要的MBT工具,微软的Spec Explorer。。



2-5 软件测试的分类

按照测试类型分:

功能测试(最主要)
性能测试
兼容性测试


部署测试
易用性测试


文档测试
本地化测试


安全测试
无障碍测试
可靠性测试

功能测试:对提供给用户的功能进行测试。
针对的问题:功能 错误或遗漏、界面问题、软件本身性能错误、数据及访问错误初始化及终止错误。
功能自动化测试工具:QTP(基于关键字驱动)现在其实已经用的很少了、winrunner; silkTest; Rational robot; selenium; Watir; Sikuli

性能测试:负载测试、压力测试、稳定性测试
性能指标:并发用户数VU、每秒事务数TPS、系统响应时间、设备性能
自动化测试工具:LoadRunner、Silkperformer、Jmeter、WebLoad、Apache Bench、LoadUI
静态性能评估:对Web应用的页面进行静态分析,并给出评估结果的性能分析方法。工具有YSlow、PageSpeed。他们是浏览器插件,评级静态网页的标准有14个,减少HTTP请求之类的。
应用性能管理(APM):提供对系统的实时监控以实现性能管理、故障管理的解决方案。比如听云。


安全测试:是否符合产品安全需求和质量标准。
渗透测试:通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试,与黑客不同于,黑客未授权,而且最后还会抹掉记录。
渗透测试 VS 安全测试
                         攻————–防
                         点————–面
可以查看OWASP网站,关注网站中的OWASP Top10和Test Guide
安全测试工具:APPscan(针对web应用的漏洞扫描)、Webinspect(类似APPscan)、Nessus(针对服务器主机类)、Nmap(端口嗅探工具)、MetaSploit(攻击框架)、WebScarab(代理劫持)、Fortify(白盒测试,代码静态分析)、W3AF(针对web应用)


兼容性测试:软件本身的兼容性、不同平台下的兼容性、在运行设备下的兼容性、软件互操作性(指的是软件内部不同功能操作是否兼容 & 与其他软件是否兼容,比如与微信是否兼容,与微信不兼容基本上就没用了)
对web应用,还有浏览器兼容性,因为浏览器的内核不同
浏览器兼容性测试工具:BrowserShots(该网站输入url值,可以看不同平台下的显示)

文档测试:配套的文档的测试。如用户手册、使用说明、用户帮助文档等。

可靠性测试:软件可靠性、(可靠性测试更多的是)硬件可靠性。

易用性测试:使用软件时是否感觉方便,用户体验怎样。

本地化测试:针对软件的本地化版本实施的针对性测试。比如英文版,中文版。不过不仅仅是语言,测试内容还有:1.语言、书写习惯;2.时区、日期格式、货币;3.当地风俗、法律法规;4.政治敏感内容。

部署测试:安装测试,主要验证系统部署过程,并确保软件经过安装测试后可以正常使用。主要测试内容:不同环境下的部署验证;参照部署文档执行,过程的合理、正确性;

无障碍测试:提供便于特殊人群使用的功能


3-1 常见软件测试分类

回归测试:软件功能修改后,对软件进行重新测试,以确认修改没有引入新的错误或导致其他部分产生错误。尽量实现自动化。 回归测试的重心在关键模块和重点功能组件。

Monkey测试:搞怪测试。就是用一些随机、稀奇古怪的方式来操作软件,以测试系统的健壮性和稳定性。

冒烟测试:确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性。类似于回归测试,但是测试的注重点不同。敏捷开发的“每日构建”中用冒烟测试来确认合入的代码没有影响主要功能的正常。

A/B测试(非常常用):多用于互联网行业,通过为页面提供2个版本给用户使用并记录相关的用户行为数据,来确定更优化设计。
A/B测试实施要点:
1.多个方案并行;
2.每次测试仅改动一个变量;
3.按照某种规则进行优胜劣汰。
A/B测试工具:Google Analytics Content Experiments、Visual Website Optimizer
————————————————


第3章 软件测试类型

本章将根据不同的角度讲软件测试进行分类,让大家更好的理解软件测试工作中具体的测试类型,比如性能测试,安全测试,兼容性测试,文档测试等。

软件测试类型

软件测试的分类

按测试类型来分类

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7D3QZ6lm-1574602053596)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\75-按测试类型来分类.png)]

功能测试

主要 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lyzvfktt-1574602053597)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\76-功能测试.png)]

功能测试工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b1golBSG-1574602053598)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\77-功能测试工具.png)]

性能测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9Aobqomv-1574602053600)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\78-性能测试.png)]

性能指标

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qXZwjSPr-1574602053601)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\79-性能测试性能指标.png)]

性能测试工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VfhqrTno-1574602053602)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\80-性能测试工具.png)]

静态性能评估

Web应用 访问

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PSRzjL6I-1574602053603)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\81-静态性能评估.png)]

插件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XGu8viP0-1574602053604)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\82-静态性能评估插件.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1PBgq8Yc-1574602053605)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\83-静态性能评估.png)]

应用性能管理(APM)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fBmVzz83-1574602053606)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\85-应用性能管理(APM)].png)

听云

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K47fRQXB-1574602053607)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\84-听云.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GCkO0kEa-1574602053607)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\86-听云1.png)]

安全测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-crVevoq5-1574602053608)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\87-安全测试.png)]

渗透测试

授权的黑客攻击

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1Ns79vcJ-1574602053609)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\88-渗透测试.png)]

黑客 销毁攻击的痕迹

渗透测试VS安全测试

攻破 防御

一个薄弱点 攻破系统 安全 整个面

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F20AOjOy-1574602053611)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\89-渗透测试VS安全测试.png)]

OWASP

Web 应用里面最著名的安全项目

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xKJbFGdY-1574602053612)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\90-OWASP.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JMD2yFcG-1574602053613)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\91-OWASPWeb应用安全项目.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Aia3xzzV-1574602053614)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\92-OWASP-Top10.png)]

注入 Injection 巧妙地构造

失效会话验证

XSS

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1ixrgdgD-1574602053615)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\93-OWASP-TOP10.png)]

测试 指

Testing Guide

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T3va4NnT-1574602053616)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\94-OWASP-TestingGuide.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HYtDEoGB-1574602053617)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\95-OWASP.png)]

安全测试

安全测试工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yeGNLB4A-1574602053618)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\96-安全测试工具.png)]

兼容性测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gn6GYJij-1574602053619)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\97-兼容性测试.png)]

浏览器内核

显示区别

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nqh4dnxI-1574602053621)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\97-浏览器内核.png)]

浏览器兼容性差异

浏览器兼容性测试工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n7IBgeZg-1574602053622)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\98-浏览器兼容性测试工具.png)]

兼容性差异

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oxvjXEHU-1574602053623)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\99-浏览器兼容性测试工具.png)]

文档测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CaT4UUCa-1574602053624)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\100-文档测试.png)]

文档测试

清晰的说明

理解性

可靠性测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DiTlIoxb-1574602053625)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\101-可靠性测试.png)]

硬件可靠性

环境方面 老化 温度 湿度 高压地区 防尘

易用性测试

易用性测试[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JNpi3r6X-1574602053627)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\102-易用性测试.png)]

本地化测试

本地化版本

汉化???

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NXwvCjKp-1574602053628)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\103-本地化测试.png)]

非常多的因素

部署测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZNOkfKMh-1574602053629)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\103-部署测试.png)]

无障碍测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CfSCPfsy-1574602053630)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\104-无障碍测试.png)]

保证软件正常 可用性

第4章 其他软件测试类型

本章会介绍一些其他软件测试分类,让大家了解到这些分类的意义和价值,最后会对本次课程做一个总结,本次基础篇就讲到这,谢谢大家!

其他的一些测试类型概念

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5722jRR8-1574602053632)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\105-其他的一些测试类型概念.png)]

回归测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zp83f0Dm-1574602053634)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\106-回归测试.png)]

Monkey测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MJ57XJ7j-1574602053635)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\107-Monkey测试.png)]

冒烟测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MmJfYfGm-1574602053636)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\108-冒烟测试.png)]

A/B测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-y4ryUfaJ-1574602053637)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\109-A&B测试.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WGwbvAFi-1574602053638)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\110-A&B测试1.png)]

A/B测试工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7ux5qtll-1574602053639)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\111-A&B测试工具.png)]

冒烟测试,是对软件基本的功能进行测试,测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本的功能正常,保证软件系统能跑的起来,可以进行后续的正式测试工作。

举个简单的例子:新开发一个加法软件,答错后会显示正确答案。测试者故意输错答案后却没有显示正确答案,就直接退回给开发人,不必去考虑其他原因。这个就是冒烟测试。

回顾总结

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NhzFLlap-1574602053641)(C:\Users\x1c\Desktop\我手码我心\软件测试\img\112-回顾总结.png)]

软件测试的历史

计算机的发展

测试的目的

软件测试的定义

软件测试的五大要素

主要原则

软件不同

测试阶段

测试手段

测试模型

测试类型

其他分类

测试之美

2019-12-11 16:53:51 qq_41782425 阅读数 66
  • 从零学习selenium2(WebDriver)自动化测试系列视频...

    通过案例讲解及其演示,掌握使用java语言开发测试脚本的技术,包括数据驱动脚本、关键字驱动脚本等,如何对自动化测试脚本进行有效管理和维护; 让学员正确地、全面地理解“软件测试框架自动化框架”概念,并基本掌握其各个部分的设计、实现及其应用场合; 清楚如何在自己团队实施自动化测试的工作,从组织、流程、技术等多个方面来保证自动化测试的成功实施,终掌握如何构建自动化测试框架及平台。

    10878 人正在学习 去看看 任健勇

说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家!
温馨提示:目录在文章右侧栏

一、 软件测试的引入

1.学习软件测试前的思考

  • 软件测试就是测试程序吗?(不是,软件包括程序丶数据以及文档,所以不止是测程序

  • 测试是不是装上软件后点鼠标、敲键盘?(不全是,测试是一个过程包括需求分析丶测试计划丶用例设计丶执行用例丶测试评估以及总结

  • 怎么开始测试工作?第一个任务是什么?(第一个任务测试需求分析

  • 测试早做好还是晚些做好?(早做好

  • 测试需要谋划或者规划吗?(需要测试计划,分析软件哪些测哪些不测,什么时候测,哪些人做哪些测试,需要的测试时间 ,测试所遇到的问题包括怎么解决

  • 测试要做到非常全面吗?尽善尽美?(后面系列文章会提到

  • 谁会参与测试?谁做最合适?(用户丶开发以及测试人员,测试做最合适,开发人员没有测试人员的思路对于自己开发的软件很多缺陷是找不出来的,用户其实也非常适合测试,但是用户不懂测试

  • 测试的最终任务是什么?测试是为了证明软件很棒吗?(寻找缺陷,看软件最终是否符合用户的需求,分开来讲测试每个阶段的任务是不一样的,测试早期预防缺陷,测试中期是发现缺陷并解决缺陷,测试后期是也就是用户手里是要给用户建立对产品的信心;恰恰相反测试是证明这个软件不棒有问题,并把问题挖出来

  • 如果你找到一个缺陷,你该怎么办?(提交给开发并跟踪缺陷有没有解决

  • 找到的缺陷一定要修改吗?你要不要去修改缺陷?(不一定要修改,测试人员不要去修改,如果改好了那么奖金归谁毕竟是开发人员开发的,改错了自己背锅

  • 你希望发现的缺陷越多还是越少?(从测试人员的角度来说那是越多越好,在产品交付给用户之前把缺陷发现的越多,那么开发就能将这些缺陷解决,从而提高软件质量,毕竟都是在一条绳上的蚂蚱

  • 缺陷修改后一定会对软件带来有益的影响吗?(后面系列文章会提到

  • 测试是一次性的任务吗?(不是一次性的任务,而是一个迭代的过程即反复丶重叠

  • 公司中开发和测试人数上哪种应该更多些?(后面系列文章会提到

2.回顾软件的概念与分类

2.1软件的概念

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

  • 程序是按事先设计的功能和性能要求执行的指令序列;
  • 数据是使程序能正常操作信息的数据结构;
  • 文档是与程序开发、维护和使用有关的图文材料。

在这里插入图片描述

2.2软件的分类

按重要性

  • 系统软件
  • 支持软件
  • 应用软件

按架构

  • 单机版软件
  • 分布式软件:C/S 架构 B/S 架构

3.软件失效

3.1 软件都是安全的吗?软件中有错误吗?

1991 年,爱国者导弹防御系统

  • 美国爱国者导弹防御系统是里根总统提出的战硌防御计划(即星球大战计划), 海湾战争中,用于拦截伊拉克飞毛腿导弹,但在沙特阿拉伯的多哈中失利,28名美国士兵丧生。
  • 分析发现症结在于一个软件缺陷,系统时钟的一个很小的计时错误积累起来到14 小时后,跟踪系统不再准确。在多哈的这次袭击中,系统已经运行了 100多个小时。

1994 年,迪斯尼狮子王游戏

  • 迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏:狮子王动画游戏,迪斯尼公司进行了大量促销宣传,结果,销售额非常可观,该游戏成为孩子们那年节假日的“必买游戏”。12 月 26 日圣诞节的后一夭,迪斯尼公司的电话支持技术员们淹没在来自于愤怒的家长并伴随着玩不成游戏的孩子们哭叫的电话之中,报纸和电视新闻进行了大量的报道。
  • 后来证实,迪斯尼公司的软件在极少数系统中工作正常(如在迪斯尼程序员用来开发游戏的系统中),但在大多数公众使用的系统中却不能运行。

2000 年,千年虫问题

  • 20C70S,美国一程序员位公司开发工资系统,当时的计算机存储空间很小,为了节省存储空间,把 4 位数日期缩减为 2 位数,如 1973—73。他简单地认为,只有在到达 2000 年他的程序计算 00 或 01 这样的年份时问题才会发生问题,他认定在 25 年之内程序肯定会升级或替换,而且眼前的任务比现在计划遥不可及的未来更加重要。后来,程序员退休了,程序仍然在使用,谁也不会想到如何深入到程序中检查 2000 年兼容问题,更不用说去修改了。
  • 据估计,世界各地检查和解决 2000 年兼容问题和错误花费了数千亿美元。

2006 年,ATM 机故障,男子恶意取款事件
在这里插入图片描述

2009 年,广州火车站售票系统瘫痪 2 个半小时
在这里插入图片描述

3.2 软件危机(software crisis)

20 世纪六七十年代,出现了软件数量急剧增长,但软件失败率高速上升的现象。

1968 年初,北大西洋公约组织的在联邦德国召开的国际学术会议上,计算机科学家们正式提出了“软件危机”(Softwre Crisis)。

  • 对进度和成本估计不准确,开发成本远远超出预算,项目进度和软件开发效率严重滞后;
  • 用户对提交的产品经常会不满意;
  • 产品的质量不可靠,缺陷很多,维护成本非常高;
  • 软件开发过程的文档匮乏。

3.3 软件为什么会失效?

在这里插入图片描述
缺陷产生的原因
在这里插入图片描述

二、软件测试的定义

1.软件测试的起源与历史

  • 早期软件开发中,没有测试的概念,开发所做的是调试,目的是发现并纠正软件中的故障。
  • 1957 年,测试与调试被区别开来。但认为测试工作应该往后推,潜意识里认为,测试的目的验证产品能工作。
  • 1972 年,在美国北卡罗来纳大学举行了首届软件测试正式会议,Bill Hetzel(比尔•海泽尔)在会上正式定义软件测试概念。
  • 1979 年,Glenford J.Myers(迈尔斯)在《软件测试艺术》中给出测试的经典定义:测试是为了发现错误而执行程序的过程。
  • 1983 年,IEEE(Institute of Electrical and Electronic Engineers)给出了软件测试的标准定义,并制定了测试的标准。
  • 1996 年,Kent Beck(肯特•贝克)在极限编程 XP 方法论中提出 TDD 测试驱动开发理论。
  • 2009 年,James A.Whittaker(惠特克)提出探索式测试理论。

2.早期测试如何进行?

在这里插入图片描述

3.软件测试的定义

3.1 经典定义

  • 1979,Myers,《软件测试艺术》
    测试是为发现错误而执行程序的过程。
    理解:
    测试是为了证明程序有错,而不是证明程序无错误。
    一个成功的测试是发现了至今未发现的错误的测试。

3.2 标准定义

  • 1983,IEEE
    使用人工或自动手段来运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
    理解:
    测试是在用户需求和开发技术之间找一个平衡点。

3.3 国内定义

  • GB/T 11457
    依据规范的软件检测过程和检测方法,按照测试计划和测试需求对被检测软件的文档、程序和数据进行测试的技术活动。
    软件测试是一个过程,测试不只是测试执行,它包括从计划开始到测试结束的一系列活动。
    软件测试需要测试方法和技术,或者说技巧。
    软件包括程序、数据和文档,除了执行程序,数据和文档也需要测试。

3.4 其他理解

  • 不同时期关于测试的其他定义
    确信程序做了它应该做的事(Hetzel,1973)。
    确认程序正确实现了所要求的功能。
    查出规格说明中错误,以及与规格说明不符的地方。
    测试是一切以评价程序或系统的属性、能力为目的的活动;测试是对软件质量的度量(Hetzel,1983)。
    评价程序或系统的过程。
    测试是与软件开发或维护工作并行进行的一个过程。
    测试是一个获取信息,降低决策风险的过程。通过测试,向整个团队提供关于产品质量和项目环境的信息,帮助他们做出决定。

三、软件测试的过程

1.分析测试需求

  • 测试人员对用户的需求进行分析,了解软件要做什么,怎么做,进而确定将来怎么测试。

2.编写测试计划

  • 测试负责人编写测试计划;
  • 测试计划的内容
    包含产品概述、测试范围/测试区域/测试项、 测试目标/被测特征、测试优先级、测试配置/测试资源(硬件、软件、人力、技术等)、测试周期、进度安排(测试任务、人员安排)、 测试策略、测试方法/途径、测试交流、风险分析、测试标准、需交付文档等内容。

3.设计与编写测试用例

  • 设计用例主要反映在编写测试点上;
  • 根据公司格式或者选择一些模板编写测试用例。

4.执行测试

  • 搭建测试环境;
  • 执行测试用例,记录测试事件;
  • 提交和跟踪缺陷。

5.评估与总结

  • 分析实际测试与计划的偏差;
  • 收集并提交各种测试文档和数据,对数据进行分析;
  • 给出是否继续测试还是终止测试结论;
  • 总结经验教训。

四、软件测试的目的/目标

在这里插入图片描述

五、区分三个概念

1.测试 & 调试

  • 在目前的开发和测试中,谁去寻找软件中潜在的问题?发现缺陷后谁去修改?
    在这里插入图片描述

2.软件质量保证 & 软件测试

  • 软件质量保证(SQA,Software Quality Assurance)
    在这里插入图片描述
2018-01-18 14:32:48 yuwenlewhl 阅读数 247
  • 从零学习selenium2(WebDriver)自动化测试系列视频...

    通过案例讲解及其演示,掌握使用java语言开发测试脚本的技术,包括数据驱动脚本、关键字驱动脚本等,如何对自动化测试脚本进行有效管理和维护; 让学员正确地、全面地理解“软件测试框架自动化框架”概念,并基本掌握其各个部分的设计、实现及其应用场合; 清楚如何在自己团队实施自动化测试的工作,从组织、流程、技术等多个方面来保证自动化测试的成功实施,终掌握如何构建自动化测试框架及平台。

    10878 人正在学习 去看看 任健勇

本人从毕业到现在,已经在测试行业摸爬滚打了7-8年了,说实在的很多时候都是在重复着功能黑盒测试,自己也没有好好认真的去学习和深挖测试领域的新技能和方法,所以直到现在都很初级或是懂得很皮毛吧!

今天开始,做些关于软件测试领域的理解和自己测试过程中遇到的些问题和工具的使用,也谢谢各位大神的指导!

开篇必须做概念性的介绍,从整体层面去了解软件测试究竟是什么,揭开它神秘的面纱。
  • 什么是软件测试?
软件测试,是一种用来促进鉴定软件的正确性、完整性、安全性质量的过程。(对,它是一个过程:有操作、有识别、有衡量、有评估)
换句话说,软件测试是一种实际输出与预期输出间的审核或者比较过程。
软件测试的经典定义是:在规定的条件下(行业标准、客户要求、研发团队内部因素)对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。
可使用人工操作或者软件自动运行的方式来检验是否满足规定的需求弄清预期结果与实际结果之间的差别过程
 
  • 如何衡量软件的质量?
软件质量:软件与明确的和隐含的定义的需求相一致的程度。通俗点就是,软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的和隐含特征相一致的程度。
 
先来看看影响软件质量的因素:
产品运行:正确性、可靠性、易用性、完整性、效率
产品修改:维护性、灵活性、易测试性
产品转移:可移植性、可操作性、可复用性
满足上面所有影响因素,就能证明软件的质量是好的么?当然。但即使没有满足这些所有因素,在某些特定条件下,也能说明软件的质量是好的。
例如:客户的要求,满足客户对软件质量的要求(如:数据正确;但不要求界面美观),这样的软件交付给客户,客户也认为质量是好的,满足了它实际需要的上线质量标准。
作为测试人员,阶段性的完成测试工作,也需要评定当前软件的质量,以便研发项目组内做相应的决策。
但BUG多的功能或模块就一定意味着质量差么?不一定!要看软件功能或模块的结构、复杂度、优先级、重要性来决定。
例如1:A模块是核心模块,算法复杂,绝对不能出数据问题,哪怕阶段测试发现数据类问题不多,但却影响很大很广(关联影响大),这意味着质量堪忧。团队必须尽快分析根因、制定解决措施,预估风险,控制关联影响问题反复发生。
例如2:B模块是非核心模块,使用频率可能并不高,但阶段测试发现各类问题很多,这也不一定意味质量不好,它的修复优先级可能并不高。团队优先处理类似A模块的问题更重要。
 
  • 软件测试的分类?
1、角度细分:
1)从是否关心软件内部结构和具体实现的角度划分:
a、黑盒测试(现阶段重点关注)
b、白盒测试
c、灰盒测试
2)从是否执行程序的角度:
a、静态测试(文档评审)(现阶段重点关注)
b、动态测试(系统操作)(现阶段重点关注)
2、阶段细分(软件开发过程):
1)单元测试/功能测试(现阶段重点关注)---注:这里先关注功能测试,而非开发类的单元测试
2)集成测试(现阶段重点关注)---注:接口测试、场景测试
3)确认测试
4)系统测试(现阶段重点关注)
5)验收测试
6)回归测试(现阶段重点关注)
7)Alpha测试
8)Beta测试
需要了解每个阶段的测试分别是何时做、范围是什么、侧重点是什么(留给大家思考)
 
  • 软件测试V模型

-----------------------------------------------------------------------------------------------------------------

软件测试的概念

阅读数 227

软件测试基本概念

阅读数 394

没有更多推荐了,返回首页