软件测试 http://blog.okbase.net/spasvo 免费BUG管理工具-TCE-小程序上上上线啦! http://blog.okbase.net/spasvo/archive/56482.html spasvo 2017/11/29 15:59:16   存在比你优秀的软件不可怕,可怕的是,比你优秀的软件不仅比你更新的快,还比你功能多,还比你好用!

 

  缺陷管理工具TCE-小程序上线啦!

  没错,这里说到的优秀软件,就是这款集项目管理、用例管理、缺陷管理、报表于一体的,轻量级的测试管理工具——TestCenter Enterprise(简称TCE)!
  作为国内首个bug管理工具,TCE一直被众多缺陷管理软件模仿,却从未被超越。如今,TCE更是领先其他工具,隆重推出“TCE微信端小程序--测试项目管理TCE”!

  TCE小程序做到了与众测平台集成,一号多用,平台互通!数据共享!实现众包项目的招募、沟通、测试、管理一站式服务!TCE注重敏捷项目管理,界面更加直观,只需要注册登录就能使用, 接下来,就让我们带你走进微信小程序--测试项目管理TCE的神秘世界!

 

  【注册方式】

  1、Alltesting众测平台(服务号)-项目列表-我的-立即注册;

  
众测平台-项目列表-我的→

 

  
立即注册→

 

  
填写信息-注册成功!


  2、PC端-打开Alltesting众测平台官网:www.alltesting.cn-免费注册;

 

 
【寻找小程序】


  打开微信(微信-发现-小程序)中搜索“TCE”或“测试项目管理TCE”找到该小程序;


  微信-发现-小程序→

 


  测试项目管理TCE→

 


 进入小程序
 

 

【TCE小程序有哪些内容?】
 
  项目列表→

 

 
新建项目→

 


缺陷列表→

 

 
查看报表

  本次上线版本为小程序的首个版本,后期我们会继续升级更新,
  增添“在线注册”等功能,请大家多多关注哦!
  TCE下载地址:http://www.alltesting.cn/jsp/newVersion2/tce.jsp

]]>
软件性能测试见解与总结 http://blog.okbase.net/spasvo/archive/56334.html spasvo 2017/8/10 15:49:10 软件性能测试见解与总结

入行快两年了,在这几年里,目睹软件测试得到极大的发展,各企业对于测试的需求大大增加,但据我所了解,大部分的企业对测试的需求大多只是停留在黑盒测试阶段,其实这样的测试是不完整的。对于测试本身,个人认为可以依照面向对象的不同划分为三种。

1、面向系统:即面对被测系统本身,这类测试主要是验证被测系统的完善性,健全性。具体的测试目的为验证方法函数是否正确,功能是否正常,需求是否满足,即包含着单元测试,集成测试、确认测试、系统测试、验收测试等。

2、面向用户:指的是站在用户的角度上测试系统是否存在缺陷,这类测试主要针对用户体验度。具体的表现在于界面是否美观,系统是否易用,能否兼容多设备,能否快速响应等,具体的测试有UI测试,兼容性测试性能测试等。

3、面向企业:考虑更多的是系统是否存在风险,具体表现在于数据泄漏,权限安全等,常见的测试有安全测试。

对于测试的需求,面向企业可以视情况抛弃或者推迟,但是面向系统与面向用户是缺一不可的。面向系统就不必多说了,这是最常规的黑盒测试,是系统质量的最基本体现。除了功能的健全完善之外,我们还应该更多的关注用户的体验,因为站在用户的立场上,使用一个系统最为直观的感受就是界面美观与响应速度。

鉴于之前所言,在此总结一下个人对性能测试的一些见解与总结。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

通俗的讲,就是通过工具模拟用户操作系统再模拟多用户并发使用,通过监控过程中的服务器资源占用情况以及虚拟用户使用情况。从而分析数据找出当前系统性能瓶颈,以及造成这个情况的原因。那么,我们需要弄清楚几个问题。

工具如何模拟?

