PM入职流程

PM入职流程思维导图，项目管理入职流程，如何让项目经理从了解到熟悉到掌握公司项目计划，快速融入公司管理，不妨看看下图。

PM入职流程

了解

格式规范Guideline

1. 确保中英文标点不混用：常见的错误是英文逗号 “,” 写成中文逗号“，”。 2. 确保不出现大小写错误：常见的错误是介词、连词首字母大小写不清楚，比如标题中的介词和连词，字母大于三个的首字母需要大写，而小于等于三个的则不应该大写。 3. 确保英文标点与文字间的空格使用正确：常见的错误是：逗号后不加空格，以及引号与非引用内容之间不加空格。 4. 确保段落之间空一行。

数字

1.1）采用英美报刊通用的数字写法 十以上数字、年份、百分率、金额等都用阿拉伯数字表示，数字采用千位逗号隔断 ；十及十以下的数字都用英文表示，比如one apple, ten apples 特例：体育比赛中的比分，如 2-1，6-3，88-89 采用阿拉伯写法 。 1.2）所有数字在后面有billion, million等情况时采用阿拉伯+英文写法，比如1 million, 10 billion, 250 billion. 1.3）正确写法示例： 基数词 one-ten用英语, 2,000, 3.25 million 10 billion 250 billion 序数词 first-ninth用英语，10th 以上用数字+简写 分数 3/4 年份 2010 1980s 百分率 3% 10% 11% 金额 $2,400 £25 billion 注意：a mandated 5.5-billion-dollar payment 时间 10 am 3 pm 日期 September 10th September 7th 单位 1,000 kilometers（美）/kilometres（英） 1,000 kilograms（美）/kilogrammes（英）

标点

2.1）区分英文和中文标点，英文文本采用英文输入模式下的半角标点。 2.2）逗号、句号、分号、叹号、破折号等后面要敲一个空格键，破折号的前后要各敲一个空格键，引号与所引用的内容之间不敲空格，但是与非引用内容之间要敲空格。 2.3）1. 冒号后面加空格，前面不加空格 2. 冒号后面如果是完整的句子，首字母大写；如果不是，就小写 3. 冒号后面不能跟“-”

大小写

3.1）英语文章标题大小写规则 1.题目的第一个单词要大写； 2.冠词都不需要大写； 3.字母多于三个(不含三个)的介词、连词首字母要大写； 4.名词、动词、形容词、副词、代词、感叹词首字母要大写； 5.大写所有英语中要求大写的单词。如月份、人名、地名等等。这几条原则的优先性是递减的，也就是说，如果几条原则之间出现了矛盾的情况，应优先实用前面的原则。如：如果题目的第一个单词是冠词或不多于二个字母的介词时也应该大写。 3.2）英文字母大写规则 1．句子开头的第一个字母要大写。“I（我）”在句中任何位置都要大写。例如：What's her name? Mary and I are teachers. 2．地名、国名和人名等专有名词第一个字母要大写。例如：Russia（俄罗斯），Chengdu（成都），Jack（杰克）。 3．一些亲属关系（如mother, sister, mum, dad等）用作称呼语时第一个字母要大写。例如：Thank you, Granny. 谢谢你，姥姥。 4．人名前的称呼或头衔第一个字母应大写。例如：Mr Smith, Dr Wang, Miss Mary. 5．表示语种、民族的名词或形容词第一个字母要大写。例如：Russian俄语、俄罗斯人（的），Chinese汉语、中国人（的）。 6．直接引语中，句首字母要大写。例如："Then, " I said, "You have been making a mistake, and the letter is not in the apartment." “那么，”我说，“你准弄错了。这封信并不在那栋房子里。” 7．星期、月份名称的第一个字母要大写，但季节第一个字母不大写。例如：Sunday星期天，August八月，winter冬天，spring春天。 8．一些大型节日名称的第一个实词的第一字母都要大写。如：Children's Day儿童节，National Day国庆节, Teachers' Day教师节。 9．由普通名词构成的专有名词词组，除其中的冠词、较短的介词和连词外，每个词的第一字母都要大写。例如：the Great Wall长城，the United States美国。 10．大型会议、文件、条约名称的每个实词（虚词：副词、介词、连词、助词、叹词和拟声词则不用大写）的第一个字母都要大写。书名、报刊名应大写首字母，文章标题中的每一个实词的第一个字母要大写。如：China Daily《中国日报》，New York Times《纽约时报》，Their Class《他们的班级》（文章标题），the Warsaw Treaty《华沙条约》, 实例：English Coaching Paper《英语辅导报》。 11．诗歌的每一行的第一个单词的第一个字母要大写。 12. 表示称呼语或职务的词首字母要大写。 实例：Mr Green格林先生, Dr Li李博士 13. 大多数的缩略词要大写。 实例：CCTV(中国中央电视台), ID(身份证), CD(光盘) 14. "I"和"OK"在句中的任何位置都应大写。 实例：Tom and I are students. 汤姆和我是学生。That's OK.不用谢

