软件测试完整学习

############软件的概念############
错误观点：“软件就是程序，软件开发就是编程序”
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合；
程序是按事先设计的功能和性能要求执行的指令序列；
数据是使程序能正常操纵信息的数据结构；
文档是与程序开发，维护和使用有关的图文材料；
############软件十大特性############
形态特性：软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它确实毫无意义的。
智能特性：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题；
开发特性：尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素；
质量特性：软件是个人编写的，由于其开发特性存在，所以不存在完全没有缺陷的软件；
生产特性：与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限；
管理特性：由于上面的特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特；
环境特性：软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性；
维护特性：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大差别，维护体现在升级、优化、功能更新等方面，甚至可以全盘重构；
废弃特性：与硬件不同，软件并不是由于被“用坏”而被废弃的；
应用特性：软件的应用极为广泛，如今它已经渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位；
############软件的分类############
系统软件
系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作；
服务性程序：如诊断程序、排错程序、练习程序等
语言程序：如汇编程序、编译程序、解释程序；
操作系统
数据库管理系统
应用软件
应用软件是为了某种特定的用途而被开发的软件，它可以是一个特定的程序，比如一个图像浏览器，也可以是一组功能联系紧密，可以互相协作的程序的集合；
############软件生命周期############
软件的生命周期，又称为软件的生存周期。它是按照按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段；
每个阶段又分解成几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件；

余额宝的诞生

软件开发模型：
由于项目、需求的模式不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同，在历史上，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷等模式的变更；
瀑布模型：
计划===>需求分析 ===>设计 ===>编码 ===>测试 ===>运行维护
特点：1 软件开发的各项活动严格按照线性方式进行；
2 当前活动接受上一项活动的工作结果；
缺点：1 由于开发模型是线性的，增加了开发的风险
2 早期的错误可能要等到开发后期的阶段才能发现
原型模型：
客户与开发公司紧密联系，开发周期长，开发会受到需求变更的影响；
特点：1 实现客户与系统的交互
2 进一步细化待开发软件需求
3 开发人员可以确定客户的真正需求是什么
螺旋模型：
制定计划 ===>风险分析 ===>实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试） ===>客户评估
特点：1 螺旋模型是将瀑布模型与快速模型结合起来；
2 强调了其他模型所忽视的风险分析；
3 每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估；
缺点：1 强调风险分析，但要求许多客户接受并相信这种分析，是不容易的；
敏捷模型：
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法；
特点：1 短周期开发 2 增量开发
3 由程序员和测试人员编写的自动化测试来监控开发进度；
4 通过口头沟通、测试和源代码来交流系统的结构和意图；
5 编写代码之前先写测试代码，也叫作测试先行；
重沟通 少文档
缺点：1 团队的组建较难，人员素质要求较高；
2 对测试员要求掌握各种脚本语言编程，能执行单元测试、自动化测试；

###################PART3 软件开发文档###################

下面是必须的一些文档

3.7 阿里系开发模型的变迁
开发模型的变迁
最早期：边做边改=》稳定期：瀑布式=》发展期：敏捷=》创新期：DEVOPS
3.8 项目的一生
项目进程：
（1）编程阶段：单元测试(白盒测试)-测试参与其中
（2）编程完成：开发联调(集成测试)-开发为主
（3）提测-冒烟测试 (自动化为主，手工为辅) 测试执行
（4）测试阶段-系统测试(黑盒功能测试为主，自动化/接口测试为辅，根据项目进行性能、安全测试)
（5）验收阶段-验收测试-测试配合用户或需求
3.9 软件的测试方法
软件测试概念：
经典定义：软件测试，在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
标准定义：软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别
软件测试的目的：
软件测试的目的在于发现问题，检查系统是否满足需求

生命周期各测试方法对比

	单元测试	集成测试	冒烟测试	系统测试	验收测试
测试阶段	编码后	单元测试完成后	提测后	冒烟测试通过后	发布前
测试对象	最小模块	模块间的接口	整个系统	整个系统	整个系统
测试人员	白盒测试或开发	白盒测试或开发	黑盒测试	黑盒测试	最终用户需求或需求方
测试依据	代码、注释、详细设计文档	单元测试模块、概要设计文档	冒烟测试用例	需求说明文档、测试方案、测试用例	用户需求、验收标准
测试方法	白盒测试	黑盒与百盒结合	黑盒测试（手工或与自动化结合）	黑盒测试	黑盒测试

