技术篇

第10回 在软件开发各个阶段的测试任务

<script type="text/javascript"></script><script class="blogstory"></script>

软件测试是软件开发过程中重要内容之一，是软件质量保证的关键。软件测试贯穿软件产品开发的整个生命周期，如第二章V模型图2-1所示，软件测试和软件项目同时开始，从产品的需求分析审查到最后的验收测试，直至软件发布。

    从测试实际的前后过程来看，软件测试的过程是由一系列的不同测试阶段所组成，这些软件测试的步骤分为：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。详细内容见下表。

阶  段	输入和要求	输出
需求分析审查 Requirements Review	市场/产品需求定义、分析文档和相关技术文档 要求：需求定义要准确、完整和一致, 真正理解客户的需求	需求定义中问题列表,批准的需求分析文档 测试计划书的起草
设计审查 Design Review	产品规格设计说明、系统架构和技术设计文档、测试计划和测试用例 要求：系统结构的合理性、处理过程的正确性、数据库的规范化、模块的独立性等 清楚定义测试计划的策略、范围、资源和风险，测试用例的有效性和完备性	设计问题列表、批准的各类设计文档、系统和功能的测试计划和测试用例 测试环境的准备
单元测试 Unit Testing	源程序、编程规范、产品规格设计说明书和详细的程序设计文档 要求：遵守规范、模块的高内聚性、功能实现的一致性和正确性	缺陷报告、跟踪报告；完善的测试用例、测试计划 对系统功能及其实现等了解清楚
集成测试 Integration Testing	通过单元测试的模块或组件、编程规范、集成测试规格说明和程序设计文档、系统设计文档 要求：接口定义清楚且正确、模块或组件一起工作正常、能集成为完整的系统	缺陷报告、跟踪报告；完善的测试用例、测试计划；集成测试分析报告； 集成后的系统
功能验证 Functionality  Testing	代码软件包（含文档）,功能详细设计说明书; 测试计划和用例 要求：模块集成 功能的正确性、适用性	缺陷报告、代码完成状态报告、功能验证测试报告
系统测试 System  Testing	修改后的软件包、测试环境、系统测试用例和测试计划 要求：系统能正常地、有效的运行，包括性能、可靠性、安全性、兼容性等。	缺陷报告、系统性能分析报告、缺陷状态报告、阶段性测试报告
验收测试 Acceptance  Testing	产品规格设计说明、预发布的软件包、确认测试用例 要求：向用户表明系统能够按照预定要求那样工作，使系统最终可以正式发布或向用户提供服务。用户要参与验收测试，包括α测试(内部用户测试)、β测试(外部用户测试)	用户验收报告、缺陷报告审查、版本审查 最终测试报告
版本发布 Release	软件发布包、软件发布检查表（清单）	当前版本已知问题的清单、版本发布报告
维护 Maintance	变更的需求、修改的软件包、测试用例和计划 要求：新的或增强的功能正常、原有的功能正常，不能出现回归缺陷	缺陷报告、更改跟踪报告、测试报告

 

