3类网站测试的套路:UI测试、功能测试和兼容性测试

11 评论 18563 浏览 143 收藏 11 分钟

关于网站测试的几个小套路,希望对大家有所帮助。

一、 UI测试

用户界面测试主要是拿待测网页和设计稿进行对比,个人觉得主要需做到以下4点:

1.注重细节:

这点最基本,就是对比时细心、细心再细心。像我现在被虐到网页上元素和设计稿差一个像素都能看出来…

2.勿忘整体性:

由于PC网页页面空间大,模块多,很容易在测试时只注意到模块内设计元素是否正确,而忽略了模块间的间距或整个页面的布局是否正确。所以最好按照由局部到整体的顺序测试。

3.注意页面间相互对比:

即注意相同系列页面、页签布局一致性。就是说的是同一系列页面中同类元素和模块的样式、间距一般要相同;同一个tab下,不同选项对应 的页签中同类元素和模块的样式、间距一般要相同。例如下图QQ空间-日志页面里我的日志和私密日记tab中,红框圈出的位置高度是否一致。

QQ空间日志-我的日志

QQ空间日志-我的日志

wps73C2.tmp

QQ空间日志-私密日志

一般情况下这些不一致问题出现的情况不多,毕竟相类似的布局前端同学应该会用相同的盒子,但是测试时还是需要留意。

4.注意极端情况下显示情况:

即要注意长度可变的元件、模块或字段在极端情况下的显示是否正常。

例如:文章标题最多可显示50字符(25汉字),测试时就要在所有会出现标题的位置(文章列表页、推荐边栏、转发弹框…)是否能正常显示含有50字符的标题,会不会出现破框而出、自动切掉等情况。

由于UI测试时需要检查的细节很多,特别是像我们团队,网站还在搭建中并未上线,UI测试的工作量更是大,测久了难免会觉得枯燥繁琐,但其实每项任务都能总结出套路、有所收获,故下面仅列出我平时在测这部分时的主要注意点和心得。

UI测试注意点总结:

  1. 模块间距
  2. 元素间距
  3. 不同类型文本(数字、汉字、英文)颜色、格式(全角、半角)大小、字体、(不必须)
  4. 固定文案:内容的可读性、正确性‚排版的合理性
  5. 可变字段:极多、极少文字的排版情况
  6. Icon用错、用混
  7. 相似页面的差异性和一致性

小体会:

其实界面测试虽然没啥技术含量,但测久了就会发现自己对网页元素有时彼此间的间距差了1、2个像素,整体的视觉效果就尺寸和布局的敏感度有提升,例如像同样一组元素,会大有不同,web是这样,移动端更是如此。

随手画张图举个栗子:左图网页做出来名称、作者、互动统计三者之间行距相等,中文字大小相 同,而设计稿原本应如右图,行距不同,不同字段的字号也不同。所以假如测试时遇到类似这种问题,我们除了可以提个bug,还会被引导去思考设计初衷,即利用间距细微差异进行视觉分组,利用字号细微差异突出主次。

wps73E2.tmp

二、功能测试

1.操作反应:

(1) 页面元素(按钮、锚文本、输入框…)自身状态变化:鼠标移入/移出时效果、点击后效果、获取/失去焦点时效果…(可以想想axure里的用例状态)

eg:鼠标移入按钮,按钮是底色是否应改变;若输入框内有默认提示文字,则是当输入框获得焦点后文字就消失,还是用户输入文字后提示文字才消失…

(2)操作成功后续反应:页面跳转、弹框、提示文字…

a.页面跳转:

  • 页面切换方式:另开页面、本页切换
  • 页面起始定位:页面起始位置、页面其他锚点(例如用户想评论某文章,在列表页点评论按钮后,就会在另开的文章内容页直接定位到评论区)

b.弹框:

  • 匹配情况:弹出的弹框是否和触发条件匹配
  • 出现位置:一般情况下要一致。因为弹框使用不同插件,可能导致弹出位置不同。
  • 显示时间(非操作类弹框):某些仅起到提示功能的弹框会自动显示若干秒关闭。一般情况此类弹框上文案较少,显示秒数应该是全站一致的。

c.提示文字:

匹配情况:出现的提示文案是否和触发条件匹配

