返回顶部

实验十 团队作业7:团队项目用户功能验收测试

项目 内容
课程班级博客链接 班级
这个作业要求链接 作业要求
团队名称 软件工程四人小团队
团队的课程学习目标 (1)掌握软件黑盒测试技术;(2)掌握软件项目功能验收测试内容,学会编制软件项目总结PPT.
这个作业在哪些方面帮助团队实现学习目标 (1)在学习软件黑盒测试技术的时候;(2)在学习软件白盒测试技术的时候;(3)在对软件进行测试的时候;(4)在撰写完档回顾所学内容的时候。
团队博客链接 连接
团队项目Github仓库地址链接 仓库

任务1.自主学习《现代软件工程-构建之法》第13章相关内容掌握基础测试技术,根据团队项目中软件的需求分析文档、需求规格说明书和软件设计说明书,编写用户功能测试方案,并执行测试方案

1.软件的功能测试方案文档

  • 上传至github截图

2.回归测试

如果在功能测试过程中发现了系统的缺陷,则进行及时修正,每次修正后,再对发现的缺陷进行验证,确保其得以改正。在系统交付前做一次完整的系统回归测试。
执行回归测试的情况:

  • 远程访问修复后进行回归测试,运行结果还是错误;
  • 其他的bug进行回归测试时运行结果正确。

3.概述项目在什么样的平台、硬件配置、浏览器类型……上对软件进行测试?

  • 该项目是基于前后端分离开发,前后端使用JSON格式的数据进行通信,基于用户-角色-权限进行系统权限管理,可以自由进行用户,角色,权限的添加,修改,删除。
  • 开发环境:编译器:IDEA2022 数据库:Mysql 8.0 操作系统:Windows
  • 实用技术:前端:Spring Boot 后端:servlet+mybats
  • 浏览器:谷歌浏览器

4.视频

任务2.完善与整理团队项目资料、编制团队项目总结陈述PPT、录制视频演示软件需求规格说明书中要求功能,在团队项目Github仓库中上传以上两个文档。

任务3.完成《实验十 团队作业7:团队项目用户功能验收测试》团队博文作业:

1.完成《实验四 团队作业1:软件研发团队组建》各项任务实际花费的时间

任务名称 计划用时(min) 实际用时(min) 分工
任务1 400 520 刘温元 闫雨馨
任务2 300 240 李瑞婷 刘转弟
任务3 120 100 刘温元

2.每位成员总结本次实验心得,最后由项目组长进行总结陈述

  • 刘温元
    这个课程终于到了尾声,我作为PM有深刻的感悟。整个项目是我们项目成员一步一步完成的,我们组每个人的能力都不算很好,把任务交给个别人完成实在很困难。所以我们每个人都很好的参与了进来,在协同完成任务的过程中,我们经常相互交流,相互帮助终于完成了任务。《软件工程》这门课程只是为我们未来做项目打下的一个基础,后面还有许许多多的项目等着我们去研发,无论我是否作为PM我都从中学会了许多能力。
  • 闫雨馨
    通过本次实验,我们将学习的关于测试的相关内容运用在了实际的软件开发的过程中,执行了整个的敏捷开发流程。在本次实验中,我负责了各功能模块的测试,同时完成了测试文档。用过此次实验,我体会到了测试的重要性,仅仅进行编码阶段的程序依然存在很多的问题,要通过测试人员的不断测试发现程序的问题,及时与开发人员沟通,及时解决问题,带给用户好的体验感。小组的成员们也能根据自己每天的任务安排,按时地完成当天任务,当有问题时大家也能及时沟通、有效地解决问题。
  • 李瑞婷
    在本次作业中,我再次深深感受到了成员之间的合作是多么重要,成员之间的配合直接影响到了作业的质量,在此次合作中,我们分工明确,相互交流配合,提出问题,解决问题。此次实验主要是软件测试及软件开发,在开发测试过程中,我们遇到了很多问题,同时也解决了很多问题,我深刻的体验到了程序测试的重要性,也感受到了成员之间的配合多么重要!
  • 刘转弟
    本次试验我们小组大家都积极参与进来,分工明确,各司其职。在系统设计中,首先进行需求分析,把系统和具体的实际的业务结合起来,明确所设计的系统所具备的功能和解决的问题。然后通过可行性分析,从经济,技术,社会等方面进行阐述和说明系统设计的必要性和可行性,然后就是业务流程和数据流程图以及数据字典。对于要做的系统已经有了一个比较安全的了解后,再往下就是数据和界面的设计。通过班次的作业,我们小组觉得开发一个与App的关键是需求分析,只有通过详细的调查分析,才能确定系统所需要实现的功能和解决的问题,开发过程中的难题和和关键是业务流程分析和数据流程分析,这关系到系统整体性和完整性,是系统实现各个模块之间调用的理论基础。
  • 总结
    在这个项目中,从开始的项目确定、项目立项、开始计划项目、整体方向讨论、制定计划、项目开始制作实施到项目的完成,这其中涉及到了个人的思维能力、团队的协作能力和实践能力等。在这个过程中,我们学到了很多。明白了团队的重要性,了解到团队项目的每一个步骤都需要团队中每一个人共同的参与配合。

