产品经理做测试那些事儿

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

chanpin

周六,深夜,我拖着满是疲倦的身躯,四处闲逛,来到小巷一家还闪着霓虹的酒吧,我略一犹豫走了进去。

酒吧冷冷清清,寥寥几对男女,在昏暗的灯光下切切私语,我没兴趣知道他们在说些什么,懒懒趴在吧台,酒保一脸贼像,笑嘻嘻问我想喝点什么,并向我推销他们的新品鸡尾酒,我不看他,只说:啤酒。

酒保自讨没趣,把酒摆在我面前,我眼神空洞,一口口喝酒。

吧台上还坐着个戴着墨镜,满脸胡茬的大叔,喝着的也是啤酒。

这时我的手机铃声响起,我挣扎两下,拿出手机,却看是总监打来的.

没办法,接吧:“喂,总监。”

总监:“朝聆夕改,你在干嘛?”

我:“我….我在回家路上。”

总监:“BUG处理得怎么样,是不是要发新版?”

我:“嗯,BUG处理得差不多了,要发新版。不过研发的同事说怕再说问题,要多测两天再上……”

总监:“那你还回什么家,好好测啊!当时测试的时候不好好测,现在倒想起来谨慎了…..”

我:“好的,我周末继续测….”

挂了电话,我木木地喝了口寒彻心扉的啤酒,准备再做几分钟就回去。

这时,旁边的大叔冷笑一声:“小伙子,你是产品吧?”

我一激灵:“你怎么知道?”

大叔抿了一口啤酒:“我不仅知道你是个产品经理,还知道你们公司人不多,你们公司没QA。”

我手抖了抖,杯子掉在桌上,溅起的啤酒,冰凉了我的神经,我一下子清醒了。

他猜的没错。我是个产品经理,移动互联产品经理,公司刚B轮,人确实不多,没有QA。

我转过身去,看他,才发现其实他邋遢之余很是潇洒,昏暗的灯光下那闪闪的墨镜遮住了他深邃的眼睛,嘴角泛着浅浅笑意,胡茬还留存着啤酒的水渍….

我一抱拳:“请问前辈高名?”

他笑了:“别来那套文绉绉的,老子姓高,你可以叫我老高。以前是移动互联创业公司的产品总监,现在下海做生意,兼职算命。”

得道高人!我知道我今天遇到高人了。

他不看我:“是不是测试遇到麻烦了?”

我低头:“嗯,公司没测试,我负责组织研发同事测试,结果测完上线,出现了机型适配的问题,只能重新发布…”

他说:“你知道测试是什么吗?为什么你们公司没测试?你作为产品经理,却得做测试的工作?”

我有点蒙:“测试,就是一群人拿着手机测BUG啊,公司不是没招过测试,上次来的那个测试,看所有人下班了都没走,第二天就不愿因来了…….我对产品最熟啊,再说也缺人。”

老高咂两下嘴:“错,错,错!测试是产品策划到上线维护中不可缺少的一环,测试质量的高低直接关系到产品的可用性,友好性,可靠性。虽然测试是必要的,但测 试人员不是必要的,因此大多数的初创公司并不设置QA的岗位。同时,没有测试人员,其实也是一种敏捷的方式,facebook在从创立起很长一段时间里都 是没有测试的。产品经理做测试,一方面是因为对产品最熟,另外也是因为开发思维与测试思维是不同思维的原因,说了你也不懂。”

我不服气,猛地喝了一口酒:“那你说说测试是什么?”

他 又笑:“从测试内容上看,测试主要分为UI测试、功能测试、兼容性和性能测试。UI测试就是界面视觉的测试,找设计师测就行了,兼容性和性能测试人力不可 为,一般要借助工具测,但是必须测,像你们这种手机适配问题肯定是没走过这个流程。一般来说,产品跟研发做的就是功能测试。测试是有许多方法的,但主要分 为三类…..”

“黑盒测试、白盒测试和沙盘测试!”原来是酒保打断,这厮在旁边偷听许久了,我还以为他是想趁我不注意给我倒酒。

我说:“你还懂这个。”

酒保贱贱一笑:“略懂,略懂,以前做测试的,花名测三通。”

老高也有兴趣了:“那你说说什么是黑盒测试。”

测三通:“黑盒测试,也可以叫不透明测试,它着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。主要方法有等价类划分法、因果 图法和错误推测法。等价类划分法就是把产品按照模块进行划分成若干个部分,分人测试,一般公司都用这。因果图法就是根据流程图,测试前、后置条件,从而推 断是否可以正常使用的办法。”

