软件测试的流程建议.docVIP

软件测试的流程建议以及现阶段问题的分析 *********************************************************** 简介： 以下内容包括测试流程的设计，测试各个要素的说明，现象的 比较和问题的分析，质量管理软件的说明，责任的承担问题，测试 周期的估计，软件测试工程师的素质要求，文档的重要性以及相应 参考文档。 ************************************************************ 回归测试流程 测试各个要素的说明 测试所涉及到的文档，工具，环境，程序都很多，其中的要素也很多，但是整个测试过程中的元素应该是一个有机的整体，而不是分散的个体。 测试计划要素： 测试各个阶段的安排； 可以利用到的资源，如测试程序，测试时间，测试工具，开发文档 涉及到的所有文档，以及各个文档程序直接的关系 规定了各个文档中描述的规则，要求，目的以及增加和修改案例等流程的标准步骤。 对应测试对象，BUG等级的制订。 它是整个测试过程必须依据和遵守的文档。 测试执行阶段： 单元测试：测试接口所有API，分正面测试和反面测试，正面测试主要验证函数是否能正常运行，反面测试测试函数的冗错性和健壮性。 集成测试：测试各个函数接口直接的输入输出关系，以及各个模块是否可以正常运行，是终端各个外设的功能性测试，同样分为正面和反面的测试。 系统测试：终端整体运行的测试，类似于应用程序的测试，可利用脚本做流程控制。同样需要简单的正反测试。 压力测试：即负载测试，比如连续运行函数或者该设备，或者该功能，涵盖了以上三种。 测试顺序从1－4，按照过程的重要性分类。 回归测试说明：对已发布使用的版本，在维护阶段发现的问题，进行的再测试。 测试执行要素： 测试环境 测试对象 测试用例 测试程序 测试数据 测试报告 测试人员 它是测试的重要执行部分。 测试用例要素： 对应的测试程序的描述。 测试对象，环境的描述。 用例的版本信息。 测试内容描述。 测试项分类。 每个测试项的测试目的，测试步骤，测试结果等描述信息。 BUG信息，等级分类等。 相关性文件链接。 演示模板，用以新手参考。 它是测试操作的重要依据。 测试程序要素： 可执行文件 源代码 设计文档 测试脚本 操作文档 版本控制 它是观察对应测试对象的程序。 对于测试用例和测试程序哪个先作，个人认为应该现写测试用例的描述部分，即各个测试项的目的和方法，测试程序按照测试描述编写，最后测试用例的测试步骤部分按照测试程序的操作文档编写。 测试环境要素： 温度，//包括是否用空调 地点，//准确位置，经度纬度。 时间，//标准时间 辅助工具 测试对象要素： 硬件信息，各个版本号，出厂日期 软件信息，版本号，发布日期 开发人员，包括姓名，部门，联系方式 测试人员要素 人数 个人信息 状态 测试数据要素 配置参数 脚本参数 输出数据//通讯包，显示返回 打印单据等信息 它是测试过程中的I/O。 测试报告要素 测试对象环境等描述。 测试过程参考用例以及程序描述。 测试结果描述，BUG等级，分析。 测试执行的时间周期。 它是版本发布的记录，以及维护出现问题反查的依据。针对了各种测试结果，分析，发给对应的开发人员。如果使用CVS来控制版本，需要记录上传的项目标签。 测试总结：对整个测试过程的总结和分析，发给项目负责人用于备档。 现阶段测试状况与期望的比较 #Item 现在的状况 期望状况 测试流程 当有版本需要测试的时候，直接找用例和程序进行测试。 按照标准的流程步骤，紧而有序的进行对应版本的测试。并填写对应的文档。 单元测试 有API的测试用例，和程序，但是没有完整的要素，和对应的文档，无法很快了解测试的方式。 独立一套的用例和程序，对应完整的要素，测试人员非常容易操作测试并记录测试结果。除了传统的完全人工测试，增加脚本控制的测试，并对用例进行分类和细化。 集成测试 有测试程序，暂时没看到用例，可能有，同样的各个要素不完整。 用脚本文件来控制函数调用关系和流程。完整的文档机制以及测试要素。对测试结果有PC的工具做分析和反查。 系统测试 没有单独的测试程序来测试，也没有对应的用例。 有比较通用的实际应用来做系统测试如EDC，并且提供详细的测试案例，不同于应用的UAT，因为不是测试应用程序的功能，而是底层库的功能。 压力测试 在单元测试的用例体现出来，没有单独的测试流程。 单独的流程，做负荷压力测试。脚本自动化测试，并自动回传测试结果。 回归测试 不清楚。 细化测试流程，需要在实践中进一