We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在项目开发过程中,项目开发流程中程序员编码过后就是测试工程师对项目进行测试,测试包括很多中:功能测试、性能测试、安全测试、特性测试等等,而对于我们开发工程师来说,许多地方的测试,测试工程师是覆盖不到的,比如我们每个功能的单元测试,我们项目的性能测试等等,所以这些东西需要我们开发工程师自己来测试自己的代码,才能让自己的代码更可靠有效的跑在线上。因此,开发工程师的测试能力同样也是项目有中至关重要的一部分。
测试可以保证代码的以下特性
测试代码可以验证代码的正确性,在上线前做到心里有底
当然手工也可以测试,通过console可以打印出内部信息,但是这是一次性的事情,下次测试需要从头再来,效率不能得到有效保证。通过编写测试用例,可以做到一次测试多次运行。
测试用例用于测试接口、模块的重要性,那么在测试用例中就会涉及如何使用这些API。其他开发人员如果要使用这些API,那阅读测试用例是一种很好地途径,有时比文档说明更清晰。
代码被测试的前提是代码本身的可测试性,那么要保证代码的可测试性,就需要在开发中注意API的设计,TDD将测试前移就是起到这么一个作用。
互联网行业产品迭代速度很快,迭代后必然存在代码重构的过程,那怎么才能保证重构后代码的质量呢?有测试用例做后盾,就可以大胆的进行重构。
对于我们前端开发工程师来说,测试的主要在于,代码功能测试,性能上的测试及安全测试,因此前端需要关注的测试有以下几种:
单元测试能够让开发者明确知道代码结果
单一职责、接口抽象、层次分离。
单元测试保证每一个function是最小的一个单元化,尽可能的抽离抽象的代码。(每一个function:也可能是一个component或者一个模块)
##### 断言库
断言库是保证最小单元化是否正确运行的检测方法。常用的断言库有:
测试风格分为两种:一种是测试驱动开发(Test-Driven Development,TDD),一种是(Behavior Driven Development,BDD)行为驱动开发。这两种测试风格都是敏捷开发方法论。
特别注意的是:TDD为测试先行,BDD为测试后行
##### 单元测试流程
自动化单元测试通过karma来完成,karma所集成的有chrome无界面浏览器(把浏览器嵌入终端),通过自动化runner几重PhantomJS无刷新。
//npm install -g karma //安装karma包 //npm install karma-cli --save-dev //安装karma对应的客户端 //npm install karma-chrome-launcher --save-dev //chrome配合karma的一个平台 //npm install karma-phantomjs-launcher --save-dev //与上面一起做一个黑盒的浏览器,这是黑盒浏览器核心的文件,上面是对向上进行的一次包裹 //npm install karma-mocha --save-dev //异步的框架库 //npm install karma-chai --save-dev //断言库
通过karma-coverage可以导出测试报告,测试报告中包括测试每一项的覆盖率问题,可以反映出测试是否全面。
npm install karma-coverage --save-dev 配置:coverageReporter:{type:'html',dir:'coverage/'}配置代码覆盖率测试生成结果
基准测试使用面向切面编程(AOP)实现无侵入式统计。
它并不是简单地统计执行多少次测试代码后对比时间,它对测试有个严密的抽样过程。执行多少次取决于采样到数据能够完成统计根据统计次数计算方差。
压力测试对网络接口做压力测试需要检查的几个常用指标有吞吐率、响应时间和并发数,这些指标反映了服务器并发处理能力。
PV每天几十万甚至上百万就需要考虑压力测试。换算公式QPS=PV/t(ps: 1000000/10 * 60 * 60 = 27.7(100万请求集中在10个小时,服务器每秒处理27.7个业务请求))
ab -c 100 -n 100 http://localhost:8001 //每秒持续发出28个请求
XSS分为三类:Stored XSS、Reflected XSS、Dom-Base XSS
例如1:在一个网站的一些留言板或者新闻等可以输入的地方,输入一下代码: <script>alert(document.cookie)</script> 或者其他功能更强大的js
Reflected XSS 即反射跨站脚本攻击,这是最常见的攻击方式。所谓反射,就是等着服务器所给的返回。我们在进行测试时依据的就是在自己页面上的简单注入。在web客户端提交了数据后,服务端马上给这个请求生成返回结果页,如果结果中包含了未验证的客户端输入数据,那就表示会允许客户端脚本直接注入到页面里,也就出现了这样一个漏洞。简单举个例子,在搜索引擎里边,我们如果搜索了一个包含html代码的字符串,如果返回的字符串仍然没被编码,那么搜索的内容就不是整个html代码了,而是只想过这个html代码,那就是存在XSS漏洞了。
Dom-Base XSS 即基于DOM的XSS攻击,它是修改页面DOM节点数据信息而形成的XSS跨站脚本攻击,该漏洞多见于客户端脚本,意思就是如果一个js访问需要参数的url,并且需要把信息作用于自己当前的页面,信息又未被编码,就会出现该漏洞。
表示用户可以提交一段数据库查询代码,根据程序返回的结果,获得某些他想得知的数据,这就是所谓的SQL Injection,即SQL注入。
CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。
你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于**商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全
CSRF这种攻击方式在2000年已经被国外的安全人员提出,但 在国内,直到06年才开始被关注,08年,国内外的多个大型**和交互网站分别爆出CSRF漏洞,如:NYTimes.com(纽约时报)、 Metafilter(一个大型的BLOG网站),YouTube和百度HI......而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称 CSRF为“沉睡的巨人”。
//selenium-webdriver //自动化测试工具 //protractor selenium-standalone //angular的自动化测试工具 //http://webdriver.io/ WEBDRIVERI/O
这是自由测试的一种,找到一个BUG开发修复,然后专门针对此BUG。优点:节省时间防止build失败,缺点:覆盖率极低。
修改一处对整体功能全部测试,一般配合自动化测试。
初学测试,并且是未接触的东西,作为前端er还是要对测试有了解的,以后自己理论得到提升会继续补这个理论篇。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
javascript与QA工程师(理论篇)
在项目开发过程中,项目开发流程中程序员编码过后就是测试工程师对项目进行测试,测试包括很多中:功能测试、性能测试、安全测试、特性测试等等,而对于我们开发工程师来说,许多地方的测试,测试工程师是覆盖不到的,比如我们每个功能的单元测试,我们项目的性能测试等等,所以这些东西需要我们开发工程师自己来测试自己的代码,才能让自己的代码更可靠有效的跑在线上。因此,开发工程师的测试能力同样也是项目有中至关重要的一部分。
为什么要进行测试
测试可以保证代码的以下特性
1、正确性
测试代码可以验证代码的正确性,在上线前做到心里有底
2、自动化
当然手工也可以测试,通过console可以打印出内部信息,但是这是一次性的事情,下次测试需要从头再来,效率不能得到有效保证。通过编写测试用例,可以做到一次测试多次运行。
3、解释性
测试用例用于测试接口、模块的重要性,那么在测试用例中就会涉及如何使用这些API。其他开发人员如果要使用这些API,那阅读测试用例是一种很好地途径,有时比文档说明更清晰。
4、驱动开发,指导设计
代码被测试的前提是代码本身的可测试性,那么要保证代码的可测试性,就需要在开发中注意API的设计,TDD将测试前移就是起到这么一个作用。
5、保证重构
互联网行业产品迭代速度很快,迭代后必然存在代码重构的过程,那怎么才能保证重构后代码的质量呢?有测试用例做后盾,就可以大胆的进行重构。
前端er的测试
对于我们前端开发工程师来说,测试的主要在于,代码功能测试,性能上的测试及安全测试,因此前端需要关注的测试有以下几种:
单元测试
目的
单元测试能够让开发者明确知道代码结果
原则
单元测试保证每一个function是最小的一个单元化,尽可能的抽离抽象的代码。(每一个function:也可能是一个component或者一个模块)
##### 断言库
断言库是保证最小单元化是否正确运行的检测方法。常用的断言库有:
测试风格
测试风格分为两种:一种是测试驱动开发(Test-Driven Development,TDD),一种是(Behavior Driven Development,BDD)行为驱动开发。这两种测试风格都是敏捷开发方法论。
单元测试框架
##### 单元测试流程
自动化单元测试
自动化单元测试通过karma来完成,karma所集成的有chrome无界面浏览器(把浏览器嵌入终端),通过自动化runner几重PhantomJS无刷新。
报告和单侧覆盖率检查
通过karma-coverage可以导出测试报告,测试报告中包括测试每一项的覆盖率问题,可以反映出测试是否全面。
性能测试
基准测试
基准测试使用面向切面编程(AOP)实现无侵入式统计。
Benchmark基准测试方法
它并不是简单地统计执行多少次测试代码后对比时间,它对测试有个严密的抽样过程。执行多少次取决于采样到数据能够完成统计根据统计次数计算方差。
压力测试
压力测试对网络接口做压力测试需要检查的几个常用指标有吞吐率、响应时间和并发数,这些指标反映了服务器并发处理能力。
常见的压力测试工具:ab、sieg、http_load
db测试方法
安全测试
XSS
XSS分为三类:Stored XSS、Reflected XSS、Dom-Base XSS
即存储式跨站攻击,存储式跨站攻击简单来说就是攻击者提交给网站的数据会提交并永久保存到服务器的数据库或者是文件系统等其他地方,之后不做任何编码操作就会显示在web页面上。这是最厉害的攻击方式。这种攻击方式影响比较大,影响的用户范围广
Reflected XSS
即反射跨站脚本攻击,这是最常见的攻击方式。所谓反射,就是等着服务器所给的返回。我们在进行测试时依据的就是在自己页面上的简单注入。在web客户端提交了数据后,服务端马上给这个请求生成返回结果页,如果结果中包含了未验证的客户端输入数据,那就表示会允许客户端脚本直接注入到页面里,也就出现了这样一个漏洞。简单举个例子,在搜索引擎里边,我们如果搜索了一个包含html代码的字符串,如果返回的字符串仍然没被编码,那么搜索的内容就不是整个html代码了,而是只想过这个html代码,那就是存在XSS漏洞了。
Dom-Base XSS
即基于DOM的XSS攻击,它是修改页面DOM节点数据信息而形成的XSS跨站脚本攻击,该漏洞多见于客户端脚本,意思就是如果一个js访问需要参数的url,并且需要把信息作用于自己当前的页面,信息又未被编码,就会出现该漏洞。
SQL注入
表示用户可以提交一段数据库查询代码,根据程序返回的结果,获得某些他想得知的数据,这就是所谓的SQL Injection,即SQL注入。
CSRF
什么是CSRF
CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。
CSRF可以做什么?
你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于**商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全
CSRF漏洞现状
CSRF这种攻击方式在2000年已经被国外的安全人员提出,但 在国内,直到06年才开始被关注,08年,国内外的多个大型**和交互网站分别爆出CSRF漏洞,如:NYTimes.com(纽约时报)、 Metafilter(一个大型的BLOG网站),YouTube和百度HI......而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称 CSRF为“沉睡的巨人”。
CSRF的原理
功能测试
用户的真实性检查
测试工具
冒烟测试SmokeTest
这是自由测试的一种,找到一个BUG开发修复,然后专门针对此BUG。优点:节省时间防止build失败,缺点:覆盖率极低。
回归测试
修改一处对整体功能全部测试,一般配合自动化测试。
QAQ
The text was updated successfully, but these errors were encountered: