开发团队有哪些
产品经理：确定需求（联系客户与客户沟通）
确定需求后
项目：
ui前端 设计图
页面（web 前端后台页面） 移动端的页面（Android+iOS）原型图进行
后台开发：对数据库和数据表的设计
测试：编写测试计划和测试用例
编码期：
UI根据修改原型图 j s界面 css界面 等等
后台根据原型图进行 编码
测试人员：用例评审/冒烟测试/执行用例/缺陷（bug）
提交bug 给开发人员
开发人员进行修改bug 提交bug状态
测试进行回归测试
直到bug关闭
上线：
测试总结
一个bug由测试人员发现并提交，我们将状态标注为新建；开发人员接收了该bug，将bug的状态修改为已分配，表示已经认可；开发人员解决了该bug后，就将bug的状态修改为解决，并发送给测试人员回归测试；测试人员对bug进行回归测试，如果确实已经解决，就将bug的状态修改为关闭，否则的话则发给开发人员重新修改
。还要说明的是，bug是可以“死而复生”的，以前版本已经关闭的bug，如果新版本中重新出现，我们需要将其状态修改为重新打开。
bug的状态：
新建（测试）
确认（开发）
解决（开发）
重新认证（测试）
关闭（测试）
重新打开（测试）
Bug的范围包含了对 UI 、web开发 、后移动端开发
Bug是通过执行是执行测试用例得到 实际结果和预期结果不匹配的
提交bug的方式
1.使用工具 禅道 jiar
2.缺陷报告 excel表格 或 word文档
- 微信/qq/钉钉 直接找负责人
开发流程
1.需求分析（软件有哪些模块和功能点）
2.概要设计
3.详细设计
4.编码
5.测试
6.上线
7.更新/迭代/维护
开发模型
V模型是指：一半开发流程 一半测试流程
优点：
包含了底层测试（单元测试）和高层测试（系统测试）；清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
缺点：
自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时进行修改
/--实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低--/
W模型是指： 一个开发流程和一个测试流程
优点：
开发伴随着整个开发周期，需求和设计同样要测试；
更早的介入测试，可以发现初期的缺陷，修复成本低；
分阶段工作，方便项目整体管理。
缺点：
开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高
bug等级
系统崩溃
严重
一般
次要
建议
优先级分高、中、低
Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等
Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)
Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
