软件测试的理论知识

1、前言

1.1什么是软件测试？

软件测试是一系列过程活动，包括软件需求分析，测试计划分析，测试用例设计，执行测试用例等。它贯穿于整个软件测试的周期，在软件项目的每个阶段，都需要进不同目的的内容的测试活动，以保证各个阶段的正确性。

1.2为什么要进行软件测试？

假如你安装的软件是一个未经测试的软件，那么在使用过程中可能会遇到：软件死机，账号被盗，资金被转等，而软件测试工程师的出现正是为了规避这些问题。

1.3软件研发初期的过程

2.研发模型

2.1 瀑布模型

计划--需求分析--设计--编码--测试--运行和维护

特点：

1. 线性化的研发模型
2. 各阶段具有里程碑的特征
3. 基于文档的驱动
4. 严格的阶段评审机制

优点：

1. 有利于大型软件研发过程中的人员组织和管理
2. 有利于开发方法和工具的使用
3. 提高了软件的质量和效率

缺点：

1. 不灵活

2.2 V模型

用户需求--需求分析--概要设计--详细设计--编码--单元测试--集成测试--系统测试--验收测试

优点：

1. 软件测试分为若干个级别，更能提高软件的质量
2. 软件测试和开发级别一一对应

缺点：

１.忽略了软件测试对象不止有程序还包括文档

２.验收测试是最后阶段，需求阶段的问题只能到验收阶段才能发现

2.3 W模型

优点：

1. w模型，又称双v模型，测试活动和开发活动同步进行
2. 软件测试的对象不仅仅是程序，还包括文档
3. 尽早投入测试可以降低开发成本

缺点：

无法迭代，指的相对的，不是绝对的

2.4 X模型

1. 最早引用探索性测试的研发模型
2. 软件分为几个片区，然后集成在一起形成最终的软件

2.5 螺旋模型

1. 非线性化的研发模型
2. 引入了风险管理，进行评估

2.6 快速模型

又称原型定义，非线性化研发模型，主要适用于小公司，客户到了最后才知道软件的最终模样，先做一个ｄｏｍｅ（模型或样本），给客户进行产品的预演。

２.７迭代开发

每次只设计和实现产品的一部分，通过逐步完成的方法叫迭代开发，每次设计和实现一个阶段叫迭代

优点：

1. 降低需求变更的成本
2. 得到早期的用户反馈
3. 持续的集成和测试

2.8 敏捷开发

敏捷开发以用户需求进化为核心，采用迭代，循序渐进的方法进行软件开发

敏捷开发的核心价值观：

1. 个人交互重于过程和工具（个体交互主要指人和人之间的沟通）
2. 可用的软件重于完备的文档
3. 客户协作重于合同谈判
4. 响应变化重于遵循计划

优点：

敏捷确实是项目进入实质的迭代阶段，用户很快可用看到一个基本架构版的产品，敏捷注重市场快速反应能力

缺点：

敏捷注重人员的沟通，忽略了文档的重要性，若项目人员流动太大，又给维护带来了不少难度，特别是项目中新员工比较多，老员工比较累。

tips：

敏捷和迭代虽然不一样，但是他们是分不开的，迭代开发和敏捷开发的结合，既保证了产品的质量又在项目产品的持续改进中具有一定的优势，吸取精华，剔除糟粕，只有这样，项目才会达到趋近完美的程度。

2.9 软件的生命周期

需求--设计--编码--测试--维护--升级--废弃

2.11 项目中的成员

1. 项目经理（PM）
2. 架构师
3. 程序员（码农）
4. 软件测试工程师：初级、中级、高级、技术专家、测试经理、交付经理、部门经理
5. 资料工程师（大公司才有）
6. 配置管理员（CMO）
7. QA（大公司才有）
8. 产品经理（BA）
9. UI设计（界面设计）
10. DBA（数据库管理员）

3.软件测试基础

3.1 软件测试的定义

在规定条件下操作程序，发现缺陷，评估软件质量

3.2 软件测试的目的

尽可能多的发现软件的缺陷，预防缺陷，对软件的质量进行评估，以提高软件的质量

