Sentry监控平台能够为项目团队提供很好的检测和解决影响用户体验的错误和其他问题的工具。它是开源的,并且是完全免费的,具有与付费版本有相同的优点。
Sentry监控平台会告诉你应用程序何时崩溃或运行太慢以及应用程序的性能,从而能够深入研究需要注意的区域。它除了可以解决错误外,还可以解决最终导致错误的问题。
Sentry监控平台的特征也十分的明显:那就是十分的容易安装;它能够利用 Google 的 Web网站要素来提供有关性能的详细信息;并且支持交易追踪。
Sentry监控平台能够为项目团队提供很好的检测和解决影响用户体验的错误和其他问题的工具。它是开源的,并且是完全免费的,具有与付费版本有相同的优点。
Sentry监控平台会告诉你应用程序何时崩溃或运行太慢以及应用程序的性能,从而能够深入研究需要注意的区域。它除了可以解决错误外,还可以解决最终导致错误的问题。
Sentry监控平台的特征也十分的明显:那就是十分的容易安装;它能够利用 Google 的 Web网站要素来提供有关性能的详细信息;并且支持交易追踪。
目前绝大多数应用都是基于网络的分布式应用,我们无法知道用户数量,用户场景的不确定性,导致系统测试时,不仅仅是功能,业务逻辑,接口测试,还要测试系统性能。
对于分布式网络,测试不同用户数量来测试系统的反应,主要关注性能指标,系统不同表现。
软件测试的作用和价值:两个方面产品和用户。
产品角度:在研发过程中尽早的发现问题,提高软件质量,确保产品交互,功能完善,稳定可靠。
用户角度:关注用户体验,操作,界面,性能,尽可能想办法提升用户体验,持续改善。
性能测试的核心原理,开发测试工具也是基于前两点 、基于协议,基于界面,基于代码。基于网络的分布式架构:基于网络协议去模拟用户发送请求多线程:模拟多线程操作,多人同时操作,模拟大负载量;
软件测试按照不同的分法可以分为不同的种类,其中按测试用例设计方法分,软件测试可以分为:黑盒测试,白盒测试和灰盒测试。
黑盒测试(Black-box testing),又被称为是功能测试或者数据驱动测试,如果把系统看成一个黑盒子,就不再考虑程序的内在逻辑,只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
白盒测试(White-box testing),又被称做结构测试或逻辑驱动测试,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。
灰盒测试(Gray-box testing),这个测试方法是融合了白盒和黑盒测试的一种测试策略,有时也被称为是混合测试法。
而按照测试策略和过程分,软件测试又会被分为以下几种:
单元测试(Unit Testing),它是最小单位测试,是在系统开发过程中要进行的最低级别的测试活动。单元测试活动中对源代码实现的每个程序单元会逐一进行测试,会检查各个程序模块是否正确地实现了规定的功能。它的目的在于发现各模块内部可能存在的各种错误,单元测试的存在需要从程序的内部结构出发设计测试用例,必要的时候要制作驱动模块和桩模块。
集成测试(Integration Testing),也被称为组装测试,集成测试的存在是在单元测试的基础上,将所有模块按照结构设计要求组装成为一个可运行的系统。集成测试是一个对应于软件概要设计阶段的测试,它要求尽可能地暴露程序单元或模块间接口和软件设计上的错误和缺陷,确保程序单元或模块间接口正确和软件结构合理。集成测试按系统集成方式,可分为非增量式和增量式,增量式可分为自定向下集成、自底向上集成和混合增量式集成两种。
系统测试(System Testing),它是基于一定的计算机硬件环境,对整个软件进行的一系列测试;是将已经通过集成测试的软件与具有一定代表性的计算机实用环境相结合,根据软件项目系统级的有关文档,检查软件与系统定义、与需求的符合性,检验并确认软件在整个系统中的功能、性能和正确性。完成集成测试后的软件系统,必须与系统的其他元素相结合,进行系统级的确认和验证测试。
关联是Jmeter工具中非常重要的一个技术。因为在测试过程过有些数据是经常发生变化的,如果想要获取并且使用这些数据,就要使用到关联这项技术。
在jmeter关联中,分为三类常见的项目技术,第一是正则表达式,第二是边界提取器,第三是Json Extractor提取器。
然而要使用Jmeter去做一些连贯性的接口调用时,开发人员需要使用接口响应的信息,用之前的信息来作为下一接口的入渗,而Jmeter关联提供了针对该操作的后置处理器配件,其中较为常见的处理器就是正则表达式处理器和更简单易用的边界提取器。
正则表达式,又被称规则表达式(Regular Expression),在代码中被简称为regex、regexp或RE,是一个计算机科学的重要概念。正则表达式往往会被用于检索、替换一些符合某个模式的文本。现在流行的很多程序设计语言都支持使用正则表达式进行字符串操作。
边界提取器:这是一个操作起来极其简单但却十分实用的后置处理器,相比正则表达式繁琐的命令方法,边界提取器只需要知道你的目标片段前后的信息就可以准确的提取目标片段了。
当我们的自动化项目代码写多了之后,就会发现常用的库就是那么几个,而且用法大同小异,俗称样板代码。这个时候就可以考虑去做一些封装,然后把那些常用的功能封装成一类一类的公共方法,这样就可以在你的项目代码、包括以后得开发中去调用,这样可以实现更快速的完成开发任务,并且便于应对需求的变化。
自动化测试框架和你在项目中封装的公共模块有着一些不同。它实现的功能更通用:例如,你可以在项目中封装一个登录的公共模块,用于所以用例的登录,但不能在框架里面封装一个登录,因为,你们的项目登录是用账号密码,别人家用的是手机号+验证码,你封装的登录脱离了你的项目就不可用了,显然不应该放到框架里。
自动化测试框架是和项目分离:因为它要给更多的人使用,并且不能轻易被修改,因此,它应该是独立安装的,不应该和项目代码混到一起。如果一个框架被使用者轻易的改来改去。请问,如何升级?使用者想体验新的版本怎么办?
自动化测试框架要有一些设计创新:我可不可以把selenium的get()方法改个名字叫open()封装到自己的框架里。当然可以,如果整个框架都是在把别人的API自己换个名字包一层,这和红芯浏览器有什么区别?
用于对 JavaScript 隔离测试 spy, stub 和 mock。unit.js是一个javascript断言库,该库可以在node.js与浏览器上运行。它适用于任何测试runner和单元测试框架,如mocha、jasmine、karma、protractor(角度应用程序的E2E测试框架)、qunit等。
Unit.js支持依赖注入,并且可以扩展为一个认证系统的插件。这使Unit.js学习曲线非常短。
为了使用户按自己喜欢的方式编写单元测试,unit.js提供了一个很棒的API。
对于jsUnit来说,其setUp和tearDown方法与Junit的运行原理是不同的,JUnit中的setUo和tearDown之间是没有关系的,也就是说不同的测试方法运行在不同的测试对象之中,而jsUnit的各个测试函数是运行在同一个测试页面中的。
项目地址:
https://unitjs.com/
Puppeteer 是一个node库,他提供了一组用来操纵Chrome的API, 通俗来说就是一个 headless chrome浏览器 (当然你也可以配置成有UI的,默认是没有的)。既然是浏览器,那么我们手工可以在浏览器上做的事情 Puppeteer 都能胜任, 另外,Puppeteer 翻译成中文是”木偶”意思,所以听名字就知道,操纵起来很方便。
Headless Chrome这个功能非常适合运行前端浏览器测试。对于UI自动化测试,少了真实浏览器加载css,js以及渲染页面的工作。无头测试要比真实浏览器快的多。
Headless Chrome可以在无界面的服务器或CI上运行测试,减少了外界的干扰,使自动化测试更稳定。在一台机器上可以模拟运行多个无头浏览器,方便进行并发测试。
Headless Chrome正在迅速取代PhantomJS。随着Google在Chrome 59版本放出了headless模式,作者决定放弃对Phantom.js的维护
Puppeteer是由Chrome团队开发的node库,可以通过DevTools Protocol控制无头版(或完全版)chrome和chromium的高级API库。
Puppeteer应用可以获取网页截图/生成PDF。从网站抓取你需要的内容;自动表单提交,UI测试,键盘输入等;创建一个最新的自动化测试环境。使用最新的JavaScript和浏览器功能,直接在最新版本可以查看。Chrome中运行测试。捕获您的网站的时间线跟踪,以帮助诊断性能问题。
Jasmine是一个针对JavaScript的行为驱动开发的测试框架,不依赖于任何其他的JavaScript框架或者文档对象模型(DOM)。它拥有清晰和简洁的语法,可以帮助开发者很容易地写测试。
Jasmine中的describe方法标志着一个测试集(test suite)的开始,这个方法有两个参数,一个字符串String,一个方法function;字符串用来描述这个test suite的测试内容,function里的内容就是测试代码,也就是suite。
Jasmine的It方法和describe方法类似, 同样有两个参数,一个String,一个function;String用来描述测试点(spec),function是具体的测试代码。一个测试点 (spec)可以包含多个expections。
Expect:全部的断言返回true,这个测试点就通过,一个或者多个断言返回false这个测试点就不通过。Matchers:Matchers方法返回true或者false,它决定着某一个测试点(spec)是否通过。
Mocha 是运行在 Node.js 和 browser 上的功能丰富的 JavaScript 测试框架,使异步测试变得简单而有趣。Mocha 串行运行测试,提供灵活精准的报告,同时将未捕获的异常映射到正确的测试用例。
单独写一个test.js的缺点是没法自动运行测试,而且,如果第一个assert报错,后面的测试也执行不了了。mocha是JavaScript的一种单元测试框架,既可以在浏览器环境下运行,也可以在Node.js环境下运行。
mocha相当的容易上手和好用,单元测试框架其实都差不多,它可以用于写测试用例的宏,属性或者函数;也可以当做断定库, 用于测试是否可以通过;当做辅助库时,如hook库(测试前后调用某些函数或者方法),异常检查(某些函数在某些参数的情况下抛出异常), 输入组合(支持多排列的参数输入组合)等。
使用mocha时我们就只需要专注于编写单元测试本身,然后,让mocha去自动运行所有的测试,并给出测试结果。更好的脱离了对开发人员的依赖,是一个更加独立的测试框架。
mocha既可以测试简单的JavaScript函数,又可以测试异步代码,因为异步是JavaScript的特性之一;可以自动运行所有测试,也可以只运行特定的测试;并且支持before、after、beforeEach和afterEach来编写初始化代码。
官方文档:
https://mochajs.org/
TDD 是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD 的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么功能代码。
TDD 的基本思路是通过测试来推动这个开发的过程,但测试开发并不是单纯的测试工作,而是把 需求分析,设计,质量控制量化的过程。
TDD 的目的不仅仅是测试软件,保证代码质量仅仅是其中的一部分,更重要的是,在开发过程中帮助开发者除去模糊不清的需求。
TDD 意味着持续测试,持续重构,能够提升团队代码质量, 让我们对自己的代码充满信心,简单来说,就是给开发者一种安全感,TDD过程涉及在编写代码之前编写单元测试。 对于开发人员来说,这意味着您必须在编写任何特定算法来解决问题之前就知道代码的行为。让开发人员永远知道这一步在做什么下一步需要做什么。有清晰明了的思路,可以大幅度减少返工的可能性。
TDD流程不会阻止您重构代码并最大化将投入生产的代码的效率。 它也不会排除通常的代码审查过程,甚至可以说您可以随时随地审查自己的代码(通过良好的质量测试,可以清楚地知道您的代码是否具有适当的质量)。
TDD 的存在主要是确保两件事:确保所有的需求都能被照顾到。在代码不断增加和重构的过程中,可以检查所有的功能是否正确。
虽然TDD的优缺点看起来相当平衡。 但是,如果你更深入地去了解,就会发现平衡是在软件质量上,一个团队在软件开发的早期就对此进行了投资,而不是在相当长的周期结束后进行维护。
测试驱动开发(Test-Driven Development,TDD)是一种敏捷(AGILE)开发方法论,它把开发流程倒转了过来,在进行代码实现之前,首先保证编写测试用例,从而用测试来驱动开发(而不是把测试作为一项验证工具来使用)。
karama是一个基于node.js的javascript执行过程的管理工具(test runner),该工具可以用于测试目前主流的浏览器(web brower),也可以集成到对应的CI(continue Integeration)工具中,其强大之处可以监控(watch)文件的变化,然后自行执行。通过console.log显示测试结果。
Karma能让基于测试驱动开发(test-driven development,TDD)的流程更加简单、快速,并且有趣。它使用NodeJS和SocketIO(http://www.socket.io)来运行代码,并且可以在多种浏览器中极其快速地进行测试工作。
karma是一个测试runner,它需要测试框架。并且karma 支持多种语言;karma 支持多种测试框架;karma 能够模拟多种真实的浏览器环境; karma 可以监听文件的变化; karma 支持语法的预编译。
对于前端而言,javaScript 和 node 就够了。所以mocha 测试框架就够了。同时mocha也可以运行在浏览器上。对于mocha 而言,需要配置html,才能运行在各个浏览器上。配置mocha 相对复杂,繁琐一点,所以我们选择框架是karma + mocha。
Jest可以让代码库更加稳定和健壮。jest。它是facebook开源的一个测试框架,自己一个人就干了上面组合的活,稍微配置一下就可以用,比较方便。至于性能,笔者没有太深入的进行过比较,所以也没有什么发言权。jest流行的另一个原因是react的流行,jest + enzyme来测试react组件是目前最流行的组合。
Jest 是 Facebook 的一套开源的 JavaScript 测试框架,它自动集成了断言、JSDom、覆盖率报告等开发者所需要的所有测试工具,是一款几乎零配置的测试框架。
Jest会自动找到项目中所有使用.spec.js或.test.js文件命名的测试文件并执行,通常我们在编写测试文件时遵循的命名规范:测试文件的文件名 = 被测试模块名 +.test.js,例如被测试模块为functions.js,那么对应的测试文件命名为functions.test.js。
在测试中,有时需要精准区分 undefined 、null 和 false,有时 又不需要区分,jest 都满足。
Jest为我们提供了expect函数用来包装被测试的方法并返回一个对象,该对象中包含一系列的匹配器来让我们更方便的进行断言,上面的toBe函数即为一个匹配器。我们来介绍几种常用的Jest断言,其中会涉及多个匹配器。
vue-test-utils是vue官方的单元测试框架,改测试框架提供了一系列非常方便的工具,使使用者可以更轻松地为vue构建的应用来编写单元测试。虽然现在主流的JavaScript测试运行器有很多,但vue-test-utils全部都能支持。vue-test-utils是与测试运行器无关的。
Jest 是功能最全的测试运行器。它所需的配置是最少的,默认安装了 JSDOM,内置断言且命令行的用户体验非常好。不过开发者需要一个能够将单文件组件导入到测试中的预处理器。虽然已经创建了 vue-jest 预处理器来处理最常见的单文件组件特性,但仍不是 vue-loader 100% 的功能。
vue-test-utils在Vue和Jest之间提供了一个桥梁,能够暴露出一些接口,也能够更加方便地通过Jest为Vue应用编写单元测试。
单元测试(unit testing),单元测试是最小巧也是最简单的测试——它们通过隔离单个组件的每一个部分,来在最小工作单元上进行断言。单元测试是指对软件中的最小可测试单元进行检查和验证。简单来说,单元就是人为规定的最小的被测功能模块,可能是一个单一函数或方法、一个完整的组件或类。
Vue Test Utils 通过将它们隔离挂载,然后模拟必要的输入 (prop、注入和用户事件) 和对输出 (渲染结果、触发的自定义事件) 的断言来测试 Vue 组件。被挂载的组件会返回到一个包裹器内,而包裹器会暴露很多封装、遍历和查询其内部的 Vue 组件实例的便捷的方法。
YOLO,是目前速度更快的物体检测算法之一。虽然它不再是最准确的物体检测算法,但当您需要实时检测时,它是一个非常好的选择,而不会损失太多的准确性。YOLO(You only look once):将物体检测重新绘制作为一个简单的回归问题,直接从图像像素生成bounding box的坐标和类的预测。
YOLO的前向测试为:将一张图片送入YOLO网络后网络输出检测结果的整体流程。从上述的代码结构中我们可以发现,网络最终的输出是一个1470维的向量。YOLO:是一个简单的卷积网络,同时预测多个boundingboxes和这些boxes所属的类。
YOLO在准确性方面仍落后于最先进的检测系统。 虽然它可以快速识别图像中的物体,但它正努力精确定位某些物体,尤其是小物体。我们在实验中进一步检查了这些折衷。YOLO使用整幅图像的特征去预测每个boundingbox,并且同时它也预测图像中所有bounding boxes中所有类别。
YOLO 检测物体非常快。因为没有复杂的检测流程,只需要将图像输入到神经网络就可以得到检测结果,YOLO 可以非常快的完成物体检测任务。标准版本的 YOLO 在 Titan X 的 GPU 上能达到 45 FPS。更快的 Fast YOLO 检测速度可以达到 155 FPS 。而且,YOLO 的 mAP 是之前其他实时物体检测系统的两倍以上。
YOLO 可以很好的避免背景错误,产生 false positives。不像其他物体检测系统使用了滑窗或 region proposal,分类器只能得到图像的局部信息。YOLO 在训练和测试时都能够看到一整张图像的信息,因此 YOLO 在检测物体时能很好的利用上下文信息,从而不容易在背景上预测出错误的物体信息。和 Fast-R-CNN 相比,YOLO 的背景错误不到 Fast-R-CNN 的一半。
YOLO 可以学到物体的泛化特征。当 YOLO 在自然图像上做训练,在艺术作品上做测试时,YOLO 表现的性能比 DPM、R-CNN 等之前的物体检测系统要好很多。因为 YOLO 可以学习到高度泛化的特征,从而迁移到其他领域。
NUnit一款单元测试框架,它可以应用于遵循.NET框架标准的所有语言下。NUnit最初是从JUnit移植过来的。NUnit完全使用C#编写且设计时考虑了多数.NET语言的特性,例如自定义属性和其它反射特性。
nunit需要新建一个类库的项目,然后引用你要测试的项目和nunit框架程序集nunit.framework.dll,这样就可以开始自己的测试代码了。
项目地址:
https://nunit.org/
“我所在的公司目前就我一个测试,我一个人对接开发,对接产品,公司也没什么流程,我不知道我该做什么,也没有前人经验可以借鉴,我该怎么办?”
最近看到有很多刚刚步入测试行业的测试工程师发出这样的疑问和求助,公司如果只有我一个测试员,我该怎么做才能把公司的工作做好呢?对于我个人发展来说,只有我一个测试,能有很好的发展前景么?到底,这种情况下我该走还是该留呢?
有人可能会说:就我一个测试?啊?怎么办啊?好可怕啊,就我一个测试啊,出了问题问谁啊,团队内部的锅甩不出去了呀,开发不得把我欺负死啊,这么多测试项都我一人测啊,累死我得了啊…
但是也会有人说:就我一个测试?哎呀好爽啊,这个团队我说了算吧,我终于可以当权威了吧,我的技术最牛了吧,还有人跟我抢任务吗,哈哈哈哈,老子天下第一啊…
其实有利也有弊,重点在于你自身心态,但是弊端确实是赤裸裸摆在眼前的无助感,因为公司只有你一个测试工程师,是不会有任何规范的流程的,都是各部门的人根据自己的想法和意愿来开展工作。比如,开发编程完成之后,直接发个包给测试员进行测试,没有需求规格说明书来详细描述这个项目的业务流程和用户需求;开发也没有流程来规范自己的单元测试,所以仅仅凭借自觉和个人使命感,很难要求他们每个人做到位,更别说提供相关的单元测试报告;所以测试并没有写测试用例的依据和基准,只能自己一边熟悉开发给的软件,一边根据自己的理解来写测试用例,这样测试工作不仅效率很低,而且也容易导致测试用例设计不充分和测试不彻底的问题。
另外,开发对测试工作也没有认同感,经常连续修改或者新增加需求,然后直接给版本到测试,测试基本都是按照开发的节奏来开展工作,测试工作完全没有自主性。经常,测试花了很多时间和努力测试产品,开了很多bug,开发并不会很积极的修复bug,当然也没有流程来推动bug的修复,自己一个基础测试员孤立无援,人微言轻,也说服不了开发,沟通效率很低,成果很差。
甚至,有时候,还没有等测试完成所有的测试工作,软件产品已经默默的上线了,自己也没有被通知。然后线上产品出了严重的问题,又会找到测试,要测试来承担后果和责任。任何事情,好像都跟测试没有真正的关系,深觉自己的工作没有人重视,也没有人理解,感觉很被动,很无助。!