第一周总结_prd、测试用例区别

1:测试模型v/w

v模型：V模型大体可以划分为以下几个不同的阶段步骤：客户需求分析、软件需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

客户需求分析

即首先明确客户对于产品的需求，软件所具备的功能。这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出需求规格说明书。

软件需求分析

主要根据客户需求分析出软件方面的需求，即需要软件需要的功能，软件需要适应的硬件功能。该部分关键的是做到需求的剥离，以保证软件功能需求覆盖客户需求且不涵盖硬件或其他方面的需求，以方便软件工程师的进一步开发。

概要设计

主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。

详细设计

对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。其中需要包含数据库设计说明。

软件编码

按照详细设计好的模块功能表，编程人员编写出实际的代码。

单元测试

按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。

集成测试

经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。

系统测试

经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。

验收测试

主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到预期的效果。

M模型：

2:公司流程

我们公司的流程是，首先是要立项确定项目--产品会出一个产品说明书--需求人员编写需求文档
--需求评审--开发编写详细设计--测试编写测试用例--测试用例评审--开发进行编码--测试部署
环境进行测试--首先进行冒烟测试(主的业务要实现)--接着进行功能测试--出现bug使用禅道进
行记录跟踪--开发进行修改--测试进行验证--然后进行回归测试--接着验收测试，验收测试通过--进行上线

3：软件测试分类

一、按开发阶段划分
1.单元测试（Unit Testing）
单元测试，又称模块测试。对软件的组成单位进行测试，其目的是检验软件基本组成单位的正确性。测试的对象的是软件你测试的最小单位：模块。

测试阶段：编码后或者编码前
测试对象：模块
测试人员：白盒测试工程师或开发人员
测试依据：代码和注释+详细文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据测试、路径测试、错误处理测试、边界测试
补充说明：
（1）学习测试依据时，我们可以对比软件测试的“V”模型结合记忆
（2）白盒测试不是单元测试，单元测试是白盒测试
（3）测试驱动开发：测试人员先编写测试用例，开发人员根据测试用例写程序
2.集成测试（Integration Testing）
集成测试也称联合测试（联调）、组装测试：将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
测试阶段：一般是单元测试之后
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的文档+概要设计文档
测试方法：黑盒测试与白盒测试（灰盒测试）
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能的正确性、全局数据结构、单模块缺陷对系统的影响
补充说明：
单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个）

3.系统测试（System Testing）
系统测试：将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。

测试阶段：集成测试阶段之后
测试对象：整个系统（软件、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
补充说明：
（1）系统测试是从完整的角度，广面去看待问题，不再看模块
（2）虽然系统测试包括冒烟测试和回归测试，但三者之间是有严格的先后顺序的，即：先冒烟、再系统、后回归。

（1）回归测试（Regression Testing）：指修改了旧的代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。（自动回归测试将大幅度降低系统测试、维护升级等阶段的成本）。

在整个软件测试过程中占有很大的工作比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

（2）冒烟测试（smoke testing）：该术语来自硬件，指对一个硬件或一组硬件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试，也可以理解为该种测试耗时短，仅用一袋烟的功夫就足够了。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续正式的测试工作。
冒烟测试的执行者是版本编译人。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续测试。
4.验收测试（Acceptance Testing）
验收测试（交付测试）：是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。

测试阶段：系统测试通过后
测试对象：整个系统（包括软硬件）
测试人员：主要是最终用户或者需求方
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试（功能、各类文档文档等）
下面，我们以手机为例，举个例子：

针对买回来的新手机以及它的美颜功能来进行测试。
（1）当买回来的手机，它的美颜功能有问题时，我们只针对美颜功能的代码进行测试，就是单元测试。
（2）对于新买回来的手机，检测手机通讯录是否可以增添、删除、更改手机号码，打电话时需要手动的输入电话，也可以在手机中查找，这就是集成测试。
（3）新手机都会有一个合格标签，原因是出厂前手机厂商会对某一个型号的手机功能全部测试一遍，包括手机硬件本身，手机自带的APP等，这个叫系统测试。
（4）当修好新买回来的手机的美颜功能以后，用户除了会查看美颜功能是否完好，还会查看其他功能是否也完好，这个叫回归测试。
（5）对于新买回来的手机，我们做的第一件事是将常用的手机功能试一遍，第二件事情就是讲所有功能都试一遍，这个叫冒烟测试。
（6）对于新买回来的手机，一般都有7天包退，30天包换，我们一般都是在7天内把手机的所有功能都试一遍，这叫验收测试。

