[发明专利]一种改进的软件测试模型及测试方法

说明书

技术领域

本发明涉及一种软件测试领域，具体地说是一种改进的软件测试模型及测试方法。

背景技术

软件测试是软件质量保证的一个重要元素。软件测试和软件开发一样，都遵循软件工程原理，遵循管理学原理。软件测试模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。在测试过程中使用合理的软件测试模型可以降低测试在开发活动中的花费和开发时间。传统的V模型仅仅把测试作为编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求的分析、系统设计等活动的验证和确认功能。W模型是v模型的优化，但也有局限性，把软件开发视作需求、设计、编码等一系列串行活动，无法支持迭代、自发性以及变更调整。X模型定义了探索性测试，这是不进行事先计划的特殊类型的测试，这一方面往往能帮助有经验的测试人员在计划之外发现更多的软件错误，但对测试造成人力、物力和财力的浪费，对测试人员的熟练程度要求较高。

发明内容

　　本发明的技术任务是针对以上不足之处，提供一种操作简单、生产成本低、测试效率高的改进的软件测试模型及测试方法。

本发明解决其技术问题所采用的技术方案是：一种改进的软件测试模型，其特征在于：包括W模型和X模型，剔除W模型和X模型中与实际测试符合率低的局限，在测试过程中设置有预期bug数比对和bug收敛趋势分析。

一种改进的软件测试方法，步骤如下：（1）将系统依据模块划分，进行模块的开发和测试；软件开发与软件测试各阶段同步进行验证与确认，针对软件开发进行需求分析、概要设计、详细设计、编码、模块单元测试，同步进行需求验证、功能确认、测试设计、用例编写、用例执行；

（2）通过步骤（1）完成软件开发后，进行模块单元软件测试；在模块单元软件测试前，测试负责人根据以往项目的经验、开发人员水平以及测试人员水平，综合评估该轮的预期bug数；

（3）步骤（2）测试结束后，将实际bug数与预期bug数进行比对；

（4）步骤（2）测试结束后，进行bug收敛趋势分析及风险分析，预估、规避测试风险及测试结束的时间点；

（5）当至少两个模块单元测试通过后，进行模块的集成，再对集成后的模块单元重复（2）、（3）、（4）、（5）步骤，直至系统软件发布。在模块单元测试与集成测试过程中允许迭代测试过程。

本发明的一种改进的软件测试模型和现有技术相比，具有以下有益效果：

（1）综合w模型与x模型的优势，剔除w模型与x模型中与实际测试符合率低的局限，并增加测试过程中预期bug数比对，bug收敛趋势分析及风险分析，提高对测试过程的控制，降低测试风险，该方法更贴合日常软件测试，为软件测试提供参考依据；

（2）用“预期bug数比对”代替“探索性测试”，在测试前对给出一个bug的估计值，该估计值给予测试人员的测试有一个督促和指导的作用；在测试结束后，实际bug数与bug的估计值进行对比，便于分析此轮测试的有效性即充分性，同时可以有效督促测试人员，防止人力、物力的浪费，提高工作效率；

（3）测试后进行bug趋势分析与风险分析，对于风险进行及时的弥补与控制，提高测试过程的可控性，防止后期测试出现反复的现象。

由此可见，本发明具有操作简单、节省人力、物力，提高工作效率特点，因而，具有很好的推广使用价值。

具体实施方式

下面以云海系统的开发测试为例具体实施例对本发明作进一步说明。

实施例1

一种改进的软件测试方法：步骤如下：

（1）需求确认后，开发、测试前期，将云海系统依据模块划分，并且分配模块的开发和测试人员；

（2）开发人员对模块进行需求确认、概要设计、详细设计、编码、模块单元测试的同时，该模块的测试人员进行需求的验证、功能确认、测试设计、用例编写，两者活动同时进行，沟通交互；

（3）模块编写结束后，交予该测试人员进行测试；在测试之前，测试组长根据以往的经验、模块复杂度、开发人员水平、测试人员水平等因素，综合评估该模块的bug数，该数值会给予测试人员指导和督促，提高测试的有效性和充分性；

（4）测试结束之后，对于bug数的预期值与实际值进行比对，若预期值明显大于实际值，考虑是否测试人员未充分测试，或者提交的功能不完全（即开发人员未充分开发），若预期值明显小于实际值，则考虑开发质量、提交测试的时间点是否正确；

（5）每轮测试之后，进行bug收敛趋势分析，预估、规避测试风险及测试结束的时间点；