测试与质量的关系 测试有助于提高软件的质量,但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。 学习好的学生,在考试时通过认真检查能减少因疏忽而造成的答题错误,从而“提高”了考试成绩(取得他本来就该得的好成绩)。 而学习差的学生,他原本就不会做题目,无论检查多么细心,也不能提高成绩。 所以说,软件的高质量是设计出来的,而不是靠测试修补出来的。 I love U software testing

测试需要考虑什么呢。。。。。ing

上一篇 / 下一篇  2007-10-18 18:15:25

黑盒测试:不基于内部设计和代码的任何知识,而是基于需求和功能性。
  

白盒测试:基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。

  单元测试:最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好,除非应用系统有一个设计很好的体系结构;还可能需要开发测试驱动器模块或测试套具。

  累积综合测试:当一个新功能增加后,对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作,或当需要时那些测试驱动器已被开发出来;这种测试可由程序员或测试员来做。

  集成测试:一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。

  功能测试:用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)

  系统测试:基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件。

  端到端测试:类似于系统测试;测试级的宏大的端点;涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。

  健全测试:典型地是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够健全,目前不具备进一步测试的条件。

  衰竭测试:软件或环境的修复或更正后的再测试。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

  接受测试:基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。

  负载测试:测试一个应用在重负荷下的表现,例如测试一个Web站点在大量的负荷下,何时系统的响应会退化或失败。

  强迫测试:在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。

  性能测试:在交替进行负荷和强迫测试时常用的术语。理想的性能测试”(其他类型的测试)应在需求文档或质量保证、测试计划中定义。

  可用性测试:对用户友好性的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

  安装/卸载测试:对软件的全部、部分或升级安装/卸载处理过程的测试。

  恢复测试:测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。

  安全测试:测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术

  兼容测试:测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。

  比较测试:与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。

  Alpha测试:在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。

  Beta测试:当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。


TAG:

 

评分:0

我来说两句

日历

« 2024-03-28  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 94184
  • 日志数: 112
  • 图片数: 1
  • 文件数: 1
  • 书签数: 1
  • 建立时间: 2007-01-16
  • 更新时间: 2010-06-28

RSS订阅

Open Toolbar