新人求点赞，求评论，各位大佬的评论我会针对进行补充完善内容，谢谢大家

34、浏览器中F12有什么作用

网页中用来打开开发者工具

Ios是使用OC语言开发

原生app：只有安卓能使用，可移植性差

Web app：基于手机的网页

混合app：以上两者都有

明文：直接能看懂的文本内容

加密:：对数据进行处理知道规则的人就看得懂

加密算法：使用算法对数据进行加密（如凯撒加密算法、市面上的MD5）

密钥：一串字符串，起到钥匙的作用

签名：作用是确保数据没有被篡改；一般经过签名的数据都会丢失一部分，是无法被还原的

签名的加密算法是不可逆的算法，所以无法还原；数据库存储的也是金国加密的数据

加密和解密完全对称的加密

凯撒加密算法是典型的对称加密算法

特点：加密解密完全对称、密钥一致；性能好、速度快

要保证对称加密的安全要保证密钥不被泄露，可以通过线下的手段：U盾、加密狗等

互联网不可能在线下进行加密，所以是非常不安全的，互联网公司都是经过网络传输来实现的

（非对称加密算法）可以解决这个问题

非对称加密算法中，把密钥分成了公钥和私钥。其中公钥是指公开的密钥，私钥是指不公开的密钥

解决办法：申请证书： 向权威机构申请证书

SSL认证是一个非常复杂的过程，主要可以认为分成以下几个步骤完成：

客户端发送请求，要与服务器建立HTTPS连接

服务器返回SSL证书和加密算法给客户端

浏览器根据内置的SSL证书验证权威结构来验证SSL证书是否合法、有效

浏览器内部使用对称加密算法生成一个密钥，用于加密传输数据

浏览器使用SSL证书中的公钥即为Pa，加密对称加密算法生成的密钥记为Ra，得到一个Pa(Ra)加密过后的字符

串，然后把它发送给服务器

服务器使用私钥解密Pa(Ra)加密过后的字符串，得到Ra

后期，客户端和服务器都使用Ra加密数据，保证数据的安全性。

TCP三次握手和四次挥手

可以用两个人打电话的过程来理解三次握手，4次挥手

A打电话-----B接电话问A是谁

B说我知道你是谁了问打电话干嘛

4次挥手就是在这三次确定信息的过程中发生的

客户端主动与服务器建立连接

客户端设置SYN序号为1，并发送一个seq序号，seq序号随机产生

服务器将SYN和ACK位置都设置为1，并把客户端的序号+1，表示应答，然后生成自己的随机序号seq

客户端恢复一个ACK，ACK的值是服务器发送的SYN+1

注意：SYN=1，ACK=0是一个连接请求报文的意思。SYN=1,ACK=1是响应报文的意思

客户端发送关闭连接请求FIN=1 和 seq

服务器返回ACK，ACK的值是客户端的seq的值加1

客户端返回ACK，ACK的值是服务器seq的值+1

1. 多选题下列关于HTTP协议的描述，正确的有：(50分)

请求数据包括：请求方法、URL、协议和版本、请求头、请求体

响应数据包括：状态码、状态消息、协议和版本、响应头、响应正文（响应体）

HTTP协议是互联网应用最广泛的协议

HTTP协议能解决实际项目开发当中的所有问题。

HTTP 无需加密，而 HTTPS 对传输的数据进行加密

本篇主要给大家分享一下 BAT 名企测试工程师的职级划分，以及想要晋级需要掌握哪些能力。

1、阿里工程师晋级路线

首先，我们先来看下阿里工程师的晋级路线。阿里是以 Professional 专业度来对工程师进行职级划分的，最高为 P14，也就是马云老师的级别，当然在阿里内部也是独一无二的。

测试及研发的级别大多是从 P4 ~ P10，它们分别是初级工程师、高级工程师，以此类推，一直到研究员。

P4 初级工程师与 P5 高级工程师大多以校招为主，这两个岗位的薪资是比较低的。

社招岗位大多是 P6 与 P7，其中 P6 的年薪大概是 40 万，P7 的年薪大概是 50~70 万，随着级别的提升薪资也水涨船高。

P8 以上的级别大多数则是来自于企业内部培养。

2、腾讯工程师晋级路线

接下来，我们看下腾讯的工程师晋级路线。腾讯主要包括 T1 ~ T6，而每个大级别又划分了 3 个小级别。

