测试这东西（二）
整个测试过程会分为单元测试、集成测试、系统测试三个关键的阶段。在特定的环境中，还会有验收测试阶段。每一个阶段测试的依据不同、重点不同、角度不同，使用的测试方法也不同。1.单元测试。
是在软件过程中最小单位的测试，它根据模块设计文档，来验证代码编写的正确性，以及是否实现了预定的标准。在这个阶段，它测试的是软件的代码，覆盖的是程序的逻辑路径，主要使用的测试方法是白盒测试。主要执行的人员是程序员。
单元测试的负责人会制定单元测试计划，得到项目组的认同之后，由相应的单元测试设计人员编写测试用例及测试代码（之后均称为测试脚本），由执行人员来运行测试。此时的测试用例重在说明使用怎样的思路，需要怎样的测试脚本，来测试什么，得出的结果应该是什么。当然，还会使用部分黑盒测试方法，在测试用例中直接说明要使用怎样的测试步骤，来验证哪些内容。当用例完成时，并且通过项目组的评审后，开始根据用例的要求编写测试脚本。程序员完成某一部分的编码后，可以调用相应的测试用例（测试代码脚本）来执行，得到的结果与预期不一致，便会提交缺陷。
在这个阶段中，为什么会说设计测试用例的人绝对不可以是负责该部分编码实现的人呢？凡是做过编码或文档的人都会深有体会：自己的东西很难扩展测试的思路。这也就是通常为什么自己写的文档明明感觉很清晰，别人却无法看懂的原因。因此需要一个旁观者来帮你设计测试，目的无非是想找出更多的缺陷。而执行单元测试的人员可以是其他程序员，也可以是负责本单元编码的程序员。此时，测试思路已定，执行时旨在发现缺陷，以及采纳他人测试思路的过程。
在单元测试阶段，需要引起重视的两点是：
一、由于测试用例、测试脚本具有紧密的关联性，在测试用例的描述中应要注意，测试步骤与测试脚本的结合必须是顺畅清晰的。而前面所说得"测试用例要重在说明使用怎样的思路，需要怎样的测试脚本，来测试什么"，实际上也可以写在单元测试计划当中，测试用例可重在说明使用怎样的步骤，来运行测试脚本，期望的结果是什么。内容写在何处并不是关键，关键是你要懂得在一个团队中如何去控制这样的过程。但是，无可厚非的，单元测试计划中一定会提及到相关测试用例要怎样设计、测试脚本需要怎样的功能，这就是你的测试策略。至于是否是在计划中简单描述，详细部分放在用例设计中实现，还是直接在测试计划中详细描述，测试用例只需规定执行过程，就要看自己的文档方式了。基本上，我还是比较推崇后者的，因为这样可以节省成本，让评审计划的项目组成员在第一时间就能够发现问题，使问题得到及时解决。
二、单元测试的执行者有可能是相应单元的程序员，而程序员的天性就是发现缺陷就立刻修改，不会去记录这个缺陷。当他执行完单元测试后，所有发现的缺陷也都得到了修复。看上去是件好事，可是其他人员根本就不了解在测试的过程中发现了多少缺陷？缺陷分布的情况如何？出现这种缺陷的原因是什么？缺陷修复的工作量有多大？因此，单元测试的执行过程又变得不可控了。所以，一方面要加强执行的控制，另一方面更要意识到，在资源允许的情况下，最好还是交叉测试。
需要让所有程序员了解的一件事，就是代码的调试与单元测试是两个完全不同的概念。你不能够认为你的代码通过了编译，就具备单元测试的资格，就可以进行单元测试。你必须在单元测试之前，自己尽可能的测试自己的代码，使其更为完善，此时，我们称之为代码的调试过程，发现与修改的缺陷并不在单元测试中的缺陷管理范围内。单元测试活动一旦开始，就意味着你的代码质量评价开始了，你的代码中出现的缺陷会全部记录下来，并由单元测试的负责人跟踪你对这些缺陷的修复状况。
2. 集成测试。
它根据概要设计文档，来验证单元之间的接口是否符合标准。很明显，它测试的是接口，覆盖的也是单元之间的接口，主要使用的测试方法是白盒与黑盒测试，通常由测试人员与程序员合作完成。
所谓接口，可大可小，要看你如何定义。小到两个函数、两个类的接口，大到整个软件与用户的输入接口、与数据库的接口等。B/S结构的软件还需要测试Webserver、WebService、数据库之间的接口。所谓集成测试，是指将不同的单位合在一起，测试合为一体之后能否达到预期的功能。
集成测试的管理过程跟单元测试是相同的，在此不做赘述。通常状况下，测试人员负责的集成测试，是对模块级别的接口测试，即模块与模块之间的接口。而程序员所负责的就是模块级别以下的单元之间的接口测试。至于单元有多大，如何划分，划分得粗细程度，是要取决于实际状况的。比如，程序员甲负责编写了A、B单元，为了降低测试成本，他完全可以在单元测试中拟定对A与B单元的接口测试，将其视为单元测试来处理，测试通过后，将其当作一个整体单元P，再与程序员乙的整体单元Q进行集成，此时集成测试就是针对了P与Q的接口来做的。那么，很明显，与数据库的集成测试也是要做的，关键看你把它定义在单元测试阶段来完成，还是在集成测试阶段完成，抑或是两个阶段都包含。
3. 系统测试。
该测试是软件过程中最为重要的测试。因此，在软件工程中，会把系统测试作为一个独立的阶段划分出来。它依据软件需求规格说明书，来验证集成后的完整的软件产物是否符合规定的标准，覆盖的是软件需求，不必顾及程序的内部逻辑结构，主要使用的测试方法是黑盒测试，由独立于编码团队的专业测试人员来完成。
系统测试的管理过程跟单元、集成测试并没有太大差别。使用到的测试类型却很多，如：功能测试、压力测试、负载测试、安全测试、界面测试、安装/卸载测试、文档测试(重点在安装手册、用户手册、在线帮助等提供给客户的帮助文档)、可靠性测试、兼容性测试等等。
每一种测试类型不同，测试的目的也不相同。但最基本也最必需的就是功能测试，它着重于对软件要实现的功能进行验证，发现软件运行时出现的缺陷并追踪缺陷的修复状况。
压力测试侧重于使用不同级别的环境压力，看软件运行的状况如何，负载测试是在软件预定的所能承受的最大压力状况下，能够持续运行的状况。两者同属于性能测试，都需要特定的性能测试工具来辅助完成，因为你不会有足够的人力、物力、时间资源来执行，只能依靠工具得到一些大致的数据以供参考。就好像联想的台式机，据说可持续运行的无故障时间为10万个小时，假设真测试10万个小时，估计联想公司早就不存在了。
如果从广义的角度来讲，可靠性、安全性、兼容性等测试也属于性能测试。但通常我们会把他们区分开来，只将性能测试定义为狭义的概念。安全性测试的典型例子就是身份验证、权限控制的测试，可靠性是指在发生了异常状况下系统的自我修复能力、可持续的无故障能力等，兼容性测试是在不同的环境中，测试程序是否能正常运行。比如该程序可共用于不同的平台、不同的操作系统、不同的硬件环境等，那么测试的目的就是要检查他们在这些环境中运行是否会有问题。
关于各种系统测试的类型定义与验证的侧重点，在网上随处可见，就不需要详细描述了。
4. 验收测试。
如果用户提出需要这样的测试并在合同中明确规定，就要在系统测试通过之后进行验收测试。它覆盖的是用户需求，测试方法仍然使用的是黑盒测试，通常是依据与客户签订的客户需求说明书，并在合同中明确规定了必须完成的软件内容，由客户来进行测试。不过也有客户委托软件开发商来替他完成的情况。通常也会由测试人员，或者市场人员，或项目经理来完成。
在没有客户提出验收测试需求的情况下，软件开发商为了确保软件符合市场需要。会在一些特定的用户群中发布一个Beta版，由这些用户进行试用，对软件提出缺陷并做出评价。这个过程被称为Beta测试，通常会由测试部门来组织。
无论是验收测试还是Beta测试，收集得到的缺陷一样要纳入缺陷管理过程中，进行缺陷修复。从这些测试数据中，可以分析出软件的质量偏差有多大，漏测率有多高等，作为软件质量或过程改进的部分依据。
需要指出的是，不同测试阶段的任务承担者并不绝对是上述特定的人员，每个企业的环境不同，决策出的测试承担者也不同。但从总体上看，不过是个角色转化问题而已，只要明确测试所要达到的目标并保证整个过程可控就好，执行人是谁并不重要，重要的是做这件事情的人是否有能力完成。
:)
[ Last edited by yayachen1109 on 2005-6-15 at 17:08 ]
页:
[1]
