1. Web前端站点有哪些功能测试的方法
有些测试方法的界限比较模糊，比如功能测试的同时会穿插一些兼容性和安全性的测试，以下列出简单的一些点，可以参考下：
1、该页所提供的功能逻辑方面有无问题；
2、各输入项的合法性测试、输入顺序；(是否只做了前端的js验证)
3、该页权限，既无访问权限的用户能否直接访问该页；
4、不同浏览器下该页的显示；
5、该页链接的参数是否可以修改，对功能的影响；
7、多个页面打开该页，进行操作，是否有不合法的影响；
8、网络环境异常情况下系统的处理；
9、页面链接是否正确；
10、cookies测试；
2. 接口测试的测试点有哪些
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
测试的策略：
接口测试也是属于功能测试，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：
评审测试接口文档（需求文档）
根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）
执行测试，查看不同的参数请求，接口的返回的数据是否达到预期
接口的功能是否正确实现了
接口是否按照设计文档中来实现（比如username参数写为了user，那么这就不符合，因为接口文档在整个开发中都需要使用，所以接口实际的设计要与接口设计文档中保持一致）
兼容性测试： 比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式
错误码测试： 通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
返回值测试： 返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析
参数边界值、等价类测试
json格式测试： 通常我们的接口一般设计的都是传递json串，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code
默认值测试： 很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。
是否有依赖业务，比如查看订单，是需要用户首先登录的，所以肯定要保证登录了或有相应的cookie
业务逻辑测试： 传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作
关键字参数：将参数写为开发语言中的关键字
参数为空：比如去掉了username参数
多或少参数：多或者少参数的验证，现在还不确定如果一个接口多了参数如果没有报错是否是合理的，或者是否需要优化，因为就目前开发给予的答案是，一般不对接口多了参数的处理
错误参数：比如将username参数写为了user等看是否能返回相应的errorcode
关键字数据：将参数的值填为开发语言中的关键字
数据为空：将参数的额值填为空
长度不一致：因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证
错误数据：就是将参数的值任意填写，或填写不存在的数值
异常类型测试： 比如count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断
响应时间
吞吐量
并发用户数
占用内存，CPU等
敏感信息是否加密
必要参数是否后端也进行校验（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证）
接口是否防恶意请求（SQL注入）
cookie：就是将header中的cookie修改或删除后看是否能返回相应的errorcode
header：就是删除或修改header中部分参数的值，看是否能返回相应的error code
唯一识别码：删除修改唯一识别码测试
那么设计测试用例时我们主要考虑如下几个方面：
功能测试：
逻辑业务：
异常测试：
异常分为两类，参数异常和数据异常
参数异常：
数据异常：
性能测试：
安全性测试：
3. 浏览器中输入什么测试应用
是指不同浏览器使用内核及所支持的 HTML 等网页语言标准不同，用户客户端的环境不同造成的显示效果不能达到理想效果。对于用户而言，无论使用哪款浏览器，期望看到的效果是正常的统一的。
市面上发布的浏览器版本非常之多，碍于测试环境和人力资源的不足，要想做到全面的兼容性测试很难。如何进行高效的浏览器兼容性测试，对于前端开发人员还是测试工程师来说，都算得上一个头疼的问题。
为此，我们可以在多台计算机或者多台虚拟机上部署不同浏览器进行测试，但这种方法会造成一定的资源浪费、或存在卡顿情况。为提高测试效率，可以利用一些浏览器兼容性测试工具来完成测试工作。以下介绍 8 款浏览器兼容性测试工具，可以依据自己需求选择，有需要的欢迎收藏！【点击领取：测试进阶资料传送门】
4. 前端开发ie浏览器的兼容问题怎么解决
所谓的浏览器兼容性问题，是指因为不同的浏览器对同一段代码有不同的解析，造成页面显示效果不统一的情况。在大多数情况下，我们的需求是，无论用户用什么
浏览器来查看我们的网站或者登陆我们的系统，都应该是统一的显示效果。所以浏览器的兼容性问题是前端开发人员经常会碰到和必须要解决的问题。
在学习浏览器兼容性之前，我想把前端开发人员划分为两类：
第一类是精确按照设计图开发的前端开发人员，可以说是精确到1px的，他们很容易就会发现设计图的不足，并且在很少的情况下会碰到浏览器的兼容性问题，而这些问题往往都是浏览器的bug，并且他们制作的页面后期易维护，代码重用问题少，可以说是比较牢固放心的代码。
第二类是基本按照设计图来开发的前端开发人员，很多细枝末节差距很大，不如间距，行高，图片位置等等经常会差几px。某种效果的实现也是反复调试得到，具体为什么出现这种效果还模模糊糊，整体布局十分脆弱。稍有改动就乱七八糟。代码为什么这么写还不知所以然。这类开发人员往往经常为兼容性问题所困。修改好了这个浏览器又乱了另一个浏览器。改来改去也毫无头绪。其实他们碰到的兼容性问题大部分不应该归咎于浏览器，而是他们的技术本身了。
5. 什么是兼容性测试兼容性测试侧重哪些方面
一、兼容性测试就是测试电脑硬件之间是否有不兼容等问题或软件问题。
二、兼容性测试侧重哪些方面
1、向前兼容和向后兼容。向前兼容是指可以使用软件的未来版本，向后兼容是指可以使用软件的以前版本。
2、不同版本之间的兼容。实现测试平台和应用软件多个版本之间能够正常工作。
3、 标准和规范
高级标准是产品应当普遍遵守的。若应用程序声明与某个平台兼容，就必须接受关于该平台的标准和规范。低级标准是对产品开发细节的描述。
4、数据共享兼容。数据共享兼容是指要在应用程序之间共享数据，要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据。
(5)前端兼容性测试扩展阅读：
软件的兼容性是衡量软件好坏的一个重要指标，在具体测试中可以从以下几个方面来判断：
1、操作系统兼容性 有些软件在不同的操作系统平台上重新编译即可运行，有些软件需要重新开发或是改动较大。
2、异构数据库兼容性 这类软件要考虑其对不同数据库平台的支持能力，软件是否可直接挂接，或需提供相关的转换工具。
3、新旧数据转换软件是否提供新旧数据转换的功能。
4、异种数据兼容性 可否完全正确地读出这些格式的文件
5、应用软件兼容性
6、硬件兼容性 硬件兼容性考察软件对运行的硬件环境有无特殊说明，
6. 苹果电脑做网站前端页面浏览器兼容性测试问题
网络建设公司很多，没有具体的衡量标准的。但是可以从几方面去选择：
1 有做了很多精明案例的
2 案例都是可以验证方法的
3 只做网站建设的，没有做别的业务的
4 做的比较久的。
7. 前端测试有哪几种类型
目前在软件系统开发中，测试是一个非常重要的环节，特别是前端测试，有几种类型的测试被认为是前端测试所必需的，让我们简单了解一下。
01
单元测试
在修复bug或添加一点功能时，软件的其他部分可能会停止工作。为了处理这种情况，单元测试将代码的各个部分分开，以单独检查其准确性。跳过或最小化单元测试可能会导致修复缺陷的成本增加。Javascript单元测试包括一个套件中有组织的测试数量，这些测试彼此不冲突，并且相互之间的依赖性更少。
02
端到端测试
端到端测试涵盖了应用程序从头到尾的流程，结束测试跟踪用户的旅程，如打开浏览器、导航，并体验完整的生产场景。端到端测试验证互连系统和软件系统，它包括一个完整的前端和后端系统。
03
集成测试
集成测试的目的是使模块/组件按预期运行。集成测试技术应用于许多模块紧密耦合的大型应用中，模块被单独测试，一旦集成，组合行为被验证，它是与开发并行进行的。在集成测试中，您需要更多的逻辑技能，因为在测试期间，某些模块可能尚未准备就绪或正在构建中。
集成时使用测试存根和驱动程序，集成测试将分析开发人员实现的逻辑是否遵循规定的标准。当模块与第三方API交互时，查看响应非常重要。当开发人员跳过单元测试时，集成测试就不可避免了。
04
功能测试
功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。
05
可视化/用户界面测试
视觉/UI测试包括屏幕截图的验证。这是一项质量保证活动，旨在确保屏幕在任何设备、屏幕分辨率、浏览器和操作系统上的外观与预期一致。通过无头浏览器中捕获的不同屏幕截图比较渲染版本的结果，可视化回归测试允许您检测偏差。
在构建应用程序时，事情会变得过载和复杂，这种情况很容易破坏现有的功能并引入新的bug—单元、行为和集成测试将到位，以使应用程序稳定。
06
性能/压力测试
性能测试是一种非功能性技术，它在各种工作负载下检查软件的稳定性、响应性、速度、可靠性和资源使用等系统参数。
压力测试：应用程序被重载以检查意外行为并了解其承受能力。
为网站执行一个高质量的前端测试将提高生产力，并增加客户对您的服务的依赖。了解趋势通用模式并结合专家经验来定义质量测试套装是很重要的。
07
跨浏览器测试
Web端应用测试主要障碍之一就是在不同的浏览器上“测试他们的网站/应用程序”，也称为“跨浏览器测试”或者“兼容性测试”。浏览器和浏览器版本很多（Google Chrome，Mozilla Firefox，Internet Explorer，Microsoft Edge，Opera，Yandex等），可以通过多种设备（通过台式机，笔记本，智能手机，平板电脑等）访问网站/应用。）以及可能用于访问网站的多种操作系统（Windows，MacOS，Linux，Android，iOS等）。
要确保网站的UI/UX及其功能正常运行，并且在“浏览器+浏览器版本+操作系统+设备配置”的组合上没有任何BUG，则将需要大量的开发，测试和维护工作。
8. UI测试、功能测试和兼容性测试
关于网站 测试 的几个小套路，希望对大家有所帮助。
因为所在团队没有专业测试人员，所以测试 工作 由我这个产品新人来负责。本文是抱着总结才能提升的小心思，想来简单写写从测试零经验到开发葛葛“谈心”的次数逐渐变少，这期间所踩过得坑和心得体会。
一、 UI测试
用户界面测试主要是拿待测网页和设计稿进行对比，个人觉得主要需做到以下4点：
1.注重细节：
这点最基本，就是对比时细心、细心再细心。像我现在被虐到网页上元素和设计稿差一个像素都能看出来…
2.勿忘整体性：
由于PC网页页面空间大，模块多，很容易在测试时只注意到模块内设计元素是否正确，而忽略了模块间的间距或整个页面的布局是否正确。所以最好按照由局部到整体的顺序测试。
3.注意页面间相互对比：
即注意相同系列页面、页签布局一致性。就是说的是同一系列页面中同类元素和模块的样式、间距一般要相同；同一个tab下，不同选项对应
的页签中同类元素和模块的样式、间距一般要相同。例如下图QQ空间-日志页面里我的日志和私密日记tab中，红框圈出的位置高度是否一致。
一般情况下这些不一致问题出现的情况不多，毕竟相类似的布局前端同学应该会用相同的盒子，但是测试时还是需要留意。
4.注意极端情况下显示情况：
即要注意长度可变的元件、模块或字段在极端情况下的显示是否正常。
例如： 文章 标题最多可显示50字符（25汉字），测试时就要在所有会出现标题的位置（文章列表页、推荐边栏、转发弹框…）是否能正常显示含有50字符的标题，会不会出现破框而出、自动切掉等情况。
由于UI测试时需要检查的细节很多，特别是像我们团队，网站还在搭建中并未上线，UI测试的工作量更是大，测久了难免会觉得枯燥繁琐，但其实每项任务都能总结出套路、有所收获，故下面仅列出我平时在测这部分时的主要注意点和心得。
UI测试注意点总结：
1、模块间距
2、元素间距
3、不同类型文本（数字、汉字、英文）颜色、格式（全角、半角）大小、字体、（不必须）
4、固定文案：内容的可读性、正确性?排版的合理性
5、可变字段：极多、极少文字的排版情况
6、Icon用错、用混
7、相似页面的差异性和一致性
小体会：
其实界面测试虽然没啥 技术 含量，但测久了就会发现自己对网页元素有时彼此间的间距差了1、2个像素，整体的视觉效果就尺寸和布局的敏感度有提升，例如像同样一组元素，会大有不同， web 是这样， 移动 端更是如此。
随手画张图举个栗子：左图网页做出来名称、作者、互动统计三者之间行距相等，中文字大小相
同，而设计稿原本应如右图，行距不同，不同字段的字号也不同。所以假如测试时遇到类似这种问题，我们除了可以提个bug，还会被引导去思考设计初衷，即利用间距细微差异进行视觉分组，利用字号细微差异突出主次。
二、 功能测试
1.操作反应：
（1） 页面元素（按钮、锚文本、输入框…）自身状态变化：鼠标移入/移出时效果、点击后效果、获取/失去焦点时效果…（可以想想axure里的用例状态）
eg：鼠标移入按钮，按钮是底色是否应改变；若输入框内有默认提示文字，则是当输入框获得焦点后文字就消失，还是用户输入文字后提示文字才消失…
（2）操作成功后续反应：页面跳转、弹框、提示文字…
a.页面跳转：
页面切换方式：另开页面、本页切换
页面起始定位：页面起始位置、页面其他锚点（例如用户想评论某文章，在列表页点评论按钮后，就会在另开的文章内容页直接定位到评论区）
b.弹框：
匹配情况：弹出的弹框是否和触发条件匹配
出现位置：一般情况下要一致。因为弹框使用不同插件，可能导致弹出位置不同。
显示时间（非操作类弹框）：某些仅起到提示功能的弹框会自动显示若干秒关闭。一般情况此类弹框上文案较少，显示秒数应该是全站一致的。
c.提示文字：
匹配情况：出现的提示文案是否和触发条件匹配
关于操作成功后续反应，以上主要是在已确定会触发某反应情况下，测试其正确性。其实这里更重要的是要考虑在前置条件不同的情况下，对某元素进行相同操作，会触发什么不同的反应。即需要对各类情况进行穷举。
eg：点击关注按钮触发反应穷举：
a.未登录用户点击该按钮后效果；
b.已登录用户点击该按钮后效果（b1.未关注过对方、b2.已关注过对方、b3.自己关注自己）
穷举时可以参考PRD，但不要局限于PRD上列出的情况，毕竟有时也许PRD上会有小疏漏，要是程序员做的时候发现疏漏，就自己随手码了一个简易提示而忘记通知产品，而测试的时候也没触发到，等用户实际操作出来就会造成不佳的用户体验。
原文来自：http://www.51testing.com/html/10/n-3714410.html
9. 想问下前端需要考虑的兼容性浏览器有哪些
一、浏览器的占有率：
ie6 - 30.23%
ie7 - 4.8%
ie8 - 30.6%
ie9 < 1%
chrome - 13.99%
firefox - 7.17%
safari ~ 5%
其他 ~ 8%
从数据上可以看出chrome + firefox + safari + ie9是高端浏览器，ie8勉强算准高端吧。这样这部分占有率约57%(如果加上其他webkit内核的浏览器会更高一些) 已经大于ie6 + ie7，但是IE6兼容性还是要解决。
二、web前端主要这些兼容浏览器：
1，firefox是开源的浏览器内核，插件很齐全，是代码人员的爱宠。
2、IE浏览器，要在Windows中开发适合自己的浏览器，很多人都在用。
推荐：ie8以上，360安全浏览器
3、Google浏览器，是谷歌公司开发的网页浏览器，稳定性和安全性很好。
推荐：Google Chrome
4、Opera12.17及更早版本曾经采用的内核是Presto，Opera15及以后的版本采用Blink的内核。用于手机代码测试也很方便。
推荐：Opera15