从 T2.3 级别到 T3.3 级别是社招主招的，T3.1 级别的年薪能够达到年薪 40 万，T3.2 级别的年薪大概是 50~75 万，以此类推，随着级别的增长薪资也会跟着增长。

从 T4.2 级别开始则以公司内部培养为主了。

3、百度工程师晋级路线

最后，介绍百度工程师的晋级路线。百度没有腾讯划分的那么细，大概从 T1 ~ T10。

社招主招的是从 T4 ~ T7 级别，T5 高级工程师的年薪大概在 30~45 万，T6 资深工程师的年薪大概在 40~60 万，以此类推。

了解完 BAT 的工程师晋级路线，你可以看到三家公司在职级划分和薪资上有一定的对应关系。那么我们如何才能快速的晋级呢，各个级别又需要掌握哪些技能呢？我们以百度工程师胜任力模型做一个简单的剖析。

T3 级别的测试工程师主要来自校招，要求比较基础。而到了 T4 级别除了完成一定的测试工作之外，就要你能够主动的发现系统的一些薄弱环节了，T4 级别需要的技能主要包括：

• 胜任简单子系统的测试和执行测试工作；
• 能够具有较强的系统设计理解能力，
• 能发现简单子系统结构上的薄弱环节，进而制定测试策略；
• 能够依据需求、设计文档进行自动化测试方案的设计、实现，并取得较好效果；
• 在测试技术和工具等方面有一定的视野，工作质量和效率都很高；
• 能主动思考测试方法、自动化方案等存在的缺陷，并设法改进。

而 T5 级别就要求在 T4 的基础上能够有一定的技术评审能力了，需要掌握以下技能：

• 可以胜任子系统级别的测试方案、自动化方案的设计
• 能够合理引进新技术、新工具；
• 能够很好的指导、评审测试工程师的测试工作。

当然更高的级别会有更高的要求，而我们在工作中需要根据自身情况去对应相应的级别，对自己技术能力有一个清晰的认识后，查漏补缺式地学习技能。

如果你不能很好的对自己级别进行一个划分，也不太清楚在日后的晋升中应该注重哪些方面，并且技术学习总是东一啷头西一棒槌。时间花费了不少，能力却没有得到显著的提升。

为了帮助每一位测试开发工程师达到阿里巴巴 P6 级别的技术能力。拉勾教育研究院，联合Tester home 知名测试专家思寒老师团队（霍格沃兹学院）历经 12 个月的精心打磨，正式推出高质量、优服务、强就业的课程【测试开发工程师.名企直推营】，不脱产学习，只需4个多月，结业100%内推，让你涨薪跳槽双管齐下！

通过对互联网数100家公司的用人需求做了深度的调研和整理后，设计了能够满足99%企业用人需求的课程大纲，让你只学有用的，只学企业需要的。

（文末可领取完整学习图谱）

2、拉勾网独家100%内推

拉勾网深耕互联网招聘行业多年，有强大的内推资源，结业100%内推。从真题解析，到简历优化、面试模拟，夯实你求职的每一步。

3、多场景学习，保证学习效果

线上学习、定期评测、班主任监督、作业批改，保障你跟的下来、学得会。

现在3期招生开始，福利补贴活动也正在火热进行中。为了保证学习效果，本期只招生100位，名额有限，（免费领取完整的测试工程师必备技能图谱）

对测试有兴趣的同伴，希望对你有帮助，求点赞求评论

，分享给各位积极向上学习、拼搏的打工人！！！！！！！！！

测试基础需要掌握的知识

下面是一个简单的功能测试流程，后面我们学习的内容都是根据这一条线来学习

首先拿到需求，先熟悉需求，需求评审会议测试人员再进一步熟悉需求，会议结束后根据需求画流程图（wps插件、visio、），理清楚需求的业务流程，一般我们使用xmind工具提取功能点，之后编写测试用例，用例编写完毕后进行用例评审，待开发转测试后，先执行冒烟测试，冒烟通过后，再进行全面的测试工作，伴随缺陷跟踪管理，我们使用禅道工具，待测试通过后，再输出测试报告，联系用户进行UAT验收，最后验收通过后进行上线

冒烟测试是指我们本次测试的产品的核心功能模块和主流程；

1. 冒烟通过的标准：（参考值。每个公司不一样）

阻塞部分不得超过10%

2、曲线管理的工具和流程-----我们工作需要熟悉的管理和办公软件平台

3、测试的4个文档：计划、方案、用例、报告------我们工作的依据和输出的数据总结文档

4、用例的设计方法和编写-----用例是测试人员必备的基础，可以说很重要的技能

