软件测试的概述
软件测试部门和软件开发部门有一定类似的架构，如图：
对于实际的生产环境，软件测试人员也同样是必不可少的，一般来说，开发一个软件大体上需要经历如下的阶段：项目启动阶段：市场、需求调查分析->项目规划阶段：为拟研发的软件项目制定一个详细的解决方案->项目执行阶段：准备及实施项目开发测试、项目信息入档管理等->项目控制阶段 ->项目流程、进度、费用、资源、风险、质量等的控制->项目收尾阶段：项目验收交接等等收尾工作（具体查看软件项目管理流程，这里就不一一赘述了）：
由上述结合实际生产，我们可知，软件的质量靠什么，靠管理、靠各个软件过程的严密配合。但勿庸置疑，质量的守护是靠测试。因此，在项目开发过程中，软件测试也是同样重要的。
- 软件测试是为软件项目服务的，以提高软件质量，降低软件项目的风险；
- 内部风险
- 指在即将发布的时候发现有重大的错误，从而延迟发布日期，失去市场的风险
- 外部风险
- 指用户发现了不能容忍的错误，引起索赔、法律纠纷、以及用于客户支持的费用甚至失去客户的风险。
- 内部风险
- 软件测试只能证明软件存在错误，而不能证明软件没有错误。
- 目的：
- 为了寻找错误并尽可能地为修正错误提供更多的信息；
- 为了证明软件有错误而不是证明软件没有错误；
- 成功的测试在于发现至今为止都没有发现的软件缺陷。
- 作用：
- 发现并管理缺陷；
- 度量质量：
- 评价工作效率和效果
- 预期项目风险
有一个例子，微软公司的经验：DEV（development version）:QA（QUALITY ASSURANCE） = 1:2，开发的版本和质量的保证为1：2的关系。
我们经常打游戏时会发现，有的游戏是会说明所需的电脑硬件配置的，对此我们反过来看，软件的测试往往也要测试他在不同配置的硬件上的运行测试的效果。软件测试的“成功”与“失败”就在于能否发现错误！没有任何人可以保证，我们研发的程序在任何操作系统上，任何硬件环境中运行，都没有任何错误。
同时，软件测试贯穿于软件定义与开发的整个周期，软件的需求规格说明书，结构设计及程序编码，都属于软件测试的对象。
当然，在实际中，测试任务不仅仅由测试人员完成，参与开发的每一个人也在始终进行测试。我的专业是软件过程，而我的发展规划是JAVA开发工程师，但是我依旧开始对这门学问做起了研究。
我们一般都会听到黑盒测试、白盒测试、灰盒测试；黑盒测试就是代码隐藏，只面向程序设计的高层，白盒测试是代码可视，同时程序设计的高层也可见而灰盒测试是部分代码可见，相当于前两者混合起来。
API(Application Programming Interface 应用编程接口)测试都是白盒测试，GUI（Graphics User Interface 图形用户界面）系统测试是高度黑盒测试，对于任何要发布给大众的软件项目系统，我们都要进行白盒测试，而是否要采用混合测试是由产品团队决定的。
具体的测试类型如下：
- 版本确认测试
- 可接受性测试
- 功能测试
- 单元测试（模块测试）
- 组件测试
- 系统测试
- 压力测试
- 配置测试
- 回归测试
- 文档和帮助文档测试
- 安全测试
- 安装测试
- 每天进行一个简短的创建测试(通常是不超过20分钟), 为了确保产品没有严重的崩溃现象
- 不必进行深层功能性检测
- 随着开发周期的进行, 增加需要
- 如果BVT可以通过, 这个版本就可以投入测试了
- 如果BVT失败, 这个版本宣告失败，而且不再用于测试
- 其目的是自动识别此版本是否值得测试
- 也被称作Smoke测试
- 变化的测试长度用来确定在开发人员进行产品改进之后,能否保持最基本的功能
- 处于 BVT测试和深层功能测试之间的一种测试
- 也可是一系列的手动测试
- 通常在开发人员确认改变代码之前进行
- 如果通过, 代码可以被存档
- 如果失败, 开发人员需要在代码存档前做更多的改进工作
可接受测试是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会轻易的就出现程序挂起或崩溃的状况。如果一个新版本没通过可测试性的验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正。
- 涵盖需要测试的全部功能，是一种更复杂，范围更广的测试
- 测试目标:
- 覆盖100% 产品功能
- 覆盖 >75% 的分支
- 不是100% 代码覆盖率
- 可能涉及边界条件和等价类
- 这类的测试通常组成了压力测试的基础
验证测试软件功能能否正常按照它的设计工作。看运行软件时的期望行为是否符合原设计。比如，测试Microsoft Excel插入->符号的功能包括测试能够在Microsoft Excel所选单元格中正确地插入符号并且显示正确符号、能否正确显示使用不同的字体的符号。
- 针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。
- 单元 = 代码的最小功能模块
- 进行功能测试
- 组件 = 代码交互的单元
- 综合测试
- 系统测试：将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。
- 系统 = 组件间的交互
- 它通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如，在最低的硬盘驱动器空间或系统记忆容量条件下，验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机。
- 一直运行的测试，直到程序运行失败
- 不必提供用户可用参数
- 可升级，压力级别由浅入深
- 范围可伸缩，可用于从单元到系统范围
- 标准和基本的度量决定产品的质量
- 通过不断的检测度量来发现稳定性退化
- 72小时连续工作是一个基本要求
- 验证软件程序在不同厂家的硬件上、所支持的不同语言的新旧版本平台上和不同方式安装的软件上都能够如预期地正确运行。比如，把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上，再验证所有功能都正常运行。
- 检验软件和硬件的兼容性
- 使用测试矩阵管理大量的系统，设备和目标平台
- 找出主要的不兼容设备类型
- 根据修复好了的缺陷再重新进行的测试。目的在于验证以前出现过但已经修复好的缺陷是否不再出现。一般指对已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围是比较困难的，特别是当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化。
- 回归所有在严重的bug,需要将这个bug引起的block和fail的测试用例都重新测试。
- 检查结果是否正常。
- 观察新的变化产生的影响
上文我们在刚刚提到软件项目管理的时候提到过文档，在这里我们要对文档审查一遍：
- 主要测试开发过程中针对用户的文档，以及需求、用户手册、安装手册等为主，测验文档是否和实际应用存在差距。
- 测试用例需要测试人员仔细对比产品的外观、帮助文档等部分是否符合产品的开发文档或用户手册。
主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据的安全。测试人员可以学习一些黑客攻防技术，来对系统进行攻击。一般也得有网络安全维护人员进行参与。
- 安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装时逆过程，测试是否删除干净，是否影响原系统等。
- 在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与。
- 测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。
- 由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些。
- 错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。
- 有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。
- 对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。
- 有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。
- 测试人员容易犯2种错误：
（1）是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种“狼来了”的效果；
（2）是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。
以上两种错误应该尽量避免。
