软件测试理论总结

1、为什么要测试？软件测试的目的？软件测试的重要性？

A、发现缺陷BUG/Defect

B、评估软件、项目、产品上线风险？

C、满足客户要求、改善软件质量

D、帮助开发发现问题、定位问题、修改问题

E、软件验收、也包括第三方的验收（验收测试、UAT）

F、通过缺陷分析，从而预防同类缺陷的发生。

G、错的：软件测试能缩短开发周期。也不能直接降低开发成本。

H、改善软件的用户体验（易用性、性能、稳定性）12306订票

角度：系统性思维（1、2、3、4、5、6、7+=100: 1+2+34+56+7=100）门萨测试

角色：用户：发现缺陷、改善用户体验

：开发：证明软件GoodEnough，定位缺陷，从而减少开发修改问题的时间

历史：证明程序是正确？--》发现功能缺陷、错误--》发现不足（易用性、性能、稳定性）--》缺陷预防

现实：验收、评估质量风险、第三方评测、为了盈利而测试（商业成功）（测试成本《《软件缺陷导致成本）

2、什么是软件测试？

IEEE（国际电器电子工程协会）：目的：验证系统是否满足需求、验证实际结果跟期望结果的差异？

xll：在一定的软件、硬件、网络环境下（搭建测试环境LAMP），遵循相对规范的测试流程，使用合适的测试工具，合理的测试方法，测试或运行软件，其目的是为了验证系统是否满足需求、验证实际结果跟期望结果的差异。

3、软件测试的工作内容？

BAT：Baidu、Alibaba、Tecent

4、测试与调试的区别：

对象：代码、文档；代码

人：测试工程师；开发

流程：有规范的流程（除了随机测试和探索性测试外）；无流程

目的：发现问题；定位和解决问题

5、测试的七大原则：

A、测试只能证明软件存在缺陷，不能证明软件没有缺陷（证伪不证真）

B、测试是无法穷举？（输入数据是无法穷举、处理逻辑路径是无法穷举），学习测试用例的设计方法。

C、测试应该尽早测试？（发现缺陷和修改的成本越早越低。需求-设计-代码-测试-运行）

测试应该在需求之后？设计之后？编码之后？测试应该尽早介入，测试应该贯穿整个软件生命周期。

D、缺陷的80/20原则（群集效应）。如果测试发现某个模块有问题？继续深入测试。刨根问底？破案？

E、杀虫剂悖论（软件对用例会免疫力）不断更新测试用例、更新的测试思维

F、测试依赖于商业背景（与行业知识相关）结合专业和工作经历和准备相关的项目。优点 SWOT

优势、劣势、机会、威慑（竞争对手）准备行业软件

G、不存在缺陷的软件并不代表是有用的系统。

一个合格、优秀、卓越、伟大的测试工程师的能力与素质的要求？

素质、性格、能力、管理、英语、行业六大维度回答

答

6、测试与开发的关系（独立性）

未来趋势：3大趋势：1、测试与开发的结合越来越紧密；2、测试与行业背景结合越来越紧密

3、专项测试（测试分工会越来越精细），大数据测试（数据库，用户工程） IT，DT。

比较分析不同网站的购物流程：亚马逊、当当网、京东、淘宝（CDC）联众游戏、QQ游戏

1、测试人员也开发，开发也做测试（Google：吃狗粮的文化）

2、测试人员独立与项目（在项目中有专职的测试人员：客观）

3、测试人员独立部门（有专门的测试部门：权威）

4、测试人员独立技术（测试工具部、测试技术部）

5、测试人员独立于公司（测试服务机构或者公司）

缺点：沟通越困难，对产品或者项目的熟悉越少。感情色彩：这是个非常严重的bug！！！！！

测试人员发现了BUG，开发人员不愿意修改，该怎么办？

加班？敏感问题？三方思考：对方、客观中立、自己

地铁自动售货机 PM

1、计划阶段：可行性分析：A、经济可行性分析；B、技术可行性分析（外包）

计划项目里程碑：计划、需求SRS、概要设计HLD、详细设计LLD、编码、测试、运行与维护

输出软件项目计划 SPP（Software Project Plan）PM

输出软件确认与验证计划 SVVP(Software verfication Validation Plan)软件测试计划 TPM