当我们打开浏览器访问一个web系统时,浏览器会向这个web系统的服务器发送一系列的请求(可以安装抓包工具进行查看),当服务器收到请求之后,会对每个请求做出回答并把信息返回给浏览器。浏览器拿到返回来的数据之后,进行处理之后呈现页面给我们查阅。而在性能测试中,工具就相当于是一个浏览器,它可以向服务器发送请求,能收到从服务器返回来的数据,但是它对数据不进行处理,而是直接呈现给我们。我们可以按照操作把需要请求的接口按顺序设置好就能模拟出用户进行了某个动作操作了系统。接着通过设置并发数(虚拟用户)来进行模拟多用户同时使用的情景。正因为这样,所以我们在进行性能测试的时候,所设计的脚本需要尽可能的符合现实情况。否则得到的数据无法反映出服务器的真实情况。

如何展开性能测试

在了解了性能测试的工作原理之后,那么我们该如何展开测试工作呢? 如果从测试准备阶段就开始讲的话,那这里就太长太臭了。所以我在这里就分阶段从简代入。

1、设计脚本:不同工具对脚本的编写的具体实现方式不同,但是他们做的都是同一件事,就是工具在运行脚本的时候能按操作顺序向服务器发送请求。除了按照顺序之外,我们的脚本还需要各种不同的设置,比如参数化,关联,检查点,添加思考时间等等,因为Http请求是无状态的,如果所测功能需要登录才能进行的话,还需要注意添加Cookie或者SessionID。在写好之后,就运行吧,体验一下成果。

2、数据分析:在运行之后,会得到一个运行的结果概要图或者详细数据,数据分析的话,如果是负载测试等想要了解系统瓶颈的测试方法,则多关注服务器的资源。如果想清楚服务器的处理能力,则多关注响应时间,TPS,吞吐量等数据。

3、情景设计:但是现实中,系统使用过程中不可能出现在线用户全部都只操作某个模块的某个功能。这时,需要我们通过各种途径了解用户不同时间段所使用各模块的大概情况。然后再把各种情况融入到脚本中。

除此之外,还有的就是用例以及报告等设计编写了。一份好的用例可能让测试事半功倍,一份好的报告可以更能体现测试结果。

本文转自:http://www.spasvo.com.cn/products/tc.asp

]]>
测试用例的设计步骤 http://blog.okbase.net/spasvo/archive/56311.html spasvo 2017/8/2 15:48:23 测试用例的设计步骤

作为测试新人,如何实现测试用例的设计一直是我的一个疑惑,在工作中写过几个项目的测试用例,尝试总结一个测试用例的设计步骤。

前提:

编写测试用例之前我们需要对项目的需求有清晰的了解,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数,作为测试用例的编写者不仅了解要有常见的测试用例编写方法,同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。

步骤:

1、测试需求分析

从项目部拿到软件的需求规格说明书后,开始对项目的需求进行分析,通过自己的分析、理解,整理成为测试需求, 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系,即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

分析完需求后,明确每一个功能的业务处理流程,不同的功能点作业务的组合,以及项目的隐式需求。如遇复杂的测试用例设计前,先画出软件的业务流程。

从业务流程上,应得到以下信息:

A、 主流程是什么?

B、 条件备选流程是什么?

C、 数据流向是什么?

D、 关键的判断条件是什么?

3、测试用例设计

完成以上两步则可进行测试用例设计,功能测试用例,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。

设计测试用例的常见方法

1)等价类

2)边界值

3)因果图

4) 判定表

5) 状态迁移

6) 正交实验

7) 场景法

8) 错误推断

注意:编写测试用例时,我们尽可能取的不应该是有效等价类而应该是无效等价类

4.编写完成后自我检查以及部门内部评审

5.测试用例更新完善

测试用例编写完成之后需要不断完善,如遇需求更改或功能新增时,测试用例必须配套修改更新,同时在测试过程中发现设计测试用例时考虑不周,需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。

TestCenter (测试管理工具)

TestCenter(简称TC)是面向测试流程的测试生命周期管理工具,符合TMMI标准的测试流程,可迅速建立完善的测试体系,规范测试流程,提高测试效率与质量,实现对测试的过程管理,提高测试工程的生产力。

TestCenter官网:http://www.spasvo.com.cn/products/tc.asp

]]>
如何建立软件测试管理体系? http://blog.okbase.net/spasvo/archive/56309.html spasvo 2017/8/1 15:01:53 如何建立软件测试管理体系?

软件测试是软件质量保证的关键步骤。美国质量保证研究所对软件测试的研究结果表明:越早发现软件中存在的问题,开发费用就越低;在编码后修改软件缺陷的成本是编码前的10倍,在产品交付后修改软件缺陷的成本是交付前的10;软件质量越高,软件发布后的维护费用越低。另外,根据对国际著名IT企业的统计,它们的软件测试费用占整个软件工程所有研发费用的50% 以上。

