51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2152|回复: 0
打印 上一主题 下一主题

[转贴] 软件测试准则-明明白白结束之六脉神剑

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2019-2-1 14:03:24 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
测试的结束标准有很多,我认为主要有以下六条
     一、基于测试计划
  单元测试首先要满足项目的进程,整个测试进度受开发计划与测试计划的影响。因此,单元测试计划是我们结束的一个标准。但由于执行力度的不同,以及中间的各种变数,因此计划的结束时间只能作为一个依据,为了保证单元测试的实际时间与计划时间匹配,需要做到以下几点:
  单元测试计划的颗粒度要够细,根据内容可区分需求验证计划、功能验证计划、性能验证计划、公共项目测试计划;根据时间可以建立月计划、周计划、甚至日计划等
  计划并不是一个表格,它需要和测试人员共同沟通并达成一致,一个盲目下达的计划很容易产生执行偏差以及人员的逆反心理。
  每步计划的执行反馈要明确到人、事。测试结果不能仅仅是报告上的一个“通过”, 它需要形成书面报告或者口头报告。
  测试计划必须基于整体测试策略以及测试方案,并将计划、策略、方案传达给所有测试人员,使大家有着相同的测试目标。

 二、基于测试用例
  单元测试阶段,测试人员往往通过测试用例来执行测试,用例的质量与执行情况便决定了单元测试的质量。当测试用例全部测试完毕并通过时,表明单元测试结束,但为了更好的保证质量,我们需要从以下情况把握:
  用例的设计必须基于测试计划、测试策略和测试方案,过细与过粗的方案都会影响测试的质量以及测试的周期。
  用例必须区分重要、一般、次要,保证重要用例100%执行完成。
  用例的执行进度需要在计划中体现,且不能只是单纯百分比的体现。
  用例必须要评审。

 三、基于测试内容
  单元测试需要测试很多内容,比如需求条目、功能验证、公共项目验证、性能验证、产品组合、加密等等,我们需要保证每项测试内容全部验证通过。比如:
  需求条目完全验证通过。
  功能验证可基于用例、特性、场景、节点等多种维度展开,保证功能覆盖率达到100%
  公共项目验证达到100%
  性能测试条目全部验证通过。

 四、基于代码
  目前我们是基于黑盒测试,虽然对代码关注不够,但通过开发部的协助,代码的测试也有几个标准可作为单元测试结束的依据
  核心代码必须经过开发人员及开发经理的代码检查与代码走查。
  代码的语句及分支的覆盖率达到70%或者更多。
  代码的缺陷发现率,比如千行代码至少发现2个BUG。

 五、基于缺陷
  测试人员发现的BUG往往通过CQ或者其他缺陷系统展现,这些BUG也能成为我们单元测试的结束标准,比如有以下几点:
  所有缺陷必须全部关闭或者遗留。
  BUG的发现趋势成正常下降趋势
  一二类BUG数量极少,且在很长时间内不产生一类BUG。
  另外还有很多缺陷度量的方法,也可借鉴使用。

  六、基于测试报告
  测试报告是测试结果的体现,因此测试报告的全部完成也是我们单元测试结束的一个标准,常见的报告一般有以下:
  基于需求条目的需求验证报告
  开发部的代码检查及走查报告
  测试用例的执行报告。
  性能测试报告等
  代码覆盖率报告等
  测试风险报告
  测试人员、测试经理、部门经理的测试报告等

  达到上面这些标准后,可进入集成测试阶段。但结果仅是过程的体现,没有过程便没有结果。因此我们还是需要步步为营,稳扎稳打,保证每道工序做到最好。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-23 09:18 , Processed in 0.074728 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表