二、按是否查看代码划分
1.黑盒测试（Black-box Testing）
黑盒测试也是功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据。
2.白盒测试（White-box Testing）
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是指打开盒子，去研究里面的源代码和程序结果。
白盒测试也是接口测试的一种。

3.灰盒测试（Gray-Box Testing）
灰盒测试是介于白盒测试和黑盒测试之间的一种，灰盒测试多用于集成测试阶段，不仅关注输入、输出的正确性，同时也关注程序内部的情况。
灰盒测试：功能+接口

三、按是否运行划分
1.静态测试（Static testing）
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。分析如下：

检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。
静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。
静态测试：代码静态分析和文档测试都属于静态测试。

2.动态测试（Dynamic testing）
动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性、健壮性、等性能。
（1）动态测试有三部分组成：构造测试用例、执行程序、分析程序的输出结果。
（2）大多数软件测试都属于动态测试。

四、按测试对象划分
1.性能测试
检查系统是否满足需求规格说明书中规定的性能。
通常表现在以下几个方面：

对资源利用（如内存、处理机周期等）进行的精确度量
对执行间隔
日志事件（如中断，报错）
响应时间
吞吐量（TPS）
辅助存储区（例如缓冲区、工作区的大小等）
处理精度等进行的监测
2.安全测试
安全测试是一个相对独立的领域，需要更多的专业知识。如：WEB的安全测试、需要熟悉各种网络协议、防火墙、CDN、熟悉各种操作系统的漏洞、熟悉路由器等。

安全测试这个领域感觉也是很有意思的，希望以后有机会学习学习！！！

3.兼容性测试
兼容性测试主要是指，软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。

平台测试
浏览器测试
软件本身能否向前或向后兼容
测试软件能否与其它相关软件兼容
数据兼容性测试
最常见的兼容性测试就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页面显示不同。
常见的IE8的兼容性。

4.文档测试
国家有关计算机软件产品开发文件编制指南中共有14种文件，可分为3大类。

开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
用户文件：用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
在实际的测试中，最常见的就是用户文件的测试，例如：手册说明书等。
文档测试关注的点：

文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
5.易用性测试（用户体验测试）
易用性（Useability）是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。

6.业务测试
业务测试是指：测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程。

7.界面测试
界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

8.安装测试
安装测试是指：测试程序的安装、卸载。最典型的就是APP的安装、卸载。

9.内存泄漏测试
内存泄漏的检测： 1、对于不同的程序可以使用不同的方法来进行内存泄露的检查，还可以使用一些专门的工具来进行内存问题的检查，例如MemProof. AQTime、Purify、BundsChecker等。 有些开发工具本身就带有内存问题检查机制．要确保程序员在编写程序和编译程序的时候打开这些功能。
2、通过代码扫描分析工具来检查

五、按测试实施的组织
1.α测试（Alpha Testing）
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。
2.β测试(Beta Testing)
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
α测试与Beta测试的区别：
（1）测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
（2）Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
（3）alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。

3.第三方测试
介于开发方和用户方之间的组织测试。
六、按是否手工执行划分
1.手工测试（Manual testing）
手工测试是由人一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一种。

优点：自动化测试无法代替探索性测试、发散思维类无既定结果的测试。
缺点：执行效率慢，量大易错。
2.自动化测试（Automation Testing）
所谓自动化测试，就是在预设条件下运行系统或应用程序，评估运行结果。（预先条件包括：正常条件和异常条件）。简单来说，自动化测试就是是把人为驱动的测试行为，转化为机器执行的一种过程。