3-11 软件测试常用术语
C/S：C指的是客户端(Client)，S指的是服务器端(Server)，这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。比如我们经常用的QQ、和各种网络游戏就属于C/S结构的软件。
B/S：B指的是浏览器(Browser)，S指的是服务器(Server)，这种软件同样是基于局域网或互联网的，它与C/S结构软件的区别就在于，不需要安装客户端(client)，只需要有浏览器，就可以直接使用。比如搜狐、新浪等门户网站及163邮箱都属于B/S结构的软件，B/S结构软件是现在软件的主流，与C/S结构软件相比，便于升级和维护，是测试的重点。
缺陷【Bug/Defect】：软件的Bug指的是软件中(包括程序和文档)不符合用户需求的问题。
测试环境：软件测试环境就是软件运行的平台，包括软件、硬件和网络的集合。用一个等式来表示：测试环境=软件+硬件+网络
测试用例【Test Case】：在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
用一个等式来表示：测试用例=输入+输出+测试环境
其中，"输入"包括测试数据和操作步骤，"输出"指的是期望结果，"测试环境"指的是系统环境设置
冒烟测试【Smoke Testing】：在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性
α测试：验收测试的一种，指的是由用户、测试人员、开发人员等共同参与的内部测试
β测试：验收测试的一种，指的是内测后的公测，即完全交给最终用户测试
3-12 软件测试常见模型
V模型：V模型时我们熟知的瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果。
V模型就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始，这两个并行的动态的过程就会极大地减少bug和error出现的几率。

W模型：一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。
W模型是从V模型演化过来，实际上开发是V，测试是并行的V；相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动，W明确表示出了测试和开发的并行关系，测试与开发是同步进行的，有利于尽早地全面的发现问题。

其他模型-H模型：真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。
为了解决V模型和W模型存在的问题，有专家提出了H模型，它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
其他模型-X模型：

3-13 软件测试覆盖率
测试覆盖率：覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量；
覆盖率=(至少被执行一次的item数)/item的总数
特点：1 通过覆盖率数据，可以检测我们的测试是否充分
2 分析出测试的弱点在哪方面
3 指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加。
测试覆盖率对于黑盒测试来说，主要指两个方面：需求覆盖和用例覆盖
需求覆盖：1 定义：它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到。
2 计算公式：需求覆盖=(被验证到的需求数量)/(总的需求总数)
用例覆盖：1 定义：主要体现在我们每轮测试验证通过的用例数在总用例中的比重；
2 计算公式：用例覆盖=(验证通过的用例数量)/(总的用例总数)
3-15 测试覆盖率的运用
简单的测试覆盖率：本次测试执行的用例数/所有用例数
上述覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%
覆盖率的审核：抽样验收
基于产品的测试覆盖率： 已测试需求点/设计所有需求数
以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%
基于白盒的测试覆盖率： 大多工具判断语句覆盖，即单元测试代码覆盖代码行/总代码行
更多考察研发人员；更多时候要求覆盖率达到80%+
缺陷： 覆盖率数据只能代表测试过那些代码，不能代表是否测试好这些代码；容易遗漏逻辑、判断等场景；
基于自动化的测试覆盖率： 自动化覆盖的测试场景(测试用例)/所有测试场景(用例)
80/20原则，比如用户80%的时间在使用20%的功能，20%的功能就可以撑起用户最关键的业务场景，自动化测试的用例选择更着重与这20%的核心功能
用途： 自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计。
测试覆盖率的最终意义：
=》应用最多的地方在测试停止标准
=》单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试
=》在短迭代、DevOps中，更强调用单元测试覆盖率来评估不断增加的代码数量
3-15 测试团队的组织架构


3-16 软件测试人员必备


软件的测试的原则：
原则1：所有的测试都应追溯到用户需求

原则2：尽早的启动测试工作

原则3：Pareto法则应用于软件测试

原则4：穷尽测试是不可能的

原则5：杀虫剂怪事

原则6：前进两步，后退一步

原则7：三心二意
细心、信心、耐心
团队合作的沟通意识、时刻保持怀疑的态度且有缺陷预防意识
3-17 软件工程标准
国内通用的标准主要有ISO9000及CMM

ISO9000：


CMM：

软件测试规范：
测试系统主要有下面6个相互关联、相互作用的过程组成


