一 今天完成的事情

1. 了解产品需求 

   需求是什么？ 需求是人们对现实生活的不满而产生的问题， 不满根源参考马斯洛、七宗罪 所描述的 需求 、人性弱点、 

   衣食住行 安全社交 尊重 自我实现 需求  淫 贪婪 贪食 懒惰 易怒 嫉妒 弱点

  只要人生活在现代社会上就受社会文化和社会意识形态影响下， 需求和弱点就自然产生了 . 

   例如 出人头地 有钱就有一切 以瘦为美 现代生活压力过大产生的发泄服务、外卖服务等

2.为什么要满足需求 

  因为满足特定目标人群需求或服务后 能抢占 目标人群市场 并让目标人群

  消费后产生依赖性 产生长久效益

  甚至创造需求 例子有 奶头乐理论 消费主义理论   

3.怎么满足需求

  IT行业 满足需求方式 是通过信息技术方式 实现某种功能服务

  使现实不同需求转到网络上实现

  例如 沟通用信 现在qq 邮箱、 购物上街 购物网站

3. 产品需求是什么

  产品 现在已经有的满足需求和产品或服务

  需求 对产品的功能或服务的 设想和要求

 并转化为产品语言来描述这个需求实现步骤

4.

我们任务

1.提炼分析客户真实需求，并符合产品定位的解决方案。

2.需求分析：从客户提出的需求出发，挖掘客户内心真正的目标，

并转为为产品需求的过程。

5.怎么获得产品需求

  听取客户需求 排除伪需求 提炼真实需求  

  分析客户和目标人群的真实需求

.  形成具体的产品需求

客户需求：要求针目标某种功能的实现 提出设想

目标人群：不知道自己要什么 但有一定的期望

伪需求：客户提出的不具备实现价值的需求

真实需求：明确产品核心作用需求 有对其详细的定义

产品需求：对功能实现的详细描述 有明确逻辑顺序说明

6.产品需求图

 7.如何排除伪需求

1分析目标人群 客户 真正的需求

2. 分析方法 七宗罪 需求层次 理论

8.需求分析

场景分析：考虑具体什么环境（时间、地点、情境）

什么类型用户的什么动机，想达到什么目标，以及人与人的关系

找出场景中对用户动机和完成目标真正起作用的因素，而后转换为产品语言描述产品需求

9.需求价值分析

广度：受众面大小

频率：需求被需要次数

强度：用户需要程度 决定优先及

时机：是否符合产品开发周期

10.筛选需求

是否为目标用户 来划分参考意见价值

是否影响产品核心功能

是否有实现价值

2. 产品测试

为了检查功能已经按要求实现了， 存在与开发到交付周期间

需求评审会议时同时会把测试需求列明

2.1 测试流程 

需求评审-需求定稿，测试人员理解需求-测试组长发布测试计划-

测试人员进行测试方案的编写及评审-测试人员根据测试方案定稿进行测试用例的设计及评审

-测试人员根据测试用例进执行测试用例-发现问题bug提交-确认bug修复，

关闭bug-编写测试报告及总结-编写安装文档或者使用手册-结束。

2.1 测试文档

非功能性测试，主要指APP运行时在各种环境下是否能正常运行，

而功能性测试是指每个具体功能是否按要求运行。

编写测试用例，前置条件。

这些前置条件满足了才能达到你得预期。

比如账号密码登录，前置条件 是 账号和密码同时正确才能正常登录成功。正确用例

就得编写条件不符的时候，是否也会成功。如果成功了，那就属于BUG，需要技术进行修复。错误用例

考虑方面

1. 页面布局是否合理，

2. 页面文字描述是否准确，

3. 如果有加载规则，是否符合加载规则。

4. 如果有排列规则，是否符合排列规则。

5. 操作是否符合要求，如单击某个点，是否准确跳转或显示内容。。

6. 输入框输入的内容是否有符合格式要求。

7. 输入的内容是否符合合法性要求

2.3 文档编写标准

第一种 

1. 序号： 不用说，就是按顺序下去的。

2. 模块：该功能点具体属于哪个模块的，填写这个主要是方便查找，如：注册/登录模块

3. 编号：对每个用例进行编号，方便后期跟进。毕竟用文字说，容易口误。不过此处建议编号设计的有点规则，方便快速定位查找。

4. 如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。

5. 功能点：具体指某个功能，如：账号登录、首页、发布等。

6. 子功能点：具体指功能点，如：账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。

7. 用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。

8. 前置条件：指要达到预期测试结果，需要满足那些条件才能达到。如：账号密码不一致时，就需要登录失败，那么此时就得保
证账号正确或密码正确以及账号正确时是存在的。

9. 操作步骤：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。

10. 预期结果：说明按照前面写的应该呈现出怎样的结果。

11. 测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，

12. 结果描述：如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。

13. 测试人员：填写测试人的名字，方便后期跟踪BUG。

14. 测试日期：填写测试的时间，方便后期查询。

15. BUGID：跟测试编号一样，自己设定ID规则，方便快速查询。

16. BUG负责人：此处应该有技术那边填写，具体落实到某个人身上，才能更好的解决到问题

第二种

用例标识：能够准确的标识每一条用例，每一个用例编号在所有测试用例中必须唯一。

用例名称：能够清晰表达测试用例的测试目的和关键测试要素。

优先级：区分测试用例的重要程度，确定用例执行的级别。

前置条件：需要描述测试所需要处于的外部环境和测试前测试对象及辅助对象所需要处于的状态和配置。需要保证在完成预置条件中所描述的状态和配置以及外部环境后，测试执行的正确性、一致性。

操作步骤：为了达到测试用例的测试目的，所需要执行的操作；每个操作步骤对应一个预期结果。

预期结果：针对测试用例的测试目的，测试步骤中操作后对应的预期输出结果。

用例编写者：设计用例的人员。

测试执行者：按照该用例执行测试的人员。

测试日期：执行测试的时间。

3.尝试编写测试 用例 格式有些问题

二 明天计划的事情 

接着写测试用例  看看任务二  

三 .遇到的问题

对第四步 的 测试方向 想歪了  这个是对后台模块的测试 

四 收获

1.基本了解了产品需求

2.知道了测试用例的意义和流程

3.学会看需求文档 

4.知道功能测试概念