当前位置 博文首页 > 专注测试领域知识分享和技能提升:测试从零开始-No.3-软件测试行

    专注测试领域知识分享和技能提升:测试从零开始-No.3-软件测试行

    作者:[db:作者] 时间:2021-09-08 22:58

    软件测试的定义

    ????软件测试:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。简单地说,软件测试是一种实际输出与预期输出之间的审核或者比较过程。

    ????软件测试的工作就跟质检差不多,只是检验的产品不一样。就好比你去买一把雨伞,商家告诉你这把雨伞在天晴和下雨的时候,伞的颜色会变化,那么,在出场的时候,肯定针对这两种情况去进行过检查,同样,你买的时候,也会带着这样的疑问去检查一下雨伞是否真如描述的那样。软件测试人员检查的是“软件”的质量,在你准备好进入IT行业并且想入测试行业的时候,就应该先认真的了解一下软件测试行业的背景,了解自己的职责和即将承担的使命,要知道自己身上的担子有多重,不要随意听信别人说的那些功能测试没前途之类的,在你刚入行的时候,经验的积累显得尤为重要。

    软件测试的重要性

    图片

    ????不知道类似这样的图片,大家平常在手机上是不是经常看到类似的段子,如果你是一个开发人员,你写出这样的代码就直接上线了,就有可能给公司带来巨大的损失,如果你是测试人员,没有测出这样的漏洞,那你很可能就要为此承担一定的损失。看到这,相信大家应该知道测试的重要性了,这也是测试人员在公司的越来越被重视的原因。但是,能不能在公司得到重视和认可,得靠自己用工作能力去赢得同事的认可,遇到问题时不能一味的抱怨。不能听别人说他们公司的测试怎么怎么样,然后一对比自己,然后就各种抱怨,希望大家在遇到问题的时候,能多从自己身上找原因,多思考如何才能像其他测试人员一样优秀。

    项目组人员组成

    项目经理、产品经理、设计人员、web端开发、后端开发、移动端开发、测试人员、运维人员、UI/UE等。

    测试什么时候参与介入项目

    从需求分析阶段开始,测试人员就要开始了解需求,编写测试用例,测试越早介入越好。

    基本软件研发模型

    • 瀑布模型

    严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。

    主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布模式不太适合中途可能变更需求的项目。

    • 迭代模型

    在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:需求分析、设计、实施和测试工作流程。实质上,它类似小型的瀑布式项目。所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。

    迭代开发的优点:

    1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。

    2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。

    3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。

    4)由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

    使用迭代模型的话,可以针对项目的一些关键节点划分里程碑,用来衡量整个项目的进度是否延期之类的。

    • 增量模型

    ????增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。

    ????在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。

    注:迭代模型和增量模型的区别:

    迭代模型适用于需求不甚明确、难度比较大的软件开发。

    增量模型适用于需求比较明确,架构比较稳定的软件开发,每次增量不影响已有的架构,在已有的架构下增加新的功能

    • 敏捷开发模型

    ????敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。通俗点讲就是:将需求拆分很细,每个小功能点做完之后开始单独测试。敏捷开发模式的话,相关概念主要有4个核心价值和12条基本原则:

    4个核心价值:

    • 个体和互动高于流程和工具

    • 工作的软件高于详尽的文档

    • 客户合作高于合同谈判

    • 响应变化高于遵循计划

    (也就是说,尽管右项有其价值,我们更重视左项的价值。)

    12条基本原则:

    • 通过尽早的、不断地提交有价值的软件来使客户满意。

    • 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

    • 以从几个星期到几个月为周期,尽快、不断地提交可运行的软件。

    • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

    • 以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并对他们的工作予以充分的信任。

    • 在团队内部,最有效、效率最高的传递信息的方法,就是面对面的交流。

    • 测量项目进展的首要依据是可运行软件。

    • 敏捷过程提倡可持续的开发,责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。

    • 时刻关注技术上的精益求精和好的设计,以增强敏捷能力。

    • 简单是最根本的。

    • 最好的构架、需求和设计都源自自我组织的团队。

    • 每隔一定时间,团队要反省如何才能更有效地工作,然后相应地调整自己的行为。

    cs