软件测试开发基础

1、软件测试的六个原则

1、 所有测试的标准都是建立在用户需求之上。所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此测试应依照客户的需求配置环境，并且按照客户的使用习惯进行测试并评价结果。

2、软件项目一启动，软件测试就已经开始，即软件测试应尽早介入。软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早地开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制订出完善的计划和方案，提高测试的效率。

3、穷尽测试是不可能的。由于时间和资源的限制，进行完全(各种输入和输出的全部组合)的测试是不可能的测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。

4、遵循GoodEnough原则。GoodEnough原则是指测试的投入与产出要适当权衡。

5、缺陷存在集群现象，二八原则：20%的模块中存在80%的缺陷。

6、杀虫剂现象。避免缺陷免疫。

我们都知道虫子的抗药性原理，即一种药物使用久了，虫子就会产生抗药性。而在软件测试中，缺陷也是会产生免疫性的。同样的测试用例被反复使用，发现缺陷的能力就会越来越差;测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定式。

要克服这种情况，就要不断对测试用例进行修改和评审，不断增加新的测试用例，同时，测试人员也要发散思维，不能只是为了完成测试任务而做一些输入和输出的对比。

另外：

7、测试用例是设计出来的，不是写出来的。

8、第三方进行测试会更客观，更有效。

9、需求阶段应定义清楚产品的质量标准。

10、软件测试计划是做好软件测试工作的前提。

11、始终保持“质量第一”的觉悟，当时间和质量冲突时，时间要服从质量。

2、软件测试的分类

冒烟测试：

是对软件的基本功能进行测试，测试对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，保证软件系统能正常跑起来，可以进行后续的正常测试工作的进行，如果最基本的测试都有问题了，就直接打回开发部了，所以正式交付的测试版本，必须先通过冒烟测试的考验。

冒烟测试只是一个测试活动，贯穿于测试的每一个阶段。单元测试，集成测试和系统测试里都会有冒烟测试。

我们如何确保开发人员修复了bug后，这个bug的修复没有影响到其他功能模块呢？这时就需要进行冒烟测试啦。

由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：

1. 代码中进行了什么更改。若要理解该更改，开发人员可以提供相关说明。
2. 更改对功能有何影响。
3. 更改对各组件的依存关系有何影响。

在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。

测试经理和项目经理等相关人员从测试用例库中选定重要的测试用例，标记为冒烟测试用例。或者单独编写。

1、主流程和主功能的确认

要求测试人员在测试开始前跟开发人员确认需求和重要的流程、功能，最好将功能点和流程以及预期结果和开发人员说明清楚。冒烟测试不要求测试结果像正式测试阶段那么准确，但是也需要列一个指标来衡量测试是否通过。）

2、预计时间

根据列出的功能点和开发人员代码质量的可信度，评估冒烟测试在不同环境下可能花费的最长和最短时间，列到测试计划中。

3、数据的准备

在测试前，透彻的了解主要功能对应表的存储结构，准备好需要的数据。冒烟测试开始后，不会因为这些工作浪费时间。

五、执行

测试人员严格按照前期的约定去校验主流程，全部校验完和开发人员报告情况，不能放过一个主要的测试功能点。

软件开发阶段划分：

1）、单元测试：
指对软件中的最小可测试单元进行检查和验证，单元测试需要从软件的内部结构出发设计测试用例。多个模块可以独立地进行测试。单元测试的策略：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析。

2）、集成测试：
组装测试/联合测试：将所有模块按照设计要求组装成子系统或者系统进行集成测试。

3）、系统测试：
将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试 和确认测试，系统测试是针对整个产品的测试。

4）、验收测试：
交付测试：确保软件准备就绪。

测试技术划分：

1）、白盒测试：
结构性测试/透明盒测试/逻辑驱动测试/基于代码的测试。

白盒测试方法：

六种覆盖方法中，覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

其中，

语句覆盖是使得程序中每个语句至少被执行一次；

判定覆盖是使得程序中的每个分支至少都通过一次；

条件覆盖是使得判定中的每个条件获得各种可能的结果；

判定/条件覆盖是使得判定中的每个条件取到各种可能的值，并使每个判定取到各种可能的结果；

条件组合覆盖是使得每个判定中条件的各种可能组合都至少出现一次；

路径覆盖，覆盖程序中所有可能的执行路径，包括循环、条件组合，分支选择。

2）、黑盒测试：
功能测试：通过测试每个功能是否都能正常使用。（输入数据/输出数据）。

黑盒测试方法：

不关心程序内部逻辑，只根据程序功能说明来设计测试用例；分为：等价类划分法，边界值分析法和错误推测法，因果图法，决策表法，场景法。

根据不同的测试阶段，测试可以分为单元测试、集成测试、系统测试和验收测试。 体现了测试由小到大、又内至外、循序渐进的测试过程和分而治之的思想。 单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。 系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。 验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

3）、灰盒测试：
介于白盒测试和黑盒测试之间的一种测试方法：不仅关注输出、输入的正确性，同时也关注程序内部的情况。

被测试软件是否实际运行划分：

1）、静态测试：
指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

