- 热门文章:
- · 微软高级开发者管理峰会演讲摘要:产品质量的…
- · CMM与软件评价及测试
- · 游戏项目中的自动化测试和持续集成
- · 对项目开发中几种测试类型的理解
- · 初学者入门:软件测试从零开始
- · Web 测试的经验
- · TPC-C性能测试指标介绍
- · RUP测试过程实践
- · 无忧测试网每日一贴精华版
- · 软件测试人员结构组成分析
- · 谈谈关于测试覆盖
- · 在Eclipse中使用JUnit(翻译)
测试的经验之谈
1、测试概念的范畴
广义上讲,测试是指软件产品生存周期内所有的检查、评审和确认活动。如:设计评审、系统测试。
狭义上讲,测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题,同时对产品质量进行客观的评价。
2、测试的目的
简单地说,就是替用户受过,测试的最终目的是确保最终交给用户的产品的功能符合用户的需求,把尽可能多的问题在产品交给用户之前发现并改正。在可接受的开销下,提高对软件的信心。
具体地讲,测试一般要达到下列目标:
1) 确保产品完成了它所承诺或公布的功能,并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。最后,书面文档的不健全甚至不正确,也是测试工作中遇到的最大和最头痛的问题,它的直接后果是测试效率低下、测试目标不明确、测试范围不充分,从而导致最终测试的作用不能充分发挥、测试效果不理想。
2) 确保产品满足性能和效率的要求
使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。用户最关心的不是你的技术有多先进、功能有多强大,而是他能从这些技术、这些功能中得到多少好处。也就是说,用户关心的是他能从中取出多少,而不是你已经放进去多少。
3) 确保产品是健壮的和适应用户环境的
健壮性即稳定性,是产品质量的基本要求,尤其对于一个用于事务关键或时间关键的工作环境中。另外就是不能假设用户的环境(某些项目可能除外)。
3、 测试的原则---GoodEnough
对于相对复杂的产品或系统来说,zero-bug是一种理想,good-enough是我们的原则。
Good-enough原则就是一种权衡投入 / 产出比的原则:不充分的测试是不负责任的;过分的测试是一种资源的浪费,同样也是一种不负责任的表现。我们的操作困难在于:如何界定什么样的测试是不充分的,什么样的测试是过分的。目前状况唯一可用的答案是:制定最低测试通过标准和测试内容,然后具体问题具体分析。
4、 测试的规律----木桶原理和80-20原则
1) 木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现,测试应该是融于其中的补充检查手段,其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说,测试是提高产品质量的必要条件,也是提高产品质量最直接、最快捷的手段,但决不是一种根本手段。反过来说,如果将提高产品质量的砝码全部押在测试上,那将是一个恐怖而漫长的灾难。
2) Bug的80-20原则。
一般情况下,在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug,而系统测试又能找出其余Bug中的80%,最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误,无法保证能够发现所有的错误。
5、传统测试流程遇到的挑战和对策----问题发现得越早,解决的代价就越小
对于测试理论,主要依据软件生命周期V字模型
可见软件测试贯穿了软件开发周期的大半,其各级测试的依据是对应开发阶段的各种详细文档。测试目前主要依赖于:测试人员的经验和素质;产品说明文档和项目组的技术咨询;测试工具的使用;测试计划的设计。
6、测试分类
按功能分:
–白盒测试(Whitetest)
–黑盒测试(BlackTest)
按测试时间来分:
–单元测试(UnitTest)
–集成测试(IntegrateTest)
–确认测试(ValidationTest)
–系统测试(SystemTest)
按运行状态来分:
–静态测试(StaticTest)
–动态测试(DynamicTest)
按方向来分:
–正向测试
–逆向测试
7、测试策略:
测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试(单元测试、集成测试、系统测试)以及每个阶段内在进行的测试种类(功能测试、性能测试、覆盖测试等)。
测试策略包括:
1、要使用的测试技术和工具;
2、测试完成标准;
3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元,按照需求编写测试计划。
把软件分解成单元有几个好处:
1、软件需求是测试设计和开发测试用例的基础,分成单元可以更好地进行设计;
2、详细的测试需求是用来衡量测试覆盖率的重要指标;
3、测试的需求包括各种测试实际的开发以及所需资源。
测试计划的输入为被测软件、基于需求的测试设计;输出为测试过程和测试用例通过设计测试计划创建可以重用的测试过程和测试用例,同时维护测试过程、测试用例与相关测试需求的一一对应。
- · 使用因果图设计测试用例
- · 嵌入式软件的基本测试方法
- · 如何成为一名优秀的软件测试工程师
- · 软件测试常用术语表
- · 软件测试知识帖(99-108)
- · 软件测试知识帖(57-70)
- · 软件测试知识帖(71-84)
- · 如何写毕业论文
- · 计算机专业毕业设计的类型
- · 实现一个系统设计生命周期
- · 文档编制的质量要求
- · 程序文档合一与动态文档
- · 无形团队,有形管理
- · Microsoft Visio在信息管理…
- · Delphi源程序格式书写规范
- · C语言的代码规范探讨
- · 软件开发文档模板(1)
- · IEEE指南:开发系统需求规格
- · 国家计算机标准和文件模板(…
- · 国家计算机标准和文件模板(…
- · 典型系统分析
- · 项目方案实例 - ProSun2000项目方案
- · 使用UML为EAI建模
- · 系统约定:用UML描述工作流管理
- · UML 在商业活动建模中的应用
- · XMI 与 UML 合力推动产品开发
- · 使用 XML:UML、XMI 和代码生成,第 1 部分
- · 两段式OOAD开发大型3- tier系统
- · 如何绘制和分析业务流程(讲义)
- · 动态企业建模体系
- · 管理软件的“银弹”
- · 用UML进行有效业务建模(编译…
- · 使用用例捕获业务需求(业务需求的7个实践原则)
- · 需求分析
- · 用例场景,软件需求的关键
- · C#语言概述
- · Internet技术知识讲座----电子邮件E-mail
- · Internet技术知识讲座----HTTP协议