产品功能测试

1. 每个测试类型都是针对独特的测试阶段或测试对象，都需要关注； 2. 每个测试类型的介绍都分3个部分:测试目标、测试点编写、测试注意点； 3. 测试点的编写可以在DEV开发开始后进行，是确保功能测试效果的重中之重； 4. 测试用例设计方法可以参考【Guideline-PM-28. 测试用例设计方法论】。

模块测试

目标

- 确保所有功能的预期需求都已经实现 - 确保在不同OS版本上都能兼容 - 确保所有发现的Bug都已经修复

测试点编写

- 列出所有的功能点，确保全覆盖 (参考需求文档和UI效果图) - 列出每个功能点的所有的逻辑路径分支，并为每个分支都添加测试点，确保逻辑路径全覆盖(参考动态逻辑图，可以请DEV帮助完善逻辑路径分支) - 和信息存储/交互、数据有关的功能，添加确保信息/数据准确性的测试点 - 对于按钮，除了正常点击外，需要添加双击和按住效果的测试点 - 和输入框、数量有关的功能，需要添加边界值的测试点(边界值+/-1) - 对于修改了存储/接口的功能，需要添加新老版本兼容的测试点 - 和RemoteConfig有关的需求，需要添加对应设置项的测试点 - 需要添加无效操作/点击，操作失败，网络失败以及其他例外情况的测试点 - 涉及到网络请求/服务器请求的，需要添加请求成功/失败的测试点 - 对于用户可能频繁使用的操作/功能，需要添加大量使用的压力测试点 - 对于有过程/进度条的操作，需要添加操作过程中的中断测试点(取消操作、页面内其他操作、关闭页面、切换Tab页、前后台切换、锁屏、杀线程、弹出Alert等页面、用户状态切换、抢占语音/视频资源、断网等) - 对于弹出页面/弹出框，需要添加页面交互的测试点(关闭页面、切换Tab页、前后台切换、锁屏、杀线程、用户状态切换等)

注意

- 遵循尽早测试原则。当DEV代码开发完就可以开始协助DEV进行测试，以便于尽早发现问题 - 需要在不同OS版本的设备上测试兼容性。OS版本可以根据活跃用户分布情况，从最高到最低中选择最有代表性的几个 - 模块测试阶段要测全，尽可能暴露出所有的问题 - 发现的Bug要记录在文档里，并确保所有的问题都修复，避免遗漏 - 对于不能重现的Crash等严重Bug，尽可能提供Crash Log，并请DEV研究解决

UI验收测试

1. 测试目标 - 确保所有涉及到的UI页面和动画效果显示都和设计的完全一致 - 确保在不同尺寸/分辨率机型上都能兼容 2. 测试点编写 - 为每个页面添加测试点，包括页面布局、控件(位置、大小、对齐、颜色、按下效果)、文字(字体、颜色、位置、大小、对齐、换行、显示内容)等 - 为每个动画效果添加测试点 3. 测试注意点 - UI验收需要根据UI效果图来验收，做到1像素差异都不放过 - 需要在不同尺寸/分辨率设备上测试兼容性。尺寸/分辨率可以根据活跃用户分布情况从最大到最小中选择最有代表性的几个。 - 对于不太确定的UI效果，需要找PM和设计师验收 - 对于新页面或动画效果，需要找周师兄验收；找周师兄验收尽可能提前，以避免耽误MS完成时间或者上传时间 - 复杂的页面或动画效果需要提前通过Demo实现后先请设计师和周师兄审核 - UI验收可以和模块测试同时进行

模块集成测试

1. 测试目标 - 确保模块分支代码集成到Develop上后没有新问题出现 - 确保集成的不同分支之间的相互影响带来的问题都能发现并解决 2. 测试点编写 - 同模块测试的测试点 - 如果从模块分支创建到集成期间，Develop已经集成了其他分支，则需要结合这些分支添加测试点(可以请DEV列出分支之间相互影响的功能作为参考) 3. 测试注意点 - 模块测试的测试点至少在一款设备上全部测完(可以根据用户分布情况选取用户最多的设备) - 重点关注对不同分支集成的影响的测试点

