关于项目_yayazhang-CSDN博客

本文链接：https://blog.csdn.net/yayazhang8180/article/details/80799302

一、项目职责和分工

1、产品经理:
产品原型图，产品prd

2、项目经理：
   项目立项，由项目经理负责。
   负责项目生命周期:
       1、产品prd什么时候
       2、开发计划是什么，
           每天开发进度，完成了什么
           测试做什么
           .....

       项目上线..上线之后本次项目的生命周期就结束。

   敏捷测试或者开发：
           1、就是一个项目一般情况下不是一次做完的，比如 QQ，微信
                               走迭代的：迭代的版本号，开发和测试....

3、开发人员:
   1、前端开发 .... 前端页面 html css js <h1>小高最帅</h1>
   2、后端开发 .... java c# .... 提供一个接口
   3、ios和安卓,app开发,本质也是调后台的接口
   4、配置管理: 环境搭建，测试环境工具(Jenkins)，禅道，jira，代码版本管理，jar包管理，上线脚本编写，配置文件管理
   5、运维人员: 生产测试环境的搭建，生产配置文件....

4、接口测试的本质
   1、协议是http协议，属于一个应用层
       http 协议:
           请求(request)和响应(response)
               request header   response header
                       body              body


           请求方法: post 和 get 它们区别：
                                           1、get的请求参数是在header (url里面) 和 post请求参数是在body
                                           2、header 里面是字符串个数限制，body里面的没有限制的
                                           3、get和post，他两其实没有本质安全的，只是一个放在手上，一个放在口袋
                                           里面，通过抓包全部抓到

           接口测试工具: postman soupui jmeter

   前面主要是针对某个项目的一个流程，在这个流程当中每个角色负责的内容是不一样的，他们各司其职，
比如说我遇到需求不懂，找产品，比如测试环境down掉了，找配管......

测试人员担任的工作
           1、熟悉业务
               熟悉产品本身的业务(软件基础)
               熟悉数据表与表之间的关系，数据流走向(数据库知识)
               熟悉测试环境的架构(linux 主要看日志)
               熟悉上线流程 ==> 后面重点讲
               熟悉人员，目的：提交bug或者出现问题，我找谁解决。

           linux 日志级别：日志级别越大，输出内容越少
                   1、debug:调试级别
                   2、info : 信息级别
                   3、warning: 警告级别
                   4、error: 报错,程序级别的报错
                   5、critical：崩溃级别(不重要)
           bug定义:
               1、不符合需求，超出需求
               2、程序本身的问题 (error)
               3、不符合用户的使用习惯

           有个地方的数据统计: 每周统计的，另个没说，需求里面是按每周统计的。
           这个两个地方:两个sql语句

       bug单据：(禅道、jira,QC,....)
           1、概述(对bug的简单描述)
           2、你的bug在哪个模块发现的
           3、测试人员
           4、指向某个开发人员
           5、重现概率(可写可不写)
           6、严重级别、优先级(优先级越高的bug，严重程度就越高....) *****
           7、发现的环境
           8、详细描述：   *****
                   1、简述
                   2、前置条件
                   3、预期结果：产品需求一致，本来不报错的
                   4、实际结果：.....
           9、附件
               把你发现bug的证据上传

       测试计划：
           1、在什么时间段用什么方式做什么事情

               1、对产品的介绍
               2、测试策略 => 以什么方式去测试 => 界面测试
                                                    安全测试、性能测试、功能....
               3、时间安排 => 小明   20180624-0625 熟悉什么业务
                                      .....          写用例
                                                      执行用例
                                                      .....
               4、遇到的风险
                   测试过程中遇到的风险
                       遇到开发出车祸
                       环境搭建，机器申请不下来
                       ......
               5、测试预期：
                   本次需要达到什么样的一个预期结果。覆盖率：98% 通过率 100%

       问项目的目的：通过你对之前项目里面用到的流程以及测试技术，跟我们公司项目的流程和技术做匹配

       测试报告:

           1、对结果的总结(通过数据统计)
               1、项目介绍
                   本次参与的人员(开发和测试人员)
                   报告修订 1.1   1.2   1.3

               2、测试用例的覆盖率和通过率
                   本次发现了多少bug => 严重级别：1:3个 2级：500 .....
                                                   看个每个模块的bug....
                   当前遗留的bug数
                   每个测试人员负责的不同测试用例执行数 N/A 无效的
                   ......

               3、风险
                   项目deplay....开发出车祸了...
                   环境没有搭建好的
                   开发人员技术不够....

               4、总结
                   本次上线是否达到上线标准严重级别以上的bug一个都不能用，测试用例覆盖率....
                   已达标，可上线...
                   不达标准，待。。。。完成之后上线...

       上线发布单：
           1、上一个版本的版本号v1.1   本次上线的版本号：v1.2
           2、本次上线的服务名 => saas20.war   本次是否有配置文件改动是否有sql
           3、本次遗留的bug
           4、本次参与的测试人员、开发人员
           5、是否需要性能测试或者安全测试
           6、由配管提供服务包、改动的配置文件   需要更新的sql(配管)
           7、上线发布(由运维)