总结
------------恢复内容开始------------
1.程序测试包含哪些内容:程序测试包括程序逻辑功能,界面,性能,易用性,兼容性,安装等测试,当然文档测试也算,排版,字体大小,也算程序测试的内容
2.环境测试:环境测试 = 硬件 + 软件 + 网络
硬件环境:笔记本,台式机,服务器
软件环境:不同的操作系统windows10 , windows8 , windows7 , Linux , Mac,
不同浏览器firefox , chrom
网络:局域网还是互联网


3.测试流程
|
需求评审 |
测试计划制定 |
测试计划执行 |
发布与测试报告总结
|
|
1从用户体验角度提供设计建议 2从开发经验角度,分析设计是否存在风险,是否能够实现 3 联合其他模块分析,设计是否存在漏洞,逻辑功能存在缺陷
|
1测试用例设计 2测试用例评审,和测试时间估计 3测试资源申请
|
1用例执行 2 Bug修复验证和推动版本进度 3性能监控,压力测试,兼容测试
|
1版本发布和线上质量监控,用户反馈实时响应 2测试用例更新整合,测试计划评估 3提供版本最终测试报告,包括用例覆盖率,bug数据分析等
|
|
全程跟进需求变更,与产品无缝沟通,在测试阶段有需求变更要第一时间了解改动范围,如果影响版本的质量要说明风险,评估需求是否必须更改以及是否影响版本发布上线的时间线
|
规划测试项目需要的功能开发和自动化开发人员比例,规划整个测试流程需要的时间,要预留处理紧急事件的缓冲
|
执行 协调测试资源,部署测试环境,督促开发和产品提供一切需要的测试工具,测试数据等,推动版本进度,每日进行bug review(bug复盘),标识出bug解决的优先级和提交测试的时间点,每日提供当日产品质量报告
|
报告 项目发布上线后,对整个版本的bug进行数据分析,总结出用例的覆盖率,对于没有覆盖到用例的bug,转化成用例,同时测试人员之间进行分享,针对新接触的测试方法测试工具和有价值的bug进行经验总结
|
4.软件测试分类

5.黑盒测试和白盒测试
黑盒测试(Black Box-Test)指的是把被测试的软件看做一个黑盒子,我们不去关心盒子里边的结构是什么样子,只关心软件的输入和输出结果
白盒测试(White Box-Testing):指的是把盒子盖打开,去研究里边的边源代码和程序结构
6.静态测试和动态测试
静态测试,是指不实际运行被测试软件,而只是静态的检查程序代码,界面或者文档中可能存在的错误的过程
动态测试:是指实际运行被测程序,输入相应的测试数据,检查实际输出结果的预期结果是否相符的过程
7.功能测试和性能测试
是黑盒测试的一部分,它检查实际软件的功能是否符合用户的需求。
功能测试可以细分逻辑功能测试,界面测试,易用性测试,安装测试和兼容性测试。
逻辑功能测试:测试应用是否符合逻辑,比如应该先注册账号之后,才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小,按钮大小,点击按钮弹出什么样的提示框,是否有滚动条,下拉菜单是否有展示内容...
易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如,软件窗口长宽比例是否合适,颜色色彩是否赏心悦目,字体大小是否合适
兼容性测试:硬件兼容性测试和软件兼容性测试
硬件兼容性:比如一款软件在pc机,笔记本,主机上是否兼容
软件兼容性测试:比如一款软件在windows8和windows10上是否兼容
性能测试:
时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮,到登录成功(失败)的反应时间,浏览器非常常见,ANR(Application not responding 应用程序无响应)
空间性能:软件运行时所消耗的系统资源,比如对内存和cpu的消耗
一般性能测试:软件正常运行,不向其施加任何压力的测试
稳定性测试:也叫可靠性测试,是指连续运行被测系统,检查系统运行时的稳定程度。
负载测试:让被测系统在其能够忍受的压力范围之内连续运行,来测试系统的稳定性。(测试载重)
压力测试:持续不断的给被测试的系统增加压力,直到被测试的系统压垮为止,用来测试系统所承受的最大压力。(测试强度)
8.回归测试,冒烟测试,随机测试
1.回归测试
是指对软件的新版本进行测试时,重复执行上一个版本测试时的用例,比如在1.0版本中,有一个bug,到了2.0版本中,再重新测试1.0中这个bug(回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。)
2. 冒烟测试
指对一个软件进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。
测试小组在正式测试一个新版本之前,先指派一两个测试人员测试一下软件的主要功能,如果没有实现,则打回开发组重新开发,这样做可以节省大量的时间成本和人力成本。
3. 随机测试
是指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。
9.单元测试,集成测试,系统测试和验收测试