Trunk系统测试／新增功能测试

1. 测试目标 - 确保所有功能都集成到Develop之后，App能达到可打包上传的标准 2. 测试点编写 - 同所有模块测试的测试点 3. 测试注意点 - 新增功能测试只需要测试本版本新增加的功能；系统测试需要测试所有的App功能 - 系统测试仅针对新产品/产品重构/功能添加或改动比较多时，一般情况下只需要执行新增功能测试 - 系统测试/新增功能测试在所有的模块都完成模块集成测试后进行 - 系统测试/新增功能测试需要选择至少2个典型的机型进行测试 (根据活跃用户分布情况，选择分布较多的不同OS版本和尺寸/分辨率的机型) - 系统测试/新增功能测试需要在生产环境下进行，并使用生产环境下的Plist配置

多语言测试

1. 测试目标 - 确保所有需要多语言的文字/图片都正常显示 - 确保文字/图片的多语言没有影响功能使用 2. 测试点编写 - 列出所有需要多语言的文字和图片，并添加显示测试点 - 列出所有使用数字的地方，添加关于数字显示本地化的测试点 3. 测试注意点 - 重点测试文字/图片的文案和显示(特别关注文案的大小，上下/左右对其方式，截断或省略等) - 当文案显示有问题时，需要确定是否要改变字体、对齐方式、显示行数，或者修改翻译 - 涉及到按钮以及其他控件时，需要检查按钮及控件的功能是否受影响 - 每个语言的每个文字和图片都需要测到 - 选择测试设备时需要考虑到不同OS版本和不同尺寸/分辨率的兼容性

Flurry测试

1. 测试目标 - 确保所有需要添加的Flurry都成功添加和上报 2. 测试点编写 - 添加Flurry记录表，并按照Flurry记录表进行测试 3. 测试注意点 - iOS产品需要使用Debug版本的Analytics库进行测试 - 每个Flurry都需要测试到 - 确保Flurry项产生的条件是充分必要的，不会出现条件还没满足就多记的情况 - 当Flurry项的出现条件有多种情况时，每一种情况都需要测到，以避免漏记 - 当Flurry项带有参数时，需要测试每一种参数都正确上报 - 当Flurry记录的条件过于容易，以至于每天可能重复记录N多次时，需要考虑是否要加上每天只记一次等条件以降低上传次数 - 有一些Flurry出现的条件比较复杂，可以请DEV通过添加测试代码来测试

＊切图＊

1、沟通要充分，确定切图需求，包括切哪些图，怎么切 - 与设计师沟通：若觉得设计图有问题，不能按要求切出，需及时找设计师沟通，修改设计图。 - 与DEV沟通：切图前，必须与DEV沟通，了解DEV对图的需求。 2、不能随意修改设计图： - 切图必须与设计图完全保持一致，不能随意对设计图进行变形、缩放、修改等操作。 3、切图上禁止出现文字： - 除艺术字等广告文字外，切图上禁止出现文字，从而方便文字的修改及多语言的制作。 4、尽可能减小文件大小： - 在保证界面效果的前提下，尽量减小图片文件的大小，以免使程序体积过大。

概述

1、切图的概念： - 把组成设计图的各个元素，从设计图中切分出来的过程。 2、切图示意图：

过程

与DEV 设计师沟通

- 有时DEV需要几个图形元素合并成一个图形，有时DEV需要把一个图形拆分成不同的几个图形元素，此时可能需要与设计师沟通，请设计师修改设计图，才能成功切图。 - 有时为了较小图片大小或适应不同分辨率，DEV需要图形元素的一部分，之后通过拉伸的方式实现设计图的效果。此时需要参考“高阶切图方法”中“2. 制作可拉伸图片及”.9"图片”。

具体切图

打开文件

使用Photoshop打开设计师提供的xxx.psd图片

选择要切分内容

1. 选择并设置“移动工具”属性： - 在Photoshop工具箱中选择“移动工具”，并设置其属性为“自动选择” + “图层”。 2. 选择要切分内容： - 点击需要切分的图形，Photoshop会在界面右下方的“图层”面板中导航到此图形所在的图层。 - 通过点击此图层前的“眼睛图标”，来隐藏、显示图层，以此来确定所选择的图形是我们需要的图形。