自动化测试有：测试自动化、性能测试自动化、安全测试自动化。（一般情况下，我们说的自动化是指功能测试的自动化）
自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。
自动化实施的步骤：
（1）完成功能测试，版本基本稳定
（2）根据项目特性，选择适合项目的自动化工具，并搭建环境
（3）提取手工测试的测试用例转换为自动化测试的用例
（4）通过工具、代码实现自动化的构造输入、自动检测输出结果是否符合预期
（5）生成自动测试报告
（6）持续改进、脚本优化

七、按测试地域划分
1.国际化测试
软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。

本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试 的一些要点。
1、本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否墼齐、不走样。
2、是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等。
3、在不同的屏幕分辨率下界面是否正常显示。
4、是否存在不同的字体大小，字体设置是否恰当。
5、日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年。
6、排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序。
7、在不同的国家采用不同的度量单位，软件是否能自适应和转换。
8、软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
9、软件是否能在Windows或者其他操作系统的当地版本上正常运行。
10、联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法错误。
软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测 试人员具备一定的翻译能力、语言文化，同时具备测试人员的基本技能。

4：测试点

1.界面的比例大小、加载出的内容
2.页面的按钮展示，以及按钮的功能
3.用户注册中的验证码失效的校验
4.用户登录过程中的断网行为
5.用户登录后的左侧菜单栏，菜单栏的情况，菜单栏的伸缩情况，不同身份展示的菜单栏情况
6.列表中【上一页】【下一页】【首页】【末页】按钮的展示，是否正常
7.若是有上传的图片，确定图片上传的格式（每一种都要校验
常用JPG、PNG、JPEG、GIF、
）注：图片上传时要注意图片格式的大小写问题
8.填写用户的信息是每一种情况（
例：app端用户注册：
1.用户的输入的手机号码为空，点击获取验证码
2.用户输入的手机号码错误，点击获取验证码
3.用户输入正确的手机号码，点击获取验证码
4手机号码是否被注册过。
5.用户输入的验证码错误，点击【确认】按钮
6.用户输入验证码失效，点击【确认】按钮
7.用户输入正确的验证码，网络中断，点击【确认】按钮
8.用户输入正确的验证码，点击【确认】按钮
9.用户输入的密码和确认密码为空，点击【确认】按钮
10.用户密码为空，输入确认密码，点击【确认】按钮
11.用户输入密码，确认密码为空，点击【确认】按钮
12.用户输入的两次密码不一致，点击【确认】按钮
13.用户输入的密码长度校验
（1）输入密码的长度为8位
（2）输入的密码小于8位
（3）输入的密码大于16位
（4）输入的密码小于16位，大于8位
（5）输入的密码等于16位
（6）输入的密码全是数字
（7）输入的密码全是字母
（8）输入的密码全是特殊字符
（9）输入的密码是数字+字母
（10）输入的密码是字母+特殊字符
（11）输入的密码是特殊字符+数字
（12）输入的密码是数字+字母+特殊字符
（13）输入过程中网络中断
（14）密码的查看功能
）

14.短信登录情况中的
（1）短信链接校验
（2）验证码的失效问题
（3）重新获取验证码的情况
（4）验证码的正确性

15.不同用户的权限不同展示的情况不同，需要将具体的情况进行具体的展示介绍（列举不同的权限展示的情况，以及页面显示的情况，页面的切换情况）

16.用户登录、注册时要考虑断网的问题

17.app的卸载问题安装问题（要考了是否卸载干净、下载过程中是否会网络中断、安装覆盖是否正常、安装异常的提示、不同系统的升级情况、自动升级失败后再次自动升级、卸载的时快捷方式是否卸载，组件是否卸载成功）

18.窗体的最大化、最小化对导航栏是否有影响

19.页面中字体、颜色、图标、大小、

20.记住密码的功能是否记住（
（1）错误的密码点击记住密码
（2）正确的密码点击记住密码
）

21.字体输入时要注意特殊的情况，全英文，全中文，全数字，中文+数字，英文+数字的情况下是什么样的。
 

5：公司专有名称,类似pm/case等

PM  产品经理

RD 研究和开发人员

FE 前端研发人员

UE 用户体验

QA 是测试

OP 是运维

IDC 机房

DB 数据库