单元测试(unit testing):是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。
总的来说,单元就是人为规定的最小的被测功能模块。
单元测试当一段代码完成之后,是由白盒测试工程师或者开发人员自行测试,比如java中执行单元测试叫做junit测试。
目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序,没有相应的单元测试计划。
单元测试方式:先静态地观察代码是否符合规范,然后动态地运行一下代码,检查运行的结果。
集成测试:
集成测试是单元测试的下一个阶段,是指将通过测试单元模块组装成系统或者子系统,再进行测试,重点测试不同模块的接口部分。
在把各个模块连接起来的时候,穿越各个模块的接口的数据时候会丢失
一个模块的功能是否会对另一个模块的功能产生不利的影响
各个子功能组装完成后,能否达到预期的父功能
全局数据结构是否有问题
单个模块产生的误差累计起来是否会放大
例如:模块接口测试
应对通过所测模块的数据流进行测试
l调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配
所测模块调用子模块时,输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。
输出给标准函数的参数的个数、属性和顺序是否正确
系统测试和验收测试:
集成测试完成之后,就是系统测试和验收测试。
系统测试:指的是将整个软件系统看做一个1个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试,前期主要测试系统的功能是否满足需求,后期主要测试系统运行的性能是否满足需求,以及系统在不同的软硬件环境的兼容性等。
验收测试:以用户为主的测试,软件开发人员和质量保证人员参加
10.软件测试的原则:
|
1.应当把“尽早和不断地测试”作为开发者的座右铭。 |
|
2.设计测试用例时,应该考虑到合法的输入和不合法的输入,以及各种边界条件,特殊情况下要制造极端状态和意外状态,比如网络异常中断、电源断电等情况。 |
|
3.一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系。 |
|
4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误,一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。 |
|
5.制定严格的测试计划,并把测试时间安排得尽量宽松,不要希望在极短的时间内完成一个高水平的测试。 |
|
6.回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多错误出现的现象并不少见。 |
|
7.妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。 |
11.软件的开发模式
线性模型与渐进性模型
线性模型:最常见的“瀑布模型”,基础框架,但缺点在于“集成之日就是爆炸之日”。(立项分析-需求分析-设计-编码-测试-维护)很多企业使用后使用迭代进行修改。
渐进式模型:最常见的“螺旋模型”,(需求分析-风险分析-设计、编码-测试、评审),迭代开发和增量开发模式。
注意:每一次迭代原型出来后,测试人员都需要从原型界面,系统主要功能,性能等方面对原型进行评审。
12.软件生命周期
软件生命周期 同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段,一般称为软件生命周期(软件生存周期)[1] 。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

13.边做边改模型
许多产品都是使用“边做边改”模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。

