关于测试类型

关于测试类型

            jackei by 2003-11-10

  现在网上还是有很多同行对于测试类型、测试方法、测试阶段区分不开，其实这几个概念还是比较容易区分的。它们之间是存在一些关系的，比如测试阶段的定义应该是最大了，比如有组件测试、集成测试、系统测试，这是最常见的不同阶段测试的区别方法。而测试方法主要就是传统的四个：静态黑盒，动态黑盒，静态白盒，动态白盒。而测试类型就很丰富了：功能测试、性能测试、完整性测试、结构测试、配置测试、安装测试、安全测试、容量测试、基准测试、竞争测试、负载测试、强度测试、UI测试、数据相关性和完整性测试、数据库测试、易用性测试、文档测试等等。
  不过这三个概念是相互之间存在联系的，比如对于组件测试阶段和集成测试阶段可以使用黑盒方法，也可以使用白盒方法；而在系统测试阶段，则主要是使用黑盒测试方法。注意，这里的黑/白盒的区分是是否涉及到代码的测试，而不是象一些书上说得是否了解系统的内部实现。
  通常可以这样做，首先，明确自己当前所处的测试阶段，是组件测试阶段，还是集成测试阶段或者系统测试阶段，然后确定自己会进行那些方面的测试——也就是确定测试类型；最后，针对不同的测试类型确定是否那些测试技术和测试方法。哦，这里又增加了一个名词叫“测试技术”，都包括那些技术呢？这个我还没有好好考虑过。总之可以明确这样的顺序：测试阶段——测试类型——测试方法和技术。
  嗯，在当前项目的实际工作中，虽然开发部准备在接下来的工作中使用新的三层架构，但是限于当前我的技术能力和项目的实际情况，我还是准备只将工作限制于系统测试阶段，而组件测试和集成测试还不准北涉足。而对于系统测试中众多的测试类型，经过总结和归纳，将只包括4个测试类型，分别定义如下：
  1.功能测试。这里的功能测试将只包括同实际业务相关的测试，也就是用户在不使用计算机软件时也同样要进行的工作。对于功能测试用例的设计，可以在需求验证阶段后就立即开始，基本上同开发部的程序设计同步开始。也正因为这样，这个阶段完成的功能测试用例是不会同实现有任何关联的，完全是只对实际业务——也就是用户在完成自己工作时需要的东西来考虑。而当程序设计和用例设计阶段结束时，还要进行测试用例和程序设计的验证，包括对程序设计的正确性验证，以及对测试用例的调整——增加、删除、修改。到此为止，所有完成的功能测试用例仍然不会同实现产生任何关联，而且这时功能测试用例也应该基本上完成了。用例的描述将只包括具体的业务操作，需要验证的结果，而不会描述通过使用那些功能和方法来实现——比如选择菜单中的那个项目，点击那个按钮，在那个edit中输入内容。
  另外，对于功能测试，将分不同的子系统进行考虑，每个子系统都会建立一个单独的目录来保存。同时，在以上的测试中，还要包括本子系统的数据准确性测试、可用性测试，但是因为这两个方面属于基本的功能要求，所以不作为单独的部分处理。
  最终一个基本原则：功能测试将以需求为唯一的标准，一切都从需求中来，也使用需求为标准验证其他阶段的工作。
  2.UI测试。对于UI测试，一直是最容易同功能测试相混淆的部分，在这里通过对功能测试的明确定义来帮助UI测试的定义。
  在我的计划中，UI测试将只包括同最终实现有关的内容，同UI本身相关的东西。比如快捷键，提示信息，文字内容的显示，可输入控件的输入长度限制、数据类型限制，等等。总之，包括的是在需求文档中没有描述，而是做为实现考虑的内容，是同用户的实际业务本来没有实际联系，而计算机强加的部分。
  3.性能测试。考虑以普通的性能测试为主。
  4.数据相关性和完整性测试。这里主要是同功能测试有关系，功能测试对于数据的保证是当前子系统业务相关的数据的准确性和完整性的测试，而这里是考虑那些在一个子系统中操作，但是可以对其他子系统所使用的数据产生影响的，但是当前子系统用户并不关心这些影响的情况——当然，另一个子系统的用户必然会关心。

  以上内容非常不完善，还需要继续思考完善。