DBA 数据库管理员

UI （用户界面）的简称

PSD 图像处理软件Photoshop处理后保存的源文件,一般容量比JPG格式的图片大。

SOP 标准作业程序

MRD 市场需求文档

PRD 产品需求文档 重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。

FSD 功能详细说明。

CRUD 增加 、读取、更新、删除

6：b/s和c/s的区别

C/S(Client/Server)：又称客户/服务器模式。服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sql Server等。客户端需要安装专用的客户端软件，结果图如下：

举个栗子：以电脑上的qq为例，qq APP就是Client客户端，存放所有用户信息的地方就是qq的Server服务器。

 B/S（Browser/Server）：又称浏览器/服务器模式。是WEB兴起后的一种网络结构模式，WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。客户机上只要安装一个浏览器，如Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互。
结构图如下：

举个栗子：我们经常访问的百度为例，当我访问百度时，我的电脑就是客户机之一，百度的代码存放的地方就是web服务器，而百度用户的信息及百度的一些基本数据信息就是数据库服务器。

对比：

一、C/S
1.优点：
（1）安全性：需要其特定的客户端，所以面向对象比较确定，将所进行的信息安全处于一个可控的范围
（2）效率：客户端的服务器直接相连，省却了中间环节，数据的传输比较快
（3）个性化：有特定的客户端，所以可以在较大程度上满足客户的个性化要求
（4）稳定性：结构比较稳定，有较强的事务处理能力，可以实现较复杂的业务逻辑
2.缺点：
（1）特定的客户端：对pc机有一定的要求，如：操作系统，并且它就像订在墙上的石头桌子，不可再利用
（2）中间环节：因为省却了中间环节，所以当客户端达到一定的量时，同时访问服务器，造成服务器的相应变慢，效率变低

二、B/S
1.优点：
（1）范围：零安装，拥有一个浏览器，即可访问，面向的范围更广
（2）维护性：维护简单，更新页面，即可实现面向所有用户的更新
（3）共享性：通过浏览器访问，共享性强，就像买来的餐桌，可以再利用
2.缺点：
（1）安全性：面向的范围广，所以安全性比较低
（2）个性化：因为面型的范围广，所以它是一种公共审美，无法满足个性化的需求

三、思想提升
    通过上面B/S 和C/S的对比学习，可以知道很多东西物极必反，就像网络一样，是一把双刃剑。

7：测试用例模板

用例编号、测试模块、用例标题、用例级别、前置条件、测试输入、执行操作、预期结果,实际结果…. 

8：测试报告模板

测试目标,测试依据,测试范围,测试环境,测试进度,执行结果,缺陷分布,遗留缺陷,测试结论,建议,附录等

9：测试计划模板

确定测试范围，制定测试策略，测试资源安排人员的分配，时间安排，风险分析等

10：编写测试用例的方法有哪些？以及对应的场景

1、等价类  输入框
2、边界值  输入框
3、因果图  自动买水机
4、场景设计法  atm机取钱
5、错误猜测法  

11：需求变动你该怎么做？

需求变化是个老生常谈的话题，当然，我们也知道，在产品的发展过程中，需求不变化的情况几乎是不存在的，就算是世界级的公司，这也是一种正常的情况，但是，如果需求频繁的发生变化，甚至因为需求的变化而造成产品定位的改变，这就是不正常的了。

这就像一个人总会有些脾气，偶尔发发是没问题的，但是三天两头发脾气就不得不考虑这个人是不是精神上有问题了。

因此，在本文中，我就简单说说如何合理的解决需求变动的情况，换句话说，就是我们如何把需求管理体系中可能存在的造成变动的窟窿堵住。

要解释这个问题，我们必须首先清楚，在需求管理体系中，可能会影响到需求变化的因素都有哪些，我总结了一下，大致可以包括三个方面：

1、人的因素：这里主要包括需求的控制者（通常为高层）、需求的管理和处理者（也就是产品经理），需求的执行者（也就是各个业务执行团队）；

2、平台的因素：这里主要包括需求管理的体系和流程、需求管理的方法和工具、需求管理的制度和规范；