4-1 软件测试环境搭建原则
搭建测试环境前：
（1）确定测试目的
（2）功能测试，稳定性测试，还是性能测试，测试目的不同，搭建测试环境时应注意的点也不同
功能测试：不需要大量的数据，需要覆盖率高，测试数据要求尽量真实
性能测试：可能需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置
测试的软件环境尽可能的模拟真实环境
尽可能的模拟用户使用环境，选用合适的操作系统和软件平台
了解符合测试软件运行的最低要求及用户使用的硬件配置
了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间
产品化的测试则需要考虑兼容性的方案
营造独立的测试环境
不同的项目、不同的公司会对测试环境的独立性有不同的要求
测试过程中尽量保证测试环境独立，不会受到其他测试人员以及项目研发人员的影响
构建可复用的测试环境
通过备份或数据隔离的方式
重复运用一套测试环境进行多版本多时间段的测试
搭建测试环境过程分析
线下搭建
独立测试服务器或虚拟机
测试环境配置
测试项目导入
测试环境配置
配置java环境(下载jdk并配置环境变量)
下载并安装中间件(tomcat、jetty或其他)
安装数据库并导入初始化脚本
Docker模式
构建属于自己的image
依赖第三方平台（如蚂蚁金融云）
4-2 测试环境的建设落地
环境建设思路：
考虑点：用途、使用成本、维护成本
基本架构：
研发环境：用于研发自测、集成测试
测试环境：用于日常单系统或两两微服务之间测试，可同时集成自动化测试回归
联测环境：完备环境，用于大型联测
外联环境(如果有需求)：稳定版本环境，用于外部商户等联调
灰度/沙箱环境：用于生产数据测试，仿真测试
4-3 测试过程

4-4 测试策划概述


4-5 需求测试









需求测试实战


审查需求文档==》我们一起简单看下需求文档

------------------------------------------------------余额理财产品需求文档------------------------------------------------------
1 货币基金消费
投资人购买货币基金后，可直接通过货币基金金额进行支付购买商品或服务，货币基金可以视同余额、集分宝一样作为支付工具进行消费。


流程说明：
1 用户在消费场景选择商品或服务并下单，进入收银台支付，此外包括标准收银台、快付收银台、暂不包括航旅收银台
2 如果用户的货币基金可用金额大于0，则在账户余额下方显示可用金额，单位为元，如果金额为0，则不显示
3 用户选择货币基金支付，点击使用，弹出浮层
4 浮层显示用户所有可用金额，和本次支付最多可用金额，默认支付最多可用金额，用户可进行修改，最大不能超过该金额，支持两位小数使用
5 货币基金金额可以跟其他支付工具(除了线下、现金方式)进行组合使用
6 用户输入支付密码后，实时扣除指定份数的货币基金，如果扣除失败，则显示失败的具体原因；如果扣除成功，将用户消费金额变成数据实时同步到用户资产，当前可用金额=交易前可用金额-消费金额，同时更新资产更新时间为当前时间。
7 用户支付成功后，异步通知基金公司扣除该金额
场景约束：
1 需支持指定时间段(时刻-时刻)停止消费，主要为解决长假和大促问题，该期间内，收银台不显示货币基金可用份额。
2 需支持合并支付，使用现有支付工具分配方案
3 需支持根据淘宝类目进行开关，本次适用所有淘宝类目
4 需支持根据指定卖家进行开关，包括淘宝卖家和外部商户，本次适用于所有卖家
5 需支持根据场景开关，业务上将货币基金等同账户余额，由于工作量原因，本期货币基金需支持场景如下：
------------------------------------------------------余额理财产品需求文档------------------------------------------------------

需求分析过程中我们会将上面的流程分为：货币基金购买、提现、消费、资产管理、交易查询几部分

4.7 测试策略
测试前的思考：
系统哪些部分需要测试？哪些不要测试？
系统对性能有什么要求？
系统对安全性有什么要求？
。。。。
测试策略是什么？
测试策略是描述测试项目和测试任务之间的关系。
它用来说明要测什么，如何测，如何协调测试资源和测试时间等。
测试策略制定的是否合理高效会对测试项目的进度产生很大的影响。
如何指定一个好的测试策略并且能防止遗漏呢？