1. bug；服务器和客户端；
2. 上线（发布版本）：用户量少；
3. 环境：开发环境、测试环境、用户环境（现网环境、生产环境、真实环境）

1软件的团队组成--项目组

产品团队：和客户谈需求，编写SRS

开发团队：前端人员（ui设计）、后端人员（Java、c语言）

测试团队：功能测试、自动化测试、性能测试

瀑布模型：适用于小项目，当今社会项目不适用

缺点：测试介入时间较晚，发现是最前端的问题，修复成本非常高不利于需求的变更

模型的流程和输出文档：

需求分析---输出需求文档/报告

测试---------输出测试计划/方案/用例/报告

运行维护---输出用户手册/运维手册

原型模型：关注用户需求的正确性

RUP模型：强调了时间性和团队协作性（需要合作能力非常高的团队）

敏捷模型：（就是scrum模型）高度迭代，循序渐进的过程

周期最多一个月，基本2-3周为一个版本

将一个大项目划分为各个小的项目，分批次上线

及时的响应市场的变化----先上线看市场反馈

（上线时如果遇到较严重的bug，需回滚流程，回复上一个版本）

缺点：测试滞后于开发；测试介入较晚

拓展：（单元测试：软件构成的最小单位，叫单元；单元=一个函数，一个方法，一个类

集成测试：单元组合为模块，模块与模块之间能够互通，为集成（菜单为一个模块）

系统测试：系统为很多模块组成系统；可以只做系统，不做单元和集成

增加了对各种文档的测试工作

在前期就介入了测试工作

比V模型较高级，但也属于瀑布模型，使用较少

H模型：测试独立于开发

敏捷测试模型：高度迭代，周期性强，能够及时的响应需求的变更和反馈。

前置测试模型：让验收测试和技术测试保持相互独立

问题一：什么是软件测试：产品是否满足用户的需求

降低产品风险，提高用户的满意度

问题二：软件测试的目的：

1. 发现被测试对象与用户需求之间的差异，即缺陷；
2. 通过测试活动发现并解决缺陷，增加人们对软件质量的信心；
3. 通过测试活动了解被测对象的质量情况，为决策提供数据依据；
4. 通过测试活动积累经验，预防缺陷出现，降低产品失败风险。

软件测试工程师需要具备的技能：严谨、沟通，专业知识

测试通过的标准：公司的标准+用户的体验感

Debug为最详细级别的日志（调试级别的日志）

Error为错误日志，报错的东西较少

Info为详细级别日志

缺陷的别名：错误、bug、缺陷、失效 （统称为bug）

需求产生的bug最多：未沟通，用户说错了

遗漏-----注意隐藏需求（客户认为的常识，开发应该知道的需求）

不满意 等4种情况引起的

1. 需求表述、理解、 编写引起的错误；
2. 系统设计架构引起的错误；
3. 开发过程缺乏有效的沟通及监督，甚至没有沟通或监督；
4. 程序员编写中产生的错误；
5. 软件开发工具本身隐藏的问题；
6. 与用户需求不符，即使软件实现本身无缺陷；
7. 外界应用环境或电磁辐射导致的缺陷。

3.缺陷报告：是提交给开发的流程单

一般用于管理缺陷的工具

内容--怎么写缺陷报告：以禅道为例子

缺陷ID：不重复的序列号（可以不要）

概要描述：缺陷标题（简明扼要的表达）

让别人通过此标题能看出问题的所在（50字内）

发现人：一般指测试人员或者用户

所属版本：一般指当前的版本号，方便定位（版本一般会保留四个周期）

所属模块：一般指大功能或菜单（方便定位）

下级处理人：一般指开发，也有可能是测试组长

修复截止时间：指定修复截止时间，防止开发拖延上线时间

指明具体操作的步骤，以及复现的步骤和实际出现的结果，以及预期的结果——详细

界面报错截图（全屏截图），日志，数据库截图，数据流量包（抓包工具f12，httpwatch，fiddler，wireshark）

缺陷状态--操作流程：

New：测试新建缺陷报告

Open：测试组长核实后打开

Close：测试关闭（测试人员有关闭权）测试核实无误后再关闭

Reopen：没有修复好重新打开

Reject：开发拒绝修复

解释5个流程--正确的缺陷管理流程（bug周期）：

