身为一个专业的 QA 当然需要有自己的测试原则，这些测试原则不仅可以帮助我们提高产品质量，对外还能体现出我们的专业性，从而让合作方后续还有意愿跟我们合作。下面是我按照测试过程中的各个阶段给到的一些工作准则建议。
1 测试前
1.1 需求评审
必须参与，有问题随时提出，如果涉及到相关背景信息，让相关同学同步一下背景信息。
1.2 技术评审
不管能否听懂，必须参与。
1.2.1 测试排期
在研发同学技术评审完之后，研发同学基本上可以预估自己需要多长的开发时间，所以往往技术评审会上会给出开发排期和提测时间点，这时需要我们给出我们 QA 的测试排期，下面是一个我根据经验总结出来测试排期策略测试排期估时多长合理？：
1、以研发同学的总开发工时的一半为基调，比如如果前后端同学排期加起来 10 天，那我们的测试时间就折半，初步定在 5 ~ 6 天
2、考虑需求的复杂程度，复杂程度从两方面体现，一是前端跟后端的改动比例，二是修改的链路长度，如果大部分是后端改动或者修改的链路较长，排期可以稍微多一两天，反之，如果大部分是前端样式的改动或者改动的链路较短，可以适当缩短排期或者维持排期不变。
3、考虑业务风险程度，对于涉及到风险程度较高的功能需求，比如涉及到账单结算这样的需求，可能排期会稍微多一两天。
4、结合开发同学一贯的提测质量，如果提测质量一贯较高而且改 bug 一直都很高效，这时可以适当缩短排期或者维持排期不变，否则适当加长排期估时。
5、想想自己在测试过程中还有哪些事需要并行的做，大概会占用多少时间，在初步确定的时间上进行调整
注意：排期不要定得太紧张，给自己留点 buffer，特别是当自己不是全人力都在当前需求测试时，更需要考虑到这方面，尽可能把排期时间加长一些。遇到特别没把握不确定的，可以先说第一次测这块业务或者这段时间还有xxx事在并行地做，估时先估这么长时间，后面如果提前测完则提前上线，但也不要估时太长，这样会让开发和产品同学觉得你能力不行。。。
1.3 编写checklist
1.3.1 checklist 模板
checklist 文档格式推荐使用思维导图。比如 MindMaster 和 processon。我喜欢用这些平台或者软件的思维导图大纲模式来编写 checklist。
包含的内容：checklist 最重要的当然是测试用例，除此之外，附上相关依赖文件和测试数据，包括：prd，技术文档，测试账号，测试数据，测试平台，测试环境，图例（用红色背景标记出 P0 的冒烟 case，蓝绿色标记 checklist 评审时新增的 case ，疑问用黄色背景标注，深蓝色标记checklist 评审后决定删除的 case ）等等。checklist 编写指南
注意：多想想需不需要验证数据库或者查询日志关键字来验证链路节点的正确性，而不仅仅是关注黑盒入口数据和返回数据，这种是冒烟case 的测试过程，但是对于正式测试来说这不够精细。
1.3.2 checklist 编写时间
如果上个需求测试过程中研发同学改 bug 的时间较多导致我们需要断断续续地测试，那可以在闲暇时间熟悉下个需求并输出 checklist，如果上个需求研发同学改 bug 的时间较少，对我们来说主要是连续的测试，可以在上个需求的测试过程中暂停半天或者一天，输出 checklist，尽量在需求提测前写好 checklist，这样主要是为了不让写 checklist 的时间占用提测之后的测试时间。
1.3.2 checklist 文件的位置
checklist 放在统一公共文件夹下，便于后续维护管理。
1.4 checklist评审
评审之前先确认下自己是否真的准备好了怎么确定自己的测试准备工作已经做好了？，提高评审的效率和价值。并提前在 checklist 上用红色背景高亮标记出 P0 的冒烟 case，疑问用黄色背景标注。
评审内容：
-
与研发和产品同学核对测试用例、测试环境和测试数据等，用蓝绿色标记 checklist 评审时新增的case，深蓝色标记 checklist 评审后决定删除的 case。
-
如果有疑问可以在这个会议上统一问
-
声明需要研发同学把冒烟 case 自测通过后才能提测。否则提测打回。
评审时间：尽量在研发同学提测前评审完。不必等 checklist 完整写完再确定评审会议的时间，因为等checklist 写完后可能刚好这两天研发同学和 PM 在日程上很难凑到一块去，这就会导致评审因为没有合适时间而延后，需要尽量避免这种情况。我们可以提前确定评审时间，比如你预估 checklist 一定可以在某个时间点完成，那么你可以尽早拉会，先把研发和产品同学的这个时间点的日程占上，然后继续 checklist 的编写，这样可以更加高效一些，最大化利用时间。
1.5 show case
show case 的意思是研发同学投屏把 P0 的 case 当场演示一遍。涉及前端改动，或者业务方较多的需求，需要让研发同学 把主流程演示一遍，演示通过才开始测试。
2 测试中
提测前观察流程管理平台该需求的状态，叮嘱研发更新状态改为「提测」，开始测试后先检验冒烟 case ，如果冒烟 case 未通过，直接打回提测，建议提测打回前先跟业务的测试 owner 说一下，让他帮你评估一下是否有必要打回。
2.1 高效提问
什么情况下发现了什么问题，理论上应该是怎么样的，实际上是怎么样的。配图用特殊标记和醒目的框出需要重点关注的区域，如果想更清晰一些，可以附上箭头。特别说明：截图截大一点，如果截个小小的局部图，别人很难知道你是从哪截的。
2.2 沟通过程
需求问题尽量不要私聊产品和研发同学，有问题直接在需求群里抛出，艾特指定的产品或者研发同学，这样沟通效率最高，不用你反复转述别人的意思给其他人，且能让其他同学明确知道目前这个需求遇到了哪些问题以及目前的一个大致测试进度。
新同学刚接手的一段时间建议每次拉需求测试群的时候都把业务的测试 owner 拉上。如果碰到无法解决的问题，可以随时艾特或者私聊测试 owner 。
沟通时不卑不亢，千万不要研发同学说不是问题就认为不是问题，被牵着鼻子走，要带有质疑精神，如果你觉得不合理或者可能不符合产品预期的时候及时在群里艾特 PM 出来确认需求。不要担心研发同学不耐烦或者发脾气，遇到这种情况只能说明这个同学的研发素质还有待提升，记住你帮他找出 bug，是在帮他，不是在求他。
2.2 每日进度同步
每天都需要在需求群周知测试进度，让大家明确知道当前的测试进度和遗留的问题，尽量不要等产品或者研发同学来问进度时才说，这样体现出我们不专业，也不利于合作。
进度同步除了告知目前测试进度和延期风险外，最好还简单罗列一下目前遗留的问题并艾特到指定的研发同学，并周知 pm，然后附上缺陷列表链接，把整条消息 Pin 住。
下面是一个比较好的进度同步模板：
2.3 注意事项
及时同步 delay 风险。任何可疑的情况都抛出让研发或者产品同学确认，宁可多花点时间确认，不可放过一个 bug 。
2.4 上线前回归和线上验收
上线后回归主要功能，上线后及时验收。验收完毕及时在流程管理平台更新需求状态，并在群聊中周知所有产品和开发同学。
3 测试后
更新流程管理平台上该需求状态为「测试完成」。如果需要填测试报告则填写测试报告。
4 工作过程的提问
有同学可能会有这样的想法，就是自己问问题太多会不会让别人觉得自己能力不行，所以尽可能少提问。这里我澄清一下：
工作中会遇到两种问题，一种是业务问题，一种是技术问题。业务问题独立思考的时间可以稍微短些，甚至直接请教询问都没关系。技术问题可以猜测和探索，独立思考的时间允许稍微多些。
无论是技术问题还是业务问题，在知道自己无法解决后果断询问，不要一直卡在一个地方导致拖慢进度。独立思考的目的一个是培养自己独立思考和独立解决问题的能力，另一个也是节约别人的时间。
欢迎关注公众号 TestDevelop , 我在这里分享各种测试开发技术知识、沟通技巧、职场感言。欢迎后续与我共同成长。
