202207-夏日限定 实验十 团队作业7：团队项目用户功能验收测试

夏日限定 实验十 团队作业7：团队项目用户功能验收测试

项目	内容
课程班级博客链接	2019级计算机科学与技术
这个作业要求链接	实验十 团队作业7：团队项目用户功能验收测试
团队名称	夏日限定
团队成员及分工描述	阮凯：任务一、任务二、任务三 潘晴：任务一、任务二 杨凯：任务一、任务二 孟姣姣：任务一、任务二
团队的课程学习目标	掌握软件黑盒测试技术 掌握软件项目功能验收测试内容 学会编制软件项目总结PPT
这个作业在那些方面帮助团队实现学习目标	学习并掌握了软件黑盒测试技术 了解并掌握了软件项目功能验收测试内容 学会了编制软件项目总结PPT 各个组员协作完成工作，极大提高了团队意识
团队博客链接	202207-夏日限定
团队项目Github仓库地址链接	Summer-limit

任务1的完成情况如下：

1. 自主学习《现代软件工程-构建之法》第13章相关内容掌握基础测试技术

1.基本名词解释及分类

团队统一思想要从基本名词解释开始。

• Bug：软件的缺陷

• Test Case：测试用例，测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等

• Test Suite：测试用例集,即一组相关的测试用例

• Bug可以分解为：症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）。

1）症状：即从用户的角度看，软件出了什么问题

例如，输入（3211）时，程序出错退出。

2）程序错误：即从代码的角度看，代码的什么错误导致了软件的问题

例如，代码在输入为某种情况下访问了非法的内存地址——0X0000000C。

3）根本原因：错误根源，即导致代码错误的根本原因

例如，代码对于 id1==id2 的情况没有做正确判断，从而引用了未赋初值的变量，出现了以上的情况

2.按测试设计的方法分类：测试设计有两类方法，黑箱（Black Box）和白箱（White Box）。这是每个接触过软件测试的人都会给出的答案，但这只是整个软件测试的入门知识。所谓黑箱/白箱，是指软件测试设计的方法，不是软件测试的方法！注意“设计”二字。

• 黑箱：指的是在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计（Be-havioral Test Design），即从软件的行为，而不是从内部结构出发来设计测试

• 白箱：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。
  在实际工作中，我们不应画地为牢，严格只用某一种测试设计方法。我们对系统的了解当然是越多越好。所谓“灰箱”的提法，正反映了这一点。有些测试专家甚至希望我们忘记全部的“箱子”及其颜色。
  进一步说，我们并不是要禁止懂得程序内部结构的人员来进行黑箱测试设计，只不过是在设计时有意不考虑软件的内部结构。例如，在测试程序内部基本模块时（单元测试），通常要求由对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且对内部基本模块的“行为”通常没有明确的定义。另一个例子是软件的“易用性测试”，在设计此类测试时，没必要纠缠于程序的内部结构，而是应着重于软件的界面和行为。但是软件易用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和“白箱”没有简单的难度高低之分。测试用例写出来之后，大家可以忘了它们是从哪种颜色的箱子里出来的，使用就行了。

3.按测试的目的分类

• 功能测试：所列的测试类别中，测试的范围由小到大，测试者也由内到外——从程序开发人员（单元测试）到测试人员，到一般用户（Alpha/Beta测试）。

测试名称	测试内容
Unit Test	单元测试-在最基本的功能/参数上验证程序的正确性
Functional Test	功能测试-验证模块的功能
Integration Test	集成测试--验证几个互相有依赖关系的模块的功能
Scenario Test	场景测试验证几个模块能否完成一个用户场景
System Test	系统测试一对于整个系统功能的测试
Alpha/Beta Test	外部软件测试人员( Alpa/Beta测试员)在实际用户环境中对软件进行全面的测试

