From ea3714f8db63871aaecdd473e530b1828c1810c0 Mon Sep 17 00:00:00 2001 From: carbon-roasted-xiaofei-chang <2378511410@qq.com> Date: Mon, 20 Sep 2021 08:10:43 +0800 Subject: [PATCH] =?UTF-8?q?1.3.2=E4=B8=AD=E4=B9=9F=E6=8D=A2=E6=88=90?= =?UTF-8?q?=E8=BF=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 7dd8ba4..4708409 100644 --- a/README.md +++ b/README.md @@ -90,39 +90,39 @@ #### 1.2.1 需求定义 **描述：** 定义出本次任务都需要做什么，做成什么样子。 -**参与者：** 产品经理、需求分析师、客户 +**参与者：** 产品经理、需求分析师、客户。 #### 1.2.2 可行性分析 **描述：** 由项目组相关成员去研究需求是否可行，能不能做出来。 -**参与者：** 产品经理、架构师、项目经理、开发人员 +**参与者：** 产品经理、架构师、项目经理、开发人员。 #### 1.2.3 需求分析 **描述：** 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个输入框、每个按钮的样式，输入输出等各项值。 -**参与者：** 产品经理、架构师、项目经理、测试人员/质量管理员(很多公司把这个统称为QA)、开发人员 +**参与者：** 产品经理、架构师、项目经理、测试人员/质量管理员(很多公司把这个统称为QA)、开发人员 。 **输出：**《需求规格说明书》 #### 1.2.4 评审 **描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。 -**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等 +**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等。 #### 1.2.5 设计 **描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。 -**参与者：** 项目经理、架构师、开发人员、测试人员 +**参与者：** 项目经理、架构师、开发人员、测试人员。 #### 1.2.6 编码 **描述：** 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现。 -**参与者：** 开发 +**参与者：** 开发。 #### 1.2.7 提测 **描述：** 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。 -**参与者：** 任务责任人（开发）、测试人员 +**参与者：** 任务责任人（开发）、测试人员。 #### 1.2.8 测试 - 测试需求 @@ -135,13 +135,13 @@ **描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。 -**参与人：** 配置管理人员、测试人员 +**参与人：** 配置管理人员、测试人员。 #### 1.2.10 支持维护 **描述：** 支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。 -**参与人：** 支持维护人员/售后工程师 +**参与人：** 支持维护人员/售后工程师。 ### 1.3 软件测试概述 #### 1.3.1 软件测试定义 @@ -166,7 +166,7 @@ The process of executing a program with the intent of finding errors. 测试是为发现错误而执行程序的过程。 ``` -这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。 +这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，还要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。 4. 1983–1987－评估为主(Evaluation Oriented) -- Gitee