切分内容

- 选择出需要切分内容后，在“图层”面板中右键点击此图层，选择“转换为智能对象”选项，双击转化后的图层，该图层会在另一个窗口中打开。

保存内容

1. 调整图片大小： - 将图片调整为固定大小。尽量裁剪掉图片周围透明区域（若透明区域上有阴影，则不能裁剪，但尽量使图片居中显示），通过选择"图像" - “画布大小...”来裁掉周围透明区域。 - 为了保证可以适应不同分辨率，若为iOS图片，则需要画布大小最终为2的倍数；若为Android图片，则需要画布大小为4的倍数。 - 为了减小DEV调整UI的工作量及可能出现的UI问题，同类元素要调整为相同大小。（例如上图三个图标）。 * 宽度、高度：设定需要的图片尺寸。图片最终会被剪裁为设定尺寸。 * 定位：设定图片剪裁方向。箭头表示从某个方向开始裁剪。通过点击箭头调整裁剪方向。 2. 选择保存方式： - 保存为高分辨率图片。选择“文件” - “存储为Web所用格式...”，在弹出对话框中，在右上角“预设”选项中，设置图片保存格式。 - 保存格式设置：若图片中没有透明像素，则保存为“JPEG 高”格式。若图片中有透明像素，则保存为“PNG-24”格式。 3. 为保存图片命名： - 需严格按照公司文件命名规则来命名，若需要了解公司文件命名规则，请点击这里 4. 保存为低分辨率图片： - 高分辨率图片保存成功后，选择“图像” - “图像大小...”来修改图像尺寸，以适应低分辨率设备。 - 若为iOS图片，则需要修改图像尺寸为原尺寸二分之一；若为Android图片，则需要修改图像尺寸为原尺寸四分之三。

熟悉

合格Guideline

备注： * 要注意做一些积累，逐渐提升文案的内功。一些积累心得： - 操作系统尽量用英文版，记住一些系统的标准用法。 - 看到其它程序的描述，截屏上的语言，what’s new等文案的时候，要沉淀一下，认真体会体会别人是怎么写的，不要轻易略过。 - 多看看Apple及其他公司的site。 - 对文案要敏感，使用App时看见别人弹出的广告，要留心体会一下。 * 广告型文案要求较高，应该邀请有经验的人（比如大师兄）一起讨论形成方案。 A. 核心原则（完成标准） 1.确保英文文案表达很地道：听起来像母语。 2.确保文案意思准确，易于理解：文案的意思表达要做到看上去让人想误解都难，尽量不要使用句式复杂的长句。 3.确保使用的都是常用词汇：不使用生僻的英文词汇，尽量用通俗易懂清晰的语言表达。 4.确保写出的广告型文案有吸引力：有吸引力即相关项点击率高，以不低于“50% off”的吸引力为合格的标准。 5.确保特定使用场景用的一定是标准说法：很多使用场景都有自己标准的表达方式，比如“使用用户名而不是Email地址来登录”这句话，一定有标准的说法，切忌自己编写。 6.确保长句尽量全部模仿：自己编写出来的长句，很难符合地道的原则，因此在写长句甚至段落时，最好是能找到雷同的说法，再替换某些单词。 B. 建议执行步骤（主要针对非广告型文案） 1.自己写出文案，把感觉可能不地道的、不确定是否正确的词或词组拿选出来在Bing/Google里搜索（写出来后可以使用Word自带的工具测试一下句子的易读性）。 2.搜索结果的判断需要满足: 第一、类似说法很多。第二、大概看一下上下文，确保是母语人士说的英文。第三、如果发现别人有同样意思，但是说得更好的，可以借用。 3. 结合自己的经验，如果自己还是不确定，再发给母语人士检验， 4. 困难的或者非常重要的问题应该邀请大师兄、周师兄或者老外讨论，比如取名字等。 5. 某些标准的用语，可以参考OS系统，或者其他大品牌App的文案。

写文案 bing／google搜索

结合经验判断

咨询专家

参考标准文案

设计单创建

详细需求

“任务描述”中要尽可能详细地描述设计的需求，将细节告诉设计师，方便设计师理解产品的概念，提高做好的概率。需求包括：设计哪些页面、每个页面都有哪些元素、每个元素都有哪些特殊的要求（比如尺寸、数量、位置、颜色等等）。

列出要求设计图

“预期目标”中要写全最终要求设计师出的设计图。