首先测试人员在执行用例的时候发现bug，新建缺陷报告并标记为打开状态，指派给开发，开发不认可时，开发可以驳回操作，测试人员进行关闭或者其他操作。如果开发人员确认是bug，直接进行修改操作，并标记为fix状态指派给测试人员，测试人员进行确认，验证此bug是否修复，如果已经修复完成，直接标记为关闭，如果还未修复完成，再次指派给对应开发并标记为打开状态，直到开发修复完成为止。

其他公司有 高中低级别；致命、严重、一般 提示：较高、高、中、低；A-E级别

致命：软件崩溃，闪退，主功能流程缺陷，内存泄漏等硬件软件无法实现正常功能；

严重：重要功能流程缺陷，或子功能业务流程缺陷；

一般：界面的问题，分支业务的一些bug，或用户一般不容易接触到的业务流程；

提示：界面描述语，错别字，布局规范等。

按照用户经常使用的，涉及到钱的，为严重或致命

一般划分为高中低，1-4；和严重程度一一对应

（如遇开发不修复bug：

可能是环境导致，测试环境有bug，开发环境没有。测试环境接近用户环境。

开发人员认为此bug没有必要修改----优化建议性：先沟通，如果不能说服开发，找产品经理。

需求理解不一致：找产品经理核实具体情况。

开发没有时间修复：催。）

问题2：（如何提交一份高质量的缺陷报告：

详细描述要将具体的复现操作步骤描述清楚；

给与相应的证明资料：界面报错截图（全屏截图），日志，数据库截图，数据流量包；

严格划分严重程度，指定修复截止时间。）

测试人员在禅道中主要执行用例，提交bug，缺陷跟踪，分析统计bug

1. 不可能执行穷尽测试（用例、bug不能保证一定能测试完）提高覆盖度
2. 尽早启动尽早介入：瀑布模型的缺点

界面bug永远高于流程

1. 杀虫剂悖论：习惯性操作（换种新方式操作可阻止习惯导致的bug）
2. 不同的测试活动依赖于不同的测试背景

完整性：每一项需求都必须要实现的功能描述清楚，为开发的设计和而是先这些功能提供所有必要的需求依据

正确性：每一项都必须准确的陈述其要开发的功能

一致性：一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾，或者与项目宣传资料一致

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的

无二义性：对所有需求说明书的读者都只能有一个明确统一的解释

健壮性（容错性）：多考虑异常情况，并作出相应处理

必要性：文件文档的签署

可测试性：每项需求都能通过设计测试用例或其他的验证方法来进行测试

可修改性：每项需求只应在软件需求规格说明书中出现一次。这样更改时易于保持一致性。使用目录表、索引和相互参照列表方法将使用软件需求规格说明书更容易修改

项目需求跟踪矩阵（RTM）：每次修改都会在该文档中填写一次

（需求评审会议：（核心：覆盖度）参与者产品经理、项目经理、开发人员。需求如何实现，对需求的完整性、可行性、实行性惊醒评审；在实际需求分析的时候，针对一些不清楚的地方，还需找产品经理进行核实；害需将具体的逻辑实现方式与产品经理核实）

主要测试的函数、类、方法

对应详细设计文档——LLD

主要测试模块与模块之间的数据交互——接口

对应的文档概要，设计文档——HLD

主要测试整个软件系统，概念上包括的范围很广

来源对应需求规格说明书

整个市场上一般将系统测试理解为功能测试

α测试——内测（是在开发环境下进行的测试，一般开发在场）

β测试——公测（是在用户环境下进行的测试，，一般开发不在场）UAT测试（UAT验收，用户接受度测试）——用户UAT同意之后，签字上线，测试通过后叫UAT

功能测试：专门验证该软件是否按照需求说明说上对软件描述进行

1. 是都有不正确、遗漏或多余的功能
2. 是否满足用户需求和系统设计的隐藏需求
3. 是否对输入做出正确的相应，输出结果是否正确展示

（一般使用黑盒+手工进行测试）

首先验证功能测试，只有在功能测试通过之后再进行其他的测试

性能测试：（很多人用，不卡，白盒测试）

性能测试一般要使用工具——jmeter/LR

一般测试服务端的性能——cpu，硬盘读写，运行内存

在有限的资源下达到性能最高

指标：相应速度、并发量、吞吐量

测试计划阶段：确定测试的时间，测试的范围，测试通过的标准，需要的人力物力，工作量的安排（工作量一般分为人天，一人一天，或人时，一人一小时），风险

一般由测试经理/组长，或测试负责人来编写

输出测试计划，属于管理类文档

测试设计阶段：确定测试的范围，测试的方法，测试的类型，用例设计的方法， 缺陷管理的流程，用例和缺陷等级