2、需求阶段：产品（金蝶）：调研与项目（用户） SE 系统工程师 what to develop？黑盒

TSE 分析测试需求挖掘用户的隐性需求

需求规格SRS：功能需求：1、接受货币 2、选择商品 3、计算功能 4、输出商品和找零、5、商品管理

性能需求：30S之内输出商品和找零

可靠性需求：7X24小时

易用性需求：良好易用性，不需要培训。最好用的软件baidu

需求分析的技术：UML建模（需求工程）

3、设计阶段：概要设计HLD （High Level Design 高层设计）：模块分解与接口的定义。

1、接受货币（识别真伪、识别面额、识别类别）分解原则？高内聚低耦合？（百度）

（无直接耦合、数据耦合、印记耦合、控制耦合、公共耦合、内容耦合）回归测试

2、接口：函数接口、消息接口、文件接口（QQ修改头像）、数据库接口

详细设计LLD（Low Level Design 底层设计）：算法的描述（程序=数据结构+算法/思路（各种排序））流程图、伪码。白盒

4、编码阶段：熟悉一门编程语言的语法 C、Java、PHP和一个开发工具或者平台 VC、Eclipse等

熟悉一门脚本语言：python、ruby、perl、tcl、shell BAT

5、测试阶段：测试工具、方法、流程

6、运行与维护：技术支持

测试应该贯穿整个软件生命周期。

1、测试应该在SRS之后？

HLD

LLD

CODE

瀑布模型：缺点：不适应需求变更频繁的项目。适合产品开发的项目。测试滞后于开发。

V模型：

用户需求URS-----------------------------------------验收测试UAT（User Acceptance Testing）

需求规格SRS---------------------------------系统测试ST（System Testing）

概要设计HLD-------------------------集成测试IT（Integration Testing）

详细设计LLD-----------------单元测试UT（Unit Testing）

编码CODE------------代码评审CODE Review

H模型、X模型。

1、方法的背景？2、方法的操作步骤、3、优缺点、4、适用范围、5与其他方法怎么样配合、6重点、要点、难点

等价类：

1、背景：why？输入无法穷举，我们不能测试所有情况，必选选择有代表数据来验证

2、操作步骤：

1、分析被测试对象输入条件以及子条件（关键点：考虑隐性子条件，条件正交完备）

2、根据等价类划分原则划分有效等价类和无效等价类

原则：1、规定范围或者格式，譬如长度6~18位，可以划分1个有效、2个无效等价类

2、规定的集合或者满足某个条件，譬如一些下拉列表的选择，可以划分1有效、1个无效

3、规定了必须如何，譬如组成、开头，可以划分1个有效和若干个无效。

4、规定是布尔量，譬如是否已经注册，可以划分1个有效和1个无效

5、规定是多种选择（还有不同的处理方式），譬如163邮箱注册的后缀，可以划分成若干个有效，和1个无效。

3、根据等价类设计用例原则：（1、用一个用例覆盖尽可能多的有效等价类；

2、为每一个无效等价类单独设计用例：为了更好定位问题）设计数据

原则：同样效果情况下用例数尽可能少，精确定位问题。

3、优缺点：适用范围广、能以有限用例达到比较好覆盖无法穷举的输入。

缺点：方法没有刻意考虑边界，只能针对单个输入条件，没有考虑输入之间组合以及输入与输出的关系。

4、适用范围：只要有业务规则的情况下，最好是有清晰的业务规则

5、与其他方法怎么样配合：一般情况下会跟边界值方法结合使用。

6、要点：等价类划分的原则：尤其是要注意隐性条件（完整性，不要遗漏）

思考：微信发送图片、上传QQ头像、导入文件这类如何使用等价类

边界值：

1、背景：why？：很多错误通常都发生在边界上。

2、操作步骤：

1、分析被测试对象输入条件以及子条件

2、分析上点、离点和内点

3、根据边界值设计用例的原则设计数据去覆盖可能上点、离点和内点

3、优缺点：优点：能够比较高效发现问题

缺点：不能考虑输入与输出之间的关系

4、适用范围：规定了大小、长度、值的范围、分辨率（广义）

5、与其他方法怎么样配合：与等价类配合

