敏捷开发

实验十 团队作业6 ：团队项目用户验收&Beta 冲刺 实验时间 2020-6-24 Deadline： 2020-6-30 10:00，以团队随笔博文提交至班级博客的时间为准。 评分标准: 按时交 – 根据实验十评分细则打分，满分138 +40分，检查项目包括： - 任务1部分（50分+40分） - 任务2部分（40分） - 任务3部分（48分） 本实验为团队任务，团队成员成绩以团队博文成绩为准 晚交 - 0分 抄袭 - 倒扣本次作业分数 评分截至日：2020-7-3 22:00 一、实验目的与要求 （1）掌握软件黑盒测试技术； （2）掌握软件项目确认测试内容，学会编制软件项目总结PPT。 二、实验环境要求 （1）实验六—实验九所编制团队项目文档； （2）实验九所开发团队项目软件包。 三、实验内容与步骤 任务1：团队作业Beta冲刺：团队项目经过Alpha阶段冲刺后，已基本完成项目编码工作。进入Beta阶段冲刺后，需要开发者对软件进行用户使用体验或典型用户应用场景测试并完善功能，此时常用黑盒测试技术完成测试工作。请根据团队项目中软件的需求分析文档、需求规格说明书和软件设计说明书，编写软件用户功能测试方案，并执行测试过程，在日期区间[6.25-6.30]内，任选连续4天进行Beta冲刺，冲刺当天晚23点前发布一篇团队Beta冲刺博客，冲刺博文内容要求如下： 各个成员今日完成的任务

第4天 日期：2020/6/15 4.1 今日完成任务情况 成员 完成的任务 遇到的问题 王颖奇 熟悉项目结构和框架，页面设计 发现图标素材不够，需要继续收集 汪慧和 熟悉项目结构和框架，设计记账模块 暂时不太美观 杨野 熟悉项目结构和框架，编写记账模块 环境不熟悉，知识不够，还需学习 李婷华 熟悉项目结构和框架，编写记账模块，汇总第四次例会报告 环境不熟悉，知识不够，还需学习 4.2 成员贡献时间 成员 贡献时间 王颖奇 2 汪慧和 3 杨野 3 李婷华 3 4.3 明天任务安排 团队成员 熟悉代码和环境 会议交流，阐述问题 学习相关的移动应用知识 一天之后的总结 视图设计成员 视图展示模块设计 视图编码成员 视图展示模块编码 其他成员 搜集所需素材 撰写博客 一天任务成果整理 4.4 站立会议照片 燃尽图及其任务安排 4.5 成果展示 来源： oschina 链接： https://my.oschina.net/u/4324623/blog/4312951

背景 名词解释 如果你的团队目前正是构建微服务架构风格的软件系统，问自己两个问题？ 软件架构演进 软件架构大致经历了从单机架构，集中式架构，分布式微服架构，程序的层次图如下所示。 单机架构 特点如下： 1， 面向过程的设计方法； 2， 结构为CS； 3，程序的层次分两层，即UI层和数据库层； 4， 设计的核心在数据库和字段。 集中式架构 特点如下： 1， 面向对象的设计方法； 2，程序层次为经典的3层架构，即业务接入层， 业务逻辑层，数据库层； 3，部分企业也采用SOA架构风格； 4，集中式的架构缺点：扩展性，伸缩性差，系统容易变得臃肿； 分布式微服务架构 特点： 1， 基于微服务的理念：分而治之，模块高内聚（独立团队，独立部署，独立存储，技术异构），模块之间通过RPC或者HTTP通信，松耦合； 2，模块之间松耦合，解决了扩展性和伸缩性的问题； 架构对比 单体架构和集中式架构，系统分析， 系统设计，系统开发这3个阶段是割裂的，即分属3个不同的人或者小组或者岗位的人负责，这样的后果是： 1， 系统分析，设计，开发三个阶段的信息不一致，导致上线之后功能跟需求偏差非常大； 2， 系统的开发无法快速响应需求和业务的变化，错失发展的良机。 微服务的困局 微服务解决的问题 微服务解决了单体架构和集中式架构的问题：扩展性，弹性伸缩，敏捷开发快速响应业务变化； 但是微服务并非毫无缺陷。