3、管控的因素：这里主要包括对人和平台进行管理和控制的机制。

这三个方面的因素是如何对需求产生作用的呢，大家看下图：

怎么来看这张图呢，因为不是本文的重点，只简单说一下，和需求相关的利益者（也就是人），在相应的平台上对需求进行操作，而所有的操作过程都要受到公司和产品级的管控机制的管理。

接下来我们还是把重点放到在这三个方面中，都会出现哪些典型的造成需求变动的因素。

1、人的因素

先来看控制者，也就是C级管理层，通常会以评审委员会的形式出现，他们会如何影响需求呢？

我们还原一个场景。

产品已经进入到技术化阶段了，这个时候，某个C级的管理者突然和你说，我刚看到一个产品，其中有个功能挺不错的，你考虑一下咱们是不是也加上。

但我们都知道，说是让你考虑，其实就是你得做的意思，这个时候，产品经理就比较为难了，加吧，还得分析一下这个需求到底是否符合自己的产品，如果符合，还得考虑要增加多少工作量，还得和研发确定可行性什么的，不加吧，面子上过不去。

我也相信，大部分的产品经理最后还是很不情愿的去做了。

实话实说，C级管理者这类和需求相关的人所造成的影响，其实最难解决，我到现在也没有一个很合理的方法来搞定这类人，在我以往的工作中，尽管也尝试了很多努力，不管是苦口婆心的交流，或是期望他们也按照管理规范来做，但是效果都很一般，因此，我也只能喊一句口号：需求面前，人人平等。

既然暂时没有合适的方法，那就先搁置起来。

再来看处理者，也就是我们这些产品经理，这个就好说了，自己解决自己，也就是一枪的事。

产品经理自己通常会如何造成需求的变动呢？

还是先还原一个场景。

在PRD通过评审，并交付研发后，某天，你突然灵光一现，觉得PRD中的某个需求说明还可以再完善一下，于是就和研发说，有个需求不要按照原来的PRD去做了，我有更好的想法，于是，研发就开始骂娘了。

那么，针对这种情况，我以前是怎么做的呢，我们会给自己制定一个叫“需求变动量”的指标，什么意思呢，简单说，就是我们会记录一个需求在发展过程中，会出现多少次变动，比方说变动量上限为3次，只要不超过这个上限，就是可以接受的，但是一旦超过了，那么，我们就会暂停这个需求，分析是什么原因造成的，是因为产品经理对需求分析不到位，还是市场原始问题输入的就有问题。

这种方法对我们有什么好处呢，主要有两点：

1）强迫产品经理要对每个需求做足够到位的分析，一遍一遍的思考和权衡，甚至时不时推翻自己已有的想法，要在规定的时间内尽可能把每个都深思熟虑的需求交付给研发。

当时我们这样做的原因就是因为我们发现，人的大脑是有懒惰区的，经常会认为想的不错了，想的到位了，但，那其实只是因为大脑有些累了而释放出来的一个自我满足的信号，因此，通过一个外界的刺激（量化标准）来把这种自我满足的可能压到最低。

当然，并不是说这样就圆满了，而是我们希望把原来的60分提高到80分。

2）有利于复盘的时候发现经验教训，复盘的时候，我们会统计每个需求和整体需求的变动比如何，以及对照以往的数据，看看是增长了还是降低了，还有就是，变动的需求主要集中在哪些类别上，然后就会寻找原因，并加以进一步的完善和优化。

最后看执行者，执行者最普遍的影响因素在哪里呢？

还是还原一个场景。

需求评审会，你把所有的需求都介绍完了，问研发，这些需求明白了没有，研发说明白了，于是大家就签字，开干了。

但是会后，研发却指着PRD中的某个功能说，这个功能怎么这么设计啊，这个功能完成两天不可能，至少得三天，于是，扯皮大战就开始了。

问题出在哪里呢？

很简单，就是研发（也包括其它业务团队成员）在评审会上根本没认真、全面评估每个需求，只是参加了一个会，而不是一个有效的会，因此，会后你才发现，研发要咨询你的问题竟然还是一大堆。

我们当时是怎么解决的呢？