相比之下,中国软件企业在软件测试方面与国际水准仍存在较大差距。首先,在认识上重开发、轻测试,没有认识到软件项目的如期完成不仅取决于开发人员,更取决于测试人员;其次,在管理上随意、简单,没有建立有效、规范的软件测试管理体系;另外,缺少自动化工具的支持,大多数企业在软件测试时并没有采用软件测试管理系统。所以对国内软件企业来说,不仅要提高对软件测试的认识,同时要建立起完善的软件测试管理体系。

让软件测试走向规范

建立软件测试管理体系的主要目的是确保软件测试在软件质量保证中发挥应有的关键作用:

软件产品的监视和测量对软件产品的特性进行监视和测量,主要依据软件需求规格说明书,验证产品是否满足要求。所开发的软件产品是否可以交付,要预先设定质量指标,并进行测试,只有符合预先设定的指标,才可以交付。

对不符合要求的产品的识别和控制 对于软件测试中发现的软件缺陷,要认真记录它们的属性和处理措施,并进行跟踪,直至最终解决。在排除软件缺陷之后,要再次进行验证。

产品设计和开发的验证 通过设计测试用例对需求分析、软件设计、程序代码进行验证,确保程序代码与软件设计说明书的一致,以及软件设计说明书与需求规格说明书的一致。对于验证中发现的不合格现象,同样要认真记录和处理,并跟踪解决。解决之后,也要再次进行验证。

软件过程的监视和测量从软件测试中可以获取大量关于软件过程及其结果的数据和信息,它们可用于判断这些过程的有效性,为软件过程的正常运行和持续改进提供决策依据。

建立测试管理体系

一般应用过程方法和系统方法来建立软件测试管理体系,也就是把测试管理作为一个系统,对组成这个系统的各个过程加以识别和管理,以实现设定的系统目标。同时要使这些过程协同作用、互相促进,从而使它们的总体作用大于各过程作用之和。其主要目标是在设定的条件限制下,尽可能发现和排除软件缺陷。测试系统主要由下面6个相互关联、相互作用的过程组成:

1、测试规划

确定各测试阶段的目标和策略。这个过程将输出测试计划,明确要完成的测试活动,评估完成活动所需要的时间和资源,设计测试组织和岗位职权,进行活动安排和资源分配,安排跟踪和控制测试过程的活动。

测试规划与软件开发活动同步进行。在需求分析阶段,要完成验收测试计划,并与需求规格说明一起提交评审。类似地,在概要设计阶段,要完成和评审系统测试计划;在详细设计阶段,要完成和评审集成测试计划;在编码实现阶段,要完成和评审单元测试计划。对于测试计划的修订部分,需要进行重新评审。

2、测试设计

根据测试计划设计测试方案。测试设计过程输出的是各测试阶段使用的测试用例。测试设计也与软件开发活动同步进行,其结果可以作为各阶段测试计划的附件提交评审。测试设计的另一项内容是回归测试设计,即确定回归测试的用例集。对于测试用例的修订部分,也要求进行重新评审。

3、测试实施

使用测试用例运行程序,将获得的运行结果与预期结果进行比较和分析,记录、跟踪和管理软件缺陷,最终得到测试报告。

4、配置管理

测试配置管理是软件配置管理的子集,作用于测试的各个阶段。其管理对象包括测试计划、测试方案(用例)、测试版本、测试工具及环境、测试结果等。

5、资源管理

包括对人力资源和工作场所,以及相关设施和技术支持的管理。如果建立了测试实验室,还存在其他的管理问题。

6、测试管理

采用适宜的方法对上述过程及结果进行监视,并在适用时进行测量,以保证上述过程的有效性。如果没有实现预定的结果,则应进行适当的调整或纠正。

此外,测试系统与软件修改过程是相互关联、相互作用的。测试系统的输出(软件缺陷报告)是软件修改的输入。反过来,软件修改的输出(新的测试版本)又成为测试系统的输入。

根据上述6个过程,可以确定建立软件测试管理体系的6个步骤:

识别软件测试所需的过程及其应用,即测试规划、测试设计、测试实施、配置管理、资源管理和测试管理;

