软件测试

软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试方法的分类有很多种，以测试过程中程序执行状态为依据可分为静态测试 (Static Testing, ST) 和动态测试 (Dynamic Testing, DT)；以具体实现算法细节和系统内部结构的相关情况为根据可分黑盒测试、白盒测试和灰盒测试3类；从程序执行的方式来分类，可分为人工测试 (Manual Testing, MT) 和自动化测试 (Automatic Testing, AT)。

测试原则

• 应尽早并不断的进行测试，比如V模型，从设计的时候就开始测试测试；
• 工作应该避免由原开发软件的人或小组承担；
• 在设计测试方案时，不仅要确定输人数据，而且要根据系统功能确定预期的输出结果；
• 既包含有效、合理的测试用例，也包含不合理、失效的用例；
• 检验程序是否做了该做的事，且是否做了不该做的事；
• 严格按照测试计划进行；
• 妥善保存测试计划和测试用例；
• 测试用例可以重复使用或追加测试。

测试方法

静态测试

静态测试是被测程序不运行，只依靠分析或检查源程序的语句、结构、过程等来检查程序是否有错误。即通过对软件的需求规格说明书、设计说明书以及源程序做结构分析和流程图分析，从而来找出错误。例如不匹配的参数，未定义的变量等。

动态测试

动态测试与静态测试相对应，是通过运行被测试程序，对得到的运行结果与预期的结果进行比较分析，同时分析运行效率和健壮性能等。这种方法可简单分为3个步骤：构造测试实例、执行程序以及分析结果。

黑盒测试

黑盒测试将被测程序看成是一个黑盒，工作人员在不考虑任何程序内部结构和特性的条件下，根据需求规格说明书设计测试实例，并检查程序的功能是否能够按照规范说明准确无误的运行。其主要是对软件界面和软件功能进行测试。对于黑盒测试行为必须加以量化才能够有效的保证软件的质量。

白盒测试

白盒测试主要是借助程序内部的逻辑和相关信息，通过检测内部动作是否按照设计规格说明书的设定进行，检查每一条通路能否正常工作。白盒测试是从程序结构方面出发对测试用例进行设计。主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正常以及内部结构是否有效。常用的白盒测试法有控制流分析、数据流分析、路径分析、程序变异等。根据测试用例的覆盖程度，分为语句覆盖、判定覆盖、分支覆盖和路径覆盖等。

灰盒测试

灰盒测试介于黑盒与白盒测试之间。灰盒测试除了重视输出相对于输入的正确性，也看重其内部的程序逻辑。但是，它不可能像白盒测试那样详细和完整。它只是简单地靠一些象征性的现象或标志来判断其内部的运行情况，因此在内部结果出现错误，但输出结果正确的情况下可以采取灰盒测试方法。因为在此情况下灰盒比白盒高效，比黑盒适用性广的优势就凸显出来了。

自动化测试

自动化测试就是软件测试的自动化，即在预先设定的条件下自动运行被测程序，并分析运行结果。总的来说，这种测试方法就是将以人驱动的测试行为转化为机器执行的一种过程。

测试阶段

从阶段上划分，软件测试可以分为单元测试、集成测试和系统测试，系统测试中又包含了多种不同的测试种类，例如功能测试、性能测试、验收测试、压力测试等。

单元测试

主要是对该软件的模块进行测试，通过测试以发现该模块的功能不符合或不满足期望的情况和编码错误。
首先应通过静态测试方法，比如静态分析、代码审查等，对该模块的源程序进行分析，按照模块的程序设计的控制流程图，以满足软件覆盖率要求的逻辑测试要求。另外，也可采用黑盒测试方法提出一组基本的测试用例，再用白盒测试方法进行验证。对一些质量要求和可靠性要求较高的模块，一般要满足所需条件的组合覆盖或者路径覆盖标准。

集成测试

集成测试通常要对已经严格按照程序设计要求和标准组装起来的模块同时进行测试，明确该程序结构组装的正确性，发现和接口有关的问题。在这一阶段，一般采用白盒测试和黑盒测试结合的方法进行测试，验证这一阶段设计的合理性以及需求功能的实现性。

系统测试

般情况下，系统测试采用黑盒测试，以此来检查该系统是否符合软件需求。
内容包括功能测试、性能测试、健壮性测试、安装或反安装测试、用户界面测试、压力测试、可靠性及安全性测试等。为了有效保证这一阶段测试的客观性，必须由独立的测试小组来进行相关的系统测试，测试人员必须进行多轮回归测试。结束标志是测试工作已满足测试目标所规定的需求覆盖率，并且测试所发现的缺陷都已全部归零。

性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。

验收测试