提供草图

草图可以给设计师提供一个大概的设计思路，不需要很精美。

明确优先级别

每个设计单都必须明确标注该任务的优先级别。 - 优先级别的概念和定义可以参见【Guideline-iHandy-05：任务优先级别概念定义和使用原则】。

完成时间

每个设计任务都应该有初稿和终稿，要和设计师商量确定一个合理的初稿和终稿的完成时间。若超出规定时间必须填写延期时间和延期原因。 - A级设计任务要求第二天出初稿。B级设计任务要求隔天出初稿。 - 初稿和终稿完成时间必须拉开距离，因为出初稿之后有颠覆性改变的可能性是很大，可能需要多次修改。

过稿次数 过稿人

每个设计单要填写预测过稿次数(Hz)和过稿人，这样就知道在终稿之前必须要调整几次，便于控制和把握整个任务的节奏。一般过稿人是艺术家，特殊情况可能需要周师兄或者黄师兄参与。定终稿之前要给黄师兄看。

避免多任务

一张单子内不能含有太多任务。若任务过多，应该拆成多个单子，以方便管理。

测试用例设计

1. 测试点覆盖要全面：确保尽可能覆盖所有的需求点，以及每个需求点所有适用的测试方法。在写测试用例的时候，遗漏需求点或者遗漏测试方法是最主要的原因，PM需要尽可能避免。 - 需求点是功能需求、UI需求和代码逻辑需求的最细分的组成部分。功能需求来自于需求文档，PM可以通过画动态逻辑图的方式确保所有的页面跳转逻辑全覆盖；UI需求来自于UI设计图和动画效果；代码逻辑需求（隐含逻辑）是指DEV编码过程中隐含的逻辑，通常没有包含在功能需求中，PM可以向DEV了解该部分代码逻辑，列出逻辑需求点。 - 常用的测试方法主要有：功能正确性、UI一致性、文案一致性、数据一致性、边界值、非法值或非法操作、功能交互或数据交互、中断、压力、兼容性、升级测试等。具体测试方法的介绍和举例可参见《测试点和报告模板》。 - 测试点就是需求点和测试方法的组合。通常情况下，一个测试点对应着一个需求点和一种测试方法。需求点和测试方法可以组成一个二维的矩阵，比如纵轴是需求点，横轴是测试方法，每一个需求点和测试方法的交叉点就是一个测试点。只要确保覆盖了所有的需求点和每个需求所有适用的测试方法，就能确保覆盖所有的测试点。测试点是测试用例的简要描述。 测试点：输入正确的用户名和错误的密码，点击登录按钮，确认用户登录失败，并显示密码错误的提示。 需求点：登录 测试方法： 非法值 常见需求点的测试点可以参考【FAQ】中的第4点。 2. 测试点的描述要全面、简洁：确保测试点的内容在信息全面的基础上要做到简洁明了，通俗易懂，一目了然。 - 测试点的内容要包括所测试的需求点、测试的步骤和期望的测试结果。在确保信息全面的基础上，尽量用一句话来描述测试点，以便提高设计测试用例的效率； 给其他用户发送1条Like+消息，确认用户能收到并正常显示Like+消息，同时Like数量+10。 - 有一些测试点的需求点或测试方法比较相似，这样的测试点可以考虑合并成一个测试点，避免人为设计过多的测试点，降低测试点设计和执行效率； 注意：合并不意味着减少测试点，可以把相似的地方通过分隔符“/”或“、”来合并显示。 修改用户Profile中的Status (空/满、正常字符/Unicode字符/特殊字符)，从其他人查看自己的Status，确认修改成功并能够正常显示。 - 对于不方便执行的测试点，可以委托给开发进行代码测试；对于没有UI的测试，可以辅助一些日志定位和代码断点等测试手段。 购买Credits时，本地存在多个Receipt同时发到服务器验证，确认服务器能够处理正确，客户端没有问题。(需要DEV模拟环境测试) 3. 测试点要避免重复：设计测试用例时应该避免同一个测试点对应着多条测试用例，以提高测试效率。 4. 测试点排序要符合测试执行的顺序：测试点可以按照功能模块进行分组，并且按照功能页面的顺序、功能使用的逻辑顺序和测试方法种类进行排序，以提高测试效率。

整理需求点

