到底要不要做软件测试_之前做软件开发的想转测试要不要报个培训班 - CSDN
  • 首先你对软件测试是否足够了解, 软件测试是目前的热门行业,薪资也比一般的行业高,工资的增长幅度也比较快,这些都是光鲜得有里面,但是软件测试的工作压力还是比较大的, 技术更新也比较快, 软件测试是一分付出...

    首先你对软件测试是否足够了解, 软件测试是目前的热门行业,薪资也比一般的行业高,工资的增长幅度也比较快,这些都是光鲜得有里面,但是软件测试的工作压力还是比较大的, 技术更新也比较快, 软件测试是一分付出一分收获,薪资就是对你最好的肯定。

    如果你做好了选择,决定从事软件测试,那就接着往下看

    自学

    优势:金钱成本较低,能够按照自己设定的学习计划进行学习,时间安排也比较自由。

    劣势:自学消耗的时间比较长,如果没有基础的话,想要自学也是比较难的,相对于有一定基础的,现在网上的软件测试资料也比较多, 需要自己去识别哪些是自己要学习的, 不然很容易陷入迷茫。

    培训

    优势:学习时间相对较短,整体学习比较全面,学习内容也比较集中。而且有老师给指导,学习的范围也是目前行业的热门技术,学习更有针对性,转行的效率更高

    劣势:相对于自学,培训是需要金钱成本,一般的培训机构学习费用都在一万五到三万不等左右,还要加上学习期间的生活费,学习成本比较高,

    如果你不是一个自制能力很强的人(你自己也觉得不是),那还是选择培训比较靠谱一些

    如何选择培训机构

    1、就业薪资虚假宣传,薪资动不动就达到一两万,不务实,你让公司里那些做了几年还没这个数的前辈们情何以堪。

    2、就从老师来说吧,选择授课老师的实战经验比较足的机构,这些老师讲的内容基本都是行业的热门技术,现在有些机构还在讲QTP这种业界目前不太流行的工具,简直就是误人子弟。

    3、选择小班教学的机构,最好不要超过15个人一个班的机构,这样老师才能够照顾到每一个学生,让每一个学生听懂,把知识学扎实, 学生太多就算是名师也不能照顾到每一个人。

    4、行业内口碑比较好,业界没有学生的负面新闻,学生对培训机构比较认可,这种机构把精力放在了学生身上的机构,才是做教育的应有态度。

    展开全文
  • 软件测试过程中,最主要的就是掌握好软件测试的方法,掌握好了软件测试方法,有利于测试技能的大幅度提高。 软件测试方法 软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样...

          软件测试过程中,最主要的就是要掌握好软件测试的方法,掌握好了软件测试方法,有利于测试技能的大幅度提高。

    软件测试方法

           软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样化,针对性更强;选择合适的软件测试方法可以让我们事半功倍。

    一、根据是否要走查代码,分为白盒测试、灰盒测试、黑盒测试;

    二、分为手工测试、自动化测试和性能测试:

    手工测试:UI测试、冒烟测试、随机测试、本地化测试、安装测试、卸载测试;

    自动化测试:

    性能测试:健全测试、衰竭测试、负载测试、强迫测试、压力测试、恢复测试;

    三、根据是否要运行程序,分为静态测试和动态测试;

    四、按测试阶段可分为:单元测试、集成测试、系统测试、回归测试、验收测试、α测试_Alpha测试、β测试,英文是Beta testing。又称Beta测试,用户验收测试(UAT);

    五、其他测试方法:端到端测试、接受测试、安全测试、兼容性测试、可用性测试、比较测试、边界测试、强力测试、装配安装测试、隐藏数据测试、等价划分测试、判定表测试、深度测试、基于设计、文档测试、域测试、接口测试、逆向测试、非功能性测试、极限测试等。

    其中一些测试方法的定义

    端到端

           端到端测试,英文是End to End Testing。

           端到端测试类似于系统测试,测试级的“宏大”的端点,涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。端到端架构测试包含所有访问点的功能测试及性能测试。端到端架构测试实质上是一种"灰盒"测试,一种集合了白盒测试和黑盒测试的优点的测试方法。

    健全测试

           健全测试,英文是Sanity testing。

           健全测试是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试能力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,不具备进一步测试的条件。

    衰竭测试

          衰竭测试,英文是Failure Testing。

          衰竭测试是指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

    负载测试

           负载测试,英文是Load testing。

           负载测试是测试一个应用在重负荷下的表现。例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。

    负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    强迫测试

           强迫测试,英文是Force Testing。

           强迫测试是在交替进行负荷和性能测试时常用的术语。也用于描述对象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。

    压力测试

           压力测试,英文是Stress Testing。和负载测试差不多。

           压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分。压力测试的基本思路很简单:不是在常规条件下运行手动或自动测试,而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。

    恢复测试

           恢复测试,英文是Recovery testing。

           恢复测试是测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。恢复测试指通过人为的让软件(或者硬件)出现故障来检测系统是否能正确的恢复,通常关注恢复所需的时间以及恢复的程度。

           恢复测试主要检查系统的容错能力。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败,然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化(reinitialization)、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性;对于人工干预的恢复系统,还需估测平均恢复时间,确定其是否在可接受的范围内。

     

    可用性

           可用性测试,英文是Practical Usability Testing。

           可用性测试是对“用户友好性”的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

    比较测试

           比较测试,英文是Compare Testing。

           比较测试是指与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。来取长补短,以增强产品的竞争力。

    强力测试

           强力测试,英文是Mightiness Testing。

           强力测试通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如,在最低的硬盘驱动器空间或系统记忆容量条件下,验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机。

    装配安装

           装配/安装/配置测试是验证软件程序在不同厂家的硬件上,所支持的不同语言的新旧版本平台上,和不同方式安装的软件都能够如预期的那样正确运行。比如,把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上,再验证所有功能都正常运行。

    隐藏数据

           隐藏数据测试在软件验收和确认阶段是十分必要和重要的一部分。程序的质量不仅仅通过用户界面的可视化数据来验证,而且必须包括遍历系统的所有数据。

           假设一个应用程序要求用户两条信息-----用户名和密码来创建帐户。这个用户输入这两条数据后保存。最后,一个确认窗口将通过数据库中找到这条数据来显示用户名和密码给用户。为了验证所有的数据保存是否正确,一个QA测试人员会在这个确认窗口简单的查看下用户名和密码。如果他们成功了?假设数据库记录了第三条信息----创建日期,它可能不会出现在确认窗口,而只在存档中才出现。如果创建日期保留的不正确,而QA测试人员只验证屏幕上的数据,那么这个问题就不可能被发现。创建日期可能就是一个bug,由于一个用户帐户保存了一个错误的日期到数据库中,这个问题也不可能会被引起注意,因为它被用户界面所隐藏。这只是一个简单的例子,但是它却演化出了一点:隐藏数据测试的重要性。

    判定表

           判定表的英文是decision table,是指一个表格,用于显示条件和条件导致动作的集合。

           定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

           判定表的优点:能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。

           在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题

    深度测试

           深度测试的英文Depth test ,是指执行一个产品的一个特性的所有细节,但不测试所有特性。

          当比较函数返回真的时候才显示出效果来。必须启用“#深度测试”,才能执行测试。不使用的时候需要关闭。

    基于设计

           基于设计的测试的英文是design-based testing,是根据软件的构架或详细设计引出测试用例的一种方法。

           一种基于设计模型的测试方法(Model Based TestIng System,MATIS).该方法利用用户界面自动生成方法,把设计模型中的类属性定义和实现中的控件属性组织在一起,构建描述界面的逻辑对照表,辅助测试脚本引擎执行自动测试脚本.借助设计模型中扩展的类定义,MATIS方法可以自动生成测试用例和测试数据。

    域测试

           域测试的英文是domain testing,定义参考等价划分测试(equivalence partition testing);

           一般分为单域测试和多域测试,其中单域测试包括设备测试和业务测试,设备测试包括测试某个系统的软交换设备、中继媒体网关设备、信令网关设备、接入媒体网关和IAD等设备。

           等价类划分有两种不同的情况:有效等价类和无效等价类。设计时要同时考虑这两种等价类,因为软件不仅要能接收合理的数据,也要能经受意外的考验。

           一有效等价类:是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

           二无效等价类:与有效等价类的定义恰巧相反。

    逆向测试

           逆向测试/反向测试/负面测试的英文是Negative Testing,测试瞄准于使系统不能工作。

           负面测试与正面测试的比较:

           负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说,正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点,正面测试就象一个毕恭毕敬的小学生,老师叫我做什么,我就做什么;而负面测试就象一个调皮捣蛋的孩子,你叫我这样做,我偏不这样做,而且和你对着干。开发人员也是最讨厌修改此类bug的。

    非功能性

           非功能性需求测试的英文是non-functional requirements testing ,是与功能不相关的需求测试,如:性能测试、可用性测试等。

           为什么非功能性需求很重要?

           在您设计解决方案的过程中满足功能性需求当然是很重要的。但是,如果没有考虑非功能性需求,您的解决方案则很难取得实效。

           非功能性需求特点:1.不要脱离实际环境;2.可靠性;3.可用性;4.有效性;5.可维护性;6.可移植性。

    极限测试

    简介

    极限测试本质上是为了满足极限测试的思想和流程而设计的一套测试策略和流程,其本身并不局限于使用特定的测试技术和方法。

    过程

    1.单元测试

    2.验收测试

        要熟记各个测试方法的意义,并且,灵活的运用它,这样,测试技能,将能更上一层楼。 

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 软件测试复习(部分) 概述 程序+文档+数据=软件 ...为什么要做软件测试 发现软件缺陷 功能错 功能遗漏 超出需求部分(画蛇添足) 性能不符合要求 软件质量高低:是否符合用户习惯、符合用户需求 测试...

    软件测试

    概述

    程序+文档+数据=软件

    狭义的软件测试定义:为发现软件缺陷而执行程序或系统的过程

    广义的软件测试定义:人工或自动地运行或测定某系统的过程,目的在于检验它是否满足规定的需求或弄清预期结果和实际结果间的差别

    为什么要做软件测试

    • 发现软件缺陷
      • 功能错
      • 功能遗漏
      • 超出需求部分(画蛇添足)
      • 性能不符合要求
    • 软件质量高低:是否符合用户习惯、符合用户需求

    测试的任务

    • 找出
    • 定位
    • 修改
    • 修改后要做回归测试,对已修改的部分进行再次的测试,避免引入新的错误

    测试用例的定义和组成部分

    • 测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。
    • 包含
      • 用例ID
      • 用例名称
      • 测试目的
      • 测试环境
      • 前提条件
      • 测试步骤
      • 预期结果
      • 其他信息

    一个好的高质量的测试用例在于能发现至今未发现的错误,一个成功的测试是发现了至今未发现的错误的测试(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    两个方向

    • 找错误,反向思维。
    • 证明能正常工作,正向思维。
    • 目前的方法出发点一般是“找错误”,因为没法证明软件是正确的。

    用户需求

    要求(用户想要) 需求(用户目的) 需要(用户内在欲望)
    牙膏 清洁牙齿 个人魅力(个人外表整洁)

    什么时候停止测试

    • 继续测试没有产生新的失效
    • 继续测试没有发现新缺陷
    • 回报很小
    • 以达到要求的覆盖
    • 无法考虑新的测试用例(若已遵循测试规则和指导方针,则可以选择)

    测试过程模型

    缺陷具有放大的特点,随着阶段的推进发现bug的成本会指数型上升,所以并不是代码级的测试才叫测试,而是开发过程各个阶段越早开始测试越好。

    • 瀑布模型:需求分析->设计(概要、详细)->编程->测试(单元、集成、系统)->维护
    • V模型(瀑布-改):在软件开发的生存期,开发活动和测试活动几乎同时的开始,如概要设计阶段结束后集成测试的测试用例就出来了、详细设计阶段结束后单元测试的测试用例也就出来了等
    • W模型(V模型更加细化、每步都加测试,边造软件边进行测试):需求分析加了需求测试、概要设计加了功能测试、详细设计加了设计测试、编码加了单元测试、集成加了集成测试、确认加了确认测试、验收加了系统测试
    • H模型:无实际意义,仅说明可以独立测试

    软件测试的原则

    • 所有的测试都应追溯到用户的需求
    • 尽早地和不断地进行软件测试(缺陷具有放大的特点,测试成本随阶段深入而上升)
    • 8-2原则
      • 测试中发现的错误80%很可能起源于程序中的20%
      • 提前测试可发现80%,系统测试找出剩余bug的80%(总体的16%),最后的4%可能只有用户大范围长时间使用后才暴露出来
      • 80%的工程用在20%的需求上(即关键需求)
    • 软件缺陷的寄生虫性:找到的缺陷越多说明软件遗留的缺陷越多
    • 避免自己测试自己的程序
    • 回归测试:避免引入新的错误

    软件测试流程

    制定测试计划->测试设计->测试开发->测试执行->评估测试

    注意

    • 测试不是开发后期的一个阶段
    • 测试入门其实稍容易,但要求技术一样高
    • 测试多数情况下不能覆盖所有输入
    • 不要“有时间多测,没时间少测”
    • 软件测试不止是测试人员的事,也是开发人员的事
    • 调试和测试不一样
    • 测试绝非只运行一下软件看结果对不对

    L10N:本地化测试

    I18N:国际化测试

    黑盒测试

    等价类划分与边界值分析

    如何划分有效和无效等价类(一些常用原则)

    • 如果一个变量在某一个范围内,给它一个有效等价类两个无效等价类
    • 如果一个变量取值在某一个集合范围内,可在集合内取一个有效等价类在集合外取一个无效等价类
    • 如果一个变量的条件是“必须怎样”、“一定会是怎样”则去一个值满足“必须要”的条件再取多个不满足的从多个角度去违背这个条件
    • 如果一个变量是布尔类型,则取一个对的一个错的

    在找到有效等价类和无效等价类后如何找测试数据

    • 有效等价类:要尽可能多的覆盖有效等价类
    • 无效等价类:每找到一组数据要至少覆盖一组无效等价类

    如果功能模块的输入是多个,多个自变量放在一起如何找有效等价类、无效等价类、测试数据,4钟方法:

    以一个具有自变量X1、X2的函数F为例,X1取值范围为[a, b)、[b, c)、[c, d];X2取值范围为[e, f)、[f, g]。仅考虑有标记的方块内为一般等价类测试(不处理无效数据的测试)、所有方块都考虑为健壮等价类测试(进行无效数据处理的测试)

    g |_______|_______|_______|_______|_______|
    f |_______|///////|///////|///////|_______|
    e |_______|///////|///////|///////|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    • 弱一般等价类
      • 有假设前提:是单缺陷的,即假设系统出现的缺陷很少是由两个及以上的输入变量共同出现缺陷而引起的。
      • 选取的测试用例覆盖所有的有效等价类
        • 对于X1(横轴):[a, b)、[b, c)、[c, d]都需要覆盖到;对于X2(纵轴):[e, f)、[f, g]都需要覆盖到。保证了这两点的情况下,就可以任意取点了
    g |_______|_______|_______|_______|_______|
    f |_______|_______|____x__|_______|_______|
    e |_______|___x___|_______|___x___|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    • 强一般等价类
      • 基于多缺陷假设
      • 选取的测试用例覆盖所有的有效等价类的笛卡尔积(集合A{a1,a2,a3} 集合B{b1,b2} 他们的 笛卡尔积 是 A*B ={(a1,b1),(a1,b2),(a2,b1),(a2,b2),(a3,b1),(a3,b2)} )
        • 对于X1(横轴):[a, b)、[b, c)、[c, d];X2(纵轴):[e, f)、[f, g],笛卡尔积的结果就是所有的格子,所以必须所有格子都取点
    g |_______|_______|_______|_______|_______|
    f |_______|___x___|___x___|___x___|_______|
    e |_______|___x___|___x___|___x___|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    • 弱健壮等价类
      • 有假设前提:是单缺陷的,即假设系统出现的缺陷很少是由两个及以上的输入变量共同出现缺陷而引起的。
      • 考虑无效值,对有效输入,测试用例的设计等同于弱一般等价类;对无效输入,测试用例需要保证拥有一个无效值(比如某一变量的有效类的取值范围为x、y、z,则无效类为x-和z+,加起来取值范围一共:x-、x、y、z、z+),并保持其余的值都是有效的。

    所以如下图,在保证弱一般等价类的取点后,还需要分别保证X1、X2中有1个属于无效输入的两个额外的取值范围,另一个属于有效输入的原本取值范围(如X1取无效X2取有效或X1取有效X2取无效,并全部覆盖无效范围)

    g |_______|_______|_______|___O___|_______|
    f |_______|_______|___x___|_______|___O___|
    e |___O___|___x___|_______|___x___|_______|
      |_______|___O___|_______|_______|_______|
              a       b       c       d
    • 强健壮等价类
      • 基于多缺陷假设
      • 所有的取值范围取笛卡尔积(比如某一变量的有效类的取值范围为x、y、z,则无效类为x-和z+,加起来取值范围一共:x-、x、y、z、z+,再与另一变量的取值范围取笛卡尔积)
    g |___O___|___O___|___O___|___O___|___O___|
    f |___O___|___x___|___x___|___x___|___O___|
    e |___O___|___x___|___x___|___x___|___O___|
      |___O___|___O___|___O___|___O___|___O___|
              a       b       c       d

    在找测试数据时(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    • 对于单缺陷的,即只有一个输入变量是处于无效等价类,其他所有输入变量都处在有效等价类中。包含:
      • 单缺陷有效值
      • 单缺陷无效值
    • 对于多缺陷的,即多个输入变量同时出现错误引起的。包含:
      • 有效值
      • 无效值

    与等价类划分密切相关的就是边界值分析。先划分等价类,再结合边界值产生测试用例。边界值分析中也有假设前提:单缺陷。包含4种设计测试用例的方法:

    • 一般的边界值分析
      • 有效范围:最小的、比最小大一点的、正常值、比最大小一点、最大值
      • 无效范围:比最小更小、比最大更大
      • 共7个,再分单缺陷和多缺陷,这样设计测试用例的个数就会指数上升
    - 单变量假设 多变量假设
    有效值 **一般边界值**5n-(n-1)【n-1个变量取正常值】=4n+1【仅考虑有效区间单个变量边界值(一般边界值):用最小值、略高于最小值、正常值、略低于最大值和最大值。】 **一般最坏情况边界值**5^n【仅考虑有效区间多个变量边界值同时作用(一般最坏情况边界值):用各个变量最小值、略高于最小值、正常值、略低于最大值和最大值的笛卡尔积。】
    无效值 **健壮性边界值**7n-(n-1)=6n+1【 同时考虑有效区间和无效区间单个变量边界值(健壮边界值):除了最小值、略高于最小值、正常值、略低于最大值、最大值,还要有略超过最大值和略小于最小值的值。】 **健壮最坏情况边界值**7^n【同时考虑有效区间和无效区间多个变量边界值同时作用(健壮最坏情况边界值):用各个变量最小值、略高于最小值、正常值、略低于最大值、最大值、略超过最大值和略小于最小值的笛卡尔积。】

    常见的边界值

    • 16bit整数32767~-32768
    • 报表第一行和最后一行
    • 屏幕光标最左上和最右下
    • 数组的第一个和最后一个
    • 循环的第0、1、倒数第一、倒数第二次

    决策表

    适合于问题有多个条件,条件有多种组合执行不同操作(有很多if、else if、else),不能表达循环结构

    最严格、最具有逻辑性

    判定表
    | 条件桩 | 条件项 | ... | 动作项 |
    | 动作桩 | 动作项 | ... | 动作项 |

    规则:条件的任意组合,判定表中的一列(贯穿条件项和动作项)。判定表有多少列就代表有多少条规则。

    规则的化简:有的规则相互包含,可以化简

    因果图

    找出所有的原因,找出结果,可能还有中间结果的产生,在画因果图时注意。

    • 从输入考虑
      • I:连虚线出去,如连到ab,表示ab中至少有一个必须成立
      • E:连虚线出去,如连到ab,表示ab不能同时成立
      • R:如处于a指向b的虚线三角箭头上,表示a出现时b也必须出现,不可能一个出现一个不出现
    • 从输出考虑
      • M:如处于a指向b的虚线三角箭头上,表示a为1时b必须为0,a为0时b值不定
    • 连线:恒等
    • ~:非
    • ∨:或
    • ∧:且
    • ci:原因
    • ei:结果

    画出因果图后,根据图得到决策表从而得到相应的测试数据:原因节点+中间节点为条件桩,结果结点为动作桩

    白盒测试

    逻辑覆盖

    语句覆盖->判定覆盖->判定/条件覆盖->条件组合覆盖->路径覆盖
          \_条件覆盖/
    • 语句覆盖:每条语句执行一次
    • 判定覆盖:每个判定分支至少执行一次
    • 条件覆盖:每个判定条件应取到各种可能的值
    • 判定/条件覆盖:同时满足判定和条件
    • 条件组合覆盖:每个判定条件的每一种组合各出现一次
    • 路径覆盖:每一条可能的路径至少执行一次

    关系:

    • 条件组合覆盖>判定覆盖>语句覆盖(即如果达到条件组合覆盖,就达到判定覆盖和语句覆盖:如果达到判定覆盖,就达到语句覆盖,下面类似理解)。
    • 条件组合覆盖>条件覆盖。
    • 条件覆盖不一定包含判定覆盖、语句覆盖。
    • 判定覆盖不一定包含条件覆盖。
    • 路径覆盖,判定覆盖>语句覆盖。

    基本路径测试

    基于程序圈复杂度产生的测试方法,画出控制流程图,算圈复杂度,找到独立路径并压缩为基本路径集合,根据集合中每条路径设计用例。把复合逻辑表达式拆成单个表达式

    圈复杂度用于计算程序的基本的独立路径数目(每条新的独立路径都必须包含一条新的有向边,从入口到出口互不相同的路径数)

    • 圈复杂的V(G) = e - n + 2p【边-节点+2*连接区域数,连接区域p通常为1】=P+1【判定节点数+1】
    • 一般来说,一个单元模块的最大复杂度V(G)<10

    如果把覆盖的路径数压缩到一定限度内,例如程序中的循环体只执行0次和1次,就成为基本路径测试,通过导出基本路径集合,从而设计测试用例,保证这些路径至少通过一次

    基于数据流的测试

    基于真的数据定义到数据的使用来进行测试,需要找到定义的节点(包括赋值的和比较的)和使用的节点(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    • 定义节点DEF:输入语句、赋值语句、循环语句和过程调用;变量的值会发生变化的语句
    • 使用节点USE:数出语句、赋值语句、条件语句、循环控制语句、过程调用

    需要找到所有这段功能代码从哪里开始定义,到哪里开始执行,把路径找出来。什么是定义使用路径(某一变量在最初节点定义到最终节点被使用)、定义清除路径(某一个变量从它的定义节点到使用节点这个过程中没有对这个变量进行二次定义)

    循环测试

    前提是程序是结构化的。

    简单循环测试

    • 0次通过循环
    • 1次通过循环
    • 2次通过循环
    • m次通过循环(m<=循环最大次数)
    • m-1,m,m+1次通过循环

    测试的过程

    单元测试

    单元测试的内容:5点(简答题)

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

    单元测试的模块

    • 被测模块:被测试的程序的模块
    • 驱动模块:用来模拟测试模块的上一级模块,相当于被测模块的主程序
    • 桩模块:用来模拟被测模块工作过程中所调用的模块

    单元测试的工具:Junit相关的概念:以插入断言的方式进行测试(类似黑盒测试)

    • 针对被测代码或者被测的功能点先创建测试类,然后在类里面创建一个个测试方法。通过实例化对象调用被测方法,用断言进行实际值预期值比较。

    单元测试的方法

    • 以白盒测试法为主(覆盖),先静态检查代码是否符合规范,再动态运行代码,检查结果。除了需要验证结果是否正确,还需要检查程序的容错能力、边界值处理等问题。

    集成测试

    • 一次性的集成big-bang:把所有通过了单元测试的模块按设计要求一次全部组装起来,然后进行整体测试。时间随变短了但急于求成。
    • 渐进地集成
      • 自上而下:从主程序模块开始按深度或广度优先策略边组装边测试
      • 自下而上:从最底层模块开始组装和集成测试
      • 汉堡包:两者进行结合,树状图每层画线,顶层采用自顶向下,底层采用自底向上
        相邻的集成:上下三层进行集成
        成对集成:先成对再相邻
        基于MM路径的集成:MM路径不是可执行路径,描述单元之间的控制转移。

    最终得到调用图,然后就会到基本路径测试,找复杂度,找路径,得到测试用例的套路

    系统测试

    黑盒为主(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    对哪些内容进行系统测试(9个):易用性、国际化本地化、性能、功能、界面、兼容性、安全性、文档、安装

    Web系统测试

    具体到如Web系统测试中的功能测试包含哪些内容、对cookies里面的内容进行测试属于Web系统测试里面的哪一项的测试(属于功能测试)

    • 功能测试
      • 页面内容测试
      • 页面链接测试
      • 表单测试
      • Cookies测试、Session测试
      • 设计语言测试
      • 数据库测试
    • 性能测试(负载/压力)
      • 连接速度测试
      • 测试工具 LoadRunner
        • 负载测试
        • 压力测试
      • 网页性能Firefox插件:Yslow,Findbug,PageSpeed
      • Dynatrace检查网页性能
    • 可靠性测试:不间断测试,看多久不出错
    • 用户界面测试/易用性测试
      • 导航测试
      • 图形测试
      • 内容测试
      • 整体界面测试
    • 安全性测试
    • 兼容性测试
    • 接口测试
      • 服务器接口
      • 外部接口
      • 错误处理

    主要讲了性能测试的含义和怎么做,如所涵盖的含义如压力测试怎么做、负载测试怎么做等

    • 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
      • 时间性能:软件的一个具体事务的响应时间
      • 空间性能:软件运行时所消耗的系统资源
      • 我让你背1袋米(轻松)
      • 我让你背1袋米,但让你去操场上跑圈,看多久累倒(吃力)
      • 我让你背3袋米去操场跑圈,看多久累倒(极限)
      • 我让你背1袋、2袋、3袋、4袋…发现最多背3袋
    • 负载测试让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的可靠性。
      • 系统能否处理某个时刻同时访问Web系统/某个页面的用户数量
      • 超过了这个数量,会出现什么现象?
      • 在线数据处理的数量
    • 负载/压力测试关注什么?
      • 验证系统能否同一时间响应大量的用户,用户传送大量数据时能否响应,系统能否长时间运行。
        • 瞬间访问高峰
        • 每个用户传送大量数据
        • 长时间使用
    • LoadRunner性能测试工具原理:录制+回放模拟用户实际操作场景,监控并分析运行结果。

    自动化测试

    录制+回放+脚本 是主要的方式

    常用的自动化测试的工具,哪些种类,每种有什么工具

    • 功能测试工具:QTP
    • 性能测试工具:LoadRunner
      • 写脚本或者录制脚本
      • 使用用户自定义参数
      • 场景设计
      • 产生虚拟用户的机制:使用控制器,来控制模拟多少用户。
      • 使用监听器,查看测试结果

    (Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)


    visitor tracker
    访客追踪插件


    展开全文
  • 软件测试--用例编写

    2018-08-15 18:47:30
    测试用例编写是软件测试的基本技能;也有很多人认为测试用例是软件测试的核心;软件测试中最重要的是设计和生成有效的测试用例;测试用例是测试工作的指导,是软件测试的必须遵守的准则。 在这里我们不讨论以上的...

    测试用例编写是软件测试的基本技能;也有很多人认为测试用例是软件测试的核心;软件测试中最重要的是设计和生成有效的测试用例;测试用例是测试工作的指导,是软件测试的必须遵守的准则。

    在这里我们不讨论以上的各种观点,但是综上所述,大家可以看出,测试用例编写这项软技能非常重要且是测试人的必备技能,相信很多人没有质疑。

    下面我们介绍下测试用例编写。

    我们将用例编写分为黑盒用例编写和白盒用例编写两大类。

    总体编写思路:

    黑盒测试用例(优先)+白盒测试用例(补充)=完整测试用例

    总体编写策略:

    对于测试用例编写来说,常用的四种方法基本就够用了,等价类、边界值、正交实验法、错误推断法,辅以场景测试法、需求/设计转换法、探索式测试思想,可以应付绝大多数产品的测试。个别的产品还需要在某一点细化和扩充,需要就事论事。

    使用各种编写方法的综合设计策略; 

    1)在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。

    2)必要时用等价类划分方法补充一些测试用例,尤其注意无效等价类情况。

    3)如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法(或判定表法、正交试验法)。

    4)用错误推测法再追加一些测试用例,主要是利用测试经验。

    5)对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例;参照白盒用例编写。

    6)对程序的应用场景进行研究和思考,增加不同场景下的测试用例;用户场景测试必须重视,很大一部分程序错误就是因为测试场景与用户真实场景的差异性带来的。

    7)对业务和程序有更深的理解之后,可以充分发挥发散思维和探索式想法;大家不要误解探索式测试就是漫无目的的测试,其实探索式测试有非常详细的测试指导思路。

     

    第一部分:黑盒用例编写

    常见的方法如下:

    • 等价类

    • 边界值

    • 因果图

    • 判定表驱动法

    • 正交实验法

    • 功能图法

    • 场景实验法

    • 错误推断法

    • 需求转化

    • 设计文档

    • 探索式测试

    1、黑盒-等价类

    等价类:选取少数有代表性的数据,这一类数据等价于这一类的其它值;找出最小的子集,可以发现最多的错误;

    两大特性:必须设计的用例;涵盖了大部分情况;

    两类情况:有效等价类;无效等价类;

    转化为测试用例

    1、按照输入条件、有效等价类、无效等价类建立等价类列表,列出所有的等价类;

    2、为每一个等价类固定一个编号;

    3、设计一个测试用例,使其覆盖一个或多个有效的等价类;

    4、设计一个或更多的测试用例以覆盖剩余的有效等价类;

    使用场景:输入条件(取值范围/值个数;必须值集合;布尔值;一组处理值;必须遵守的规则;再细分更小等价类;)

    等价类举例:

    以三角形测试为例:输入3个整数做为三角形的三个边,通过程序判定三角形的类型。

    2、黑盒-边界值

    边界值:所谓边界条件,是指输入和输出等价类中那些恰好处于边界、超过边界、或在边界以下的状态 ;

    两个特征:选择一个或多个元素,以便等价类的每一个边界都经过了测试;与仅仅关注输入条件不同,还需要考虑结果空间(输出等价类)设计测试用例;

    边界条件可能非常微妙,因此把他们确定下来煞费心思;

    使用场景:输入+输出都需要考虑(值的范围;值个数;有序集合;内部数据结构;分析规格说明;)

    边界值举例

    以三角形测试为例:输入3个整数做为三角形的三个边,1<a、b、c<10,通过程序判定三角形的类型;

    3、黑盒-因果图

    因果图:输入条件的组合进行分析。用一个系统的方法选择出高效的测试用例集;

    分析思路

    1、分析规格说明描述,确定原因和结果,并赋予标识符;

    2、分析规格说明语义,找出原因与原因之间,原因与结果之间关系,画出因果图;

    3、有些原因与原因之间,原因与结果之间组合不会出现,用记号表明约束或限制条件;

    4、因果图转换为判定表;

    5、判定表的每一列作为依据,设计测试用例;

    使用场景:必须考虑输入条件的各种组合(一种适合于描述多种条件的组合、相应产生多个动作的形式来进行设计);

    4、黑盒-判定表

    判定表:分析和表达多逻辑条件下执行不同操作的情况的工具 ;略过因果图的绘制,直接列出所有组合进行筛选;

    分析思路:判定表通常有四个部分组成:条件桩、动作桩、条件项、动作项;

    判定表的建立步骤:(根据软件规格说明)

    确定规则个数;列出所有条件桩和动作桩;填入条件项;填入动作项,得到初始判定表;简化合并相似规则;

    使用场景:控制类和游戏。优点是能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。缺点是不能表达重复执行的动作,例如循环结构。

    5、黑盒-正交试验法

    正交实验法:利用因果图来设计测试用例时, 输入原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到;往往因果关系非常庞大,以至于测试用例数目巨大,为了有效地、合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

    分析思路

    1、提取功能说明,构造因子--状态表 ;

    2、加权筛选,生成因素分析表 ;

    3、利用正交表构造测试数据集 ;

    使用场景:必须考虑输入条件的各种组合(从大量的数据中挑取适量、有代表性的点,合理有效的测试);

    6、黑盒-场景实验法

    场景实验法:软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流;生动的描绘出事件触发时的情景,有利于设计用例,同时测试用例也更容易的得到理解和执行。

    分析思路:

    每条路径都反映了基本流和备选流;基本流是最简单的路径;备选流自基本流开始,会有特定条件下加入并执行,可能有多种情况;

    使用场景(0代表基本流):0;0+1;0+1+2;0+3;0+3+1;0+3+1+2;0+4;0+3+4;…

    7、错误推断法

    错误推断法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法;更多的与用户的使用习惯及测试程序中的常见问题为主。

    分析思路:

    列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据这些情况选择测试用例;

    注意积累与分享;

    使用场景:任何测试、任何情景下都会用到的方法。

    有常用的测试用例集,可以参照。

    举例:数字输入验证,分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值;不合法的输入,系统给出必要的判断提示信息;

    8、黑盒-需求转换法

    需求转换法:根据需求,执行需求分析,并编写测试用例。

    分析思路:

    将需求转换为思维导图;

    仔细推敲每一个字的含义;

    与用户的使用场景和目的结合;

    严格设计每一个用例;

    可以建立一种模型,进行需求转换;

    使用场景:任何测试、任何情景下都会用到的方法。

    注意:需求的变更带来的影响;需求理解偏差带来的影响;需求含糊不清带来的影响等;

    9、黑盒-设计文档

    设计文档:参照设计文档,可以理解软件系统内部设计流程及处理机制,对比写好的测试用例,可以在对应功能及模块处新增;

    分析思路:

    仔细阅读设计文档;

    与相关人员沟通实现机制;

    结合测试用例编写方法,对比之前写好的用例;

    使用场景:任何测试、任何情景下都会用到的方法。

    注意:设计文档的编写正确性;设计文档的理解偏差;

    10、黑盒-探索式测试法

    探索式测试法:无限创意的测试点,永无止境的探索测试;我们要在测试的最前沿发挥洞察力、技术及应变措施,找出产品的缺陷;

    分析思路:

    局部探索式测试;全局探索式测试;混合探索式测试;

    使用场景:任何测试、任何情景下都会用到的方法。像漫游一样,自由地寻找软件中的缺陷,软件测试的未来必然有探索式测试。

     

    第二部分:白盒用例编写

    基本思路:

    第一步需要绘制流程图;

    第二步根据路径分析法确定测试用例;

    第三步使用等价类/边界值的方法确定测试用例的数据

    第四步根据实际情况补充(如默认流程、特殊流程等)

    基本策略:

    1、语句覆盖准则基本上没啥用,比较强的逻辑覆盖准则是判定覆盖或者条件覆盖;通常判定覆盖可以满足语句覆盖;语句覆盖<判定覆盖<条件覆盖;

    2、循环覆盖来说,完全的路径测试并不符合实际;

    展开全文
  • 出来做软件测试三,四年了,确实正应了那句“测试不如开发”,只是个人观点,而且我工作过都是外企和大型国有企业,软件测试流程和管理都相对很规范化的。 下面几点给测试的朋友参考一下:   ...

    出来做软件测试三,四年了,确实正应了那句“测试不如开发”,只是个人观点,而且我工作过都是外企和大型国有企业,软件测试流程和管理都相对很规范化的。

    下面几点给做测试的朋友参考一下:

     

    1、钱肯定少过开发人员,除非你工作七,八年才能拿年薪10W以上,一般的软件测试工程师很难上10K以上,开发人员工作四,五年后拿7,8K是太多数的。

     

    2、加班的现象可以说是很普遍,周一到周五随时加班是很正常的,周末肯定有一天要加班。

     

    3、不管怎么样努力和用什么测试效果的数据说明,领导还是不太重视测试部,领导认为我们测试的没有什么技术含量。但是我们已经在流程上改进很大,使用测试管理工具和自动化测试工具来提高测试生产力等等,这些努力的结果好象只有我们的老大才得分比较高,我们下面的小兵就只有吃苦的份。

     

    4、团队合作精神比较差,都是做技术的人的通病,以为你在一间公司呆久了,就很牛B一样,说话口气难于接受,好象现在公司就是他的一样。这个问题在几间公司里面的测试队伍中得到证实。在工作之余,很少团队一起聚餐或是出外游玩的机会,好象大家就知道上班---吃中午饭--上班--吃晚饭---加班---下班回家---睡觉的简单模式。

     

    5、人际关系和沟通技能都很重要,这一点不用我多说,大家都知道的。

     

    6、还有一点要提醒测试人员的是:做测试容易懒惰,因为重复性的工作比较多,然后在公司呆着好好的,什么都不想学和提高了,这样容易使你在软件的测试面比较狭窄了,其实你到其他的公司面试的时候,才发现自己很多不知道,不懂的。

     

    7、我们做测试几年了,都不想老是停留在执行测试,写测试用例,设计测试计划,写测试脚本,评审开发/测试文档上,写缺陷报告,写测试报告,管理和维护测试工具。但是上面的几点工作后,我们软件测试人员还能做些什么?

     

    怎么样提高软件测试员自身素质培养?

     

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

     

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

     

    (3) 打破砂锅问到底的精神,对于只出现过一次的bug,一定找出原因,不解决誓不罢休。

     

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

     

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

     

    (6) 灵活一些,聪明一点,多制造一些容易产生bug的例子。

     

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

     

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

     

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

     

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

     

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

     

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

     

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

     

    (14) 到此是不是对测试很有兴趣呢?不过我要告诉你,测试过程中有酸甜苦辣,其中的滋味只有你知道,也许你会感到枯燥,要学会放松自己,去溜冰或做你喜欢做的事,不过,别放弃,因为你的自信告诉过你“你会是很优秀的测试员”不是吗?

     

    我们常见软件测试的技巧 :

     

    软件测试虽然辛苦,但是掌握了一定的技巧之后将使你事半功倍。

     

    (1) 边界测试,测试用户输入框中的数值的最大数和最小数,以及为空时的情况。

     

    (2) 非法测试,例如在输入数字的地方输入字母。

     

    (3) 跟踪测试,跟踪一条数据的流程,保证数据的正确性。

     

    (4) 在开始测试时应保证数据的正确性,然后在从系统中找出各种BUG。

     

    (5) 接口测试,程序往往在接口的地方很容易发生错误,要在此模块测试勿掉以轻心。

     

    (6) 代码重用测试,在开发过程中有些模块功能几乎相同,程序员在重用代码时可能忘记在原有代码上修改或修改不全面,而造成的错误。

     

    (7) 突发事件测试,服务器上可能发生意外情况的测试。

     

    (8) 外界环境测试,有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。

     

    (9) 在程序员刚修复Bug之后的地方,再找一找,往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。

     

    (10) 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。

     

    (11) 文字测试,如果在系统中有用词不当的地方,我想这是不应该的。

     

    (12) 系统兼容测试,例如有些程序在IE6能运行正常,到IE5下不能运行。有些程序在WIN2000下能运行,而到WIN98却不能运行。像一些很

    特别的用户去使用系统,你很有可能发现BUG。

     

    (13) 用户的易用性测试,往往用户的需求是不断的变化的,而其中的一部份变化的原因,是有用户操作上不方便引起的。

     

    软件测试是软件开发中的重中之重,没有一点可以马虎的,在项目管理过程,我强调的时是每个过程的每一个环节都要进行测试,保证系统在每个阶段可以控制。因为软件测试中考虑的问题基本上是项目管理中考虑的问题。

     

    我认为在项目管理中考虑的一些问题应该是在软件测试时有些体现,体现的内容是软件测试的一些侧重点,具体说,软件测试是事务性的,而项目管理是策略性,一些策略性的东西必须在一些事务性的事务上来实现。

     

    针对这个经验,看过的朋友都会产生相同或者不同的看法,不妨与大家共享一下!

    展开全文
  • 第一部分:软件评测知识 1. 软件质量与软件测试 软件测试:在规定条件...软件测试只是质量保证工作中的一个环节,软件质量保证与软件测试是软件质量工程的两个不同层面的工作; 质量保证:通过预防、检查与改进来
  • 我一个野蛮的了十年软件测试的工程师。在每次定季度任务的时候,都非常的尴尬。想写写软件测试领域的各种尴尬,让那些想从事软件测试的新人好好体会一下,自己真的是否走上这条不归路。由于最近负能力爆棚,害怕...
  • 问:软件测试的原则? 答:https://blog.csdn.net/weixin_30363263/article/details/102986878 问:你在测试中发现了一个 bug ,但是开发经理认为这不是一个 bug ,你应该怎样解决。 1、将问题提交到缺陷...
  • 可以看到在做软件测试工作的时候,最开始,就是做好计划工作,也就是软件测试计划。 在软件测试计划里面应该包含哪些内容呢? 包括这些: 1)测试开始时间&测试结束时间 2)测试的内...
  • 可以看到在做软件测试工作的时候,最开始,就是做好计划工作,也就是软件测试计划。 在软件测试计划里面应该包含哪些内容呢? 包括这些: 1)测试开始时间&测试结束时间 2)测试的内容模块定位(包含...
  • 最近小编常常收到一些小伙伴在后台询问关于软件测试的一些问题,比如: 我是女生,我适合做软件测试吗? 我30岁了,能学会软件测试吗? 我大专毕业,能做软件测试吗? ……     就在今天,小编又在知乎上...
  • 1、软件测试的流程 2、web测试和APP测试的区别 仅仅从功能测试的层面上来讲的话,在流程和功能测试上是没有区别的。那么区别在哪里呢? 由于载体不一样,所以系统测试和一些细节可能会不一样。 那么我们就要先...
  • 软件测试面试题100道整理 1.什么是软件测试? 答:软件测试是为了发现错误而执行程序的过程。 2.软件测试的目的? 答;测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正错误和缺陷...
  • 阿泽在某乎上看到一个问题,《33岁学软件测试来得及吗?》 问题:之前一直在工厂上班,看不到希望。已经33岁了,想转学软件测试来得及吗? 同样类型的问题,还有“我是大专学历,学软件测试能找到工作不?”“我是...
  • 软件测试是软件生存周期中必不可少的环节,软件的典型生存周期可以用下图来形容: 软件测试的目的是尽可能早的发现软件缺陷并确保其得以修复,因此软件测试是提高软件质量的重要手段,大量的经验实践证明,软件...
  • 软件测试 验证软件功能是否满足用户的需求 测试和调试的区别 目的不同 测试的任务是发现程序中的缺陷,调试的任务是定位并且解决程序中的问题; 参与角色不同 测试主要由测试人员和开发人员来执行(黑盒...
  • 第一部分:软件评测知识 1. 软件质量与软件测试 软件测试:在规定条件下对程序进行操作,...软件测试只是质量保证工作中的一个环节,软件质量保证与软件测试是软件质量工程的两个不同层面的工作; 质量保证
  • 面试问题参考第一问,95%都会问到请...2,专业不对口也不要过多的去提及(提到了就会增加问你的概率)比如你的专业是机械专业例子:面试官您好,我叫***,来自于哪里,一直从事软件测试工作有几年了比如你的专业是计...
  • 软件测试的十二个误区大体总结如下:  1)测试人员不需要了解软件开发的知识:  这个是很多初级测试人员或者部分对测试不理解的开发人员的理解,我们谈到软件测试人员未来的发展方向大致有:自动化测试,性能测试...
  • 软件测试现状与前景

    2019-05-20 16:50:16
    软件测试(英语:Software Testing),描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说,软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是:在规定的条件下...
1 2 3 4 5 ... 20
收藏数 305,239
精华内容 122,095
关键字:

到底要不要做软件测试