• 非功能测试：一个软件除了基本功能之外，还有很多功能之外的特性，这些叫非功能需求（Non-functional Re-quirement），或者服务质量需求（Quality of Ser-vice Requirement）。然而，若没有软件的基本功能，这些特性都将无从表现出来，因此，我们要在软件开发的适当阶段——基本功能完成后再来做这些非功能测试，如下表所示

测试名称	测试内容
Stress/Load Test	压力测试一测试软件在负载情况下能否正常工作
Performance Test	效能测试测试软件的效能
Accessibility Test	可访问性测试测试软件是 否向残疾用户提供了足够的辅助功能
Localization/Globalization Test	本地化，全球化测试
Compatibility Test	兼容性测试
Configuration Test	配置测试测试软件在各种配置下能否正常工作
Usability Test	易用性测试测试软件是否好用
Security Test	软件安全性测试

4.按测试的时机和作用分类

• 在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否顺畅，这些测试如下表所示。

测试名称	测试内容
Smoke Test	冒烟测试 一测试不通过， 则不能进行下一步工作
Build Verification Test	验证构建是否通过基本测试
Acceptance Test	验收测试一全面 考核某方面的功能/特性

• 另一些测试名称，则是说明不同的测试方法，如下表所示。

测试名称	测试内容
Regression Test	“回归”测试一对一个 新的版木，重新运行以往的测试用例，确认新版本相比已知版本有无“退化”( Regression )
Ad hoc (Exploratory) Test	随机进行的、探索性的测试
Bug Bash	Bug大扫荡
Buddy Test	伙伴测试--开发人员 (伙伴)作为测试人员测试特定模块

5.各种测试方法

• 单元测试( Unit Test)和代码覆盖率测试( Code Coverage Analyis)
  代码覆盖率(code coverage,test coverage)是单元测试(unit test)中的一种度量方法，用来评估测试用例(test case)能够覆盖多少的代码，能够从一定程度上反应代码的质量。

• 构建验证测试 ( Build Verification Test, BVT )
  顾名思义，构建验证测试是指在一个构建完成之后， 构建系统会自动运行一套测试， 验证系统的基本功能。在大多数情况下，这此验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

• 验收测试( Acceptance Test )
  测试团队拿到一个“可测”的构建之后，就会按照测试计划，测试各自负责的模块和功能，这个过程可能会产生总共10来个甚至100个以上的Bug,那么如何才能有效地测试软件。

• “探索式”的测试（Ad hoc Test）
  “Ad hoc”原意是指 “特定的，一次性的"。 这样的测试也可以叫Exploratory Test.什么叫“特定的"测试或者“探索式”的测试?
  就是指为了某一个特定目的而进行的测试，且就这一 一次， 以后- 般也不会重复测试。在软件工程的实践中，“Ad hoc"大多是指随机进行的、探索性的测试。
  比如:测试人员小飞拿到了一个新的版本，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能 B做得如何，或者想看看模块 A在某种边界条件 下会出现什 么问题，于是他就“Adhoc" 一把，结果还真在这一功能模块中发现了 不少小强。
  “Ad hoc"也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按 ，然后随意改变窗口大小，看看会出什么问题....如果没问题，那么以后也不会再这么做了。

• 回归测试（Regression Test）
  在单元测试的基础上，我们就能够建立关于这一模块的回归测试（Regression Test）。Regress 的英语定义是：return to a worse or less developed state，是倒退、退化、退步的意思。在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准线（Baseline），一个模块的所有单元测试就是这个模块最初的Baseline。假如，在3.1.5版本，模块A的编号为125的测试用例是通过了的，但是在新的版本3.1.6上，这个测试用例却失败了，这就是一个“倒退”（Regres-sion）。工程师们应该在新版本上运行所有已通过的测试用例，以验证有没有“退化”情况发生，这个过程就是一个“Regression Test”。如果这样的“倒退”是由于模块的功能发生了正常变化引起的（例如，我们要修改模块，支持电子邮件地址以.name为最后的域名），那么测试用例的基准就要修改，以便和新的功能保持一致。针对一个Bug Fix，我们也要做Regression Test。

