01-测试理论

最新推荐文章于 2024-09-04 14:30:28 发布

等灯亮起来

最新推荐文章于 2024-09-04 14:30:28 发布

阅读量792

点赞数 21

文章标签：代码覆盖率 bug 团队开发 scrum 需求分析

本文链接：https://blog.csdn.net/qq_43708708/article/details/140178910

版权

什么是软件？

软件(英语:software)是一系列按照特定顺序组织的计算机数据和指令，是计算机中的非有形
部分。软件是一种抽象的，计算机中的程序代码组成的产品。

在20世纪50年代，英国计算机科学家图灵已提出了程序测试的定义，测试是验证程序正确性的一种实验形式。直到60-70年代，软件危机出现后，人们意识到测试的意义。

软件复杂度:
程序代码的复杂度，软件产品的并发性，复杂性越来越高，对程序的正确性检测也越来越高

行业竞争大:
由于用户审美提升与需求越来越高，现在一个新闻类app，就有百度新闻，网易新闻，趣头条，今日头条，各家公司都想做到完美，用户喜欢自己的产品，那就得从易用性，美观性，趣味性，快速性等等等等方面超过其他的产品，那么大公司都会配备专门的功能测试岗位，性能测试岗位，乃至于更强大的测试开发岗位。

软件测试概念

Software Testing软件测试:
在规定的条件下对程序进行操作(人工测试、自动化测试)，以发现程序错误，衡量软件质量并对其是否能满足需求进行评估。

软件测试的目的：

用特定的目的和特定的方法，提交错误信息，跟踪错误信息，发现软件问题，检查系统是否满足用户需求。

什么是软件测试？

软件测试是为了检验出程序错误而执行的一系列若干操作。
软件测试可以人力执行，也可以借助工具执行。
软件测试过程可以运行软件，也可以不运行软件，指的是动态测试与静态测试。

软件测试的发展

1957年之前一调试为主(Debugging Oriented)：

20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，测试等所有工作，当然也不会有人去区分调试和测试。然而严谨的科学家们已经在开始思考“怎么知道程序满足了需求?”这类问题了。

1979-1982一破坏为主(Destruction Oriented)