输出测试方案（测试策略）属于技术类文档

测试实现阶段：测试环境的搭建，用例的评审，测试数据的准备

输出测试环境，测试用例

测试执行阶段：执行用例，缺陷跟踪回归，输出测试报告（讲的是通过还是不通过）

输出测试报告，缺陷报告

2.相应速度（一般分为二五十的相应时间，一般定义在5秒内），并发数（普通网络系统最高不要超过一千），吞吐量（单位时间传输数据的大小量），TPS，资源

负载：指所有指标正常（在测试时不断的增加用户量）

1. 主要目的是找到系统处理能力极限和性能临界点，便于设定阈值
2. 在超过被测对象性能负荷情况下实施
3. 一般用来了解系统系统容量，或者配合性能调优来使用。

压力：指指标出现报错，会耗尽系统的资源，讲的是持续时间

web系统（bs系统）：操作系统，浏览器，分辨率

客户端系统：操作系统，分辨率，配套软件

安全测试：安全测试验证被测试对象的安全保护机制能否在实际应用中保护系统不受非法侵入，用来保护系统本身数据的完整性和保密性

对密码项进行测试：加密，暗码

App的安全：调取通讯录，摄像头等，访问一些资源

平均故障间隔时间（MTBF）

平均故障修复时间（MTTR）

MTBF越长越好，MTTR越短越好

可用性测试：用户体验感测试

可用性测试一般由两类人实施，一是行业或特定领域内的专家，二是合适的软件系统终端用户

移植测试：更注重硬件方面（如安卓系统）（软件也要遵循移植测试）

实施过程中，从适应性、易安装性、共存性、易替换性等方面进行考虑。

确认测试：测试工程师发现缺陷，开发人员进行修复，生成新的版本时，测试工程师需要确认是否已经成功修复了该缺陷。

回归测试是对已被测试过的程序在修复缺陷后进行的重复测试，目的是验证修复缺陷没有引发新的缺陷问题

回归测试策略有完全回归、部分回归和选择性回归两种

4.缺陷覆盖回归：在实际的回归测试过程中，确认测试与回归测试往往一起执行

优点：能够解决深层次的bug

黑盒：只关注输入和输出，不关注内部逻辑。该测试方法验证被测对象使用质量及外部质量表现。主要是系统测试（功能测试）