见我不太明白,他又补充说:“比如在购物车点击确定,但是购物车里是空的——返回“用 户名错误”提醒,就是一条因果图法的测试用例。白盒测试与黑盒测试互补,是透明测试,在于全面了解程序内部逻辑结构、对所有逻辑路径进行测试。沙盘测试就 像你们产品经理做竞品分析的时候做的那个什么….“

老高提醒:“任务走查。”

测三通:“嗷~任务走查,模拟用户在实际环境中的测试,也就是把一个个用户场景都走通一遍把重要的逻辑漏洞过滤掉,一般产品上线前的回归测试就用它。”

真是人不可貌相,我深深看了测三通一眼,然后温柔地对他说:“倒酒。”

老高补充说:“其实还有许多测试内容,比如:

  • 排序测试
  • 字符测试
  • 缓存测试
  • 必要信息测试
  • 准确性测试

在测试中是很容易忘记的,你最好记住。”

我拼命点头:“前辈教导的是,我们平时用的就是黑盒测试,那你能跟我讲讲测试的流程吗?”

老高用酒杯砸了砸桌子:“这个要好久(好酒)呀…..”

我定睛一看:果然酒杯空了。

我看了测三通一看:“倒酒,算我的!”

测三通这小子早就在旁边等着了,赶紧给老高倒了杯12年的人头牛。

老高喝了口:“好酒,既然你这么有诚意我就好好跟你说说。”

我跟测三通都聚精会神地看着他。

老高:“测试流程主要分为这么几步,

  1. 测试资源准备;
  2. 测试人员分工与选择测试方式;
  3. 测试FIX任务。除此之外你还要准备相关文档。话说你叫什么名?”

我这才想起我没做自我介绍:“哦哦,我叫朝聆夕改,你叫我小朝就行了。”

老高:“小改呀,你平时测试资料准备都准备些什么呀”

我想了想:“主要就是各种型号、操作系统的手机,有时候还需要给他们准备点纸笔。”

老高点点头:“嗯,你说的是测试设备的准备。测试资料一般要准备下面几项:

  • 测试设置,除了你说的手机、纸笔外,你还要借场所,就是会议室之类的,准备点小零食也是有好处的;
  • 测试坏境,一般就是内测坏境、正式环境;
  • 测试账号,普通账号和特殊账号,都要多准备些,临时准备会影响测试人员的士气;
  • 测试人员,要预约好,安排规划,不然临时就叫走,把你气的半死;
  • 测试用例,这儿是产品测试的核心,是对产品的所有节目的视觉、交互和功能逻辑的汇总。”

测三通插嘴:“这个测试用例可得好好讲讲。”

我冷冷地看了他一眼:“你也要请喝酒吗?”

测三通闭嘴。

老高呵呵一笑:“当然,不讲测试用例算什么测试。

测试用例撰写的原则有这么几种:

  • 有效性,就是说测试用例必须是真实有效的,不同的测试人员依据相同的测试用例所得到的输出应该是一致的;
  • 复用性,不用写的太死,能复制最好,要不然一个小产品就随随便便几千个,累都累死你了;
  • 易组织性,写用例的时候最好能考虑到测试的场景,别上一个用例写的是A页面,下一个又跑到C页面去了,当然产品经理还是有这个思维的;

还有其他原则,比如可评估性,可管理性,太专业了不太重要,原则有几个就够了。

得,我先上个厕所。”

说罢,他扶着墙去厕所了。

老高真是教科书一样的人物,只可惜,人到中年就双目失明…我正在替他感到悲哀,就听到老高远远地就在厕所门口喊:“你这贼酒保,又趁我不在给我倒酒是不是!”

测三通,僵住了正在偷偷倒酒的手臂,尴尬地说:“哎呀,你老身体健康就好,没事戴什么墨镜算命呐,我就想做点好事,请您喝杯酒……“

老高大步流星走到位置,不客气地猛喝一口:“原来是这样,三通你这年轻人不错,我看好你。”

测三通讪讪而退,我看看老高,他正摘下眼镜朝我眨眼:原来是装的,骗酒喝!

我苦笑:“前辈,咱们接着说测试用例吧。”

老高:“好嘞,刚说了原则,下面说说类型,类型就这么几种:

基本功能用例、交互用例、临界用例还有压力测试。前面三种你应该都懂,最后一种压力测试一般人就不懂了,压力测试一般是指在比较短的一段时间内,被测手机执行比较多的任务或者操作,来检测被测手机承受压力的能力。这个测试还是比较有必要的,知道了也可以装X。”

