需求分析书写总结

需求怎么进行分析？
1，显性需求：需求文档上写了什么就是什么，不需要过多的发掘的
2，隐性需求：在需求文档上去进行发掘，一般是不写在文档上，要考虑需求的一些异常的场景，通过挖掘隐性需求去找到更多的异常场景，或者说异常测试点
3，特殊需求：一般指的是用户的需求，个性化需求
例子：现在P2P项目，普通用户的投资年化收益率12%，为了吸引新用户，同一个产品，给到新用户的年化收益率是18%，时间为1个月
10000元的年化收益率为12%时，普通用户一天收益多少钱：12%*10000/365=3.28元
新用户的权益为1个月18%的年化收益率，新用户一天收益多少钱：18%*10000/365=4.93元
4，关联需求：考虑到关联系统的需求，本系统发生修改时会不会影响到其他关联的系统



项目流程中，产品经理输出了基线化的需求文档后，能不能改？
能改，但是并不是我们测试或者开发改，我们是可以提意见，和需求人员进行沟通修改，让产品经理和客户进行沟通，确认修改，并不是说我们项目内想改就改的。



页面加载时间的3-5-8原则：
3：用户在3秒内得到响应就会感觉系统响应很快
3-5：在3-5秒内得到响应，感觉响应速度还可以
5-8：在5-8秒内得到响应，感觉系统的响应速度很慢，但是还能接受
8：超过8秒就会感觉系统很差，会离开页面或重新刷新页面



开发和测试比例：
4:1、5:1、6:1


测试总工作量计算：
以一个月一个版本为例
本次的迭代周期是2021-8-16~2021-9-17，可用工作日是25天，5个测试的总工作量：25*5=125人天



整个项目的周期时间分配
需求分析--开发设计--开发编码（测试设计）--测试执行--上线准备
       1      :       2      ：        3                        :      3        :     1

60天
6天做需求分析：12天做开发设计：18天做开发编码、测试编写测试用例：18天执行测试、修复bug：6天做上线准备

上线准备一般的工作内容有：
1，执行系统的全量回归测试--看看本次更新的功能有没有影响到原有功能的正常使用
2，维护自动化脚本
3，输出测试报告
4，准备投产验证


34个工作日
测试进度的时间分配
设计阶段：执行阶段：收尾阶段
    3        :       5       ：      2
    4        :       4       ：      2
10~13   ：13~17       :   5~7

执行阶段的时间分配
SIT1:SIT2:SIT3
  5   :   3  :  2
  6   :   3  :  1
11:6:2


测试任务的模块划分：
难的、复杂的 --中级，老员工（对业务是熟悉的人去做）
简单、业务流程不重要的--初级，新入职员工

一般怎么带新人？
1，会把系统回归测试用例（我们系统原有的业务流程）给到新员工去进行执行，让新员工熟悉我们系统的业务
2，会说明我们系统的架构以及业务情况，一般是给文档给新人看，然后一周后进行考核，让新人复述我们系统的业务流程
3，安排一些小任务给到新人去进行测试
。。。。。



如何避免风险？
一般会把当天出现的风险及时以邮件或者微信或者口头的形式通知领导，让领导知道当前项目可能存在的风险，让领导及时沟通调整

我们测试组几个人在固定的时间会召开一个小会议（站会），各位同事会把自己昨天所做任务、今天准备执行的任务、执行过程可能存在的风险都拿出来讨论，一般会议时长控制在半个小时左右



设计编写测试用例的一些注意点：
1，一些实际生活中的动作不需要真的去执行，模拟真实情况即可（例如去兄弟门店调拨商品的动作，可以直接通过切换TSM系统账号进行模拟）
2，注意后台系统的验证，作为一个测试，后台系统也是需要进行验证的，很多功能都是前后台互相影响（前后台系统的交互操作）
3，要描述清楚你是在哪个软件上操作（本次人人乐需求上就涉及到TSM系统、人人乐园、人人乐微商城）
4，前置条件是测试之前需要准备的工作，不要把必要的步骤写前置条件中
5，如果前置条件已经描述清楚，就没必要再在测试步骤中重复执行



*代码的参数化：做一些可以配置的功能，这些功能是可以直接在系统上进行修改的，可以方便业务人员去使用的。
参数化的作用：减少代码的冗余