测试流程主要分为这么几步，
- 测试资源准备；
- 测试人员分工与选择测试方式；
- 测试FIX任务。除此之外你还要准备相关文档。
测试资料一般要准备下面几项：
- 测试设置，除了你说的手机、纸笔外，你还要借场所，就是会议室之类的，准备点小零食也是有好处的；
- 测试坏境，一般就是内测坏境、正式环境；
- 测试账号，普通账号和特殊账号，都要多准备些，临时准备会影响测试人员的士气；
- 测试人员，要预约好，安排规划，不然临时就叫走，把你气的半死；
- 测试用例，这儿是产品测试的核心，是对产品的所有节目的视觉、交互和功能逻辑的汇总。
注：测试用例撰写的原则有这么几种：
- 有效性，就是说测试用例必须是真实有效的，不同的测试人员依据相同的测试用例所得到的输出应该是一致的；
- 复用性，不用写的太死，能复制最好，要不然一个小产品就随随便便几千个，累都累死你了；
- 易组织性，写用例的时候最好能考虑到测试的场景，别上一个用例写的是A页面，下一个又跑到C页面去了，当然产品经理还是有这个思维的；
还有其他原则，比如可评估性，可管理性，太专业了不太重要，原则有几个就够了。 基本功能用例、交互用例、临界用例还有压力测试。前面三种你应该都懂，最后一种压力测试一般人就不懂了，压力测试一般是指在比较短的一段时间内，被测手机执行比较多的任务或者操作，来检测被测手机承受压力的能力。这个测试还是比较有必要的，知道了也可以装X。 测试用例在内容上可以分为两个部分：测试信息和用例信息。
- 测试信息包涵了测试人、测试时间、测试版本号、测试机型、操作系统以及测试的结果统计；
- 用例信息主要包涵用例所属模块、用例ID、用例事件描述、前置条件、期望结果以及测试结果等。
交叉结对测试，就是指安卓和iOS两端的负责同一个模块的开发人员，组成队伍，相互测试对方的客户端。有点拗口，但很有用处：
- 由于是负责自己开发的模块，所以不需要学习，能够很快投入状态；
- 测试对方的模块，能够在测试的同时检查自己的错误，测试的时候能够心中有数；
- 既是合作也是竞争，同时由于测试必须同时进行，一个人不来，另一个人也没办法开展工作，所以时间被拖延，这样也是培养他们的责任心。
遇到这种问题，原因无非以下几点：
- BUG改不完，没有时间单独测试；
- 利用测试用例做单独测试的习惯未养成，同时也缺乏良好的监督；
- 认为自己的本职不是测试，所以对测试有排斥；
怎么破呢？我的建议是：
- 规范测试用例，以及单独测试的任务，甚至可以作为绩效指标；
- 招聘专业测试。”
我已经打开自己的笔记本在做笔记了:“
- 使用交叉结对测试；
- 在中午午休之前做集中测试，并减少集中测试时间；
- 做测试激励，规范单独测试的任务；
- 招聘专业测试。”
测试出问题，就得归类、整理、分配嘛。我现在随便给它起个名字，叫FIX任务流程。自创的名字，不用回忆了。”
我按照任务的生命周期，把整个流程分成了四步：任务创建、任务处理、任务审核、任务归档。现在都是在线办公了，咱们也不能总用SVN这种传统工具不是，多不方便，如果公司没有开发自己的任务系统，那也可以用现成的。
第一招，集中测试时，每个人一张纸，将BUG写在纸上，然后署名，由负责人去记录，同时任务创建的同事需要关注BUG的发现人；单独测试时，创建的任务默认关注自己。这样有几个好处：
- 集中测试时，BUG多、乱，这时候做记录很麻烦，不如用笔记；
- 由负责人做记录，文风统一了，理解起来不困难；
- 关注了BUG的发现人，遇到不理解的，或者不能重现的，可以快速准确地找到发现人；
- 为BUG的修复检查做准备，须BUG的发现人去检查BUG是否被修复，之后才能做归档处理。
第二招，记录与通知。
记录就是时刻记录这些产品设计上的改动，不一定需要PRD，但一定要记着；通知就是做了修改后就通知两端的负责人，记住啦，别把别人当傻子，就叙述就好了，别过去就傻愣愣地问别人改了没。
- 处好关系；
- 把问题整理好，别找到了别人还说不出个所以然来；
- 把测试的重要性强调强调再强调。至于任务归档这件事，我建议你不要随便归档，最好就是等到新版本上线并稳定后，再归档。
最后就是文档了，测试日报、周报，目的就是评估开发质量、对问题进行分析。你们既然用了在线工具，那么这个日报也不是问题。
人的确是很大的问题。除了前面的责任感与专业程度外，还有几个麻烦：
- 不可控的外界原因，比如紧急事件处理、测试场所被占、测试机不足等都会影响测试，甚至让测试停止；
- 人员的不可控，紧急任务的人员抽调，请假、离职都会导致人员不足；
- 非测试人员的参与，由于不了解测试的进展，胡乱创建任务、归档任务，导致了大量的重复任务，甚至有些人还直接来询问产品和开发，一个个都要讲清楚才行。增加了开发的负担，归档任务的就更麻烦了，直接找不回来了。”
“还有在测试的时候集中提需求的。”测三通补充道。
我看着老高，老高沉默良久，说：“这件事情，是解决不了了，只能缓解：
- 尽量做足准备，比如预约多个会议室，向公司多申请些测试机，或者让同事们借出等，做好备用方案；
- 强调，提升测试的重要性，不能因为周期长而认为测试不紧急；
- 尽可能地调整人员调派的时间，不予固定的测试时间冲突；
- 提高人员出借的难度，如果有人要借人，那么需要找负责人说明原因；
- 尽量控制非测试人员的权限，不允许直接向测试项目组添加、修改、归档任务；
- 非测试人员创建的人员，需要测试审核通过后，才能由测试负责人创建任务；
- BUG修复审核完成后，应该先归类到特别的任务组中，等到产品上线并稳定后才可以归档；
- 由项目负责人整理测试日报、周报发送给非测试人员，打消他们对测试进度的疑惑。”
十六字箴言：写好用例，处好关系，做好沟通，招个测试。
|
