大家好,我是晓星航。今天为大家带来的是 与软件测试 有关的问题的讲解!
最常见的理解是:软件测试就是找BUG,发现缺陷。
现实生活中在很多情况下我们都在默默进行测试: 刚新买来一部手机,我们要干什么? 一场考试, 做完一遍题目之后, 进行一遍检查, 就是在 “测试” 买一台电视, 安装好之后打开试试看能不能正常使用, 也是在 “测试”
软件测试就是验证软件产品特性是否满足用户的需求。
早期,人们更多的将测试看成是对软件产品“检验”,检查软件的每个功能是否运行正常。
1983年,Bill Hetzel将软件测试定义为:软件测试就是一系列活动,这些活动是为了评估一个程序或者 软件系统的特性或能力,并确定是否达到了其预期的效果。
从这话我们可以看出以下两点:
软件测试的特点:
软件测试只是一个样本试验,具有不可穷尽性。
难易程度 开发广度小,专业度高。测试广度大,专业度低
工作环境 基本类似
薪水 中小企业总体比研发低,自动化等专业测试领域和研发基本无差距。大厂研发测试基本无差别
发展前景 自动化测试、安全测试等领域发展前景和研发基本一致。
繁忙程度 敏捷模式下差距不大,产品发布前压力比较大
技能要求 测试要求更广泛:业务能力,设计和架构分析能力,测试手段和工具使用,用户模型分 析和理解,编程能力
软件测试与调试的区别:
目的不同
-调试(Debug):确保程序做了程序员想它做的事情
-测试(Testing):确保程序解决了它该解决的问题
参与角色不同
-测试由测试人员和开发人员来执行,黑盒测试主要由测试人员完成、单元/集成测试主要是由开发 人员执行。
-调试由开发人员完成。
执行的阶段不同
–测试贯穿整个软件开发生命周期
-调试一般在开发阶段。
- 软件调试为主,发生在20世界50年代。
- 1957年Charles Baker对调试和测试进行了区分。
这是软件测试史上一个重要的里程碑,标志已经有独立的软件测试了。
- 1979年,《软件测试的艺术》中给出了软件测试的定义:测试是为发现错误而执行程序的过 程。
它意味着软件测试不仅要证明软件做了该做的事情,也要保证它没做不该做的事情。
- 1983年,美国国家标准局(National Bureau of Standards)发布了VV&T,VV&T提出了测试 界很有名的两个名词:验证(Verification)和确认(Validation)。
这些意味着软件测试正作为一门独立的,专业的,具有影响力的工程学发展起来了。
- 预防为主是当下软件测试的主流思想之一
软件测试已经贯穿到了整个软件开发的生命周期当中了。
软件测试工程师:工程师的主要工作一般包含需求分析、编写测试计划和测试方案、设计测试用例、执 行测试用例、跟踪BUG、编写测试报告等;
测试开发工程师:根据项目的特点来开发一些自动化测试的脚本,或自动化测试的工具,或者是软件测 试工作中用到的提高工作效率的小工具什么的,从而能够更有效地进行测试,提高软件产品的质量。
测试开发工程师工作的目的就是为了更高效,更快捷地让测试工程师进行测试工作;测试开发岗位一般 要求一定的开发能力,解决问题的能力尤为重要。
性能测试工程师:针对系统进行性能测试,包括使用工具和编写性能自动化测试脚本。
安全测试工程师:主要分析产品可能会出现的安全问题,做各个方面的渗透测试,提高产品的安全性
其它:系统测试工程师,嵌入式测试工程师,硬件测试工程师。
最简单的软件测试组织形式就是没有任何组织的测试,几个人就把所有软件测试工作做完,这样做没有 任何分工、没有任何层次结构。 简单的软件测试组织带来的问题是:软件测试依附在软件开发的组织下,不能真正发挥软件测试的 威力。 一两个人的软件测试缺乏交流和思维的碰撞,导致测试人员的进步非常有限。缺乏测试的组织,导 致测试无计划进行,测试人员疲于应付各项突如其来的测试任务,测试经验也得不到很好的总结。
按照测试人员的职责明确程度,可以划分成兼职测试和专职测试两大类。目前在很多软件企业,尤 其是小规模的软件企业,往往没有专职的测试人员。在做测试工作的同时还要兼顾软件幵发、配置管 理、技术文档编写、用户教育、系统部署实施等工作。 即使是在一些比较大规模的软件企业,拥有专门的质量部门,也会有兼职的情况,最常见的兼职工 作是测试+配置管理,或者测试+QA。这种方式的好处是节省成本,可以充分利用资源。但是这样测试人 员缺乏专门的独立的发展空间,不利于测试的纵深方向的发展,很难把测试做得精细,也不利于测试经 验的积累和测试知识的传播。 当然,由于目前软件企业的现状,很多企业还是使用这种方式。新入行的测试人员来说,可以认为 这是对自己很好的锻炼机会。 测试本身的要求就是知识面要广,而这些工作有助于从不同层面、不同角度、不同角色的位置考虑 软件的相关问题。
按测试人员参与项目的形式来划分,可分成项目型和职能型。 项目型的测试组织是指测试人员作为项目组成员之一紧密地结合到项目中,与项目组其他人员紧密 协作,一般是从头到尾跟着项目走。当然,也有些项目是到了中后期才考虑把测试人员加入到项目中。 这种类型的测试组织一般不会有测试组长,测试的管理由项目的主管或项目经理负责。当然,在一些大 的项目中,会划分出幵发组长、也会划分出测试组长,但是最终报告的对象都是项目经理。因此项目经 理是负责测试资源调配和测试计划的主要人员。 而职能型的测试组织是指测试人员参与到项目中是以独立的测试部门委派的方式进入的。 在这种结构中,一个测试人员有可能不仅仅测试一个项目的产品,可能会同时测试多个项目的产 品。测试人员也可能不是长期稳定地从头到尾参与一个项目。 测试人员不向项目主管或项目经理报告工作,而是向自己所在的部门经理报告工作。并且这种结构 的项目经理也可能是虚拟的,或者由多个部门经理共同担当。 这两种方式各有利弊。项目型的好处是测试人员参与的力度很强,能深入了解项目方方面面的信 息,有利于稳定持续有效地测试出更多细节问题;但是同时也有弊端,就是测试人员受项目负责人的管 理,在对待Bug的处理意见上往往受到约束,同时由于过于亲密,很可能出现“网开一面”,不能严格要 求的惜况。并且由于缺乏独立的组织,测试人员的知识可能局限在项目组内传播,不利于测试经验在不 同项目组之间的传播。某些测试人员在这种组织中可能会感到孤独和无助。 而职能型的好处是能避免项目型的部分问题,并且能节省部分测试资源,充分利用各个项目阶段之 间的时间差来合理利用测试资源;但是也不可避免地存在一些问题。例如,深入程度不够,尤其是对项 目涉及的领域知识和业务知识理解可能不够深入,导致测试的问题比较表面。
项目性:
尽管独立的测试部门会有一些不可避免的问题,例如参与项目的深入程度,容易导致“扔过墙”的测试。 但是很多软件企业还是倾向于建立一个相对独立的软件测试组织。一个理想的软件测试组织可以是综合 和兼容了几种结构方式的组织。 例如,可以将项目型结构和职能型结构组合并加以改造。测试部门是独立的部门,测试部门经理根据各 项目组中项目经理的请求,结合公司对项目的投入和重点方向,决定委派哪些测试人员加入到项目组, 并且长期稳定、持续地跟进项目,在项目的各个阶段都参与并做测试的相关工作内容。测试人员作为一 种服务资源供项目组调用,测试的结果和报告作为评估软件产品质量的必要参考信息,为项目经理做出 产品发布的决定提供参考价值。
测试工程师的沟通能力会直接影响事务开展的效率。良好清晰的沟通能力,是一个技术优秀的测是 工程师是否可以获得更好发展的“敲门砖”。
对不同业务需求和功能的快速学习与理解能力。 对于测试新技术和新方法的学习能力。
掌握自动化测试技术,可以把你从大量重复性的手工劳动中解放出来,这样可以把更多的精力花在更多类型的 测试上。
测试用例设计能力是指,无论对于什么类型的测试,都能够设计出高效地发现缺陷,保证产品质量的优 秀测试用例。
如何提高测试用例设计的能力?
1,掌握设计测试用例的方法
2,积累,总结
3,阅读好的测试用例设计案例
探索性思维是指,测试工程师在执行测试的过程中不断学习被测系统,结合自己的经验,知识,直觉, 进行系统的错误猜测和逻辑推理,整理和分析出更多有针对性的的测试关注点。
案例:测试一台自动售票机。 正向,逆向,边界,压力,性能,耗电量,断电,外观,没零钱…
责任感是任何工作的都需要的,对于测试工作者而言:
测试往往是产品质量的最后个把关者;由于测试工作成效很难衡量,测试用例执行、bug数目的多少都 无法说明产品的质量是否合格;所以,责任感是最重要的测试必备素质之一。
压力,测试工作者,特别是属于互联网行业需要能够抗住各种压力。
学习方法:
以实践为主,理论为辅。
学习内容:
概念–基础-用例-进阶-管理-项目实践-工具(禅道-持续集成-功能自动化-性能自动化)
者,特别是属于互联网行业需要能够抗住各种压力。
学习方法:
以实践为主,理论为辅。
学习内容:
概念–基础-用例-进阶-管理-项目实践-工具(禅道-持续集成-功能自动化-性能自动化)
感谢各位读者的阅读,本文章有任何错误都可以在评论区发表你们的意见,我会对文章进行改正的。如果本文章对你有帮助请动一动你们敏捷的小手点一点赞,你的每一次鼓励都是作者创作的动力哦!