PC、APP、H5三端测试的相同与不同
随着手机应用的不断状态，同一款产品的移动端应用市场占相较PC端也越来越大，那么app与PC端针对这些产品的测试有什么相同与不同之处呢？笔者总结如下：
首先谈一谈相同之处。。。
一，针对同一个系统功能的测试，三端所测的业务流程是一样的
二，一般情况下手机端和PC端都对应一套后台服务，比如说笔者公司所开发的互联网金融平台，整个平台做了分布式服务架构，后台服务包括用户服务、交易服务、产品服务等。PC和手机端测试以上三个流程时，调用的都是同一个后台服务。（注：也有一些功能，比如PC与手机端展示不一致，或者有什么特殊处理，这样情况下后台会写两套不同的接口来处理对应的业务需求）
不同之处
一，测试平台（容器）不同：
pc项目都是在电脑上进行测试的：常见的PC项目架构有BS架构和CS架构的，BS架构就是通过浏览器（browser）请求后台服务（server），后台返回到响应内容显示在浏览器上，常见BS架构的项目有天猫、京东等浏览器输入地址就可以访问。CS架构的项目比如QQ、微信等，需要在电脑下载客户端（client），客户端与后台服务器（server）进行数据传输交互。基于以上信息，PC端测试都是在电脑上，要么是在浏览器上测试要么安装对应客户端。平台都是电脑
app测试平台分为安卓和IOS端：安卓测试需要在安卓手机上安装开发提供的apk测试包；IOS测试需要将手机UUID提供给开发安装ipa测试包进行测试
H5测试就是测试HTML5页面：在PC或者手机浏览器都可以直接访问H5页面
二，兼容性测试不同：
基于以上测试平台的不同，三端的兼容性也不一样。
PC的兼容性主要包括各浏览器和不同操作系统，目前笔者所经历的公司主要测试了不同主流版本浏览器的兼容性，还未涉及操作系统层面
APP的兼容性包含安卓和IOS不同机型，不同版本，不同屏幕都要适配
H5的兼容性主要测试手机端的不同浏览器的兼容性
三，系统架构不一样
PC和H5端项目尤其是WEB项目对应一个后台服务，所有客户访问的都是同一个后台。上线测试时，直接访问线上地址测试即可
APP测试虽然对应了一个后台，但是不同的用户可能下载了不同版本的客户端，上线测试时，需要兼容每个版本的测试。
四，发布流程不同：
PC端每次更新发布，需要将测试通过的包替换线上包，重启服务后立刻生效，访问的就是最新的环境
H5由于是一些html5网站发布上线后无需重启即可访问
APP端需要向应用市场发布，安卓发布的市场有很多，应用宝、豌豆荚、应用商店等每个应用都需要单独审核；IOS端应用比较单一就是appstore。从提交、审核到发布会有几天的时间间隔，开发的应用包不会立刻发布。
五，专项测试
除以上不同外，app端还有一些专项测试：
性能方面：响应时间、流量测试和耗电量测试
安装测试（PC端web项目不用测试，CS架构的也需要考虑）
交叉测试：就是在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件
操作类型：手势测试、横屏竖屏
网络测试：包含弱网和网络切换测试，重点要考虑回退和刷新是否会造成二次提交。弱网络的模拟，据说可以用360wifi实现设置。
升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了
HTTPS和HTTP的区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
二、下面是详细的测试点：
需求测试： 查看电梯使用说明书、安全说明书等
界面测试： 查看电梯外观
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。
4.报警装置是否可用。
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。
8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
9.是否有手机信号
可靠性：
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。
3.点击当前楼层号码
4.多次点击同一楼层号码
5.同时按上键和下键
易用性：
电梯的按钮的设计符合一般人的习惯吗
用户文档：
使用手册是否对电梯的用法、限制、使用条件等有详细的描述
压力测试：
1.看电梯的最大承重量，在负载过重时报警装置是否有提醒
2.在一定时间内不断让电梯上升、下降
稳定性测试：
看电梯在最大负载下平稳运行的最长时间
- 启动差别
app端：在执行用例的时候，1部安卓手机同一时刻打开一个apk包，可以理解，因为比如你在做王者荣耀的测试，那么你的apk肯定只有1个在主屏幕显示，其他apk在后台继续运行，但是你无法对他们做操作。
web端：web端就不太一样了，在web端，我们可以通过Python多线程(或多进程)同时开启几个浏览器，让selenium对多个浏览器进行操作，同样100个测试用例，如果均匀分布在3个浏览器进行，那么测试效率会有所提高，而且只需要一台电脑就可以测试多种浏览器。 - 安装检查
app端：这点感觉很像c/s架构软件，因为app是需要安装了才能使用的，所以软件是否安装异常，也是需要检查的一个点。
web端：不需要安装，在浏览器中输入url就可以测试。 - 页面元素操作
app端：只会显示在手机页面里加载出来的部分，比方说有的页面比较长，需要向下滑动才能看到更多信息，此时需要保证不可见的元素显示在手机页面才能对它进行操作。
web端：不太一样，如果控件不是下拉产生的异步加载，那么我们是可以对屏幕内不可见的元素做操作的。因为虽然页面上没有加载出来，但是html页面实际上已经有了。如果遇到需要下拉才能加载的页面，可以用js操作滚动条。 - 元素定位
app端：基本操作和web端差不多，不过部分定位方式不支持，比如css_selector和link_text，使用的时候会提示方法还没实现，也多出了accessible_id这种新的定位方式，不过目前我还没有用到，以后再补充。
web端：基础的就name，id，class_name，css，xpath这几种了。 - 启动
app端：需要制定desired_caps内容，因为里面包含了设备信息等。
web端：通过启动webdriver不同的浏览器类，获取driver，如webdriver.Chrome()，也可以模拟手机端加载wap页面做wap页面的测试。 - 关于元素的属性
app端：查找到元素以后，查看元素对象，发现里边基本上只有元素的text属性，也没有相关的方法修改，这个区别还是很大的。不过appium有set_text和set_value的方法，目前还没有尝试，用的还是send_keys()。
web端：web端简直就是天堂了，比起修改，读取元素属性。比如我要获取input标签的name，我可以用get_attribute方法，也可以自行写js代码改变这些属性。 - 使用js
app端：似乎是支持了，但是执行任何命令server端都会提示404的错误。
web端：支持非常好，因为本身js就是负责网页交互的，所以会很方便。 - 关于滑动
app端：关于滑动是会用得很多的，比如页面很长，或者打开通知栏，这种需要在屏幕上滑动的，用到的还比较多。
web端：用到的比较少，之前基本上没有用到过。 - 异常
app端：需要注意的是其他apk给你带来的影响，目前没有找到很好的方式去处理这些问题，因为其他apk给你做了弹窗，比如qq异地登陆，或者短信这种推送，会影响到目前的流程。办法肯定是有解决的，我个人理解，可以在出错之后比对一下是否在当前apk，如果不在的话则进入当前apk再做一次相关操作。
web端：很少被影响，可以边跑用例边聊qq，当然我只是举个例子，总之个人体会就是影响比较小，因为浏览器的driver完全只是控制浏览器，别的地方和它无关。
现在一般公司的测试流程
1．制定测试策略
首先测试策略，当用户提出新的需求时，测试人员应该和开发人员一起做测试需求分析，一般我们都会通过会议的形式去进行讨论分析，这样测试人员会对测试需要有个大概的了解，需要是干什么的，包括哪些功能等等，而不至于什么都不清楚不了解。
2．制定测试计划
大概了解需求内容之后，要对整个测试进行预期估算，包括计划要测试哪些方面的功能，要计划分配哪些人员参与到测试中，哪些人负责哪个模块，以及按照交叉测试的方法，同时还要计划要测试的开始和结束时间，便于掌控这个测试进展等等。
3．编写测试用例
测试计划规范之后，则是进行测试用例的编写。测试用例的编写，主要围绕界面模块而展开，如界面包括哪些按钮，按钮操作是否可以正常进行，其次围绕功能来设计，然后根据不同的场景来设计。对于测试过程中，出现的缺陷问题，要在将缺陷问题记录到测试用例“测试结果”一列，便于查看测试项测试任务情况。
4．形成测试报告
测试用例执行之后，对于测试过程中发现的缺陷问题，要汇报自己的测试情况并且测试中的缺陷反馈到测试工具中，便于开发人员解决。对于安排的不同模块的负责人在测试自己对应模块的任务时，也要及时的汇报自己的测试日工作进度，便于测试小组掌握测试的整个进度。
5．测试总结及文档编写
按照测试用例执行完所有的测试任务，且开发人员修复完了所有的bug问题（不包含一些难以修复但不紧急的问题，），测试人员需要编写针对本次项目的测试总结，要在总结中说明，测试计划是否按照如期进行。总测试缺陷数据多少，测试覆盖了多少等等。
同时文档人员要针对本次项目开发新增加的功能进行项目“升级日志”和“帮助手册”任务的编写。便于用户了解并能够快速上手使用新增加的功能。
Web测试是常见的测试场景，下面从页面，页面元素，功能，提示信息，容错性，权限，键盘操作部分讲述常见的测试点。
1.页面部分
（1）页面清单是否完整（是否已经将所需要的页面全部列出来了）
（2）页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是否显示）
（3）页面在窗口中的显示是否正确，美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
（4）页面特殊效果（如特殊字体效果，动画效果是否显示）
（5）页面特殊效果显示是否正确
2.页面元素部分
（1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮，单选框，复选框，列表框，输入框等）
（2）元素是否显示（元素是否存在）
（3）元素是否显示正确（针对文字，图形，签章等）
（4）元素的外形，摆放位置是否合理（如按钮，单选框，复选框，列表框，输入框等）
（5）元素基本功能是否实现（如文字特效，动画特效，按钮，超链接等）
（6）元素的容错性列表（如输入框，时间列表或日历）
（7）元素的容错性是否正确或存在
3.功能部分
（1）数据初始化是否执行
（2）数据初始化是否正确
（3）数据处理功能是否执行或正确
（4）数据保存是否执行或正确
（5）是否对其他功能有影响
（6）如果影响其他功能，系统能否做出正确的反应
（7）对模块的具体功能进行测试时可以列出功能模块所有的功能，进行排列组合，测试所有情况
（8）查询功能分2种–验证操作结果，打开页面时自动显示结果，则不需要特别强调；需要手工操作进行查询，则每次在其他功能完成后进行
4.提示信息
（1）成功，失败提示
（2）操作结果失败
（3）确认提示
（4）危险操作，重要操作提示
（5）返回页面提示后显示的页面
5.容错性
（1）为空，非空
（2）唯一性
（3）字长，格式
（4）数字，邮编编码，电话，电子邮件，ID号，密码
（5）日期，时间
（6）特殊字符（对于数据库），英文单词，单双引号
6.权限部分
（1）功能：指定用户可以使用哪些功能，不能使用哪些功能
（2）数据：指定用户可以处理哪些数据，不可以处理哪些数据
（3）操作：在逻辑关系上，操作前后顺序，数据处理情况
（4）权限变化
7.键盘操作
（1）Tab键
（2）上下方向键
（3）Enter键
（4）系统设定快捷键
我培训时，总结的一起分享，
Web与APP区别：
- web基于浏览器， app必须要有客户端
- web关注响应时间，app还需要关注流量、电量、手机本身的硬件条件
- 兼容方面，web是浏览器兼容，选择不同的浏览器内核，app是手机，有不同品牌，android和ios系统，还需要看屏幕分辨率、屏幕尺寸，和其它app之间的兼容
- 网络环境，App还有不同网络环境，2G、3G、4G、wifi、断网
- 硬件环境，App还需考虑异常场景：中断、关机、死机、重启等
- 交叉事件，接听电话、短信、邮件、其它操作
- App有横屏和竖屏之分、溢屏、触屏和手势
- Web直接连接服务器，app的取值方式可能是服务器、接口或本地缓存
- 升级、更新，Web更新无提示，直接进入浏览器就是最新，app是需要自己进行更新才能获取最新数据
- web登录需要密码，除非设置的记住密码，App有免登录功能
标准区别：
（1） 兼容性测试:web兼容各种版本浏览器，app兼容各种操作系统、手机型号、版本
（2） 手势：web没有，app有手势测试、功能键测试
（3） 交叉事件和横竖屏测试：app需要测试和其它app的兼容，与通话、短信之间的交叉
（4） 安装测试：web的bs架构，客户端不需要安装，手机app需要安装测试
（5） 更新：web一般更新服务端，app更新会对客户端进行更新，需要对更新进行测试
（6） 网络：app需要测试网络之间的切换，以及断网情况下，不同的网络类型对app是否有影响
（7） 屏幕的限制：app需要关注不同的屏幕上传的图片，文字的显示效果，是否会溢屏
（8） 性能测试：web需要关注页面的响应时间，app除了要考虑响应时间，还需要考虑到耗电量和流量消耗
（9） 软件的运行和启动：移动端需要测试app的启动，卸载和升级
问题1.请描述什么是性能测试、什么是负载测试、什么是压力测试？
参考答案：
性能测试：性能测试是和功能测试相对应的。根据用户场景进行的单个用户操作，是属于功能测试领域，主要是验证软件是否可以满足用户的功能需求。比如，单个用户使用系统，系统各项功能是否满足用户的需求。
如果把这1个用户的操作放大，变为100个，1000个，10000个用户同时操作软件，验证软件系统是否满足用户的需求。那么这个就是软件性能测试。通常使用性能测试工具对软件开展并发的访问，同时监控系统各项指标，比如CPU、内存、网络、磁盘等关键部件的使用情况。目标是发现软件在大用户量的情况下，系统的工作情况。性能测试是负载测试、压力测试、并发测试的统称。
负载测试：通过逐步加压的方式来确定系统的处理能力，确定系统能承受的各项阀值。
压力测试：逐步增加负载，使系统某些资源达到饱、极限甚至失效的测试。目的是用来发现系统的软件业务处理能力、系统硬件的极限处理能力等。