主要采用了三个策略：

1）在评审会之前，我们会规定提前多少天要把PRD提前发到相关利益人手里，并且规定提前看，评审会主要探讨每个需求能否解决，多少时间，谁来做，而不是去解释。

2）评审会上，我们会针对研发给出的每个答案做记录，如果大家都没有问题了，那就进入到“数据冻结”点，言外之意，就这么定好了，大家都不能动了啊。

3）评审会后，我们会形成会议记录，并发送到各个参会人手里，大家都留个纸面的东西，别过几天不承认自己说过的话。

这三个策略总结起来就是十二个字：提前准备；只听方案；留底存档。

整体上看，就是希望通过这些策略的使用，逼迫执行团队的成员不要把开会当成是一种负担，而是要把每一次业务会议重视起来，最终解决“会上不想，会后乱想”的情况。

2、平台的因素

We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems.

我们的非凡成果来自于普通人管理着非凡的体系。我们的竞争对手得到普通的成果是因为非凡的人周围都是支离破碎的体系。

这是丰田公司的主席张富士夫说的一句我认为对体系的作用和价值最到位的一句话。

需求管理系统作为产品管理四大体系之一，如何构建好，是个需要并值得深入研究的课题，产品管理中的需求管理系统，绝不是我们现在看到的这样，我说过了，现在大部分的产品管理中的需求管理系统其实很多都是脱胎于已有的研发管理中的需求管理体系的，两者之间有联系，但是肯定不能直接搞过来用啊，毕竟产品经理涉及到的需求分为三个层级：

商业需求；市场需求；产品需求。

我们的需求管理系统是要管理这三个层级的需求的，研发的需求更多的是项目层面的需求。

有点扯远了啊，如果大家有兴趣了解如何构建产品管理的需求管理系统，可以参考一下这两篇文章：

那么，平台的因素会如何造成需求的变化呢，这个从大面上说，其实很简单，没有合理的需求管理系统自然就会造成混乱，而混乱必然会出现很多影响因素，因为篇幅原因，我还是还原一个场景。

一个需求确实需要变动了，你看了看，认为变动不大，于是就通过了，然后研发就按照变动后的需求去做了，但是刚做了没多长时间，你的上级看到了，然后问你，为啥这个需求变动我不知道，谁让你通过的，记住，以后所有的需求变动都得经过我，于是，你就把挑子撂了，管他娘的呢，就按你说的来，我没事找骂这不是吃饱了撑的吗。

这其实就涉及到一个需求变更的管理，我也知道很多朋友的公司都有这个需求变更的制度，但是通常是形同虚设，按说不同级别需求的变动只要通过对应级别的人的审核就可以了，但是我就一直很奇怪，为什么就不能按照这个来呢？

我也观察了一些企业的情况，抛开人的因素，平台的因素也占了很大的比例，比方说，我们在定义需求变动级别的时候，往往都是比较粗粒度的，也就是说，在遇到具体情况的时候，往往很难直接从定义好的级别中找出标准，例如，产品经理可控制的需求变动级别，其中有一项是“不会对产品操作造成严重的影响”，这种定义就太宽泛了，啥是严重的影响，最好是定义清楚，这样才能方便操作。

当然，一开始构建这些标准的时候，谁也不能一下子想到位，想全面，但是体系和平台本来就是不断完善，不断优化的过程，丰田的TPS干了快40年了，不依然在不断改进吗！

3、管控的因素

有了合格的人，有了合理的平台，是不是就可以保证需求的管理不会出现混乱了呢，肯定不是了，再牛的人也会犯错，再好的平台也有漏洞，但是人往往是“当局者迷，旁观者清”，而平台自己又不具备自我发现问题，自我纠正的能力，因此，就需要有第三方来对人和平台进行管控。

这个机制好像我在那篇文章中提到过，一时也想不起来了，再简单说一下啊，就是在我以前的一家公司里，有一个叫“质量改进小组”的团队，这个团队干什么呢，就是每天审核整个产品小组的每项工作成果，比方说，产品经理写了一个PRD，那么，他们会去审核你写的这个PRD是否符合公司的撰写要求，其中的内容是否清晰明白，是否能够让程序员看懂，如果有问题，就会打回去让你重写。