关于操作成功后续反应,以上主要是在已确定会触发某反应情况下,测试其正确性。其实这里更重要的是要考虑在前置条件不同的情况下,对某元素进行相同操作,会触发什么不同的反应。即需要对各类情况进行穷举。

eg:点击关注按钮触发反应穷举:

a.未登录用户点击该按钮后效果;

b.已登录用户点击该按钮后效果(b1.未关注过对方、b2.已关注过对方、b3.自己关注自己)

穷举时可以参考PRD,但不要局限于PRD上列出的情况,毕竟有时也许PRD上会有小疏漏,要是程序员做的时候发现疏漏,就自己随手码了一个简易提示而忘记通知产品,而测试的时候也没触发到,等用户实际操作出来就会造成不佳的用户体验。

2.数据:

(1)数据状态:此处指数据值自身的状态。即前置条件满足后,数据状态是否会按照规则更新。
这里的规则一般是

a.时间规则(eg:经过多长时间数据状态改变;在哪个时间点更新…);

b.统计规则(eg:每个ID多次完成前置操作,数据更新多次;每个ID多次完成前置操作,数据仅更新一次;每个ID…)

(2)数据排序:数据在某筛选条件下排序的正确性。

eg:某宝某店铺商品展示页面,当用户选择按销量由高到低排序时,列表是否变为按销售量多到寡进行排序;当商品A的销量超过商品B的时候,商品A的位置是否会更换到商品B的前面。

3.特殊情况 :

(1)缺省情况:当某页面或模块还没有内容或尚未加载出来时,是否有相关提示画面、文案。

(2)操作中断:用户操作中途退出页面(eg:填写资料并尚未保存时关闭页面);操作中途断网…这些情况下是否设置了相关提醒弹框。

三、兼容性测试

不同浏览器(360、谷歌、火狐等等主流浏览器)下的页面显示情况是否正常。

四、怎样测试才能少被开发怼?

1、用例尽量辅助截图:

由于我们公司还没有bug管理工具,测试反馈都是用excel撰写的,因此我非常能理解程序员葛葛们看着密密麻麻的文档时,心里一万只羊驼呼啸而过的心情。而辅助页面截图,一方面表达更清楚,减少文字描述;另一方面,某些偶发bug留下“事故现场”的证据很有必要。

2、用词准确到位:

这点我的体会是,如果公司负责测试的同学不是技术出身,无法完全用专业术语,也要尽量把bug和正确结果描述的清楚到位,否则反而会增加沟通成本。当然,如果测试也懂技术,那么世界将变成美好的人间~

3、前端、后端、设计问题在文档中区分开:

这个不多说了,就是为了避免导致三个和尚没水吃的下场…

4、某些问题采取灵活的解决方式:

测试时也会偶尔发现原有产品逻辑疏漏或错误、或者感觉某些功能有更好的实现方式。第一种情况时,不要慌了手脚忙着策划新方案,而是先去和程序员葛葛们沟通、听取建议,咨询有什么方式可以在变动最小的情况下达到策划的目的。第二种情况就相当于提新需求了,就算是情势所迫或开发时间充裕,也尽量三思后行吧,要提可以迭代的时候提。如果测试的时候总提新需求,暂不提程序员的心理阴影面积,产品开发节奏可是会乱套。

以上是对近期测试工作的小总结,主要列出的是自己经常踩的坑。由于经验尚浅,肯定有许多方面写的不够到位,请大家多多指教,我会虚心学习哒~

 

本文由 @晴SAMA 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 很详细,感谢分享

    回复
  2. 兼职测试兼职产品的商务人员来此取经,十分感谢老鸟的分享~~~

    来自北京 回复
    1. 你的头像会动!

      来自山东 回复
  3. 我是产品新人,写的很受用 😉

    来自菲律宾 回复
  4. 技术转型产品中 😉

    来自河北 回复
    1. 好棒!一起加油 😉

      来自上海 回复
    2. 测试转产品难吗?我是从英语教研刚转测试,想了解一下测试专员之后的职业发展方向有哪些?

      来自美国 回复
  5. 我是测试转过来的产品经理,哈哈

    来自四川 回复
    1. 哈哈我是三无产品新人,请测试+产品老司机多多指教~ 😉

      来自上海 回复
  6. 😉

    来自上海 回复
    1. (*^__^*)

      来自上海 回复