在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。
这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:
(1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;
(2) 忽略需求环节,给软件开发带来很大的风险;
(3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。
14.瀑布模型
瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动。同时评审该项活动的实施,若确认,则继续下一项活动;否则返回前面,甚至更前面的活动。对于经常变化的项目而言,瀑布模型毫无价值。

瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件,前面一个步骤不完成,后面的步骤不能开始,否则问题会滚到下个阶段,带来更多的问题
优点:
1) 为项目提供了按阶段划分的检查点
2) 当前一阶段完成后,只需要去关注后续阶段。
缺点:
1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4)瀑布模型的突出缺点是不适应用户需求的变化。
15.原型化模型
原型化模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,经过和用户针对原型的讨论和交流,弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后,再在原型基础上开发出用户满意的产品。
如图所示:原型严格来说不算一种软件生命周期模型,它只是一种获取需求的方法,在实际工作中该方法是相当重要的方法。
模型要点:瀑布和原型模型相结合,强调版本升级。
该模式的特点是一次性地获取全部的需求,然后做出分版本实现各需求的计划,每个版本只实现一部分需求,通过多个版本逐步实现全部需求,而每个版本可以认为是一个“小瀑布”。
该模型的好处是可以尽快让系统上线,让客户先使用部分功能,尽早实现系统的价值。
该模型比较能符合实际的情况,我们往往也是通过多个版本来逐步实现全部需求,但需求是不可能在一开始就完全确定的,实际情况是往往只能确定80%,而后期通过各版本我们还会获取更多的新需求以及需求调整。将此模型稍微调整后,可以适用于大部分的实际项目。
16.增量模型
增量模型也是原型化开发方法。如图所示

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

图中的螺旋线代表随着时间推进的工作进展;开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段:制定计划、风险分析、实施工程和客户评估。螺旋模型要点:统一了瀑布模型与原型模型,与增量模型相似,更强调风险分析。
1.软件分多个版本开发,每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行:
1)确定软件目标,选取定实施方案,弄清项目开发的限制条件;(图中左上象限)
2)分析所选取方案,考虑如何识别和消除风险;(图中右上象限)
3)实施软件开发;(图中右下象限)
4)评价开发工作,提出修正建议,调整计划。(图中右下象限、左下象限)
3.需求不是一次获取和实现的,通过多个螺旋来完善。
4.计划也不是一次成型的,每次螺旋都需要调整。
优点:
1)设计上很灵活,可以在项目的各个阶段进行变更;
2)以小的分段来构建大型系统,使成本计算变得简单容易;(国企项目)
3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性;
4)随着项目推进,客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互;
5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点:
螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的。
因此,这种模型往往适应于内部的大规模软件开发。该模型建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。
18.V模型
V 模型的左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

V模型的缺陷及解决思路
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的满足情况一直到后期的验收测试才被验证。
解决的思路是,当一个软件开发的时候,研发人员和测试人员需要同时工作,测试在软件做需求分析的同时就会有测试用例的跟踪,这样,可以尽快找出程序错误和需求偏离,从而更高效的提高程序质量,最大可能的减少成本,同时满足用户的实际软件需求。
优点:
1 每一个阶段都清晰明了,便于控制开发的每一个过程。
2 既包含单元测试又包含系统测试。
缺点:
1 测试介入的比较晚,对于前期的一些缺陷无从发现和修改。
2 测试和开发串行。
19.W模型
相对于V模型,W模型更科学。W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。

优点
1 测试伴随着软件的整个生命周期,例如,在需求分析结束后就可以进行需求分析测试。
2 测试于开发是并行独立进行的。
缺点
1 对有些项目,开发过程中根本没有文档产生,故W模型无法使用。
2 对于需求和设计的测试技术要求很高,实践起来很困难。
20.软件测试的常识知识
1.测试部门的组织结构


21.软件测试工具
https://zhidao.baidu.com/question/8152959.html
软件测试工具是通过一些工具能够使软件的一些简单问题直观的显示,使测试人员更好的找出软件错误所在。
软件测试工具分为自动化软件测试工具和测试管理(禅道)工具。
软件测试工具存在的价值是为了提高测试效率,用软件来代替一些人工输入。
测试管理工具是为了复用测试用例,提高软件测试的价值。
一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。
Bug管理工具: 禅道 Jira(付费),Trac,gitlab
自动化 python+ selenium ,python+ appnium (ui自动化) pytest,unites,Junit (测试用例 单元测试) innerHtml (发送测试报告) request +python+allure 接口自动化
性能测试工具 jmeter ,Loadrunner、
抓包工具 Fiddler ,charles (弱网测试的)
接口工具 postman ,jmeter
录制脚本 bodyboy jmeter
云测 腾讯云 模拟不同的移动端或者是web浏览器
命令 Linux adb monkey
数据库 myql,oracle,redis
语言 python,java,c,c++


浙公网安备 33010602011771号