我深以为然:“前辈,我也写了一些测试用例,请您指点。”

1-1

老高看完我的测试用例,点点头:“小改,其实这就够了。测试用例在内容上可以分为两个部分:测试信息和用例信息。

  • 测试信息包涵了测试人、测试时间、测试版本号、测试机型、操作系统以及测试的结果统计;
  • 用例信息主要包涵用例所属模块、用例ID、用例事件描述、前置条件、期望结果以及测试结果等。”

老高顿了顿,说:“这是黑盒测试的用例,如果是沙盘测试或者白盒测试,用例就会复杂许多,往往需要流程图之类的,如果是成熟的,或者传统公司对测试的流程就要多许多,你是用不着学的。”

我得到了前辈的认可,还是有些欣喜:“那该说说测试分工的事情了。”

老高:“那你们平时怎么分工的。”

我说:“就找两端的主管要些人,然后随即分模块给他们,把测试用例分给他们,下午的时候组织一下集中测试。”

老高摇摇头:“效果怎么样。”

我品了品苦涩的啤酒:“不太好。”

老高:“具体表现呢,列举出来,你个产品总得有点逻辑能力吧。”

我掐了掐自己已经快麻木的大腿,强打起精神:“那我可得好好吐槽一下:

  1. 集中测试的时间缩水太严重,每次召集人手都要几十分钟,还经常检查出BUG就马上去改,一次集中测试要测1~2小时;
  2. 集中测试效率低下,测试时很容易被与自己测试内容不相关的部分打断;
  3. 负责测试的研发同事对产品不熟悉,要跟他们讲,特费时间,效果还不好;
  4. 单独测试不能很好执行,不可控;
  5. 经常性被不同的人提出重复的BUG,浪费时间。”

老高哈哈一笑:“看来你很清楚出现的问题呀,可是你还是不能解决是不是。”

我:“是啊,请前辈指教。”

老高挥挥手:“叫老高就行了,指教谈不上,兵法有云:知己知彼,百战不殆。你既然知道问题,也应该知道出现问题的原因。第一条,集中测试太费时间,主要的原因是这么几个方面:

  1. 没有很好的时间规划,测试人员不知道什么时候测什么时候停止测,建议你们的集中测试由下午改成中午,到午休的时候自动停止,这样至少有个停止的时候,让测试人员能够自觉调节测试的速度,同时下午的时间其实更有弹性,你懂得,改不完的可以加班嘛;
  2. 人气不足,可能是你在公司呆的不久,跟开发不是很熟,更重要的是没有建立那种说一不二的威信,所以你得以身作则,梳理形象;
  3. 测试人员责任心不足,这是怎么回事,你知道乌合之众这个词吧,差不多就是说群体会降低每个人的智慧,大家嘻嘻哈哈没当回事,自然不行。这时候我建议你使用交叉结对测试的方法测试。
  4. 测试人员动力不足。没奖励呀,你得多鼓励鼓励才行,有鼓励师没?”

我张张嘴,还没说话,老高就打断了我:“没有是吧,那就物质奖励,前面说测试资料准备的时候不是也提了准备零食吗,这时候就得上啊。”

我皱皱眉:“老高,那个什么交叉结对测试是什么意思?我只听说过交叉测试。”

老高眯了眯眼睛:“交叉结对测试,就是指安卓和iOS两端的负责同一个模块的开发人员,组成队伍,相互测试对方的客户端。有点拗口,但很有用处:

  1. 由于是负责自己开发的模块,所以不需要学习,能够很快投入状态;
  2. 测试对方的模块,能够在测试的同时检查自己的错误,测试的时候能够心中有数;
  3. 既是合作也是竞争,同时由于测试必须同时进行,一个人不来,另一个人也没办法开展工作,所以时间被拖延,这样也是培养他们的责任心。

这样,使用交叉结对测试的方法,其实也很好地缓解了第二、三、五个问题。”

我抢过测三通手上的酒,给老高满上:“高哥,这个我算明白了,你给我讲讲其他的吧。”

老高满意地点点头:“集中测试效率低下,很容易被打断。其实这个也很好理解,集中测试就是发现一些重要、明显的BUG的嘛,不要指望它能够带来多大的效果, 但是由于单独测试不可控,所以集中测试是很有必要的,你就把集中测试当成一个测试的热身,调动热血与气氛的工具就好了,可以适当地缩短集中测试的时间。”

