软件需求,软件概要设计,软件源代码,软件详细设计,可运行程序,软件运行环境(提交 BUG 应注明当前环境)。
通常是 C/S 架构,比如优酷客户端是 C/S,网页版 B/S。
软件测试定义:使用人工和自动手段来运行或测试某个系统的过程,其目的在于检验它是否 满足规定的需求或弄清预期结果和实际结果之间的差别。
软件测试目的:
① 黑盒测试:无法看到内部代码逻辑,只能关注外部功能,比如给一个输入数据, 看输出数据是否跟预期的结果相符,如果正确,则称该功能正确。(数据驱动和测试)
② 白盒测试:基于软件内部设计和程序实现的测试方法。不只是关注输入输出, 还关注程序处理问题(代码层面)
③ 灰盒测试:(介于白黑)
① 动态测试:运行中的软件测试
② 静态测试:(文档检查、代码走查)
① 手工测试:点点点
② 自动化测试:代替手工繁琐操作
① 功能测试:功能是否符合需求(黑盒)
② 界面测试(UI):布局是否合理,整体风格是否一致,文字是否正确,命名是否统一,是否美观,文字图片是否完美等。
③ 安全测试:测试系统防止非法入侵的能力。(前期工作主要是验证登录)
④ 兼容性测试:系统与其他软硬件兼容能力。
⑤ 易用性测试:主观性比较强,一般基于用户反馈。
⑥ 性能测试:指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
① 单元测试:颗粒度最小,一般由开发小组采用白盒方式来测试,主要测试单元是否符合“设计”;是指对软件中的最小可测试单元进行检查和验证。
② 集成测试:也叫组装测试或联合测试。在单元测试的基础上将所有模块按照要求设计组装成为子系统或系统,进行集成测试。
③ 系统测试:对整个系统的测试,将硬件、软件、操作人员看作一个整体,检验它是否有不复合系统说明书的地方。系统测试可以发现系统分析和设计中的错误。
④ 验收测试:是部署软件之前的最后一个测试操作。在上述步骤完成之后,产品发布之前所进行的测试活动。验收测试是技术测试的最后一个阶段,也称交付测试。目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
① 冒烟测试:对象是新编译需要正式测试的软件版本,其目的是确认软件基本功能是否正常,之后才可以进行后续的正式测试。
② 回归测试:BUG 修正重新测试,关联其他模块测试。
③ 探索性测试/自由测试(测试思维,啥都没测试)
问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试、 软件维护。敏捷开发模型(以人为核心、迭代、循序渐进)
(测试用例)
充分熟悉软件产品业务+参考同类型已上市成熟的软件,与产品经理确认。
等价类、边界值、错误推断法、场景法。我个人常用的方法就是这些。
需要评审;公司业务用户群体达到一定基础数必须要有评审。可以进行内部召开。
我们会根据需求用 xmind 编写测试点,之后进行测试,测试完了,时间充足会进行用例的补充完善。
充分熟悉软件产品业务+参考同类型已上市成熟的软件,与产品经理确认。
在实际测试实践中,测试用例根据重要性分成一定的等级
UI 等测试用例
比如支付、充值等;我们项目按照测试用例的顺序,先去冒烟跑一遍核心功能,然后接下来就是针对每个测试点,考虑一些异常情况,比如充值这块,非 100 的整数倍等情况, 空的输入、0 的输入、超出余额的输入,还有界面是否美观,文字是否一致,用户使用起来是否舒适。
数据库的问题:在做接口测试的时候,加标,借款的竞标天数:输入的是 3 天,数据
库里默认都是 5 天,投资和充值了,交易的流水在数据库里有异常。===我当时觉得印象深刻,主要是做功能测试,主要关注界面,做接口测试的时候呢,比较多的去关注数据库了。 所以发现数据库的很多层面的问题,虽然不是很严重的问题,但是呢我发现数据库测试这部分很重要。==对我来讲,数据库里某一个字段有问题,反映到页面,页面的展示和数据显示等,都会异常,就会影响很大一块的问题。
新建(提 bug)-->指派-->已解决(bug 已修复、不予解决、延期、不是缺陷、重复 bug)
-->待验-->关闭
首先确认开发环境是否跟自己测试环境一致(有时候开发是在他们已更新代码的环境上验证 bug 的,所以 bug 就没出现,但在测试环境上面会出现;还要确认缓存有无清除), 确认在测试环境能重现,如果确认是缺陷跟开发保持有效的沟通,如果是级别较低的建议性bug,可以先记录到 bug 平台,先保留沟通;如果是 bug 级别较高的问题,对应需求文档的预期结果跟开发说明,更有说服力;耐心讲解 bug 的危害,不行就找产品确认,确认是 bug 注明情况并再次指派给开发。
评估这些 BUG 对系统的影响,根据严重等级进行处理,对于比较严重的问题,查看服务器日志协助开发查找原因。
我们公司没做浏览器兼容性测试;建议客户更换兼容性较好的浏览器。
前台可能需要,后台一般不需要,看公司项目安排。
① 软件没有实现产品的说明书所描述的功能。
② 软件实现了产品说明书描述不应有的功能。
③ 软件执行了产品说明书没讲的操作。
④ 软件没有实现产品说明书没描述但应该实现的功能(用户体验相关)。
⑤ 从软件测试员的角度来看,软件难以理解、不易使用、运行缓慢,或者最终用户
认为不对。
① Bug ,由代码编写错误导致的功能问题
② Defect 缺陷,实现与需求不一致
③ Fault 即故障,由于环境系统问题引起运行失败
④ Error 即错误,语法错误,逻辑错误,不易发现
如:错字,文字排版不整齐等,对功能几乎没有影响,软件产品仍可使用。
如:次要功能模块部分丧失、提示信息不够准确、用户界面差和操作运行时间长等。
指功能模块和特性没有实现,主要功能部分丧失,次要功能全部丧失。
造成系统崩溃,四级,或造成数据丢失、主要功能完全丧失等。 如:死机、宕机、黑白屏无法使用、完全卡死
测试人员新报告的缺陷或者验证后缺陷仍存在。
修正软件后已解决问题或已通过单元测试 。
① 功能性
准确性:软件提供具有所需精确度的正确或相符的結果或效果的能力 互操作性:软件与一个或更多个的规定系统进行交互的能力
② 可靠性
1) 定义:软件在指定的条件下使用,维持规定的性能级别的能力 成熟性:软件为避免由软件中错误而导致失控的能力,
容错性:在软件出现故障或违反指定接口的情况下,软件维持规定性能级别 的能力,
易恢复性:在失效发生的情况下软件里重建规定的件能级别并恢复受直接影响的数据的能力
可靠性依从性:软件遵循与可靠件相关的标准,约定以及法律法规的能力
③ 效率
1) 定义:在规定的条件下,相对于所用资源的数量,软件提供适当性能的能力时间特性:在规定的条件下软件执行其功能时,提供适当的响应和处理时间 以及吞吐率的能力
资源利用性:在规定的条件下软件执行其能力时,使用合适的资源数量和类 别的能力
效率依从件:软件遵循与效率相关的标准和约定的能力
④ 易用性
1) 定义:在指定的条件下使用时,软件被学习,理解,使用和吸引用户的能力
易理解性:软件的使用,用户能理解软件是否合适,以及如何将软件用于特
定的任务和使用环境的能力
易学习:软件使用户能学习其应用的能力易操作性:软件使用用户操作和控 制它的能力
吸引性:软件吸引用户的能力
易用性依从性:遭循与易用性相关的标准、约定风格指南或法规的能力
⑤ 可维护
1) 定义:软件可被修改的能力,修改可能包括修正、改进或软件对环境、需求 和功能规格说明变化的适应性
易分析性:软件诊断软件的缺陷,失效原因或识别待修改部分的能力, 易改变性:软件指定的修改可以被实现的能力
稳定性:软件避免由于软件修改而造成意外结果的能力, 易测试性:软件使已修改软件能被确认的能力
可维护依从性:遵循与维护相关标准和约定的能力,
⑥ 可移植
1) 定义:软件从一种环境迁移到另一种环境的能力适用性:软件能适用于不同的环境的能力
易安装性:软件在指定环境中被安装的能力
共存性:软件在公共环境中同与其分享公共资源的其他独立软件共存的能力
易替换性:软件在同样的环境下,替代另一个相同用途的指定软件产品的能 力
可移植性依从性:软件遵循可移植性相关的标准和约定的能力
需求分析 —》可行性分析 —》概要设计 —》详细设计 —》编码实现 —》调试和测试 —》软件验收与应用 —》维护升级 —》废弃
基于测试是为了寻找软件的错误与缺陷,评估与提高软件质量,因此我们提出了这样的一组测试原则,如下所示。
4W1H 原则:
从功能测试层面上,web 和 APP 测试在流程上没有区别,但是两者的载然不同,主要区别如下:
Web 项目是 B/S 结构,基于浏览器,只需要更新服务器,客户端就会同步响应
APP 项目是 C/S 架构,服务器更新之后,客户端手动进行更新
Web 测试需要响应时间、内存、CPU、吞吐量、并发数
APP 测试需要响应时间、内存、CPU、消耗电量、流量
Web 测试主要考虑浏览器和操作系统
APP 测试主要考虑手机品牌、型号、尺寸、分辨率、版本
自动化测试:web 一般用 selenium,手机用 APPnium
性能测试:web 一般用 LR,手机用 jmeter
相对 web 测试手机 APP 测试还需关注
① 干扰测试:来电,短信,通话,关机,重启
② 不同网络下的测试,网络切换的测试,无网的测试
③ 安装,卸载,更新
二、网络基础知识
GET 产生一个 TCP 数据包;POST 产生两个 TCP 数据包。
对于 GET 方式的请求,浏览器会把 http header 和 data 一并发送出去,服务器响应 200
(返回数据);
而对于 POST,浏览器先发送 header,服务器响应 100 continue,浏览器再发送 data, 服务器响应 200 ok(返回数据)。
SYN=1,seq=x
ACK=1,ack=x+1,SYN=1,seq=y
上面分析过程可以看出,握手两次达不到让双方都得出自己、对方的接收、发送能力都正常 的结论的。
已经随 Location 头信息返回
或 HEAD 请求的响应)时,会自动将请求者转到新位置。
响应代表着服务器验证已经拒绝了那些证书
UDP:不需要连接成功也能发送成功数据;微信、QQ,自己账号没有登陆,别人也可以发送成功;只适合少量数据,否则容易丢失数据。
TCP:必须连接成功才能发送数据,适合大量
三、自动化测试
接口项目测试流程:
就拿简历上的 xxx 项目来说吧,在编写脚本前,我们会对系统进行评估,确认这个系统可不可以实现 UI 自动化,如果可以的话,就筛选出能实现自动化测试的用例,一般优先把冒烟测试用例的转为成脚本。我们是用 selenium 工具来实现自动化,采用 python 脚本语言,基于 unittest 框架进行用例的编写。比如,充值这个功能的脚本,我们是这样做的:首先,我们会构建一个测试工程,测试工程包含 testcase,主要用来存放测试用例,report 用来存放测试报告,其次我们会把用例中公共的部分封装到 common 中,最后用 runAllCase 的 python 文件运行项目自动化用例,脚本调试完后,我们会用 jenkins 持续集成工具,设置脚本每天晚上 10 点跑一遍脚本,跑完后生成 html 格式的自动化测试报告并自动发送邮件。
冒泡排序是最简单的排序算法,如上图所示,我们可以看到不断的从左到右进行比较两个元素的大小,如果后面的元素小于前面的元素,那么它们会交换位置,这样小的元素就会 在前面。
5-1 次比较,就能把最大的数放在最后面;第 2 轮的时候,因为第一轮的原因,最后 1 个数
字不用比较,就是 5-1-1 = 3 次
def bubbleSort(arr): n = len(arr)
# 一共要进行 n-1 轮才能排好序
for i in range(n - 1):
# j 控制每一次的比较,n-i-1 是元素的范围,也就是要比较几次,这里不理解的, 自己在纸上画
for j in range(0, n - i - 1):
if arr[j] > arr[j + 1]: # 交换位置
arr[j], arr[j + 1] = arr[j + 1], arr[j]
return arr
arr = [64, 34, 25, 12, 22, 11, 90]
bubbleSort(arr) print(arr)
四、性能测试
五、必记代码
for i in range(1,10):
for y in range(1,i+1):
msg = '{0}*{1}={2}'.format(i,y,i*y) print(msg,end='\t')
print()
a = [9,2,3,1,6,7,0]
# 确定循环次数为 列表长度-1 次
times = len(a) -1
while times > 0:
for i in range(times): if a[i] < a[i+1]:
a[i],a[i+1]=a[i+1],a[i] times = times -1
print(a)
from selenium import webdriver from time import sleep
import unittest
class mytest(unittest.TestCase): def setUp(self):
self.d = webdriver.Chrome() self.d.get('网址')
def tearDown(self): self.d.close() self.d.quit()
def test_case_001(self):
self.d.find_element_by_css_selector('CSS 定位表达式').send_keys('username') self.d.find_element_by_xpath('Xpath 定 位 表 达 式 ').send_keys('password') self.d.find_element_by_css_selector('CSS 定位表达式').click()
sleep(1)
login_msg = self.d.find_element_by_id('ID').text self.assertIn('预期结果',login_msg)
if name == ' main ': unittest.main()
公司有接口测试需求,接收到接口测试任务。
模拟客户端向服务器发送请求,服务器接收请求后对相应的请求做处理并向客户端返回相应结果,客户端接收结果的一个过程。
前后端对接 OK(跑正常功能)、前端基本校验
集成测试
如果接口响应的数据不正确,那就很可能是后端的问题,如果请求参数不正确或者接口响应数据正确但是页面上显示不对,就是前端的问题
https://www.cnblogs.com/fighter007/p/12145205.html
先对开发提供的接口文档做好需求分析,进行用例编写及评审,然后我们选择 jemter 做接口测试,我的习惯是把主要的接口串在一起做一个自动化批量测试,确保接口功能是正 常的,然后进行详细的测试。比如测试一个接口,添加线程组添加 http 请求,填写接口信息;如果接口与接口之间有依赖就需要添加 cookie 管理器,jdbc requests,正则表达式等元件,然后添加结果树和断言,关注响应结果是否跟预期一致,同步关注数据库字段,如果
报错查看日志定位,大致就是这样
在 HTTP 请求的返回数据包中,响应状态码分为以下 5 种。
版本不支持等。
HTTP 中有四种发送请求的方式:GET、POST、PUT 和 DELETE。
在实际应用中常用的是 GET 和 POST。其他的请求方式都可以通过这两种方式间接地实现。
HTTP 发送请求最主要的两个方式是 GET 和 POST,这两者有哪些区别呢?
区别一:对请求参数的处理方式不同(直观的区别)
举例:https://www.v2ex.com/api/nodes/show.JSON?name=Python
举例:http://192.168.1.171:8081/api/user_sign/
Body 数据:{"time":"1499933825","sign":"deb697c7fffcca828a7a03a218b2cda5"}
区别二:传输数据的大小不同
HTTP 没有对传输数据的大小进行限制,也没有对 URL 的长度进行限制。而在实际的程序开发中,存在以下限制。
(2×1024Byte+35Byte)。其他浏览器(如 Netscape、FireFox 等)在理论上没有长度的限制,其限制取决于操作系统的支持。因此,在采用 GET 方式提交数据时,传输数据会受到URL 长度的限制。
服务器会对采用 POST 方式提交的数据的大小进行限制,例如,Apache、IIS6 都有各自的配置。
区别三:安全性不同
POST 方式的安全性比 GET 方式的安全性高。使用 GET 方式时,在地址栏里可以直接看到请求数据,采用这种方式可能受到 Cross-site request forgery 攻击。
POST 方式需要抓包才能获取到数据,变相地提高了安全性。
我以充值这个接口说下吧:充值这个接口用的是 http 协议,使用 post 请求方式,发送给服务器的参数有手机号,充值额度,这些参数都是必传的参数。我们是使用 Jmeter 来做接口测试的,首先,要新建一个线程组,在线程组下面添加一个 http 的请求,然后填写好服务器地址,接口路径,请求方式,请求参数。由于充值的接口依赖于登录,所以我们会先调用登录接口,从中获取 cookies 值,在充值接口中使用${参数名}的方式引用,接下来还要对其他参数进行参数化,构造各种正常和异常的数据,我们先在本地创建一个 txt 文档, 把参数填写到文档里面,在 Jmeter 中添加一个 csv 文件设置,填写好 txt 文档的路径,然后在请求参数中使用正则提取器把 cookies 值关联出来,然后在充值接口中使用${参数名} 的方式引用;接下来添加断言,检查服务器返回的结果和预期结果是不是一致的。最后,添加查看结果树查看测试结果。
需要的先关注再私我关键字【000】免费获取哦 注意关键字是:000
疑惑:为什么要先关注呢? 回:因为没关注的话私信回了你看不到
app项目,银行项目,医药项目,电商,金融
听说关注我并三连的铁汁都已经升职加薪暴富了哦!!!!