成人达己:从SEO角度闲扯缺陷描述

2010-02-22  王恩建 

SEO是Search Engine Optimization缩写,中文叫做搜索引擎优化,是一种网络营销手段,通过SEO让网站内容被搜索引擎更多收录,同时在通过关键字搜索的时候让网站尽量排在前面。搜索引擎想把最好的搜索结果返回给用户,SEO则是把网页优化成为搜索引擎最喜欢的内容。SEO与软件测试有什么关系呢,我把缺陷当做一篇网络文章将从SEO的三个方法来描述。

1、网页主题优化
跟每个缺陷一样,每个网页都一个主题。主题要求一定包含关键字,例如网页主要是讲手机的,那么主题一定要包含“手机”这个关键字。这样做的目的是当用户在搜索“手机”的时候,这个网页能够出现在搜索结果中。如果搜索“手记”出现的你的“手机”网页,那就杯具了。对应到缺陷主题呢,我觉得也需要设置关键字,简单来说,缺陷也经常被搜索,选择好的关键字,有助于缺陷能被更方便被找到。

除了关键字设置,另外还要求网页主题言简意赅,要求主题符合中文语义。对于缺陷的主题,言简意赅同样重要,尽量通过主题就对该缺陷了解七八分。这一点对测试人员似乎要求有高,我也很少见到有测试人员能做到。网站上的那写文章标题,都是专职的编辑取名。

2、网页内容优化
SEO讲究把最终要的内容放在最前面,往往会在第一段就把故事发生的时间、地点、人物、事件都讲清楚,作为概述和摘要。这么做是让用户花最短的时间快速了解文章内容,让用户判断是不是他们感兴趣的内容。网易在这点上做的非常好。回到缺陷描述呢,我觉得应该做到这一点,把缺陷简洁描述一下,让开发人员和其他人员快速了解,那些细枝末节的内容放在后面补充。如果一开始就拖泥带水,没有重点,有些开发人员没那多好耐性看下去。

3、网页长度优化
SEO不提倡网页内容太长,太长同样考验用户的耐性,有的人一看文章太长直接关闭窗口。同样,如果缺陷描述冗长,同样有是考验开发人员耐性,难免开发人员抱怨。所以说,缺陷描述在能够描述清楚问题的前提下尽量简单,但是也有个度,不能从一个极端走到另外一个极端。我就见过这样的缺陷描述:“系统错误,不能使用”。这不是挑战开发人员的耐性,是挑战开发人员的智商。

好了,闲扯到这儿。好的缺陷描述可以改善开发与测试之间的关系,记住,缺陷是写给别人看的(但不包括你),方便别人最终是方便自己,成人达己。

522°/5068 人阅读/16 条评论 发表评论

金鑫  2010-02-23

最近在欧阳兄的引领下,和测试相关发散出的领域真是层出不穷
总之,好文就收藏了


欧阳辰  2010-02-23



不错的文章,Bug也需要SEO,有创意 :) 。 我以前有2个好的经验关于Bug.
1) 在Bug的Tilte上加上很多描述,对于Bug查找非常有效。
   Bug的Tilte 可以是: [组件名][缺陷类型][Titile] 。
    例如, [界面][性能][登陆界面很慢。。。。]
2) 在Bug的Title/description中,尽量用简单地描述缺陷的,这样每个人都能够看懂,能够快速明白Bug的含义。


王恩建  2010-02-23

欧阳辰:

不错的文章,Bug也需要SEO,有创意 :) 。 我以前有2个好的经验关于Bug.
1) 在Bug的Tilte上加上很多描述,对于Bug
对于欧阳兄分享的第一个经验,我的看法略微不同,探讨一下。描述缺陷的时候有一些其他选项,如“功能模块”或者“组件名”,“缺陷类型”,在titile里面在写上[组件名][缺陷类型],实际上这部分内容是冗余的,你是在“登陆界面很慢”这例子里面,“登陆界面很慢”已经说明了是“界面”组件,缺陷类型是“性能”。我比较喜欢“登陆界面很慢”这样的标题。


吴卓扬  2010-02-23

顶了!灰常的有创意,将seo引用到缺陷描述上面!我们公司一直在用TD作为缺陷管理工具,在bug描述上显得比较乱,有时都分不清那条bug是关于哪一模块的,根本不方便查看。后来的做法是在bug概述前面加上功能模块名称,如[登陆模块]描述信息。一目了然。看了你这篇文章,对bug归类、查找及其bug描述很有指导作用。赞~~


王爱莉  2010-02-23

我们公司有SEO部门,如果真要做到这步的话,不是抢了别的部门的工作了吗


王恩建  2010-02-23

王爱莉: 我们公司有SEO部门,如果真要做到这步的话,不是抢了别的部门的工作了吗
不是抢别人饭碗,是把SEO的方法应用到测试领域。


金鑫  2010-02-23

老王的“登陆界面很慢”,我有不同意见,我们这里的要求是:避免测试人员在所有文字输出时,尽量杜绝副词、或含糊的形容词出现。
原因是:
1、词不达意且语意含糊;
2、副词往往带有测试人员主观倾向的意味;
3、从产品质量控制的角度,(尽管该问题可能需要专项测试来定位或量化)不利于问题描述的可量化


王恩建  2010-02-23

金鑫: 老王的“登陆界面很慢”,我有不同意见,我们这里的要求是:避免测试人员在所有文字输出时,尽量杜绝副词、或含糊的形容词出现。
原因是:
1、词不达意且语意含糊;
2、副词
我这个意见我接受,“很慢”应该量化。


田庆希  2010-02-23

题目的描述真的是一个难题,很多缺陷都无法用简洁的文字描述出来,我在这块一直都很郁闷,每次提交一个bug都是把步骤、预期结果、实际结果写完了才考虑题目该怎么描述


欧阳辰  2010-02-23

更新一下我的Title例子,更好的应该如下。:) ;) :)
例如, [界面][性能][登陆过程太慢,超过4秒。。。。]


田静  2010-02-23

王恩建: 对于欧阳兄分享的第一个经验,我的看法略微不同,探讨一下。描述缺陷的时候有一些其他选项,如“功能模块”或者“组件名”,“缺陷类型”,在titile里面在写上[组件名][缺
如果bug管理系统可以根据“功能模块”或“组件名”进行类别搜索的话,那[]中的内容就是很有必要。


田静  2010-02-23

吴卓扬: 顶了!灰常的有创意,将seo引用到缺陷描述上面!我们公司一直在用TD作为缺陷管理工具,在bug描述上显得比较乱,有时都分不清那条bug是关于哪一模块的,根本不方便查看。后来
TD可以从多维度自定义一个bug。比如“登录界面很慢”,就可以从[界面问题][性能问题][登录模块]等三方面去定义,当然,维度越多越复杂,还是要把握一下度的。


田静  2010-02-23

金鑫: 老王的“登陆界面很慢”,我有不同意见,我们这里的要求是:避免测试人员在所有文字输出时,尽量杜绝副词、或含糊的形容词出现。
原因是:
1、词不达意且语意含糊;
2、副词
然~


袁永云  2010-02-23

这就是我一直追求的,受教了!


吴卓扬  2010-02-24

田静: TD可以从多维度自定义一个bug。比如“登录界面很慢”,就可以从[界面问题][性能问题][登录模块]等三方面去定义,当然,维度越多越复杂,还是要把握一下度的。
恩,说得有道理,谢谢提醒~


袁帅  2010-06-09

hehe


登录 后发表评论