My_Project

资料整理


WEB测试白皮书

<p>维护人:赵纯博、宋紫微 最后更新时间 :2019年10月15日 更新内容:更新排版</p> <p><img src="http://rpddoc.weoa.com/server/../Public/Uploads/2019-10-15/5da5638b6dbb1.png" alt="" /></p> <h2>一、界面</h2> <p>注:被测系统前端框架为:VUE</p> <p>1、UI 检查页面元素显示是否合理,字符或按钮显示完整度,错别字校验。</p> <ul> <li>常见问题: &emsp;&emsp;&emsp; 1)可以链接到其他页面的文字或可以打开弹窗的按钮,鼠标指向的时候应该显示手状最好; &emsp;&emsp;&emsp; 2)缩放浏览器时页面显示排版容易出现异常</li> <li>实例: &emsp;&emsp;&emsp;1)测试采薇比赛系统时,浏览器适当缩放,将底部滚动条拖动到最右侧,也无法看到顶部右侧的“历史赛事”按钮 &emsp;&emsp;&emsp;2)FDN官网测试,页面放大至110%,顶部多出菜单图标及选项,且各选项点击无作用</li> </ul> <p>2、字符 所有字符应该显示完整,不能出现切边、字符中间有空格等问题</p> <ul> <li>常见问题:字体不一致、字体大小不统一</li> </ul> <p>3、兼容性 web端兼容性测试包括:浏览器兼容性、分辨率兼容性和系统兼容性</p> <p>浏览器:应该最先以产品面向的用户群体使用的浏览器为重点测试对象。如果产品没说明,默认以chrome浏览器为主,其次是firefox和360浏览器.因为这3种浏览器分别使用不同内核(渲染引擎)的. 备注:世界上使用浏览器的内核一共就4种,最后一种是苹果系统浏览器使用的内核</p> <p>系统:windows7,windows10,IOS为主</p> <p>分辨率:1920 * 1080,1366 * 768为主 <img src="http://rpddoc.weoa.com/server/../Public/Uploads/2019-10-31/5dba47e0a5fca.png" alt="" /> 数据来源于:<a href="https://cn.screenresolution.org/year-2019/">https://cn.screenresolution.org/year-2019/</a></p> <ul> <li>常见问题:IE兼容性最差甚至影响到功能的使用,其次360如果选择的是IE内核的话,会出现和IE浏览器一样的问题</li> <li>实例:DSP 1.0版本测试中出现使用当前IE最高版本11测试都会出现无法登录、新建创意时无法上传素材等严重影响功能性问题</li> <li>参考办法:如果测试过程中遇到该问题,开发同学没有解决思路时,可以把以下链接发给前端同学做参考: <a href="https://mp.weixin.qq.com/s/Sjrna0hv71bFndEkGdRtUQ">https://mp.weixin.qq.com/s/Sjrna0hv71bFndEkGdRtUQ</a></li> </ul> <h2>二、功能</h2> <h5>1、登录</h5> <p>1)密码:用户名&amp;正确密码、用户名&amp;错误密码、用户名&amp;历史密码 2)验证码:用户名&amp;密码&amp;正确验证码、用户&amp;密码&amp;过期验证码、用户&amp;密码&amp;错误验证码 3)提示语:当密码错误时给出的提示语建议为:您的账号或密码错误</p> <h5>2、数据库校验</h5> <p>1)新建:页面上可以看到的所有用户输入的数据都应该在数据库中可以查看到 2)修改:系统上用户可以修改的数据,数据库中应该及时更新 3)删除:系统上被删除的数据,数据库中应该查询不到此数据或status状态为-1等(以实际项目为准) 4)筛选:测试系统中包含大量数据时,对于检索功能的测试,数据库会大大提升测试工作的效率</p> <ul> <li>常见问题: &emsp;&emsp;&emsp;1、页面勾选的内容,实际并没有传入到数据库中 &emsp;&emsp;&emsp;2、涉及大量数据系统需要对检索功能测试</li> <li>实例: &emsp;&emsp;&emsp;1、AI程序化广告,选择投放媒体(两个选项:不限(包含所有媒体)、设置),在设置下取消一个选择媒体,再切换到不限,提交,实际传入数据库的数据缺少一个媒体 &emsp;&emsp;&emsp;2、CVM系统,需要检索出,公司名称包含某些字符或姓名或其他字段</li> </ul> <h5>3、逻辑场景校验</h5> <ul> <li> <p>一个业务需要有多个逻辑场景校验时,考虑中间某个环节跳过,直接去下一步操作,看是否可以操作 比如: 1)专利平台审批业务:发明人申请单据-&gt;专利主管-&gt;专利代理;测试发明人提交申请单后应该先到专利主管审批通过后再到专利代理去;校验专利代理是否可以绕过专利主管直接操作申请单(此场景为不可绕过) 2)淘宝购物:登录-&gt;浏览产品-&gt;(购物车)-&gt;下单-&gt;支付;测试可否绕过购物车直接下单支付(此场景为可绕过)</p> </li> <li>两个系统关联,其中一个系统的设置影响到另一个系统的显示与功能 如: 1)TrendBox项目:管理台设置商品的上架与下架,影响到盒子端商品的显示与消隐;校验管理台商品未上架、上架、下架三种状态盒子端对应显示的商品是否正确及是否在下架日期后及时消隐不再显示 2)采薇比赛系统:管理台设置赛事,可以显示在用户端的正在进行或历史赛事页面;校验管理台赛事开始日期是否及时显示在正在进行页面、结束日期后是否显示在了历史赛事页面</li> </ul> <h5>4、设计典型模块用例</h5> <h2>三、易用性</h2> <p>尼尔森十大易用性问题 1、状态可见原则 用户在网页上的任何操作,不论是单击、滚动还是按下键盘,页面应即时给出反馈。“即时”是指,页面响应时间小于用户能忍受的等待时间。 2、环境贴切原则 网页的一切表现和表述,应该尽可能贴近用户所在的环境(年龄、学历、文化、时代背景),而不要使用第二世界的语言。《iPhone人机交互指南》里提到的隐喻与拟物化是很好的实践。此外,还应该使用易懂和约定俗成的表达。 3、撤销重做原则 为了避免用户的误用和误击,网页应提供撤销和重做功能。 4、一致性原则 同一用语、功能、操作保持一致。 5、防错原则 通过网页的设计、重组或特别安排,防止用户出错。 6、易取原则 好记性不如烂笔头。尽可能减少用户回忆负担,把需要记忆的内容摆上台面。 7、灵活高效原则 中级用户的数量远高于初级和高级用户数。为大多数用户设计,不要低估,也不可轻视,保持灵活高效。 8、易扫原则 互联网用户浏览网页的动作不是读,不是看,而是扫。易扫,意味着突出重点,弱化和剔除无关信息。 9、容错原则 帮助用户从错误中恢复,将损失降到最低。如果无法自动挽回,则提供详尽的说明文字和指导方向,而非代码,比如404。 10、人性化帮助原则 帮助性提示最好的方式是:1、无需提示;2、一次性提示;3、常驻提示;4;帮助文档。</p> <h2>四、自动化测试</h2> <ul> <li> <p>稳定性测试 参考:<a href="http://rpddoc.weoa.com/web/#/1126?page_id=25579">http://rpddoc.weoa.com/web/#/1126?page_id=25579</a></p> </li> <li>自动化测试 推荐使用:selenium 待补充</li> </ul> <h2>五、权限安全</h2> <p>权限测试就是测试当前用户没有操作权限的功能点</p> <p>测试实例:</p> <p>通过后台传到前台的选项1,2,3,4,5(数字是直接存到数据库的),前台通过处理web表单中一个下拉框选项有:a,b,c,d,e(前台显示) 实例:web表单的一个下拉框选项有:aa,bb,cc,dd,ee5个选项,真实传到后台服务器对应字段是1,2,3,4,5;其中vip用户能看到并操作aa,bb,cc,dd,ee所有选项,但是普通用户登录进去只能看到并操作aa,bb,cc(后台对应1,2,3).这时候测试普通用户越权请求4,5后台是否能识别.操作步骤: 1、普通用户正常提交表单</p> <p>2、用fiddler拦截请求内容</p> <p>3、操作fiddler:找到对应的请求,右击-&gt;Replay-&gt;Reissue and Edit</p> <p>4、重新编辑请求内容:选择Raw(或者在webForm修改)-&gt;找到对应字段的key将value的由1/2/3改成4/5(改成没有操作权限)-&gt;点击run to completion重新发送-&gt;看下面区域的raw(下面区域都是返回)</p> <h2>六、工具</h2> <p>为什么要使用工具? 1)助于开发同学定位问题 2)提高测试效率(如可以通过fiddler测试同学自己模拟响应数据就不需要每次都去麻烦开发同学,耽误双方时间)</p> <h5>1、提交BUG之开发者工具</h5> <p>1)问题到底是前端的还是后台的? 发现问题后,我们通过DPMS系统上传问题,选择关注人的时候,我们需要简单判断该问题应该分派给前端开发同学还是后台开发同学,这个时候需要通过借助开发者工具,查看服务器返回数据与页面显示数据是否一致,如果显示一致则说明该问题的根源是后台处理问题,任务人选择后台;如果返回数据与页面显示数据不一致,则说明是前端展示数据的问题,任务人选择前台。 举例:如 下图的问题就是后台取错了“最佳成绩提交日”的时间: <img src="http://rpddoc.weoa.com/server/../Public/Uploads/2019-09-11/5d78a251d5161.png" alt="" /></p> <p>下图的问题就是后台有传username过来,但是前台没有显示: <img src="http://rpddoc.weoa.com/server/../Public/Uploads/2019-09-11/5d78a379ee431.png" alt="" /></p> <p>2)进入开发者工具的三种方式</p> <p>&emsp;&emsp;&emsp;1)页面右击,选择“检查页面元素”;</p> <p>&emsp;&emsp;&emsp;2)通过F12快捷键打开(最常用的一种方式);</p> <p>&emsp;&emsp;&emsp;3)通过菜单,选择(如chrome浏览器的打开方式为:点击设置——更多工具——开发者工具)</p> <h5>2、x-mind</h5> <ul> <li> <p>用X-MIND列出需要测试的类型 测试的类型分为:功能测试/兼容性测试/性能测试/界面测试/安全性测试 根据项目需要依据以上5大类去设计用例</p> </li> <li>用X-MIND设计测试用例</li> </ul> <h5>3、fiddler</h5> <p>1)测试中借助fiddler,避免不必要的干扰,建议先设置过滤条件,如图(多个地址之间以英文分号相隔): <img src="http://rpddoc.weoa.com/server/../Public/Uploads/2019-10-15/5da536ee6825a.png" alt="" /></p> <p>2)fiddler除了可以拦截请求外,也有和开发者工具一样的用途: 测试过程中,页面不方便打开开发者工具时,可以使用fiddler; 测试过程中,有偶现型问题出现时,建议打开fiddler</p> <ul> <li>request请求拦截</li> </ul> <p><img src="http://rpddoc.weoa.com/server/../Public/Uploads/2019-10-15/5da53861ceb61.png" alt="" /></p> <p>点击底部位置,出现如图所示图标,即当前是request请求拦截</p> <p>实例参照:</p> <ul> <li>response响应拦截</li> </ul> <p><img src="http://rpddoc.weoa.com/server/../Public/Uploads/2019-10-15/5da5389a53e4d.png" alt="" /></p> <p>点击底部位置,出现如图所示图标,即当前是response响应拦截</p> <p>如: AI程序化广告,创意审核失败的原因,取后台返回的&quot;checkReason&quot;的值,可以通过response响应拦截设置checkReason的值,再在前端校验是否正确。</p> <p>3)fiddler其他使用方法(设置过滤条件,Https请求的抓包)参考:<a href="http://rpddoc.weoa.com/web/#/1126?page_id=32947">http://rpddoc.weoa.com/web/#/1126?page_id=32947</a></p> <h2>七、app与web测试的区别</h2> <p>1、web项目,一般都是b/s架构,基于浏览器的,而app则是c/s的,必须要有客户端。从系统架构来看的话,web测试只要更新了服务器端,客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的,除非用户更新客户端。如果是app下修改了服务端,意味着客户端用户所使用的核心版本都需要进行回归测试一遍。 2、从功能测试的来讲的话,在流程和功能测试上是没有区别的。系统测试和一些细节可能会不一样。 3、性能方面,web页面可能只会关注响应时间,而app则还需要关心流量、电量、CPU、GPU、Memory这些了。 4、兼容方面,web是基于浏览器的,所以更倾向于浏览器和电脑硬件,电脑系统的方向的兼容,不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试(IE、chrome、Firefox)。app的测试则必须依赖phone或者是pad,不仅要看分辨率,屏幕尺寸,还要看设备系统。系统总的来说也就分为Android和iOS,不过国内的Android的定制系统太多,也是比较容易出现问题的。 5、相比较web测试,app更是多了一些专项测试:   一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断,来电,短信,关机,重启等;而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验,重点要考虑回退和刷新是否会造成二次提交。需要测试丢包,延时的处理机制。 安装、卸载、更新,现在app产品的用户都是使用的触摸屏手机,所以测试的时候还要注意手势,横竖屏切换,多点触控,事件触发区域等测试。</p>

页面列表

ITEM_HTML