软件测试--

软件测试

1，软件测试是什么

软件测试的定义：

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

软件测试的目的：

1. 软件测试为了发现程序(软件)存在的代码或业务逻辑错误。
2. 软件测试为了体验产品是否符合用户需求。
3. 软件测试为了提高用户的体验。

2，软件测试的分类

按测试技术划分

黑盒测试，白盒测试，灰盒测试

按测试对象是否运行划分

动态测试，静态测试(文档检查，代码走查)

按不同的测试手段划分

手动测试，自动化测试

按测试包含的内容划分

功能测试，界面测试，安全测试，兼容性测试，易用性测试，性能测试

按测试阶段划分

单元测试，集成测试，系统测试，验收测试，阿尔法测试，贝塔测试

其他测试

回归测试，冒烟测试，探索性测试/自由测试(测试思维)

黑盒测试：产品–黑色盒子–代码是实现===输入 输出—数据驱动的测试 —点点

白盒测试：产品—透明盒子：代码逻辑，会代码 不是测试做的，开发自测—代码审查=单元测试

灰盒测试：大概知道代码的逻辑实现，不需要看懂所有的代码—接口测试

功能测试：测试业务逻辑(手工 ，自动化）—核心重要

界面测试：UI—外观美观，设计合理，友好—主观性强=需求文档(原型图，UI切图)----优先级会低

安全测试：高级类型—攻击 （工具（扫描–appscan，代码(脚本–sql注入)））—漏洞，薄弱===账号密码， http协议—>https协议

性能测试：高级类型—双十一 (访问人数多)–并发(1000)–资源，cpu,内存–正常处理(压力测试，稳定性，负载测试)

兼容性测试：软件+硬件;软件+软件(浏览器兼容)–调用；软件不同版本之间==APP升级(老功能，数据)

易用性测试：主观—人性化，舒适，用户使用习惯，用户体验–提bug===站在用户角度考虑，参考成熟产品

回归测试：regression text：测试—bug,开发修复bug(修改代码)验证bug其他没被修改的代码模块的测试，影响：上线之前–很多轮(2-4轮)的回归

冒烟测试：来源—硬件测试：电路板–通电–冒烟–短路被烧了===打回开发重做–软件测试：软件提测—核心业务功能，主流程—打回开发；–提高测试效率

探索性测试：发散测试–能力要求非常高：依据，方法===靠经验，积累，直觉

软件的生命周期&测试流程

1，软件生命周期

是软件开发研制到最终被废弃不用所经历的各个阶段。—软件开发模型

2.1，瀑布型生命周期模型

1.测试介人项目特别晚：回溯成本高

2.项目周期很长，效率低

2.2，V模型

1.测试介人早，可以提前对需求进行评审和测试–回溯成本减少

2.测试提前在测试文档(用例)----可以直接执行测试===节省准备文档时间–提高项目效率，周期拉短。

2.3，敏捷开发模型

​ 是一种以人为核心，快速迭代，循序渐进的开发方法。强调以人为本，专注交付对客户有价值的软件。是一个用于开发的维持复杂产品的框架，就是把一个大项目分为多个相互联系，但是也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

1，弱化文档。

2，人之间沟通。

3，软件测试工作流程图

3.2，软件测试的基本流程(重点)

测试需求分析

1，测试需求是什么？

• 测试需求主要解决“测什么”的问题，一般来自需求规格说明书中原始需求。
• 测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。

2，为什么需要软件测试需求？

简而言之：只有明确了测试需求，才能知道怎么去测试？什么时候开始测试？需要多少人测试？在什么环境上测试？------提炼测试点，时间规划，人力规划，测试环境。

3，测试点思路步骤

拿到项目的基本测试思路:(分析需求)

1. 明确一下这个项目是做什么的？基本业务逻辑流程。
2. 细化每一个功能，细化分析提取测试点。
3. 所有的细化模块的分析组合在一起 ===完成项目的测试点—功能
4. 非功能;界面，易用，兼容，安全性，性能压力。

测试点思路步骤如下：正常+异常–单个功能

1，正常功能：

是否可以正常提交–注册成功–单个功能冒烟测试。

2，单个功能项验证(正常+异常)：

规则：安顺序从上到下，对每一个输入项进行验证。

1）数据长度，数据类型，必填项验证，重复。

2）限制约束验证。

3）隐形需求：充分熟悉产品业务，挖掘隐形需求。

3，功能交互验证

模块之间传递的信息和数据，对存在功能交互的功能项。

4，非功能性测试：

界面，易用，兼容，安全性，性能压力、

测试用例设计方法

1，等价类划分的概念

​ 等价类划分法是把所有程序的输入域划分成为若干个子集合****(等价类)，然后从每一个子集合(等价类)中选取少数具有代表性的数据作为测试的输入数据。

​ 在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。–保证质量，减少测试用例数量–提高效率等价类划分有效等价类(正面,不会报错)和无效等价类(负面，抛出错误)。

2，等价类划分法用例设计步骤和原则

1. 分析需求，先确定其有效等价类，和无效等价类。
2. 在确立了等价类之后，建立等价类表，列出所有划分出的等价类。
3. 再从划分出的等价类中选择测试用例。
   • 设计一个新的测试用例数据，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；—减少测试用例的数量，避免重复，提高效率。
   • 设计一个新的测试用例数据，使其覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止—为了确定是哪个因素触发错误，每一个错误都被正确处理。

等价类划分的应用场景：当测试需要数据量过大，且数据操作可以分类时进行等价类划分。

3，场景法

​ 1,什么是场景法？

​ 通过场景描述的业务逻辑(业务流程)，也包括代码实现逻辑,设计用例来遍历场景(路径),验证软件系统功能的正确性。

​ 2,如何使用场景法

​ 2.1 画出流程图 --产品需求文档–画好了； --需要测试自己画

​ 矩形:表示步骤(操作，输入，输出结束)

​ 菱形:判断条件

​ 箭头:流向

​ 2.2 遍历场景，提取测试用例。

​ 1)覆盖正常路径

​ 2)走每一条分支

​ 3)出错步骤重新回到主流程图

​ 注意:场景法的重点是测试流程,因此每一个流程用例验证即可,流程测试没有问题并不能说明系统的功能没有问题,还需要针对单步的功能进行测试,

只有单个功能点和流程测试,才算是充分的测试+等价类,边界值----细化测试

4,错误推测法(反推法) —原则 步骤

​ 基于经验和直觉推测程序中存在的各种错误,从而有针对的设计测试用例的方法.

​ 它的要素共有三点,分别为:经验,知识,直觉.

​ 不单独使用–可以作为其他方法的补充

​

Bug的管理流程&禅道使用

1,bug的定义

​ 软件的bug,狭义概念是指软件程序的漏洞或缺陷,广义概念除此

之外还包括测试工程师或用户所发现和提出的软件可改进的细节(增强性,建议性),或与需求文档存在差异的功能实现等.

我们的职责就是,发现这些Bug,并提交给开发,让开发去修改

2,bug的类型–了解

常见的bug类型划分(禅道系统为例,可自定义):

代码(功能) 错误

界面优化—UI测试

设计缺陷 --优化建议

按照公司具体的规定来分类!!!

3,bug的等级

1. 致命错误:----blocker
2. 严重错误:----critical
3. 一般错误: --major
4. 细微错误: --minor
5. 改进建议–enhancement

4,bug的生命周期(管理流程) --重点

5,bug的跟踪管理流程

6, bug的跟踪管理—状态处理

7, bug的跟踪管理—缺陷管理工具

8, bug的跟踪管理—如何提交bug