细化迭代二测试报告

一,用例模型 1,系统用例图 2,开单用例分析 用例名:销售开单 主要参与者:收银员 主成功场景: (1),收银员开始新的一次销售 (2),收银员依次录入商品条目,选择数量(默认1) (3),系统总金额随商品的录入不断刷新 (4),收银员录入完毕,确认结账 (5),系统创建交易信息表,并自动记录交易时间,等待客户支付 扩展: 2a.收银员录入错误商品或者客户不需要某个商品 1.主管或者高权限人员登陆系统 2.主管或者高权限人员删除该条商品录入信息 3.主管或者高权限人员退出系统 4.系统显示回销

1,登陆设计 (1),该超市员工号为6位数字,如020001~工号输入也只能填写数字~ (2),密码使用<input type="password"/> (3),具有表单验证,按登陆的时候,会检验是否为空值,是否工号不存在~ (4),默认选择收银员~重置可情况输入,返回默认值 2,输入商品 (1),通过输入商品ID,以及数量进行添加商品 (2),商品ID输入限定只允许数字输入 (3),数量的输入限于1-1000 (4),数量可以通过按↑↓键进行递增递减~便于收银员操作 (5

通过为期两周的微信抢票应用迭代二,我对一个django工程的各个方面都在后端小学期的基础上有了进一步加深的理解,同时感到一个成功工程的诞生是多么的不易. 整个工程可大致分为几块内容:功能开发,各种测试.部署上线和文档展示,每个方面都值得一说. 功能开发方面,完全是参照文档中给出的前后端接口要求和微信网页中"帮助"页面中提到的所有功能,不过一开始对整个工程没有概念,接手框架时对这个庞然大物不知所措.也曾试过想认真阅读代码,可读了一阵之后发现没有任何目的的阅读完全没有效率,尽管大多数代码行

1.认识与体会 做了Popush这个项目之后,觉得软件工程更像是一个工程,更加完整,而不是几个代码文件,几个算法那么简单,也体会到了架构和团队开发的重要性.对于完成的ShadowFiend作品我个人十分满意,对我来说这就是最大的收获了. 2.课程建议 1)Popush和微信的平衡问题,两个项目的组的数量如果差的比较多感觉老师的重心也会偏移. 2)展示鼓励的是展现优秀的项目还是口才,个人不喜欢把话说的太漂亮. 3)规则制定了不要大幅度改(指的是需求分析那部分,规则换的太醉了) 最后感谢老师的悉心指

报告目录结构 Reporter根目录 | |-------------LOGS |                                                | |                                         2017-09-21_12-34-39   每次按日期时间动态生成报告目录 |                                                | |                          

二.开发计划 2.1 团队成员 项目经理:吴泽标 分析师 架构师 程序员 测试员 陈璇斐 吴泽标 苏俊伟 吕柔纯 2.2 开发迭代计划 过程 时间 工作内容 提交资料 控制措施 初始 阶段 第2周 确定分组,讨论主题,进行需求分析 提交分组计划,与开发主题 小组开会讨论 细化迭代1 3-4周 学习研究涉及技术框架,实现基础数据增删改查 Git程序: 发布前期开发计划文档 项目经理组织会议讨论,明确设计思想和要求,给组员进行分工.

一.项目设想 1.1 系统展望 产品应用场景:书店的销售管理软件, 用户:书店的工作人员.管理人员.收银员等 系统范围:包括书店POS机系统的销售模块.书本录入模块 基本目标:能够支持采购人员和管理人员对书本基本信息维护,收银员对消费者的消费进行销售开单,收银并打印票据,支持经理对销售数据的统计等几大功能,并且系统能够成功运行. 1.2 系统特性.功能 (1)用户:普通收银员.管理员.经理 (2)图书信息管理:管理员对图书信息进行增删改查 (3)员工信息管理:对值班收银员信息的管理,确定每笔交易

1.前言 从本文开始进入细化阶段,讨论迭代技术的基础,本次讨论将着重讨论第一次迭代,以POS机为例. 2. 第一次迭代处理的需求(以NextGen POS项目处理销售用例) 实现 处理销售 用例中基本和关键的场景:输入商品项目并收取现金 实现用于支持迭代初始化需要的启动用例 不处理任何特殊和复杂的部分,仅仅针对场景的简单理想路径,并对此进行设计和实现 不与外部服务进行协作 不应用复杂的定价规则 不考虑UI支持.数据库内容的支持 3. 迭代过程,并非一次就实现所有需求 迭代生命周期方法的关键理解:

主要谈一谈团队管理方面的体会吧.首先团队如何分工是一件非常有挑战的事情,一方面需要让每个人都愿意做自己承担的部分工作,同时还要尽量使每个人都擅长自己的部分,这样的开发团队才是最高效的.但这其实是很难的一件事,尤其是在学校里,在一门课上组成的学生团队中.对于所使用的开发技术,我们是从头开始学:此外,团队成员的固定性决定了团队的不足,比如我们组就缺乏在设计方面有兴趣且有经验的成员.所以无论最后我们开发的结果如何,我觉得课堂上的团队其实很难真正体会到作为“软件工程”的软件开发过程,软件工程首先得以项目