- 根据需求文档，画动态逻辑图，确保所有的页面、功能点和功能逻辑都包括在动态逻辑图中。 - 根据动态逻辑图和需求文档，按照页面和功能的顺序整理并列出功能需求点。 - 根据设计图和动画效果整理并列出UI需求点。 - 和DEV沟通，了解并列出在需求文档之外的代码实现中隐藏的逻辑需求点。

找出使用测试方法

- 通过Excel或者Numbers工具，列出所有需求点，作为矩阵的纵轴。例如，A列写功能模块，B列写每个功能模块的每个需求点。 - 在第一行列出所有的测试方法。(具体测试方法的介绍和举例可参见《测试点和报告模板》) - 一一对比需求点和测试方法，如果适用就在交叉的单元格打一个标志（如“X”）。可参见下面的图片： - 熟练时可以简化以上步骤，直接对比需求点和测试用法列出每一个需求点适用的测试方法。（慎用，容易漏测试点）

写测试点描述

- 复制一份测试用例模板，在《测试结果》页中填写“功能模块”、“测试点”和“测试方法”。 - 测试点通常用一句话来概括需求点、测试步骤和期望的结果。

合并去重

- 检查测试点，合并需求点和测试方法相似的测试点，以控制测试点的数量。(举例：数值相关的等价类划分测试和边界值测试可以写在一个测试点中) - 检查测试点，删除重复的测试点。

其他人评审

- 找其他PM或者DEV Lead评审测试用例。评审通过后，测试用例就可以定稿了。

FAQ

【FAQ】 1. 为什么要编写测试点？ - 测试点是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式； - 测试点是团队内部交流以及交叉测试的依据，便于测试工作的跟踪管理，包括测试执行的进度跟踪和测试质量的跟踪； - 测试点可以避免测试工作开展的盲目性； - 测试点是相信产品质量的最佳依据，同时也可以作为项目验收的依据。 2. 什么时候准备测试点比较合适？ - 需求确定下来后就可以着手写测试点了，最晚在开发开始时就要开始编写测试点； - 确保在开发完成编码之前测试点编写完毕，以避免因时间太紧导致遗漏测试点或者延误开发MS。 3. 测试点和测试用例有什么区别？ - 测试用例有固定的格式，包括“标题、前提条件、操作步骤、期望结果、实际结果”等。 - 测试点是测试用例要点的简要描述，是测试用例的简化版。为了简化测试过程、提高测试效率，可以直接写测试点进行测试。 4. 常见需求点都有哪些测试点可以参考？ - UI页面：页面布局、每个页面元素的尺寸/位置/颜色、文案的字体/大小/颜色/位置、排序和对齐方式、图标/按钮的按住效果、动画效果、页面切换效果、不同分辨率手机显示兼容性等。 - 按钮/可点击图片：单击/双击/长按/滑动、快速点击、初始效果/按下效果/松开效果、有网点击/无网点击/取消点击、点击按钮同步&异步、页面切换过程中点击(无效点击)等。 - 文本框：输入文字/字母/字符/UniCode字符/Emoj/Sticker、边界值、键盘切换、软文提示、删除已输入内容、有网修改/无网修改、保存过程中断、保存后查看等。 - 弹出框/Alert/Tips：内容、位置、UI页面、动画效果/出现时长/自动消失、点击、后台回前台/杀进程/锁屏、和其他临时页面交互等。 - 图片/视频：下载/播放/暂停/左右滑动、多次快速滑动/播放、下载过程中断网/重新连网、后台回前台/杀进程/锁屏、Like/收藏/分享、不同OS版本手机兼容等。 - 数值：不同的典型值(等价类划分)、边界值、非法数值、准确性测试等。 - 风火轮：出现时机、hold全屏、点击按钮/返回键/home键、后台回前台/杀进程/锁屏/断网、点击风火轮或页面其他区域等。 - 数据：数据完整性/准确性/数量(等价类划分/边界值)/排序、 有网取数据/无网取数据、取数据时机/不同条件取数据、取数据过程中后台回前台/杀进程/锁屏/断网、重新登录查看数据、升级测试、数据库读写性能测试等。 - 服务器存储交互：有网存储、无网存储、失败重传机制(增/删/改)、上传过程中后台回前台/杀进程/锁屏/断网、存储成功验证、不同客户端版本存储读取兼容性、有网升级测试/断网升级测试/非登录状态升级等。 - 服务器接口/数据变动：新代码新数据、新代码老数据、老代码老数据、老代码新数据。 5. 有哪些常见的测试用例设计方法理论可以参考？ 常见的黑盒测试点设计方法有：等价类划分法、边界值法、错误推测法、因果图法等。 等价类划分法：等价类划分就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，覆盖了更多的可能数据，以发现更多的软件缺陷。更多内容参见http://baike.baidu.com/view/3028549.htm 边界值法：边界值测试指的是大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。更多内容参见http://baike.baidu.com/link?url=dJn_7OOarjFv_K8gb9RUkP9nr9CPcjp3DWKGCPq018j-7VbG5a4I3Ry5I8uyj5Ehg_WNHczUcQzfdDxL8BR9d_ 错误推测法：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试点的方法。更多内容参见http://baike.baidu.com/view/4950985.htm 因果图法：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。更多内容参见http://baike.baidu.com/view/4532272.htm