• 场景/集成/系统测试（Scenario/ Integration / System Test ）
  在软件开发的一定阶段， 我们要对一个软件进行 全面和系统的测试， 以保证软件的各个模块都能共同工作，各方面均能满足用户的要求。这类测试叫系统|集成测试。

• 伙伴测试（Buddy Test）
  我们这里要讲的伙伴测试是指开发人员可以找一.个测试人员作为伙伴( Buddy).在签人新代码之前，开发人员做一个包含新模块的私人构建(PrivateBuild)，测试人员在本地做必要的回归1功能1集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签人优码。
  在项目后期，签人代码的门槛会变得越来越高，大部分团队都要求缺陷修正(Bug Fix)必须经伙伴测试的验证才能签人代码库。

• 效能测试（Performance Test）
  用户使用软件，不光是希望软件能够提供一定的服务， 而且还要求服务的质量要达到一定的水平。软件的效能是这些“非功能需求”或者“服务质量需求”的一部分
  效能测试要验证的问题是:软件在设计负载内能否提供令用户满意的服务质量。

• 压力测试( Stress Test )
  压力测试严格地说不属于效能测试。压力测试要验证的问题是:软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃。

• 内部/外部公开测试( Alpha/Beta Test )
  在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会让特定的用户( Alpha/Beta用户)使用正处于开发过程中的版本，用户会通过特定的反馈渠道( E-mail、BBS、微博等)与开发者讨论使用中发现的问题，等等。这种做法成功地让部分用户心甘情愿地替开发团队测试产品并提出反馈。
  按惯例来说，Alpha Test般 指在团队之外、公司内部进行的测试; Beta Test 指把软件交给公司外部的用户进行测试，与之对应地，软件就有Alpha、Betal、 Beta2版本。 在网络普及之前，做BetaTest费时费力，成本较高，现在由于网络的传播速度很快，与外部用户的联系渠道很畅通，很多外部用户都想先睹为快因此， 现在开发团队增加了反馈的密度，不必再局限于Alpha 或者Beta发布、而是不断地把此中间版 本发布出去以收集反馈。

• 易用性测试( Usability Test )
  测试人员，以及其他的团队成员都可以对软件的可用性提出意见，包括以Bug的形式放在TFS中。软件的可用性并不神秘，就是让软件更好用，让用户更有效地完成
  工作。

• “小强”大扫荡( Bug Bash )
  Bug Bash,或者叫Bug Hunt,简而言之，就是大家一起来找小强的活动小强大扫荡。一般是安排出一段时间(如一天)，这段时间里所有测试人员(有时也加入其他角色)都放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找到最多和最厉害的小强的员工。一般情况下是的，但是并不是全体人员用键盘鼠标一通乱敲乱点就可以搞定，大扫荡的内容也应该事先安排好
  这种活动。

2. 软件的功能测试方案文档及仓库截图

• 软件的功能测试方案文档

• 仓库截图

3. 视频演示软件系统安装配置过程及仓库截图

• 视频演示软件系统安装配置过程

• 仓库截图

4.软件远程访问地址

软件远程访问地址Please Click

5. 列表统计此次测试共运行了多少个测试用例，发现了多少Bug？

测试用例编号	用户注册模块	用户登录模块	学习模块	圈子模块	个人信息模块
Test-001	Test-001注册成功	Test-001登录成功	Test-001可学习资源	Test-001基本正常发布帖子	Test-001可正常管理个人信息
Test-002	Test-002注册成功	Test-002登录成功	Test-002可学习资源	Test-002基本正常发布帖子	Test-001可正常管理个人信息

出现的BUG：

1）在收藏学习资源时会闪退。

2）发布帖子的时候编码只能是数字，有其他自字符输入就发布不了

6. 总结执行用户场景测试的情况

我们让一些不同从业者，不同地区的用户帮我们完成测试，最后总结出基本功能完善，只是存在一些小问题。