确定这些过程的顺序和相互作用,前一过程的输出是后一过程的输入。其中,配置管理和资源管理是这些过程的支持性过程,测试管理则对其他测试过程进行监视、测试和管理;

确定这些过程所需的准则和方法,一般应制订这些过程形成文件的程序,以及监视、测量和控制的准则和方法;

确保可以获得必要的资源和信息,以支持这些过程的运行和对它们的监测;

监视、测量和分析这些过程;

实施必要的改进措施。

TestCenter打造测试管理体系

所谓工欲善其事,必先利其器,有了事半功倍的工具,自然能提高工作效率,软件测试管理系统就是建立软件测试管理体系、保证软件测试顺利进行的利器。TestCenter是泽众软件(SPASVO)公司从软件测试的需求出发,按照国际质量管理标准研制的软件测试管理系统。

它采用B/S结构,可以安装在Web服务器上,项目相关人员可以在不同地点通过Internet同时登录和使用TestCenter,协同完成软件测试,可减少为了集中人员而出差所产生的费用。它还提供相应的自动化功能,可高效地编写、查询和引用测试用例,快速填写、修改和查询软件缺陷报告,减少了人力投入。它自带的测试用例数据库和软件缺陷数据库,可以帮助项目成员更好地实施软件测试。

在具体的软件缺陷中,它将其生命周期分为6个生命状态:openworkingverifycancelclosedefer,能详细记录、跟踪和管理每个软件缺陷的生命过程,直至排除这个缺陷。它还为软件缺陷设定了严重级别、优先级、缺陷类型等属性,可自动分清软件缺陷的轻重缓急,并能提供相关的分析和统计功能。

此外,除了可以监测和分析软件的质量,TestCenter还可以自动统计程序员和测试人员的工作进度。它提供的测试文档模板,可以将测试文档及数据直接传送到Office,使排版、打印等操作更为便捷。

TestCenter(简称TC)是面向测试流程的测试生命周期管理工具,符合TMMI标准的测试流程,可迅速建立完善的测试体系,规范测试流程,提高测试效率与质量,实现对测试的过程管理,提高测试工程的生产力。

TestCenter测试管理工具官网:http://www.spasvo.com.cn/products/tc.asp

]]>
关于手工测试,应该如何做? http://blog.okbase.net/spasvo/archive/56287.html spasvo 2017/7/24 15:02:01 关于手工测试,应该如何做?

每一个与软件相关的企业,都少不了这样一群人。他们被称之为测试,一群以发现缺陷为职责的人。他们与开发是一对欢喜冤家。他们每天做的最多的工作就是重复,无尽的重复,在待测软件中找出隐藏的隐患,保证软件的质量。他们是一群永远都保持怀疑的人。

很多时候,其他人对于我们测试人员寄予厚望,希望我们能够发现软件产品中潜在的所有风险(当然这是不可能的,世界上没有完美)。但是总有很多因素在制约着我们的发挥,知识面、经验、思维定式等等。知识和经验也许可以通过别的途径来弥补,但是思维定式很难跳出,特别是当一个软件、一个模块,同一个人测试了多遍以后,思维定式几乎不可避免。这个时候我们怎么办,这时就要看我们测试准备工作的功底如何了。下面是我整理的测试准备工作,希望能给大家带来一定的帮助。

一、测试内容

确定自己的测试对象是什么,一个软件,什么软件;或者一个模块,什么模块。准备需要测试的软件的需求规格说明书、原型交互图以及系统效果图等等一切和软件有关的需求文档;通过对这些需求文档进行分析总结,使测试人员能够很好的了解甚至是全面了解被测对象的所有功能点以及需求点;

二、使用场景

用户在什么情况下会使用该软件或者模块,期望达到什么效果,用户关注什么。测试人员需要在测试之前认真的去思考待测对象被使用的场景,包括测试场景以及用户场景

三、测试重点

本次测试的重点是什么,是主要测试功能还是测试性能功能健壮性还是性能或者其他方面。测试人员需要清晰的知道本次测试的重点内容,知道重点之后不仅可以着重测试重点内容,而且可以减少测试时间提高测试效率。

四、测试环境

在什么环境下测试,即待测软件需要什么样的测试环境,包括软件和硬件以及网络要求等;对于数据库有无要求,数据量有无要求,操作系统有无要求,存不存在制约软件使用的硬件等等;

