今天完成的事：

总结了之前的任务总结

明天计划的事：

提交任务五

遇到的困难：

没有

收获：

任务一

测试用例编写流程
需求分析 提取测试点 测试用例编写 测试用例评审
需求是什么
业务需求：关注系统是否满足业务需求
用户需求：关注系统是否满足用户习惯
功能需求：关注系统是否满足功能需求
需求就是客户的需要和要求，业务需求、用户要求和功能需求。需求不明时整理已有的需求不懂的需求可和负责人确认或参考同类型产品的实现情况。一个项目都是围绕进行的，所有岗位都离不开需求。
没有需求怎么办？
参考市面上已经上线的同类产品
需求模糊怎么办？
1.收集整理已有需求
2.和产品经理逐条确认
3.参考同类型产品的实现情况
什么是测试点？
测试点即通过需求分析后对得出的需要进行测试的具体内容
测试用例编写注意的事项
1.根据项目的实际情况设计测试用例表格
2.用例格式不是固定的，不要生搬硬套
3.根据具体的情况编写
测试用例评审：
1.什么是用例评审？
<1>简单的说，评审就是对测试用例进行检查
<2>评审包括：同行评审、小组评审、部门评审和第三方评审等
<3>不同的评审有不同的角色参与其中
2.评审的意义：
<1>通过评审发现用例的不足
<2>方便测试人员改进用例
<3>达到在测试时提高测试质量的目的

3.评审的流程是什么？
评审后改进测试用例，再进行评审再改进测试用例，这样一直循环直到评审都通过，这时候才结束评审，也标志着测试用例编写的完成
需求分析的重要性
需求分析是对软件非常重要的一个周期，主要是用户对产品经理的需求，分析这个软件是否全部完成了必须要有的需求
测试点对测试用例的好处：
1.能根据测试点快速的编辑出来测试用例

任务二

一、严重程序

P1：致命（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失， 与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数 据库发生死锁、重要的一级菜单功能不能使用、内存泄漏、严重计算错误、无法登录、无法正常退出、功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出， 关联程序间调用冲突等。

P2：严重（不影响其他功能测试的情况下可以继续该版本测试）

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用 但是不影响其他功能的测试。安全问题、稳定性等。如：软件中数据保存后数据库中显 示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等

P3：一般（实际测试中存在最多，解决率关系版本的优化程度）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多、容错性不好、大数据无响应或没有滚动条等

P4：建议（测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢 失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等

二、优先级

①　?：不确定紧急程度（新手或辅助测试时使用）

②　1：立即处理

③　2：紧急处理

④　3：正常处理

⑤　4：有时间再处理