一、发展阶段

 

二、软件测试

一）软件测试的定义

        软件测试是使用人工或自动的手段来测试某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差距。

eg：

拿手机打游戏

不是测试，没有检验是否满足需求，没有了解其需求；没有刻意去弄清预期结果与实际结果的差距。

把一个app应用安装到手机上以后再卸载   ——不是测试

一个不知道再怎么用的软件上随便点点点，看看会不会出现什么问题

不是测试，未知需求

找个类似于按摩精灵 的工具录制操作步骤，自动化地帮我抢红包

不是测试，没有弄清预期结果于实际结果之间的差距。没有比较的自动化，是自动化操作而不是自动化测试。

二）软件测试的特点

三）软件生命周期

MCP：Minmal Concept Principie(最小概念原则)

软件生命周期：

1. 计划
2. 需求分析
3. 设计
4. 编码：根据概要说明书及详细设计说明书编写程序代码
5. 测试：

• 单元测试：对程序的最小单元进行测试的过程，最小单元指函数或者是一个类的代码
• 集成测试：对模块与模块之间调用的接口进行的测试叫集成测试
• 系统测试：对完成编译的系统整体进行测试的过程。
• 验收测试：交付给客户或者最终用户时，和客户一起完成的测试。

1. 运行和维护

四）软件测试模型

模型：将比较抽象的事物用比较形象的方式表现出来

• 传统的瀑布模型：古老，很少用
• V模型：经典
• W模型
• 敏捷测试模型：最流行，最广泛

1）瀑布模型

特点：

• 阶段间具有顺序性和依赖性
• 推迟实现
• 质量保证的观点

瀑布模型是文档驱动的模型，遵守这个约束可使软件维护变得比较容易，从而显著降低软件预算。

优点：

• 开发的各个阶段比较清晰。
• 强调早期计划及需求调查。
• 适合需求稳定的产品开发。

缺点：

• 依赖于早期的需求调查，不适应需求的变化。
• 单一流程不可逆。
• 风险往往延至后期才显露，失去及早纠正的机会。
• 问题在项目后期才开始暴露。
• 前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败。

最大的问题：

        测试工作后置，呆滞整改项目开发完成之后如果发现比较验证的问题，修改的成本巨大。风险后期才发现，难以回溯。

2）V模型

• 测试阶段划分得很清楚
• 每个测试阶段都有对应的开发文档支持
• 测试与开发是串行进行的而不是并行，也就是测试需要等到开发完成后再开始
• 测试对象只有程序，而不包括需求等文档
• V模型是瀑布模型的变种，瀑布模型存在的问题V模型也存在

V模型主要的特点：

将测试过程细化，分为了单元测试、集成测试、系统测试和验收测试四个不同的阶段，但仍然是测试后置，没有解决风险问题。

3）W模型

Verification：验证，针对过程的正确性（正确地做某事）

Validation：确认，针对最终产品的正确性（做正确的事）

W模型特点：

将测试和开发过程分离出来，对整个项目过程中的需求文档、设计文档同样要进行测试，将测试工作前置，大大降低整个项目的质量风险。

4）敏捷模型

敏捷模型主要的特点：

就是为了适应现代互联网公司“短频快”的开发节奏而设计的一种测试和开发的模型。

过程：

Product Backlog：产品需求

迭代：每次迭代叫做一个sprint，每个sprint里面选出来要实现的需求会安排到sprint backlog里面。每个sprint一般是以一个月作为一个周期。

Product Owner：相当于产品经理。整理出项目的所有需求，并且按照需求的优先级来将需求排列到product backlog

Scrium Master：相当于组长，team manager，他统一管理组员。

组员不会直接和Product Owner进行沟通。

daily meeting：每日会议，一般是站会形式（stand meeting）。每个人发言一般不会超过1分钟，主要开发内容包括三点：昨天你做了什么，今天准备做什么，有什么风险和问题。

sprint burndown：迭代燃尽图，记录剩余的工作量有多少。

sprint review meeting：迭代的回顾会议。主要回顾在本轮迭代中存在的问题有哪些，后面如何去改进。

首先，Product Owner整理出项目的所有需求，并且按照需求的优先级来将需求排列到product backlog，整理出来后，Product Owner会决定每一轮要实现什么需求，将其归置到sprint backlog中，每个sprint会花四周的时间，期间会有一个daily meeting，daily meeting主要是快速的组建交流，所有人汇报自己每天做了什么，今天在准备做什么，有什么风险和问题，需要什么帮助；同时可以通过sprint burndown迭代燃尽图去看当前剩余的工作量有多少；经过四周的sprint 后需要有一个产出给客户；同时，组员会进行一个sprint review meeting，迭代的回顾回忆，主要回顾在本轮迭代中存在的问题有哪些，后面如何去改进。一个迭代完成后，将未完成的需求选出下一批sprint blacklog进行迭代，直到需求完成。

