验收测试E2E分析方法

babyfengfjx

已于 2024-05-06 14:53:48 修改

阅读量1.6k

点赞数 38

文章标签：服务器 linux 运维

于 2024-03-22 09:42:37 首次发布

本文链接：https://blog.csdn.net/babyfengfjx/article/details/136929482

版权

前言

对于验收测试工程师来说，编写验收测试分析和测试用例是一项必须且重要的工作内容，但大多数同学在做验收测试分析及用例编写时，仍旧陷入到传统的分析及用例编写思维中，与内部测试团队所输出的内容并无差异，虽然大家在讲述验收工程师职责或者测试分析思路时，都知道说要编写用户场景用例，可实战过程中仍旧是任性的走老套路，犟的很！

究其原因，还是没有摆脱传统的测试思维，更多的关注点仍旧在文档中罗列的基本需求点，除了字面上描述出来的东西，很难将自己放在用户角色上去想象体验手头的产品，在验收时，又本着任务的压力，只能优先去完成流程上的一些基本任务：验收测试分析、验收测试用例编写、各种会议评审、输出各类报告……

上述每一个具体事项实际都只是我们工作实施的一个产物体现，并不是最终的目的，也就是说不仅仅为了去完成一篇分析或者用例的编写，就匆匆忙忙开干，在没有深入理解需求，了解用户痛点，及项目意义的情况下，所有的忙碌都不会产生太高价值，看起来长篇大论的文字表格一堆，但其中蕴含的思维和测试覆盖点却很难达到我们的预期，往往后期需要花费大量的精力去查漏补缺，进行各种优化，算算总投入成本那是极不划算的，而且还觉得自己特忙。

对于团队中每一个同学来讲，每个人都有自己的特长和优势，但也会存在部分同学的确存在以上描述的若干问题，所以也就有了此篇文档，作为个人理解的内容，想要起到抛砖引玉的效果，希望在某些方面能够对大家有所帮助，也许能够通过思维的碰撞产生更加适合当前团队的执行方法和流程。

本文会以通俗易懂偏口语化的风格进行阐述，尽量结合当前项目的实际内容来阐述具体思想，文中所有举例只是为了阐述某种思维方式，请读者不要钻牛角尖，而应该深入扩展理解思维背后的原理，内化成自己的经验和做事方法。

导读

本文总体文字比较多，且讲述的内容非常基础，可能都是在各位平常工作中已经在实施的部分，只是做了一个系统的呈现，如果看的过程确有共鸣，则可以快速跳过熟知内容，直接查看“精加工生产E2E验收用例”部分内容；
如果前文中部分内容平常未涉及到，则可以细致去想一下描述中的各问题及思维过程，最好是能转化成自己独特的思维逻辑；
如果文章通篇读起来觉得索然无味，也可以私下进行一些深入的交流（排除语文功底因素），这是我极其希望遇到的场景。

我可以怎么做

如果你是一位新同学，或者是从传统测试转做验收测试的，下面的几点内容或许对你有所帮助；
当然如果你是老司机，那也可以看看是否有其他更好的点子可以帮到大家。

作为验收工程师，首要任务是先把自己以前的思维做一个冻结，把杯子倒空，忘掉过往的所有荣耀与成就，重新出发；–调整心态
清晰认识自己的职责和责任，做的所有事情都不仅仅只是为了完成上级下达的任务，而是为了某一个目标; --清晰自己工作的价值
比如XX项目经过你的验收后，可以拍着胸脯对他人说，已经验收通过没有问题，大胆发布，让用户拿去用吧!
或者是经过验收后，发现XX模块有风险，具体风险是XX，可能造成XX影响，建议提前采取XX行动，规避方案是XX，提前告知关注者项目的实际情况，即便是发布后真出现了问题，也做到了未雨绸缪。
接触任何一个项目时，首先是要弄清楚该项目的需求背景，直接接口人就是产品经理，从产品经理这里可以获取到项目的最原始信息，包括项目使用者，使用者的一些特点，此项目能够解决他们什么问题，核心价值具体体现在哪里，产品最差做到什么程度用户也能够接受（逐步剥离可以提炼到核心需求）？所有的这些只为弄清楚背景与用户痛点；
在了解项目的背景与用户痛点后，接下来的工作就需要始终将这些信息放到制高点，任何的思考行为都为这两点服务，你的模块分析是为了更好的保证用户能够流畅满意的使用，你的用例是为了能更全面的覆盖用户的操作行为，你的执行动作就是将自己当做用户来操作使用这个产品；
通过上述的信息输入后，就可以开展实际的验收测试分析，这里还是推荐使用思维导图的方式来开展此项工作；
在思维导图分析完成后，接下来就是用例的转化写作了，转化过程只需要抓住一个核心：思维导图中辛苦分析出来的验证点不要漏掉；
验收执行阶段工作主要是执行用例，在执行每条用例时，同样需要思考用例编写的本意是要验证什么点，切记无脑执行，往往能够发现用例可优化的地方，或者可扩展验证场景。

