质量保证体系

8.1 质量保证措施和方法
质 量 保 证 体 系
保证产品质量，是保障企业生存发展的必由途径。鹏博士软件事业部公司始终如一地重视产品质量，更注重实际运营质量，能够量体裁衣专程为客户服务，满足现代学校的管理需要。以切合实际和实现学校管理层先进的管理思想，在系统应用中的全面应用。

所谓质量保证就是把软件开发和工程实施的质量要求具体规定为每个开发或工程实施阶段，以此可以检查系统运营的全过程质量。鹏博士软件事业部公司为使提供给用户的服务质量得到保证，建立了一整套质量保证体系。通过建立管理制度化，实施科学的管理流程，使得管理工作有章可循；通过实施质量管理的标准化，使开发工作和工程实施能够较好地按质量标准实施；软件和工程的变更均依照变更流程进行，做到规范化管理。

质量保证计划分为两块：软件质量保证计划和工程质量保证计划。
☆ 软件质量：保证计划包括技术工作和管理工作实现标准化、文档化；建立完善的培训制度和技术评审制度；全部技术活动和管理活动稳定实施；软件的质量、进度和费用均可控制；对项目进行中的过程、岗位和职责均有共同的理解。

☆ 工程质量：保证计划是按工程实施周期，把全部项目实施工作划分为若干阶段，对每个阶段的工作做出计划。再把每个阶段的工作进一步分解为若干个任务，并形成任务计划。还要把任务细分为若干步骤，制定步骤计划。这样三层次的计划成为整个项目计划的依据。并且还包括工程实施过程中已建立定量的质量目标；已建立的过程数据库；已实现项目产品和过程的控制；可预测过程和产品质量趋势，如遇预测偏差，实行及时纠正。

项目质量保证
总结和分析实施工程项目失误的软件开发原因，我们不难看出其失败的原因大多与管理工作有关。

在项目开始执行时遇到的问题往往是：可供开发利用的资源太少；项目组成员的责任不明确；项目的定义模糊；没有计划或计划过分粗糙；资源要求未按时做出安排而落空；没有明确规定子项目完成的标准；

在项目执行的过程中可能会发生：项目审查只注意琐事而走过场；人员变动造成对工作的干扰；项目进行情况未能定期汇报；对阶段评审和评审中发现的问题如何处置未做出明确规定；资源要求并不像原来预计的那样大；未能作到严格遵循需求说明书；项目管理人员不足。

项目进行到最后阶段可能会发生：未作质量评价；获得的知识和经验很少交流；未对人员工作情况给予评定；未作严格的移交；扩充性建议未写入文档资料。

考虑到上述问题，鹏博士软件事业部公司股份有限公司积极与用户协同配合，按照制定的质量体系的标准对项目的质量进行追踪和控制。

在系统的设计或开发过程中遇到难题之后，双方应保持及时协商和协调。在问题领域可能需要一些追加资源；业务流程需要变更；必要时人员进行适当调整，或者项目进度要重新确定。这些需与学校共同在实施过程中确定。

以上过程须在学校数字化系统项目参与的全过程中，共同商讨，根据已经确定的原则、意见双方形成书面备忘录，保留存档，便于检查。

8.2 系统测试规范
软件测试是软件质量保证的主要活动之一。软件测试是软件质量保证的决定成分，它提供对软件规格说明、设计和编码的最终评审。

软件工程范围内的测试，实际上分为四步：单元测试，组装测试，确认（功能）测试，系统（实例）测试。它们顺序地被实现。

8.2.1 单元测试
单元测试集中检查软件设计的最小单元--- 模块，是以详细设计描述为指南，对重要的控制路径进行测试，用以发现错误。单元测试总是使用白盒子测试法，多个模块可以同时平行测试。主要对模块的五个基本特性进行评价。
模块接口
局部数据结构
重要的执行路径
错误处理
边界测试

8.2.2 组装测试
组装测试是用于装配软件的一种系统化的技术，要在软件装配的同时进行测试，用以发现与接口相联系的问题，目的是将经过单元测试的模块构成一个符合设计要求的软件结构。组装测试技术有自顶向下结合和自底向上结合两种测试方法。