五）软件质量模型

1. 质量模型是基于ISO25000和国标GB/T25000制定的可用于测量产品质量的模型，该模型提供了从不同维度考量产品质量属性的依据。

1. 质量模型规定的各种不同质量属性和不同的测试类型之间具有映射关系，所以可以用不同的测试类型来测试不同的质量属性。

蓝色的六个为内部的质量属性：（测试关注）

• • 功能性

• • 可靠性

• • 易用性：满足法律法规，合规，eg：苹果地图事件

• • 性能效率

• • 兼容性：共存性、互操作性、兼容性的依从性

• • 安全性

黄色的六个为内部的质量属性：（开发和运维关注）

• • 可移植性

• • 维护性

关于以上第一点：

eg：如何测试一个水杯的质量

1. 功能性，测试可不可以用
   • 装一半容量的水

• • 装最大安全容量的水

• • 水倒满流出来，是否影响使用

• • 水杯的刻度和国标是否一致

• • 水杯是否可以装冷水、热水，是否烫手或者冷手

• • 水杯是否保温

• • 杯盖拧紧到什么程度水倒不出来

1. 可靠性，最大的承受能力
   • 掉到地上不易破坏

• • 保温时长

• • 杯子的耐热性

• • 杯子的耐寒性

• • 杯子上防止重物达到什么程度杯子被损坏

• • 杯子和包装（有填充物），检查产品是否能对应恶劣的铁路/公路/航空运输

1. 易用性，好不好用
   • 外观是否完整，美观

• • 大小与设计是否一致

• • 喝水时是否容易漏水

• • 是否方便携带

• • 拿着舒服

• • 倒水方便

• • 喝水方便

• • 使用简单，任意操作

• • 防滑措施

1. 安全性，对人体是否有害
   • 材质是否符合国家标准

• • 杯子使用材质是否有毒或细菌

• • 高温无毒性

• • 低温无毒性

• • 装其他物体是否容易产生毒性

1. 可移植性，不同环境下使用是否有问题
   • 水杯是否能在高压或低压环境下使用

• • 水杯是否可以在高温/低温条件下使用

• • 水杯是否可以在水中使用

• • 水杯是否可以在特殊作业条件下使用

1. 兼容性，在不同环境下是否可以使用
   • 能容纳果汁、白水、酒精、汽油等

1. 性能效率
   • 使用的最大次数或时间

• • 长时间放置，放水不会漏出来

• • 往水杯倒入水的时长

• • 水杯中的倒出来的时长

1. 可维护性
   • 水杯是否容易修复

• • 水杯是否容易分解

凡是问到一个产品怎么测（不管是软件还是硬件），都必须从产品质量模型所规定的8大质量属性去考虑。

关于以上第二点：

测试类型

1. 常见测试类型及其与质量属性的关系表

名称	说明	对应的质量属性
功能测试	验证产品能否满足用户特定功能要求并做出正确响应	功能性
安全性测试	验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击	功能性
兼容性测试	验证产品是否能够和其他相关产品顺利对接	功能性
配置测试	验证产品是否能够在推荐配置上流畅运行；验证产品为了完成特定功能的输入是否会出现故障	功能性，易用性
可靠性测试	验证产品在长时间运行下能否满足保证系统的性能水平；在存在异常的情况下系统是否依然可靠	可靠性
易用性测试	验证产品是否易于理解、易于学习和易于操作	易用性
性能测试	测试产品提供某项功能时的时间和资源使用情况	效率
安装测试	测试产品能否被正确安装并运行	可移植性

六）测试类型分类

测试阶段不同	代码是否可见	执行手段不同	测试目的不同	其他测试类型
单元测试 集成测试 系统测试 验收测试	黑盒测试 白盒测试 灰盒测试	手工测试 自动化测试	GUI测试 接口测试 性能测试	回归测试 冒烟测试 探索性测试

1. 黑盒测试：指在不知道被测代码结构的基础上根据产品的需求、站在最终用户的角度来对软件的输入和输出进行测试的过程。

1. 白盒测试：指基于被测软件的代码和结构，对被测软件的代码和结构本身进行测试的过程。（一般开发工程师做）

1. 灰盒测试：介于白盒和黑盒之间 ，一般来说灰盒是针对接口来进行测试。比如只知道函数的函数名、参数以及返回值，并不知道函数内部的实现结构。

探索性测试：即不依赖于测试用例，根据自己的经验、感觉进行测试

七）项目相关的文档

1. 开发阶段主要文档
   • 需求规格说明书

• • 概要设计

• • 详细设计

1. 测试阶段主要文档
   • 测试计划和方案（一般工作了几年）

