产品经理做测试那些事儿
产品经理我做AB Test遇到的坑
编辑导语：在产品经理的日常业务中，AB测试可以帮助产品经理进行数据对比，进而推动后续方案决策。
那么，在AB测试过程中，有哪些事项是需要注意的呢？本篇文章里，作者结合其个人经验，总结分享了AB测试中可能会遇到的“坑”，一起来看一下。
大家好，我是策略产品经理夏唬人。
AB测试，是产品经理经常用于对新老方案上线后的效果进行对比的方法，核心目的在于通过AB测试能够增加需求上线后能够给平台带来正向收益的确定性。
页面功能的改动，需要进行AB测试，来观测用户对新老功能的使用情况。
策略逻辑的改动，需要进行AB测试，来观测流量在不同逻辑下的转化和收益。
总之，AB测试目前已经成为了一种大家公认的通过数据对比，来决策新方案是否上线的一个标准。
但是，我看到一种现象就是，大多数产品经理都是为了做AB 、而做AB。
其中涉及到几个非常重要的环节，稍有不慎就会入坑。
AB实验流量的控制是很多产品经理会忽视的一个环节。
先看一个我经历过的案例。
我记得刚去搜索团队的时候，有个产品经理在线上跑了一个搜索策略优化的AB实验，按照预期，新策略肯定要比老策略好。
但是她面临的问题是，一个AB实验做了半年了，因为AB结果数据经常波动，导致实验结果很难敲定下来。
也就是有的时候是实验组比对照组好，有的时候是实验组比对照组差，很难体现出趋势性。
后来，我看了看他们做的AB方案，发现了问题所在。
他们给这个AB Test分了两个组，实验组和对照组。
因为担心新策略的影响面太大，因此给新策略，也就是实验组分了10%的流量，然后直接用这10%的流量，与剩下90%的流量来进行AB实验。
此时，问题在哪，我估计大家也看出来了。
AB Test，为了尽量保证结果的可信，最基本的给到每个BUCKET（桶、组的概念）的流量是一样大小的。
就拿这个实验来说，考虑降低新策略的影响范围没错，但是拿一个10%流量的实验数据和一个90%流量的实验数据进行对比，很明显难以得出可信的结论。
所以我后来把AB Test的方案进行了调整，整个AB Test分了三个组：实验、对照和空白。
产品经理测评方案
产品经理测评方案目标产品经理的工作是负责产品的规划、设计和推广等工作，对于一个公司的产品质量和市场竞争力起着至关重要的作用。
为了确保产品经理具备必要的能力和素质，我们需要建立一个全面的测评方案，以评估他们在不同方面的表现和能力水平。
该测评方案的目标如下：1.评估产品经理在市场调研、需求分析、产品规划、团队协作等方面的能力；2.发现产品经理在工作中存在的问题和不足，为其提供进一步培训和发展方向；3.了解产品经理对于行业动态和用户需求变化的敏感度，以及对竞争对手情况的了解程度；4.提高整个团队的专业水平，提升公司产品质量。
实施步骤步骤一：确定测评指标首先，我们需要确定一组全面且具体的测评指标，用于评估产品经理在不同方面的能力和表现。
这些指标应该包括但不限于以下几个方面：1.市场调研能力：包括市场分析、用户调研、竞争对手分析等；2.需求分析能力：包括用户需求挖掘、需求整理和需求优先级确定等；3.产品规划能力：包括产品定义、产品路线图制定和产品特性设计等；4.团队协作能力：包括与开发团队的沟通协调、项目管理和团队合作等；5.行业动态敏感度：包括对于行业趋势和技术变化的了解程度；6.用户导向思维：包括用户体验设计和用户反馈处理等。
步骤二：制定测评方案基于确定的测评指标，我们可以制定一套完整的测评方案，具体步骤如下：1.设计问卷调查：通过设计问卷调查，收集产品经理在各个指标上的自我评估数据。
问卷应该结构清晰，问题具体明确，并充分考虑到不同层次的产品经理。
2.进行面试评估：根据自我评估数据，选取一部分表现较好或较差的产品经理进行面试。
面试过程中可以通过提问、情景模拟或者案例分析等方式来评估其在各个指标上的实际表现。
3.360度评估：除了自我评估和面试评估外，还可以邀请产品经理的直接上级、同事和下属参与到测评过程中。
他们可以通过观察、交流和反馈等方式提供对产品经理能力的评价，从而获得更全面的数据。
4.综合评估结果：根据以上三个环节收集到的数据，对产品经理在各个指标上的表现进行综合评估，并给出相应的分数或等级。
产品经理如何进行产品测试
产品经理如何进行产品测试一、协议关键信息1、测试目标明确产品是否满足用户需求检测产品功能的完整性和准确性评估产品性能和稳定性发现潜在的安全隐患和漏洞2、测试流程需求分析测试计划制定测试用例设计测试环境搭建执行测试缺陷跟踪与管理测试报告编写3、测试人员职责产品经理开发人员测试工程师4、测试资源人力时间设备软件工具5、测试标准功能实现符合预期性能满足指标要求用户体验良好兼容性达标二、协议内容11 测试目标的详细说明111 明确产品是否满足用户需求产品经理应深入了解用户的期望和需求，通过用户调研、反馈收集等方式，确定产品在功能、性能、可用性等方面是否能够满足目标用户的实际需求。
这需要与用户进行充分的沟通和交流，以确保测试的方向和重点与用户的关注点一致。
112 检测产品功能的完整性和准确性对产品的各项功能进行全面测试，确保每个功能都能按照设计要求正常运行，且输出结果准确无误。
包括但不限于核心功能、辅助功能、边缘功能等，不放过任何一个可能影响用户使用的功能点。
113 评估产品性能和稳定性测试产品在不同负载和压力条件下的性能表现，如响应时间、吞吐量、资源利用率等。
同时，对产品进行长时间运行测试，以评估其稳定性，确保产品在长时间使用过程中不会出现崩溃、死机等严重问题。
114 发现潜在的安全隐患和漏洞通过安全测试手段，如漏洞扫描、渗透测试等，查找产品中可能存在的安全风险，如数据泄露、权限滥用、恶意攻击等，保障用户的信息安全和产品的正常运行。
12 测试流程的具体步骤121 需求分析产品经理与相关团队成员共同对产品需求进行详细的分析和理解，明确产品的功能特性、性能要求、用户场景等。
在此基础上，确定测试的范围和重点，为后续的测试工作提供指导。
122 测试计划制定根据需求分析的结果，产品经理与测试工程师一起制定详细的测试计划。
测试计划应包括测试的目标、策略、资源分配、时间安排、风险评估等内容，确保测试工作能够有条不紊地进行。
做一个懂测试的产品经理-分享版
等价类划分法
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分， 然后从每一部分中选取少数有代表性的数据做为测试用例。
等价类的划分有两种不同的情况： ①有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 ②无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。 在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。
技能 提升
小公司的QA往往空 缺或人力不足，需 要PM和RD补位。
知己知彼，有助于 项目中PM与QA的 沟通协作。
PM与QA的工作存 在交叉地带，QA的 一些工作方法可以 被借鉴。
多掌握一类技能， 提升个人能力。
第二部分
全景了解测试行业
测试工作的分类、不同类公司对QA的需求
那些年，人们对测试的误解……
制定发布策略
• 用户行为分析报告 • 用户问卷调查 • 社会化媒体意见收集 • 产品功能改进列表
• 运维系统部署 • 用户行为分析系统
反馈收集与发 布分析
• 用户付费系统 • 设定分流规则 • 运营数据分析
系统部署
选定用户
• 用户规模 • 发布频率 • 功能覆盖度 • 风险评估与回滚策略 • 运营策略
• 全流程质量保证-VE（Verification） – 从需求/设计/编码/产品发布/线上质量的全流程都会有QA介入并提供各类质量保障手段。 – 核心指标：漏测率、事故数
• 产品效果、用户体验测试-VA（Validation） – 不仅要发现程序的错误，还要发现产品效果的问题，对用户体验质量全面负责。 – 核心指标：产品用户口碑、Bad case发现占比、Bad case推进解决效率
产品经理如何进行用户测试
产品经理如何进行用户测试在当今竞争激烈的市场环境中，产品经理要想打造出一款成功的产品，深入了解用户需求和行为是至关重要的。
而用户测试就是获取这些关键信息的有效手段之一。
那么，产品经理究竟应该如何进行用户测试呢？首先，明确测试目标是关键的第一步。
产品经理需要清晰地知道通过这次测试想要解决什么问题，是验证产品的某个新功能是否易于使用，还是评估用户对整体界面设计的满意度？目标越明确，后续的测试设计和分析就越有针对性。
在确定目标之后，就要精心挑选测试用户。
这可不是随便找几个人就行的。
要根据产品的特点和目标用户群体，选择具有代表性的用户。
比如，如果是一款针对年轻人的社交软件，那么测试用户就应该以年轻人为主，并且涵盖不同性别、地域、使用习惯等方面的特征。
同时，还要注意用户的数量，太少可能无法得出有普遍意义的结论，太多则会增加测试成本和分析难度。
接下来是设计测试任务和场景。
这需要产品经理充分发挥想象力，模拟出用户在实际使用产品时可能遇到的各种情况。
例如，如果是一个电商平台，测试任务可以包括搜索商品、比较价格、下单支付等；如果是一款办公软件，测试任务可以是创建文档、编辑表格、分享文件等。
场景也要尽量贴近真实，比如考虑在不同的网络环境下、不同的设备上使用产品。
准备好测试环境也是必不可少的。
要确保测试使用的设备、网络等都处于正常状态，避免因为外部因素影响测试结果。
如果是线下测试，要布置舒适、安静的测试场地；如果是线上测试，要提前测试好相关的软件和平台，确保其稳定运行。
在实际测试过程中，观察用户的行为和反应是非常重要的。
产品经理要保持敏锐的洞察力，注意用户在操作过程中的每一个细节，比如他们的表情、动作、语言等。
这些都能反映出用户对产品的感受和体验。
同时，要尽量避免对用户进行过多的引导和干扰，让他们能够自然地使用产品。
测试结束后，收集用户的反馈至关重要。
可以通过问卷调查、面对面访谈、在线留言等多种方式获取用户的意见和建议。
产品经理如何做测试？
产品经理如何做测试？本文不是教产品经理如何转行做测试，而是在团队没有测试人员的情况下，如何快速承担起测试的工作，以下是正文：大公司有明确的职位分工：工程师、测试、设计、运营都由不同的人负责，测试自然就是测试工程师的事，而在中小型创业公司，人员匮乏，很多团队只有工程师和产品经理，工程师负责开发，开发以外的事情全都由产品经理承包，这其中自然包括测试。
测试是产品上线前的质量检验，只有通过测试，产品才能放心的呈现到用户面前，本文就详细说说，产品经理该如何做测试。
我们不探讨测试究竟分多少种，每种类型又是如何定义，产品经理的测试任务基本只涉及一种：功能测试，测试的内容就是：工程师实现的产品，和PM 最初定义的产品是否一致，如果一致，则测试通过，如果不一致，则测试不通过。
需求文档——测试的基础需求文档定义了产品要实现的功能和具体的细节，工程师依据它进行开发，测试当然要依据相同的标准进行测试，如果缺少需求文档，测试就没了依据，就很难往下进行。
比如有以下需求文档：XX 博客系统发布文章页需求清单文章标题为必填，最长80 个字符，支持中英文和特殊符号，超出时即时提示“标题不能超出80 个字符”（原型见附件）文章内容为选填，最长8000 个字符，支持中英文和特殊符号，超出时即时提示“文章内容不能超出8000 个字符”…进行测试时，除了要考虑产品的常规使用流程，还要重点考虑产品中的边界问题，比如以上例子中标题和内容的字数限制。
测试用例了解清楚需求之后就要设计测试用例了，测试用例就是一个个用户实际的使用场景，要求有设定好的输入条件和预期结果，比如针对上面的文章发布页设计以下用例：上面的4 个用例覆盖了常见的用户场景，如果实际测试结果符合预期，产品基本上是合格的，但不要忘记一些隐藏的陷阱：标题或文章内容包含html 标签等特殊字符时，系统能否正确保存？文章内容为富文本编辑器，如果录入的有8000 个字符，插入图片、添加格式后是否还能保存成功？…根据需求文档可以定义大多数情况的测试用例，还有很多特殊情况的用例，需要经验的积累来完善。
产品经理如何做产品可用性测试？
感觉：可用性测试的本质：产品，从用户中来，到用户中去。
小技巧：1、招募测试用户。
招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户。
招募小白鼠了喂，有报名的没？没有？我等下再问一次。
2、准备测试任务。
测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。
万一他们瞎几把乱点，触雷弹出BUG页面该多尴尬。
3、观察测试过程。
组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。
偷偷拿小本本儿记下他们的SB行为。
切忌，引导与暗示用户。
4、询问用户产品体验情况。
测试结束后，组织者可以询问用户对于产品整体的主观看法或感觉。
而不是让其一顿操作猛如虎。
结果，你懵逼他更懵逼。
另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。
求虐，求摧残。
5、研究和分析。
在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。
统计不是来源于真实用户，都是耍流氓。
统计结果，要尽快出来并发给测试用户。
让用户参与，让其感觉到被重视，做了一件很有价值的事情。
6、早测好过晚测。
你以为你是贾跃亭啊？一个PPT就能验证可用性。
产品从0到1的任何过程，都可以让用户参与，验证真伪，及时提前纠正错误。
实际上，往往都是等到产品快要上线的时候，才做产品可用性测试，结果为时已晚。
然后，又周而复始的重复性犯错，死循环。
7、易小不易大，易少不易多。
往往我们想做的事很多、想要的大而美，但却忽略了投入成本、现有资源等实际情况。
你丫，能不能务实点？先做个最小MVP出来验证市场，不香吗？8、别跟测试用户说过多专业性术语。
要有同理心，现在你不是显摆装X的时候。
亲，我们做了个新产品，你体验下给点宝贵意见呗?9、提前预约人家工作忙的焦头烂额的时候，结果突然被你打断。
冒冒失失的来一句：帮我测个产品呗？(白眼表情包)给你一个白眼，自己体会。
产品经理该如何做AB 测试？
产品经理该如何做A/B 测试？在产品运营过程中会存在许多次迭代优化，大到某项功能的增加或删除、小到某个点击按钮的颜色，都有可能成为驱动关键转化指标提升的因素，那么就会存在一个问题，作为公司内部的产品、运营等团队，要如何才能保证每一次的方案都能取得更好的效果呢？很简单，试一试就知道了。
A/B 测试指的是根据试验的目标，把测试群体分为2组（或更多的组，取决于备选方案的数量），每组采用不同方案试行，最后对统计结果进行分析，选取效果最好的方案。
一、确定测试目标，提出方案做任何事之前，都需要想清楚是为什么而做，因为这很大程度上决定了其可行性，以及之后的发力方向、时程、耗费的人力物力等。
1. 收集需求需求可能来自真实业务中的方方面面，但都保持跟整个公司的发展大方向一致（也就是北极星指标），这些需求的解决能够从某个角度推动总体业务前进，（例如优化注册页面文案可以提高新用户注册转化率，增大产品拉新规模），包括但不限于以下来源：（1）来自内部（团队）：•产品部门•运营部门•市场部门•研发部门（2）来自外部（用户）：•问卷调查•用户调研（3）来自外部（行业）：•行业分析•竞品分析用户增长团队（or数据分析师们）收集到这些需求，会做出一些可行性评估，并筛选出合理需求进入试验库。
2. 进行优先级排序当产生了众多的需求之后，该如何安排先处理哪些呢？对于试验顺序的处理不能毫无章法，拎出哪个做哪个，针对此问题，可在公司内部制定一个优先级排序系统，将所有待处理的需求进行科学有序地排列。
例如ICE排序系统（Impact=影响力，Confidence=成功率，Effort=开发成本），其核心思路是根据不同试验执行的综合性价比来决定先后顺序，“性”指的是可以收获到的价值（包括影响力及成功率），“价”指的是需要为此付出的人力物力及财力。
预期影响力越大，成功概率越高，开发成本越小，优先级就越高，反之则越低。
相信在评估上述的重要参考因素之后，可以比较清晰地指导不同的试验顺序，找到应尽快实施的试验。
产品经理验收测试模板范文
产品经理验收测试模板范文示例1:标题：产品经理验收测试模板范文引言：产品经理是一个非常重要的角色，他们负责确保产品的质量和功能符合用户需求和预期。
而验收测试则是产品经理在产品开发过程中的一项关键任务。
本文将为读者提供一个详细的产品经理验收测试模板范文，帮助他们更好地组织和执行验收测试。
一、测试目标与背景在此部分，产品经理应明确测试的目标和背景。
例如，测试目标可以是验证产品是否满足需求和预期，背景可以是产品开发过程中的需求变更或增加。
二、测试范围产品经理需要在此部分明确测试的范围。
范围可以包括以下几个方面：1. 功能测试：检验产品的各个功能是否正常工作。
2. 兼容性测试：验证产品在不同操作系统、浏览器或设备上的兼容性。
3. 性能测试：评估产品在负载下的性能表现，包括响应时间和稳定性。
4. 安全性测试：检测产品是否存在潜在的安全漏洞。
5. 用户体验测试：评估产品在用户使用过程中的易用性和用户满意度。
三、测试计划与策略在此部分，产品经理应详细说明测试的计划和策略。
测试计划包括以下内容：1. 测试时间：明确测试的开始和结束时间。
2. 测试环境：指定用于测试的硬件设备、操作系统和软件版本。
3. 测试人员：列出测试人员的名称和分工，确保每个功能都得到测试。
4. 测试工具：指定所需的测试工具和软件。
5. 测试数据：准备需要用于测试的数据。
6. 测试场景：列出需要覆盖的测试场景和用例。
测试策略包括以下内容：1. 自动化测试：确定哪些测试可自动化，以提高测试效率。
2. 手工测试：指定需要手工测试的环节，确保产品的质量。
3. 回归测试：决定是否需要进行回归测试以确保已有功能没有受到新功能的冲击。
4. 报告与跟踪：明确测试结果的报告和问题跟踪的方式。
四、测试执行与记录在此部分，产品经理应确保测试的正常执行并记录测试结果。
测试执行时，产品经理可以使用测试管理工具，跟踪测试的进度，并记录测试过程中的问题和发现。
产品经理应确保测试人员按照预定的测试场景和用例进行测试，并记录每个测试的结果。
产品经理-6个要点,打造有效的AB测试
6个要点，打造有效的AB测试管理者十分看重市场营销的资产价值，花费大量的精力投入到A/B 测试的研究中，但是收效甚微。
究竟是什么究其原因导致了一场垃圾A/B测试，我们又该如何改进呢，看看笔者是怎么说的吧。
在这个数字以数字为先的平面广告世界，许多领导者都渴望将营销手段、市场作为一门科学来管理。
于是，他们用精确、测量、数据这些科学的字眼来说话，他们聘请教育者，他们教团队用结构化实验来验证他们的假设……然而，除了十分外专业的产品经理以外，大多数女孩子并不知道如何用科学、正面的方法论去研究A/B测试的问题，尽管他们或进行了所有“成功”的A/B测试，但对于的业务指标并没有多大改善。
为什么会这样呢？相关人员到底在A/B测试中学到什么？我认为，从市场营销的角度来谈，在设计一轮A/B测试时，必须要记住以下六个要点：虽然这几个字看上去毫无趣味，但大多数营销人员不可正确定义统计的意义。
当我们开始一个A/B测试——“我正在测试的广告之间没有性能差异。
”然后，我们运行测试并追踪数据，我们盼望这些数据将反馈给我们报送信息，并得出反之亦然的结论，即存在性能差异。
但从技术上讲，问题是——“假设种叠的假设成立，任何性能上的差异即使是由随机因素造成的，那么能到实际差异的可能性有多大？”所以，计算p值很棘手，但需要理解的重要一点是：p值越低，我们就越有信心得出我们测试的广告计算结果之间存在真正差异的结论。
具体地说，p值为0.05意味着有5%的可能性，观察到的性能差异将由于纯粹的随机因素而产生。
然而重要的是，要学会理解这只是一个社会惯例所使用的标签而已。
在一个数据匮乏、没有电脑的时代，这可以说是一个合理的统一标准，但在今天的世界，它可能已经被打破了。
统计显著性分析虽然可以帮助消费市场人员评估广告是否之间是否存在性能差异，但它并没有说明这种差异在实际应用中有多大或有多重要。
有了足够的数据，无关紧要的差异可被视为“具有统计意义”。
例如：假设你用两个稍微不同的广告运行一个A/B测试。
产品经理产品的原型应该如何去测试？
产品的原型设计是产品设计开发的必要过程之一，而且原型设计在扮演着越来越重要的角色。
原型设计的成功与否，有时会直接影响到这款产品的最终质量。
同时一个合格的原型可以从多个方面模拟真正的产品，并切实的反应出产品所存在的问题。
那么，如何才能从原型中分析出产品存在的问题呢？这里就涉及到了对于产品原型的测试。
1. 原型测试的目的和目标：测试一个产品的原型，其目的就在于模拟现实中的App、Web或其他类型的产品的真实应用场景，并且反映出真实产品可能存在的问题和隐患，进而避免潜在的风险。
测试产品原型的目标就不一样了，它可以有很多种，比如：测试一个界面的用户友好程度、测试一个交互产生的结果是否符合用户的心理期待，等等。
但是在测试还需要特别注意一点，那就是尽量不要在一次测试中检查过多的问题，最好保持一次测试中测试目标的固定。
如果测试的目标是设计中的重点，那我建议在保持测试过程中测试目标固定的同时，也还要保持本次测试目标的唯一性。
2. 原型测试的主体和参与者：测试的主体就是原型了，保证每个参与者手中的原型是一致的、可以运行的。
这里的重点在于参与者，测试中的参与群体是否正确，很大程度上决定了这次测试能否成功、能否为产品的设计开发提供有效的建议和反馈。
正确的参与群体需要至少从以下三个方面选取：1). 开发团队期待的目标用户。
通过部分目标用户来测试原型，反馈和建议对产品的下一步开发和设计往往会有更直接的作用。
2). 竞品的使用者。
这部分群体很更多的把测试的原型与自己正在使用的工具去做比较，这样一来更容易了解目前设计中的缺点和不足。
3). 公司内部的推广或者市场人员。
这部分可能是大多数测试组织都没有考虑到的人群，不过我认为这部分人群的反馈也很重要。
首先，产品最终还是要靠他们去推广，如果推广的人本身都觉得产品设计有问题，这就有可能造成推广效率低下的问题。
第二，这部分人群与开发团队期待的目标用户是直接接触的，有时他们不仅会从用户的角度考虑，还会从如何让用户接受的角度去考虑问题。
产品经理必备干货：全面详细的产品测试知识
产品经理必备干货：全面详细的产品测试知识什么是产品测试？测试可归为两点：程序做了它应该做的事情；程序没有做它不该做的事情。
1、写在前面文章主要涉及产品经理工作上经常接触到的基础的测试知识，包括测试的定义、测试何时进行、产品经理应该懂的测试概念、产品经理如何测试验收产品。
2、为什么产品经理需要懂测试产品每个阶段都有验收标准，比如需求评审阶段验收、开发阶段验收，所以每个阶段都需要测试。
产品经理尽管不是专业的测试人员，但产品经理作为最熟悉产品的人，理应对产品每个阶段都进行相应的测试验收产品，比如功能测试、可用性测试、用户体验测试，确保符合需求文档的要求，所以产品经理应该懂得相应的测试知识。
产品经理懂测试，在相应的测试方式中验收产品的时候，能更清楚的系统地记录产品的每个问题，然后用产品思维去思考如何解决这些问题。
可以用极简主义去思考如何把选择复杂的问题简单化减少用户的选择，比如刻意显示引导用户选择的功能按钮或隐藏用户很少用到的功能，比如微信用户很少用到的朋友圈停用的功能，使用路径刻意加深隐藏。
可以用可用性原则的思维去思考如何去引导用户更好的完成产品使用，比如页面说明该页面所处的位置状态，比如微信的朋友圈页面顶部显示朋友圈的位置说明。
可以用情感化设计的思维去思考如何超出用户的期望，比如微信聊天窗口发送我想你了会落下满天星星的效果超出用户的期望。
可以用可行性的思维去思考如何用现有的资源解决产品的问题，比如前端工程师人数少的情况下可以直接借助前端开源框架快速开发MVP，比如借助bootstrap。
还可以去和开发人员沟通如何解决app使用卡顿启动难加载缓慢等产品本身的性能问题，比如使用网易新闻app滑动时卡顿，开发人员会告诉你其中的一个原因是因为每个页面上承受的控件过多，app一个页面看起来的效果是一个平面，但app中一个页面的组成由webview或者文本框等多个控件布局叠加的，控件过多会占用内存，导致使用卡顿，这时你可以思考如何去平衡控件数量和卡顿体验问题。
产品经理可用性测试计划
产品经理可用性测试计划测试计划是整体可用性测试的基石。
计划要说明测试方法、时间、地点、谁推动测试、为什么测试和测试内容。
但是，有时在项目期限临近的巨大压力下，可能不会制定详细的测试计划。
最后，你认为你已经知道了即将进行的测试，你不必再花时间写它了。
但是，这样不规范的方法显然是错误的，最终不可避免地会引起问题。
为什么要制定测试计划？合理的方法是：一旦知道测试将要进行的那一刻，就要准备测试计划。
(约翰f肯尼迪，测试名言)此后，随着项目的进展，不断改进计划，收集反馈等往返。
当然，灵活性也是有限的。
测试前必须设置特定的时间节点。
此后，计划要保持不变。
同时测试的产品在这个时间节点后，在测试结束之前不能再更改。
您可能已经知道测试计划是产品开发周期中唯一具有明确时间点的文档，因此特别重要。
当期限临近时，你要尽力不要更换要试验的设计产品。
进一步的更改可能会使以前开发的测试方案不再可靠。
例如，需要研究的问题，甚至数据收集方法的可靠性也会受到影响。
如果需要在预定时间点后更改测试，则测试可能无效，并且在测试前更改的产品可能无法正常工作的风险必须让所有人都理解。
以下说明了需要制定详细计划的原因，以及开发团队如何使用计划作为沟通工具。
作为测试的规划指南。
正如设计图准确地描绘了要建造的房子一样，测试计划也准确地说明了如何测试你的产品。
建筑承包商在盖房子时不会希望按计划即兴发挥，可用性测试也遵循这个逻辑。
测试计划保证一切妥当。
在测试第一名时，你肯定不希望测试中还存在不明确的事项。
作为主要的沟通工具，测试计划是设计师、开发人员、测试主持人和团队其他成员的主要沟通工具。
开发团队和管理团队(如果有兴趣并且在团队中)的官员应该仔细阅读测试计划的文档报告。
也就是说，您需要了解测试是如何进行的，并确认是否满足了具体要求。
你可以利用计划从其他成员那里得到建议和反馈，使每个人都能同意即将进行的实战测试。
正在进行的项目每天每周都会更改，测试结束后，我不想有人质疑他或她的一些要求没有出现在测试中。
产品经理写测试报告的职责
产品经理写测试报告的职责引言在软件开发过程中，测试是一个不可或缺的环节。
通过测试可以验证产品的质量，发现和修复潜在的问题。
测试报告是测试工作的结晶，是产品经理向团队和上级汇报测试结果的一种方式。
产品经理写测试报告是产品经理工作中的重要职责之一。
本文将探讨产品经理写测试报告的职责以及该如何进行测试报告的撰写。
职责1.协调测试工作作为产品经理，你需要协调测试团队的工作进度并确保测试工作按照计划进行。
你需要与测试团队进行有效的沟通，了解测试进度、测试结果等信息，及时处理测试过程中出现的问题。
2.定义测试目标和策略在产品规划的阶段，产品经理需要定义测试的目标和策略。
你需要明确测试的覆盖范围、测试重点以及测试方法。
通过明确测试目标和策略，可以确保测试的有效性和高效性。
3.编写测试计划和用例产品经理需要编写详细的测试计划和用例。
测试计划描述了整个测试过程的安排和步骤，包括测试时间、人员分配、测试环境等。
测试用例是具体的测试步骤和预期结果的描述，用于指导测试人员进行测试工作。
编写清晰、详细的测试计划和用例对于保证测试的质量至关重要。
4.监控测试进度和结果产品经理需要及时了解测试进度和结果，对测试过程中出现的问题进行跟踪和解决。
你需要参与测试会议，与测试团队讨论测试结果，并提出解决方案。
同时，你还需要确保测试结果的准确性和可靠性，对于测试结果的异常情况进行分析和处理。
5.撰写测试报告测试报告是产品经理向团队和上级汇报测试结果的一种文档形式。
产品经理需要以清晰、简洁的方式撰写测试报告，确保信息的准确传达。
测试报告应当包括以下几个方面的内容：- 测试目标和策略：说明测试的目标和策略- 测试环境和配置：描述测试所使用的环境和配置信息- 测试进度和结果概述：概述测试的进度和结果情况- 问题总结和解决方案：总结测试过程中出现的问题，并提出解决方案- 测试总结和建议：总结整个测试过程，提出针对性的建议和改进措施除了撰写测试报告外，产品经理还需要准备一份口头报告来详细陈述测试的结果和建议，并与团队和上级进行交流和讨论。
产品经理升级：打开测试的正确方式
产品经理升级：打开测试的正确方式本文针对的是创业公司的测试、验收工作，顾省略测试用例编写等步骤（实际工作中，如果是产品经理兼顾测试的，也不会时间去写测试用例的）。
产品经理需要兼顾测试工作或验收产品，这是很平常的事，但又有多少人可以正确打开”测试”这份工作呢?一轮奋战之后，新版本终于上线了，正当嗨森之时，却收到了BOSS或者其他渠道的反馈，出现了xxxx的bug，瞬间整个人都要崩溃了。
相信很多人都有遇到过这种神乎其神的情况，明明是测试过的，为什么就是会出现问题了。
如果公司是有专门的测试人员，这时候一般是测试人员遭殃，如果是产品自己兼顾测试的，那就是产品遭殃了。
这种情况并不是在测试的过程中漏掉了，而是自己的测试方式不对！那打开测试的正确方式应该是怎样的呢？皓皓把自己多年的坑一一告诉大家。
一、产品的上线流程完成测试版之前的需求评审之类，皓皓就不多啰嗦了，今天主要讲的出了测试版到上线这个流程。
正常情况，都会现有专门的测试部门去测试，当产品达到了一定的条件，就会提交给产品去验收，验收没有问题之后，就可以上线了。
二、确定目标：是测试还是验收“勿忘初心，方得始终！”这句话从另一个角度的理解就是：做什么事情需要确定目标，不要让自己迷失了，最后毫无收获。
因很多创业公司是没有专门的测试部门，所以产品经理也会义不容辞（其实是迫不得已）把测试工作给接下来。
到了这个时候，产品经理就一定得明白，自己到底是做测试阶段的工作，还是在做验收的，请不要搞混了，否则就要承担后果了。
皓皓的心血叮嘱：请不要偷懒，把测试和验收工作一起做了！三、测试阶段：重功能清楚目标，那就要开展工作了。
在测试阶段的工作中心是注重功能的实现，功能可以简单概括为三个方面：UI、具体功能、逻辑。
这三个方面可以使用以下方法来进行测试。
1）UI——界面显示是否美观UI，通常容易出现问题地方就是“撑爆了”。
撑爆了是在展示内容超过一定限制时，会出现奇怪的现象，比如一个名字展示框，在展示5个字以内时，显示都是美美的，一旦超过了5个字，就出现莫名奇妙的换行或者其他影响美观的现象。
产品经理做好可用性测试的全流程(下)
可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。
不同于其他用户研究方式，可用性测试尤其关键的一点是用户的发声思考的练习，发声思考直接影响可用性测试最后的效果和结论。
在破冰、保密协议和流程说明等基础步骤完成之后，可用性测试的第一步即是用户发声思考练习，在提纲中可以使用一个简单的例子来使用户得到练习，举个例子：主试：“下面我们进行出声思考练习。
请在执行每一步操作时，用语言描述出你当前的感觉和想法。
比如：我准备打开菜单，我正在寻找某功能，我现在觉得很迷惑等等，任何想法都可以说出来，不需要刻意去思考，这有助于我去了解你的想法和感受。
接下来，先由我示范一下出声描述的做法。
我将进行出声思考示范：为了会议不迟到，需要设定第二天7:00起床的闹钟。
”主试人员示范后，请被访者练习。
练习完成之后，主试可以说：“现在您已经了解如何进行边操作边描述，在之后的任务操作中，请尽量保持。
在测试的过程过，如果用户不进行出声思考，不便于现场对其操作进行判断和追问，后期数据整理时，不便于回看追踪和统计问题。
除了发声思考练习，主试可对用户说明：用户主动的说明可以更为快速知道用户的难处，便于之后的询问，另一方面可以有效提升测试的速率，不会一个任务上死磕，拉长整个测试时间。
同时也需要主试人员观察用户的操作和表情，进行适当的提示，并且在大纲中记录是提示后完成的任务，在现场进行询问。
另外，测试时候需准备“任务情景卡片”，卡片可用较大的字将每一个具体任务打印下来，每出一个测试任务，主试展示一个。
如果仅仅是主试人员表述任务，用户很有可能不清楚具体任务，或者在操作一半后遗忘。
用户在发声思考完成测试任务时主试可不说话，测试中一定要观察用户的表情变化，当用户出现思考、犹豫、惊讶、皱眉等表情时，可进行简单询问。
不必完全按照大纲设置的问题进行询问，可针对当下用户个体表现的差异性进行追问。
追问的方式可以采用一般疑问的方式，客观具体的重复说一遍他刚才的行为，询问“为什么”会出现刚刚的行为。
干货,产品经理如何进行可用性测试(上)
产品经理简称PM，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。
产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。
产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。
近年来互联网产品经理火热，一起看下为大家精选的互联网产品经理学习文章。
可用性测试是一种定性的研究方式，可用性测试做的好，能够有效的发现产品设计中的不足，那我们该如何做一场完美的可用性测试呢？本文为你详细解锁姿势!一、什么是可用性测试呢？福特自从发现了用户想更快的达到某地以后，发明了一辆汽车，但是他不知道自己的汽车设计的好不好，于是邀请几个人来试驾，试驾的人在试驾的过程中不断地给他提意见，座椅太高了、方便盘太死...,这个过程就是可用性测试。
邀请一批真实的具有代表性的用户针对典型场景操作产品，并鼓励他们在尝试完成任务的时候出声思考，可用性工作人员在一旁观察、聆听、记录，从而发现产品中存在的可用性问题。
它适应于产品前期设计开发、中期改进和后期维护完善的各个阶段，是以用户为中心设计思想的重要体现。
可用性测试的具体概念包含观察、访谈和发声观察：让一群具有代表性的用户对产品进行典型操作，同时观察人员在一旁观察，聆听，做记录。
动作的起始位置、操作的流畅程度、面部表情的变化...访谈：有的时候我们观察用户，并不一定能洞察用户出现的问题，这个时候可以通过访谈的形式来询问用户的想法，比如：“您这么操作是为了？这里遇到什么问题了？总体使用感受怎么样？”不要问用户您觉得怎么设计会更好用？…这种问题，不要让用户给你解决方案，用户又不是产品经理。
发声：鼓励用户诉说使用产品过程中的感受，让用户把遇到的问题和想吐槽的点说出来，用户发声的过程也是一个交流思考的过程。
这里面有几个关键词汇：“一批、代表性用户、观察聆听、记录、访谈、发声”。
测试产品经理岗位职责
测试产品经理岗位职责产品经理作为一个职业，是为了让产品与用户的需求相匹配而存在的，而实现这一目标就需要贯穿整个产品生命周期，从市场调研、竞品分析到产品设计、开发、测试、上线以及售后维护等环节，下面将就产品经理在这些过程中的职责进行详细解释。
1. 市场调研和竞品分析一个好的产品总会来源于对市场和用户的深入了解，所以产品经理需要对市场进行研究和调研，了解用户需求，掌握市场趋势和竞争对手的信息。
他们需要定期对行业和市场进行深入分析，了解市场的需求和用户的痛点，以及竞品的优缺点。
2. 产品规划和需求分析产品经理需要根据市场调研结果和竞品分析，制定产品规划，明确产品定位、目标用户、功能需求、特色功能、开发周期等。
在此基础上，产品经理还需要进行用户需求分析、需求优先级排序和需求文档编写等工作。
3. 项目管理和需求跟踪产品经理需要与团队协作，制定产品开发计划和开发进度，以确保产品按时按质量交付。
在开发过程中，需求和产品文档会发生变动，产品经理需要及时跟踪需求变动，并确保团队开发方向和用户需求保持一致。
4. 用户体验设计和用户测试产品经理需要根据用户需求和产品特色，对产品的交互设计、视觉设计、用户流程等进行用户体验设计。
同时，产品经理还需要针对用户目标群体，制定测试计划，并进行测试用例编写、测试环境部署、测试执行以及结果分析等工作。
5. 数据分析和产品改进最后，产品经理需要根据产品的实际使用情况，对已上线产品进行数据分析和用户反馈分析，发现产品存在的问题，并提出解决方案和产品改进意见。
综上所述，产品经理作为一个全能型的职业，需要具备市场研究、需求分析、项目管理、用户体验设计和数据分析等能力。
同时，产品经理还需要具备较好的沟通能力、协调能力和团队领导能力，能够与产品团队、开发团队和测试团队等其他部门密切协作，共同打造出用户满意的产品。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
总监：“那你还回什么家，好好测啊！当时测试的时候不好好测，现在倒想起来谨慎了…..”我：“好的，我周末继续测….”挂了电话，我木木地喝了口寒彻心扉的啤酒，准备再做几分钟就回去。
这时，旁边的大叔冷笑一声：“小伙子，你是产品吧？”我一激灵：“你怎么知道？”大叔抿了一口啤酒：“我不仅知道你是个产品经理，还知道你们公司人不多，你们公司没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. 测试人员动力不足。
没奖励呀，你得多鼓励鼓励才行，有鼓励师没？”我张张嘴，还没说话，老高就打断了我：“没有是吧，那就物质奖励，前面说测试资料准备的时候不是也提了准备零食吗，这时候就得上啊。
”我皱皱眉：“老高，那个什么交叉结对测试是什么意思？我只听说过交叉测试。
”老高眯了眯眼睛：“交叉结对测试，就是指安卓和iOS两端的负责同一个模块的开发人员，组成队伍，相互测试对方的客户端。
有点拗口，但很有用处：1. 由于是负责自己开发的模块，所以不需要学习，能够很快投入状态；2. 测试对方的模块，能够在测试的同时检查自己的错误，测试的时候能够心中有数；3. 既是合作也是竞争，同时由于测试必须同时进行，一个人不来，另一个人也没办法开展工作，所以时间被拖延，这样也是培养他们的责任心。
这样，使用交叉结对测试的方法，其实也很好地缓解了第二、三、五个问题。
”我抢过测三通手上的酒，给老高满上：“高哥，这个我算明白了，你给我讲讲其他的吧。
”老高满意地点点头：“集中测试效率低下，很容易被打断。
其实这个也很好理解，集中测试就是发现一些重要、明显的BUG的嘛，不要指望它能够带来多大的效果，但是由于单独测试不可控，所以集中测试是很有必要的，你就把集中测试当成一个测试的热身，调动热血与气氛的工具就好了，可以适当地缩短集中测试的时间。
”我把手机调成的录音机，放在老高面前，生怕漏了一句。
老高顿了顿，说：“你说了许多集中测试的事，却不说单独对照测试，肯定不是因为单独测试很顺利，而是因为没人单独测试是不是。