五、实现机制

作为一个测试,我们也许不需要了解一个软件的实现细节。但是基本的实现流程,我们绝对需要了解,它可以帮我们快速锁定软件的危险区,通过了解待测软件的实现机制,可以减少测试时间,提高我们的测试效率。并且能够为开发人员提供详细准确的bug产生的位置,帮助开发人员快速高效的解决产生的bug;

六、日志路径

测试软件之前,一定要确定日志文件在哪里。作为一个测试,定位bug产生的点是我们必不可少的一个工作,有日志的话,相信大家可以快速确定一个bug的级别高低。测试人员需要学习如何查看错误日志,并且学习更多的关于快速定位bug的方法。

七、版本差异

如果是一个增量版本,请确定是否存在版本差异。本次测试版本与上个版本不同点在哪里,需要关注什么,这点很重要。因为很多软件,外观可能没有变动,里面早已今非昔比。而且,测试人员需要时刻关注待测软件是否有需求变更的部分,若有需求变更的部分,测试人员在测试的时候需要着重测试需求变更的部分,同时要关注需求变更知否是否会对其他关联模块产生什么影响。

转自:http://www.spasvo.com.cn

]]>
阿里云和SPASVO合作推出BUG管理工具TestCenter企业免费版 http://blog.okbase.net/spasvo/archive/55989.html spasvo 2016/12/2 17:07:07

  1、产品介绍
  TestCenter(简称TC)是面向测试流程的测试生命周期管理工具,符合TMMI标准的测试流程,可迅速建立完善的测试体系,规范测试流程,提高测试效率与质量,实现对测试的过程管理,提高测试工程的生产力。
  2、产品概述

 

TestCenter

传统测试

PK

支持GB/T11457-1995,GJB2725A-2001规定的测试流程,从应用系统需求出发,定义了标准的测试流程:测试需求创建、评审;测试计划;测试用例评审、执行;测试任务分配、报工;缺陷管理;测试报告生成等。

使用word、excel等来编写和管理测试用例、测试需求、缺陷等,测试流程无法完善。

测试用例

标准化测试用例库构建,支持测试用例树与需求树的同步,支持测试用例关联缺陷、需求。

测试用例缺乏规范性,质量无法控制,测试工程师之间无法共享,成本增加、资产浪费。

测试过程

覆盖了测试过程中的整个流程,也覆盖了流程上的所有角色,确保测试工作中的协同工作。

测试过程难以进行管理,无法保证需求覆盖率、用例执行情况、所有缺陷均关闭。

测试需求

支持对测试需求的全方位管理:导入导出,评审,与用例缺陷关联,变更等,支持word、excel格式的测试需求导入。

无法对每个需求项进行跟踪管理,及需求变更后测试用例哪些需要重新设计、哪些需要回归。

缺陷管理

支持自定义缺陷管理流程。

缺陷管理的力度不足,对测试过程中产生的缺陷,没有进行登记、编号,并且采用标准化的流程进行跟踪,无法确保每个缺陷都已经被关闭。遗漏的缺陷对软件的正常使用是非常重大的威胁。

  3、TC流程图

  4、产品功能
  ◇ 测试计划管理
  支持发布版本管理,版本关联测试计划,计划关联测试轮次;支持轮次包含测试集合,通过测试集合执行用例;支持通过发布版本的需求基线创建测试集。
  ◇ 标准化测试用例库构建
  支持测试用例的各种状态:通过、未执行、失败;支持手工编写测试用例、用例附件批量导入;支持执行中的测试用例管理;保证测试用例的质量,实现测试用例的标准化,降低了测试用例对个人的依赖。
  ◇ 缺陷管理
  支持根据实际情况自定义缺陷处理流程,可以自定义项目角色、缺陷状态、缺陷属性;支持缺陷合并,全方面筛选缺陷;支持实时邮件的功能,在关注的缺陷发生状态改变时,发邮件通知给关注人;支持缺陷列表的导出、缺陷处理状态的自动跳转、处理角色的选择、缺陷关联测试用例和需求等。
  ◇ 测试项目管理
  支持项目的团队管理;支持字段属性自定义。新版本新增了报文配置、工作周报、报工审批等功能,可以统筹管理整个测试项目
  ◇ 日志报表与测试分析
  支持手工测试日志,以测试用例为单位来保存测试日志;支持自动测试日志,支持步骤、截图显示和校验规则结果;持每次测试的测试报表;支持用户自定义报表,支持多种统计图标,如需求覆盖率图、测试用例完成的比例分析图、业务组件覆盖比例图等;支持自动化测试的测试分析报告与手工测试的测试分析报告。
  5、产品说明

 

