理论知识
1.B/S和C/S的区别
B/S 只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,需要针对性的开发,并且维护成本高
-------------------------分割线----------------------------
2.HTTP协议
http请求由三部分组成，分别是：请求行、消息报头、请求正文
HTTP（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。
1、常用的HTTP方法有哪些？
GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器。
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URI支持的HTTP方法。
-------------------------分割线----------------------------
3.POST与GET区别
- Get是不安全的，因为在传输过程，数据被放在请求的URL中；Post的所有操作对用户来说都是不可见的。 2. Get传送的数据量较小，这主要是因为受URL长度限制；Post传送的数据量较大，一般被默认为不受限制。 3. Get限制Form表单的数据集的值必须为ASCII字符；而Post支持整个ISO10646字符集。 4. Get执行效率却比Post方法好。Get是form提交的默认方法。
-------------------------分割线----------------------------
4.Cookie和Session的区别与联系
1.存储位置不同
1，session 在服务器端，cookie 在客户端（浏览器）
2，session 默认被存在在服务器的一个文件里（不是内存）
3，session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）
4，session 可以放在 文件、数据库、或内存中都可以。
5，用户验证这种场合一般会用 session
-------------------------分割线----------------------------
5.测试的目的
测试人员的工作是通过各种手段，发现和找出软件的缺陷。最直接的作用就是确保了开发人员的错误能够被尽早快速的发现，确保软件是符合产品经理设计的。
测试工作的最终目的是确保软件的质量，确保用户能够使用到质量优秀的软件，并且测试的时候，是站在用户的角度考虑软件的质量和性能。
-------------------------分割线----------------------------
6.软件测试的原则 - 测试显示软件存在缺陷
- 穷尽测试是不可能的
- 测试尽早介入
- 缺陷集群性（2/8原则）
- 杀虫剂悖论
6.测试活动依赖于测试内容
7.没有错误是好是谬论
-------------------------分割线----------------------------
7.软件测试分为哪几个阶段？
一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试
-------------------------分割线----------------------------
8.单元测试与集成测试的侧重点
单元测试:单元测试（又称为模块测试）是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
集成测试的侧重点：验证了2个或多个单元之间的集成是否正确,并有针对性地对详细设计中所定义的各单元之间的接口进行检查;
-------------------------分割线----------------------------
9.系统测试范围
**一、系统测试主要内容
1、系统测试的过程：计划-->设计-->实现-->执行
2、被测对象： xxxxxx系统
3、测试被测对象的版本：例如V1.0
4、做的是什么测试： 系统测试 ，针对的是整个软件，采用黑盒测试
5、依据：SRS
6、测试过程中用到的管理工具： SVN、bugfree、excel等
7、测试人员的角色：测试经理、测试组长、高级测试人员、中级测试人员、初级测试人员
二、测试计划
制定一份系统测试的计划
1、制定计划的作用
a、制定好的计划，使整个测试工作受控，能够很好的做到按期按质的去完成测试工作，如期交付；
b、制定好的计划，如果发生意外状况，可以在原有计划上做出微调，让测试工作再次进入受控状态；
c、制定好的计划，开发可以根据计划预留出时间来协助测试的工作。
d、使每个人都清楚自己的职责；
2、计划中包含的内容
a、核心内容：分工、进度把控，3w：what、when、who
b、6要素：
what：什么？ 明确测试范围
when：时间？ 包括开始时间和结束时间；例如：什么时候写用例、什么时候执行、什么时候回归等
who：人？ 谁负责做哪些工作
分工、进度把控：在什么时间由谁来做什么事情
why：为什么？ 测试的目标
where：在哪里测试？测试环境
how： 怎样做？具体测试的方法； 例如：人工测试、自动化测试
三、设计
制定一份测试方案
方案的核心内容：用来指导后期的用例设计和执行的工作
对设计具体细化
四、 实现
写测试用例
用例的核心要素：
用例编号：
用例标题：概括；通过这个标题能看出来用例测试什么即可
等级：高 中 低
预置条件： 执行用例的前提准备
操作步骤： 具体的步骤；
预期结果： 执行完之后应该得到的正确结果 （根据需求）
五、执行
1、搭建测试环境
a、得知道怎么连接（组网图）、环境中包含东西
b、被测对象：B/S OR C/S架构的系统
B/S:browser server 有客户端（游览器）和服务端
C/S：client server 客户端（需要额外的装一个客户端软件）和服务端
c、环境中包含的东西：硬件、软件（os、web服务器、数据库等等）、被测对象（oscommerce）、测试工具（浏览器）
d、客户端： 只需要浏览器 还是需要安装客户端
服务端：硬件、操作系统、在操作系统上部署的软件
e、环境的分类
主环境和辅环境： 知道在不同的环境上做的测试分别是什么
主环境：做全覆盖的测试；（覆盖所有的模块，覆盖功能、性能、兼容性、易用性等等）
辅环境：只做兼容性测试（首页界面正常显示，基本功能用起来没问题）
f、 真实环境（用户那边的）和模拟环境（测试环境）： 尽量避免环境差异带来的影响；
2、预测试
也称冒烟测试
先执行基本功能用例，如果基本功能用例没问题，再测试其他地方，如果基本功能用例执行失败，不测试，直接打回给开发
3、正式执行：按照用例执行即可
4、缺陷的跟踪
a、缺陷管理系统
b、缺陷的要素：
缺陷编号：
缺陷标题：
缺陷的详细描述：
测试环境：
用例标题：直接用例复制粘贴
操作步骤：
预期结果：
实际结果：
缺陷的严重级别：
缺陷的复现频率：
5.回归测试
部分回归和全部回归
六、输出测试报告
将测试的结果整理成报告输出
七、系统测试其他内容
1、测试流程： 熟悉需求（srs）——计划（安排工作，定好进度）——方案（指导后期的工作）——用例——执行（搭环境、预测试、正式执行、缺陷的跟踪）——测试报告
2、 系统测试：针对整个软件的测试，是以界面作为入口进行的测试；做系统测试时需要结合被测对象、测试数据等信息在环境上进行一系列的测试
系列测试：功能测试、性能测试、GUI测试、易用性测试、配置测试、安装测试、可靠性测试等等
3、系列测试
功能测试关注的是软件的正常使用
性能测试关注的是软件的承压能力，往往跟并发量相关
GUI测试关注的是软件的界面
易用性测试关注的是软件使用起来要方便，关注用户的体验
兼容性测试关注的是软件要在不同的环境下都能正常
配置测试：跟环境相关，测试软件在不同的环境都能正常使用
安装测试关注的是软件要能正常安装上
可靠性测试**
-------------------------分割线----------------------------
10.a测试与ß测试的区别
-
α测试
就是把用户请到公司内部进行测试使用。
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；
目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
注意！α测试不能由程序员或测试员完成。 -
β测试
用户在不同场所进行测试。
β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。
3.区别
它们都是验收测试！
α测试是指把用户请到开发方的场所来测试
β测试是指在一个或多个用户的场所进行的测试。
α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。
α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长
-------------------------分割线----------------------------
11.验收测试怎么做？
测试步骤：
制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
建立测试环境，设计测试用例，并经过评审。
准备测试数据，执行测试用例，记录测试结果。
分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。 测试项目通过； 测试项目没有通过，并且不存在变通方法，需要很大的修改； 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进； 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
提交测试报告。
验收标准和注意事项：
验收测试完成标准: 完全执行了验收测试计划中的每个测试用例。
在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待下一版本中修改。
完成软件验收测试报告。
注意事项：
必须编写正式的、单独的验收测试报告
验收测试必须在实际用户运行环境中进行 由用户和测试部门共同执行。
如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行。
-------------------------分割线----------------------------
12.白盒、黑盒和灰盒测试区别
一、黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试方法：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
二、白盒测试
白盒测试也称为结构测试或逻辑驱动测试。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。
白盒测试方法：主要有代码检查法、逻辑覆盖法(语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖)、基本路径测试法。
白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。
三、灰盒测试
灰盒测试是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于 集成测试 阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
-------------------------分割线----------------------------
13.冒烟测试的目的
冒烟测试的目的就是为了减小 软件的测试成本！试想一下，如果完成的一个版本，不去做冒烟测试，而是直接去做余下的测试，做着做着发现做不下去了，因为测试过程中发现最基本的业务功能模块都存在bug，更别说相关的其他功能模块了，更别说集成测试等其他测试了，而bug发现的越早其修复bug所耗费的成本越低，如果不做冒烟测试，可以想象成本代价风险多高！
-------------------------分割线----------------------------
14.回归测试怎么做？
回归测试我有两层理解，一是就是当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是当一个新版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有bug！其实回归测试用的很多，比如新增加一个功能模块等等，所以动化测试可以高效率的进行回归测试。
-------------------------分割线----------------------------
15.全部回归与部分回归的区别？
全部回归:对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了。
部分回归:当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
-------------------------分割线----------------------------
16.需求分析的目的
找出来需求，实现这个需求，产品价值最大，可能就会涉及到，判断需求对产品的价值是什么对用户的价值是什么开发成本大吗需求的前后置条件等由此来判断需求的价值和优先级；等优先级确认后，就得出现阶段要做哪些需求，然后需要拆解需求，感觉拆解需求也算是需求分析的一部分；拆解需求，明确核心需求和场景，确定需要哪些功能来满足该需求，为产品设计提供依据
-------------------------分割线----------------------------
17.测试计划的目的
1.尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。
2.所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。
3.测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。
-------------------------分割线----------------------------
18.什么时候开始写测试计划
软件需求分析阶段就开始，因为从这个时候就要进行需求测试了。
在测试项目确定了之后，无论测试需求是否到位都要开始做了
-------------------------分割线----------------------------
19.由谁来编写测试计划
一般都是由测试经理或者测试组长来编写
-------------------------分割线----------------------------
20.测试计划的内容
1、 测试目标：对测试目标进行简要的描述。
2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4、 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5、 质量目标：制定测试软件的产品质量目标和软件测试目标。
6、 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7、 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8、 测试策略：制定测试整体策略、所使用的测试技术和方法。
9、 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10、 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的
Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。
11、 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。
12、 风险分析：需要考虑测试计划中可能的风险和解决方法。
-------------------------分割线----------------------------
21.结束条件(项目上线的条件)
1、明确上线流程规范要求和实施步骤；
2、确立整体的上线计划时间表，譬如上线前的准备、设置、数据库服务器部署、业务验证、版本切换、流程验证等时间节点安排；
3、申请上线相关权限；
4、做好相应人员的安排；
5、配置好环境等软硬件；
6、准备好上线需求清单功能列表，逐条核对避免遗漏；
7、准备上线检查checklist；
8、上线后跟踪安排。
其次是组织团队开展上线演练规划的评审
1、上线流程规范、实施步骤的评审；
2、上线变更计划的评审；
3、脚本、环境配置、需求清单、关键代码、上线checklist的评审，保证有效性和版本最新。
紧接着就是正式演练前的准备
1、罗列交付需求清单，提交上线申请给相应责任人或通过流程审批；
2、数据库维护脚本、实施步骤、潜在的回退步骤、实施方案，齐备；
3、检查上线质量红线相关的要求，避免违规操作生产环境；
4、上线相关权限验证，确保权限正常可用；
5、人员对齐各自职责，通讯畅通；
6、复查各项配置项设置正确性，环境准备妥当；
7、知会上下游我方上线的安排，提醒潜在影响，规避关联问题。
正式演练
1、比对代码、脚本、包版本、环境版本等配套情况；
2、验证发包正常，验证功能正常，取生产环境代码；
3、检查配置库注释，最后提交的代码无异常，各团队全员所有人对齐各自工作都已结束或已正常准备上线；
4、冻结代码，不允许再做修改，打生产包并checklist检查。
上线部署
1、复查上线checklist都已检查无问题，保证上线不会影响到现有用户（或已提醒停服）；
2、脚本部署，执行；
3、上线验证，发出上线报告；
4、上线后跟踪现网，关注潜在异常，有风险及时处置。
-------------------------分割线----------------------------
22.常见的测试风险
进度风险，质量风险和需求变更
需求阶段
1.产品需求不明确，导致后期版本改动大，沟通成本大
比如: 无需求、需求不完善、需求不清晰
2.产品需求逻辑有漏洞，导致版本上线后影响用户体验
3.需求理解不一致，导致后期版本改动大，沟通成本大
4.需求变更频繁，导致后期版本改动频繁
开发实现阶段
1.代码系统架构设计不足，导致可扩展性不足
2.代码质量差导致缺陷多
3.代码性能兼容差
4.代码没做好注释，修改难度大
测试规划阶段
1.测试方案评估不足，导致测试内容不全、不合理
2.测试计划不合理，导致测试进度紧张
3.测试用例设计不合理，用例设计有遗漏
产品验收阶段
1.开发提测代码质量不合格，无法按预期执行
2.开发提测Demo与产品预期不符，需要重新实现
测试验证阶段
1.测试环境准备不足，无法按预期执行
比如：服务器测试环境未搭建、测试数据未准备、测试工具未准备好等
2.测试环境配置和正式环境配置不同，导致测试结果有误差
3.测试人员能力或经验不足，导致遗漏bug或发现bug时间段较晚
4.项目bug多、修改难度大，导致代码改动范围大，增长项目周期
5.新增需求或需求变更，导致增加开发测试工作量，增长项目周期
6.测试进度把控不足，导致测试进度不满足预期
上线阶段
1.上线预期要求不明确，比如“升级策略不明确、版本放量控制不明确”
2.上线环境准备不足，无法按预期上线
比如：线上数据未准备、线上环境配置未搭建
3.上线相关人员不明确或不能及时到位，导致无法按预期上线
-------------------------分割线----------------------------
23.测试用例的要素
1：用例编号
测试用例编号是由字母和数字组合而成的，用例的编号应该具有唯一性，易识别性，有且于其和测试结果、错误报告等其他文档的链接。这样看到编号就可以知道是做的什么测试，测试的对象是什么，也方便维护
2：测试模块
你现在这个测试用例所测的项目名，可以是测试用例所属的大类，被测需求，被测的模块，或者是被测的单元。
3：用例的标题
测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。
4：测试级别
重要级别分为高中低三等：
高：保证系统基本功能、重要特性、实际使用频率比较高的用例；
中：重要程度介于高和低之间的测试用例；
低：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。
5：测试目的和条件
描述设计此测试用例的目的是什么和执行此测试用例之前需要做的准备。
6:测试输入
测试用例执行时，需要输入的外部信息。
7：操作步骤
执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行
8：预期结果
在检查点上待测功能应有的正常反应、运作或显示。
这就是测试用例的八大要素，也是做测试的基本流程
-------------------------分割线----------------------------
24.测试用例级别的划分
1 –小版本确认测试（Build Verification Tests (BVTs)：也叫做“冒烟测试”，一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。
2 – 高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
3 – 中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例
4 – 低（Lows）：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。
-------------------------分割线----------------------------
25.怎样保证覆盖用户需求？
-
覆盖显性需求
需求文档或原型图上已经标注清楚的功能一定要全部覆盖，通过思维导图工具进行梳理一般都能保证。 -
获取隐含需求
隐含需求的获取是一大难点，但需求就像冰山，露在水面的始终只是极少的一部分。
行业
测试某个产品，要对产品所针对的业务要清楚。一般每个行业都有一定的规范、标准。同时复杂的业务，也会有专门的行业研究。比如电商、物流、ERP、CRM、财务、OA 等系统都有其自身的业务体系。
作为测试人员，测试某个行业的业务，就要学习该行业的业务知识，才能保证测试时能够考虑得更加全面。
竞品分析
竞品也就是同类的产品，需求分析也讲究竞品分析，每个行业都有标杆性的软件，这些软件代表了该领域的高水平设计。那么对这些产品的分析，取长补短，同时也能获取到很多需求中没有描述到的内容。
比如电商，多关注淘宝、京东、拼多多、唯品会等；比如视频，关注优爱腾（优酷、爱奇艺、腾讯）；比如直播，关注斗鱼、虎牙等；比如小视频，关注抖音、快手、美拍等。根据自己的业务类型关注对应领域的产品。简单看看应用商城分类排行榜也就一目了然了。
沟通记录
如果可能收集到产品经理在与客户沟通的原始记录，也能够更好的理解客户的本意。在获知客户本意的基础上，更容易揣摩用户的隐含需求。
站在用户的角度分析
如果可能多与一线的使用终端的用户沟通，可以获取第一手的用户使用流程。可以更好的站在用户的角度去思考。
你作为一个用户，在什么场景下会使用这个产品，使用这个产品是为了达成什么目标，为了达成这个目标会怎么做？
比如一个OA系统中的请假条，用户可能会先有请假的计划，那么会提前申请；也有可能用户需要临时紧急请假；还有生病了，要先请假后提请假申请等各种情况。
通用规范
对于用户体验、界面样式等都有一定的通用规范或者业界都认可的一些方案。那么这些经过检验的内容，也可以帮助我们提高隐含需求的覆盖度。
- 合理使用合适的用例设计方法
常规设计方法
等价类、边界值、流程分析法等常规的用例设计方法自不必说，这是测试人员的基本技能，通过合理的用例设计方法可以有效提高测试用例覆盖度。
历史问题分析
我们常说错误猜测法，由于软件缺陷的免疫性、集中性、反复性，错误猜测法是除教科书式的测试用例设计方法以外最有效的用例设计方法。
但是错误猜测法有一个最大的问题，就是要基于测试经验的积累。没有大量的实际项目经验是难以有效的猜测哪些地方容易出 bug 的。
这里结合经验给大家几点建议：
a. 典型问题：收集每次项目中的典型问题，这些典型问题极具代表性，比如查询功能中的日期范围问题，比如输入为空的判断；
b. 出现频率高的问题：每次项目的测试报告中对高频率的 Bug 进行收集和分析；
c. 线上遗漏问题：客户遗漏问题，往往是测试过程中忽略的问题，极具参考价值，对于测试范围、用例设计的改进有很大的意义。
Bug 管理工具上的 Bug 是一个宝库，好好分析总结收集，会有很多可见或不可见的好处。
- 用例评审
用例评审是保证用例覆盖度的一种制度性的方案。用例评审一般是需求、开发和测试三方参与。
测试思路
测试人员在参与用例评审，通过讲解用例体现每个人的测试思路，这时其他成员可以检验该测试人员有没有测试范围的偏差、测试思路的欠缺等。
通过用例评审及时纠正，可以避免后期测试过程中方向性的错误。
覆盖度
通过用例评审可以借助开发、需求从不同的角度来提高用例的覆盖度。
需求人员可以从业务的角度、用户使用的角度来检验用例的覆盖度；
开发人员可以从设计和编码的角度，为测试人员提供代码逻辑层面的逻辑覆盖。
不同人员负责模块交叉部分
一般在体量较大的项目，都会有多个测试人员协调分工，每人负责一部分模块。这些模块与模块之间都可能存在交互。
如果每个测试人员闭门造车，那么可能就会忽略很多模块之间的交互内容。
通过用例评审，测试人员可以结合互相模块之间交互的地方，检查有没有被忽略的需求点
-------------------------分割线----------------------------