1979年，《软件测试的艺术》(The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义:

The process of executing a program with the intent of finding errors.

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

1988-至今一预防为主(Prevention Oriented)

STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型，STEP认为测试与开发是并行的，整个测试的生命周期也是由计划，分析，设计，开发，执行和维护组成，也就是说，测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。没有100%完美的软件，零缺陷是不可能的，所以我们要做的是：尽量早的介入，尽量早的发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。

软件测试的目的

通过软件测试暴露软件中隐藏的错误和问题，便于考虑是否使用该产品。

测试目的之证明

软件开发者的角度：通过软件测试证明软件中不存在错误和问题，给予自己产品质量足够的信心。
在非正常情况和条件下软件的功能性没问题。

测试目的之检测

一个成功的测试，需要不懈的挖掘软件的错误，并且不断的完善产品和满足用户的需求是产品成功的关键点。
确保交付的产品符合用户的需求。
在产品上线前尽可能的发现和修复bug，提供产品系统的质量报告。

测试目的之未雨绸缪

预防下一个版本可能出现的问题。
预防用户使用过程中可能遇见的问题。
提前检测软件开发过程中的问题和风险。
提供用于分析的测试报告。

软件测试历程转变

软件测试主要工作

执行软件测试需求分析，编写测试计划书，编写测试用例
执行测试过程，目的发现软件缺陷，进行软件缺陷管理，提交测试缺陷报告
衡量软件质量，检测易用性，兼容性，性能等

软件的生命周期

软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。

软件编码

把软件设计转化为计算机可以理解的程序，也就是以计算机编程语言来描述软件功能，用DBMS工具创建数据库数据。

软件测试

测试是检验软件是否符合用户需求，是否达到软件质量标准，由专门测试部门执行。
常见测试方法分为:

单元测试，对每一个代码函数测试
集成测试，对代码组成的模块进行测试
系统测试，针对每一个功能需求，完整的设计测试环境，指派测试人员执行

软件运维

再此阶段，软件已经交付上线提供用户使用，进入维护阶段，保证软件系统正常运转，如网站的7*24小时运行，因为软件系统可能出现如下问题:

由于用户增长造成的性能压力
服务器出现问题造成系统不可用
软件系统出现bug
系统升级出现未知bug

用户在使用过程中出现问题，反馈给技术支持人员，然后再递交给测试组，由研发组修复。

软件开发模型

由于项目、需求的模式不同，软件在生命周期过程中选择的软件开发模型也有所不同。早期开发中，软件是边做边改，项目，需求没法管控，软件愈发复杂，开发越难。随后开发模型开始演进，瀑布、原型、螺旋、敏捷等模式出现。

瀑布型生命周期

瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。(银行体系用的最多，一个需求做一年，变化很少。以及印度开发者是瀑布模型的重度使用者)

优点：

明确划分了软件生命周期的各个环节。
强调早期软件计划，需求分析重要性。
清晰的工作流程，便于分工协作。
适合需求稳定的产品开发。

缺点：

线性的开发流程，存在巨大的风险。
依赖于早期的需求调查，不适应需求的变化，单一流程不可逆。
风险在后期可能才会暴露，且无法纠正。
无法保证用户的产品需求不变，开发过程无法更改。(比如盖房子，照着图纸打好的地基可以承载7层楼，现在用户突然要加三层，那么地基就得重打，已经盖好的楼就得爆破，这是不可能的操作。)

一、问题的定义及规划

确定软件开发目的以及可行性，指定开发计划。
二、需求分析
在确定软件开发可行性正确下，对软件所需的功能进行详细分析，明确客户需求，输出原型图。
三、软件设计
概要设计：架构的实现，表述各模块功能、模块接口和数据传递等事务。

详细设计：对表述的各模块深入分析，要求达到代码级别，将程序具体的实现描述出来，以及数据库设计。
四、软件编码
按照详细的模块功能表，编程人员编写出计算机可运行代码。

快速原型模型

客户与开发公司紧密联系，开发周期较长，开发受到需求经常变更的影响。
增加客户与系统的交互：
根据用户的主要需求，建立一个软件原型，然后让用户进行评价，然后根据用户的评价和提出的更多的需求来开发出相应的软件产品。通过逐步调整原型使其满足客户的要求。(例如室内设计客户想要客厅装修成xx样，待你画好了效果图，客户一看，不行，我想要这样、我想要那样..)
细化软件需求：
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

优点:

快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
提供学习手段，通过开发原型和演示原型对开发者和使用者对整个系统了解有积极作用。
真正理解客户的需求。

缺点:

快速建立的系统结构可能产品质量低下。

螺旋模型

螺旋模式结合了瀑布模型与快速原型。将开发过程分为螺旋周期，每个螺旋周期和瀑布模型相符，沿着螺旋线旋转，坐标轴的四个象限表示四个活动。
1988年由巴里·勃姆提出的软件开发模型升级版，兼顾了瀑布型的优点。“螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要模块和功能点，先实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。
(1)制定计划:确定软件目标，选定实施方案，弄清项目开发的限制条件;
(2)风险分析:分析评估所选方案，考虑如何识别和消除风险;
(3)实施工程:实施软件开发和验证;
(4)客户评估:评价开发工作，提出修正建议，制定下一步计划。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

优点：

引入了其他模型不具备的风险分析，使得软件遇见风险时可以停止，减少损失。
要求每个迭代阶段都需要构建原型，进行软件测试以减小项目开发风险。
整个过程有较高灵活性，开发过程的任意阶段自由应对变化。

缺点:

需要测试人员有丰富的风险评估经验和专业知识才能及时标识风险，减少软件缺陷损失。
过多的评审迭代，造成开发成本压力。

敏捷开发之Scrum方法

20世纪90年代开始引起关注的新型软件开发方法：敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。Scrum就是敏捷开发的具体方式。Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
Scrum团队中三个关键角色：Scrum Master，Scrum Product 0wner和Scrum开发团队

敏捷开发思想：

技术团队与业务专家之间的紧密协作和面对面沟通
频繁交付新的软件版本，自动化测试为核心
紧凑的团队组织
更好适应需求变化的代码编写方式与团队管理。

核心分为产品负责人，敏捷主管，技术团队

产品负责人采集用户需求，放入产品列表，通过计划会议讨论要实现哪些功能，敏捷开发不强调一次性就确定软件需求，完成开发，而是通过短期内的多次迭代，完成产品开发。

了解敏捷开发：

软件是在逐步的改进增减的过程，最终达到用户满意度。
敏捷开发就是迭代+增量。
敏捷开发对于自动化测试的要求较高，开发人员注重开发，测试人员注重测试过程。
传统瀑布模型要求写好诸多的文档，敏捷开发不需要太多文档，测试人员就需要更好的掌握自动化技能。

软件测试模型

随着软件测试的发展，测试人员在大量实践中总结出一些测试模型，如V模型、W模型等。
V模型和瀑布开发模型有着一些共同的特性，V模型中的过程从左到右，描述了基本的开发过程和测试行为。
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
局限性:把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。

V模型

模型部分解析：

单元测试：
单元测试也叫做模块测试，进行正确性检查的工作。单元测试要从程序内部结构设计测试用例，每个模块可以独立进行测试。那么单元是什么？单元就比如Python中的类，图形化软件的一个窗口，一个功能菜单。

集成测试：
集成测试也叫组装测试，也就是将所有单元测试，进行有序的组合后再进行测试。

系统测试：
将整个软件系统看做一个整体进行测试，对功能，性能，硬件，软件所有环节进行测试。单元测试的目的是测试功能是否满足要求。系统测试的目的是测试系统是否满足性能的要求，以及不同的机器再不同的操作系统平台中运行，如一台机器我登陆多个qq，是否可以运行在windows，linux平台上，或者运行过程中是否正常等方面。

验收测试：
α测试：
Alpha测试模拟实际操作环境下的验收测试，如删档内测，软件只是初步完成的产品，bug可能较多，不会进行上线。但是提前提供用户访问。
β测试：
Beta测试表示系统已经通过内部测试，大部分错误已经修复，即将正式发布，在多个真实环境下发布，如不删档公测。对比α测试的版本已经有了较大改进，但仍可能存在一些bug，需要大规模测试，例如DNF公司更新一个地图，提供公测免费下载，由专业游戏玩家进行游戏结果反馈，开发者再进行修复。
y版本：
y版本指的是正式版本，与上线版本几乎无区别。

W模型

开发和测试的协调工作图，绿色开发，橙色测试。《软件验证和确认》原则中提出：在软件需求设计阶段，也得有测试活动。W模型就是开发流程一个V，测试流程一个V，组合而来的W。

W模型优点：
测试伴随整个软件开发生命周期，更早接入测试，可以更好的发现需求设计中的缺陷，修复成本也更低。
W模型缺点：
依赖于软件开发和测试的前后线性关系，还是无法解决需求变更调整的问题对于项目中不产出文档的事例，测试工作无法执行。(小型公司直接产出原型图，并不写需求说明书)对于复杂业务，新人经验不足以测试需求，测试设计。

测试覆盖率

覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的度量。例如我有一百个测试点，我目前完成了九十个，那么我功能点覆盖率就是90%。

覆盖率 = ( 至少执行一次的项目点 ) / 项目点总数
特点：

通过覆盖率数据，检验测试工作是否充足。
分析出测试的弱点，对比测试人员的测试结果。
设计能够增加覆盖率的测试用例，有效提高测试质量

测试覆盖率与黑盒：

需求覆盖：在测试中，有哪些功能被测试了，被测试的频率

需求覆盖 = ( 验证的需求数 ) / ( 总需求数 )

用例覆盖：体现每轮测试验证通过的用例数在总比例中的比重

用例覆盖 = ( 验证通过的用例数 ) / ( 总用例总数 )

软件测试常用术语

c/s：Client客户端、Server服务端，指的是互联网中一台服务器安装服务端软件，每个用户都需要安装客户端软件，例如QQ、微信、游戏。
b/s：Browser浏览器，Server服务器，不需要安装客户端，只需要有浏览器即可，例如淘宝网、京东网，便于维护与升级。
bug：指的是软件中不符合用户需求的问题，软件存在的缺陷。
Testing Environment：软件运行的平台，包括硬件、软件、网络配置。
Test Case：测试执行之前的详细测试方案，包括测试环境、测试步骤、测试数据、预期结
果。

测试用例 = 数据输入 + 测试结果输出 + 测试环境配置

Smoke Testing：在软件大规模测试之前，验证基本功能，决定是否有可测性

测试人员的原则

所有测试动作必须追溯到用户需求

80%的产品缺陷都是在产品开发过程中的需求定义出现偏差引发的，如果需求得到准确的验证可以消除80%的返工问题，节省投入成本40%。

尽早启动测试工作

Pareto法则应用于软件测试

Pareto(帕累托)法则是由意大利经济学家帕累托提出，又称为28效率法则【二八定律、帕累托定律、最省力法则、不平衡原则、犹太法则。】
人们采用二八定律，用于计量投入和产出之间可能存在的影响关系。

管理学：通常一个企业80%的利润来自于20%的项目。
心理学：

20%的人集中了人类80%的智慧，出生就是鹤立鸡群。
20%的人买时间，80%的人卖时间
20%的人做事业，80%的人做事情
20%的人正面思考，80%的人负面思考

在项目管理认证中(PMP)Pareto法则成效是:

抓住主要矛盾
科学分配时间和经历
把80%的资源花费在关键效益的20%的方面，这20%又能带动80%的发展，相辅相成，生生不息。

测试中的Pareto法则是指在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，系统测试又能找出其余缺陷的80%，最后4%的缺陷可能在用户大范围、长时间试用下才会暴露。