测试安排、发布计划：
罗列测试项目本身重要的里程碑
每个里程碑都需要有明确的结束时间
这个时间可以指导我们后续的测试
如果我们测试时间安排不足，我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试
这样可以最大限度的保证产品的质量
测试范围（按优先级排列）：
分为In Scope和Out Of Scope
需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的
对于在测试范围中的模块，需要给出优先级，以便相应测试时间不足的情况
对于不在测试范围中的模块，需要给出原因，为什么在本测试阶段不考虑测
测试资源：
测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分
人力资源主要说明参与测试的人员，当然可以包括很多的角色，如专业测试人员、客户、产品经理等
工具主要是指可能用到其他软件
测试环境：
测试环境主要包括推荐环境解决方案，操作系统要求，软硬件要求
对于推荐解决方案，需要陈述的是对测试项目对其他软件的依赖
比如测试项目对JAVA有依赖，推荐版本可能就是1.7
测试方法：
测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试
功能测试是必须的，非功能测试是可选的
文档管理：
对于一个完整的产品来说，文档是很重要的一环
他一般包括安装、升级文档，用户指南等
文档不单单是一个文件，它需要经过完整的测试才能发布给客户，差的文档很可能会误导用户，从而使他们对测试项目失去信心
风险管理：
风险管理模块需要罗列出来现在已经知道的可能会出现不确定性的因素，这些因素可能来自技术、资源或者其他方面的
4-8 测试方案设计–方案何等重要




我们来看看正常情况下一个测试方案：

货币基金消费测试方案分析过程：
1 分析需求：当前测试包含需求项（需求文档或wiki链接等）
2 测试计划（里程碑）及负责人：整理当前项目各模块测试负责人、任务分配及测试时间安排
3 测试范围、测试重点：那些point需要测试，重点放在什么地方，优先级安排
4 测试策略及工具：是否需要进行自动化、性能、安全测试？使用那些工具
5 测试用例设计方法：使用什么样的黑盒测试方法进行设计（等价类？边界值？因果图？等等）
6 测试环境：测试环境是什么？需要哪些服务器、数据库？配置如何等
7 联调测试：是否需要与第三方或其它部门联调？何时开展？联调包括哪些功能？例如基金公司
8 测试限制：在测试环境中哪些内容无法测试？比如消费到账
9 测试风险：在测试或计划测试过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量

4-9 测试评审–决定测试质量
目前，开发有需求说明会、设计评审会、代码复审会等各种会议，但多是站在开发的角度，从需求和代码层面进行复审和风险规避，在测试环节和测试阶段缺少以测试为主体的评审机制和沟通机制。
容易造成以下几方面的问题：
仅从文档、沟通获取信息，可能会造成信息不对称，认识片面，理解错误或不深入等问题
缺少同行交叉评审和开发评审机制，无法充分发挥集体智慧，个人的思维难以突破，可能会出现测试遗漏的情况
评审目的：
呈现测试的工作
与开发达成共识
不同的思维方式碰撞出火花，借鉴别人的思考方式
培养这样的行为模式：愿意为团队或他人出谋划策
发挥团队协作，最大限度发挥个人的经验，特长，实现技能互补
评审重点：
采用的测试方法
等价类划分的依据
测试数据的选取和准备方法
流程测试的路径组合
数据比对选取的对象和数据检查点
是否需要模拟数据及模拟数据的方法
基于风险的测试取舍

5-1 测试设计与测试用例
测试设计是将概括的目标转化为具体的测试条件和测试用例的一系列活动
测试分析和设计的主要任务：
评审测试依据（需求，系统架构、设计和接口说明）
评估测试依据和测试对象的可靠性
通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级
设计测试用例，并确定优先级（最为重要）
确定测试条件和测试用例所需的必要的测试数据
确定测试条件：
依据在测试策略或测试计划中确定的测试技术
通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件

测试用例：
测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体操作产生何种结果的文档。
测试用例就是指引我们测试的步骤文档
测试用例应该具有可重复性、可验证性和需求可追踪性
测试用例设计包括以下关键点：
前提条件，如项目或局部测试环境的需求，及其交付计划
测试步骤
测试数据
预期结果

测试用例常用设计方法
等价类划分法
边界值法
因果图设计法
判定表设计法
正交实验法
5.2 等价类划分法的特点







（1）一个有效等价类：-99到99 两个无效等价类：99之上与-99之下
（2）今天我要完成100道题：等价类：完成了100道题 无效等价类：没有完成
（3）地铁进站：我们要站好队，不同的队伍进不同的入口



回到计算器的例子：等价类划分实战
STEP1：根据测试需求可以分为三个等价类：
一个有效数据的等价类，两个无效数据等价类
有效数据等价类就是：由哪些对程序的规格说明有意义的、合理的输入数据所构成的集合
无效数据等价类就是：哪些对程序的规格说明不合理的或无意义的输入数据所构成的集合