第一天 日期：2020/6/26 1.1 今日完成任务情况 姓名 今日完成任务 马 强 学习黑盒测试，制定用户登录功能测试计划 李志龙 学习黑盒测试，编写测试报告 李雪芬 学习黑盒测试，编写测试报告 邵阳阳 学习黑盒测试，制定科研项目管理功能测试计划 1.2今日发现了哪些Bug，描述发现Bug的测试用例和Bug的修复情况； 今天团队主要是学习黑盒测试，编写测试报告以及制定部分的功能测试计划。 1.3 成员贡献时间 姓 名 贡献时间(h) 马 强 5.0 李志龙 5.0 李雪芬 5.0 邵阳阳 5.0 1.4 明天任务安排 姓 名 明天任务安排 马 强 用户登录功能测试，完善登录模块代码 李志龙 科研成果功能测试 李雪芬 学术活动功能测试 邵阳阳 科研项目功能测试，完善科研项目模块代码 文档和视频上传项目Gitub仓库 1.5 站立会议照片 1.6项目燃尽图 软件远程访问地址： 软件远程访问地址 管理员账户：admin 密码：111 科研人员账户：xxxry 密码：111 科研管理人员账户：kygl 密码：111 1.6项目总体进度 在团队Beta阶段冲刺的第一天，首先讨论学习了黑盒测试技术，编写测试报告，对任务进行了较为细致的划分，制定了部分的测试计划。 来源： oschina 链接： https://my.oschina.net/u/4409634/blog/4327671

4 需求管理 　　4.1 需求的三个层面 　　4.2 用户需求收集 　　4.3 产品需求分析 　　　　4.3.1 产品可行性分析 　　　　4.3.2 产品版本规划 　　　　4.3.3 MVP规划 　　　　4.3.4 产品需求细化 　　　　4.3.5 产品需求评审 　　　　4.3.6 录入用户故事 4 需求管理 　　 需求管理，属于需求工程（Requirements Engineering,RE）范畴，一般情况，不做区分。 　　 需求（Requirements）是软件产品的起点。询问软件人员，什么对软件产品最重要，大部分人的答案是需求，可见需求在软件开发中占据的重要位置。 　　 然而，据我所知，大多数软件人员对需求的理解并不准确，结果导致软件开发常常遭遇需求困境。软件开发没有阶段性里程碑，需求加入很随意，结束更是遥遥无期，更有甚者，某些需求与本系统关系不大，也被硬塞进来，系统结构越来越臃肿，系统弹性越来越差，令人抓狂！ 4.1 需求的三个层面 　　 我认为，需求分三个层面：用户需求、产品需求和软件需求。 　　 用户需求，是产品需求的驱动和源泉，来源有：竞品分析，潜在客户的调研，已有用户的提供的资料、调研、建议和投诉，往往由市场人员、销售人员、客服人员收集。有时候，用户需求是不清晰的，因为用户自己也无法描述清楚其到底需要什么！ 　　 产品需求，是从用户需求中裁剪出来一个需求集合

当今的软件开发行业，单靠一两个牛人来完成一个个小型软件的做法早已成为历史，规模各异的团队协同开发已经成为标配。为保持代码在多人开发的情况下的一致性、及早发现代码的问题，持续集成Continuous Integration（缩写CI）得到了广泛的认可与应用。 部分开发人员只是片面的理解与执行CI，但对其原理与价值知之甚少。本文旨在分享XP极限编程与CI持续集成的定位与核心价值，让每位开发人员都能够理解其价值，更好的运用。 关于XP极限编程 1.认识作者 极限编程的作者是软件开发大牛Kent Beck，作为”十大Java人物”之一，除了XP之外，同时也对设计模式、敏捷、重构、测试驱动开发、JUnit等诸多主题有着巨大的贡献。他的一系列著作也都是各别领域里面的经典之作，值得我们深入钻研、并尝试实践来研读与运用。 2.XP极限编程 极限编程（ExtremeProgramming，简称XP）是Agile敏捷开发的典型代表，同时也是十几种敏捷开发落地方法论中名气与应用最广的其中一种（类似的还有Scrum、Kanban等）。XP本质上是轻量级的、迭代式的软件开发过程。其核心思想是强调人与人之间的协作因素和以敏捷性应对变化。 XP极限编程官方网站： http://www.extremeprogramming.org/。 包含以下内容： XP有4个核心价值： 沟通(Communication) 简单

​ 软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。 在现代社会中，软件应用于多个方面。典型的软件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，也提高了工作效率和生活效率 。 在大公司里，软件工程的应用已经非常普遍，比如敏捷开发，领域模型驱动这类的实践方法已经深入人心，今天我们就来推荐一下关于软件工程的一些经典书籍。 软件工程系列书单 ​ 人月神话 在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了具有洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。 《人月神话（40周年中文纪念版）》内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。 《人月神话（40周年中文纪念版）》英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。 在《人月神话（40周年中文纪念版）》第首次出版40年后的今天