PM共享流程模版

掌握

What's New Guideline

内容使人兴奋

What’s New 要求语言能让用户产生兴奋感，提高下载率。 What’s New写出的语言给用户的直观感受要像电视购物一样，具有强烈的煽动性。 示例事件：InstaMessage 更新了 Recently Online 功能，能让用户更易查看最近在线的好友。 初稿版： - Enhanced Recently Online to get replies more easily! - Faster startup speed and improved stability 点评：语言平淡，不能让用户兴奋 正确说法： - Check out who's waiting there! Enjoy the new enhanced Recently Online NOW. - Get better replies when you use a photo in Quick Chat! 点评：更改后的说法不仅说清楚了更新的地方，并且能让用户兴奋起来，用户会更有欲望去更新。

语言积极

What’s New 语言用辞要求积极乐观，不能让用户产生对程序失去信心的感觉。 示例事件：Carpenter的Ruler在iPhone 6和6 Plus上刻度不准，更新修改了这个问题。 初稿版： - Fixed an issue that the ruler was inaccurate on iPhone 6 and 6 Plus. 点评：语言不积极，看着让人感觉很悲观，可能会对这个程序失去信心。 针对上述问题的修改版： - Improved accuracy of ruler on iPhone 6 and 6 Plus. Try it now! 点评：这一版本语言很乐观，能让有问题的人觉得问题解决了，很高兴。

有引导性

要引导用户去使用我们想让用户使用的功能，同时要避免给用户造成错误引导，致使用户去用我们并不想他们使用的功能。

语言地道

语言看起来要像老外说的。 要避免太专业化的词汇，例如algorithm，但像engine、system这样用户容易理解的词汇是可以使用的； 避免使用我们内部使用而普通用户不容易理解的词汇。 事件示例：InstaMessage 优化了 Recently Online 算法，能让用户更易查看最近在线的好友。 初稿版： - New optimization algorithm: Get TONS of replies when you use a photo in MiniChat! 点评：使用了太专业的词汇algorithm和公司内部使用而用户不易理解的词汇MiniChat. 针对上述问题的修改版： - Get better replies when you use a photo in Quick Chat! 点评：不必告诉用户涉及专业词汇的技术细节，使用用户容易理解的词汇；

避免透露核心思路

不能透露产品核心思路，目的是为了避免让竞争对手看到。

避免重复

要避免和以前的版本重复；要避免和别的账号的What’s New一样，除非是通用的，例如性能优化等。

针对Bug修复要求

不能吓到用户； 要给有大Bug的用户希望； 要让有问题的用户看到问题得到了解决，感到很高兴，同时也要让没有这个Bug的用户明确程序没问题，而且能感觉程序很好。 示例事件：Carpenter的Ruler在iPhone 6和6 Plus上刻度不准，更新版修改了这个问题。 初稿版： - Carpenter is perfect on all devices now! 点评：没问题的人看了不会有疑问，但是有问题的人会觉得不清不楚，很困惑。 针对上述问题修改版： - Ruler is 100% accurate even on iPhone 6 and 6 Plus. 点评：有问题的用户看见明确问题解决了，没有问题的用户不会怀疑自己。

不低于两条

原则上，What’s New 不低于两条。如更新只有一个内容，可以再加上性能提升等。

步骤

1. 列出此次产品更新的内容。 2. 确定哪些是重点更新，哪些是可有可无的，重点更新放在前面。 3. 参考上述标准和实例，写出What’s New 初稿。 4. 将初稿与设定的标准逐条对比，看看是否满足要求。上述所有要求都需要满足。 5. 将自己写的What’s New 与竞争对手的作对比，要让自己从用户的角度觉得我们的What’s New写得更用心。

FAQ

