发布新日志

  • 我谈对敏捷项目测试的理解

    2011-02-12 16:57:08

      敏捷这个词已经流行很长一段时间了,作为我们测试来说,对于这个词更加不会陌生。总是听到我们的测试人员说,在敏捷的项目中,对测试的挑战很大,之前没有机会参与敏捷的项目,所以一直望着,前段时间有幸参与到了敏捷的项目中,谈谈自己对这一类项目测试如何开展和把控质量的理解,权当抛砖引玉吧,欢迎拍砖,多拍点,我可以拿着盖个房呵呵
     
       敏捷其思想的价值就在于对一个需求的快速的响应,这个其实也不仅仅是对我们测试的挑战,对于开发和设计来说,一样是也存在很大的挑战的,这个牵涉到有时候设计的重构和代码的重写,有时候系统的可扩展性也会在这个时候变的非常的重要。
     
      这个就引出我个人对于敏捷项目质量把控的第一点理解:质量先行。在前期做设计评审的时候,需要对设计的可扩展性进行关注。避免后期需求的变更带来的重构的风险。另外:第二点理解就是,在敏捷的项目中,单元测试显的especiaaly重要。在通过了单元测试的模块进行集成之后,这个时候就是我们系统组的应用团队关注接下来的集成测试,主要关注业务流程的正确性,数据的前后台一致性,模块的接口测试。对于数据流频繁,数量庞大的模块接口需要做性能测试的分析,是否需要做性能测试。再接下来,对于可以确定的稳定的功能模块,业务流程就可以进行手工用例向自动化用例的转化了。转换完成之后,如果后期发生了关联到次类业务流,模块的需求的变更,无论是新增还是更改,只要这一部分确定下来的业务流程业务需求没有变,那就可以自动化这一部分用例,当然是整体还是部分就要看当时的实际情况了。
     
      这个就是我当前对于敏捷项目的测试如何做的理解。至于管理方面,那么需要我们的测试管理人员对于业务需要有一定的了解,同时部门之间消息一定要联动,平常结合管理上的scrum方法,思想,加强监控,及时的做出调控。
  • 测试目标--质量特性的验证

    2010-11-16 14:35:00

    1. 正确性测试(correctness testing)或功能性测试是基于产品规格说明书、从用户角度针对产品特定的功能和特性所进行的验证活动,以确认每个功能是否得到完整的实现,用户能否正常使用这些功能。功能测试一般要在完成集成测试后时行,而且是针对应用系统、在实际运行环境下而进行的测试。
    2. 性能测试(performance testing)是测试在一定条件下系统行为表现,是否在设计的性能指标范围内。如测试网站在并发用户数为10、100、1000、10000等情况下, 页面的响应时间是否在3秒和5秒内,响应时间最长是否不超过15秒或30秒。性能测试不同于负载测试(stress/load testing),性能测试是在定义的各种条件下去衡量系统的有关性能指标,而负载测试只测试在一些极端条件下,系统还能否正常工作,或加载到系统崩溃而找出系统性能的瓶颈,所以两者要结合起来。
    3. 可 靠性测试(reliability testing)是评估软件在运行时的可靠性,即通过测试确认平均无故障时间(Mean Time To Failure,MTTF)或最初平均寿命,即故障发生前平均工作时间(Mean-Time-To -First-Failure,MTTFF)。可靠性测试强调随机输入,并通过模拟系统实现,很能通过实际系统的运行来实现。可靠性测试,一般伴随着强壮 性测试(robustness/strong testing).
    4. 安全性测试(safety or security testing)是测试系统在应付非授权的内部或外部访问、非法侵入或故意损坏时的系统防护能力,以检验系统有能力使可能存在来自于内部或外部的损害的风 险限制在可接受的水平内。软件可靠性要求,通常包括了安全性的要求。但是软件的可靠性不能完全取代软件的安全性,因为安全性还涉及数据加密、保密、存取权 限等方面的要求。
    5. 容错性测试(tloerance testing)是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时,能否在指定时间间隔内修正错误并重新启动。容错性测试看作由系统异常处理测试和恢复测试组成。
    6. 恢复测试(recovery testing)在系统崩溃、硬件故障、或者其他灾难发生之后,重新恢复系统和数据的能力测试,包括确定软件系统的平均修复时间(Mean Time to Repair,MTTR)。
    7. 兼容性测试(compatibility testing)测试在各种的硬件/软件/操作系统/网络环境下的软件表现,包括硬件接口、软件新旧版本兼容、已存在数据的兼容能力。
Open Toolbar