正题

前面的内容主要是一些铺垫，也就是大家说的鸡汤软文，下文主要从上面列出的几个步骤来描述一下个人理解的验收测试用例的生产过程，用例输出绝对不是直接上来就干的事儿，拿到项目一上来就直接干用例的行为那都是莽夫行为，测试最高价值体现就是你的思维，而对思维的加工最终输出的产物才是思维导图、测试用例这些实际的文档，下面会针对每个步骤进行详细的阐述，希望对大家有所帮助。

下文整体思路会以下图思路开展

在这里插入图片描述

用例生产过程

所需要的原料

此部分内容，主要是列出我们在做一个项目的时候，最好弄清楚我们所需要的输入；
包括我们需要具备的一些能力或者了解的知识点；
当然不是所有列出的东西都一定需要具备或者精通，当前不具备的就可以针对性的去提升学习，以便能在工作中能够轻松应对。

实物原料：- 项目需求文档；–必选（哪怕是一句话需求）

需求原型；–可选

研发概要设计文档；–可选
研发详细设计文档；–可选
项目demo；–可选
……

思想原料：- 熟悉软件研发流程；

熟悉软件测试基本理论知识:

黑盒测试基本方法（等价类、边界值、正交、状态迁移、判定表、错误猜测、……）；
接口测试、安全测试、性能测试、网络基本知识的了解；
测试思维导图分析方法；
用例编写的基本原则，测试用例的八大要素；

加工流程

通过对上述或者更多的原料进行有序加工，我们的思维产物最终会以具体的思维导图、测试用例体现出来。

Step1 深入理解项目背景、用户痛点

实操步骤

首先我们在接触到一个新项目时,首要的就是拿到该项目的需求文档,如果没有需求文档就直接找产品经理或者一线人员,甚至是直接用户进行沟通,主要目的就是弄清楚如下几个问题:
8. 这个项目产生的原因是什么?–为什么要做这个项目,有钱任性?做着玩? 主要是为了解决用户什么问题,用户在当前碰到了什么难题需要我们来解围?
9. 不做这个项目行不行?–市面上有没有现成的解决方案?为什么要我们做这个?我们这个项目的优势在哪里?我们能为用户提供什么核心价值?
10. 我们的核心用户都是哪些人?都是一些什么样的人?这些人有些什么习惯或者特点?在产品使用上会不会有些特殊癖好或者要求?
11. 我们是怎么解决用户遇到的这个难题的,当前的需求内容是否能够达到解决用户痛点的目的?
经过上述几个问题的自问或者问他人,你一定会获得一些有用的信息,经过对这些信息的消化和理解,你基本上就具备了与产品经理或者用户等位思考的状态,在此状态下,再结合产品经理编写的现成的背景和痛点问题描述,基本上就真正理解了项目的背景了；
如何确定自己已经理解了当前项目背景呢？

Check点

把这个项目介绍给其他人，能够流畅的按照上述几个问题维度来讲解清楚的话，就说明已经达到要求了。

Step2 梳理、挖掘基本需求点

这一部分内容大家最熟悉，也是一般人上来就开搞的一步，每个人都能整出一篇“丰满”的思维导图出来，全部展开的时候看起来内容丰富，但很多同学的思维导图内容细看后发现缺乏逻辑，有时候会很全，有时候会遗漏一些内容，实际上就是缺乏一些系统的思维。
实际上我们在做项目或者模块分析时还是有套路可以耍的： 1
首先就是把我们软件质量模型这张牌掏出来，如果能熟练的掌握质量模型的6大特性（功能性、可靠性、易用性、效率、可维护性、可移植性），27个子特性，那你做测试分析可能遗漏的几率是很小的。