3.3 软件测试的范围或对象

程序、文档、数据

3.4 软件测试的原则

1. 所有的测试都应该追溯到用户需求

   需求是软件测试的依据

2. 应当把尽早测试和不断测试作为软件测试的座右铭

   尽早测试能够降低开发成本不断测试更能提高软件的质量

3. 完全测试是不可能的，测试需要终止

   出于成本考虑和现实考虑

4. 软件测试无法显示潜在缺陷

   缺陷有时候需要在特定的情况下才会出现

5. 充分注意群集现象

   二八原则，80%的缺陷出现在20%的模块上，发现bug越多的模块，残留的bug越多

6. 避免程序员检查自己的程序

   开发沿用之前的开发思路，去找问题很难发现问题

7. ``避免软件测试的随机性`

   测试需要计划，节约成本和人力

3.5 软件测试的风险

进度风险，质量风险，人员风险，成本风险，变更风险

3.6 测试工程师所具备的素质

综合素质：

1. 细心，耐心，责任心，自信心
2. 沟通能力，语言以及文字表达能力
3. 团队协作的能力
4. 发现问题的敏锐程度以及观察能力
5. 逻辑思维能力和发散性思维能力
6. 具有丰富的软件测试经验

专业素质：

1. 熟悉软件研发流程以及测试流程的知识
2. 熟悉软件测试理论知识
3. 掌握测试工具，管理工具，自动化工具，集成工具，性能工具，安全工具…
4. 计算机相关知识，数据库，操作系统，网络基础，开发语言

4.软件测试的分类

4.1 按照阶段 阶段划分

单元测试--集成测试--系统测试--验收测试

1. 单元测试

1. 对于软件中最小可测单元进行检查和验证：如：java中的类，C语言中的函数，UI界面
2. 依据：详细设计
3. 谁测试：90%是开发人员测试，因为必须具有代码阅读能力
4. 单元测试能够发现80% 左右的缺陷
5. 单元测试工具：java语言中的junit，python语言中的unittest，pytest
6. 侧重于检查程序内部结构，逻辑控制和异常处理

2. 集成测试

1. 在单元测试基础上，把模块组装成系统或者子系统，然后进行测试，又称联合测试，组装测 试
2. 依据：概要设计
3. 谁来做：软件测试工程师
4. 侧重于检查模块与模块之间以及接口传递数据的正确性
5. 分类：
   1. 非增量式集成：又称一次性集成
   2. 增量式集成：
      自顶向下增量式集成需要编写：测试桩
      自底向上增量式集成需要编写：驱动程序

3. 系统测试

1. 将软件，硬件，网络等设备连接系统进行测试
2. 依据：需求规格说明书（产品经理编写的需求文档）

分类和范围

1. 功能测试：测试软件的功能是否正常实现
2. 性能测试：测试系统所消耗的时间和资源
3. 压力测试：系统在什么情况下会达到极限
4. 容量测试：测试系统最大的访问用户数
5. 安全测试：验证系统是否容易被攻击
6. 可用性测试：验证系统使用是否方便
7. GUI测试：界面测试
8. 安装测试：安装和卸载
9. 异常测试：检查系统对于异常情况下的处理
10. 配置测试：测试系统软件和硬件的最优配置
11. 备份测试：系统的数据备份
12. 健壮性测试：用于测试系统出现故障时，是否能够自动恢复或者忽
13. 文档测试：测试帮助文档
14. 在线帮助测试：联系产品的售后客服
15. 网络测试：不同网络下的使用情况：5g，4g，3g，2g，wifi
16. 稳定性测试：软件长时间运行，系统是否能够正常运行

4. 验收测试

   依据：用户需求，需要用户参与
   分类：
   正式验收测试 非正式验收测试 阿尔法测试(α测试）和贝塔测试（β测试）
   阿尔法测试和贝塔测试的区别：
   阿尔法测试是由公司内部人员测试，贝塔测试是由典型用户测试
   阿尔法测试遇到bug可以控制，贝塔测试遇到bug不可控
   阿尔法测试使用的是测试环境，贝塔测试使用的是现网环境，又称线上环境，公网环境，生产环境
   阿尔法测试发现问题能够及时修复，贝塔测试需要统一收集然后集中修复

4.2 按照是否运行程序 划分

动态测试：运行被测试的软件

静态测试：静态去查看文档，或者代码走查，代码审查

4.3 按照技术 技术划分

黑盒测试：不关注软件的内部逻辑结构，只关注输入和输出，关注功能和性能，适用于系统测试和验收测试

白盒测试：与黑盒测试相反，适用于单元测试

灰盒测试：介于白盒测试和黑盒测试之间，适合用于集成测试，接口测试

4.4 其他测试

1. 回归测试：执行上个版本的用例，查看bug是否修复，或者修复bug是否引入新的问题
2. 冒烟测试：又称BVT测试或者预测试，在正式测试之前，抽取项目中基本流程用例（大概10%左右），全部执行通过，如果冒烟测试不通过，项目直接打回，冒烟测试之前需要安装测试环境，测试时间半天至一天
3. 兼容性测试：将软件运行在不同的设备上，保证软件在各种设备上均提供正常的服务，如web测试不同的浏览器，app测试不同型号的手机

5.需求分析

5.1 什么是需求分析

主要是解决测试什么的问题，明确测试的地方

以需求规格说明书为基础，进行细化和分解

5.2 需求分析的范围

主要指的是明确和隐含的需求

5.3 需求分析的责任人和时间

谁来做：有经验的软件测试工程师

需求分析的时间：通常占项目周期的10%-20% 左右的时间（工作日）

5.4 需求分析的文档和工具

输出的文档：测试需求分析文档（测试点）

工具:mindmanager，xmind

5.5 需求分析的评审人员

组内的软件测试工程师，产品经理，开发代表，测试经理，项目经理，QA

5.6 需求分析的特征

需求项必须是可核实的

需求分析需要指出正确条件和错误条件

需求分析不包含具体数据

5.7 需求分析的方法

测试要点，测试类型，功能交互，质量特性

5.8 需求分析的过程

5.9 需求分析举例

5.10 常见的测试点

5.10.1.登录

5.10.2 删除

5.10.3 修改密码

5.10.4 新增

5.10.5 验证码

5.10.6 查询

5.10.7 翻页

5.10.8 统计

5.10.9 日历控件

5.10.10 导入

5.10.11 导出

5.10.12 支付

6. 测试计划

6.1 编写人和时间

编写人：测试经理或者测试组长

编写时间：需求分析完成后，时间2-5天，在整个测试过程中处于不断修改的状态，保证测试计划满足实际需求

6.2 参考依据和读者对象

参考依据：需求分析结果，项目计划

读者对象：

1.上：项目经理

2.中：开发经理，产品经理

3.下：组内的软件测试工程师，组外的其他测试经理

6.3 如何制定测试计划

认真做好测试资料的收集工作，主要收集人和设备

明确测试的目标，主要是时间目标和质量目标

坚持5W原则，明确内容和过程

why：测试的目的

what：测试的范围

when：测试的时间

who：测试的参与人

where：项目中的输出的文档，软件包存放的位置

6.4 测试计划包含哪些内容

项目概述，目的和范围，测试的通过准则，读者对象，测试的参考资料，测试策略，硬件环境，软件环境，启动条件，结束条件，测试周期，人力投入，任务分配以及进度安排，测试风险

6.4.1 测试策略

又称测试类型，主要指的是冒烟测试，功能测试，回归测试，兼容性测试，性能测试，接口测试，安全性测试…

6.4.2 测试的启动条件和结束条件

启动条件：

1.测试用例编写完成，并通过评审

2.开发编码完成，并通过自测

3.开发提交了转测试申请单以及相关配置

4.测试环境搭建完毕，冒烟测试通过

结束条件：

1.测试任务全部完成，人力投入充分

2.需求覆盖率一般达到100%，测试用例通过率一般达到100%

3.缺陷密度达到预定标准

​ 1.预定标准：高验收标准：3-5个，一般验收标准：6-10个

​ 2.缺陷密度计算方式。缺陷密度=bug总数/中代码量，代码量单位：KLOC，千行

4.bug缺陷呈现正态分布或者收敛状态

5.需求规格说明书中的所有功能全部正确实现

6.交付件齐全，系统测试通过

7.测试方案

7.1 概念

测试方案是对需求分析结果进行细化和分解得到的功能点，主要是解决怎么做的问题

7.2 编写人和时间

时间：测试计划编写完成后，大型项目：两周左右，中小型项目：一周左右

编写人：具有丰富经验的软件测试工程师

tips：

真实项目中大多数公司（90%）没有测试方案，将测试方案和需求分析结果合并一起称为测试设
计，测试方案主要是围绕测试类型进行展开，如：自动化测试，接口测试，性能测试，安全测试…

7.3 评审人

组内软件测试工程师，产品经理，开发代表，测试经理，项目经理，QA

8.测试用例

8.1 概念

测试方案和测试用例均属于测试的设计文档，测试用例描述了输入动作和一个期望结果，目的是确定程序的某个功能是否正常工作的

8.2 参考依据

需求规格说明书，需求分析结果，测试方案

8.3 编写人和时间

编写人：具有丰富经验的软件测试工程师

编写时间：测试方案编写完成并且通过评审，编写时间占整个项目周期30% 左右

8.4 编写的工具和输出的文档

输出的文档：测试用例

编写工具：excel，word，zentao，bugfree，testlink…

8.5 评审人

组内软件测试工程师，开发代表，产品经理，测试经理，项目经理，QA

8.6 用例组成

用例编号，功能模块，标题，优先级，预置条件，操作步骤，预期结果，设计人，设计时间，备注

8.6.1 用例编号

不能重复

格式：项目名-模块名-编号

如：QQ-login-0001

这里的模块指的是一级模块

8.6.2 功能模块

主要是为了方便任务分配，知道用例的所属路径，一般写二级模块，也写三级模块。

如：朋友圈-评论

8.6.3 标题

格式：在什么地方+条件+结果

如：在QQ登录界面，输入正确的用户名密码，登录成功

要求：

1.标题不能重复

2.标题中不能写bug

3.标题不能有歧义。如：是否，大概，也许，可能…

4.标题不能涉及具体数据，具体数据在预置条件和操作步骤中

5.标题和预期结果相呼应

6.标题中没有句号，最多一个逗号（不是必须）

7.标题长度一般不超过24个字（不是必须）

8.6.4 优先级

1.目的是为了测试时间不充分的情况下，按照优先级比例抽取主要功能模块进行执行，如：冒烟
测试，回归测试

2.根据重要性和使用频率来确定用例的优先级，两高得高，两低得低，一高一低得中

3.优先级高中低的比例：1:3:1

4.正常场景用例比异常场景用例高一个级别

8.6.5 预置条件

1.在具体的测试数据之前需要准备的前提条件，如：登录系统，必须提前注册账号

2.包含具体的测试数据

3.测试时需要的环境信息

8.6.6 操作步骤

1.具体的功能界面输入的数据和操作的按钮

2.操作步骤包含的测试数据

8.6.7 预期结果

用例的期望结果，指明测试用例执行后要达到什么样的结果

9.黑盒测试用例的设计方法

9.1 概念

黑盒测试，又称功能测试，数据驱动测试或者基于需求规格说明书的测试，是从用户观点出发的测试

9.2 测试用例的设计要点

1.用最少的测试用例尽可能全面的覆盖所有的需求

2.穷举测试数据太大，完全测试是不可能的，测试需要终止

9.3 等价类

1.定义：把所有可能输入的数据划分为若干部分，然后从子集中抽取少量具有代表性的数据作为测试用例

2.有效等价类：指对程序规格说明书来说是合理的，这些数据的构成的集合称为有效等价类

3.无效等价类：指对程序规格说明书来说不合理无意义的输入数据所构成的集合称为无效等价类

4.划分标准：

​ 1.完备测试：将集合划分成不相交的一组子集，而子集的并集是整个集合

​ 2.避免冗余：子集之间互不相交

5.划分方法：

​ 5.1在输入条件规定了取值范围或者个数的情况下，可以确定一个有效等价类和两个无效等价类

5.2 在输入条件规定了值的集合或者规定了必须如何的情况下，确定一个有效等价类和一个无效等价类

5.3在输入条件是一个布尔值的情况下，可以确定一个有效等价类和一个无效等价类，布尔值：True和False

5.4 在规定了输入数据的一组值，并且程序需要对每一个值分别处理的情况下，可以确定n个有效等价类和一个无效等价类

5.5 在规定了输入的数据必须遵守规则的情况下，可以确定一个有效等价类和n个无效等价类，从不同角度去违反规则

​ 5.6在确定已划分等价类中由于元素在程序处理方式不同的情况下，需要将等价类进一步划分为更小的等价类

6.设计原则

1.为每个等价类规定一个唯一编号

2.设计一个新的用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有的有效等价类都被覆盖为止

3.设计一个新的用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有的无效等价类都被覆盖为止

7.举例

某个系统的注册页面有一个会员名称输入框，该会员名称由字母或者汉字组成，不能包含空格，长度为3-10个字符，一个汉字占一个字符，会员名称不能为空，会员名称不能重复，采用等价类划分方法，对会员名称进行用例设计

9.4 边界值

边界值是对等价类方法的补充

上点：取值范围的端点，不用关注端点取值到底是有效还是无效

离点：取值范围端点的左右两边的值

内点：取值范围大概中间的值

弱覆盖：上点有效，离点无效，上点无效，离点有效

强覆盖：上点+离点

举例：

例题1：某程序有一个输入框，该输入框可以输入整数范围(-32,23】 <==> （-32 请写出需要对应的边界值？

上点：-32,23

离点：-33.-31,22,24

内点：-5

强覆盖：-33，-32，-31,22,23,24

弱覆盖：-32，-31,23,24

例题2：电子称生产商生产了一批电子称，电子称可称重范围是【1.01,100.00），电子称精度为
0.01kg，写出对应的边界值？

上点：1.01,100.00

离点：1.00,1.02,99.99,100.01

内点：50.00

强覆盖：1.01,1.00,1.02,99.99,100.00，100.01

弱覆盖：1.00,1.01,99.99,100.00

9.5 错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而针对性的设计测试用例。如：

1.对于日历控件中考虑闰年的2.29和平年的2.28

2.对于多条相同数据怎样排序

3.密码中加入空格

4.密码不支持拷贝，但是可以在密码输入框中粘贴内容

5.两个用户同时删除同一条数据，一个成功，一个失败

6.不勾选数据，删除数据，应当有相应的提示

7.新增时，考虑数据的唯一性

8.查询数据时，输入通配符，只能查询出包含通配符%和_的数据

9.app软件在使用过程中来电话，软件能够正常使用

10.退出用户登录界面，使用浏览器的返回按钮，不能返回至登录界面

11…

9.6 场景法

场景法又称流程分析法，是将软件系统的某个流程看成路径，使用路径分析的方法来设计测试用例，根据用例顺序依次进行组合，使得流程的各个分支都能覆盖

基本流：主场景，流程的主干

备选流：可选场景，流程的分支

1.开始用例–基本流–结束用例

2.开始用例–基本流–备选流1–结束用例

3.开始用例–基本流–备选流4–结束用例

4.开始用例–基本流–备选流1–备选流2–结束用例

5.开始用例–基本流–备选流3–结束用例

6.开始用例–基本流–备选流3–备选流1–结束用例

7.开始用例–基本流–备选流3–备选流4–结束用例

8.开始用例–基本流–备选流3–备选流1–备选流2–结束用例

例2：

9.7 用例设计方法选择策略

1.对于业务流程清晰的系统，可以采用场景法贯穿整个测试流程（主要用于冒烟测试和回归测试）

2.进行等价类的划分，将无限的测试变为有限

3.然后结合边界值分析方法进行补充

4.然后使用错误推测法追加一些异常的测试用例

10.测试执行

概念：根据编写的测试用例，按照用例步骤进行执行，查看预期结果和实际结果是否一致，如果不一致则为bug（缺陷）

参考依据：测试用例

执行人：软件测试工程师

开始时间：测试用例编写完成并通过评审，且达到测试执行的启动条件

时间周期：占整个项目周期40% 左右时间

测试用例执行过程中时间安排，假设项目周期为三个月（66天），66*40%=26

测试执行分为3轮，时间安排如下：13:8:5-------------------->按照5:3:2的比例进行安排

测试执行分为4轮，时间安排如下：10:8:5:3------------------>按照4:3:2:1 的比例进行安排

10.1 测试用例的执行结果状态

new(未执行)：用例编写完成，未开始执行的状态

pass（通过）：执行用例预期结果和实际结果一致

fail （失败）：执行用例预期结果和实际结果不一致

block（阻塞）：当因为软件有缺陷妨碍了测试用例的执行，并且该缺陷不是该用例的关注点

investigate （观察中）：当用例在执行过程中需要消耗较多的时间来观察期间的结果

10.2 测试执行过程中的注意事项

搭建软件测试环境

测试用例需要全部执行

不要忽视任何偶现的bug

加强测试过程中的记录

提交缺陷和开发关系处理恰当

提交一份优秀的问题报告单

及时更新测试用例

10.3 提交的缺陷开发不认可，怎么处理？

1.首先进行自我检查，依据需求确定该缺陷是否有问题

2.确定是问题，拿出依据与开发人员有理有据的沟通

3.沟通无效，告知测试经理，将问题升级提交项目组变更控制委员会CCB进行裁决是否是
问题

10.4 缺陷的分布特征

1.群集现象（二八定律）

2.测试进行的越多，新缺陷就越难发现，此时需要拓展测试思路，寻找新的突破点

3.并非所有的缺陷都需要修复

​ 1.修复风险太大，不值得修复
​ 2.没有足够的时间进行修复，并且遗留的bug不会影响版本发布新功能

10.5 测试过程中发现bug太多你会怎么处理？

1.冒烟测试进行的不充分，不彻底

2.发现bug越多的模块，残留的缺陷也越多，同时说明开发编码质量太差，会影响到测试的质量
和效率

3.我们需要将版本打回，要求开发人员自测，自测通过后再提交代码

10.6 幽灵（偶现）bug的处理方式？

1.截图，保留证据，必要时录制视频，抓包，查看日志文件

2.在本机进行多次尝试该问题，若能够出现问题，则记录

3.若本机不能重现，在其他电脑上尝试重现是否能够出现

4.在其他电脑上无法重现，但是问题比较严重，找到开发人员进行协助定位

5.对于难以重现的问题，需要将问题单挂起，看后续版本是否存在，后续版本如果不存在，则关
闭

10.7 缺陷的组成

缺陷ID，缺陷标题，缺陷状态，缺陷级别，缺陷优先级，测试版本，测试阶段，缺陷类型，重现步骤（缺陷描述），实际结果，预期结果，缺陷所属模块，提交人，提交时间，修改人，修改时间，关闭时间，附件

1.缺陷ID：缺陷编号，bug管理系统自动生成的编号

2.缺陷标题：对发现的bug通过简洁的文字进行描述

3.缺陷的状态

1. 测试发现问题，使用bug管理工具提单至开发人员，bug状态为 new（新建）
   2.开发打开bug单，确认问题是否存在，bug状态为 open（打开）
   3.开发确认是bug，将bug修复完成后，bug状态为fixed（修复）
   4.开发给出依据确认不是bug，bug状态为 rejected（拒绝）
   5.测试回归bug，验证通过，bug状态为 closed（关闭）
   6.测试同意开发给出不是bug的依据，关闭问题单，bug状态为 closed（关闭）
   7.开发确认测试提交问题是问题，延迟解决，bug状态为pending（挂起）
   8.测试回归bug，验证不通过，bug状态为 reopen（重新打开）

4.缺陷级别
致命：程序的主要功能丧失，闪退，崩溃，报5xx，如：无法注册，无法登录

​ 严重：次要功能没有实现，引发部分功能无法使用，如：无法删除商品，无法新增商品，无法编辑商品

​ 一般：基本功能实现，但是边界值错误，或者某些重要功能异常情况错误

​ 轻微：界面排版错误，系统操作不方便，但是可以使用

5.缺陷优先级：4,3,2,1

6.测试版本：即本次发布新功能的版本号

7.测试阶段：
BVT（build verification testing）：冒烟测试

​ SIT （system integration testing）：系统集成测试

​ UAT（user acceptance testing）：用户验收测试

8.缺陷类型：
文档缺陷：文档不容易理解，文档缺失，文档描述错误
设计缺陷：主要指的是需求设计不合理
配置缺陷：软件在安装时出现的错误
界面错误：系统界面排版错误，界面文字错误
功能缺陷：需求规格说明书中要求的功能没有实现
性能缺陷：业务处理性能低，查询性能低，统计报表性能低

9.缺陷描述：又称重现步骤，指导开发人员具体怎样重现问题

10.实际结果：执行用例后得到的结果

11.预期结果：需求中期望得到的结果

12.bug所属模块：bug在哪个模块下测试发现的

13.提交人：发现问题的软件测试工程师

14.提交时间：发现问题的时间

15.修改人：缺陷修复对应的开发人员

16.修改时间：开发修改完bug的时间

17.关闭时间：软件测试工程师关闭问题的时间

18.附件：主要是为了开发人员快速定位问题，提供分析问题的依据：如：截图，视频，抓包，日志文件

10.8 提单的5C原则

correct （准确） ：问题单中每个组成部分描述准确，不会引发误解

clear （清晰） ：问题单中每个组成部分描述信息，易于理解

concise （简洁） ：只包含必不可少的信息，不包含任何多余的信息

complete （完整） ：包含重现该缺陷的完整步骤

consistent （一致） ：按照一致的格式书写全部的问题单

10.9 缺陷的生命周期

提交，确认，分配，修改，验证，关闭

10.10 常用的bug管理工具

禅道（zentao），bugfree，QC，mantis，DTS（华为），TAPD（腾讯），jira…

11.配置库管理工具

11.1 常用的配置库管理工具

svn（subversion），git

11.2 svn使用

安装和使用

连接服务器

上传文件

下载文件

修改文件

查看文件

恢复删除的文件

重新定位

给文件加锁和解锁

12.测试报告

概念：主要是对测试结果，测试过程中的质量和产品的质量进行度量，总结和描述

参考依据：测试计划，测试用例执行结果，缺陷数量

负责人：测试组长和测试经理

时间：测试用例执行完成达到测试结束标准，时间为1-2天

评审人：组内软件测试工程师，开发代表，产品经理，测试经理，项目经理，QA

测试报告的组成：

项目背景，测试目的，测试范围，测试策略，测试环境，测试工具，人员组成，人力投入和工作量的数据统计,用例数，缺陷数，遗留问题，测试风险

测试用例的数据统计：

三个月项目测试用例在1200-1500左右

一个月迭代依次项目用例数在200 左右

缺陷数据统计：

三个月项目缺陷数在270-300 左右

一个月迭代项目数在80-100左右

测试时间安排：

假设项目第一个版本研发周期是3个月，大概可用工作日时间为66天

1.需求分析：10%-20%左右时间，如：10天

2.测试计划：2-5天，如：3天

3.测试方案：1-2周，如5天

4.测试用例：30%左右时间，如：20天

5.测试执行：40%时间左右：如：26天

6.测试报告：1-2天时间：如：2天
项目组测试人员2名，人均每天编写测试用例数35条/天左右
（35*2） * 20=1400条用例，总计bug数：300个左右，我发现了160个bug（体现自己的工作能力）

tips ：上面的数据只是合理范围，不是写死的

13.质量

13.1 质量的范围

外部质量：明确的需求

内部质量：隐含的需求

使用质量：用户在使用过程中对产品的质量进行评估

13.2 质量的三要素

技术、流程、组织

13.3 CMMI等级

CMMI：软件能力成熟度模型综合

初始级，受管理级，已定义级，定量管理级，持续优化级

13.4 质量的六大特性

功能性：适合性，准确性，互操作性，安全保密性，功能性的依从性

可靠性：成熟性，容错性，易恢复性，可靠性的依从性

易用性：易理解性，易学性，易操作性，吸引性，易用性的依从性

效率：时间特性，资源利用性，效率的依从性

维护性：易分析性，易改变性，稳定性，易测试性，维护性的依从性

可移植性：适应性，易安装，共存性，易替换性，可移植性的依从性

14.项目中的文档

需求分析：用户需求，产品需求，需求规格说明书

开发文档：可行性分析，概要设计，详细设计

测试文档：需求分析，测试计划，测试方案，测试用例，bug清单，测试报告

管理文档：项目计划，版本计划

15.测试流程

1.产品经理进行需求调研，搜索用户的需求，整理出一份文档：需求规格说明书

2.产品经理组织开发和测试，召开需求讲解会议，会议结束后，开发和测试均得到需求规格说明 书

3.开发和测试深入了解需求文档，提出对需求文档有疑问的地方

4.产品经理召开会议给测试和开发澄清需求

5.软件测试工程师对自己负责的模块进行需求分析，完成后组织测试内部人员和开发人员进 行评审

6.评审后根据评审意见修改需求分析文档，测试经理开始编写测试计划，安排后期测试过程
中人力投入和各阶段时间安排，测试计划评审通过后

7.软件测试工程师，开始编写测试用例，完成后，进行评审

8.开发编码完成后，从svn上获取安装包，搭建测试环境

9.软件测试工程师开始执行冒烟测试，通过后，进行正式的测试执行，如果不通过版本打回

10.正式测试分为三轮，达到测试结束条件，终止测试

11.测试经理开始编写测试报告，测试报告评审通过后，软件提交预发布流程，审核通过后，开
始安排上线时间点

内部质量：隐含的需求

使用质量：用户在使用过程中对产品的质量进行评估

13.2 质量的三要素

技术、流程、组织

13.3 CMMI等级

CMMI：软件能力成熟度模型综合

初始级，受管理级，已定义级，定量管理级，持续优化级

13.4 质量的六大特性

功能性：适合性，准确性，互操作性，安全保密性，功能性的依从性

可靠性：成熟性，容错性，易恢复性，可靠性的依从性

易用性：易理解性，易学性，易操作性，吸引性，易用性的依从性

效率：时间特性，资源利用性，效率的依从性

维护性：易分析性，易改变性，稳定性，易测试性，维护性的依从性

可移植性：适应性，易安装，共存性，易替换性，可移植性的依从性

14.项目中的文档

需求分析：用户需求，产品需求，需求规格说明书

开发文档：可行性分析，概要设计，详细设计

测试文档：需求分析，测试计划，测试方案，测试用例，bug清单，测试报告

管理文档：项目计划，版本计划

15.测试流程

1.产品经理进行需求调研，搜索用户的需求，整理出一份文档：需求规格说明书

2.产品经理组织开发和测试，召开需求讲解会议，会议结束后，开发和测试均得到需求规格说明 书

3.开发和测试深入了解需求文档，提出对需求文档有疑问的地方

4.产品经理召开会议给测试和开发澄清需求

5.软件测试工程师对自己负责的模块进行需求分析，完成后组织测试内部人员和开发人员进 行评审

6.评审后根据评审意见修改需求分析文档，测试经理开始编写测试计划，安排后期测试过程
中人力投入和各阶段时间安排，测试计划评审通过后

7.软件测试工程师，开始编写测试用例，完成后，进行评审

8.开发编码完成后，从svn上获取安装包，搭建测试环境

9.软件测试工程师开始执行冒烟测试，通过后，进行正式的测试执行，如果不通过版本打回

10.正式测试分为三轮，达到测试结束条件，终止测试

11.测试经理开始编写测试报告，测试报告评审通过后，软件提交预发布流程，审核通过后，开
始安排上线时间点

12.上线后对主功能进行测试，成功上线后，开始进行下一轮迭代