1.京东/淘宝的手机销售榜（前4名 -- 手机品牌 --手机型号*3 --手机分辨率 -- 手机操作系统 --安卓版本号）
Apple
型号 : Iphone11
屏幕分分辨率: iphone11屏幕尺寸6.1英寸，分辨率是1792x828，对比度1400:1，是iphone11系列中分辨率最低的，
系统 : 搭载ios系统
ios版本号 : ios13
型号: Iphone12 Pro Max:
屏幕分分辨率: Phone 12 Pro Max采用一块6.7英寸1080P分辨率的屏幕，支持4K 60fps录制，IP68防水，搭载苹果A14仿生芯片，12pro max为2778*1284 像素分辨率
系统 : 搭载ios系统
ios版本号 : ios14
型号: iPhone 12 mini
屏幕分分辨率 : iPhone 12 mini采用一块5.4英寸的屏幕，支持4K 60fps录制，IP68防水，搭载苹果 A14 仿生芯片,iphone12为2532*1170 像素分辨率
系统 : 搭载ios系统
ios版本号 : ios14
小米
型号:Redmi Note 8
屏幕分分辨率 :Redmi Note 8该款手机屏幕分辨率为：2340*1080 FHD+,对比度：1500:1(typ)
系统 : android
android版本: Android 9
型号: Redmi Note 8 pro
屏幕分辨率 : Redmi Note 8 pro 6.53英寸水滴全面屏最高可选分辨率：2340 x 1080 FHD,对比度：1500:1(typ)，NTSC：84%(typ)
系统 : android
android版本: Android 9
型号Redmi 8A
屏幕分辨率 : Redmi 8A 屏幕尺寸6.22英寸,屏幕分辨率1520×720像素手机尺寸156.5×75.4×9.4mm
系统 : android
android版本: Android 10
华为
型号:华为荣耀20 青春版
屏幕分辨率: 华为荣耀20 青春版屏幕达到7.09寸。2280*1080分辨率水滴屏，拥有双扬声器+侧边指纹。支持DCI-P3色域和最高780nit亮度。
系统 : android
android版本: Android 7
型号:华为畅享10 puls
屏幕分辨率: 华为畅享10 puls 屏幕尺寸：6.59英寸分辨率：FHD+ 2340*1080像素实际屏幕采用圆角设计，有效像素略少。
系统 : android
android版本: Android 9
型号:华为p40pro
屏幕分辨率:华为p40pro分辨率为2640x1200，不是2K屏。其搭载了一块6.58英寸的四曲面OLED 屏幕，刷新率为90Hz，支持DCI-P3广色域、HDR10+，色彩还原准确、真实丰满。
oppo
型号:oppo K7
屏幕分辨率: oppo K7 屏幕类型水滴屏多点触摸电容屏.屏幕大小6.44英寸.屏幕比列20:9.屏幕分辨率2400*1080像素
系统 : android
android版本: Android 9
型号: oppo A8
屏幕分辨率:oppo A8 屏幕大小：6.5英寸 ,屏幕分辨率1600x720像素89%全面屏
系统 : android
android版本: Android 10
型号: oppo Ace2 5G
屏幕分辨率:oppo Ace2 5G 屏幕分辨率2400×1080,屏幕大小为:6.55英寸,90Hz柔性直屏，180Hz触控采样率，峰值亮度1100尼特，康宁第5代大猩猩玻璃，色域：100% DCI-P3 100% RGB，500nit(亮度典型值)
系统 : android
android版本: Android 6
你以什么方式来进行对真机的成本降低 ?
1.租
2.借
3.二手
4.7天无理由退货
5.卖
6.云测 (如何建议老板使用那个平台)
给你一个app你如何展开测试？
1. 安装卸载
安装卸载路径是否能自己选择，在不同操作系统下（Android、ios）安装是否正常，能正常运行，安装的文件及文件夹是否写入了指定的目录里，安装来自不同来源的（应用宝、360助手）下是否正常。
卸载是否删除所有相关的文件
2.功能测试
每项开发的新功能都需要进行测试。app测试中功能测试是一个重要方面。测试人员应该要进行手动测试和后期的自动化测试维护。刚开始测试时，测试员必须把app当做"黑盒"一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮、提交订单看看会发生什么，测试员还必须执行更多功能的app测试。
运行、应用的前后台切换、免登录、数据更新、离线浏览、App更新、定位、启动相机服务。。根据软件说明看看提供的功能是否能正确并如设计的一样正常运作。
除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多自动化测试工具，有商业的也有开源的，面向各个不同平台，如Android，iPhone，WindowsPhone7，BlackBerry以及移动Webapp。根据开发策略和结构，品质管理测试专家需找出最适合他们环境的自动化工具。
3.客户端性能测试
一个app不仅仅表现在功能上，还要看在不同操作系统下，以及中低端机上的性能表现，
关于App性能测试，我们主要关注的参数有：CPU、内存、耗电量、流量、FPS（画面每秒传输帧数/刷新率）。同时也需要关注一下App安装耗时和启动耗时。
4.服务器性能测试
服务器性能测试，主要包含单机容量测试和24小时稳定性测试。
单机容量测试，可以检测到单机服务器在90%的响应时间和成功率都达标的前提下，能够承载多少用户量。
使用特定游戏模型压测24小时，服务无重启，内存无泄漏，并且各事务成功率达标。
5.UI测试
测试用户界面（菜单、对话框、窗口）等布局，文字正确，页面美观，操作友好，符合行业标准，易操作。
6.兼容性测试
在不同品牌手机上的安装、点击、卸载、运行。
在不同操作系统上的安装、点击、卸载、运行。
与本地及主流App是否兼容
我们在实际测试中，常常会遇到下列问题：
(a)在某个平牌某个系统上，app安装不上；
(b)在某个平牌某个系统上，app无法拉起；
(c)在某个平牌某个系统上，app拉起后无响应或拉起后黑屏、花屏；
(d)在某个平牌某个系统上，app无法顺利卸载；
7.安全测试
检测是否容易被外界破解，是否存在被恶意代码注入的风险，软件权限、安装与卸载安全、数据安全、通讯安全、人机接口安全性。
给你一个web端项目你如何展开测试？
测试分为 6 个部分：
1. 功能测试
2. 性能测试（包括负载/压力测试）
3. 用户界面测试
4. 兼容性测试
5. 安全测试
6. 接口测试
1 功能测试
1.1 链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
采取措施：采用自动检测网站链接的软件来进行。
推荐软件：
Xenu Link Sleuth 免费 绿色免安装软件
HTML Link Validator 共享（30天试用）
1.2 表单测试
当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3 数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。
1.4 cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。
采取措施：
1 采用黑盒测试：采用上面提到的方法进行测试
2 采用查看cookies的软件进行（初步的想法）
可以选择采用的软件
IECookiesView v1.50
Cookies Manager v1.1
1.5 数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
采取措施：暂时没有更好的测试方法
考虑结合到1.2和1.3的测试中
1.6 应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
采取措施：深刻理解需求说明文档
1.7 设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
暂时没有方法测试，可以多参考一点讨论组内的更新信息
2 性能测试
2.1 连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
2.3 压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。
每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?
长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
采取措施：采用测试工具WAS、ACT协助进行测试
3 用户界面测试
3.1 导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2 图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到 30k 以下
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。
3.3内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。
3.4 表格测试
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?
3.5 整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
采取措施：手动测试，参与人员最好有外部人员
4 兼容性测试
4.1 平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
4.2 浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
4.3 分辨率测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?
4.4 Modem/连接速率
是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。
4.5 打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。
4.6 组合测试
最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。
采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵
5 安全测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5.1 目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
5.2 SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
5.3 登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
5.4 日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
6 接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到
6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。
ANR----以及如何定位是前端问题还是后台问题？
ANR一般有三种类型：
1：KeyDispatchTimeout(5 seconds) --主要类型
按键或触摸事件在特定时间内无法得到响应
2：BroadcastTimeout(10 seconds)
BroadcastReceiver在的onRecieve运行在主线程中，短时间内无法处理完成导致
3：ServiceTimeout(20 seconds) --小概率类型
Service的各个声明周期在特定时间内无法处理完成
Anr场景分析
1.使用命令导出anr日志
adb pull/data/anr/traces.txt~/Desktop/
**2.分析关键信息
以每行的重点内容没准，每行自带时间戳
典型的分析情况
1.如果TOTAL的和接近100，有可能是因为当前使用的app占用的cpu太高，导致系统将你的杀死。
2.如果TOTAL很小，则说明线程被阻塞了，主线程在等待下条消息的进入，任务在等待时anr。
3.如果ioWait很高，则说明是io操作导致的
分析
因为主线程被阻塞导致的关键信息。
at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:119)
at android.os.Looper.loop(Looper.java:110)
io读写导致的anr
关键点：ioWait很高，ContentResolver in AsyncTask onPostExecute
1.首先看到total中ioWait很高，说明是io操作导致的。
2.具体原因
可以看到关键词sqlite，ContentResolver
在主线程进行了网络访问
关键词OSNetworkSystem.receiveStream，net
内存不足导致
可以看到TOTAL的使用率有98，所以内存不足。
广播阻塞导致anr
android.intent.action.SCREEN_OFF广播为order，即如果其中注册了此广播的任何应用在处理此广播时未返回，则会导致后续broadcast的失败，出现ANR，导致系统无法唤醒。而导致广播未被及时处理的原因，除了可能是由于对应的Receiver处理函数中一些操作长时间未完成外，也可能是由于整个应用进程被block了，从而没有机会去调用Receiver函数。
1.针对onRecieve中的耗时操作，可以将业务单独加入到一个线程中执行
快速定位anr
1.如果是ANR问题 ， 则搜索“ANR”关键词 。 快速定位到关键事件信息
2.如果是ForceClosed(程序强制关闭) 和其它异常退出信息，则搜索"Fatal" 关键词， 快速定位到关键事件信息 。
发现一个bug如何定位是前端还是后台问题？
后端的Bug，如何准确的定位问题在哪里，如何精准的描述Bug？
（1）查看报错日志
查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础，才能更好地定位问题。
（2）查看数据库的数据
了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。
（3）查看缓存（如Memcache、apc、redis等缓存）是否正确
现在来分析bug可能是前台还是后台：
case1：文本框输入不合法的内容，点击提交按钮， 如果不合法的内容提交成功， 那应该是前后台没有做校验， 前后台都有这个bug
case2：文本框输入合法的内容，点击提交按钮， 查看数据库中的数据和输入的内容不一致， 这个时候需要看前台传的数据是否正确，使用fiddler抓包， 查看请求头里面的数据是否和输入一致，如果一致就是后台的问题， 如果不一致，就是前台的bug
case3：界面展示不友好， 重复提交 这些都是前台的bug
前台定位方法：
前台bug定位：按F12在console中查看报错信息，对于出错的js可以在Sources下查看对应报错的资源文件，写入禅道提交给开发即可
前台bug注意以下三个方面：
（1）网站前台的权限控制：没有权限的用户是不能直接输入url的方式来进行访问的，必须进行登录。以后涉及到权限的测试，一定不能漏掉url的方式也需要验证一下。而在单个页面进行W3C测试时则需要去掉该权限控制。
（2）网站前台的title，对于这个也很容易忽视。进入到不同的功能页面，title显示应该是有，并且要和你进入的页面一致。title就是在浏览器最左上角看到的那些文字
（3）http和https的注意点：https是一种安全链接，它是需要证书的，而http就是普通链接，所以在你的系统中客户会要求某些关键的地方希望加上这种安全连接，那么此时你需要注意的是，对于不需要的安全链接的地方千万也要去重点测试，有些开发会很容易忽略这一点。
你要打开HTTPS开头的网站，前提是该网站安装了SSL证书，只有安装了SSL证书的网站，并且开启了443端口，你才可以通过HTTPS加密协议无访问。如果没有则不能访问。比如在某个网站http协议后面加个s去访问，看能否访问成功，能成功，会显示绿色安全小锁，否则就不能访问。给你举几个安装了ssl证书，可要https访问的网站，1号店，天猫，淘宝，支付宝，百度，沃通CA，工信部网站等等
前端bug主要分为3个类别：HTML,CSS,Javascript三类问题
给个最大的区别方式方法：
出现样式的问题基本都是CSS的bug
出现文本的问题基本都是html的bug
出现交互类的问题基本都是Javascript的bug
现在以淘宝的前端人员工作为例进行相关bug定位的剖析
判断前后台问题的区分方法：
F12, 打开错误控制台console
区分前后台交互：查看网络请求
a) Html中如果有链接，有相应的情况下，基本可以定位到是属于前端的问题
b) 如果为空，或者有出现error错误信息，我们就可以定位到属于后台开发的问题
TMS对应的VM模板，出现的一些截断控制，转换功能都属于前端的问题
一、HTML
最常见的HTML的问题—就是标签的问题了，最常见的排查和解决办法就是查看页面源代码，然后通过检查标签的工具，现在暂时提供idea.exe进行检查，有其他更好的工具再进行推荐。
常见问题类别：
标签闭合—表象，页面中出现大范围的混乱，就是少了标签的情况，导致标签未闭合
标签浮出—例如鼠标移动到文本位置，浮出全名的这种浮出形式都属于标签浮出的问题
标签在不同的浏览器的一种解析方式的不同导致的前端bug例如如下结构
该部分可以看做为一个大的框即是标签 内嵌标题的标签的一种形式，但在FF下可能解析为
的两行的形式从而导致前端在复古鞋/板鞋这块ing里面的格式产生混乱
结构可看为：
页面定点的问题：最明显的前端功能，在于点击某个链接将页面位置定位到对应的位置
a) 我们可以通过右键，查看元素的工具进行定位到毛点所定位到的位置，如果出现问题这种问题很直观，并且能通过这种方法直接定位到问题页面的跳转，也属于html的问题，大家在出现点击未跳转或者跳转方式不正确的问题，直接可以定位到跳转属性的问题，找到对应的跳转对应的块提供给开发人员即可
二、CSS，产生样式问题。例如：排版，布局，颜色，背景等
css的bug主要分为：兼容型bug 、业务性bug 和 内容型bug
兼容型bug
a) 表现：仅在少数几个浏览器上出现
b) 原因：浏览器的解析不一致
c) 解决：根据实际情况进行前端代码的通用性
d) 类别：
脚本兼容型问题：在出现对应交互的问题就基本可以定位到脚本兼容型bug，例如DIV的显示和层结构。实际可以参考聚划算的几个商品鼠标移动到小图的时候，对应大图展示的功能。
页面样式兼容型问题：直接表象在样式上，都是基于框架的页面展示错误，很容易定位业务性bug
a) 表现：在所有浏览器下都有该问题
b) 原因：对业务不熟悉
c) 解决：根据需求进行修改达到业务要求
该类型的定位，主要在和实现的要求不一致，最直接表现在页面的友好型，用户的可用性的bug，可以定位为该类型内容型bug
a) 表现： 前端自测正确，但在填入内容后，出现的错误，内容消失等
b) 原因： 扩展性未考虑周全
c) 解决： 进行overflow test
输入内容的长度限制等功能可定位为内容型bug
三、Javascript
最直接的判断方法，刷新页面，出现滞后显示的一些模块基本都为脚本的输出块。该部分的一些问题可以参照兼容型bug中类别的脚本兼容型bug。
有产生交互类的问题，大多数都可以定位到是属于javascript产生的问题，该部分大多不会报错有错误提示类的。页面左下方有出现javascript的错误提示；有弹出错误信息提示的bug；浏览器返回的一些错误弹出框都属于javascript的bug