3. 每位成员陈述《软件工程》课程学习总结,并回顾《实验一软件工程准备》提出的3个问题尝试总结答案

  • 刘温元
    • 课程学习总结
      现在课程已结束,通过对这门课程的学习以及对比自己的期待,我了解了开发一个项目的各种方法以及各个流程是怎样的以及其中的各种知识。这次课程设计我们开发的是一个小系统,从这次开发经历来说,我了解到开发一个项目并不是一件简单的事,需要考虑的因素非常多,还有还需要自己去自学很多知识以及技术。现在开发一个小系统就这么难,可想而知开发一个软件会更难。对于自己对这门课程的期待,前两点,开发一个项目的步骤流程有了大概的了解,所需知识,这点我觉得需要自己自己去学习更多的知识与技术,提升自己的能力,开发过程中肯定会遇到各种格样的问题,当遇到问题时就需要自己去学习去钻研解决方案。所需语言,现在大部分基本都是用的java,而通过这次课程设计也让我感受到自己的java还得再认真学学。最后一个希望自己也能开发一个软件,这点就有点长路漫漫了,还需要自己多去学习一些知识与技术提升提升自己,之后再完成这一期待。
    • 在我的认知中,大部分软件都是由多人完成的,每个人负责的部分可能不同,在把不同的部分组合成一个完整软件的过程中,是否存在一个标准使得组合的过程比较容易?如果有那么这一标准对每一个模块又有什么样的标准呢?
      软件设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题,以及该问题的解决方案。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。在软件开发中,为了提高软件系统的可维护性和可复用性,增加软件的可扩展性和灵活性,程序员要尽量根据以下几条原则来开发程序,规范编码:开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、迪米特法则、合成复用原则
    • 文中提到“合作的最小单位是。两个人”,两个人开发一个软件的过程应该比多人开发的要慢,为了提高开发的效率对两个人的开发团队有什么要求呢?
      两个工程师在一起,做的最多的事就是看对方的代码了,每个人的都能看对方的程序代码来发表自己的意见。但是这也要求程序员写的代码可以给同伴看。所以要求程序代码要规范包括代码风格规范和代码设计规范。
    • 既然是多人共同开发一个软件,那必然有团队的管理者,如果作为一个团队的管理者,如何安排、管理不同部门来共同开发一个软件?
      管理从来都没有固定的模式,因人,因环境而异。现代知识分子,特别是在软件开发领域,对于人员的管理更是一件不容易的事情。要管理好团队,以下几点非常重要:经常和你的队员沟通、了解队员,也去理解队员、作为PM在技术方面要有过人之处。
  • 闫雨馨
    • 课程学习总结
      通过本次团队项目的设计实现,我对所学的知识有了进一步的理解与掌握,认识到了课本所学知识与实际应用的差异。只有通过具体项目的实践,才能更好的掌握所学知识,并针对具体的问题灵活的变通处理。此外,我深刻认识到一个项目的实现最重要的是需求分析而不是代码的实现。只有合理的分析设计,代码实现的过程中才不会遇到问题。通过本次项目设计,我深知道自己相关专业知识掌握的还很不够,也发现了学习和实践中的不足。软件工程中需求分析的不充分,软件开发方法的不恰当这些都是需要以后改进和学习的,软件开发中的各种文档编写能力还需要提升,在以后学习和实践中认真总结和完善,参考他人的软件工程项目,体会优秀软件工程的思想。总的来说,我在这一门课程的学习收获很大,希望通过这些收获,我在未来的学习与编程中能够越做越好。
    • 软件开发流程有哪些?
      软件开发流程即软件设计思路和方法的一般过程,包括对软件先进行需求分析,设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编码和调试、程序联调和测试以及编写、提交程序等一系列操作以满足客户的需求并且解决客户的问题,如果有更高需求,还需要对软件进行维护、升级处理,报废处理。
    • 什么样的数据能说明一个软件工程师的技术和能力呢?
      1.软件开发相关知识的积累程度,技术技能的熟练程度;
      2.问题领域知识和经验的积累程度;
      3.对通用的软件设计思想和软件工程思想有自己的理解;
      4.职业技能的熟练程度;
      5.实际成果的质量。
    • 团队模式和团队的开发模式有什么关系?
      软件团队的模式包括以下几种:
      (1)主治医师模式:一人为主,其他人为此人服务。
      (2)明星模式:主治医师模式到达极致,一人的光芒掩盖所有人。
      (3)社区模式:每个人参与自己感兴趣的项目,贡献力量,大部分人不拿报酬。
      (4)业余剧团模式:在不同项目中每个人扮演着不同的角色,可能随着项目的改变,自己的角色也会发生变化。
      (5)秘密团队模式:一些软件项目在秘密状态下进行,别人不知道他们具体在做什么。
      (6)特工团队模式:有一些有特殊技能的专业人士组成的团队。
      (7)交响乐团模式:人员工具齐全,准备充足的团队。
      (8)爵士乐模式:相对自由,有风险,人少且不靠谱。
      (9)功能团队模式:具备不同能力的同事们平等协作,共同完成一个功能。
      (10)官僚模式:层层领导的团队模式。
      团队的开发模式包括以下几种:
      (1)写了再改模式:和一窝蜂团队模式比较像。
      (2)瀑布模型及其各种变形。
      (3)RUP统一流程。
      (4)老板驱动的流程。
      (5)渐进交付的流程。
      (6)TSP的原则。
      团队模式是团队的定性,团队的开发模式则是团队使用的方法的定性
  • 李瑞婷
    • 课程学习总结
      刚开始在软件工程这门课开始之前,我的一个小目标是通过这学期的学习,能够增强自己的团队协作能力并学习了解软件工程的基础知识。如今软件工程这门课接近尾声,我深刻的感觉到了自己的成长,其中最主要的是团队协作能力的提升,很幸运自己遇到了优秀的组员和组长,不仅在每次的分工方面都能各尽所长,还能在遇到问题的时候一起学习进步,是我满意的一次团队合作项目,也锻炼了我很多能力。其次就是关于软件工程这门课的感受,自己的编程能力一直较弱,对于软件工程这方面开始抱着胆怯的心态,但经过一次又一次的课程作业,从个人项目到团队项目不断地在进步,我发现很多书本上的知识一定要经过实践才会有深入的了解,尽管很多次作业开始时由于自己的能力欠缺很多时候都是硬着头皮上,虽然有时候也会耗费很多时间。但最后回过头思考,发现自己真的学到了很多,学科知识也更加充实。感谢这门课带给我的成长!
    • 好的软件,从表面来看,我们可以理解为没有缺陷,没有bug的软件。软件团队的人几乎每天都在和bug打交道,那么我们如何去评价这个软件是否有bug,而bug又在衡量这什么?
      什么是bug,其实每个人对软件的行为和用户的期望值是不一样的,bug更多的来说是取决于用户,开发者的不同角度,满足用户和开发者,做到足够好,就能尽可能的减少bug。
      软件团队每天都在和bug打交道,bug的多少衡量这一个软件的开发效率,用户满意度,可靠性和可维护性。
    • 单元测试应该准确,快速地保证程序基本模块的正确性,怎么样才算一个好的单元测试,它有哪些标准呢?
      单元测试应该测试程序中最基本的单元,在此基础上,可以选择测试基本的功能点。除此之外,单元测试必须有熟悉代码的人来写,测试要快,结果要一致,在测试结束后,应该保证机器状态不变
      ,和产品代码一起保存和维护。
    • 从接触计算机以来,我们一直在写代码,有单独写的,也有一起合作写的,我们习惯注释,时刻注意代码的规范和设计,可是我们写的代码,到底是给机器看的,还是给人看的?
      我们将代码写进编译器,看似是电脑在运行,但总归是给人看的,计算机只关心的是编译生成的机器码,规范代码是为了让合作者看的明白,清楚。
  • 刘转弟
    • 课程学习总结
      刚开始在软件工程这门课开始之前,我的一个小目标是通过这学期的学习,能够增强自己的团队协作能力并学习了解软件工程的基础知识。如今软件工程这门课接近尾声,我深刻的感觉到了自己的成长,其中最主要的是团队协作能力的提升,很幸运自己遇到了优秀的组员和组长,不仅在每次的分工方面都能各尽所长,还能在遇到问题的时候一起学习进步,是我满意的一次团队合作项目,也锻炼了我很多能力。其次就是关于软件工程这门课的感受,自己的编程能力一直较弱,对于软件工程这方面开始抱着胆怯的心态,但经过一次又一次的课程作业,从个人项目到团队项目不断地在进步,我发现很多书本上的知识一定要经过实践才会有深入的了解,尽管很多次作业开始时由于自己的能力欠缺很多时候都是硬着头皮上,虽然有时候也会耗费很多时间。但最后回过头思考,发现自己真的学到了很多,学科知识也更加充实。感谢这门课带给我的成长!
    • 怎样区别程序与软件?
      程序和软件的区别:软件是为了完成特定的功能,解决特定的问题而用计算机语言编写的命令序列集合,可以理解为应用程序的集合。而应用程序是软件的一个组成部分,它是软件的必要元素。简单来说,“软件=程序+文档=数据结构+算法+文档”
    • 错误处理为何不是设计约束呢?
      错误处理应该属于功能描述的范畴。对要执行的功能给出一个陈述外,还应规约如下相关内容:
      (1)关于该功能输入的所有假定,或为了验证该功能输入,有关检测的假定。
      (2)功能内的任一次序,这一次序是与外部有关的。
      (3)对异常条件的响应,包括所有内外部所产生的错误。
      (4)需求的时序或优先程度。
      (5)功能之间的互斥规则。
      (6)系统内部状态的假定。
      (7)为了该功能的执行,所需要的输入和输出次序。
      (8)用于转换或内部计算所需要的公式。
      上述就是说明错误处理属于功能描述范畴。设计约束规约限制系统或系统构件的设计方案,所以不涉及错误处理。
    • 做产品设计的话需不需要考虑低耦合的功能?
      做产品设计需要考虑低耦合的功能,只有这样,产品本身以及构成产品的软件构件才能有更长的生命周期。
posted @ 2022-06-27 23:24  软件工程四人小团队  阅读(109)  评论(0编辑  收藏  举报