周六,深夜,我拖着满是疲倦的身躯,四处闲逛,来到小巷一家还闪着霓虹的酒吧,我略一犹豫走了进去。酒吧冷冷清清,寥寥几对男女,在昏暗的灯光下切切私语,我没兴趣知道他们在说些什么,懒懒趴在吧台,酒保一脸贼像,笑嘻嘻问我想喝点什么,并向我推销他们的新品鸡尾酒,我不看他只说:啤酒。
  酒保自讨没趣,把酒摆在我面前,我眼神空洞,一口口喝酒。吧台上还坐着个戴着墨镜,满脸胡茬的大叔,喝着的也是啤酒。这时我的手机铃声响起,我挣扎两下,拿出手机,却看是总监打来的.
  没办法,接吧:“喂,总监。”
  总监:“朝聆夕改,你在干嘛?”
  我:“我....我在回家路上。”
  总监:“BUG处理得怎么样,是不是要发新版?”
  我:“嗯,BUG处理得差不多了,要发新版。不过研发的同事说怕再说问题,要多测两天再上......”
  总监:“那你还回什么家,好好测啊!当时测试的时候不好好测,现在倒想起来谨慎了.....”
  我:“好的,我继续测....”
  挂了电话,我木木地喝了口寒彻心扉的啤酒,准备再做几分钟回去。
  这时,旁边的大叔冷笑一声:“小伙子,你是产品吧?”
  我一激灵:“你怎么知道?”
  大叔抿了一口啤酒:“我不仅知道你是个产品经理,还知道你们公司人不多,你们公司没QA。”
  我手抖了抖,杯子掉在桌上,溅起的啤酒,冰凉了我的神经,我一下子清醒了。他猜的没错。我是个产品经理,移动互联产品经理,公司刚B轮,人确实不多,没有QA。
  我转过身去,看他,才发现其实他邋遢之余很是潇洒,昏暗的灯光下那闪闪的墨镜遮住了他深邃的眼睛,嘴角泛着浅浅笑意,胡茬还留存着啤酒的水渍....
  我一抱拳:“请问前辈高名?”
  他笑了:“别来那套文绉绉的,老子姓高,你可以叫我老高。以前是移动互联创业公司的产品总监,现在下海做生意,兼职算命。”
  得道高人!我知道我遇到高人了。
  他不看我:“是不是测试遇到麻烦了?”
  我低头:“嗯,公司没测试,我负责组织研发同事测试,结果测完上线,出现了机型适配的问题,只能重新发布...”
  他说:“你知道测试是什么吗?为什么你们公司没测试?你作为产品经理,却得做测试的工作?”
  我有点蒙:“测试,是一群人拿着手机测BUG啊,公司不是没招过测试,上次来的那个测试,看所有人下班了都没走,第二天不愿因来了.......我对产品熟啊,再说也缺人。”
  老高咂两下嘴:“错,错,错!测试是产品策划到上线维护中不可缺少的一环,测试质量的高低直接关系到产品的可用性,友好性,可靠性。虽然测试是必要的,但测试人员不是必要的,因此大多数的初创公司并不设置QA的岗位。
  同时,没有测试人员,其实也是一种敏捷的方式,facebook在从创立起很长一段时间里都是没有测试的。产品经理做测试,一方面是因为对产品熟,另外也是因为开发思维与测试思维是不同思维的原因,说了你也不懂。”
  我不服气,猛地喝了一口酒:“那你说说测试是什么?”
  他又笑:“从测试内容上看,测试主要分为UI测试、功能测试、兼容性和性能测试。UI测试是界面视觉的测试,找设计师测行了,兼容性和性能测试人力不可为,一般要借助工具测,但是必须测,像你们这种手机适配问题肯定是没走过这个流程。一般来说,产品跟研发做的是功能测试。测试是有许多方法的,但主要分为三类.....”
  “黑盒测试、白盒测试和沙盘测试!”原来是酒保打断,这厮在旁边偷听许久了,我还以为他是想趁我不注意给我倒酒。
  我说:“你还懂这个。”
  酒保贱贱一笑:“略懂,略懂,以前做测试的,花名测三通。”
  老高也有兴趣了:“那你说说什么是黑盒测试。”
  测三通:“黑盒测试,也可以叫不透明测试,它着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。
  主要方法:有等价类划分法、因果图法和错误推测法。等价类划分法是把产品按照模块进行划分成若干个部分,分人测试,一般公司都用这。因果图法是根据流程图,测试前、后置条件,从而推断是否可以正常使用的办法。”
  见我不太明白,他又补充说:“比如在购物车点击确定,但是购物车里是空的——返回“用户名错误”提醒,是一条因果图法的测试用例。白盒测试与黑盒测试互补,是透明测试,在于全面了解程序内部逻辑结构、对所有逻辑路径进行测试。沙盘测试像你们产品经理做竞品分析的时候做的那个什么....“
  老高提醒:“任务走查。”
  测三通:“嗷~任务走查,模拟用户在实际环境中的测试,也是把一个个用户场景都走通一遍把重要的逻辑漏洞过滤掉,一般产品上线前的回归测试用它。”
  真是人不可貌相,我深深看了测三通一眼,然后温柔地对他说:“倒酒。”
  老高补充说,其实还有许多测试内容,比如:
  · 排序测试
  · 字符测试
  · 缓存测试
  · 必要信息测试
  · 准确性测试
  在测试中是很容易忘记的,你好记住。”
  我拼命点头:“前辈教导的是,我们平时用的是黑盒测试,那你能跟我讲讲测试的流程吗?”
  老高用酒杯砸了砸桌子:“这个要好久(好酒)呀.....”
  我定睛一看:果然酒杯空了。
  我看了测三通一看:“倒酒,算我的!”
  测三通这小子早在旁边等着了,赶紧给老高倒了杯12年的人头牛。
  老高喝了口:“好酒,既然你这么有诚意我好好跟你说说。”
  我跟测三通都聚精会神地看着他。
  老高:“测试流程主要分为这么几步:
  1、测试资源准备;
  2、测试人员分工与选择测试方式;
  3、测试FIX任务。除此之外你还要准备相关文档。话说你叫什么名?”
  我这才想起我没做自我介绍:“哦哦,我叫朝聆夕改,你叫我小朝行了。”
  老高:“小改呀,你平时测试资料准备都准备些什么呀”
  我想了想:“主要是各种型号、操作系统的手机,有时候还需要给他们准备点纸笔。”
  老高点点头:“嗯,你说的是测试设备的准备。测试资料一般要准备下面几项:
  测试设置,除了你说的手机、纸笔外,你还要借场所,是会议室之类的,准备点小零食也是有好处的;
  测试坏境,一般是内测坏境、正式环境;
  测试账号,普通账号和特殊账号,都要多准备些,临时准备会影响测试人员的士气;
  测试人员,要预约好,安排规划,不然临时叫走,把你气的半死;
  测试用例,这儿是产品测试的核心,是对产品的所有节目的视觉、交互和功能逻辑的汇总。”
  测三通插嘴:“这个测试用例可得好好讲讲。”
  我冷冷地看了他一眼:“你也要请喝酒吗?”
  测三通闭嘴。
  老高呵呵一笑:“当然,不讲测试用例算什么测试。
  测试用例撰写的原则有这么几种:
  有效性,是说测试用例必须是真实有效的,不同的测试人员依据相同的测试用例所得到的输出应该是一致的;
  复用性,不用写的太死,能复制好,要不然一个小产品随随便便几千个,累都累死你了;
  易组织性,写用例的时候好能考虑到测试的场景,别上一个用例写的是A页面,下一个又跑到C页面去了,当然产品经理还是有这个思维的;
  还有其他原则,比如可评估性,可管理性,太专业了不太重要,原则有几个够了。
  得,我先上个厕所。”
  说罢,他扶着墙去厕所了。
  老高真是教科书一样的人物,只可惜,人到中年双目失明...我正在替他感到悲哀,听到老高远远地在厕所门口喊:“你这贼酒保,又趁我不在给我倒酒是不是!"
  测三通,僵住了正在偷偷倒酒的手臂,尴尬地说:“哎呀,你老身体健康好,没事戴什么墨镜算命呐,我想做点好事,请您喝杯酒......“
  老高大步流星走到位置,不客气地猛喝一口:“原来是这样,三通你这年轻人不错,我看好你。”
  测三通讪讪而退,我看看老高,他正摘下眼镜朝我眨眼:原来是装的,骗酒喝!
  我苦笑:“前辈,咱们接着说测试用例吧。”
  老高:“好嘞,刚说了原则,下面说说类型,类型这么几种:
  基本功能用例、交互用例、临界用例还有压力测试。前面三种你应该都懂,后一种压力测试一般人不懂了,压力测试一般是指在比较短的一段时间内,被测手机执行比较多的任务或者操作,来检测被测手机承受压力的能力。这个测试还是比较有必要的,知道了也可以装X。”
  我深以为然:“前辈,我也写了一些测试用例,请您指点。”

 

  老高看完我的测试用例,点点头:“小改,其实这够了。测试用例在内容上可以分为两个部分:测试信息和用例信息。
  测试信息包涵了测试人、测试时间、测试版本号、测试机型、操作系统以及测试的结果统计;
  用例信息主要包涵用例所属模块、用例ID、用例事件描述、前置条件、期望结果以及测试结果等。”
  老高顿了顿,说:“这是黑盒测试的用例,如果是沙盘测试或者白盒测试,用例会复杂许多,往往需要流程图之类的,如果是成熟的,或者传统公司对测试的流程要多许多,你是用不着学的。”
  我得到了前辈的认可,还是有些欣喜:“那该说说测试分工的事情了。”
  老高:“那你们平时怎么分工的。”
  我说:“找两端的主管要些人,然后随即分模块给他们,把测试用例分给他们,下午的时候组织一下集中测试。”
  老高摇摇头:“效果怎么样。”
  我品了品苦涩的啤酒:“不太好。”
  老高:“具体表现呢,列举出来,你个产品总得有点逻辑能力吧。”
  我掐了掐自己已经快麻木的大腿,强打起精神:“那我可得好好吐槽一下:
  1、集中测试的时间缩水太严重,每次召集人手都要几十分钟,还经常检查出BUG马上去改,一次集中测试要测1~2小时;
  2、集中测试效率低下,测试时很容易被与自己测试内容不相关的部分打断;
  3、负责测试的研发同事对产品不熟悉,要跟他们讲,特费时间效果还不好;
  4、单独测试不能很好执行,不可控;
  5、经常性被不同的人提出重复的BUG,浪费时间。”
  老高哈哈一笑:看来你很清楚出现的问题呀,可是你还是不能解决是不是。
  我:“是啊,请前辈指教。”
  老高挥挥手:“叫老高行了,指教谈不上,兵法有云:知己知彼,百战不殆。你既然知道问题,也应该知道出现问题的原因。第一条,集中测试太费时间,主要的原因是这么几个方面:
  1、没有很好的时间规划,测试人员不知道什么时候测什么时候停止测,建议你们的集中测试由下午改成中午,到午休的时候自动停止,这样至少有个停止的时候,让测试人员能够自觉调节测试的速度,同时下午的时间其实更有弹性,你懂得,改不完的可以加班嘛;
  2、人气不足,可能是你在公司呆的不久,跟开发不是很熟,更重要的是没有建立那种说一不二的威信,所以你得以身作则,梳理形象;
  3、测试人员责任心不足,这是怎么回事,你知道乌合之众这个词吧,差不多是说群体会降低每个人的智慧,大家嘻嘻哈哈没当回事,自然不行。这时候我建议你使用交叉结对测试的方法测试。
  4、测试人员动力不足。没奖励呀,你得多鼓励鼓励才行,有鼓励师没?”