7. 任务1执行回归测试的情况

测试项目	测试内容
数据库是否正常	是
系统各级用户能否正常登录、使用	是
能否通过系统管理员对系统进行管理	是
系统界面是否人性化	是
系统帮助性是否很强	是
系统安装程序的提交	是
数据传递是否正常、一致	是
系统bug、错误率是否较高	否
系统运行速度是否正常	是

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

• 操作系统：Windows 10
• Java开发包：JDK 1.7以上
• Android版本：Android Studio 2.3.2
• 数据库：SQL Server

任务2的完成情况如下：

1. 团队项目总结陈述PPT及仓库截图：

2. 软件功能演示视频

任务3的完成情况如下：

1. 各项任务的时间花费情况：

任务类型	花费时间（h）	分工
任务一	420	团队
任务二	300	团队
任务三	100	阮凯

2. 完成本次作业的感受和体会：

• 杨凯：通过本次实验，我深刻体会到了在软件开发的过程中前期设计的重要性。虽然在前面的多次实验中已经经过很多次详细的软件设计，包括数据库等各方面，但是在最后实际的项目开发中，仍然会出现很多的问题，所以一定要重视项目设计。同时与大家合作也非常得愉快！

• 潘晴：通过本次实验，我对于团队合作有了更深刻的体会，孤木难成林，良好的团队合作的确对于项目的进度和最终呈现的质量可以起到非常重要的作用。同时我也深刻的体会到了自己很多的不足，无论在与人的交流沟通方面还是在专业知识方面，我都有很多需要向我的同伴学习。

• 孟姣姣：通过本次实验，通过与同伴的合作，我学习到了自己很多以前没有接触过的知识，对于以前不会自己去主动学习的内容，在团队合作中体会到了自己所发挥的作用，会积极主动的去学习自己不懂的内容，我认为非常有利于我们的成长与学习。

• 阮凯（PM）：通过撰写本次实验团队作业，以及成员之间的交流与沟通，整体来说我们小组合作氛围非常良好，每个人都能各尽其责，在遇到问题时能够自主发言，基本可以按时完成自己的任务，同时在完成的自己的任务时会寻求其他成员的帮助；在此次实验中，由于前期设计不够完善，我们在此次实验中出现了一些问题，需要我们每位小组成员在以后的软件开发中注意。同时通过本次团队作业，我们每个人在各方面也有了非常大的成长和进步，这的确是一次非常系统，非常全面的软件开发过程，使我们受益匪浅，且体会到了团队协作的重要性！

3. 回答提出的3个问题：

• 阮凯

• 问题1：在章节1.2中，我看到了如下的一段文字：

  人们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想体系。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”

  对于这段文字的理解存在困惑：这些相关的技术和过程具体指的是那些技术，以及如何统一到一个体系中。

  • 软件开发流程即软件设计思路和方法的一般过程，包括对软件先进行需求分析，设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编码和调试、程序联调和测试以及编写、提交程序等一系列操作以满足客户的需求并且解决客户的问题，如果有更高需求，还需要对软件进行维护、升级处理，报废处理。

• 问题2：在章节1.2.4中，我看到了如下的一段文字：

  什么是好的软件？一些同学认为，所谓的好软件，就是软件没有缺陷(Bug)，所谓软件工程，就是把软件中的Bug都消灭掉的过程。

  对于这段文字的理解存在困惑：文中描述到好的软件是没有缺陷(Bug)的，我认为从一个普通人的角度来说，一个好的软件的评价标准不仅仅是没有Bug的。

  • 我认为：一个好的软件应该具有：

    • 简单的使用方法，即用户容易理解和操作；

    • 界面设计应该符合用户的审美需求，即了解清楚用户群体。