6、要点：找到边界（隐含的边界）

航空行李托运：重量不能超过30公斤，如果超过就要收费，正常人4元每公斤，外国人收6块，头等舱是其他舱的2倍

残疾人是正常人的1/2.

判定表/决策表：

1、背景：why？：输入条件很多情况（要么满足、要么不满足），不同条件组合下输出结果也很多，希望条件跟结果的一一对应的关系

它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确

2、操作步骤：

1、分析被测试对象的输入条件，同时分析各种可能的输出结果（）

2、列出所有的条件和动作（）

3、填写条件项和动作项

4、合并相似规则

3、优缺点：优点：能解决复杂条件之间逻辑组合，比较清晰列出所有的组合

缺点：一旦条件数过多，组合数会很庞大，合并存在漏测的风险（很难精确定位问题）。

对于条件，只能是有两种取值（为真、为假）

4、适用范围：条件只有两种取值的多条件组合的例子

5、与其他方法怎么样配合：与因果图

6、要点：找出业务条件规则，列出各种可能输出结果。（测试象棋马走日这个规则）当条件比较多>5 要考虑是否有中间结果（简化）

正交试验法

1、背景：弥补判定表方法可能导致用例规模非常庞大，多条件组合的数量非常巨大。

根据伽罗瓦理论，条件之间的两两组合如果不出问题，三三组合以上出问题的概率小，这样

一来，可以用非常少的用例来达到比较好的测试效果。

2、操作步骤：

1、分析输入条件以及条件的取值范围。（筛选出来的条件之间没有约束关系）

2、选择合适的正交表（计算需要最小正交表的试验数，然后分两种：

1、单一水平：去挑选比需要大但是是最接近的正交表，直接套用；合并去匹配正交表-->分解

2、混合水平：）

保证试验数最少

3、根据正交表（拆分之后）设计测试数据（每一列行是一个测试项），如果是空的地方，可以根据实际需要加权处理。

3、优缺点：优点：在保证一定均匀覆盖率的前提下可以大大降低试验次数（测试项），缺点：可能有一定的遗漏

4、适应范围：配置类需求的分析，多条件多取值的业务测试。

5、与其他方法配合：等价类和边界值（输入框）

6、要点：选择合适正交表以及如何去合并和分拆！

Use Case法/场景法/流程分析法

1、背景：在实际工作中，我们很业务功能是通过工作流来实现，需要站在流程角度（用户角度），譬如购物流程

安装测试、转账流程、游戏场景

2、操作步骤：1、分析业务的基本事件流和备选事件流（正常备选事件流和异常事件流（退出））担心备选流有遗漏

2、画出事件流图（Use Case图用例图）

3、根据图设计场景

4、根据场景来设计测试数据

3、优缺点：优点：站在用户的角度来测试（），可以很好地与开发配合，直接通过用例图转化，效率比较高

4、适应范围：验收测试用例的设计，只要流程

5、与其他方法配合：等价类、边界值（选多少个备选流）

6、要点：事件流分析，尤其是备选流的分析是最关键的地方。思路比较清晰，比较广

网银转账：写出基本流和备选，并且画出事件流图。

影响软件质量的因素：

技术：1.现有的技术：人

2. 技术沉淀：技术文档，专利技术，指导书，问题库，经验库

流程：流程可以提高软件透明度，控制项目的进度，帮助项目组预防风险。

组织：组织体现的是管理

1. 让合适的人去做合适的事情

2. 流程的推动需要组织强有力的保障

软件质量管理体系

1. ISO9000

八项质量管理原则：

以顾客为中心：以用户的角度去思考问题（UAT）

下游环节为上游环节的客户

领导的作用：有激情，有谋略，演讲才能，身先士卒

全员参与：团队合作信任

基于事实的决策方法：个人能力基线（PCB）（量化管理）

持续改进（持续改善）：最初是日本的一个管理理念，从初级员工到高级管理者都需要参与

互利的供方关系：共赢，共同创造利润

过程方法：

过程：输入转化为输出的活动

过程方法：过程的识别，相互作用以及管理

管理的系统方法：全局化的管理策略

2. CMM

-- 初始级：

手工作坊式，个人英雄主义，没有相关过程，不可预测并且缺乏控制。

