应用软件开发完毕后，对于软件的测试非常的关键。软件测试人员的身价也一涨再涨，甚至有盖过程序开发人员的趋势。从中也可以看出程序测试人员的重要性。特别是在团队开发项目中，选择什么样的测试类型、如何相互协调等等，显得尤其的重要。笔者这里就以一个团队项目为例，谈谈如何选择合适的测试类型。
一、普通测试。
普通测试是指现有的程序或者来自另一个源的测试。经过一定的包装之后，在Visual Studio中作为测试运行。通常情况下，如果采用普通测试的话，有一个前提条件，即需要有比较完善的基础架构。其测试效果的好坏，则主要去取决于在框架外部创建的自动化测试工具。在使用一般测试的时候，可以包装现有的测试程序或者第三方工具。在进行测试时，可以根据不同的测试需要选择返回不同的结果。如有些情况下，只需要测试是否通过，那么就可以让其只返回“通过”或者“失败”的结果即可，而不需要返回具体的原因。而有时候可能还需要具体的结果。如现在可能需要测试某个功能优化的效果，那么就需要返回内部测试的详细结果。
普通测试最常用的一个地方就是通过普通测试来收集代码覆盖率数据。如通过如下步骤就可以收集到代码覆盖率的相关数据。
第一步创建或者打开包含普通测试的测试项目。在解决方案资源管理器中，打开“解决方案项”文件夹。然后在这个文件夹中找到一个叫做testrunconfig的文件，并双击打开。第二步在打开的对话框中，可以看到“代码覆盖率”的按钮。单击这个按钮，在“选择要检测的项目”对话框中，选择要为其手机代码覆盖率数据的成品代码二进制文件。单击应用进行测试即可。在这个过程中需要注意一个问题。有时候在“选择要检测的项目”对话框中可能会找不到需要测试的二进制代码文件。这主要是需要检测的二进制文件没有与添加程序集关联的原因。此时需要先点击“添加程序集”，然后再在“选择需要测试的程序集”对话框中，制定需要测试的二进制文件。通常情况下第一次测试是需要这么操作。第二次测试时可以直接打开。另外如果测试的是成品代码，那么需要注意包含成品代码的二进制文件可能不是一般测试中所包含的文件。遇到这种情况的话，测试人员需要指定普通测试将中间应用程序作为测试来包装。也就是说利用中间应用程序来运行需要测试的成品代码。这往往能够取得比较好的测试效果。
二、单元测试。
单元测试与普通测试有本主的区别。单元测试是编程测试中的一种重要方法。其主要通过调用带参数类的方法，来验证返回值是否是用户所期望的值。简单的说，就是测试人员输入几个参数，然后看应用程序得到的结果，是否与我们所期望的值类似。显然，对于单元测试来说，要取得比较好的效果，不在于测试的数量，而在于提供的参数是否包含了实际应用中涵盖的范围。简单的说，如果现在要测试一个单元格金额合计的程序，那么就需要提供金额为零、为负、为空(如果对输入的金额没有限制的话)等值，以取得在包含这些数据时会返回什么样的运算结果。
在Studio平台中，程序测试人员可以选择采用平台自带的单元测试模板进行测试，也可以自己手工编写代码进行测试。在这个平台中，提供了两种专用的单元测试变体，分别为数据驱动型单元测试和ASP.NET单元测试。前者主要是针对数据源的每一行反复调用时采用的。此时单元测试使用每一行的数据作为输入数据。后者主要用来测试Web应用程序的代码或者IIS进程中所运行的代码。
如果以上这两个测试模板不能够满足要求的话，则就需要手工添加新的单元测试代码。手工添加测试代码时，也有两种方法。一是直接添加，即使用单元测试在测试项目中添加一个源文件，该文件中包含一个有效的空白单元测试方法，然后再手工编写这个方法的代码。二是通过向导来完成。可以选择“使用测试向导”显示创建单元测试对话框。测试人员可以使用这个对话框利用当前项目中的方法来生成单元测试。不过虽然使用向导来创建单元测试，可以节省代码编写的时间。但是生成单元测试之后，仍然需要检查并在必要的时候进行手工的调整。
三、负载测试。
顾名思义，负载测试主要就是用来测试用户并发访问时应用程序的性能。负载测试的原理比较简单，就是将单元测试、普通测试等方法进行封装，然后使用虚拟用户同时运行应用程序，以判断在多用户的环境中应用程序的运行状态。在负载测试下运行这些测试将生成比较多的测试结果，包括以表格或者图标形式显示的性能计数器等相关的计数器。现在大部分应用程序都是服务器/客户机模式，用户数量比较多，负载测试是一种必不可少的测试方法。
如现在需要使用Studio开发一个Web应用程序。其有可能有成千上万个用户。一个用户使用的时候，性能等方面可能没有问题。但是如果许多用户同时访问这个应用程序，是否会有性能上的障碍呢?在测试的时候，同时叫上千个人对应用程序进行同时访问，也不怎么现实。在实际工作中，通常是通过负载测试来完成。如可以将Web测试添加到负载测试项目中，然后可以模拟数千个用户与某个特定的Web应用程序同时进行交互访问。负载测试可以帮助程序开发人员判断在应用程序的访问达到最大量的时候，是否否出现错误或者性能上的瓶颈。而不是等到真的出现这种情况时再去弥补。
用户选择负载测试的时候，需要注意如下问题。
一是要从少到多进行测试。有时候用户可能需要测试应用软件的最大访问量是多少，此时最好从少到多进行测试。这主要是因为如果页面因数据库或者CPU瓶颈而导致响应时间比较长的话，则会限制每个虚拟用户每秒发出的请求数，从而影响到最后测试的结果。比较合理的做法是，先从少量的负载开始，并确保缓慢增加负载时能够保持合理的响应时间。如可以通过响应时间目标属性为每个请求设置期望的最长响应时间。工具加上合理的经验，才能够得到比较准确的结果。
二是在负载测试时，最好进行直接测试，而不要在测试端与被测试端之间加入代理服务器。虽然在Studio提供的负载测式方法中，可以启用自动代理服务器检测工具。但是，如果启用这个工具的话，可能会带来一些误诊。因为代理服务器性能不同，会直接影响到检测的结果。为了保持客观公正的效果，最好不要使用代理服务器。毕竟代理服务器会在负载测式中降低性能，较少吞吐量。绝大部分情况下，在使用代理服务器之后，应用程序的性能都会有所下降。
从以上的分析中可以看出，在Studio平台中提供了比较丰富的测试方法。但是不同的测试方法其侧重点有所不同，都有各自的应用领域。作为程序测试人员，比较重要的一点就是如何根据企业的实际情况，选择合适的测试方法，并在各个项目成员之间取得一致。
文章来源于领测软件测试网 https://www.ltesting.net/