• • 测试用例

• • 缺陷报告

• • 测试报告

八）测试流程

1. 分析：需求评审、测试需求分析——得到测试点

1. 计划：测试计划和方案文档编写

1. 设计：测试用例设计

1. 实现：编写测试用例、测试脚本等

1. 执行：搭建测试环境，执行测试脚本、编写测试报告

按照以上步骤一：步步实现

1）需求评审

需求的来源：

1. 合同型项目（外包，有甲乙方）
   • 用户业务需求->产品需求

1. 产品型项目（没有明确用户）
   • 协议/标准/规范

• • 继承性需求

• • 竞品分析

1、需求评审

1. 需求从哪里来，如果没有需求怎么办
2. 需求评审怎么评

需求评审表：

2、测试需求分析

1. 为什么要做需求分析
2. 测试需求分析流程

为什么要做测试需求分析：

1. 在做任何系统的测试之前，我们都需要思考以下的问题：

1. 你知道要测试的系统是干什么的吗

1. 你了解系统有哪些特点吗

1. 你知道系统有哪些功能吗

1. 你知道系统的业务的流程是什么吗

1. 系统在这个版本上，哪些需要测试，哪些不需要测试/strong>

1. 系统对性能、安全性上有没有什么要求/strong>

3、需求分析流程

1. 根据产品需求提取系统的测试点
2. 编写需求跟踪矩阵
3. 根据测试点利用适当的测试用例设计方法设计测试用例

4、测试设计与用例编写

测试设计的概念

将测试点转化为测试用例的过程，就叫测试设计。

测试用例的概念

测试用例就是一种用来说明具体如何进行测试操作并验证结果的文档

测试用例模板

1. 用例编号：TC：Test case，系统名，模块名，自然编号
2. 用例标题：用一句话来表述该测试用例测试哪个测试点
3. 优先级：高中低。作用是在项目时间不够或人员不充足的时候，我们可以优气测试重点的测试用例
4. 预置条件：在执行该条用例时，系统必须达到的一个状态或者条件。可选，不要全部都写
5. 创建人
6. 创建时间
7. 所属模块
8. 测试步骤：详细描述测试此条用例时，需要进行哪些操作
9. 预期结果：来自于需求，要求我们达到的一个结果
10. 实际结果：实际操作系统之后的结果
11. 测试结果：Fail / pass / NA。N/ A指当前用例不适用或无法操作。必填。
12. 备注

九）测试用例设计方法

等价类、边界值、判定表、流程分析法（场景分析法）、错误猜测法

世界上最好的测试方法是什么举法

1 )等价类法

定义：某个输入域的集合，在这个集合中每个输入条件都是等效的．如果其中某一个输入不会导致问题，则集合中其他输入条件进行测试也不可能发现问题。

有效等价类：有效等价类对程序有意义、正确的输入数据。

无效等价类：无效等价类对程序无意义、不正确的输入数据。

基本原则：

1. 如果输入条件规定了取值范围或者值的个数，则可以确定一个有效等价类和两个无效等价类

eg:要求输入年龄在18~25之间

则18~ 25就是一个有效价类，小于18和大于25就是两个个无效等价类。

1. 输入条件规定了输入值的集合，或是规定了必须如何的条件，则可以确定一个有效等价类和个无效等价类。
2. 在输入条件是一个布尔值的情况下，可以确定一个有效等价类和一个无效等价类
3. 如果我们确知，已经划分的等价类中各个元素在程序中的处理方式不同，则应该将此等价类进一步划分
4. 在规定了输入数据必须遵守的规则情况下，可以确立一个有效等价类（遵守规则）和若干个无效等价类（从不不同角度违反规则）

等价类划分法设计步骤：

        编写等价类表，为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号。

        设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类，重复这一步骤，使得有效等价类均被测试用例所覆盖。

        设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤石得所有无效等价类均被覆盖。

2）边界值法

       对于程序的输入和输出边界进行测试的一种黑盒用例设计方法，常与等价类设计法结合使用，此时它的用例来自于等价类的边界。

       边界值分析法的理论基础是假定大多数的错误发生在各种输入条件的边界上，如果再边界附近的取值不会导致程序错误，那么其他的取值导致程序错误的可能性也很小，

       边界值使用条件（重点：可度量）

输入条件明确了一个值的取值范围，或是规定了值的取值个数

输入条件明确了一个有序集合

1. 上点：边界上的点

1. 离点：离边界最近的点

1. 内点：取值域内的任意一个点

如何使用括号法快速判断离点/strong>

上点：范围中你看到的那两个点一定是上点（不管等于还是是<、>、=）

离点：

离括号更近的点，比如59，60）61 所以离点是61

一个数不可能是上点又是离点

来源：PD137