我把手机调成的录音机,放在老高面前,生怕漏了一句。

老高顿了顿,说:“你说了许多集中测试的事,却不说单独对照测试,肯定不是因为单独测试很顺利,而是因为没人单独测试是不是。”

”是啊,除了我跟个别的开发,其他人都不照着测试用例测。”我如遇知己。

老高叹了口气:“这也难怪,我以前也遇到这种问题,原因无非以下几点:

  1. BUG改不完,没有时间单独测试;
  2. 利用测试用例做单独测试的习惯未养成,同时也缺乏良好的监督;
  3. 认为自己的本职不是测试,所以对测试有排斥;

怎么破呢?我的建议是:

  1. 规范测试用例,以及单独测试的任务,甚至可以作为绩效指标;
  2. 招聘专业测试。”

我已经打开自己的笔记本在做笔记了:“

  1. 使用交叉结对测试;
  2. 在中午午休之前做集中测试,并减少集中测试时间;
  3. 做测试激励,规范单独测试的任务;
  4. 招聘专业测试。”

老高:“嗯,你这小产品,做整理的本事还是不赖的嘛。行,那我就倾囊而出,下面讲讲测试流程的第三环–FIX任务流程。”

见我有些疑惑,老高点了根烟,狠狠抽了一口:“测试出问题,就得归类、整理、分配嘛。我现在随便给它起个名字,叫FIX任务流程。自创的名字,不用回忆了。”

原来如此,我对老高更崇拜了。我想我要是个女生,现在的样子肯定很花痴。

老高见我默认了他的命名,很高兴地继续讲了下去:“我按照任务的生命周期,把整个流程分成了四步:任务创建、任务处理、任务审核、任务归档。现在都是在线办公了,咱们也不能总用SVN这种传统工具不是,多不方便,如果公司没有开发自己的任务系统,那也可以用现成的。”

我急说:“是,我们公司用的就是在线办公,还不错。”

老高得意地吐个烟圈:“看来我还没过时。那你觉得怎么好用了,有哪些不好用的地方吗。”

我说:“还不错,不过确实也有不对劲的地方。

  1. 任务创建的时候,有的开发把自己发现的BUG提交上去,但他们描述的任务的风格不一样,有的描述问题,有的描述正确的做法,让那些修BUG的人看不懂;有 的开发把BUG给负责人,让他们去提交BUG,结果修BUG的人不知道这个BUG是谁提交的,到处找,遇到一个人就描述一遍,费劲;
  2. 改BUG的时候,有时候需要跨部门合作,可能需要产品、设计、服务端、前端等部门的同事参与,周期太长,他们也不见得有时间帮忙,总是拖拖拖;
  3. 有的问题,其实不是BUG,是产品设计上的问题,这时候要找负责该模块的产品确定,但是常常就是一个客户端改了,另一个根本不知道,好麻烦;
  4. 任务太多的时候,就需要归档,可是一个个归档特别耗时间,然后就是归档任务之后就不知道这个任务是怎么发现,怎么处理得了。”

老高笑道:“这些简单,我教你几招:

第一招,集中测试时,每个人一张纸,将BUG写在纸上,然后署名,由负责人去记录,同时任务创建的同事需要关注BUG的发现人;单独测试时,创建的任务默认关注自己。这样有几个好处:

  1. 集中测试时,BUG多、乱,这时候做记录很麻烦,不如用笔记;
  2. 由负责人做记录,文风统一了,理解起来不困难;
  3. 关注了BUG的发现人,遇到不理解的,或者不能重现的,可以快速准确地找到发现人;
  4. 为BUG的修复检查做准备,须BUG的发现人去检查BUG是否被修复,之后才能做归档处理。

其实,还有个好处。”老高露出一丝与刚才骗酒喝一样的诡异笑容:“出了问题,可以追究责任。但真实目的是让大家更有责任意识。”

我觉得老高真是个妙人,随便支了一招居然解决了五个问题。

老高接着说:“第二招,记录与通知。”

说完就静静地看着我,我当然知道什么意思,赶紧顺着他的意思,装成傻子:“什么意思。”

老高看看杯中的酒,缓缓地晃晃杯子:“记录就是时刻记录这些产品设计上的改动,不一定需要PRD,但一定要记着;通知就是做了修改后就通知两端的负责人,记住啦,别把别人当傻子,就叙述就好了,别过去就傻愣愣地问别人改了没。”

我拼命点头。

