应用知识点最新版Word下载.docx
《应用知识点最新版Word下载.docx》由会员分享,可在线阅读,更多相关《应用知识点最新版Word下载.docx(14页珍藏版)》请在冰豆网上搜索。
C/S架构也可以看做是胖客户端架构。
因为客户端需要实现绝大多数的业务逻辑和界面展示。
这种架构中,作为客户端的部分需要承受很大的压力,因为显示逻辑和事务处理都包含在其中,通过与数据库的交互(通常是SQL或存储过程的实现)来达到持久化数据,以此满足实际项目的需要。
C/S架构的优缺点
优点:
1.C/S架构的界面和操作可以很丰富。
2.安全性能可以很容易保证,实现多层认证也不难。
3.由于只有一层交互,因此响应速度较快。
缺点:
1.适用面窄,通常用于局域网中。
2.用户群固定。
由于程序需要安装才可使用,因此不适合面向一些不可知的用户。
3.维护成本高,发生一次升级,则所有客户端的程序都需要改变。
B/S架构
B/S架构的全称为Browser/Server,即浏览器/服务器结构。
Browser指的是Web浏览器,极少数事务逻辑在前端实现,但主要事务逻辑在服务器端实现,Browser客户端,WebApp服务器端和DB端构成所谓的三层架构。
B/S架构的系统无须特别安装,只有Web浏览器即可。
B/S架构中,显示逻辑交给了Web浏览器,事务处理逻辑在放在了WebApp上,这样就避免了庞大的胖客户端,减少了客户端的压力。
因为客户端包含的逻辑很少,因此也被成为瘦客户端。
B/S架构的优缺点
1)客户端无需安装,有Web浏览器即可。
2)BS架构可以直接放在广域网上,通过一定的权限控制实现多客户访问的目的,交互性较强。
3)BS架构无需升级多个客户端,升级服务器即可。
1)在跨浏览器上,BS架构不尽如人意。
2)表现要达到CS程序的程度需要花费不少精力。
3)在速度和安全性上需要花费巨大的设计成本,这是BS架构的最大问题。
4)客户端服务器端的交互是请求-响应模式,通常需要刷新页面,这并不是客户乐意看到的。
(在Ajax风行后此问题得到了一定程度的缓解)
5.测试需求的特征
●完整性、充分性:
测试需求必须充分地覆盖软件需求所有的功能性要求和非功能性要求,不能有遗漏。
●准确性:
测试需求当中的每一项内容都必须描述清楚,且正确地反应了测试任务和用户的要求。
●可追溯性:
从测试需求可向上回溯到系统需求,向下追踪到测试用例
●一致性:
测试需求中各部分内容的描述是一致的,不存在相互矛盾的地方
●可行性:
每一项测试需求在已有的条件下都是可是测试、可以实施的
6.测试过程的4项基本活动
测试策划、测试设计、测试执行、测试总结
7.基本测试过程的计划和控制步骤的任务
基本测试过程:
分析测试需求,制定测试计划,定义测试内容,评审,执行测试,分析结果
8.衡量测试过程进度的度量项
每件具体工作的计划开始结束时间,实际开始结束时间,计划工时数,实际工时数,计划完成率
9.回归测试中选择测试用例的方法
第一,新修改的功能,这个显然是重点
第二,新修改的功能的关联功能,就是有耦合的部分,这个一般最好咨询一下开发人员
第三,程序最有卖点或者说亮点的部分,这个地方一旦有问题,会使程序质量大打折扣
第四,程序中最致命的部分,譬如说安全隐患,数据泄露,加密注册,
第五,程序中比较脆弱的部分,这个要咨询开发人员,一般就是他们心中最没底的地方
第六,程序的主干功能
第七,如果以上做完,还有时间的话,最好把用例中级别比较高的用例再执行一遍。
10.Web应用软件测试相关知识
11.检查Web对象的属性值的检查点
将需检查的对象加入对象库中
Browser("
Welcome:
MercuryTours"
).Page("
FindaFlight:
Mercury"
).WebList("
passCount"
).CheckCheckPoint("
)
12.RunLogic中Run迭代相关计算
设置Replay——Run-timeSetting——RunLogic
13.CalltoCopyofAction和CalltoExistingAction的区别
14.测试计划及方案包含的主要内容项
测试计划:
项目背景,测试目标,测试范围,测试资源,测试策略,测试环境,测试时间表,测试用例,进度报告,缺陷管理,风险分析
测试方案:
方案概述,方案概述、测试需求范围、测试计划制定、测试用例设计、测试环境部署、准备测试数据、测试执行与回归、系统功能测试、系统性能测试、各阶段评审、项目组织架构及职责分工、项目交付物
15.LoadRunner和UFT的工作原理及两者之间的比较
QTP工作原理
QTP的脚本运行其实就是一组对象有组织的执行自己的方法,最终完成一个流程的过程。
当打开一个web时,想要
脚本能够模拟人来操作整个流程,那多就要求这个脚本能识别人的每一个操作,而人的操作实际上是对web页面上控件的操作,所以只要QTP的脚本能够识别人操作过的控件就可以模拟人的操作流程,而web页面上的控件都是QTP脚本中的对象,也就是说只有QTP脚本中的对象能够被唯一的识别出来,就可以模拟人的整个操作流程。
QTP支持直接访问DOM,可以通过DOM来访问HTML标签。
在QTP中,访问DOM是通过使用page测试对象的object属性来进一步访问的,这样就可以访问到很底层的对象属性,可以用底层的对象属性来唯一区分web页面上的对象控件,这样就能够解决一些关于对象识别的错误。
LoadRunner工作原理
LoadRunner由五大组件组成:
VuGen、控制器、负载发生器和分析器和用户代理程序。
1、虚拟用户脚本生成器(VuGen):
捕捉用户的业务流,并最终将其录制成一个脚本。
2、测试控制器(Controller):
(1)设计场景,包括手动场景设计和目标场景设计两种方式;
(2)场景监控,可以实时监控脚本的运行的情况。
3、负载生成器(LoadGenerators):
模拟用户对服务器提交请求。
4、结果分析器(Analysis):
主要用于对测试结果进行分析。
5、用户代理(Proxy):
协调不同负载机上虚拟用户,产生步调一致的虚拟用户;
区别
LoadRunner是性能测试工具,一般用来做压力、负载测试等性能测试。
它是基于议协的的工具,它根据你测试的系统需求,选择合理的议协来录制这个议协下发出的“信号”,然后它可以虚拟并发器回放那种“信号”;
QTp是GUI界面功能自动化测试工具,简单来说就是可以录制人操作,然后回放,工具根据录制好的人操作来操作系统,这样可以很好地进行回归测试。
16.ALM可以集中管理的UFT和LoadRunner的测试资源
便于测试资源、测试脚本、测试文档的集中管理
ALM能管理LoadRunner脚本、场景文件
ALM能管理UFT脚本、对象库、函数库、场景恢复文件
17.描述性编程写出登录函数以及相关参数
CRM
system"
Title:
=Login"
).WebEdit("
Name:
=login"
).setText
"
admin"
=Password"
).WebButton("
).Click(程序没有调试,不知道有没有错)
18.黑盒测试方法设计功能测试要点
等价类划分:
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:
测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:
有效等价类和无效等价类.
边界值:
边界值分析方法是对等价类划分方法的补充。
测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
因果图:
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,
相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图(逻辑模型).因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况.
场景法
19.场景中TPS和虚拟用户之间的相关计算
简单例子:
在术语中解释了TPS是每秒事务数,但是事务时要靠虚拟用户做出来的,假如1个虚拟用户在1秒内完成1笔事务,那么TPS明显就是1;
如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务,TPS就是1000了;
如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务,要想达到1000TPS,至少需要1000个用户;
因此可以说1个用户可以产生1000TPS,1000个用户也可以产生1000TPS,无非是看响应时间快慢。
Chapter01:
1.4.3:
B/S架构简介
表示层(UI):
显示数据和接收用户输入的数据,为用户提供一种交互式操作界面。
业务逻辑层(BLL):
与业务需求有关的系统设计,BLL调用DAL提供的接口实现业务逻辑,UI根据用户需求,调用BLL提供的接口检索数据并显示用户。
数据访问层(DAL):
实现对数据库表的查询,添加,更新,删除等操作
●层是一种弱耦合结构,层与层之间的依赖是向下的。
●理想的分层式架构应该是一个支持可抽取的、可替换的、抽屉式架构。
1.4.4:
B/S架构的关键技术及测试要点
功能测试:
性能测试:
系统需求链接速度
界面负载测试
链接测试压力测试
数据库测试疲劳测试
Cookies测试强度测试
容量测试
Chapter02:
2.2.2:
性能测试指标分析(P40)
并发用户数=(5%-20%)*在线用户数
系统响应时间:
普通业务操作最好是低于3s,一般不超过5s
80-20原理:
80%的业务操作集中在20%的时间内完成
CPU使用率>
75%繁忙
2.3.1:
测试过程的实施策略(P43