提问回顾与个人总结 项目 内容 作业属于哪个课程 2020春季计算机学院软件工程 作业的要求 提问回顾与个人总结 课程的目标 经过了一学期的学习，总结自己的收获，解决自己在曾经的疑问。 一.第一次作业链接 第一次博客作业 二.问题解答 问题1 原问题如下： 在原书第85页，有如下描述： 在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有互相激励的作用，工程师看到别人的思路和技能，得到实时的讲解，收到激励，从而牡蛎提高自己的水平，提出更多创意。 我的疑问在于，考虑工作和学习中的结对编程，我们需要考虑到合理的分配两个人的任务，如果只是将工程分解为数个模块分给两个人做，那结对编程和团队编程有什么区别呢？ 其次，编程并不是做数学题，我们还要考虑到代码风格等等问题，我觉得两人合作解决问题的能力更强这句简单的描述缺乏说服力，强行结对可能并不能有文中事半功倍的效果，在后文我们也能发现，作者所指的结对编程需要大量的磨合，这种高投入的方法真的适合高强度的现代开发吗？ 最后，看别人的思路与技能来启发自己，为什么我们一定要在工作中做而不是在其他时间阅读他人代码和文档来起到相同的作用。 在本学期课程中我们也尝试了一次结对编程，与我结对的同学也是我比较了解的朋友。在我们结对编程中，我们遇到了一些问题： 代码风格不统一。 各人课程时间，往往不能一起编程

Beta冲刺(5/7) 这个作业属于哪个课程 班级 这个作业要求在哪里 作业要求 这个作业的目标 记录冲刺当日的SCRUM会议和PM报告 作业正文 刚下飞机——Beta冲刺(5/7) 其他参考文献 ... SCRUM会议 会议记录表 学号 组员 昨天花了多少时间 还剩余多少时间 昨日完成的任务 遇到什么困难 今天的进度 明天的计划 221701317 卓晓鑫 5h 2d 实现举报处理中相关接口、修复bug 无 添加部分成就的达成判断、重构用户部分、修复bug 完成认证学校后导入学生/教师信息的接口 221701328 张春翔 6.5 2d 前端完成编辑问题、回答功能，完成删除问题、回答、评论、回复的功能 缺乏美术细胞，界面颜色调不好 优化界面，完成文字敏感词提醒，完成问题界面的回答排序 前端完成查看用户资料和邀请回答功能 221701319 郭秋中 2h 2d 消息的生成，以及将未读消息已读，获取各种消息 空指针异常 添加是否存在未读消息标志位，修改Bug 对beta冲刺中的功能进行整体测试，发现Bug 221701333 池政涛 5h 2d 认证接口编写，举报信息处理接口编写，bug修复 数据获取空指针异常导致前端无法调试 修复部分管理员功能bug 协助完成接口，对项目进行测试 221701337 朱凯文 8h 2d 完成批量删除。评论，回答，举报，回复处理界面 批量删除时

持续集成和持续交付是由测试驱动的。以下是如何做到的。 “如果一切似乎都在控制之中，那只是你走的不够快而已。” —Mario Andretti 测试自动化是指在软件开发过程中尽可能早、尽可能快地持续关注检测缺陷、错误和 bug。这是通过使用那些追求质量为最高价值的工具完成的，它们旨在 确保 质量，而不仅仅是追求质量。 持续集成/持续交付（CI/CD）解决方案（也称为 DevOps 管道）最引人注目的功能之一是可以更频繁地进行测试，而又不会给开发人员或操作人员增加更多的手动工作。让我们谈谈为什么这很重要。 为什么要在 CI/CD 中实现自动化测试？ 敏捷团队要更快的迭代，以更高的速度交付软件和客户满意度，而这些压力可能会危及质量。全球竞争制造了对缺陷的 低容忍度 ，同时也增加了敏捷团队的压力，要求软件交付的 迭代更快 。减轻这种压力的行业解决方案是什么？是 DevOps 。 DevOps 是一个大概念，有很多定义，但是对 DevOps 成功至关重要的一项技术是 CI/CD。通过软件开发流程设计一个连续的改进循环，可以为测试带来新的机会。 这对测试人员意味着什么？ 对于测试人员，这通常意味着他们必须： 更早且更频繁地进行测试（使用自动化） 持续测试“真实世界”的工作流（自动和手动） 更具体地说，任何形式的测试，无论是由编写代码的开发人员运行还是由质量保证工程师团队设计，其作用都是利用