(质量及外部质量：1、过程质量：产品是否规范

2、内部质量：内部设计及静态测试是否合格

3、外部质量：产品功能、性能的表现

4、使用质量：在使用过程中的易用性、满意度表现）

优点：1、用户易于接受

2、执行速度快、成本低

缺点：由于仅关注被测对象外部特性表现，对于一些结构性、深层次的问题不易揭露，带来漏测的潜在风险

灰盒就是接口测试（集成测试）

静态：不执行被测对象程序代码

SRS、手册、设计说明书、代码

动态：执行被测对象程序代码

静态黑盒：SRS，手册

静态白盒：代码，设计文档

手工测试：常说的点点点

在测试前期（开发转测试的时候）都是用手工测试

自动化测试：人通过写代码，通过执行代码来模拟人的操作，需要借助工具

用于每次都需要测试的模块，而且此模块未发生改变（一般指核心模块）（回归不一定会用）

遵循杀虫剂悖论【习惯性操作（换种新方式操作可阻止习惯导致的bug）】

自动化并不用于发现新bug，只用于验证通过

接口自动化用于发现新bug

冒烟测试（预测试）：在开发转测试时，首先针对核心业务（或叫主流程业务）进行一次测试，一般时间很短

拿到需求后了解需求的业务逻辑和实现的功能，之后参加需求评审会议，测试根据组长分配的模块进行编写测试方案，后进行方案评审，开发转测试后，针对开发的产品进行冒烟测试，冒烟测试通过后在进行全面测试，期间遇到的bug使用禅道提交，bug 达到标准后编写测试报告，UAT验收后上线

拿到需求--组长测试计划--划分模块--透析需求--设计方案和编写用例--用例评审--开发转测试--冒烟--全面测试--缺陷管理--测试报告--UAT验收--上线

首先测试人员在执行用例的时候发现bug，新建缺陷报告并标记为打开状态，指派给开发，开发不认可时，开发可以驳回操作，测试人员进行关闭或者其他操作。如果开发人员确认是bug，直接进行修改操作，并标记为fix状态指派给测试人员，测试人员进行确认，验证此bug是否修复，如果已经修复完成，直接标记为关闭，如果还未修复完成，再次指派给对应开发并标记为打开状态，直到开发修复完成为止。

1. 瀑布模型和敏捷模型的优缺点：

瀑布：缺点：适用于小项目，出现在的项目基本不适用

测试介入时间较晚，发现是最前端的问题，修复成本非常高

敏捷：优点：高度迭代，循序渐进的过程

将一个大项目划分为各个小的项目，分批次上线

缺点：不注重文档的作用

V、w、h、x、敏捷、前置测试

黑白灰三种测试方向：性能

可用性测试：用户体验感测试

1. 软件测试级别怎么划分，具体描述一下一一对应什么文档，属于那种测试：

α测试——内测（是在开发环境下进行的测试，一般开发在场）

β测试——公测（是在用户环境下进行的测试，，一般开发不在场）

UAT测试（UAT验收，用户接受度测试）——用户UAT同意之后，签字上线，测试通过后叫UAT。

1. 给你一个web系统，你会如何进行测试

1. 可移植性（类似兼容性）

测试用例（测试案例）----测试时使用的一个例子

用例编号（也称用例ID）：

测试项（又称所属模块）

测试标题：验证xxx操作可以/不能xxx

用例属性：功能/性能/兼容/接口/界面

重要级别（优先级）：一般划分为1-4类、或者极高-低，高-低

预置条件：测试所需的条件

操作步骤：（可将测试输入合并）严格按照用户实际的操作，分步骤来写。

预期结果：如果软件没有bug的，将会出现此结果（如有bug，会出现报错，不会出现此结果）

操作步骤和预期结果要一一对应（实际工作可以不遵循）

一般使用excel编写

一条用例只验证一个功能

当限制很多，在测试某一个点时，只考虑这一个点的情况，其他默认满足条件

一般来说，在编写一个模块的用例是，首先写一条冒烟的用例，优先级为：极高。和一条界面显示的用例

一般来说一个模块只有一个冒烟

所有输入框的先写一条输入为空的情况

流程用例的级别一般为中-高；界面的用例级别为低-高

清晰明了，你的用例别人要看的懂

等价类：实际软件测试活动中，保证被测对象测试充分性的最好方法即是使用穷举法完全覆盖、完全组合，针对界面上的输出框之类的测试

离点：靠着上点的点，如果上点在内，离点则在外

判定表：注重条件和结果

布尔值一般假用0表示，真用1表示。或者，F为假，T为真

因果图：从判定表中细化出来的，可以转成判定表，考虑了条件之间的关系

恒等：输入条件发生，则一定会产生对应的输出

非：与恒等关系恰好相反

与：在多个输入条件中，只有输入项发生时，才会产生对应输出

或：多个输入条件中，只要有一个发生，则会产生对应输出，可以多个条件同时成立

异：（互斥）只有一个成立

要求：其中一个出现，下一个必定出现

正价实验：关注各个条件的组合情况

因子：有几个条件成为因子

水平：每个有条件的取值称为水平

状态迁移：适用于业务流程

场景设计：适用于业务流程

备选流：经过备选流程后也能达到正常流程

异常流：单独的一个结果，而且可以容易出bug的地方

相对于状态迁移，多了判断，异常处理，选择处理

语言描述--别人要看懂，要清晰

测试的结果--质量评价（核心）

本次测试活动的具体时间，消耗的资源的统计（人力物力资源），环境

阶段评审定义（管理类）

阶段评审通常从项目的人力资源、物力资源、资金状况、风险、技术、规模、进度等因素评审项目的状态并确定软件生产活动是否可以进行下一阶段

同行评审定义（技术类）

同行评审活动开展得越早越好，便于早期发现缺陷，从而去除缺陷，降低成本和产品或项目风险，提高质量

同行评审与阶段评审的区别

同行评审更侧重于技术实现和工作开发，阶段评审关注于产品或项目的进度管理，通过评审阶段了解项目的进展情况

同行评审时对软件元素进行评审，尽早发现软件元素的缺陷，并且对缺陷管理进行跟踪和分析。阶段评审时对项目不同阶段不同状态进行评审，从而决定是否继续下一个阶段

同行评审可以时正式的会议评审（正规检视、技术评审），也可以时非正式的评审，如代码走查、检视等。阶段评审时正式的会议评审

同行评审主要由项目组成员、具有同等开发专业技能并熟知被评审对象的人员。

阶段评审一般有产品或项目外部用户担任，如用户代表、项目经理、部门经理等