day02(测试分类占比、原则;软件开发模式、生命周期模型)

1.测试分类占比

image.png

2.软件测试的原则

1.应当把“尽早和不断地测试”作为开发者的座右铭。

2.设计测试用例时,应该考虑到合法的输入和不合法的输入,以及各种边界条件,特殊情况下要制造极端状态和意外状态,比如网络异常中断、电源断电等情况。

3.一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系。

4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误,一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。

5.制定严格的测试计划,并把测试时间安排得尽量宽松,不要希望在极短的时间内完成一个高水平的测试。

6.回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多错误出现的现象并不少见。

7.妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。

3.软件的开发模式

3.1.线性模型与渐进式模型

  • 线性模型:最常见的“瀑布模型”,基础框架,但缺点在于“集成之日就是爆炸之日”。(立项分析-需求分析-设计-编码-测试-维护)很多企业使用后使用迭代进行修改。
  • 渐进式模型:最常见的“螺旋模型”,(需求分析-风险分析-设计、编码-测试、评审),迭代开发和增量开发模式。
  • 注意:每一次迭代原型出来后,测试人员都需要从原型界面,系统主要功能,性能等方面对原型进行评审。

3.2.迭代和增量的理解

image.png
image.png

4.软件生命周期模型

  • 软件生命周期 同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段,一般称为软件生命周期(软件生存周期) 。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
image.png

4.1.边做边改模型

  • 许多产品都是使用“边做边改”模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。
image.png
  • 在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。

这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:
(1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;
(2) 忽略需求环节,给软件开发带来很大的风险;
(3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

4.2.瀑布模型

瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动。同时评审该项活动的实施,若确认,则继续下一项活动;否则返回前面,甚至更前面的活动。对于经常变化的项目而言,瀑布模型毫无价值。

image.png

瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件,前面一个步骤不完成,后面的步骤不能开始,否则问题会滚到下个阶段,带来更多的问题

优点:
1.为项目提供了按阶段划分的检查点
2.当前一阶段完成后,只需要去关注后续阶段。

缺点:
1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4)瀑布模型的突出缺点是不适应用户需求的变化。

4.3.原型化模型

原型化模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,经过和用户针对原型的讨论和交流,弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后,再在原型基础上开发出用户满意的产品。
如图所示:原型严格来说不算一种软件生命周期模型,它只是一种获取需求的方法,在实际工作中该方法是相当重要的方法。

image.png
  • 模型要点:瀑布和原型模型相结合,强调版本升级。

该模式的特点是一次性地获取全部的需求,然后做出分版本实现各需求的计划,每个版本只实现一部分需求,通过多个版本逐步实现全部需求,而每个版本可以认为是一个“小瀑布”。
该模型的好处是可以尽快让系统上线,让客户先使用部分功能,尽早实现系统的价值。

该模型比较能符合实际的情况,我们往往也是通过多个版本来逐步实现全部需求,但需求是不可能在一开始就完全确定的,实际情况是往往只能确定80%,而后期通过各版本我们还会获取更多的新需求以及需求调整。将此模型稍微调整后,可以适用于大部分的实际项目。

4.4.增量模型

增量模型也是原型化开发方法。如图所示

image.png

4.5.螺旋模型

螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中,软件开发是一系列的增量发布。螺旋模型的整个开发过程如图所示。

image.png

图中的螺旋线代表随着时间推进的工作进展;开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段:制定计划、风险分析、实施工程和客户评估。螺旋模型要点:统一了瀑布模型与原型模型,与增量模型相似,更强调风险分析

1.软件分多个版本开发,每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行:
1)确定软件目标,选取定实施方案,弄清项目开发的限制条件;(图中左上象限)
2)分析所选取方案,考虑如何识别和消除风险;(图中右上象限)
3)实施软件开发;(图中右下象限)
4)评价开发工作,提出修正建议,调整计划。(图中右下象限、左下象限)

3.需求不是一次获取和实现的,通过多个螺旋来完善。
4.计划也不是一次成型的,每次螺旋都需要调整。

优点:
1)设计上很灵活,可以在项目的各个阶段进行变更;
2)以小的分段来构建大型系统,使成本计算变得简单容易;(国企项目)
3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性;
4)随着项目推进,客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互;
5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点:
螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的。
因此,这种模型往往适应于内部的大规模软件开发。该模型建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。

4.6.V模型

V 模型的左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。

V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

image.png