实际上很少人能全部掌握，但你需要做到的是6大特性一定要掌握，每个特性大概对应的是哪些维度要非常清楚，质量模型中的维度需要逐项去做分析覆盖，功能性这块基本是个测试都能做到，但如何把功能性做全做深就又是一个挑战；

功能特性分析：

功能特性分析基本占据了80%以上的内容，也是我们需要花费80%精力去做好的部分，看起来最简单的部分，也是最难的部分;
你需要深入理解项目背景和用户痛点，需要了解需求文档中提及的每一个模块功能，以及模块与模块之间的联系；
需要在没有原型的基础上在脑海里自己勾勒出产品界面的雏形，想象各个功能模块之间的跳转逻辑以及依赖关系；
通过对SE/开发编写的概要设计、详细设计的仔细研读，了解每个模块的具体后台实现，来挖掘隐藏的测试点和逻辑联系；–这一步至少50%的测试人员做不到，很多人无法理解开发的后台实现逻辑，也就不可能知道该实现可能存在的问题，自然就不可能挖掘出这种隐藏的测试点，往往代码的缺陷就来自于这里，因为开发编码实际上就是把他的思维以代码的方式去呈现出来，那开发自己的想法都可能有问题，我们做测试的不去识别他的想法缺陷，再到后面去弥补，你肯定已经想到这个地方的成本有多高。所以能够落地去做的事情就是仔细研读开发编写的详细设计文档，技术这块不懂的就去查资料去问开发，直到理解他的实现逻辑是什么，在这个过程中你就会找到很多隐藏的测试点，从而能够丰富你的功能分析点。
对于解决方案类产品（B/S架构），B/S类架构项目都是分前后台的，往往测试分析的时候大家只会去关注前台的显示，文案，按钮这些基本肉眼可见的东西，对于后台数据库的内容往往“视而不见”，在理解开发详细设计时，就要同时清楚他们的数据表设计内容，了解表与表之间的关联关系，字段的具体含义，前端数据获取的地方，以此就非常容易识别前台代码是否写死，是否是按照约定的逻辑来处理加工数据的，也就能提早发现一些设计、实现上不合理的地方。

思维导图的输出

通过上面的思路分析后，我们就能输出80%的思维导图分析内容，也就抓住了这个项目的80%的测试点。
此时你完成的思维导图大概应该是这个样子：
在这里插入图片描述
完成80%内容后，剩下的把其他五大特性的内容进行完善即可，具体每个特性所体现的内容请大家自行学习，并转化成项目中可实施的测试点此部分完成后思维导图大致会是下面的结构，能够确保质量模型维度的全覆盖，那测试点的梳理基本就完成95%了。
在这里插入图片描述
完成上述测试分析后，实际上我们还有一个很重要的维度容易忽略，那就是异常场景，当然很多同学也容易特立独行，在上面的分析过程中就投入大量精力去搞异常场景，显得自己考虑问题的角度比较深入或者独特。
想法是好的，但这个不是我们主要发力的点，你基本业务流都没整明白，直接到这种容易“钻牛角尖”的胡同里，很容易走火入魔。
建议上来说，在完成上面的所有分析后，再把自己脱离出来，去思考一些异常场景的补充，此时你的角色就变换成一个“破坏”者，以你能想到的，在日常使用过程中可能发生的一些“可怕”场景都用上来，如果符合当前项目的操作入口，那么就是你异常场景的突破口。

打比方（也不知道比方会不会怪我老打他）：

