遵循CMMI3的测试计划

1、1.1. 遵循CMMI3的测试计划测试计划也应遵循CMMI3级体系的要求制定。测试是与开发紧密结合在一起的，不能抛开开发单独谈论测试，因此根据本项目开发的迭代型生命周期模型，本项目的测试过程也同样采用迭代模型，另外根据本项目的特点，系统测试是本项目的测试重点。1.1.1. 测试分类在整个项目实施过程中，软件测试从流程上可分为四个阶段：单元测试、集成测试、系统测试、验收测试；单元测试和集成测试相对于开发介入的比例比较大，相对独立的测试是系统测试（验收测试是用户对系统进行验收的一种测试，其方法基本同系统测试，只是测试的参与者不同），而且系统测试更是能直接反映出项目成功与否，因此在系统测试方面，我们

2、又从测试内容上进行了详细的分解，在本项目中，我们拟采用的测试内容包括以下方面：功能测试、性能测试、压力测试、强壮性测试、安全性测试、兼容性测试、安装/反安装测试、可使用性测试、文档测试。1.1.2. 测试的四个阶段1.1.2.1. 单元测试单元测试是对最小的可测试软件元素（单元）实施的测试，它所测试的内容包括单元的内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。使用白盒测试方法测试单元的内部结构，使用黑盒测试方法测试单元的功能和可观测的行为。单元测试采用以下二种方式：静态分析和动态执行。静态分析：不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术，包括代码走

3、查、审查、评审；走查：开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。检查要点（逻辑错误，代码标准/规范/风格）；审查：开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。检查要点（设计需求，代码标准/规范/风格）；评审：开发组、测试组和相关人员联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。检查要点（设计需求，代码标准/规范/风格，文档的完整性和一致性）动态执行：确定测试用例和开发测试驱动程序和桩模块，需要很大的工作量;对于一些底层模块的单元测试

4、，可以借助公司内的单元测试工具，目前公司的单元测试工具有Jtest 和C+test。分别可以对Java和C/C+代码进行单元测试。单元测试需要投入大量的人力和时间，在本项目中最终可以根据项目周期的安排进行取舍。1.1.2.2. 集成测试集成测试的目的是确保经过单元测试的各模块组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口的完整性、功能的有效性、信息内容、以及性能。接口的完整性：在每一个模块集成到整个结构中去的时候，要对其内部和外部接口进行测试；功能的有效性：进行以发现功能性错误为目的的测试；信息内容：进行以发现和局部或全部数据结构有关的错误为目的的测试

5、；性能：设计用来验证在进行软件设计的过程中建立的性能边界的测试； 集成测试的基本策略包括自底向上和自顶向下二种，根据实际情况，也可以采用三明治式的策略。总的来说，一种组合策略可能是最好的折中：在程序结构的高层使用自顶向下策略，而在下面的较低层中使用自底向上策略； 集成测试由开发组完成，测试组使用黑盒测试方法重新测试集成的功能，并且对以前的集成进行回归测试。1.1.2.3. 综合测试在开发或运行环境下，针对系统需求规格说明规定的所有功能和非功能需求的全面验证工作，测试整个系统，以证实它满足要求所规定的功能、质量和性能等方面的特性，对于非功能需求的测试，我们拟提供以下八方面的测试内容，分别是性能测

6、试、压力测试、强壮性测试、安全性测试、兼容性测试、安装/反安装测试、可使用性测试、文档测试，将在以下详细说明。1.1.2.4. 验收测试在浙江省监测总站的实际环境中，以系统需求规格说明为依据，测试整个系统，以保证其达到可以交付使用的状态，测试方法参照系统测试，测试主体为浙江省监测总站相关人员，根据浙江省监测总站的需要，也可加入聚光科技的相关测试人员。测试的内容测试内容应该根据项目的本身特点进行取舍，因为要考虑项目周期及成本。以下列举一些常用1.1.2.5. 功能测试功能测试要求100%覆盖功能需求，但可根据需求的重要程度和使用频度设置测试的优先级别，对于高优先级别的测试需求，相对投入较多的测试

7、资源。1.1.2.6. 性能测试性能测试是测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。 有时人们关心测试的“绝对值”，如每秒能处理几笔交易。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍，在本项目中，我们主要是以绝对值方式体现本系统的性能。在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。 性能测试的一些注意事项：Ø 不要试图拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。 Ø 测试软件在标准配置和最