-- 可重复级：特点 ->可以重复以往的项目经验

证券项目（招商证券）

国信证券：

SRS

HLD

LLD

Code

test case

模板

关键过程域（KPA）（key process area）：

需求管理

配置管理

软件质量保证

--已定义级

统一标准，一致的过程（软件工程小组SEPG）

关键过程域：同行评审

--已管理级：可预测的过程

量化管理，通过数据量化，来实现预测项目

Gompertz模型

--优化级：对过程的持续改进

新技术或新思想的引入

关键过程域：缺陷分析-》预防缺陷 -》质量标准

CMM与CMMI的区别

CMM：阶段式表示

CMMI：阶段式、连续式

3. 六西格玛

六西格玛管理法原则：

注重客户

注重流程

全员参与

预防为主

事实依据的决定

持续和突破性改进

六西格玛的实施方式：

DMAIC (define, measure, analysis, improve, control)

软件质量模型：

功能性

适合性：软件产品为指定任务或用户目标提供一组合适的功能的能力

准确性：软件产品提供所需要的精确度或和结果相符的能力

互操作性：软件产品与一个或更多的其他系统进行交互的能力

保密安全性：保护信息和数据的能力，不同权限的人可以操作不同的数据

功能性的依从性：遵守与功能性相关的标准，约定或法规的能力（国际标准，国家标准，行业标准，企业内部标准）

可靠性

成熟性：软件产品为避免由于软件中的错误而导致失效的能力

容错性：由于用户操作错误，软件可以处理相应的错误，而不是死机或崩溃

易恢复性：在失效已经发生的情况下，软件产品如何快速恢复使用的能力

可靠性的依从性：软件产品遵循与可靠性相关的标准或约定或法律法规

易用性

易理解性：软件产品使用用户能理解软件是否合适以及如何能将软件用于特定任务和使用环境的能力。

易学性：软件产品使得用户能学习其功能的能力（操作手册，帮助文档）

易操作性：软件产品使用户能操作和控制它的能力

吸引性：软件产品吸引用户的能力。界面美观，易用性要好

易用性的依从性：软件产品的易用性遵循相关的标准或法律法规

效率

时间特性：在规定的条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。也就是完成用户的某个功能需要的时间

资源利用率：在规定的条件下，软件产品执行其功能时，使用合适的资源数量（CPU，内存占用）

效率依从性：软件产品遵守与效率相关的法规

维护性

易分析性：软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。（日志记录）

易改变性：修改缺陷的能力，实现功能的能力。（代码要高内聚，低耦合）目的在于降低修改软件的成本

稳定性：软件产品避免由于软件修改而造成意外结果的能力

易测试性：软件产品的问题能被确认的能力。定位问题的能力

维护性的依从性：软件产品的维护性遵循相关的标准

可移植性：

适应性：软件产品适应不同的环境的能力

易安装性：被安装的能力（一键安装）

共存性：和其他软件共同安装或存在的能力

易替换性：升级时替换文件的能力

可移植性的依从性：软件产品的可移植性遵循相关的标准

软件质量活动：

软件质量保证（ＳＱＡ）：从流程方面保证软件质量

　测试：从技术方面保证软件质量

度量：

作用：理解，预测，评估和改进

度量的分类：四个基本度量项：规模工作量进度缺陷

BUG属性：

发现人 reporter

发现时间 date

缺陷状态 status (new, open, resolved, reopened, closed) （fixed, duplicated, Invalid, won't fix, postpone）

缺陷版本 version

缺陷所属的产品/项目/模块 product, project, feature

缺陷编号 no

缺陷严重程度serverity

缺陷优先级 priority

标题 title

详细描述 description

系统环境 OS (服务器环境和客户端环境)

测试环境（用户名/密码）test environment

重现率 repository

预置条件pre condition

步骤 steps

实际结果 actual result

期望结果 expected result

其他信息 additional information

用例编号testcase no

*附件 attachment

==================

缺陷引发的原因 root cause

缺陷解决方案 resolution (改代码，数据库，环境问题)

代码改动范围

影响范围

==================

验证人

验证环境

验证范围

结果

本文来源：https://www.2haoxitong.net/k/doc/fa260d11f8c75fbfc67db23f.html