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

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

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

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

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

　　没办法，接吧：“喂，总监。”

　　总监：“朝聆夕改，你在干嘛?”

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

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

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

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

　　我：“好的，我周末继续测….”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　我说：“你还懂这个。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　老高：“测试流程主要分为这么几步，

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

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

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

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

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

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

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

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

　　测三通闭嘴。

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

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

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

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

　　得，我先上个厕所。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　我：“是啊，请前辈指教。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　怎么破呢?我的建议是：

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

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

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

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

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

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

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

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

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

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

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

　　老高笑道：“这些简单，我教你几招：

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

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

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

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

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

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

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

　　我拼命点头。

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

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

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

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

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

　　我跟老高都看着他。

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

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

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

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

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

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

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

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

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

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

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

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

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

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