8、低配置下的性能。 Ø 为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。 Ø 不同的输入情况不同的环境会得到不同的性能数据，应当分别记录。由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。 在本项目中一些底层的性能测试，如工作流的性能指标可以借助于公司内的测试工具进行来完成。1.1.2.7. 压力测试压力测试是指系统承受压力的极限能力，如果再超过一点，就会造成系统瘫痪。压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。常用的方法有：Ø 加大并发用户数，观察达到多少并发用户时系统不能正常运行

9、。Ø 加大数据库容量，构造几百万，甚至上千万条记录。Ø 加大处理文件容量，处理几百G以上的文件。 压力测试基本方法类似于性能测试，但在实现上却难于性能测试，因为压力测试需要更多的依赖于测试工具进行，比如最大支持并发用户数，一般难以用人工来测试，因此一些底层模块的测试，我们也可以在公司内借助测试工具来测试。1.1.2.8. 强壮性测试强壮性是指系统在异常情况下，软件还能正常运行的能力。强壮性有两层含义：一是容错能力，二是恢复能力，所以有时也把强壮性测试分做容错测试和恢复测试，也有把强壮性测试认为是破坏性测试的。 容错性测试通常构造一些不合理的输入来引诱软件出错，例如：

10、6; 输入错误的数据类型。如“猴”年“马”月。Ø 输入定义域之外的数值。如上海人常说的“十三点”Ø 采用一些粗暴方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试数据通讯时，把网络线拔掉，造成通信异常中断；在系统运行过程中，拔掉机器电源，造成突发停电或人为踢掉电源的现象。恢复测试重点考察以下几项内容：Ø 系统能否自动重新运行或者在人为的干预下能否重新运行；Ø 有无重要的数据丢失；Ø 是否毁坏了其它相关的软硬件。 1.1.2.9. 安全性测试信息安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。安全

11、性测试注意以下方面：Ø 用户界面上敏感数据是否加密，密码不能明文显示。Ø 用户访问权限控制机制是否合理，是否有比较全面的安全审计。Ø 数据库中敏感数据是否加密，主要如用户表信息表中的密码是否进行了加密，如果加密了能否简单的被解密。Ø 网络通讯中数据包是否加密，能否通过一些简单的网络工具就能获取通讯数据，如果是明文传输，而且在不安全的网络上传输就可能存在安全隐患。Ø 整个系统架构是否安全，如果一个系统架构在一个不安全的平台上，就谈不上自身的安全。Ø 在管理上，客户资料是否会被泄漏出去。信息安全性测试除了以上的一些常用检查项，对于一些In

12、ternet上的应用还可以邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”， 如果有人成功了，请他详述入侵的过程。1.1.2.10. 兼容性测试兼容性是指系统在需求规格说明书要求的范围内，在不同的支持系统和环境下是否都能兼容（正常）的一种测试，做好兼容性测试是系统下一步进行移植的必要准备和前提。兼容性测试一般考虑的方面有：Ø 在不同的操作系统下，系统的兼容程度，比如一个WEB系统，是否如需求规格说明书要求的那样，支持unix，或Linux系统呢。Ø web系统的客户端，除了支持IE，是否也支持Netscape。Ø 系统是否支持不同的数据库，主要采

13、用的一些通用的数据库技术还是比较多的采用某数据库的专有功能。Ø 支持IE，是否支持IE的所有版本，会不会IE7.0下正常支持，在IE6.0下就不正常了呢。Ø 同样IE下，显示分辨率在1280×1050下正常，会不会在1024×768下就会显示乱套了呢。1.1.2.11. 安装/反安装测试安装/反安装测试主要用于在系统的推广过程中。一个商业软件产品，安装程序是个门面，虽然简单，但也不要在阴沟里翻了船安装测试一般考虑的方面有：Ø 在标准配置和最低配置两种环境下测试Ø 在安装界面中，应当尝试各种选项，如选择“全部”、“部分”、“升级”等以及

14、其它可以选择的参数。反安装测试一般考虑的方面有：Ø 系统卸载后文件是否删除干净。Ø 注册表里是否还有相关垃圾信息。安装/反安装测试相对优先级别较低，可在后期进行。1.1.2.12. 使用性测试可使用性测试也有叫做界面测试的，因为绝大多数软件拥有图形用户界面。图形用户界面的测试重点是正确性、易用性和视觉效果。在评价易用性和视觉效果时，主观性非常强，应当在综合考虑多个人的观点。但在界面/可使用性测试中，也可以把一些公认的标准列出来，如果不符合也要当作BUG处理，比如： 输入域中，TAB键的顺序一定是从左到右，从上到下，不可能是乱跳的。系统中的某一特定功能，不能使用Windows