第11回 集成测试的模式和方法 

       单元测试主要由开发人员完成，所以从测试人员工作来看，集成测试可能是具体测试实施的第一个阶段，虽然开发人员也比较多地参与集成测试。集成测试相对来说是挺复杂的，而且对于不同的技术、平台和应用，差异也比较大。不过，我们还是不得不面对它，保证系统集成成功，为后来的系统测试打下基础。
      
       集成测试简单的表现形式就是每日构建（Daily Build）, 保证Build构建成功，也就是保证软件的组件或单元能组装成一个系统。每日构建是一个很好的实践，被许多软件公司采用。

      集成测试，更多是和开发环境融合在一起，在编程过程中去实现，如MS Visual Studio.NET ，Borland JBuilder IDE， Compuware OptimalJ的集成开发/测试环境。更正确的说法，集成测试发要追溯到设计阶段。当设计数据接口(DB，XML等）、组件接口、应用接口(API)之时，我们就要审查接口的规范性、一致性等，就已经开始了集成测试。

集成测试阶段，测试方法是动态变化的，从白盒测试方法向黑盒测试方法逐渐过渡。在自底向上集成的早期，白盒测试方法占较大的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒测试慢慢占据着主导地位。

集成模式是软件集成测试中的策略体现，其重要性是明显的，直接关系到测试的效率、结果等，一般要根据具体的系统来决定采用哪种模式。集成测试基本可以概括为以下两种：

• 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。
  
• 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进来测试。

     非渐增式测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是渐增式集成模式，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，接口的测试亦可做到完全彻底。两种模式中，渐增式测试模式虽然需要编写的Driver或Stub程序较多、发现模块间接口错误相对稍晚些，但渐增式测试模式还具有比较明显的优势。

在实际测试中，应该将两种模式有机结合起来，采用并行的自顶向下、自底向上集成方式，而形成改进的三明治方法。而更重要的是采取持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现缺陷，避免集成阶段大量缺陷涌现。同时自底向上集成时，先期完成的模块将是后期模块的桩程序，而自顶向下集成时，先期完成的模块将是后期模块的驱动程序，从而使后期模块的单元测试和集成测试出现了部分的交叉，不仅节省了测试代码的编写，也有力于提高工作效率。

如果不采用持续集成策略，开发人员经常需要集中开会来分析软件究竟在什么地方出了错。因为某个程序员在写自己这个模块代码时，可能会影响其它模块的代码，造成与已有程序的变量冲突、接口错误，结果导致被影响的人还不知道发生了什么，缺陷就出现了。随着时间的推移，问题会逐渐恶化。通常，在集成阶段出现的缺陷早在几周甚至几个月之前就已经存在了。结果，开发者需要在集成阶段耗费大量的时间和精力来寻找这些缺陷的根源。如果使用持续集成，这样的缺陷绝大多数都可以在引入的第一天就被发现。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。这也就是为什么进行每日构建软件包的原因所在。所以，持续集成可以提高软件开发的质量与效率。

在现实中，集成测试和单元测试所处的情形相似，测试不彻底、不充分，没有各种接口参数、各类接口数据进行充分测试。如果系统的架构的层次不清楚，这种问题会更严重。目强许多开放系统都支持API，其集成测试的内容就更多了，除了API手册的内容正确性验证之外，还要模拟用户调用API的各种Scenario，后者在编程技术、对产品的各类应用要很好掌握，才能做好测试。

 

第12回 功能测试和适用性测试的标准

<script type="text/javascript"></script><script class="blogstory"></script>

        软件的功能测试往往被认为是测试中的相对简单工作，缺乏技术，只是"Mouse-driven"。实际上，软件功能测试，一方面依赖于不断积累的的经验，另方面功能测试也是离不开技术，包括环境设置、功能实现的理解。如果结合测试自动化、白盒或灰盒测试方法等，测试的效率会更高。

         适用性测试，往往可以和 功能测试结合起来做。但适用性主要是用户体验的评估活动，需要外部不同的各类人员参加。用户体验，对软件的生命力、市场影响和客户满意度的影响是非常重要的，越来越受到企业的重视。在微软公司，就设立了12个专门用于适用性的测试。在国外，也有专业公司（如 UE Group - http://www.theuegroup.com/, Genesis - http://www.genesishci.com/）帮助软件企业运作适用性测试，组织大量的、不同的用户进行体验测试。

          功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用、是否实现了产品规格说明书的要求、是否能适当地接收输入数锯而产生正确的输出结果等。功能测试，包括用户界面测试、各种操作的测试、不同的数据输入、逻辑思路、数据输出和存储等的测试。对于功能测试，针对不同的应用系统，其测试内容的差异很大，但一般都可归为界面、数据、操作、逻辑、接口等几个方面，如：

•  程序安装、启动正常，有相应的提示框、适当的错误提示等；
•  每项功能符合实际要求；
•  系统的界面清晰、美观；菜单、按钮操作正常、灵活，能处理一些异常操作；
•  能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理等；
•  数据的输出结果准确，格式清晰，可以保存和读取；
•  功能逻辑清楚，符合使用者习惯；
•  系统的各种状态按照业务流程而变化，并保持稳定；
•  支持各种应用的环境，能配合多种硬件周边设备，与外部应用系统的接口有效；
•  软件升级后，能继续支持旧版本的数据

软件产品以软件的客户为出发点，好的用户界面，除了正确性和实用性之外，还包括另外5个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、。

1. 符合标准和规范：软件在现有的平台上运行，通常标准是已经确立的（如MAC或者WINDOWS），这些规则和约定也是功能测试的依据。这些标准和规范是在大量实践基础上、随着时间而沉淀下来的、方便用户的各种规则和约定，如软件菜单格式、快捷键、复选框和单选按钮的界面，使用提示信息、警告信息或者严重警告信息等特定场合。

2. 直观性：首先了解所需的功能或期待的响应明显，并在预期的地方出现。其次要考虑用户界面的组织和布局是否合理、界面是否洁净、不拥挤以及是否有多余的功能，是否太复杂难以掌握等因素。

3. 一致性：软件自身的一致性以及软件与其他软件的一致性。字体和界面的各元素风格是否一致是比较容易判定的，而较难的一致性判断体现在用户操作方式上。用户习惯于将某一程序的操作方式带到另一个程序中使用。例如在WINDOWS平台客户已经习惯用Ctrl+C表示复制操作的，而在软件中将复制操作的快捷键定义为其它键，必定会给用户造成挫败感，难以接受。

4. 灵活性：软件可以选择不同的状态和方式，完成相应的功能。但灵活性也可能发展为复杂性，太多的状态和方式的选择增加的不仅仅是用户理解和掌握的困难程度。多种状态之间的转换，增加了编程的难度，更增加了软件测试的工作量。

5. 舒适性：人们对舒适的理解各不相同，但总体上要求恰当的表现、合理的组织、色调和谐、必要的提示或等。