软件测试基本功之——概念篇
《易经》曰：无极生太极，太极生两仪，两仪生三才，三才生四象，四象生五形，五行生六合，六合生七曜，七曜生八卦，八卦生万物。实乃可以说出了万物由来的至尊道理，由此我们可以推断出世界万物的生成都是有无极而来。我们也可从这方面推断出计算机方面，计算机归根结底是由机器码0和1组成，0和1就相当是两仪，八卦中的黑白，再往后就看把汇编当为三才等，由此可见，世间万物都是由最基本的东西组成，一切的东西最后推断到最后都是简简单单的，测试也是一样，推断到最后就是软件测试和硬件测试，对硬件不是很了解，在这就不写了。要想学好软件测试，首先就必须掌握一些软件测试的基本概念，就像我以前那样在还不懂性能测试到底是什么概念的时候，就去学那些性能测试工具，到最后测试出来的都不知道是不是性能问题，不知道性能测试需要关注网络环境，硬件配置，软件性能需求，数据库等，最后只知道测试的软件很耗资源，很卡，然后拿到个报告就不知道了，不会分析。说白了就是做了很多无用功，很多东西还是要从底层掌握，了解，慢慢就知道是怎么会事了，做什么基础好了，做起来就事半功倍。J，扯多了，下面就介绍一些我知道的，我了解的测试概念，也许几年后来看由是不一样的想法o(∩_∩)o…
软件测试概念：
标准定义：使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果的差别。
我的理解：就是保证你的软件按照用户的需求做了该做的，其它的一概不要存在。
软件测试的目的：
用户角度：
希望通过软件测试来发现软件中隐藏的错误和缺陷，尽量的符合用户的需求，而来考虑是否接受该产品
开发者角度：
希望测试表明软件产品不存在错误和缺陷的过程，验证软件以正确实现了用户的需求，确立对软件质量的信心。
测试者角度：
以最少的时间和人力，执行测试来尽可能暴露出软件的各种错误和缺陷，收集测试结果数据为可靠行分析提供依据，验证软件所有的功能符合用户的需求并确保顺利发布产品。
Myers软件测试目的
(1)测试是程序的执行过程，目的在于发现错误；
(2)一个好的测试用例在于能发现至今未发现的错误；
(3)一个成功的测试是发现了至今未发现的错误的测试。
软件测试原则：
1， 所有的软件测试都应追溯到用户需求
2， 应当把“尽早地和不断地进行软件测试”作为测试者的座右铭
3， 完全测试是不可能的，测试需要终止
4， 测试无法显示软件潜在的所有缺陷；
5， 充分注意测试中的群集现象
6， 程序员应避免检查自己的程序
7， 严格按照测试用例执行测试，尽量避免测试的随意性
8， 保存好所有的测试文档，包括测试计划，测试用例，测试结果，测试报告，出错统计，最终分析报告等，为维护和后续版本测试提供方便
9， 写测试用例和执行测试用例的人尽量分开
10，测试尽可能按照制定的流程走
软件测试的不同分类：
1，按是否关心软件内部结构和具体实现的角度划分
A：黑盒测试：black-box testing
说白了就是根据需求和功能来测试，并不需要知道软件内部的代码和设计是这样实现
的。
B：白盒测试：white-box testing
这个就需要根据软件内部代码的具体实现情况，比如内部逻辑实现，语句，分支，路径和条件的覆盖率。其实就是去研究源代码和程序结构。
C：灰盒测试：monkey testing
灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
2，按照是否执行程序的角度划分
A：静态测试：static testing
不利用计算机运行待测程序，而只是静态地检查程序代码，界面或文档中可能存在的错误的过程
B：动态测试：dynamic testing
实际运行被测试程序，输入相应的测试数据，检查输出结果和预期结果是否相符合的过程
3，按照软件开发的过程按阶段划分
A：单元测试：unit testing
对软件中的最小可测试单元进行检查和验证。这个单元可以是一个函数，一个类，一个窗口，一个功能等，就是你认为最小的被测试的模块。
单元测试主要根据单元测试计划（根据详细设计），单元测试用例来执行，主要是白盒测试方法，一般先进行静态代码检查测试，再进行动态测试。
单元测试的任务一般包括：
1模块接口测试；2模块局部数据结构测试；3模块边界条件测试；4模块中所有独立执行通路测试；5模块的各条错误处理通路测试
B：集成测试：integration testing
集成测试是单元测试后的下一个阶段，是将单元测试成功的各个模块，类或函数组成系统或子系统，重点测试各个单元模块的接口，组合后的功能是否正确。
一般集成测试和单元测试是同步进行的，集成测试的依据为单元测试的模块和概要设计。
提交集成测试计划、集成测试规格说明和集成测试分析报告。
集成测试的策略主要有自顶向下和自底向上两种
C：确认测试：confirmation testing
验证软件的功能和性能及其它特性是否与用户的要求一致
D：系统测试：system testing
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等
E：验收测试：acceptance testing
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现
场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试
F：回归测试：regression testing
回归测试一般在软件维护阶段，测试先前测试过并修改过的程序，确保更改没有给软件其它未改变的部分带来新的缺陷，软件修改或使用环境变更后都要执行回归测试。
4，其它类型测试
1，功能测试：functioncal testing
一种黑盒测试，通过对组件/系统功能规格说明的分析而进行的测试
2，Alpha测试：
在开发进行结束的时候进行测试，针对测试的结果可能还会进行一些小的设计更改，这类测试一般由用户和开发者或测试人员共同参与。
3，BETA测试：
当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。
4，压力测试：stress testing
指持续不断地给被测试系统增加压力，直到被测试系统压垮为止，用来测试系统最大
承受能力
5，性能测试：performance testing
被测试软件在正常的软硬件环境下运行，收集到的一些性能。
6，负载测试：load testing
指被测试系统在其能忍受的压力的极限范围下连续运行，来测试软件的承受度
7，容量测试：volume testing
容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
8，兼容性测试：
测试系统在不同的平台/硬件/操作系统/网络上的表现情况
9，易用性测试：
测试程序是否符合用户使用习惯，人机相互操作是否够人性化。
10，可靠性测试：reliability testing
指连续运行被测软件，检查软件运行时的稳定性。
11，安装和反安装测试：
在正常情况/异常情况下测试完全，部分或升级的安装/反安装过程
12，安全测试：safety testing
测试系统对内部和外部非法入侵，故意损坏的表现情况。（可能需要了解更多的安全知识）
13，恢复测试：
测试当出现崩溃，硬件错误或其它灾难性问题时，系统的表现情况
14，文档测试：
测试开发提交/测试产生的文档是否全部齐全，全部符合要求
15，界面测试：
测试软件界面是否人性化，是否符合大部分人的使用习惯而进行的测试
软件测试结束标准：
1，是否达到原先定义的覆盖标准。
比如原先定义测试95％的功能条目，测试100％的需求条目，只对接口类做集成测试等等。达到标准了就停。
2，所发现的缺陷（bug或者功能不足等等）低于预先定义的上限。
比如定义每周发现的缺陷少于5个，即可停止。
3，找到缺陷耗费的代价超过这个缺陷可能导致的损失
这个的依据是：权限开始好找，越到后面越难找。具体操作的时候可以根据公司实际情况来定义什么样的情况算是“花费的代价大”
4，团队集体同意（开发，管理，测试，市场，销售人员）
由于利益和市场的原因，必须推出产品了。哪怕有bug也得上了。
（其它情况看各个公司的不同）
因篇幅问题不能全部显示，请点此查看更多更全内容