1、需求分析阶段对应生成需求规格说明书,对应测试生成系统测试方案,即为系统测试准备的,该阶段已经完成了单元测试和集成测试,主要是对软件产品的功能与非功能进行测试,几乎不测试代码,所以测试方法以黑盒为主;

2、概要设计阶段对应生成概要设计说明书,对应测试生成集成测试方案,该阶段已完成单元测试,是将各个功能模块组装起来进行的测试,所以也叫组装测试。主要看模块调用是否正常,接口是否可用,数据传输是否正确等,所以用到的测试方法几乎是白盒的方法,如路径覆盖,条件组合覆盖等;

3、详细设计阶段对应生成详细设计说明书,对应测试生成单元测试方案,该阶段是开发人员编码后的第一个测试阶段,是对开发出来的单独模块进行测试,以确保每一个功能模块的功能正常,可以构建桩模块和驱动模块来回调用,方法也是以白盒为主。

4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构,黑盒则是尽可能覆盖所有的输入输出接口,包括文档等一些静态的测试。除常用的测试方法外,仍需补充大范围的随机测试,尽可能达到覆盖率100%。

V模型的缺陷及解决思路
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的满足情况一直到后期的验收测试才被验证。
解决的思路是,当一个软件开发的时候,研发人员和测试人员需要同时工作,测试在软件做需求分析的同时就会有测试用例的跟踪,这样,可以尽快找出程序错误和需求偏离,从而更高效的提高程序质量,最大可能的减少成本,同时满足用户的实际软件需求。

4.7.W模型

相对于V模型,W模型更科学。W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。

image.png

5.敏捷开发和测试

image.png

敏捷开发

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

由于版本节奏比较快,开发与测试几乎并行,一个版本周期内会有两版在推动,也就是上图中提到的波次发布,波次发布用于尝试新加入的功能,做小范围快速的开发,验证和发布,为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应,敏捷测试模式适应项目需求。

  • 模型优势:
    工作任务划分清晰,工作效率较高
    与开发和产品沟通紧密,团队协作性强
    测试介入到整个项目的所有会议中,对整体版本信息情况把控全面
    迅速占有市场,添加新的功能,吸引更多用户使用,提升用户体验度
  • 模型的缺陷:
    模块提交较快,测试时较有压迫感
    项目规划要合理,不然测试时会出现复测的现象,加大工作量

6.软件质量模型

image.png

6.1.软件的功能性

1..适用性:
所提供的功能是用户所需要的,
用户所需要的功能软件系统是否已提供。
2.准确性:
软件系统提供给用户的功能是否满足用户对该功能的精确度要求。
3.互操作性:
软件系统和一个或多个周边系统进行信息交互的能力。

image.png

不同型号的打印机与word之间的协议可能不一致,导致消息传递过程中发生错误。

▲应该将被测软件系统和周边系统的各种主流型号进行互操作性测试。

4.保密安全性:
软件系统保护信息和数据的能力。
Ⅰ、防止未得到授权的人或系统访问相关的信息或数据
Ⅱ、保证得到授权的人或系统能正常访问相关的信息或数据。
不同的系统对于安全性的需求差别很大

常见的安全性测试:
⑴用户验证:登录密码验证、IP地址访问限制等 sql注入
用户超时:登录超过30分钟,重新登录(安全设置,cookie过期时间30分钟)
⑵用户权限管理:验证低级别用户是否具有了高级别用户的权限,各级别用户权限都得到了实现。
⑶系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。

5.加密、解密:
在计算机通讯中,采用密码技术将信息隐蔽起来,再将隐蔽后的信息传输出去,使信息在传输过程中即使被窃取或截获,窃取者也不能了解信息的内容,从而保证信息传输的安全

token


image.png

Cookie 与session的区别:
1.cookie是明文传输 session的是隐藏专属
2.Cookie是存在与本机 session是存在与服务器
3.Cookie的大小是限制在4K session大小限制在5M

6.2.软件可靠性

1.成熟性
软件系统防止内部错误扩散而导致失效的能力。

  • 子系统、模块、单元模块的设计人员应该仔细分析和自身有接口关系的子系统、模块、单元模块,识别出这些接口上可能会传递过来的错误,然后在自己子系统、模块、单元模块内部对这些可能的错误预先进行防范,规避这些错误传递到自身而引起自身的失效。

.2.容错性
软件系统防止外部接口错误扩散而导致系统失效的能力。

  • 设计人员应该充分分析外部接口可能产生的错误,然后在设计上对这些错误一一予以防范,防止这些外部传入的错误波及自身而失效。

3.易恢复性
系统失效后重新恢复原有功能、性能的能力

  • ①原有能力恢复的程度
    ②原有能力恢复的速度