使用过程中，直接关闭程序（数据都没保存呢……）–程序是否能再次正常启动，数据是否可以恢复到之前打开的状态；
直接暴力切断电源，系统重启后，程序是否正常运行，数据是否恢复之前状态；
直接关闭浏览器，提交的数据是否能下次恢复，程序是否能拦截并给出提示还有数据未保存；
服务器直接断电，被手动关闭，重启服务器后，服务是否能正常拉起，恢复后台服务能力，数据是否均正常；
对于存在输入的地方，我们可做的骚操作很多，这里边界值的上点和外点、非等价类的输入就是我们做异常测试的发力点，会不会因为我们的一些上点、内点、非等价类输入，或者特殊字符输入，或者SQL注入的内容输入造成程序崩溃，或者安全漏洞等等；
对于图谋不轨的人，我们还需要考虑安全问题，是否存在明文传输（密码全程是否加密），通过浏览器F12调试模式查看接口的传参过程，通过后台数据库查看具体的密码存储形式，通过后台日志查看敏感信息是否脱敏处理……
数据传输过程中，直接断开网络，程序下次是否能正常重新处理数据；
上传非法格式，非法超大文件前台是否能正常校验拦截，通过接口直接上传，后台是否能正常拦截；
程序提供的配置，逻辑上是否有做依赖控制，是否存在前后冲突的配置可以设置，导致部分配置不生效；
数据的多次重复提交是否会存在异常；
数据的新建=》删除=》再建，是否能正常处理；
数据的提交更改后，下次进入展示，回显是否正确；
存在数据记忆的场景，是否能够正常记忆；
存在回退的场景，数据是否能够正常回滚无残留；
存在数据迁移的场景，数据是否能够正常迁移，且兼容新版本的展示结构；
存在数据结构升级的场景，是否能向下兼容老旧数据，或者正常转换旧数据结构，从而正常展示在前端；
存在可以向后台提交数据的按钮时，是否可以快速频繁的点击提交，可能导致数据异常；
存在单选、复选、全选、全不选的场景时，频繁的选择状态切换，选择逻辑是否处理正确，选择数据对象是否准确；
存在批量新建、上传、删除等场景时，对于单条数据的批量操作，多条数据的批量操作，是否能正确处理；
存在大数据量场景时，需要重点关注接口数据的处理准确性，在实现规格内，提交的大数据请求处理，是否能准确且高效的完成。
此时你的思维导图大概是这个样子：

Step3 精加工生产E2E验收用例

通过上面的生产加工后，想必大家觉得分析工作已经完成了，可以说作为内部测试在完成上面工作后，测试分析工作的确可以告一段落，我也可以打包票说只要你能按照上面提到的维度，每个维度都做出了深入的思考与分析，那你的测试分析是比较完善的；
但作为验收工程师，最核心的部分还没开始，那就是E2E场景，也就是说，到现在为止，验收工程师的核心工作才刚刚开始……
实际上前面的工作都已经做的比较全了，剩下的部分只需要结合部分思维来串联一下就可以完成，此刻你就变身为一个串珠的人儿了，把你精心准备好的“珍珠”按照某种方式串起来，做成一条条“项链”，这些“项链”就是我们验收的E2E场景用例，其主要会涉及到如下方面内容：

理解何为用户场景？

用户日常使用时，使用产品的操作路径，可能进行的操作流。

写这些E2E场景的意义是什么？

尽可能全的模拟覆盖用户日常会操作的路径，提前发现可能存在的问题，确认产品是否能够满足用户日常使用，弥补在模块测试中对模块之间的关联性测试覆盖不足的问题。

用户场景的来源有哪些？

通过功能点分析，站在用户角度采用状态机思路编写E2E场景用例–你就是用户；
通过分析一线人员提供的问题信息，获得用户使用的场景信息–真实使用者的反馈；
通过一线人员提供的用户群体特征，使用产品的场景等信息，通过关联分析构建用户场景信息–对真实使用者的模拟分析，有时候用户自己都不知道自己需要的是什么，那我们就需要替用户去思考这个问题，如同乔布斯说的：在我发布苹果手机的时候，用户才知道这就是他们想要的。

什么叫做端到端（E2E）场景用例？

不同于传统测试过程中仅针对某一个功能点进行深入验证的用例，而是尽可能将多个功能点通过某种思路（如状态机）有目的设计成一连串的操作流，形成的一种用例形式。

场景用例的编写粒度该如何把控？

在编写这类用例时，很多同学会陷入两难境地，在测试步骤中，不知道编写粒度该控制到哪个层次，写太细了跟传统用例没区别，写太粗了又担心不具备可执行性；

实际上这个问题很难按照某种要求去规定，主要把握几个原则：