15、的保留热键，通用功能热键，要与windows保持一致。重要操作（如造成数据无法恢复的，常见为删除操作）一定要有确认提示，以允许用户放弃操作。长时间的操作（18秒以上），要有操作提示，以免造成死机的假象。 可使用性测试相对其它测试内容优先级别较低，在本项目中，采用以正确性为主，易用性为辅的原则进行。1.1.2.13. 文档测试文档也是软件的一部分，所以也要测试通过文档测试最基本的内容如安装文档、使用文档、维护文档等。文档测试应该注意以下几方面内容：Ø 首先应确认文档内容正确，也是最新的。Ø 文档条理是否清楚，排版是否合理，是否采用能用模板格式进行排版。Ø 文档版本标

16、识是否正确文档的修改一般落后于项目开发进度，测试时可放在后期进行。1.1.3. 测试过程管理1.1.3.1. 角色及职责角色职责项目经理将项目计划需求规格说明书提交测试人员测试人员负责整个测试过程项目组成员负责修改测试人员提交的问题1.1.3.2. 过程管理软件测试开发、管理流程贯穿了项目的整个开发和测试生命周期，与整个软件开发过程基本上是并行进行并相互协调的。测试管理总流程图如下：需求规格说明书；概要设计说明书；详细设计说明书；开发计划书；集成计划书参与需求评审；参与设计评审；项目组完成编码，走查，单元、集成测试；逐步细化测试计划，测试用例；评审通过YN修改指派项目立项创建计划BUG分配修订

17、BUG记录BUG库基线/创建版本开发版本配置库YNN测试计划书；测试用例；创建计划书；NYYYNN产品库项目验收系统测试例外放行否？项目终止否？出口准则Y功能集成测试版本创建冒烟测试YN版本创建冒烟测试YN测试管理总流程图 1.1.3.3. 测试过程实施要点测试人员应该尽早介入项目，而非开发完成后才进入项目。测试人员应该参与早期的需求和设计的讨论与评审，在需求的讨论和评审中要重点关注需求的可测性。 每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据，同时，开发人员不能把调试来代替测试。80的缺陷聚集在20的模块中，经常出错的模块改错后还会经常出错测试只能证明缺陷存

18、在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试，所以在设置测试的出口条件。测试应当动态的过程，要循序渐进，不要企图一次性干完，注意“欲速则不达”，特别是在迭代的开发模型下。1.1.3.4. 测试计划根据确认的需求规格说明书和相关设计文档，确定项目测试阶段的目标和策略，确保测试工作有序、有效进行。测试计划包括以下工作内容：确定系统的测试需求，如功能需求、性能需求、安全性要求、可使用性需求等需求说明书中说明的和潜在的需求；测试负责人与项目经理协商，逐步确定测试项目的测试范围、测试粒度（覆盖标准）以及测试方案、测试阶段的出入口准则；根据项目的复杂度和以

19、往的测试数据初步估计测试项目工作量，制定测试计划的进度安排。逐步细化测试方案及测试规模估计；测试进度安排中要留有合理的测试BUG、用例管理时间；形成测试计划书（可包括单元、集成、系统阶段）并提交测试负责人、项目经理或测试部门经理审核。批准人为项目经理。同时测试负责人可发起测试计划的评审；审核批准通过则放入开发配置库；当项目开发计划或测试需求发生变更时，测试计划应考虑是否需要变更；1.1.3.5. 测试用例根据批准的需求规格说明书和相关设计文档，策划测试过程执行依据，确保测试范围有效并正确。测试用例管理包括以下工作内容：Ø 测试人员参与需求评审，正确理解系统需求并确认需求的可测性，获取

20、测试项目需求；Ø 根据批准的测试项目需求，测试目标的逻辑实现和约束，测试工具及其测试环境等限制条件，设计测试用例；测试用例的基本要素至少包括用例编号、用例名称、执行步骤、输入数据、期望输出等。Ø 测试负责人发起组织相关人员进行测试用例评审，从而提高测试用例的质量；系统测试用例审核人可以是测试负责人、项目经理、测试部门经理，批准人为项目经理；Ø 测试负责人负责基于系统的详细设计，确定单元测试范围和粒度，有效路径和值域等，组织开发人员进行单元测试中自动和手动测试用例的编写；并组织相关人员进行评审；Ø 测试负责人负责进行阶段测试用例的实施、跟踪及用例统计分析工