对于代码测试：主要测试代码是否符合相应的标准和规范；
对于界面测试：主要测试软件的实际界面与需求中的说明是否相符；
对于文档测试：主要测试用户和需求说明是否符合用户的实际需求；
2）、动态方法：
指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性、健壮性等性能。

测试实施组织划分：

1）、开发方测试：
验证测试/α测试

2）、用户测试：
β测试

3）、第三方测试

压力测试

是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等

静态测试

不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。

确认测试

检验所开发的软件是否满足了需求规格说明中确定了的各种功能和性能需求，以及软件配置是否完全和正确。一般在系统测试前。

确认测试主要指的是一个阶段，但是无论怎样，都与可靠性、安全性等不冲突，因为不是一个纬度，即在确认测试阶段即可以做可靠性测试，也可以做安全测试（当然这些类型测试最好放在系统测试阶段）

国际标准中没有对于确认测试的定义，就连软件测试的定义都没有绝对统一的，所以对其理解应该本着从传统概念提出到不断演化的柔性理解，而不是死认定义。
安全性测试

目的在于检查系统对非法侵入的防范能力，验证安装在系统内的保护机构是否确实能够对系统进行保护，使之不受各种干扰。

(1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(2) 加密机制
(3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
(4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
(5) 防病毒系统
软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

用户认证安全的测试要考虑问题：

• 明确区分系统中不同用户权限
• 系统中会不会出现用户冲突
• 系统会不会因用户的权限的改变造成混乱
• 用户登陆密码是否是可见、可复制
• 是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）
• 用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统
• 系统网络安全的测试要考虑问题
• 测试采取的防护措施是否正确装配好，有关系统的补丁是否打上
• 模拟非授权攻击，看防护系统是否坚固
• 采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，
• 现在最常用的是 NBSI 系列和 IPhacker IP ）
• 采用各种木马检查工具检查系统木马情况
• 采用各种防外挂工具检查系统各组程序的外挂漏洞

数据库安全考虑问题：

• 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）
• 系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）
• 系统数据可管理性
• 系统数据的独立性
• 系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）
   

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环

境下进行的受控测试，Alpha 测试不能由程序员或测试员完成。

β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在

测试现场，Beta 测试不能由程序员或测试员完成。

兼容性测试

检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。

兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。

兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。

兼容和配置测试的区别在于，做配置测试通常不是Clean OS（比较纯净的系统环境，除OS和基本驱动外无其他应用程序。类似于安全模式的最基本启动环境）下做测试，而兼容测试多是在Clean OS的环境下做的。

恢复测试

主要目的是检查系统的容错能力。通过采用多种人工干预方式使系统失效，检验系统的恢复能力。

3. 缺陷

缺陷的表现形式：

软件没有实现产品规格说明书所要求的功能模块；
软件中出现了产品规格说明指明不应该出现的错误；
软件实现了产品规格说明中没有提到的功能需求；
软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；
软件难以理解、不易使用、运行缓慢、用户体验不友好；
产生软件缺陷的原因：

需求不清晰；
系统结构较为复杂；
对程序逻辑路径或者数据范围考虑不全面；
确保设计时间的精准同步；
存在系统性、可靠性的隐患问题；
系统运行环境的复杂；
通信端口较多时影响系统的安全性、适用性；
设计技术系统兼容的问题；
缺陷的属性：

缺陷标识：标识唯一；
缺陷类型：缺陷种类；
缺陷严重程度：指因缺陷引起的故障对软件产品的影响程度；
缺陷优先级：指缺陷必须被修复的紧急程度；
缺陷状态：通过一个跟踪修复过程的进展情况；
缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段；
缺陷来源：引起缺陷的原因；
缺陷根源：反正错误的根本因素

4. 测试用例

特征： 

1、测试用例具有代表性：测试用例能够代表并覆盖各种合法的和非法的、合理的和不合理、边界的和越界的以及极限的输入数据、操作和环境设置等。

2、测试结果是可判定的：测试执行结果的正确性是可以判定的，每一个测试用例都应有明确的期望结果，否则将难以判断系统是否正常运行。

3、测试结果可以再现：对同样的测试用例，系统的执行结果应当是相同的。

 原则：

1. 使用成数的测试用例设计方法来进行设计；
2. 保证测试用例数据的正确性和操作的正确性；
3. 确保测试用例具有一定的代表性；
4. 每个测试用例应该针对单一的测试项；
5. 保证测试结果是可以判定并且可以再现的；
6. 保证测试用例描述准确、清晰、具体；
7. 测试用例设计应满足项目的时间、人员和资金要求；

测试用例的基本要素

要素名称	含义
功能模块	待测试模块名称
功能特征	待测试模块功能特征
测试时间	测试进行时间
用例编号	唯一标识该测试用例的值
输入数据	测试需要的数据列表
操作步骤	按照操作步骤的顺序，准确详细的描述
期望结果	按照规格设计所要求的的正确结果
优先级	依据重要程度确定优先级
预置条件	测试进行时的前置条件
测试类型	该用例是功能测试/冒烟测试/接口测试/性能测试等