场景用例编写的前提，一定是内部测试已经有非常详尽的功能用例，覆盖每个功能点，确保了基本功能是没有问题的；–如果担心这个地方有遗漏，说明我们内部测试需要改进，并且在测试执行阶段，验收工程师也需要有能力进行适当发散，做事不能眉毛胡子一把抓，每个阶段的重点核心不同，该放的时候要放，该收的地方得收。
基于上述前提，就知道我们的场景用例不会写的太细，更多的是一种操作行为流的描述，可以做的是，在每一个操作行为后，预期结果我们尽可能的描述全面；
每一条用例都需要有一个核心目的，要想清楚该用例的核心是为了验证或者保证什么功能，那么用例的步骤描述都需要围绕这个核心去开展，避免一条用例中混杂不同的场景和行为路径，会导致用例缺乏目标，也容易产生冗余用例内容；
用例粒度确保能够清晰引导执行者完成步骤描述内容，在存在依赖的部分交代清楚依赖获取的方式，预期结果明确无歧义；
在编写过程中发现用例步骤太多（超过十几步）,那就需要针对该路径做分离处理，可以分成多条用例来覆盖，避免单条用例步骤过于复杂，可能对后续的执行带来不必要的麻烦；

我该如何知道E2E用例步骤该从哪里开始又从哪里结束？

此行为实际上也没有固定的公式可以参考，仍旧是结合部分经验来完成：

把握一个核心目的，场景用例内容必须包含我们前面分析的所有功能点；–如果没有包含在内，则问自己前面的分析是否有必要，如果觉得没必要就裁剪前面的分析；
用例开始起点一般可以采取某个功能模块的入口；
用例的结束就不一定会有唯一的结束点，因为从起点开始后，可能有多个分支均会走向结束，此时则可以分成多条用例来覆盖（对于前面覆盖的步骤则可以作为前置条件，以此精简其他分支的用例内容）；
有些分支走下去发现是一个死循环，无法有效闭环，那此时我们至少需要覆盖以此完整的循环，保证各个状态之间的转换路径均需要覆盖（下文会采用状态机的方式做阐述）
我们先来了解一个概念：“状态机”，这个将对我们编写E2E用例有较大帮助，场景用例编写的总体思路我们将采用状态机的套路来进行，所以我们需要先了解这个概念：

状态机含义

状态机就是有限状态自动机的简称，是现实事物运行规则抽象而成的一个数学模型状态机有4 个要素: 现态、条件、动作、次态。这样的归纳，主要是出于对状态机的内在因果关系的考虑:

“现态”和 “条件” 是因，

“动作”和 “次态” 是果。

现态：是指当前所处的状态。
条件：又称为 “事件”，当一个条件被满足，将会触发一个动作，或者执行一次状态的迁移。
动作：条件满足后执行的动作。动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。动作不是必需的，当条件满足后，也可以不执任何动作，直接迁移到新状态。
次态：条件满足后要迁往的新状态。“次态”是相对于 “现态” 而言的，“次态”一旦被激活，就转变成新的 “现态” 了。
转换状态示意图：

下面就是对水在不同状态之间的转换示意图 - 假如水蒸气是现态，在施加降温这个条件后，会发生凝结动作，从而变成次态的液态水；

当前液态水是现态，在施加降温这个条件后，会发生凝固动作，从而变成次态的冰；
相反在施加加温这个条件后，冰又能变成液态水，在继续加温后，又能变成水蒸气。
说人话呢这个东西就是某物体、某程序功能，会被不同的条件动作触发产生变化，从而形成一种新的状态或者结果（也可能保持不变）；
一般来说程序中的这些变化的状态，肯定是有限的，所以我们也叫有限状态机，正因为是有限的我们才有分析的可能性；
既然是有限的状态，那我们就可以将任何程序采用此思想，将其抽象出一个个的状态；
然后提炼出触发的各种条件，通过在不同状态之间施加不同的触发条件，就能让这些状态不断变化，从而完成我们对程序的不同路径的覆盖；
通过上面的示意图我们也是能很容易去理解这个点的，之所以E2E用例的编写需要去采用这种思维呢，主要就是模拟用户日常可能会触发的各种点，只要我们能触碰到他们会触发的各种操作行为，了解到他们企图达到的最终状态，那我们的验收用例就是有意义的。
将上面水的状态变化类比到我们软件产品中来，就是这么个意思：
拿到某个功能模块时，可以选择一个最基础的入口作为起点（现态）；
确定起点后，可以分析有哪些条件可以来施加，也就是从这个起点开始，有哪些后续的功能按钮可以操作？
分别操作这些功能按钮后，会跳转到哪个模块或者页面（次态）？
依照上述思路，针对这些次态继续分析可以施加的条件（可点击的功能按钮），继续往下发觉后续的状态；
当分析到最后发现已经没有新的状态可以产生了，那就说明这条路径已经走到头，此时就可以结束了；
如果发现不同状态之间会存在循环，那么我们可以保证完成一次循环即可（比如：固态=》液态=》气态=》液态=》固态）；
如果发现在某一个次态时，会产生多分支时，那么就需要单独分析每个分支，直到每个分支都走到头才结束；
针对不同的分支我们就可以梳理出不同的场景用例来。