21、作、改进测试用例等管理活动；Ø 当软件需求或设计变更引起测试需求变更时，将变更测试用例文档；Ø 测试负责人实时或定期根据Bug数据、状态和测试用例执行情况进行分析，以确定是否需要对目前测试的模块设计新的测试用例，对不稳定的模块，测试负责人负责与项目经理讨论确定测试范围、粒度和执行方案等，并指定相关人员完成新增测试用例的编写；1.1.3.6. 测试的开发设计、编写和管理测试程序、测试脚本和其它辅助测试程序，以提高测试效率和测试质量。测试开发的工作内容：Ø 根据测试需求，设计测试程序和脚本；Ø 选择相应的开发语言编写测试程序和脚本；除了完成测试所需的功能外，

22、还应考虑模块的重用和代码的简洁；Ø 对于一些底层模块，在测试没有界面的接口时可以考虑用编写测试程序或脚本实现；Ø 没有现成工具可使用的性能测试也可以通过编写测试程序或脚本模拟实际环境进行测试；Ø 开发单元测试和集成测试所需的桩模块和驱动模块；Ø 脚本必须在动态维护过程中，对于可重复利用的模块必须建立公共库，以实现资源共享；1.1.3.7. 测试的执行测试执行是根据测试用例实施测试的过程。测试执行的工作内容包括：Ø 充分理解测试用例，按用例要求准备测试前置条件，并按用例要求的步骤执行测试过程，把测试结果与预期结果进行比较，得出测试通过与否的结论；

23、Ø 详细记录测试结果，对于产生的BUG，还要认真记录BUG发生的具体情况。Ø BUG提交给开发人员修改后，需要验证BUG是否真正解决，对解决的BUG，作关闭操作，没解决或全部解决的BUG，返回开发人员继续解决。Ø 不定期与开发人员讨论BUG的情况。Ø 测试结束时，提交测试分析报告，评价系统的质量状况。1.1.4. BUG管理包括对所发现的BUG的记录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除等一系列活动状态的管理；6.15.4.1 BUG管理流程以上的状态迁移图遵循如下原则：矩形表示的为状态名称，蓝色字体表示的为操作名称。一个状态可以

24、通过一个操作迁移到另外一个状态。Ø 提交：提交新的BUG，没有起始状态，结束状态为“已提交”；组织内任何人均可执行该操作；Ø 无效：审核BUG为无效，起始状态为“已提交”，结束状态为“无效的”；组织内测试负责人可执行该操作；Ø 有效：验证BUG为有效，起始状态为“已提交”，结束状态为“有效的”；组织内测试负责人可执行该操作；Ø 延迟：将BUG进行延迟处理，起始状态为“有效的”，结束状态为“已延迟”；组织内项目经理可执行该操作；Ø 分配：将有效的或延迟的BUG分配给相应的开发员进行修改，起始状态为“有效的”或“已延迟”，结束状态为“已分配”；组织

25、内项目经理可执行改操作；Ø 解决：将分配好的BUG进行修改处理，起始状态为“已分配”，结束状态为“已解决”；组织内开发人员可执行该操作；Ø 重新分配：把分配错误的BUG或需要延迟的BUG退回分配状态，起始状态为“已分配”，结束状态为“有效的”；组织内开发人员可执行该操作；Ø 拒绝：将已解决的BUG进行测试验证，测试不通过的进行拒绝操作，由开发员重新进行修改，起始状态为“已解决”，结束状态为“已分配”；组织内测试人员可执行该操作；Ø 关闭：将已解决的BUG进行测试验证，测试通过的进行关闭操作，起始状态为“已解决”，结束状态为“已关闭”；组织内测试人员可执行

26、该操作；Ø 修改：修改操作可在任何状态进行，且只能修改BUG记录的内容，不进行状态迁移；组织内测试负责人可进行该操作。6.15.4.2 BUG分类BUG级别说明1类BUG：致命错误致命错误通常有如下情况：1、 需求书中的重要功能未实现；2、 造成系统崩溃、死机,并且不能通过其它方法实现功能；3、 常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。2类BUG：严重错误严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，如：1、 重要功能基本能实现，但系统不稳定、一

27、些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；2、 重要功能不能按正常操作实现，但可通过其它方法可实现；3、 错误的波及面广，影响到其它重要功能正常实现；4、 密码明文显示；5、 C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。3类BUG：一般错误程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，如：1、 次要功能不能正常实现；2、 操作界面错误（包括数据窗口内列名定义、含义不一致）；3、 打印内容、格式错误；4、 查询错误，数据错误显示；5、 简单的输入限制未放在前台进行控制；6、 删除操作未给出提示；7、 数据库表中有过多的空字段；8、 因错误操作迫使程序中断；9、 找不到规律的时好时坏；10、 数据库的表、业务规则、缺省值未加完整性等约束条件；11、 经过一段时间运行后，系统性能或响应时