博客笔记_软件测试基础知识学习2

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.在一定时间内不断让电梯上升、下降
稳定性测试：
看电梯在最大负载下平稳运行的最长时间

1. 启动差别
   app端：在执行用例的时候，1部安卓手机同一时刻打开一个apk包，可以理解，因为比如你在做王者荣耀的测试，那么你的apk肯定只有1个在主屏幕显示，其他apk在后台继续运行，但是你无法对他们做操作。
   web端：web端就不太一样了，在web端，我们可以通过Python多线程(或多进程)同时开启几个浏览器，让selenium对多个浏览器进行操作，同样100个测试用例，如果均匀分布在3个浏览器进行，那么测试效率会有所提高，而且只需要一台电脑就可以测试多种浏览器。
2. 安装检查
   app端：这点感觉很像c/s架构软件，因为app是需要安装了才能使用的，所以软件是否安装异常，也是需要检查的一个点。
   web端：不需要安装，在浏览器中输入url就可以测试。
3. 页面元素操作
   app端：只会显示在手机页面里加载出来的部分，比方说有的页面比较长，需要向下滑动才能看到更多信息，此时需要保证不可见的元素显示在手机页面才能对它进行操作。
   web端：不太一样，如果控件不是下拉产生的异步加载，那么我们是可以对屏幕内不可见的元素做操作的。因为虽然页面上没有加载出来，但是html页面实际上已经有了。如果遇到需要下拉才能加载的页面，可以用js操作滚动条。
4. 元素定位
   app端：基本操作和web端差不多，不过部分定位方式不支持，比如css_selector和link_text，使用的时候会提示方法还没实现，也多出了accessible_id这种新的定位方式，不过目前我还没有用到，以后再补充。
   web端：基础的就name，id，class_name，css，xpath这几种了。
5. 启动
   app端：需要制定desired_caps内容，因为里面包含了设备信息等。
   web端：通过启动webdriver不同的浏览器类，获取driver，如webdriver.Chrome()，也可以模拟手机端加载wap页面做wap页面的测试。
6. 关于元素的属性
   app端：查找到元素以后，查看元素对象，发现里边基本上只有元素的text属性，也没有相关的方法修改，这个区别还是很大的。不过appium有set_text和set_value的方法，目前还没有尝试，用的还是send_keys()。
   web端：web端简直就是天堂了，比起修改，读取元素属性。比如我要获取input标签的name，我可以用get_attribute方法，也可以自行写js代码改变这些属性。
7. 使用js
   app端：似乎是支持了，但是执行任何命令server端都会提示404的错误。
   web端：支持非常好，因为本身js就是负责网页交互的，所以会很方便。
8. 关于滑动
   app端：关于滑动是会用得很多的，比如页面很长，或者打开通知栏，这种需要在屏幕上滑动的，用到的还比较多。
   web端：用到的比较少，之前基本上没有用到过。
9. 异常
   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区别：

1. web基于浏览器， app必须要有客户端
2. web关注响应时间，app还需要关注流量、电量、手机本身的硬件条件
3. 兼容方面，web是浏览器兼容，选择不同的浏览器内核，app是手机，有不同品牌，android和ios系统，还需要看屏幕分辨率、屏幕尺寸，和其它app之间的兼容
4. 网络环境，App还有不同网络环境，2G、3G、4G、wifi、断网
5. 硬件环境，App还需考虑异常场景：中断、关机、死机、重启等
6. 交叉事件，接听电话、短信、邮件、其它操作
7. App有横屏和竖屏之分、溢屏、触屏和手势
8. Web直接连接服务器，app的取值方式可能是服务器、接口或本地缓存
9. 升级、更新，Web更新无提示，直接进入浏览器就是最新，app是需要自己进行更新才能获取最新数据
10. 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、内存、网络、磁盘等关键部件的使用情况。目标是发现软件在大用户量的情况下，系统的工作情况。性能测试是负载测试、压力测试、并发测试的统称。
    负载测试：通过逐步加压的方式来确定系统的处理能力，确定系统能承受的各项阀值。
    压力测试：逐步增加负载，使系统某些资源达到饱、极限甚至失效的测试。目的是用来发现系统的软件业务处理能力、系统硬件的极限处理能力等。