5-4 边界值法










5-5 因果图和判定表

比如我们说北京就会引出海淀，昌平。。天津就会引出津南，和平。。

因果图-判定表：
因果图法基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合情况规定相应的操作。
因此，可以考虑为决策表中的每一列设计一个测试用例，以便测试程序在输入条件的某种组合下的输出是否正确。
概括的说，因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变）。
将因果图转换为判定表，为决策表中的每一列设计一个测试用例。
这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。
判定表：
判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的工具。
在程序设计发展的初期判定表就已被当作编写程序的辅助工具了。
因为它可以把复杂的逻辑关系和多种条件组合的情况表达的既具体又明确。

判定表通常由四个部分组成：
条件桩（Condition Stub）：列出了问题的所有条件，通常认为列出的条件的次序无关紧要。
动作桩（Action Stub）：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
条件项（Condition Entry）：列出针对它左列条件的取值，在所有可能情况下的真假值。
动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。












5-6 正交实验法
正交实验法（Orthogonal experimental design），是从大量的试验点中挑选出适量的、有代表性的点，应用依据伽罗卡瓦理论导出的"正交表"，合理的安排试验的一种科学的试验设计方法。
指标：通常把判断试验结果优劣的标准叫做试验的指标。
因子（因素Factor）：所有影响试验指标的条件
因子的状态（水平Level）：而影响实验因子的，叫做因子的状态（因子变量的取值）













5-7 测试场景设计








5-8 实际测试中用例设计的综合运用





6-1 测试执行过程




6-2 测试准入准出
测试准入标准：
开发编码结束，并在开发环境已完成单元测试；
需求上规定的功能均已实现，如没有完全实现，请提供测试范围；
已完成集成测试，被测系统的基本流程可以走通，界面上的功能均实现，经过代码评审并符合软件编码规范；
开发提交最新版本代码，以此为基线，提交并通知测试组进行测试；
兼容性测试要求明确；
安全测试和性能测试范围和要求；
（开发要自测）（通过我们的冒烟测试）（所有的测试内容、测试要求、测试范围都已经非常明确）
测试暂停、停止
测试人员先进行冒烟测试，若发现重大缺陷或bug过多时，或者流程卡壳导致基本流程无法走通，测试无法正常进行，可以暂停测试并返回开发；
被测项目需调整而暂停的，测试也相应暂停；
存在其他优先级更高的任务时，可以向领导申请暂停测试；
被测系统经过系统测试，达到系统准出标准，可以停止测试；
测试准出标准

6-3 软件缺陷概述
软件缺陷：
缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等；
并不是所有的测试人员都能提交被开发认可的缺陷，也不是测试员在任何时候都能提交被开发认可的缺陷；
什么是软件缺陷
1 软件未达到产品说明书标明的功能；
2 软件出现了产品说明书指明不会出现的错误；
3 软件功能超出产品说明书指明范围；
4 软件未达到产品说明书虽未指出但应达到的目标；
5 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好；

发现缺陷：
1 用户体验不够好
2 界面上有明显的错误信息
3 功能不完备，没有按照需求说明编写代码，致使某些功能缺失
4 功能不完善，不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况
5 逻辑不正确，与需求说明书、测试用例不符
6 模块之间的交互性不好，与其他模块做集成测试时遇到问题
7 程序的性能不够好，不能承载压力考验

6-4 缺陷报告



















6-5 缺陷报告的原则










6-6 缺陷跟踪-持续跟踪才能高效测试



于是，缺陷跟踪管理系统应运而生。。。

6-7 禅道项目管理及实战






6-8 易用性测试-测试点的总结











6-9 兼容性测试


















8-1 白盒测试之代码审查




8-2 白盒测试方法值逻辑覆盖

















8-3 自动化测试概述-涨薪必会






项目周期很长，项目迭代很规律（自动化测试）
8-4 自动化测试工具的介绍
















兼容性不好！

8-5 Selenium初窥-自动化必会的工具


8-6 安全测试概述












功能测试-自动化测试-安全测试-性能测试

8.7 安全审计-安全测试必会

问题：错报和漏报







8-8 性能测试概述
























8-9 LoadRunner使用（上）





下面用一个例子来展示LoadRunner的使用：

9-1 认识移动APP-手机APP测试




9-2 移动APP测试与传统测试的区别





9-3 APP测试方法















9-4 APP测试工具