image.png

4.可靠性依从性
遵循相关的标准(国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

6.3.软件易用性

1..易理解性

用户在使用软件系统的过程中,系统交互给用户的信息是否准确、清晰、易懂,能帮助用户准确理解系统当前真实的状态,指导其进一步的操作。

image.png

2.易学性
软件系统提供相关的辅助手段,帮助用户学习使用它
的能力。
例如:是否有用户手册,用户手册是否有中文版,是否有在
线帮助,界面上控件是否有回显功能等。

3.易操作性
例如:
①Nokia手机和Moto手机在编辑短消息时的方便性差异。
②GUI界面,菜单层次不要太深
③安装软件的过程
错误:给用户大量的安装步骤,每步又有大量分支选项
(把用户当成本软件的专家)

测试时应该以非专业的角度来测试过程,往往需要α、β测试。

4.吸引性
美观:GUI界面、手机外观等
新颖:如夏新手机来电跳舞功能

5、易用性的依从性
遵循相关的标准(国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

问:性能测试的标准:
吞吐量
响应时间
资源使用率 内存使用率 cpu的使用率 电量的损耗 流量使用
成功率

6.4.软件效率(性能测试)

1.时间效率(2-5-10) 358
系统在各业务场景下完成用户指定的业务请求所需的响应时间。

2..资源效率
系统在各业务场景下完成用户指定的业务请求所消耗的系统资源,如CPU占有率 75%内存占有率80%、通信带宽占有率、软件内部消息包资源占有率等。

3..效率依从性
遵循相关的标准(国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

6.5.软件可维护性

1.易分析性
软件系统提供辅助手段帮助开发人员分析识别缺陷、失效产生的原因,找出待修复部分的能力。(降低缺陷定位的成本)
2.易改变性
对软件缺陷的修复容易被实施(降低修复缺陷成本)

  • 设计上封装性好、高内聚(同层次设计时,一个实体只完成一个功能)、低耦合,为未来可能的变化留有扩充余地。

3..稳定性
例如:代码中的有物理含义的数字,一定用宏代替。

4.易测试性
(降低发现缺陷的成本)
①软件可控制:
软件系统提供辅助手段帮助测试工程师控制该系统的运行,实现其测试执行步骤的能力(通过打点、改变内部状态、值等手段)
②可观察:
软件系统提供辅助手段帮助测试工程师获得充分的系统运行信息,以正确判断系统运行状态和测试执行结果的力。
a、设计单独的测试模式
b、提供单独的测试版本
▲测试部(一般指测试系统工程师)应该在需求分析阶段就提出可测试性需求,可测试性需求和软件产品其他需求一起纳入需求包被分析设计并实现。

5.维护性的依从性
遵循相关的标准(国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

6.6.软件可移植性

1.适应性
软件系统无需做任何相应变动就能适应不同运行环境(操作系统平台、数据库平台、硬件平台等)的能力。

  • 解决平台无关、可移植性问题的一个常用思路是构造出一个虚拟层,虚拟层将下层细节屏蔽,对上层提供统一口。

2.易安装性
主流平台 全部测试用例
非主流平台 10%测试用例

3.共存性
软件系统和在公共环境与其共享资源的其他系统共存的能力。
▲测试不仅需要关注自身特性的实现,还要关注本软件是否影响了其他软件的正常功能。

6.7.易替换性

软件系统升级能力(在线升级、打补丁升级等)
可移植性的依从性
遵循相关的标准(国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

7.软件测试的常识知识

1.测试部门的组织结构

image.png
image.png

8.软件测试工具

软件测试工具是通过一些工具能够使软件的一些简单问题直观的显示,使测试人员更好的找出软件错误所在。
软件测试工具分为自动化软件测试工具和测试管理(禅道)工具。
软件测试工具存在的价值是为了提高测试效率,用软件来代替一些人工输入。
测试管理工具是为了复用测试用例,提高软件测试的价值。
一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。

Bug管理工具: 禅道 Jary
自动化 selenium appnium (ui自动化) pytest (测试用例 单元测试) innerHtml (发送测试报告)
性能测试工具 jmeter Loadrunner、
抓包工具 Fiddler charles (弱网测试的)
接口工具 postman
录制脚本 bodyboy jmeter

云测 腾讯云 模拟不同的移动端或者是web浏览器

命令 Linux adb monkey
数据库 myql
语言 python

你可能感兴趣的:(day02(测试分类占比、原则;软件开发模式、生命周期模型))