1、软件及软件测试数据库
软件=程序+文档编程
软件测试=程序测试+文档测试浏览器
“程序”是指可以实现某种功能的指令的集合安全
“文档”是指软件在开发、使用和维护过程当中产生的图文集合服务器
2、常见软件系统架构网络
C/S架构架构
C/S架构的优势:并发
1 C/S架构的界面和操做能够很丰富。(客户端操做界面能够随意排列,知足客户的须要)编程语言
2 安全性能能够很容易保证。(由于只有两层的传输,而不是中间有不少层。工具
3 因为只有一层交互,所以响应速度较快。(直接相连,中间没有什么阻隔或岔路,好比QQ,天天那么多人在线,也不以为慢)
C/S架构的缺点:
能够将QQ做为类比:
1 适用面窄,一般用于局域网中。
2 用户群固定。因为程序须要安装才可以使用,所以不适合面向一些不可知的用户。
3 维护成本高,发生一次升级,则全部客户端的程序都须要改变。
B/S
B/S架构的优势:
1、客户端无需安装,有Web浏览器便可。
2、BS架构能够直接放在广域网上,经过必定的权限控制实现多客户访问的目的,交互性较强。
3、BS架构无需升级多个客户端,升级服务器便可。能够随时更新版本,而无需用户从新下载啊什么的。
B/S架构的缺点:
一、在跨浏览器上,BS架构不尽如人意。
2、表现要达到CS程序的程度须要花费很多精力。
3、在速度和安全性上须要花费巨大的设计成本,这是BS架构的最大问题。
4、客户端服务器端的交互是请求-响应模式,一般须要刷新页面,这并非客户乐意看到的。
3、什么是软件测试
使用人工操做或软件自动运行的方式来检验它是否知足规定的需求弄清预期结果与实际结果之间差异的过程
预期结果
指用户的预期结果
实际结果
指的是软件的实际运行结果
软件缺陷
预期结果与实际结果之间的差异
4、开发人员的测试:是调试(Debug)仍是测试(Test)?
调试
在源程序内定为错误
分析错误的缘由
修改错误
在程序运行时检验程序功能
测试
诱发错误
重现错误
定位错误(功能·需求·模块)
记录错误
5、软件测试概述-测试原则
软件测试应该遵照哪些原则呢?
原则1:测试能显示缺陷的存在
原则2:穷尽测试是不可能的
原则3:测试尽早介入
原则4:缺陷的集群性
原则5:杀虫剂悖论
原则6:测试活动依赖于测试内容
原则7:没有失效不表明系统是可用的
原则8:测试的标准是用户的需求
原则9:测试贯穿软件整个生命周期
原则10:独立的测试团队
6、测试人员应具有的素质
技术能力(智商)
软件测试知识
测试工具的使用
操做系统
代码能力
数据库知识
网络知识
沟通交际能力(情商)
好奇心
主动沟通
胆大心细
不被别人绑架
要有怀疑的态度
我的素养(五心)
七、瀑布模型
特色:这是一种古老的瀑布模型,反映了实际和测试之间的关系
局限:仅仅把测试过程做为编码以后的一个阶段,忽视了测试对需求分析,系统设计的验证,若是前面设计错误,得一直到后期的验收测试才被发现,耗时耗力。
生命周期划分为:
制订计划
需求分析
软件设计
程序编写
软件测试
运行维护
优势:
一、开发的各个阶段班级清晰。
二、强调早期计划及需求调查。
三、适合需求稳定的产品开发。
缺点:
一、依赖于早期的需求调查,不适合需求的变化。
二、单一流程不可逆。
三、风险每每延至少后期才会显露,失去及早纠正的机会。
四、问题在项目后期才开始暴露
五、前面未发现的错误会传递并扩散到后面的阶段,看你致使项目失败
改良:
沿用瀑布模型的线性思想,细化了各个阶段,在某些重要关注的阶段之间掺入迭代的思想。
八、W模型
体现“尽早地和不断地进行软件测试”的原则
用户需求 验收测试准备
需求分析与系统设计 系统测试准备
概要设计 集成测试准备
详细设计 单元测试准备
编码 单元测试
集成 集成测试
实施 系统测试
交付 验收测试
九、快速原型模型
在开发真实系统以前,构成一个原型,在该原型的基础上,逐渐完成整个系统的开发工做。
第一步建造一个快速原型,实现用户与系统的交互,用户对原型进行评价,进一步细化待开发软件需求。经过逐步调整原型使其知足用户的要求,开发人员能够肯定用户的真正的需求。
第二步是在第一步的基础上开发出用户满意的软件产品。
优势:
克服瀑布模型的缺点,更好地知足用户的需求并减小因为软件需求不明确带来的项目开发风险,适合预先不能确切定义需求的软件系统的开发。
缺点:
不适合大型系统开发(适合开发小型的、灵活性高的系统)。前提要有一个展现性的产品原型,由此在必定程度上可能会限制开发人员的创新。
十、螺旋模型
螺旋模型将开发过程分为几个螺旋周期,每一个螺旋周期大体和瀑布模型和瀑布模型相符合,螺旋模型沿着螺旋螺线旋转,即在坐标的4个象限上分别表示了4个方向的活动
优势:
螺旋模型很大程度上是一种风险驱动的方法体系,由于在每一个阶段以前及常常发生的循环以前,都必须首先进行风险评估。
缺点:
采用螺旋模型须要具备至关丰富的风险评估的经验和专门知识,在风险较大的项目开发中,若是未可以及时标识风险,势必形成重大损失。过多的迭代次数会增长开发成本,延迟提交时间
十一、软件测试与软件工程
软件测试与软件工程息息相关,软件测试是软件工程中不可缺乏的一部分。
在软件工程、项目管理、质量管理获得规范应用的企业,软件测试也会进行得比较顺利,软件测试发挥的价值也会更大。
要关注软件工程、质量管理以及配置管理与软件测试的关系;在不一样的开发模式下,如何进行软件测试
十二、测试模型
随着测试过程的管理和发展,测试人员经过大量实践,从而总结出了很多测试模型,如常见的V模型、W模型、H模型等。这些与开发紧密结合,对测试活动进行了抽象,成为了测试过程管理的重要参考依据。
1三、V模型
需求分析—》概要设计—》详细设计—》编码—》单元测试—》集成测试—》系统测试—》验收测试
优势:
开发V模型即包含底层测试又包含高层测试
底层测试:检验源代码质量的测试
高层测试:检查整个系统的须要
V模型清楚的标识出软件开发的阶段
它采用自顶向下逐步求精的方式,把整个开发过程分红不一样阶段,每一个阶段的工做都很明确,所以便于控制开发过程。当全部的阶段都完成以后,该软件的开发过程也随之结束。
缺点:
V模型一大缺点正是它自身的顺序性所致使。到了测试阶段,程序已经完成,错误已经产生,不少前期的错误一直到测试阶段才发现,甚至没法发现,每每无从修改了;
同时实际的开发过程当中,在需求阶段就很难把用户的需求彻底明确下来,所以,当需求变动时将会致使阶段反复,并且都要重复需求,设计、编码、测试、等过程,返工量很是大,模型灵活性比较低。
一、单元测试:又称为模块测试,针对单一的程序模块进行测试
二、集成测试:又称组装测试,在单元测试的基础上,对全部模块进行测试
三、系统测试:将整个软件看作一个总体来进行测试,包括功能、性能、兼容性
四、验收测试:
(1)内测版:内部交流版本,可能存在有不少bug,不介意用户安装
(2)公测版:面对全部用户,经过用户的反馈再去进行修改
(3)候选版:与正式软件相差无几
1四、随机测试(探索测试)
随机测试主要是对被测软件的-些重要功能进行复测,也包括测试那些当前的测试用例没有覆盖到的部分。另外,对于软件更新和新增长的功能要重点测试。重点对一些特殊点状况点、特殊的使用环境、并发性、进行检查。尤为对之前测试发现的重大Bug,进行再次测试,能够结合回归测试一块儿进行。
1五、灰盒测试
灰盒测试,是介于白盒测试与黑盒测试之间的一种测试,既可保证黑盒的关注点又可掌控白盒的内部结构,但不会去对内部程序功能和运做作详细了解,灰盒测试结合了白盒测试和黑盒测试的要素。
1六、黑盒测试的分类
功能测试(funct iontest ing)
-是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需
求。
●逻辑功能测试(funct ionesting)
●界面测试(Test ing)
●易用性测试(usability testing)
●安装测试(installationtest ing)
兼容性测试(compatibillitytesting)
性能测试(performance testing)峰值(后面详细如今了解)
-是软件测试的高端领域,性能测试工程师的待遇和白盒测试工程师不相上
下,一般咱们所说的高级软件测试工程师通常就是指性能测试或是白盒测试工程师。
●时间性能(事务响应时间等)
●空间性能(系统资源消耗)
●-般性能测试
●稳定性测试
●负载测试:经过负载测试来肯定在各类工做负载下,系统各项性能指
标的变化状况。
●压力测试:经过肯定- -个系统的瓶颈或者恰好不能接受的性能点,来
得到系统可以提供的最大服务级别。
1七、黑盒测试:
黑盒能发现如下几类错误:
功能不对或功能遗漏。
界面错误。
数据库访问或者处理错误。
性能问题。
黑盒测试的缺点
不能测试程序内部特定部位;
若是程序未执行的代码没法发现;
不可能作到穷举测试
黑盒测试的优势
测试人员不须要了解实现得细节,包括特定的编程语言(没有编程经验的人也可
以设计测试用例) ;
测试人员和编程人员是相互独立的(黑盒测试用例设计与程序如何实现无关) ;
从用户的角度进行测试,很容易被接受和理解;
有助于暴露任何与规格不一致或者歧异的地方;
1八、按是否查看源代码
黑盒测试:
又称数据驱动测试,彻底不考虑程序内部结构和内部特性,注重
于测试软件的功能需求,只关心软件的输入数据和输出数据。
白盒测试:
指的是把盒子打开,去研究里面的源代码和程序结构。
1九、H模型
测试流程:
测试准备:全部测试执行活动的准备;判断是否到测试就绪点;
测试就绪点:测试准入准则,便是否能够开始执行测试的条件;
测试执行:具体的执行测试的程序。
其余流程:
具体开发中的流程,如:设计流程
H模型的优势:
开发的H模型揭示了软件测试除测试执行外,还有不少工做;
软件测试彻底独立,贯穿整个生命周期,且与其余流程并发进行:
软件测试活动能够尽早准备、尽早执行,具备很强的灵活性;
软件测试能够根据被测物的不一样而分层次、分阶段、分次序的执行,同时也是能够被迭代的。
H模型的缺点:
管理型要求高:因为模型很灵活,必需要定义清晰的规则和管理制度,不然测试过程将很是难以管理和控制;
技能要求高: H模型要求可以很好的定义每一个迭代的规模,不能太大也不能过小;
测试就绪点分析困难:测试不少时候,你并不知道测试准备到何时是合适的,就绪点在哪里,就绪点的标准是什么,这就对后续的测试执行的启动带来很大困难;
对于整个项目组的人员要求很是高:在很好的规范制度下,你们都能高效的工做,不然容易混乱。例如:你分了一个小的迭代,可是由于人员技能不足,使得没法有效完成,那么整个项目就会受到很大的干扰。
20、敏捷开发模型
敏捷开发(Agile Development)
以用户的需求进化为核心、迭代、按部就班的开发方法
软件项目的构建被切分红多个子项目
各个子项目的成果都通过测试具有集成和可运行的特征
经过尽早、持续交付有价值的软件来使客户满意
即便在开发的后期,需求变动也是容许的
常常交付可工做软件
项目开发期间,业务人员和开发人员在一块儿工做
强化激励机制,为受激励的我的单独构建项目在团队内部,最富有效果和效率的信息传 递方法是面对面交谈
可工做软件是进度的首要度量标准
敏捷过程提倡可持续的开发速度
不断关注优秀的技能和好的设计,加强敏捷能力
简化
尽可能简化所要作的工做
好的架构、需求和设计出自于组织团队自身
团队要按期检讨如何更有效地工做,并相应地调整本身的行为