产品经理做测试那些事儿

　　周六，深夜，我拖着满是疲倦的身躯，四处闲逛，来到小巷一家还闪着霓虹的酒吧，我略一犹豫走了进去。
　　酒吧冷冷清清，寥寥几对男女，在昏暗的灯光下切切私语，我没兴趣知道他们在说些什么，懒懒趴在吧台，酒保一脸贼像，笑嘻嘻问我想喝点什么，并向我推销他们的新品鸡尾酒，我不看他，只说：啤酒。
　　酒保自讨没趣，把酒摆在我面前，我眼神空洞，一口口喝酒。
　　吧台上还坐着个戴着墨镜，满脸胡茬的大叔，喝着的也是啤酒。
　　这时我的手机铃声响起，我挣扎两下，拿出手机，却看是总监打来的。
　　没办法，接吧：“喂，总监。”
　　总监：“朝聆夕改，你在干嘛？”
　　我：“我。我在回家路上。”
　　总监：“BUG处理得怎么样，是不是要发新版？”
　　我：“嗯，BUG处理得差不多了，要发新版。不过研发的同事说怕再说问题，要多测两天再上”
　　总监：“那你还回什么家，好好测啊！当时测试的时候不好好测，现在倒想起来谨慎了。。”
　　我：“好的，我周末继续测。”
　　挂了电话，我木木地喝了口寒彻心扉的啤酒，准备再做几分钟就回去。
　　这时，旁边的大叔冷笑一声：“小伙子，你是产品吧？”
　　我一激灵：“你怎么知道？”
　　大叔抿了一口啤酒：“我不仅知道你是个产品经理，还知道你们公司人不多，你们公司没QA。”
　　我手抖了抖，杯子掉在桌上，溅起的啤酒，冰凉了我的神经，我一下子清醒了。
　　他猜的没错。我是个产品经理，移动互联产品经理，公司刚B轮，人确实不多，没有QA。
　　我转过身去，看他，才发现其实他邋遢之余很是潇洒，昏暗的灯光下那闪闪的墨镜遮住了他深邃的眼睛，嘴角泛着浅浅笑意，胡茬还留存着啤酒的水渍。
　　我一抱拳：“请问前辈高名？”
　　他笑了：“别来那套文绉绉的，老子姓高，你可以叫我老高。以前是移动互联创业公司的产品总监，现在下海做生意，兼职算命。”
　　得道高人！我知道我今天遇到高人了。
　　他不看我：“是不是测试遇到麻烦了？”
　　我低头：“嗯，公司没测试，我负责组织研发同事测试，结果测完上线，出现了机型适配的问题，只能重新发布”
　　他说：“你知道测试是什么吗？为什么你们公司没测试？你作为产品经理，却得做测试的工作？”
　　我有点蒙：“测试，就是一群人拿着手机测BUG啊，公司不是没招过测试，上次来的那个测试，看所有人下班了都没走，第二天就不愿因来了。我对产品最熟啊，再说也缺人。”
　　老高咂两下嘴：“错，错，错！测试是产品策划到上线维护中不可缺少的一环，测试质量的高低直接关系到产品的可用性，友好性，可靠性。虽然测试是必要的，但测试人员不是必要的，因此大多数的初创公司并不设置QA的岗位。同时，没有测试人员，其实也是一种敏捷的方式，facebook在从创立起很长一段时间里都是没有测试的。产品经理做测试，一方面是因为对产品最熟，另外也是因为开发思维与测试思维是不同思维的原因，说了你也不懂。”
　　我不服气，猛地喝了一口酒：“那你说说测试是什么？”
　　他又笑：“从测试内容上看，测试主要分为UI测试、功能测试、兼容性和性能测试。UI测试就是界面视觉的测试，找设计师测就行了，兼容性和性能测试人力不可为，一般要借助工具测，但是必须测，像你们这种手机适配问题肯定是没走过这个流程。一般来说，产品跟研发做的就是功能测试。测试是有许多方法的，但主要分为三类。。”
　　“黑盒测试、白盒测试和沙盘测试！”原来是酒保打断，这厮在旁边偷听许久了，我还以为他是想趁我不注意给我倒酒。
　　我说：“你还懂这个。”
　　酒保贱贱一笑：“略懂，略懂，以前做测试的，花名测三通。”
　　老高也有兴趣了：“那你说说什么是黑盒测试。”
　　测三通：“黑盒测试，也可以叫不透明测试，它着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。主要方法有等价类划分法、因果图法和错误推测法。等价类划分法就是把产品按照模块进行划分成若干个部分，分人测试，一般公司都用这。因果图法就是根据流程图，测试前、后置条件，从而推断是否可以正常使用的办法。”
　　见我不太明白，他又补充说：“比如在购物车点击确定，但是购物车里是空的返回“用户名错误”提醒，就是一条因果图法的测试用例。白盒测试与黑盒测试互补，是透明测试，在于全面了解程序内部逻辑结构、对所有逻辑路径进行测试。沙盘测试就像你们产品经理做竞品分析的时候做的那个什么。“
　　老高提醒：“任务走查。”
　　测三通：“嗷任务走查，模拟用户在实际环境中的测试，也就是把一个个用户场景都走通一遍把重要的逻辑漏洞过滤掉，一般产品上线前的回归测试就用它。”
　　真是人不可貌相，我深深看了测三通一眼，然后温柔地对他说：“倒酒。”
　　老高补充说：“其实还有许多测试内容，比如：
　　排序测试
　　字符测试
　　缓存测试
　　必要信息测试
　　准确性测试
　　在测试中是很容易忘记的，你最好记住。”
　　我拼命点头：“前辈教导的是，我们平时用的就是黑盒测试，那你能跟我讲讲测试的流程吗？”
　　老高用酒杯砸了砸桌子：“这个要好久（好酒）呀。。”
　　我定睛一看：果然酒杯空了。
　　我看了测三通一看：“倒酒，算我的！”
　　测三通这小子早就在旁边等着了，赶紧给老高倒了杯12年的人头牛。
　　老高喝了口：“好酒，既然你这么有诚意我就好好跟你说说。”
　　我跟测三通都聚精会神地看着他。
　　老高：“测试流程主要分为这么几步，
　　测试资源准备；
　　测试人员分工与选择测试方式；
　　测试FIX任务。除此之外你还要准备相关文档。话说你叫什么名？”
　　我这才想起我没做自我介绍：“哦哦，我叫朝聆夕改，你叫我小朝就行了。”
　　老高：“小改呀，你平时测试资料准备都准备些什么呀”
　　我想了想：“主要就是各种型号、操作系统的手机，有时候还需要给他们准备点纸笔。”
　　老高点点头：“嗯，你说的是测试设备的准备。测试资料一般要准备下面几项：
　　测试设置，除了你说的手机、纸笔外，你还要借场所，就是会议室之类的，准备点小零食也是有好处的；
　　测试坏境，一般就是内测坏境、正式环境；
　　测试账号，普通账号和特殊账号，都要多准备些，临时准备会影响测试人员的士气；
　　测试人员，要预约好，安排规划，不然临时就叫走，把你气的半死；
　　测试用例，这儿是产品测试的核心，是对产品的所有节目的视觉、交互和功能逻辑的汇总。”
　　测三通插嘴：“这个测试用例可得好好讲讲。”
　　我冷冷地看了他一眼：“你也要请喝酒吗？”
　　测三通闭嘴。
　　老高呵呵一笑：“当然，不讲测试用例算什么测试。
　　测试用例撰写的原则有这么几种：
　　有效性，就是说测试用例必须是真实有效的，不同的测试人员依据相同的测试用例所得到的输出应该是一致的；
　　复用性，不用写的太死，能复制最好，要不然一个小产品就随随便便几千个，累都累死你了；
　　易组织性，写用例的时候最好能考虑到测试的场景，别上一个用例写的是A页面，下一个又跑到C页面去了，当然产品经理还是有这个思维的；
　　还有其他原则，比如可评估性，可管理性，太专业了不太重要，原则有几个就够了。
　　得，我先上个厕所。”
　　说罢，他扶着墙去厕所了。
　　老高真是教科书一样的人物，只可惜，人到中年就双目失明我正在替他感到悲哀，就听到老高远远地就在厕所门口喊：“你这贼酒保，又趁我不在给我倒酒是不是！”
　　测三通，僵住了正在偷偷倒酒的手臂，尴尬地说：“哎呀，你老身体健康就好，没事戴什么墨镜算命呐，我就想做点好事，请您喝杯酒“
　　老高大步流星走到位置，不客气地猛喝一口：“原来是这样，三通你这年轻人不错，我看好你。”
　　测三通讪讪而退，我看看老高，他正摘下眼镜朝我眨眼：原来是装的，骗酒喝！
　　我苦笑：“前辈，咱们接着说测试用例吧。”
　　老高：“好嘞，刚说了原则，下面说说类型，类型就这么几种：
　　基本功能用例、交互用例、临界用例还有压力测试。前面三种你应该都懂，最后一种压力测试一般人就不懂了，压力测试一般是指在比较短的一段时间内，被测手机执行比较多的任务或者操作，来检测被测手机承受压力的能力。这个测试还是比较有必要的，知道了也可以装X。”
　　我深以为然：“前辈，我也写了一些测试用例，请您指点。”
　　老高看完我的测试用例，点点头：“小改，其实这就够了。测试用例在内容上可以分为两个部分：测试信息和用例信息。
　　测试信息包涵了测试人、测试时间、测试版本号、测试机型、操作系统以及测试的结果统计；
　　用例信息主要包涵用例所属模块、用例ID、用例事件描述、前置条件、期望结果以及测试结果等。”
　　老高顿了顿，说：“这是黑盒测试的用例，如果是沙盘测试或者白盒测试，用例就会复杂许多，往往需要流程图之类的，如果是成熟的，或者传统公司对测试的流程就要多许多，你是用不着学的。”
　　我得到了前辈的认可，还是有些欣喜：“那该说说测试分工的事情了。”
　　老高：“那你们平时怎么分工的。”
　　我说：“就找两端的主管要些人，然后随即分模块给他们，把测试用例分给他们，下午的时候组织一下集中测试。”
　　老高摇摇头：“效果怎么样。”
　　我品了品苦涩的啤酒：“不太好。”
　　老高：“具体表现呢，列举出来，你个产品总得有点逻辑能力吧。”
　　我掐了掐自己已经快麻木的大腿，强打起精神：“那我可得好好吐槽一下：
　　集中测试的时间缩水太严重，每次召集人手都要几十分钟，还经常检查出BUG就马上去改，一次集中测试要测12小时；
　　集中测试效率低下，测试时很容易被与自己测试内容不相关的部分打断；
　　负责测试的研发同事对产品不熟悉，要跟他们讲，特费时间，效果还不好；
　　单独测试不能很好执行，不可控；
　　经常性被不同的人提出重复的BUG，浪费时间。”
　　老高哈哈一笑：“看来你很清楚出现的问题呀，可是你还是不能解决是不是。”
　　我：“是啊，请前辈指教。”
　　老高挥挥手：“叫老高就行了，指教谈不上，兵法有云：知己知彼，百战不殆。你既然知道问题，也应该知道出现问题的原因。第一条，集中测试太费时间，主要的原因是这么几个方面：
　　没有很好的时间规划，测试人员不知道什么时候测什么时候停止测，建议你们的集中测试由下午改成中午，到午休的时候自动停止，这样至少有个停止的时候，让测试人员能够自觉调节测试的速度，同时下午的时间其实更有弹性，你懂得，改不完的可以加班嘛；
　　人气不足，可能是你在公司呆的不久，跟开发不是很熟，更重要的是没有建立那种说一不二的威信，所以你得以身作则，梳理形象；
　　测试人员责任心不足，这是怎么回事，你知道乌合之众这个词吧，差不多就是说群体会降低每个人的智慧，大家嘻嘻哈哈没当回事，自然不行。这时候我建议你使用交叉结对测试的方法测试。
　　测试人员动力不足。没奖励呀，你得多鼓励鼓励才行，有鼓励师没？”
　　我张张嘴，还没说话，老高就打断了我：“没有是吧，那就物质奖励，前面说测试资料准备的时候不是也提了准备零食吗，这时候就得上啊。”
　　我皱皱眉：“老高，那个什么交叉结对测试是什么意思？我只听说过交叉测试。”
　　老高眯了眯眼睛：“交叉结对测试，就是指安卓和iOS两端的负责同一个模块的开发人员，组成队伍，相互测试对方的客户端。有点拗口，但很有用处：
　　由于是负责自己开发的模块，所以不需要学习，能够很快投入状态；
　　测试对方的模块，能够在测试的同时检查自己的错误，测试的时候能够心中有数；
　　既是合作也是竞争，同时由于测试必须同时进行，一个人不来，另一个人也没办法开展工作，所以时间被拖延，这样也是培养他们的责任心。
　　这样，使用交叉结对测试的方法，其实也很好地缓解了第二、三、五个问题。”
　　我抢过测三通手上的酒，给老高满上：“高哥，这个我算明白了，你给我讲讲其他的吧。”
　　老高满意地点点头：“集中测试效率低下，很容易被打断。其实这个也很好理解，集中测试就是发现一些重要、明显的BUG的嘛，不要指望它能够带来多大的效果，但是由于单独测试不可控，所以集中测试是很有必要的，你就把集中测试当成一个测试的热身，调动热血与气氛的工具就好了，可以适当地缩短集中测试的时间。”
　　我把手机调成的录音机，放在老高面前，生怕漏了一句。
　　老高顿了顿，说：“你说了许多集中测试的事，却不说单独对照测试，肯定不是因为单独测试很顺利，而是因为没人单独测试是不是。”
　　”是啊，除了我跟个别的开发，其他人都不照着测试用例测。”我如遇知己。
　　老高叹了口气：“这也难怪，我以前也遇到这种问题，原因无非以下几点：
　　BUG改不完，没有时间单独测试；
　　利用测试用例做单独测试的习惯未养成，同时也缺乏良好的监督；
　　认为自己的本职不是测试，所以对测试有排斥；
　　怎么破呢？我的建议是：
　　规范测试用例，以及单独测试的任务，甚至可以作为绩效指标；
　　招聘专业测试。”
　　我已经打开自己的笔记本在做笔记了：“
　　使用交叉结对测试；
　　在中午午休之前做集中测试，并减少集中测试时间；
　　做测试激励，规范单独测试的任务；
　　招聘专业测试。”
　　老高：“嗯，你这小产品，做整理的本事还是不赖的嘛。行，那我就倾囊而出，下面讲讲测试流程的第三环FIX任务流程。”
　　见我有些疑惑，老高点了根烟，狠狠抽了一口：“测试出问题，就得归类、整理、分配嘛。我现在随便给它起个名字，叫FIX任务流程。自创的名字，不用回忆了。”
　　原来如此，我对老高更崇拜了。我想我要是个女生，现在的样子肯定很花痴。
　　老高见我默认了他的命名，很高兴地继续讲了下去：“我按照任务的生命周期，把整个流程分成了四步：任务创建、任务处理、任务审核、任务归档。现在都是在线办公了，咱们也不能总用SVN这种传统工具不是，多不方便，如果公司没有开发自己的任务系统，那也可以用现成的。”
　　我急说：“是，我们公司用的就是在线办公，还不错。”
　　老高得意地吐个烟圈：“看来我还没过时。那你觉得怎么好用了，有哪些不好用的地方吗。”
　　我说：“还不错，不过确实也有不对劲的地方。
　　任务创建的时候，有的开发把自己发现的BUG提交上去，但他们描述的任务的风格不一样，有的描述问题，有的描述正确的做法，让那些修BUG的人看不懂；有的开发把BUG给负责人，让他们去提交BUG，结果修BUG的人不知道这个BUG是谁提交的，到处找，遇到一个人就描述一遍，费劲；
　　改BUG的时候，有时候需要跨部门合作，可能需要产品、设计、服务端、前端等部门的同事参与，周期太长，他们也不见得有时间帮忙，总是拖拖拖；
　　有的问题，其实不是BUG，是产品设计上的问题，这时候要找负责该模块的产品确定，但是常常就是一个客户端改了，另一个根本不知道，好麻烦；
　　任务太多的时候，就需要归档，可是一个个归档特别耗时间，然后就是归档任务之后就不知道这个任务是怎么发现，怎么处理得了。”
　　老高笑道：“这些简单，我教你几招：
　　第一招，集中测试时，每个人一张纸，将BUG写在纸上，然后署名，由负责人去记录，同时任务创建的同事需要关注BUG的发现人；单独测试时，创建的任务默认关注自己。这样有几个好处：
　　集中测试时，BUG多、乱，这时候做记录很麻烦，不如用笔记；
　　由负责人做记录，文风统一了，理解起来不困难；
　　关注了BUG的发现人，遇到不理解的，或者不能重现的，可以快速准确地找到发现人；
　　为BUG的修复检查做准备，须BUG的发现人去检查BUG是否被修复，之后才能做归档处理。
　　其实，还有个好处。”老高露出一丝与刚才骗酒喝一样的诡异笑容：“出了问题，可以追究责任。但真实目的是让大家更有责任意识。”
　　我觉得老高真是个妙人，随便支了一招居然解决了五个问题。
　　老高接着说：“第二招，记录与通知。”
　　说完就静静地看着我，我当然知道什么意思，赶紧顺着他的意思，装成傻子：“什么意思。”
　　老高看看杯中的酒，缓缓地晃晃杯子：“记录就是时刻记录这些产品设计上的改动，不一定需要PRD，但一定要记着；通知就是做了修改后就通知两端的负责人，记住啦，别把别人当傻子，就叙述就好了，别过去就傻愣愣地问别人改了没。”
　　我拼命点头。
　　老高：“就这两招吧。跨部门的事情，其实你需要做的就是：
　　处好关系；
　　把问题整理好，别找到了别人还说不出个所以然来；
　　把测试的重要性强调强调再强调。至于任务归档这件事，我建议你不要随便归档，最好就是等到新版本上线并稳定后，再归档。”
　　老高喘了口气：“最后就是文档了，测试日报、周报，目的就是评估开发质量、对问题进行分析。你们既然用了在线工具，那么这个日报也不是问题。”
　　我没想到今夜居然有如此大的收获，三谢老高，准备离开。
　　测三通不知道什么时候已经冷冷地站在我背后，看我要离开，就冷冷地来了一句：“你没有把话讲完。”
　　我跟老高都看着他。
　　他好不容易有点存在感了，又在哪里卖关子：“我就看不惯你们这些做产品的，有什么话讲。“
　　我跟老高同时冷冷地道：“有话就说，没事就滚。”
　　测三通彻底蔫了：“你们都避着人的事情不说，我当初就是处不好人情才出来做酒保的。”
　　我心一惊，没想到这衰货居然还有这种思考深度。
　　老高也把脸对着我，他的墨镜后面深邃的眼睛也一定盯着我看。
　　我喝了口酒：“好吧，人的确是很大的问题。除了前面的责任感与专业程度外，还有几个麻烦：
　　不可控的外界原因，比如紧急事件处理、测试场所被占、测试机不足等都会影响测试，甚至让测试停止；
　　人员的不可控，紧急任务的人员抽调，请假、离职都会导致人员不足；
　　非测试人员的参与，由于不了解测试的进展，胡乱创建任务、归档任务，导致了大量的重复任务，甚至有些人还直接来询问产品和开发，一个个都要讲清楚才行。增加了开发的负担，归档任务的就更麻烦了，直接找不回来了。”
　　“还有在测试的时候集中提需求的。”测三通补充道。
　　我看着老高，老高沉默良久，说：“这件事情，是解决不了了，只能缓解：
　　尽量做足准备，比如预约多个会议室，向公司多申请些测试机，或者让同事们借出等，做好备用方案；
　　强调，提升测试的重要性，不能因为周期长而认为测试不紧急；
　　尽可能地调整人员调派的时间，不予固定的测试时间冲突；
　　提高人员出借的难度，如果有人要借人，那么需要找负责人说明原因；
　　尽量控制非测试人员的权限，不允许直接向测试项目组添加、修改、归档任务；
　　非测试人员创建的人员，需要测试审核通过后，才能由测试负责人创建任务；
　　BUG修复审核完成后，应该先归类到特别的任务组中，等到产品上线并稳定后才可以归档；
　　由项目负责人整理测试日报、周报发送给非测试人员，打消他们对测试进度的疑惑。”
　　我设置的零点闹钟响起，我必须回家了，明天还有许多工作去做。我再谢了老高，也辞别了测三通，离开酒吧。
　　出了酒吧，寒风袭来，我被酒染红的燥热的耳朵，感受到今年入冬以来最刺骨的寒意，但我还很兴奋，我的手机收到一条短信，原来是老高送我的十六字箴言：写好用例，处好关系，做好沟通，招个测试。
　　我回头看看这家不起眼的酒吧，霓虹灯上的有些灯泡已经熄灭，但我还是能够辨认：测马奔腾。