（一）自顶向下结合
自顶向下（top-down）结合是一种递增的装配软件结构的办法。这种方法被日益广泛地采于需要连接程序，但不需要驱动程序的测试模式。

（二）自底向上结合
从软件结构的最低一层模块开始，进行装配和测试，这种方法常用在软件开发阶段的早期。与自顶向下的结合相反，它需要驱动软件，而不需要连接软件。
8.2.3 确认测试
确认测试主要检查软件功能与用户的需求是否一致。在软件需求规格说明的确认标准这一节中定义了用户对软件的合理要求，其中包含的信息是确认测试的基础和根据。

软件确认测试是通过黑盒子测试，来证实软件功能与用户需求是否一致。在测试计划中概述了要进行的测试类型，测试过程定义了用于证实软件与需求一致的具体测试用例。测试计划和测试过程的设计都是为了使软件符合所有功能和性能的要求，文档的正确和完整，以及其他要求（如可移植性、兼容性、容错性和可维护性）。

当开发者为用户建立起软件以后，还要进行一系列的验收测试（acceptance tests），以保证用户的所有需求有效。验收测试不是由系统开发者而是由最终用户实施。一个验收测试可以从非正式的一直延伸到有计划地系统地进行各种测试。事实上，验收测试要进行数周，甚至数月，因为发现长时间地运行会降低系统的积累性错误。

8.3 系统验收标准
软件最终要与其他系统元素（如新的硬件、信息等）相结合，进行各种集成测试（integration tests）和确认测试。这些软件工程过程工作范例以外的测试不是由软件开发者实施的。但是，软件开发者在软件设计和测试过程中历采取的步骤会极大地改善软件在系统（特别是大型系统）中集成功能的可能性。

系统验收实际上是一系列不同的测试，其主要目的是充分的运行基于计算机的系统。虽然，每种测试都有自己的目的。但是，所有工作都应该用来验证所有系统元素已经恰当地被集成，而且完成了所分配的功能。这里，我们将讨论学校校园数字化管理系统项目用于系统验收的几种软件系统测试类型。

（一）恢复测试
许多基于计算机的系统，如果发生故障，系统必须能从故障（faults）中恢复过来，并在预定的时间间隔内重新开始处理。在某些情况下，一个系统必须能容忍故障，即处理故障必须不会导致整个系统功能的中止。在另外一些情况下，一个系统的故障必须能在已确定的时间间隔内或在严重的经济损失发生前被改正。

恢复测试（recovery testing）是一种系统测试，它以不同的方式强使软件出现故障，用来验证软件能否恰当地完成恢复。如果恢复是自动的（由系统自身完成），则重新初始化、检测点设置、系统恢复，以及重新启动等都是对其正确性的评价。如果，恢复需要人员的干预，则要估算出修复的平均时间，以便确定它是否能在可接受的限制范围以内。

例如：要模拟非正常关机操作，服务器收到黑客攻击、网络线松动，管理人员误操作、病毒入侵等异常状况，查看对正常使用系统造成的影响是否是可以恢复的。测试后台数据录入操作时，要模拟非正常关机等故障，查看是否对数据准确性造成影响。

（二）安全性测试
安全性测试（security testing）就试图去建立系统内的预防机制，以防止来自非正常的侵入。也就是说，测试系统的安全性，不仅必须保证对来自正面的袭击不受伤害，而且必须保证对来自侧面或背面的袭击也不受伤害。

（三）强度测试
强度测试是在要求一个非正常数量、频率或容量资源方式下运行一个系统。例如：
（1）当平均速率有一种或两种时，可以设计每秒产生十个中断的特殊测试。
（2）输入数据的速率，可以按大小递增的顺序来决定输入功能怎样响应。
（3）可以运行要求最大内存或其他资源的测试用例。
（4）在虚拟操作系统中，可以设计产生多次反复的测试用例。
（5）对磁盘驻留数据，可以设计产生过度搜索的测试用例。

（四）性能测试
性能测试有时是与强度测试联系在一起的，常常需要硬件和软件的测试设备。也就是说，通常需要在严格的方式不变量资源的利用率（如处理器的周期）。外部测试设备可以监控运行时间间隔，记录它们发生的事件（如中断），以及在有规律的基础上样机的状态。通过测试设备系统，测试者可以发现导致降级和系统可能故障的情况。