软件测试流程（重中之重）。

企业中的软件测试流程就是按照这个步骤来实施的。

软件测试流程的阶段包括：需求分析---编写测试计划---提取测试点---设计测试用例----搭建测试环境----冒烟测试----执行测试---缺陷管理与跟踪---测试报告。

目前学习的软件功能测试项目的实施是依据软件测试流程来开展的。

每个测试流程阶段都需要有对应的交付结果输出物。

最终测试项目实施课程需要输入测试流程各阶段的成绩---平时成绩考核。

学习软件测试流程的目的：是为更好地了解互联网企业中是如何来开展软件测试工作的，帮助我们提前了解企业中的测试过程与步骤。

流程阶段详解：需求分析：指的是对产品经理编写的需求规格说明书进行分析、评审，发现需求中存在的缺陷或者bug。

需求文档的编写者：产品经理，所以发现需求层面的bug需要找产品经理进行确认。

产品、开发、测试、项目经理等项目组相关干系人一起参与评审。

评审的目的：发现需求当中的问题，及时提出需求问题，让产品经理帮助解答。

需求评审：需要确定开发完成时间、测试完成时间、产品上线时间。

在需求评审发起之前，需要与开发负责人、测试负责人、产品相关人员沟通需求评审的时间，需求内容需要提前通过邮件的方式发送给项目组成员，提前分析需求，记录需要存在的问题，需求时让产品经理给予解决方案。

需求评审结果分：通过与不通过，如果需求评审不通过需要进行二次评审，需求通过开发与测试执行产品相关研发与测试活动过程事项。

如果在小公司没有需求文档你怎么去测试？

产品编写需求文档 或者测试人员编写需求文档，在已有产品的基础上提炼需求，没有什么文档时你能创造的价值就是通过自己的能力来展现。

测试文档的测试是没有依据，会导致做很多无效的测试。

测试组负责人设计测试计划。

我们的ecshop项目的实施是由组长负责编写测试计划。

什么是测试计划？指的是在实施软件测试之前需要做的测试任务工作的安排。例如：编写测试点与测试用例、准备测试数据、用例评审、执行测试、缺陷管理与跟踪等相关的测试活动过程都属于测试计划的范围内。

测试计划的负责人注意事项：

1、负责测试工作任务的安排。

2、负责产品测试时间的评估（产品共需要5天时间测试）

3、测试环境的准备（硬件、软件环境），如果是性能测试需要性能测试环境，如果是功能测试-功能测试环境。

为什么性能测试环境要与功能环境测试分开 ？性能是基于多并发的--如果出现性能测试系统会崩溃，功能测试与性能测试在同一个环境会影响测试工作的实施的。

相当于系统崩溃，功能测试员无法开展工作，等待开发人员修复环境后才能实施测试工作。

测试为什么要分QA 、UAT、PRE、 PRD ，因为不同的环境资源配置不同，出现的问题也不同，为更好的模拟真实用户的使用。

4、组长分配测试任务时：要根据组员个人能力去分配，也就是复杂的业务与简单的业务根据组员的能力分配，分配任务将相类似的模块分配给同一个人。

测试计划的编写者一般是需要具备一定项目经验的人才能将计划做得更准确。

5、需要对资源进行协调：如果项目组中存在资源欠缺需要组长对资源进行协调，组长需要对整个项目的进度负责，考核组员的工作完成结果。

6、测试时间的评估、阶段性的准入规则，例如：第一轮测试发现了90%的bug，在进入第二轮测试之前需要将第一轮测试的bug解决掉再进行二轮测试。

总结：什么人在什么时间完成了什么事。

编写测试用例：将需求的功能点设计成一条条测试用例，覆盖所有的需求功能点。

设计用例的注意事项：根据软件测试的原则，设计用例时需要覆盖合理的输入和不合理的输入。

用例设计完成需要根据要求进行检查，分析自己编写的用例是否存在遗漏，进行内审--自己写好的用例在测试组内进行评审，再进一步与开发、产品、测试人员一起评审。

用例要在系统上线之前提前2天完成。

编写的用例包括两部分内容：冒烟用例、详细的用例。

冒烟用例用来测试主流程的用例，开发人员需要根据测试人员提供的冒烟用例验证自己研发的功能进行验收。

冒烟用例子设计正常的场景。

用例评审：针对于组员编写的用例以会议组织的形式开展评审，评审用例的目的是为了发现需求项是否存在遗漏，如果评审过程中发现有需求项未被覆盖，可以提前发现问题及时补充用例。

用例评审的参与人：产品经理、开发、测试。

用例评审发起人：项目负责人

参与人：产品经理、研发人员、测试人员、项目经理

发起之前需要与开发人员、产品经理对评审的时间进行沟通确认。

提前通过邮件的方式将用例提前发布出去，告诉开发完成了那些模块的用例，让他们提前有时间可以做分析。

执行用例评审，负责编写用例模块的人员需要对用例进行宣讲。

评审需要测试人员及时记录评审过程中的问题，如果有发现需求明确的直接与产品经理进行沟通给予解决问题。

评审结果：通过 或者不通过 ，通过的用例纳入版本库，不通过的用例需要会议后进行补充。

编写用例的目的：覆盖需求项，如果不写用例会带来什么问题？一个好好的用例能够发现至今尚未发现的问题，一般来说软件当中的80%的bug来源于需求与设计阶段。

好的用例能够指导测试人员合理地执行测试工作。

搭建测试环境

因为所有的需求项都需要基于测试环境来完成测试，优先有环境才能开展软件测试工作。

冒烟测试---测试开发移交的主流程是否能正常执行通过。

执行测试用例

执行测试的过程检验需求项是否满足用户要求。

执行用例的个数占比，例如：100条用例 ，一天内执行90%的用例，还有10%的用例受阻塞。

bug缺陷管理

bug需要使用缺陷管理工具来进行管理，缺陷管理工具最常用的禅道和tapd---专门用来管理用例 和bug一样，开发、产品用来管理项目进度与需求。

提交bug，开发修复bug，测试验证bug，每日需要输出测试日报---就是你今天做了那么工作内容，工作的进展怎么样，发现了那些问题，质量方面是否存在风险。

测试报告----能够更好地体现软件产品的质量。

测试报告包括哪些内容：用例数，通过数、失败数、测试风险，缺陷优先级别个数统计、参与人、测试类型、经验总结、测试的需求项、什么项目名称、冒烟测试通过率。

一份好的测试报告能够将测试团队的工作展现得更漂亮，汇报非常重复

测试人员通过报告能够了解开发人员的程序代码质量与产品质量。

测试人员通过报告也能分析缺陷与需求的覆盖面。

测试报告对客户是一种质量保障

测试报告分两种情况 ：对内与对外。

对外使用word文档来编写更规范，对内一般使用excel表示进行设计。

测试报告的数据来源开禅道工具或者TAPD.

测试报告的数据是由于测试过程产生的。

体检报告----从每一项的检测中得出。