从一线人员获取灵感

大多数同学可能觉得到这里任务就该结束了，实际上上面的所有行为都是我们自己通过功能分析构造的一些场景，仍旧会存在遗漏点，每个人的思维都是存在局限性的，如果条件允许的话，我们可以进一步与一线人员甚至直接用户进行交流，来获取其真实日常是如何开展的，从而获取到最为真实客观的使用场景信息。

获取一线用户的真实场景信息并不是所有项目都具备的条件，但条件具备时就一定要充分利用起来；
如果没有此条件，我们也可以主动创造，可以主动申请出差客户现场，进行有效信息的获取；
与一线人员、产品经理进行日常有效交流，从交谈中挖掘有效信息，都是可以帮助到我们丰富场景的；
通过上述各种途径获取到的信息，则可以转化成用例，作为有效的覆盖条件。

过程验收&抽验的遗漏补充

怎么还没完没了了？
到此还没结束？
当然，因为前期我们的所有行为都是纸上谈兵（做的策略分析），老话说的好，纸上得来终觉浅，绝知此事要躬行，事情还得自己“弯着腰”去做啊……
在验收的整个生命周期中，我们的时间跨度是非常大的，在前期用例全部编写完成后，还有很长一段时间，此期间伴随着迭代版本的提测，内部测试的测试，验收的抽验，等等过程，
此阶段我们是有机会接触真实的产品形态，也能够去实践之前的策略性动作，在这个过程中，是能够发现一些遗漏点，或者过程性不完善的地方。

在过程验收或者抽验阶段，发现的一些遗漏点，需要及时的补充到场景用例中；
发现的一些不合理的地方，需要及时优化调整用例的执行步骤等内容；
对于内部测试发现的BUG分布较多，已经识别风险较大的模块，则需要针对性的增加用例密度，提高用例覆盖粒度，做出针对性预防；–BUG都是集中产生的，容易长虫子的地方，他就会成批成批的长，不用去怀疑这个规律；
过程中发现内部测试狙击不足的模块或者方向，也需要我们针对性的提高预防措施，增加用例密度，明知道前面的兄弟没守住，已经有鬼子进村了，还不做好彻底的预防，那是我们的失职；
上述的策略都是在实战中逐步调整完善，进一步巩固我们的武器装备，布好天罗地网，从而在验收阶段真正做到胸有成竹。
此时思维导图框架大概是这么个样子：

转换成用例

实际上在上面过程中就有可能已经完成了用例的转换，所以此阶段并不一定是在最后，我们对于用例的补充和思维导图的维护应该是同步的，避免用例有更新，思维导图有缺失，真正在后续去评审和讲解时都是拿思维导图来展示，用例很难逐条去评审，拿用例评审是无法有效知道是否有遗漏，只能评审用例的规范与否，但思维导图则可以方便点的查看是否针对某个模块有遗漏的场景。
如何编写转换成最终的用例则不在此文中做讲解，针对用例的编写可以单独进行分享，此文默认大家都能够有效的转换编写用例。

质检

在实际生产过程中，都有一个质检环节，我们的工作也不例外，此环节与各位的职位级别、能力无关，再牛皮的人都有出错的时候，那么质检的这个动作我们一定要实施。

实际上就是我们的评审过程，当局者迷，有时候就会迷在自己的思维中，而其他评审角色就能够从一些意想不到的角度提出遗漏和不足的地方，以便帮助我们进一步完善分析和用例内容；
永远不要迷恋自己的想法，不要相信自己的分析是完善的，在分析过程中，永远多敲一个回车，预留待填写的空间……
有效的评审能够避免后期的不足，重视此过程是对我们对项目的负责。