• 问题3：在章节3.2中，我看到了如下的一段文字：

  软件的模块之间存在着各种各样复杂的依赖关系，软件的不可见性和易变性，使得软件的依赖关系很难定义清楚，导致软件不易及时的维护和修复。

  对于这段文字的理解存在困惑：软件的依赖关系的具体定义是什么？

  • 依赖关系：有两个元素A、B，如果元素A的变化会引起元素B的变化，则称元素B依赖（Dependency）于元素A。在类中，依赖关系有多种表现形式，如：一个类向另一个类发消息；一个类是另一个类的成员；一个类是另一个类的某个操作参数，等等。

• 杨凯

• 问题一：怎样将自己的代码构建成一个软件工程项目？

  • 所谓的构建软件工程项目只不过是严格化各个程序设计流程。

    但是如果完全照搬流程去设计，不仅没灵活性而且扩展性、效率各方面都不一定符合自己的要求，《设计模式(Design Pattern)》上说到，软件工程如果是建立在空泛的理论上，是无法对软件设计能力进行强化的，设计模式是软件工程实践上的强有力工具。

• 问题二：怎样将多人编程的代码规范的整合到一起？

  • 定好规则

  • 分层设计

  • 抽象共同点、封装变化点

  • 定义接口

  • 坐在一起讨论，并形成文档

• 问题三：怎样的软件算是一个质量好的软件项目？

  • 质量好的软件项目：要衡量一款软件是不是好软件，可以从以下几个方面来判断：首先是使用方法要简单，一款性能优越的软件，在使用方法上是很简单的，初次使用也能够在短期内就可以上手使用。其次就是功能全面，这也是软件的灵魂所在。一款好的软件要满足使用者的各方面的个性需求。因为使用者的行业不同，对象不同，因此产生了各种各样的使用软件，可以完成不同任务的软件。还有就是对软件后期维护，软件升级换代比较及时，省心。软件维护是决定着它可不可以正常使用，能不能发挥出软件的全部性能。还有软件的升级是可以弥补软件自身的某些缺陷和不足，因此这两个因素也是非常重要的。

• 潘晴

• 问题1:怎样才算做是一个合格的软件工程师？

  • 有良好的编程能力。编程能力直接决定了项目开发的效率，至少要精通一门编程语言，熟悉它的基本语法、技术特点和 API( 应用程序接口 ) 。

  • 有自觉的规范意识和团队精神。随着软件项目规模越来越大，仅仅依靠个人力量已经无法完成工作，因此，团队精神是十分重要的。一个合格的软件工程师应在团队里扮演好自己的角色，有良好的合作意识。

  • 有认识和运用数据库的能力，了解数据库的操作和编程是软件工程师需要具备的基本素质之一。

  • 具有软件工程的概念，从项目需求分析开始到安装调试完毕，基础软件工程师都必须能清楚地理解和把握这些过程，并能胜任各种环节的具体工作。

  • 具有求知欲和进取心。软件工程是不断变化和不断创新的行业，面对层出不穷的新技术，软件工程师的求知欲和进取心就显得尤为重要，软件工程师应具有较强的学习总结能力、需求理解能力以及对新技术的敏感性。

• 问题2：软件工程与计算机科学之间到底有什么不同和联系？

  • 软件工程和计算机科学都是属于计算机专业的一个分支。不同在于软件工程是一门研究用工程化方法构建和维护有效的、实用的及高质量的软件学科。它主要涉及到程序设计语言、数据库、软件开发工具等方面，更加偏重于软件的开发与测试、维护等方向；计算机科学与技术需要掌握计算机硬件、计算机软件与应用的基本理论，计算机科学与技术可从事于科研单位、事业单位、技术和管理部门，计算机科学与技术学的更多，更在于基础知识。结构工程师更像计算机科学家，而建筑师更像软件工程师。

