自学软件测试
你和我类似,一样学数学的一样转的测试。
优势我就不说了。
毕竟软件测试初期是个体力活没难度。
我是培训出来的,不过学完后感觉自己学也是可以的。
学习是个循序渐近的过程,当你接触越多的时候你会发现你需要学习的越多。
我把我的经验介绍下希望能对你有所帮助。
主要看个人态度:一定要有毅力和恒心。
其次:初学可以到网上找相应的资料来学习。
(1、2学完后可以作为一个初级的测试员,建议都了解了在去工作。
)需要学习的知识有:1、计算机基础知识(不必深)(IP DNS 什么的懂点就OK)2、软件测试的基础理论软件测试意义、方法(黑盒:等价类、边界值等、白盒:域测试、逻辑覆盖)、模式(V模型W模型)、类别(功能测试、性能测试等)、软件测试常见故障模型3、学习常用的工具使用:缺陷管理工具比如:qc ,功能测试工具:QTP,性能测试工具LR4、操作系统的学习(LINUX常用命令的学习)5、数据库基础知识(增删改查 语句)
什么是瀑布模型?
软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。
软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。
最早出现的软件开发模型是1970年W·Royce提出的瀑布模型。
该模型给出了固定的顺序,将生存期活动从上一个阶段向下一个阶段逐级过渡,如同流水下泻,最终得到所开发的软件产品,投入使用。
但计算拓广到统计分析、商业事务等领域时,大多数程序采用高级语言(如FORTRAN、COBOL等)编写。
瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。
典型的开发模型有:①瀑布模型(waterfall model);②渐增模型/演化/迭代(inCRemental model);③原型模型(prototype model);④螺旋模型(SPIral model);⑤喷泉模型(fountAIn model);⑥智能模型(intelligent model) ; 7. 混合模型(hybrid model)1. 边做边改模型(Build-and-Fix Model) 遗憾的是,许多产品都是使用"边做边改"模型来开发的。
在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改.在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。
在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。
这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于: (1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改; (2) 忽略需求环节,给软件开发带来很大的风险; (3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。
2. 瀑布模型(Waterfall Model)1970年WinSTon Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。
当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。
瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。
但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于: (1) 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量; (2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险; (3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
我们应该认识到,"线性"是人们最容易掌握并能熟练应用的思想方法。
当人们碰到一个复杂的"非线性"问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。
一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。
线性是一种简洁,简洁就是美。
当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。
例如增量模型实质就是分段的线性模型,螺旋模型则是接连的弯曲了的线性模型,在其它模型中也能够找到线性模型的影子。
3. 快速原型模型(RAPId Prototype Model) 快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。
通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。
显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。
快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。
因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。
4. 增量模型(Incremental Model) 与建造大厦相同,软件也是一步一步建造起来的。
在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。
但是,增量模型也存在以下缺陷: (1) 由于各个构件是逐渐并入已有的软件体系结构...
测试工程师需要学习什么
1、 基础:前文所说的基础技能必需掌握,推荐Java+Oracle+Uml组合。
掌握程度一般不用太深,测试工具开发职位的除外。
特别注明,Junit是一定要掌握的。
市面上书籍很多,笔者推荐《Java编程思想》、 《Oracle 9i 参考手册》、《UML精粹》。
2、 专业:前文所说的测试方法、测试工具必需掌握。
其中对于测试工具,如果开源则尽可能阅读源码。
推荐书籍《计算机软件测试技术》、《软件测试艺术》、《软件测试》。
3、 实战:前文所说的测试模式必需掌握。
至少全程参与二十次项目,至少参与两次50人以上规模的项目,至少编写测试用例10000个,至少发现缺陷5000个,至少编写测试脚本20000行,至少担任过三次测试负责人,所有产品发布后遗漏缺陷总数小于50个并呈收敛趋势。
推荐书籍《设计模式》、《人月神话》、《软件测试经验与教训》。
4、 沉淀:深入了解质量控制原理,对功能性(含安全)、效率、易用性、可移植性、可维护性、可靠性等质量特性均有实际测试经验。
推荐书籍《质量无泪》、《质量免费》、《ISO9126》等所有软件质量相关国标。
5、 领域:选取一至两门测试技术作为长期研究的方向,中途可适当调整,这里说的长期指的是五年、十年及以上,在这个层次重点是要做到专精。
推荐方向“云测试”、 “基于模型测试”。
6、 专家:理论计算机科学研究。
笔者不是专家,因此不敢臆测到达此层次后应该做些什么以及怎么做,但“P/NP问题”是笔者一直有兴趣并持续关注的,也是很多科研工作者选取的研究课题,在此郑重推荐。
考软件测评师要怎么准备呢
1.考试要求 (1)熟悉计算机基础知识; (2)熟悉操作系统、数据库、中间件、程序设计语言基础知识; (3)熟悉计算机网络基础知识; (4)熟悉软件工程知识,理解软件开发方法及过程; (5)熟悉软件质量及软件质量管理基础知识; (6)熟悉软件测试标准; (7)掌握软件测试技术及方法; (8)掌握软件测试项目管理知识; (9)掌握C语言及C++或Java语言程序设计技术; (10)了解信息化及信息安全基础知识; (11)熟悉知识产权相关法律、法规; (12)正确阅读并理解相关领域的英文资料。
2.通过本考试的合格人员能在掌握软件工程与软件测试知识基础上,运用软件测试管理办法、软件测试策略、软件测试技术,独立承担软件测试项目;具有工程师的实际工作能力和业务水平。
3.本考试设置的科目包括: (1)软件工程与软件测试基础知识,考试时间为150分钟,笔试,选择题; (2)软件测试应用技术,考试时间为150分钟,笔试,问答题。
二、考试范围 考试科目1:软件工程与软件测试基础知识 1.计算机系统基础知识 1.1 计算机系统构成及硬件基础知识 ??计算机系统的构成 ??处理机 ??基本输入输出设备 ??存储系统 1.2 操作系统基础知识 ??操作系统的中断控制、进程管理、线程管理 ??处理机管理、存储管理、设备管理、文件管理、作业管理 ??网络操作系统和嵌入式操作系统基础知识 ??操作系统的配置 1.3 数据库基础知识 ??数据库基本原理 ??数据库管理系统的功能和特征 ??数据库语言与编程 1.4 中间件基础知识 1.5 计算机网络基础知识 ??网络分类、体系结构与网络协议 ??常用网络设备 ??Internet基础知识及其应用 ??网络管理 1.6 程序设计语言知识 ??汇编、编译、解释系统的基础知识 ??程序设计语言的基本成分(数据、运算、控制和传输、过程(函数)调用) ??面向对象程序设计 ??各类程序设计语言的主要特点和适用情况 ??C语言以及C++(或Java)语言程序设计基础知识 2.标准化基础知识 ??标准化的概念(标准化的意义、标准化的发展、标准化机构) ??标准的层次(国际标准、国家标准、行业标准、企业标准) ??标准的类别及生命周期 3.信息安全知识 ??信息安全基本概念 ??计算机病毒及防范 ??网络入侵手段及防范 ??加密与解密机制 4.信息化基础知识 ??信息化相关概念 ??与知识产权相关的法律、法规 ??信息网络系统、信息应用系统、信息资源系统基础知识5.软件工程知识 5.1 软件工程基础 ??软件工程概念 ??需求分析 ??软件系统设计 ??软件组件设计 ??软件编码 ??软件测试 ??软件维护 5.2 软件开发方法及过程 ??结构化开发方法 ??面向对象开发方法 ??瀑布模型 ??快速原型模型 ??螺旋模型 5.3 软件质量管理 ??软件质量及软件质量管理概念 ??软件质量管理体系 ??软件质量管理的目标、内容、方法和技术 5.4 软件过程管理 ??软件过程管理概念 ??软件过程改进 ??软件能力成熟度模型 5.5 软件配置管理 ??软件配置管理的意义 ??软件配置管理的过程、方法和技术 5.6软件开发风险基础知识 ??风险管理 ??风险防范及应对 5.7 软件工程有关的标准 ??软件工程术语 ??计算机软件开发规范 ??计算机软件产品开发文件编制指南 ??计算机软件需求规范说明编制指南 ??计算机软件测试文件编制规范 ??计算机软件配置管理计划规范 ??计算机软件质量保证计划规范 ??数据流图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定 6.软件评测师职业素质要求 ??软件评测师职业特点与岗位职责 ??软件评测师行为准则与职业道德要求 ??软件评测师的能力要求 7.软件评测知识 7.1 软件测试基本概念 ??软件质量与软件测试 ??软件测试定义 ??软件测试目的 ??软件测试原则 ??软件测试对象 7.2 软件测试过程模型 ??V模型 ??W模型 ??H模型 ??测试模型的使用 7.3 软件测试类型 ??单元测试、集成测试、系统测试 ??确认测试、验收测试 ??开发方测试、用户测试、第三方测试??动态测试、静态测试 ??白盒测试、黑盒测试、灰盒测试 7.4 软件问题分类 ??软件错误 ??软件缺陷 ??软件故障 ??软件失效 7.5 测试标准 软件工程 产品质量 第1部分:质量模型 7.5.2 GB/T 18905.1 – 2002 软件工程 产品评价 第1部分:概述 7.5.3 GB/T 18905.5 – 2002 软件工程 产品评价 第5部分:评价者用的过程 8.软件评测现状与发展 ??国内外现状 ??软件评测发展趋势 9.专业英语 ??正确阅读并理解相关领域的英文资料 考试科目2:软件测试应用技术 1. 软件生命周期测试策略 1.1 设计阶段的评审 ??需求评审 ??设计评审 ??测试计划与设计 1.2 开发与运行阶段的测试 ??单元测试 ??集成测试 ??系统(确认)测试 ??验收测试 2. 测试用例设计方法 2.1 白盒测试设计 ??白盒测试基本技术 ??白盒测试方法 2.2 黑盒测试用例设计 ??测试用例设计方法 ??测试用例的编写2.3 面向对象测试用例设计 2.4 测试方法选择的策略 ??黑盒测试方法选择策略 ??白盒测试方法选择策略 ??...
软件测试的目的是什么?
软件测试是程序的一种执行过程,目的是尽可能发现并改正被测试软件中的错误,提高软件的可靠性。
它是软件生命周期中一项非常重要且非常复杂的工作,对软件可靠性保证具有极其重要的意义。
在目前形式化方法和程序正确性证明技术还无望成为实用性方法的情况下,软件测试在将来相当一段时间内仍然是软件可靠性保证的有效方法。
软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成软件开发项目。
不足的测试势必使软件带着一些未揭露的隐藏错误投入运行,这将意味着更大的危险让用户承担。
过度测试则会浪费许多宝贵的资源。
到测试后期,即使找到了错误,然而付出了过高的代价。
E.W.Dijkstra的一句名言说明了这一道理:“程序测试只能表明错误的存在,而不能表明错误不存在。
”可见,测试是为了使软件中蕴涵的缺陷低于某一特定值,使产出、投入比达到最大。
瀑布模型 软件 过程
1 引言软件生命周期是软件由产生直到报废的生命周期,周期内可有可行性分析、需求分析、概要设计、详细设计、编码、测试和维护等阶段。
软件生命周期解释如何演绎软件过程的思想,是软件生命周期模型化技术的基础,也是建立软件开发环境的核心。
生命周期模型会为软件开发提供支持,为软件开发过程中所有活动提供政策保证,为参与软件开发的所有成员提供帮助和指导。
软件生命周期模型的适用与否,对于软件开发的成功、用户的满意影响巨大。
瀑布模型是软件工程中应用的非常广泛的一种软件生命周期模型,传统的软件工程方法学的软件过程基本上都可以用该模型进行描述。
2 瀑布模型瀑布模型是W.Royce 于1970 年首先提出的,由可行性研究、需求分析、系统设计、编码、测试、运行和维护各阶段组成。
该模型把软件生命过程比喻成瀑布的流水,每个阶段看作瀑布中的一个台阶,软件生命过程在台阶上由上向下流动。
瀑布模型规定上一阶段的变换结果是下一阶段变换的输入,相邻两个阶段具有因果关系,紧密相联。
为保障软件开发的正确性,每一阶段任务完成后,都必须对它的阶段性产品进行评审,确认之后再转入下一阶段的工作。
评审过程发现错误和疏漏后,应该反馈到前面的有关阶段修正错误、弥补疏漏,然后再重复前面的工作,直至某一阶段通过评审后再进入下一阶段。
瀑布模型的特点非常鲜明。
首先,它以文档形式驱动的,为管理者进行项目开发管理提供基础,对开发过程中的活动进行约束。
其次,它是一种整体开发模型,在开发过程中,用户看不见系统是什么样,只有开发完成向用户提交整个系统时,用户才能看到一个完整的系统。
最后,该模型过程逆转性很差或者说不可逆转,因为根据前面阶段的错误会在后面的阶段进行发散性传播的原理,所以逆转将会延误工期,增加成本,造成重大损失。
瀑布模型的优点如下:通过设置里程碑,能够明确每阶段的任务与目标;可为每阶段制定开发计划,进行成本预算,组织开发力量;通过阶段评审,将开发过程纳入正确轨道;严格的计划性保证软件产品的按时交付。
任何事物都不是完美的,瀑布模型也一样,该模型的缺点包括:缺乏灵活性,不能适应用户需求的改变;开始阶段的小错误被逐级放大,可能导致软件产品报废;返回上一级的开发需要十分高昂的代价;随着软件规模和复杂性的增加,软件产品成功的机率大幅下降。
3 V模型V模型是瀑布模型的变形,着重于测试活动如何与分析和设计相联系。
V 模型认为:单元测试和集成测试用于验证程序设计,即在单元测试和集成测中,编码人员和测试人员应确保程序设计的所有方面都已经在代码中正确实现;系统测试应验证系统设计,保证系统设计的所有方面都已正确实现;验收测试由用户来进行,把测试步骤与需求规格说明中的每一个要素联系起来对需求进行确认。
该模型中V 形左右两边连线说明各阶段的对应关系。
如果在验证和确认期间发现问题,应重新执行左边的步骤进行修正和改进相应的需求、设计和编码,然后去再次执行右边的测试,这样做使得迭代和重做的过程由隐藏变明确。
与瀑布模型关注对象是文档和制品相比,V 模型更加关注活动和正确性。
4 结束语不是任何软件都可采用瀑布模型的,瀑布模型适合于结构化方法,也就是面向过程的软件开发方法。
软件项目或产品选择瀑布模型必须满足下列条件:在开发时间内需求没有或很少变化;分析设计人员对应用领域很熟悉;低风险项目(对目标、环境很熟悉);用户使用环境很稳定;用户除提出需求以外,很少参与开发工作。
尽管上述条件比较苛刻,但是软件企业在开发新产品或新项目时往往还是采用瀑布模型,系统软件和工具软件也常常采用瀑布模型。