这种机制有啥好处呢，做个类比，就有点像军队里的宪兵，警察里的督察，只要发现你有违规的行为，就会立刻进行纠正，避免出现“法恩法则”提到的情况。

尤其是对于刚刚开始构建需求管理系统，甚至产品管理体系的企业来说，这种管控机制尤其重要，因为大家都需要学习和适应新的体系，这个不断学习和训练的过程，一定是需要有第三方来管控的，学车还得有个教练了，是吧。

小知识：

法恩法则：是指每起严重的事故的背后，必然有29次轻微事故和300次未遂先兆及1000处事故隐患。

好，我就大概说这么多，看起来是在讲如何处理一个需求变动的问题，但事实上，我更想表达的是一个小小的需求背后，其实牵扯到的是一个需求管理系统的质量和操作这个系统的人的素养，因此，我个人的想法是，与其纠缠于枝枝蔓蔓，不如从根上好好思考一下如何来解决。

12：缺陷报告模板

缺陷编号，是缺陷的唯一标识符，在禅道之类的缺陷管理工具中一般都会自动生成，这个大家不用纠结。

缺陷状态，是缺陷跟踪过程的进展情况，缺陷工具都会有相应的流程和状态标识，一般不需要我们去选择。

缺陷标题，是缺陷的概述，最好能一针见血的揭示出该缺陷的本质，这个需要后续多练习。

重现步骤，就是一步一步描述再现缺陷的操作步骤，基本要求就是开发人员按照步骤能重现Bug就可以。

严重程度，就是缺陷对软件系统的影响程度，有些影响较大，有些影响较小。

优先级，就是修复缺陷的重要性或紧迫性，即哪些缺陷需要紧急修复，哪些缺陷可以后续再修复。

缺陷类型，就是根据缺陷产生的来源和根源划分出的缺陷种类。

测试环境，主要是测试环境的配置，包括操作系统和浏览器。

13：Linux基本命令

•   cd /                切换到系统根目录
• mkdir 目录名称        创建目录
• ls    目录名称        查询该目录下所有的目录和文件
• ls [-a] 目录名称        查询该目录下所有的目录和文件,包含隐藏文件
• ls [-l]  目录名称        查询该目录下所有的目录和文件的详细信息
• find / -name 目录名称   查找/root下的目录(文件)
• mv 目录名称 新目录名称  修改目录名称
• mv 目录名称 目录的新位置   剪切
• cp -r 目录名称 目录的目标位置 拷贝
• rm -rf 目录          强制删除目录
• 文件操作
• touch 文件名称      创建空文件
• cat/more/less/tail 文件  查看文件内容
• tail -f 文件          动态查看/实时查看文件(日志)
• grep 要搜索的字符串 要搜索的文件         关键字搜索
• vi/vim 文件         修改文件内容
• rm -rf 文件         强制删除文件
• 文件的打包
• tar -zcvf 文件名.tar 要打包的文件
• 文件的解压
• tar -xvf 文件名.tar
• 扩充:将文件解压到固定位置
• tar -xvf 文件名.tar -C 指定解压的位置
• 查询当前所在位置
• pwd   
• 查看进程
• ps -ef | grep 进程名称(tomcat/mysql)
• 杀死进程
• kill -9 进程pid
• 查看端口号
• netstat -an | grep 端口号(3306)
• 查看服务器ip
• ifconfig
• 查看网络是否能正常使用
• ping 外网地址       查看是否能访问外网
• ping 内网ip        查看是否能访问内网
• 权限命令
• chmod 777 文件    赋权
• 查看cpu
• top
• 查看磁盘信息
• df -h
• 查看内存信息
• free
• 关机命令
• shutdown -h now 立刻关机，其中now相当于时间为0的状态
• shutdown -h 10：23
• shutdown -h +10  系统再过十分钟后自动关机
• 重新启动
• reboot  重新启动操作系统
作业:完成博客中的Linux命令
标题:Linux基本命令
内容:上面的全部操作顺带截图，文字描述