系统测试
系统测试的定义
计算机软件在开发完毕投入运行前还应与系统中其他部分如硬件系统、数据信息等集成在一起，进行一系列系统集成再进行系统测试（System Testing），以保证各组成部分在真实的运行环境下能够正常地协调工作。
系统测试的目的在于通过与系统的需求定义进行比较，检测软件是否存在与系统需求定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等是否满足其规约所指定的要求。
系统测试的流程
在系统测试之前，软件测试工程师应完成下列工作：
1.为测试软件系统的输入信息设计出错处理通路。
2.设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助。
3.参与系统测试的规划和设计，保证软件测试的合理性。
系统测试的目标
确保系统测试的活动是按计划进行的。
验证软件产品是否与系统需求用例不相符合或与之矛盾。
建立完善的系统测试缺陷记录跟踪库。
确保软件系统测试活动及其结果及时通知相关小组和个人
系统测试的方针
1.为项目指定一个测试工程师负责贯彻和执行系统测试活动。
2.测试组向各事业部总经理／项目经理报告系统测试的执行状况。
3.系统测试活动遵循文档化的标准和过程。
4.向外部用户提供经系统测试验收通过的项目。
5.建立相应项目的缺陷库，用于系统测试阶段项目不同生命周期的缺陷记录和缺陷状态跟踪。
6.定期对系统测试活动及结果进行评估，向各事业部经理／项目办总监／项目经理汇报项目的产品质量信息及数据。
系统测试的过程
（1）软件项目立项，软件项目负责人将项目启动情况通报给测试组长，测试组长指定测试工程师对该项目进行系统测试跟进和执行。
（2）测试工程师首先参与前期的需求分析活动、前景评审、业务培训、需求规格说明书评审。目的是了解系统业务及范围、了解软件需求及范围，验证需求可测性。并将所有收集到的测试需求汇总并输出到《测试需求管理表》中。
（3）测试工程师根据测试需求定义测试策略，进行工作量估计。测试工程师根据测试需求制订测试策略和方法；系统测试工程师参与项目计划和测试计划评审，依据项目计划（或周计划），编制《系统测试计划》。
（4）测试组长周期性地根据事业部项目的测试情况，进行总体测试工作量估计并进行测试任务分派。
（5）测试工程师组织《系统测试计划》评审，测试组长根据评审意见审批《系统测试计划》。
（6）测试工程师根据《系统测试计划》中的测试环境要求搭建测试环境。特别技术要求的需要项目组及其他相关职能部门的配合。
（7）测试工程师检查测试设计入口条件；根据《用例规约》、《补充规约》、《界面原型》、《词汇表》进行测试用例设计。
（8）测试工程师组织《系统测试用例》评审，测试组长根据评审意见审批《系统测试用例》。
（9）测试工程师定义系统测试用例执行过程，并更新《系统测试用例》。
（10）测试工程师检查测试执行入口条件，从受控库获取测试版本，执行系统测试并记录测试结果。
系统测试的设计
为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。对需求规格进行充分的分析，分解出各种类型的需求（功能性需求、性能要求、其他需求等），在此基础之上进行测试设计工作。在测试设计中，从多方面考虑系统规格的实现情况，通常从以下几个层次来进行设计：用户层、应用层、功能层、子系统层、协议／指标层。
几种常见的系统测试方法
1）恢复测试
恢复测试也叫容错测试，用来检查系统的容错能力。通常若计算机系统出现错误，就必须在一定时间内从错误中恢复过来，修正错误并重新启动系统。
恢复测试是通过各种手段，让软件强制性地出错，使其不能正常工作，从而检验系统的恢复能力。对于自动恢复系统，即由系统自身完成恢复工作，则应该检验重新初始化、检查点、数据恢复和重新启动等机制的正确性。对于人工干预恢复系统，要评估平均修复时间是否在可接受的范围。
2）安全测试
安全测试的目的在于检测系统对外界非法入侵的防范能力。在安全测试过程中，测试者采用各种手段攻击系统，如尝试破译系统密码，或有目的地引发系统错误，或在系统恢复过程中侵入系统等来检测系统的防范能力。
系统的安全测试要设置一些测试用例试图突破系统的安全保密防线，用来查找系统的安全保密的漏洞。系统安全测试的准则是让非法侵入者攻击系统的代价大于保护系统安全的价值。
3）强度测试
强度测试也称压力测试、负载测试，是检测程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行，以检验系统能力的最高限度，从而了解系统的可靠性、稳定性等。在设计测试用例时应尽量加大系统的负载，如当中断的正常频率为每秒一至两个时，使用运行每秒产生10个中断的测试用例；定量地增长数据输入率，检查输入子功能的反映能力；运行需要最大存储空间（或其他资源）的测试用例；运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
4）性能测试
性能测试用来测试软件在系统运行时的性能表现，比如，运行速度、系统资源占有或响应时间等情况。对于实时系统或嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能。系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。若只能满足功能需求而不能满足性能需求，是不能被接受的。
5）容量测试
容量测试是指在系统正常运行的范围内测定系统能够处理的数据容量，测试系统承受超额数据容量的能力。系统容量必须满足用户需求，如果不能满足实际要求，必须努力改进，寻求解决办法。暂时无法解决的需要在产品说明书中给予说明。
6）正确性测试
正确性测试又称功能测试，它检测软件的各项功能是否符合产品规格说明的要求。由于正确性是软件最重要的质量因素，所以其测试也最重要。正确性测试的总体思路是设计一些逻辑正确的输入值，检查运行结果是不是期望值。
正确性测试主要有两种方法，一种是枚举法，另一种是边界值法。
7）可靠性测试
可靠性测试是检测系统的可靠性是否达到预期目标的测试方法。可靠性测试需要从用户角度出发，模拟用户实际使用系统的情况，设计出系统的可操作视图。在这个基础上，根据输入空间的属性及依赖关系导出测试用例，然后在仿真的环境或真实的环境下执行测试用例并记录测试的数据。
对可靠性测试来说，最关键的是测试软件系统的失效间隔时间、失效修复时间、失效数量、失效级别数据等。根据获得的测试数据，应用可靠性模型可以得到系统的失效率及可靠性增长趋势。
8）兼容性测试
兼容性测试是指测试某新开发的软件在某一特定环境下与各种软件的协调性，软件之间能否很好地运作。例如，会不会有相互不良的影响，软件和硬件之间能否发挥很好的效率工作，会不会影响或导致系统的崩溃等。
兼容性测试通常需要解决以下问题：
1）新开发的软件需要与哪种操作系统、Web浏览器和应用软件保持兼容；
2）如果要测试的软件是一个平台，应用程序能否在其上运行；
3）应该遵守哪种定义软件之间交互的标准或者规范；
4）软件使用何种数据与其他平台、与新的软件进行交互和共享信息
兼容性通常有向前兼容与向后兼容、不同版本间的兼容、标准和规范的兼容及数据共享兼容。
软件兼容性测试的主要内容：
操作系统/平台兼容性测试
应用软件之间兼容性测试
不同类型的数据库兼容性测试
9）Web测试
现在好多应用软件都应用B/S结构，它们的客户端都使用浏览器。因此，浏览器是Web客户端最核心的构件，但来自不同厂商的浏览器对Java、 JavaScript、 ActiveX、 plug-ins或HTML规格都有不同的支持。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。所以，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性，也是软件兼容性测试的重点之一。
针对Web网站这一特定类型软件的测试，包含许多测试技术，如功能测试、压力／负载测试、配置测试、兼容性测试、安全性测试等。黑盒测试、白盒测试、动态测试和静态测试都有可能被采用。
验收测试
验收测试的定义
验收测试是软件开发结束后，用户对软件产品投入实际应用前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。在真正进行用户验收测试之前一般应该已完成了以下工作：
软件研发已完成，并全部解决了已知的软件缺陷；
验收测试计划已过评审并批准，并且置于文件控制之下；
对软件需求说明书的审查已完成；
对概要设计、详设计的审查已完成；
对所有关键模块的代码审查已完成；
对单元、集成、系统测试计划和报告的审查已完成；
所有的测试脚本已完成，并至少执行过一次，且通过评审；
使用设置管理工具且代码置于设置控制之下；
软件问题处理流程已就绪；
已制订、评审并批准验收测试完成标准。
验收测试的内容
软件验收测试应完成的工作内容如下：
明确验收项目，规定验收测试通过的标准；
确定测试方法；
决定验收测试的组织机构和可利用的资源；
选定测试结果分析方法；
指定验收测试计划并进行评审；
设计验收测试所用的测试用例；
审查验收测试的准备工作；
执行验收测试；
分析测试结果；
做出验收结论，明确通过验收或不通过验收，给出测试结果。
验收测试的标准
验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。在这个阶段发现问题往往与“需求分析”阶段的差错有关，涉及的面比较广，难以解决。此时必须与用户协商，寻求一个妥善解决问题的方法。
验收测试的常用策略
验收测试的常用策略有3种，选择的验收测试的策略通常是建立在合同需求、组织和公司标准及应用领域的基础上的。
1）正式验收测试
正式验收测试是系统测试的延续，是一项严格管理的过程，测试前要制订周密详细的计划和设计。在选择测试用例时应延续系统测试中所执行测试用例的方向。测试小组由开发组织与最终用户组织的代表组成并共同执行验收测试，或完全由最终用户组织人员组成并执行，或者由双方认可的客观公正的第三方组织来执行。
正式验收测试的优点是要测试的功能和特性都是明确的；测试的细节是已知的并且可以对其进行评测；测试可以自动执行并支持回归测试；可以对测试过程进行评测和监测；可接受性标准是已知的。
当然，正式验收测试也有缺点，主要包括：测试要求大量的资源和计划，而且这些测试可能是系统测试的再次实施，也可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。
2）非正式验收或Alpha测试
在非正式验收测试中，执行测试过程的限定不是很严格，也没有可以遵循的特定测试用例，测试步骤和内容完全由各测试人员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。大多数情况下，非正式验收测试由最终用户组织执行。
非正式验收测试的优点是：要测试的功能和特性都是已知的；可以对测试过程进行评审和监测；可接受性标准是已知的；非正式验收测试和正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
非正式验收测试的缺点包括：要求资源、计划和管理资源；无法控制所使用的测试用例；最终用户可能沿用系统工作的方式，并可能无法发现缺陷；最终用户可能更专注于比较新系统与遗留系统，而不是专注于查找缺陷；用于验收测试的资源不受项目的控制，并且可能受到压缩。
3）Beta测试
与以上两种验收测试策略相比，Beta测试需要的控制是最少的。在Beta测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据，并决定要测试的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。Beta测试由最终用户实施，通常开发组织对其管理很少或不进行管理。Beta测试是所有验收测试策略中最主观的。
Beta测试形式的优点是：测试由最终用户实施；大量的潜在测试资源；提高客户对参与人员的满意程度；与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
Beta测试的缺点包括：未对所有功能／特性测试；测试流程难以评测；最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷；最终用户可能更专注于比较新的系统与遗留系统，而不是专注于查找缺陷；用于验收测试的资源不受项目的控制，并且可能受到压缩；可接受性标准是未知的。
验收测试的过程
① 软件需求分析要分析测试样品及其相关资料，要了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。综合分析产品是否达到验收测试状态，未达到验收测试状态，要返回提交测试样品及相关资料；达到测试状态，则可向下执行。
② 编制《验收测试计划》和《项目验收准则》：测试计划在需求分析阶段建立，根据软件需求和验收要求编制测试计划，制订需测试的测试项，制订测试策略及验收通过准则，并经过客户参与相关计划的评审。
③ 进行项目相关知识培训。
④ 测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例和相关方案。
⑤ 测试方案评审：评审测试实施方案和相关测试用例。
⑥ 测试环境搭建：建立测试的硬件环境、软件环境等（可在委托客户提供的环境中进行测试）。
⑦ 实施测试：进行验收测试并记录测试结果。
⑧ 编制验收测试报告并组织评审：根据验收通过准则分析测试结果，做出验收是否通过及测试评价。
⑨提交验收测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
验收测试的总体思路
在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了正式测试。用户在按照合同接收并清点开发方的提交物时（包括以前已经提交的），要查看开发方提供的各种审核报告和测试报告内容是否齐全。
用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启动标准（着手本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。
验收测试可以分为两大部分：软件配置审核和可执行程序测试。
1）软件配置审核
可执行程序、源程序、配置脚本、测试程序或脚本。
主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。
主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。
不论项目大小，都必须具备上述的文档内容。在验收测试执行过程中，文档审核是最难但也是最重要的工作。审核要达到的基本目标是：根据共同制订的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
2）可执行程序的测试
在软件配置审核后，就可以进行验收测试的最后一个步骤——可执行程序的测试，它包括功能、性能等方面的测试，每种测试都包括目标、启动标准、活动、完成标准和度量5部分。
如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题都已解决，而且所有的软件配置均已更新和审核并可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。