1. 没有更新理由的时候，例如只是为了更新广告库、更换 iTunes名字、更新内容不能让用户知道的时候，What’s New怎么写？ 使用其他“正当”理由，例如iPhone 6 & 6 Plus 适配等； 用性能优化，例如加快了启动速度，优化用户体验等理由； 参考同类产品，竞争对手的What’s New，寻找灵感，但是要比原文写得更好。 示例事件：Get Followers 做了一次更新，但是更新内容不能让用户知道。 What’s New 可以这么写： - Big improvements to make getting followers even faster. 2. 语言怎么处理？是要非常明确还是故意模糊以给用户神秘感？ 有的时候需要用户无歧义，明确说明更新内容，但有的时候需要用户模糊一点，给用户一些神秘感。 3. What’s New 注意事项 What’s New 中不能使用Emoji表情，因为 App Store 规定 What’s New 不支持Emoji表情。 4. 怎么使用语言能让用户兴奋 强调用户关心的点； 某些具有号召性的词汇可以使用大写，例如“CHECK OUT NOW”.

Update Alert Guideline

让用户兴奋

Update Alert 的内容要能让用户产生兴奋感。 对于一次更新了多个功能的，重点放在最能抓住用户的功能上，促使用户去应用商店给予我们的产品好评。 示例事件：InstaMessage 更新了 Recently Online 功能，能让用户更易查看最近在线的好友。 初稿版： - Enhanced Recently Online to get replies more easily! - Faster startup speed and improved stability 点评：语言平淡，不能让用户兴奋

引导性

在 Update Alert 中，要引导用户去使用我们想让用户使用的功能。

积极乐观

Update Alert 语言要积极乐观。 示例事件：Carpenter的Ruler在iPhone 6和6 Plus上刻度不准，更新修改了这个问题。 初稿版： - Fixed an issue that the ruler was inaccurate on iPhone 6 and 6 Plus. 点评：语言不积极，看着让人感觉很悲观，可能会对这个程序失去信心。 针对上述问题的修改版： - Improved accuracy of ruler on iPhone 6 and 6 Plus. Try it now! 点评：这一版本语言很乐观，能让有问题的人觉得问题解决了，很高兴。 示例事件：InstaMessage 更新优化了位置服务功能，定位更精准。 初稿版： - Updated location services to maximize the success rate of finding your location. 点评：听起来可能会吓到用户。有关location service，用户其实潜意识里面是希望能看见周围的人，是“别人”的location. "把自己的location交出去”是负面的感觉，“看到你周围的别人”是正面的感觉，所以要避免“我看到你的location”这样的话语。

地道

语言看起来要像老外说的。 要避免太专业化的词汇，例如algorithm，但像engine、system这样用户容易理解的词汇是可以使用的； 避免使用我们内部使用而普通用户不容易理解的词汇。 事件示例：？ 初稿版： - New optimization algorithm: Get TONS of replies when you use a photo on MiniChat! 点评：使用了太专业的词汇algorithm和内部使用而用户不易理解的词汇MiniChat. 针对上述问题的修改版： - Get better replies when you use a photo in Quick Chat! 点评：不必告诉用户涉及

针对Bug

对于重大bug, 要跟用户说解决了； 对于有把握的bug, 可以说的细致，显得真诚。但是要注意不能吓到没有遇见这个bug的用户，这里就需要判断bug的覆盖面，能区分出遇到该bug的用户最好。

步骤

1.列出此次产品更新的内容。 2. 确定哪些是重点更新，重点放在能抓住用户的更新上。 3. 参考上述标准和实例，写出Update Alert 初稿。(Update Alert 可参考What’s New 内容) 4. 将初稿与设定的标准逐条对比，看看是否满足要求。上述所有要求都需要满足。

FAQ

1. 没有更新理由的时候，例如只是为了更新广告库、更换 iTunes名字、更新内容不能让用户知道的时候，Update Alert 怎么写？ 用性能优化，例如加快了启动速度，优化用户体验等理由； 参考同类产品，竞争对手的What’s New，寻找灵感，但是要比原文写得更好。 示例事件：Get Followers 做了一次更新，但是更新内容不能让用户知道。 Update Alert 可以这么写： - We have worked on many improvements to the overall experience. Enjoy! 2. 语言尺度怎么把握？是要非常明确还是故意模糊以给用户神秘感？ 有的时候需要用户无歧义，明确说明更新内容，但有的时候需要用户模糊一点，给用户一些神秘感。