老高:“就这两招吧。跨部门的事情,其实你需要做的就是:

  1. 处好关系;
  2. 把问题整理好,别找到了别人还说不出个所以然来;
  3. 把测试的重要性强调强调再强调。至于任务归档这件事,我建议你不要随便归档,最好就是等到新版本上线并稳定后,再归档。”

老高喘了口气:“最后就是文档了,测试日报、周报,目的就是评估开发质量、对问题进行分析。你们既然用了在线工具,那么这个日报也不是问题。”

2-1

我没想到今夜居然有如此大的收获,三谢老高,准备离开。

测三通不知道什么时候已经冷冷地站在我背后,看我要离开,就冷冷地来了一句:“你没有把话讲完。”

我跟老高都看着他。

他好不容易有点存在感了,又在哪里卖关子:“我就看不惯你们这些做产品的,有什么话讲…….“

我跟老高同时冷冷地道:“有话就说,没事就滚。”

测三通彻底蔫了:“你们都避着人的事情不说,我当初就是处不好人情才出来做酒保的。”

我心一惊,没想到这衰货居然还有这种思考深度。

老高也把脸对着我,他的墨镜后面深邃的眼睛也一定盯着我看。

我喝了口酒:“好吧,人的确是很大的问题。除了前面的责任感与专业程度外,还有几个麻烦:

  1. 不可控的外界原因,比如紧急事件处理、测试场所被占、测试机不足等都会影响测试,甚至让测试停止;
  2. 人员的不可控,紧急任务的人员抽调,请假、离职都会导致人员不足;
  3. 非测试人员的参与,由于不了解测试的进展,胡乱创建任务、归档任务,导致了大量的重复任务,甚至有些人还直接来询问产品和开发,一个个都要讲清楚才行。增加了开发的负担,归档任务的就更麻烦了,直接找不回来了。”

“还有在测试的时候集中提需求的。”测三通补充道。

我看着老高,老高沉默良久,说:“这件事情,是解决不了了,只能缓解:

  1. 尽量做足准备,比如预约多个会议室,向公司多申请些测试机,或者让同事们借出等,做好备用方案;
  2. 强调,提升测试的重要性,不能因为周期长而认为测试不紧急;
  3. 尽可能地调整人员调派的时间,不予固定的测试时间冲突;
  4. 提高人员出借的难度,如果有人要借人,那么需要找负责人说明原因;
  5. 尽量控制非测试人员的权限,不允许直接向测试项目组添加、修改、归档任务;
  6. 非测试人员创建的人员,需要测试审核通过后,才能由测试负责人创建任务;
  7. BUG修复审核完成后,应该先归类到特别的任务组中,等到产品上线并稳定后才可以归档;
  8. 由项目负责人整理测试日报、周报发送给非测试人员,打消他们对测试进度的疑惑。”

我设置的零点闹钟响起,我必须回家了,明天还有许多工作去做。我再谢了老高,也辞别了测三通,离开酒吧。

出了酒吧,寒风袭来,我被酒染红的燥热的耳朵,感受到今年入冬以来最刺骨的寒意,但我还很兴奋,我的手机收到一条短信,原来是老高送我的十六字箴言:写好用例,处好关系,做好沟通,招个测试。

我回头看看这家不起眼的酒吧,霓虹灯上的有些灯泡已经熄灭,但我还是能够辨认:测马奔腾。

再会,离场不散场。我心说,然后扭过头,疾步离开。

#专栏作家#

朝聆夕改,人人都是产品经理专栏作家。移动应用客户端产品经理,关注移动社交、教育等领域;拒绝空谈的行动派,爱深度研究。

本文原创发布于人人都是产品经理,未经许可,不得转载。

您的赞赏,是对我创作的最大鼓励。

评论( 12

登录后参与评论
  1. 难道只有我一个人关心 。。这家酒吧的名字跟坐标吗?

    回复
  2. 弱问哈 那个项目管理工具是?

    回复
  3. 一股子韩利的问道啊!

    回复
  4. :roll:

    回复
  5. 其实还是有必要招一两个测试。看遍全文,一个产品经理 顶着 项目经理 + 测试经理双重职责,跟程序员说计算机语,与业务人员说人话,真不是一般的累啊

    回复
  6. 写作能力不错哦 ~

    回复
  7. 软软的干货 收藏了哈哈

    回复
  8. 故事型的说法,真不错

    回复
  9. :roll: 一个苦逼的测试人员

    回复
  10. 别具一格的文风,湿润的干货。

    回复
  11. 测试就找testin

    回复
  12. 不错 收藏了

    回复
加载中