l系统的测试示例文档.docVIP

第7章 系统的测试 7.1系统的测试框架 在软件系统开发的各个环节都有可以产生问题，因此需要不断的进行测试。目前，一种主流的思想认为任何系统开发后都存在各种各样的缺陷，而这些缺陷的存在是不可避免的。测试的目的不是证明系统的准确性，而是为是尽可能的发现系统存在的问题，从而减少当系统交付客户后暴露出的问题，从而提升用户的体验、降低系统的开发、运行与维护成本。 软件测试[27-30]的方法很多。在本系统中测试策略主要以时间为序，按目的展开测试。具体测试框架如图7-1所示： 图7-1本系统测试的框架 软件测试贯穿软件工程的每个阶段，一般来讲单元测试对应系统开发中的模块、类、方法。由于每个单元较小，最适合由开发人员自行测试。由于不同的类、模块、包等由不同开发人员开发，在集成时需要进行集成测试，看在调用方面是否存在问题。由于这一部分不与具体功能关联，所以测试规模不大。 在开发的各个阶段有单元测试、集成测试、系统测试与验收测试等不同的测试。然而这四种测试的测试计划制定时间与其开展的时间正好相反。测试计划的制定与测试工作的开展在时间上有较强的应对关系，相关情况如图7-2所示： 图7-2程序开发对应测试类型 7.2单元测试 7.2.1单元测试作用 就范围而言单元测试是软件测试是最小规模的一种。单元测试只关注某个方法、类的内部处理细节，如顺序与路径等。单元测试需要注意以下几点内容： 1）测试目标单元的执行过程是否与预期一致。 2）单元测试需要关注测试目标内部的路径。在有较多路径的情况下需要采用路径覆盖，使得尽可能多的路径被测试到。如果忽略了一些非主要的分支路径，则这种隐患可能在系统运行时显露出来。 单元测试根据测试的目的，又有不同的分类等。例如功能单元测试用于测试单元是否实现了预期的目标，逻辑单元测试用于了解被测试单元的逻辑是否合乎要求，而集成单元测试则用于了解不同单元之间的相互调用情况。 7.2.2基于NUnit的单元测试 在微软的VS.NET集成开发环境中内容了NUnit单元测试工具，该工具能根据测试目标的名称、输入、输出等相关信息生成桩模块。相关模块结构如下： [TestMethod] public void TestMethod1(参数1，参数2，…..) { // 定义相关参数值 // 将期望值与运行结果进行比对 // 输出对比结果。 } 在提供了桩模块后系统还会生成驱动模块，只需要驱动模块中提供输入参数与期望值，系统会自动进行批量测试。 7.2.3单元测试的实现 在得知NUnit的工作原理后，只需要提供测试用例即可进行单元测试。此处测试用例的编写有一定的依据，在本系统中这些依所为为需求分析时的数据字典、数据流图等。以下列举出系统中常用的几个测试用例。 表7-1 用户入职时间合法性检查用例 测试用例 期望结果 实际结果 √ √ 32323232323232323 χ χ “ ”[输入空格] χ χ 321 321 321 321 321 χ χ DEF.COMASD χ √ %$%#$% χ χ 4432@126 χ √ DFEH ab χ √ （2）表7-2所示为用户邮箱测试用例。 表7-2用户邮箱测试用例 测试用例 期望结果 实际结果 abc@123.com √ √ DEF@ABC.COM √ χ “ ” χ χ *%^ χ χ 123456 χ χ 123@123.COM χ χ 123@123 χ χ 1286@123 123 χ χ （3）白盒测试反馈 此处的白盒测试主要用于测试小范围的代码段或简单的逻辑片段，如表5.3为白盒测试用例。 表7-3白盒测试用例 √/χ 测试 √ 代码已经遵守开发标准，未见错误 代码逻辑经验证无误 代码有良好的编码风格，注释简洁易懂 4、代码层次结构按规范编写 √ 使用NUnit对所有单元进行的测试 所有的代码逻辑均进行了测试 （4）其他功能模块测试 表6-4所示为用户ID的测试用例。 表7-4用户ID测试用例 测试用例 期望结果 实际结果 χ √ Dream √ √ Dream Dream χ χ 21_21 χ χ 2010-10-10 χ χ %%#$$() √ χ abcdefg χ χ ABCDEFGQWERRTYU χ χ 山山山山山 χ χ 姓名 √ √ while χ χ return χ χ 表7-5为用户职位测试用例，职位由不超过10位的英文、中文字符组成，不能与一些保留字相同。 表7-5 用户职位