1、软件测试的六个原则

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

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

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

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

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

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

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

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

另外：

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

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

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

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

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

2、软件测试的分类

软件开发阶段划分：

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

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

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

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

测试技术划分：

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

白盒测试方法：

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

其中，

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

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

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

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

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

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

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

黑盒测试方法：

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

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

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

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

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

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

测试实施组织划分：

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

2）、用户测试：
β测试

3）、第三方测试

压力测试

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

静态测试

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

确认测试

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

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

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

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

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

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