档次

用户个数

费用(元/年)

技术服务费(元/年)

备注

1

10人以下(含10)

0.00(免费)

900

试用期间 不收费用

2

11-20(含20)

1000

3

21-30(含30)

2000

4

31-40(含40)

3000

5

41-50(含50)

4000


  TestCenter官网地址:http://www.spasvo.com/testcenter/
  TestCenter测试管理工具【免费版】下载地址:https://market.aliyun.com/products/53400005/cmjj014287.html?spm=5176.730005.0.0.FYAvQD

]]>
如何编写和设计测试用例? http://blog.okbase.net/spasvo/archive/55917.html spasvo 2016/10/14 17:13:05   一、测试用例是软件测试的核心

  软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

  影响软件测试的因素很多,例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的,无法避免。有些因素则是波动的、不稳定的,例如开发队伍是流动的,有经验的走了,新人不断补充进来;一个具体的人工作也受情绪等影响,等等。如何 保障软件测试质量的稳定?有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。

  因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导,是软件测试的必须遵守的准则,更是软件测试质量稳定的根本保障。

  二、什么叫测试用例

  测试用例(Test Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略,内容包括测试目标测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。

  不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据测试脚本测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的 每个特定功能或运行操作路径的测试构成了一个个测试用例

  三、编写测试用例

  着重介绍一些编写测试用例的具体做法。

  1测试用例文档

  编写测试用例文档应有文档模板,须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

  软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位,形成一个测试用例文档,但并不是绝对的。

  测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例 基本元素:测试索引,测试环境,测试输入,测试操作,预期结果,评价标准。

  2测试用例的设置

  我们早期的测试用例是按功能设置用例。后来引进了路径分析法,按路径设置用例。目前演变为按功能、路径混合模式设置用例。

  3、按功能测试是最简捷的,按用例规约遍历测试每一功能。

  对于复杂操作的程序模块,其各功能的实施是相互影响、紧密相关、环环相扣的,可以演变出数量繁多的变化。没有严密的逻辑分析,产生遗漏是在所难免。路径分析是一个很好的方法,其最大的优点是在于可以避免漏测试。

  为提高测试效率,软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书,那么测试脚本的设计规格说明书就是测试用例

  4、评估测试结果的度量基准

  完成测试实施后需要对测试结果进行评估,并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例:测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,等等。以前统计基准是软件模块或功能点,显得过于粗糙。采用测试用例作度量基准更加准确、有效。

  5、分析缺陷的标准

  通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映实施测试或变更处理存在问题。

  四、相关问题

  1测试用例的评审

  测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审,需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成,也可邀请客户代表参加。

  2测试用例的修改更新

  测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故:第一、在测试过程中发现设计测试用例时考虑不周,需要完善;第二、在软件交付使用后反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成;第三、软件自身的新增功能以及软件版本的更新,测试用例也必须配套修改更新。

  一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。

  3测试用例的管理软件

  运用测试用例还需配备测试用例管理软件。它的主要功能有三个:第一、能将测试用例文档的关键内容,如编号、名称等等自动导入管理数据库,形成与测试用例文档完全对应的记录;第二、可供测试实施时及时输入测试情况;第三、最终实现自动生成测试结果文档,包含各测试度量值,测试覆盖表和测试通过或不通过的测试 用例清单列表。

有了管理软件,测试人员无论是编写每日的测试工作日志、还是出软件测试报告,都会变得轻而易举。

本文转自:http://www.spasvo.com/news/html/20161010163514.html

]]>
项目管理之如何控制项目进度和质量 http://blog.okbase.net/spasvo/archive/55881.html spasvo 2016/9/1 16:55:32   控制项目进度和质量首先在整体上要有一个合理清晰的流程,并且在整个管理过程中,严格按照流程走。流程的每一步如果都控制好了,那么整个项目管理就不会出大问题。

  下图是我们所有项目应该严格遵守的流程。

   流程-需求

  需求是整个流程的入口。通常需求从客户那里来,而客户通常不是那么专业,客户发过来的需求可能很零散,甚至可能不合理,这时,项目经理需要对需求进行整理,并且多次不断跟客户沟通,保证正确理解了需求。

  一个项目的需求入口必须只能是一个人——项目经理。相信很多项目都遇到过这种情况,客户好像跟有的开发人员很熟悉,有时候客户会把需求告诉开发人员,开发人员就自己做了,结果项目经理不知道。这就会出很大的问题。所以,不管来自内部还是外部的需求,所有的需求都只能经过项目经理

  流程-原型

  原型用axure画,不管是webdesktop还是APP,都用axure画。目前为止没有比axure更强大的原型工具。

  在我们的经验中,导出成网站的原型,可以作为需求管理很重要的一部分。所以,每一次需求的变更都应该首先体现到原型中,原型一定要一直维护下去。

  画原型的一个最最重要的经验就是,要把所有的UI都体现出来。包括哪些呢?各种状态下的界面,所有的错误或者提示,也就是说凡是最终用户看得见的东西,全部要体现在原型中。

  由于原型本身还是需求管理系统的一部分,所以,原型页面上也可以放一些业务逻辑说明,特别是页面跳转等。还有一些隐藏的业务逻辑也可以在原型页面上写出来。

  流程-UI设计

  原型做好了之后,就可以让UI团队开始基于原型做设计了。设计做好了就切图。设计团队的产出物为设计源文件、效果图和切图。放到SVN里面供开发人员使用。

  流程-测试用例

  原型做好了之后,测试团队就可以基于原型写测试用例了。如果没有测试团队,这一步也可省去。

  流程-任务系统

  这一步是非常关键的,其中最重要的工作就是功能评估。功能评估建议用Xmind软件来做,评估好了再录入到我们的任务系统。参考:

  如果项目经理不是项目所需技术领域的专家,那么在评估的时候,叫上技术团队领头人一起。但是一个好的项目经理,即使是自己不熟悉的技术领域,自己也应该有一个比较准确的评估。

  任务评估时间还应该包含开发人员自测的时间。

  当任务都评估好了,就可以录入到我们的任务系统了。录入任务系统之后,就是做迭代计划。

  在我们的任务系统中,开发计划是通过迭代来做的。建议每一周提一个迭代,最多不超过2周一个迭代。开发人员只需要关心当前这一个迭代里面的所有任务,至于具体先完成哪个任务,如无特殊要求,都应该让开发人员自行安排或者项目经理给一些建议。

  每一个迭代要求明确的开始和结束日期。一旦结束日期到,就应该把迭代里面未完成的任务移到下一个迭代。也就是说,迭代日期到,迭代的进度就是100%。对于有些只完成了一部分的任务,在我们的任务系统中,要么你可以拆分任务把已完成的部分拆分出来,要么你也可以把整个任务移到下一个迭代。

  开发人员完成功能开发之后,首先要经过全面的自测。一个聪明的开发人员应该在自测的时候解决绝大多数BUG。经过自测的产出物应该是具有很高质量的,特别是高质量的UIUX。自测通过才能提交给测试团队,或者项目经理。做不到这一点的开发人员应该被淘汰。

  自测完成之后,填写工时记录,将进度标记为100%,将任务状态标记为完成(不是关闭)。

  流程-测试

  如果没有测试团队,测试就应该由项目经理负责。

  测试中报的BUG要提交到任务系统。测试人员提交BUG的时候不需要评估时间,并且也不需要指派。项目经理把所有未指派的BUG列出来,然后进行时间评估,然后再指派给某个开发人员。

  BUG也是属于迭代的。如果不是那么紧急的BUG,可以暂时不安排到迭代里面,可以等到最后再去修复BUG

  流程-完成

  测试团队测试通过,项目经理可以根据实际情况看是否需要再检查一遍。或者检查的力度到什么程度,这都由项目经理自行决定。检查通过,任务状态标记为关闭,任务完成。

  问题 – 团队间等待

  开发过程中,可能各个技术团队之间的衔接会出现等待。比如客户端开发的开发人员,在做到某一个功能的时候,结果UI设计或者API还没有准备好,那么就只能等起。

  这种衔接等待是无法避免的,我们只能尽可能降低等待的时间。我们是这样解决的:

  在我们的任务系统中,我们会加一个任务标签,叫“紧急任务”。注意这里是标签,不是优先级也不是任务类型。一旦出现这种等待,等待的人就给被等待的人建一个“紧急任务”。如果等待的人没有新建任务的权限,那么交给其团队负责人创建。我们也建议你把这类任务同时放到一个任务分组里面,并且加个快速查询。

  等待的过程中,开发人员可以用假数据或者假UI来代替,等数据或UI准备好后再替换。

  问题 – 需求变更

  需求变更是任何开发团队都无法避免的问题。我们要做的就是把需求变更对项目造成的影响尽可能降到最低。

  通常情况下,只有最紧急的需求才会放到当前的迭代,否则变更的需求都应该放到以后的迭代。如果放在当前的迭代,那么就需要把当前迭代中的部分任务移到下一个迭代。并且跟客户沟通好这个计划的改变。

  需求变更时,一定要将需求更新到需求管理系统(原型和任务系统),不管变更的需求造成的工作量有多大。这一点是很多项目忽略的。举个例子,用户完成注册,本来系统送100金币,某天客户过来说改成送200金币,结果程序员就花了几分钟时间将100改成200了事。过了几个月,新同事加入项目,看需求系统里还是写的100,就去问项目经理,项目经理就说什么时候改成200了。于是这个需求管理系统就再没有人相信和使用了。所以这一点非常重要。

  需求变更时,要按照本文开始的流程图一步一步走,因为是新的需求从流程入口进来了。

  项目管理中经常还会遇到其他棘手的问题,扰乱项目计划,让项目管理失去了对进度和质量的控制。

  本文转载自:http://www.spasvo.com/news/html/2016826135059.html

]]>
你在过度测试你的软件吗? http://blog.okbase.net/spasvo/archive/55878.html spasvo 2016/8/23 15:19:01   发布候选测试需要花费很长时间,这是许多敏捷团队都面临的一个最大的挑战。但据JavaWorld报道,许多公司都通过持续交付模型消除或极大地减少了发布候选测试,而且它们有一些共性:

  使用测试工具:有许多测试工具可以执行软件,贯穿软件的基本流程。因此,选择恰当的自动化检查工具非常关键,而其目标是降低风险,快速执行,减少手工维护的工作量。

  将工具钩连到构建系统:等待构建完成再手工执行检查会浪费大量的时间,而在每次构建时自动检查可以消除这种浪费,最好是有一个自动化的检出/构建/部署/测试/推广管道。

  从根本上消除回归错误:利用减少发布候选测试节省出的时间改进开发实践。

  开发可单独部署的组件:借助组件,每个变更都是相互隔离的。变更影响范围小,降低了部署风险,使得部署或回滚过程更可控。

  根据风险划分测试/部署策略:不同的功能可能需要不同的测试策略或过程,高风险、发布频率低的变更可能需要更严格的测试过程ZapposAmazon的一个部门)很久之前就采用了这种方式。

  持续监控生产环境:缺陷代码在生产环境中存在的时间越长造成的损害越大。如果团队可以快速发现并修复缺陷,那么风险将大大降低。

  自动部署和回滚:通过几次点击就可以实现部署或回顾。

  配置标识:程序员在编码时将新特性封装在一个if()语句中,然后就可以通过将配置标识设置为“On”或“Off”来启用或关闭特性。感兴趣的读者可以阅读下这篇文章。

  增量滚动发布:将配置标识与不同的用户关联,就可以实现为不同的客户提供不同的功能。感兴趣的读者可以看下微软的做法。

  当然,并不是在任何情况下都可以消除发布候选测试。在某些情况下,需要在测试时间和发布风险之间进行权衡。也就是说,要根据风险制定灵活的发布候选测试策略。

  对于JavaWorld的报道,有网友提出了不同的意见。Steve Naidamast认为:

  这个消除或减少应用程序的建议跟实际的测试过程一样复杂,甚至更复杂……此外,由于能力的不足或工具的缺陷……,会引入新的问题……

  而网友Chris Riley则认为该报道具有误导性:

第一,它没有建议我们减少测试,而只是将测试移到了管道中的不同位置。第二,持续交付并不适合所有人……这看上去是个不错的理想,但可能会误导R&D主管在没有备用计划的情况下错误地削减了QA职位

本文转自:http://www.spasvo.com/news/html/201591103204.html

]]>