• 问题3：在如下几句话中，我的感想是如果过度预期，可能会出现停滞不前的情况，如果团队主要领导人对于工程的变化反应过于敏捷，那么如何让团队成员短时间内转变思维和工作方式，团队成员又该怎样去适应。那么该如何把握好适应软件工程开发过程中出现的变化的这种“分寸感”？

  • 软件工程，唯一不变的是变化。保持敏捷，预期和适应变化。我们是预期变化，不是期待变化。如果短时间内无法快速转变思维和工作方式，我可以考虑在不拖慢整体团队工作效率的情况下，先将自己正在做且符合项目实行计划的部分做，如果做的部分需要全部推翻，就先转变自己的心态，重新制定工作计划，当然这些都是在决策者的想法是正确的前提下。

• 孟姣姣

• 问题1.我们在设计软件的过程中需要考虑这个软件的商业模式吗？如果考虑那么应该怎样去选择？
  在1.1中我看到这样一段话：

一个软件团队或企业总要养活自己，市面上有很多赚钱的方式：
有的交钱买断
有的“先适用再交钱”，有些软件也提供试用版、免费版、和正式版、还有的类似期刊订阅，每年交钱
有的不但免费，连源代码也一并奉送，但是要求获得源代码的开发人员遵守某种协定
有的送硬件，但是软件要收钱
有的送软件，但是硬件要收钱
也有的是“免费用，但是要看我提供的广告”
还有的是“免费用，程序也不是我写的，如果有问题，给我钱，我就来提供咨询”
我查阅资料理解，软件设计的过程中需要考虑软件的商业模式（https://wenku.baidu.com/view/23386fa2ad1ffc4ffe4733687e21af45b307fe9b.html）

• 在在设计软件的过程中需要考虑这个软件的商业模式，每一家企业在整个市场中的份额都小得可怜，他们基本上都是面向自己的优质增值服务商和最终用户来销售。而在中国的情况是，有能力基于厂家的软件开发平台进行二次开发，并且有能力购买这个平台的增值服务商和用户很少，所以，中国的软件开发平台提供商们很难快速、大规模的抢占市场。都是提供“标准化+行业化+个性化”的应用模式。所以，现在软件商们都学乖了，他们实际上是先向合作伙伴或最终用户提供标准化的软件产品，让其先将这个产品熟悉和掌握起来，然后再向其推销自己的开发平台，使其能够基于这个平台对软件进行自主开发。

• 问题2.一个软件可以有Bug，那么怎样程度的Bug是可以接受的呢？这个度又要依靠什么去把握呢？
  在1.2.4中有这样一句话：

很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。

• 判断这个Bug是一个Bug的标准：

1.通过技术文档来识别缺陷
1）需求规格说明书
2）设计和分析文档
3）用户指南、帮助手册
4）早期提出的bug,测试用例
2.根据行业标准规范或参考同类型软件来识别缺陷
3.与客户和相关 人员沟通来识别--产品经理、开发人员、运营人员等
我们去识别一个缺陷，一定要参考相关的文档来作为你提交Bug的一个依据。如果说对于有些公司没有这个文档的话，我们可以去参考行业的标准或者说同类型的软件来进行一个识别。
这个是属于功能测试面试的时候基本上是必问的一个问题！

• 问题3.把一个大任务划分为可操作的小任务，这个“大任务”与“小任务”是如何定义的？
  在2.4.2.2中有这样一段话：

正如谚语所说:不能一口吃成个胖子。罗马不是一天建成的。同样，一个功能完备的程序也不是一炽而就的。在这里，我们讨论如何把大任务划分为可操作的小任务，以及任务的次序。

• 将一个人不能完成的任务划分为多个小任务，和其他人相互配合共同完成这个大的任务，有时候把一个大的task拆成小的task，这样对做的人来说条理很清晰，不会出现某些功能忘了的情况，对管理人来说也可以清楚的看到任务的进度，有个明确的预期。如果能把拆成的小任务做成可以并行开始的任务，那么队员就可以帮你，很多时候不是别人不愿帮你，而是无法提供帮助。通过这学期对软件过程的学习，我和小组成员的配合，更加体会到了将大任务划分为小任务的必要。