验收测试是最后一个阶段的测试，是软件产品投入正式交付前的测试工作。
验收测试是要满足用户需求或者与用户签订的合同(包括技术协议、技术协调单以及各个阶段用户参与的评审意见等)的各项要求。
系统测试是软件开发过程中一项工作，而验收测试是由用户对要交付软件开展的一种测试工作。
通过验收测试后，产品可进行发布。但由于无法预测用户如何使用产品，所以从用户的角度出发，测试人员还应进行Alpha测试或Beta测试。
Alpha 测试是在软件开发环境下由用户进行的测试，或者模拟实际操作环境进而进行的测试。
Beta 测试是在实际环境中由多个用户对其进行测试，并将在测试过程中发现的错误有效反馈给软件开发者。

其它测试

由于Web应用和 App 应用的大规模兴起，也出现了一些新型的测试种类，例如 AB 测试、 Web测试中的链接测试、表单测试等。

AB测试

AB测试是为Web或 App界面或流程制作两个 (A/B) 或多个 (A/B/n) 版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。

Web测试

Web测试是软件测试的一部分，是针对Web 应用的一类测试。
由于 Web应用与用户直接相关，又通常需要承受长时间的大量操作，因此Web 项目的功能和性能都必须经过可靠的验证。
通过测试可以尽可能地多发现浏览器端和服务器端程序中的错误并及时加以修正，以保证应用的质量。由于Web具有分布、异构、并发和平台无关的特性，因而它的测试要比普通程序复杂得多，包含的测试种类也非常多。

链接测试

链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址页面的主要手段。链接测试可分为3个方面。
首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；
其次，测试所链接的页面是否存在；
最后，保证 Web应用系统上没有孤立的页面。

表单测试

当用户通过表单提交信息的时候，测试表单能否正常工作。如：提交按钮正常工作、确保程序能够正确处理数据、验证服务器保存信息、测试提交完整性、检验默认值、输入内容校验等。

测试用例设计

黑盒测试用例

将程序看做一个黑盒子，只知道输人输出，不知道内部代码，由此设计出测试用例，分为下面几类
等价类划分：等价类划分是一种方法，通过将输入值分成不同的类别，从而减少测试用例的数量，同时确保测试覆盖各种可能的情况。这样可以更高效地测试软件，而不必为每个可能的输人值都编写一个测试用例。
边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值。
错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。
因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。

白盒测试用例

知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例。以下图为例，覆盖级别从低至高分为下面几种

语句覆盖SC：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。如图中，SACBED。
判定覆盖DC：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。如图中，SACBD、SABED。
条件覆盖CC：针对每一个判断条件内(比如一个if）的每一个独立条件（if中的每个判定条件）都要执行一遍真和假。如图中，SACBED、SABED
条件判定组合覆盖CDC：同时满足判定覆盖和条件覆盖。如图中，SACBED、SABD。
路径覆盖：逻辑代码中所有的可能性都覆盖了，覆盖层级最高。如图中，SABD、SACBED、SACBD、SABED。

调试

测试是发现错误，调试是找出错误发生的代码和原因。
调试需要确认错误的准确位置；确定错误的原因并改正；改正后要进行回归测试。
调试的方法有：（1）蛮力法；（2）回溯法；（3）原因排除法等。
软件的两种属性：外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标；内部属性指软件产品本身的的属性，如可靠性等，只能间接测量。
McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m,节点数为n,则此有向图的环路复杂度为m-n+2。
假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m-n+2。
注意：m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点。

系统维护

遗留系统

遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统，它通常具有以下特点

• 系统虽然完成企业中许多重要的业务管理工作，但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。
• 系统在性能上已经落后，采用的技术已经过时。例如，多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。
• 通常是大型的软件系统，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难。
• 没有使用现代信息系统建设方法进行管理和开发，现在基本上已经没有文档，很难理解。

遗留系统维护方式如下图

系统转换

系统转换是指新系统开发完毕，投入运行，取代现有系统的过程。

转换方式

需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换方式:

1. 直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本，只适合小系统。
2. 并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。
3. 分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题，

数据转换与迁移

将数据从旧数据库迁移到新数据库中。
有三种方法：系统切换前通过工具迁移、系统切换前采用手工录人、系统切换后通过新系统生成。

评价指标

系统维护是整个系统开发过程中耗时最长的，系统的可维护性可以定义为维护人员理解改正、改动和改进这个软件的难易程度，其评价指标如下:

• 易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
• 易改变性。软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改
• 稳定性。软件产品避免由于软件修改而造成意外结果的能力。
• 易测试性。软件产品使已修改软件能被确认的能力。

系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下

• 正确性维护：发现了bug而进行的修改。
• 适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级。
• 完善性维护:基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更高，更加完善。
• 预防性维护:对未来可能发生的问题进行预防性的修改。