测试方法的辩证统一

软件测试的众多方法是辩证统一的，它们相互依赖而存在，相互对立又相互补充，任何一种测试方法都有其优点，在特定的测试领域能得到充分发挥。同时，任何一种测试方法都不能覆盖所有测试的需求，在某些场合存在一定的局限性和不足。这种测试的辩证统一，从下面这些相对应的测试方法就得到很好的印证。

l         白盒测试方法和黑盒测试方法

l         静态测试 (static test) 和 动态测试( Dynamic test)

l         手工测试（Manual test）和自动化测试(Automated Test)

l         有计划测试（Planned Test）和随机测试（Ad-hoc test 或Random test）

l         新功能测试（new feature test）和回归测试 (Regression testing)

 

1. 白盒测试方法和黑盒测试方法

黑盒测试方法，不考虑程序内部结构和内部特性，而是从用户观点出发，针对程序接口和用户界面进行测试，根据产品应该实现的实际功能和已经定义好的产品规格，来验证产品所应该具有的功能是否实现，是否满足用户的要求。

所以，黑盒测试方法技术相对要求低，方法简单有效，可以整体测试系统的行为，可以从头到尾（end-to-end）进行数据完整性测试。黑盒测试方法适合系统的功能测试、易用性测试，也适合和用户共同进行验收测试、软件确认测试。黑盒测试方法不适合单元测试、集成测试，而且测试结果的覆盖度不容易度量，其测试的潜在风险比较高。

由于白盒测试方法，已知产品的内部工作过程，针对性很强，可以对程序每一行语句、每一个条件或分支进行测试，测试效率比较高，而且可以清楚已测试的覆盖程度。如果时间足够多，可以保证所有的语句和条件得到测试，测试的覆盖程度达到很高。白盒测试方法所以适合单元测试、集成测试，而不适合系统测试。白盒测试方法准备的时间很长，如果要覆盖全部程序语句、分支的测试，一般花费比编程更长的时间。

白盒测试方法所要求的技术也较高，相应的测试成本要大。对于一个应用的系统，程序的路径数可能是一个天文数字，即使借助一些测试工具，白盒测试法也不可能进行穷举测试，企图遍历所有的路径往往是做不到的。即使，穷举路径测试，也不能查出程序违反了设计规范的地方，不能发现程序中已实现但不是用户所需要的功能，可能发现不了一些与数据相关的错误或用户操作行为的缺陷。所以白盒测试方法也存在一定的局限性。

 

2. 静态测试和动态测试

静态测试是通过对软件的程序源代码和各类文档或中间产品（产品规格说明书、技术设计文档），采用走查、同行评审、会审等方法来查找错误或收集所需要的度量数据，而不需要运行程序，所以相对动态测试，可以更早地进行。

静态分析的查错和分析功能是其他方法所不能替代的，静态分析能发现文档中问题（也只能通过静态测试实现），通过文档中问题或其他软件评审方法来发现需求分析、软件设计等问题，而且能有效地检查代码是否具有可读性、可维护性，是否遵守编程规范，包括代码风格、变量/对象/类的命名、注释行等。静态测试已被当做一种自动化的、主要的代码校验方法。

动态测试是通过观察程序运行时所表现出来的状态、行为等发现软件缺陷，包括在程序运行时，通过有效的测试用例（对应的输入 / 输出关系）来分析被测程序的运行情况、或进行跟踪对比，发现程序所表现的行为与设计规格或客户需求不一致的问题。

动态测试是一种经常运用的测试方法，无论在单元测试、集成测试中，还是在系统测试、验收测试中，都是一种有效的测试方法。但动态测试不能发现文档问题，必须等待程序代码完成后进行，发现问题相对迟得多，一旦发现问题，必须重新设计、重新编码，必然增大不良质量的成本。

 

3. 手工测试和自动化测试

        手工测试是指通过测试人员自身对系统进行操作来完成操作，而自动化测试是通过计算机运行测试工具和测试脚本自动进行。自动化测试具有很多优点，如执行速度高而缩短测试周期、可以多次重复运行相同的测试而减少测试的单调性、真实反映测试结果、二十四小时不知劳累运行等等，所以在测试工作中，我们尽力实现测试自动化、或扩大自动化测试的覆盖范围。但是自动化测试前期投入大，对被测对象要求高以及存在其它的局限性。
软件测试自动化绝不能代替手工测试，它们两者有相应的测试对象和范围：
1) 工具本身并没有想象力和灵活性，根据业界统计结果，自动测试只能发现15-30%的缺陷，而手工测试可以发现70-85%的缺陷；所以自动化测试有其局限性，不适合软件的新功能测试，而特别适合回归测试，可以保证对已经测试过部分进行测试的准确性和客观性。
2) 在系统功能的逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，也很难通过自动化测试来实现，多采用黑盒测试的手工测试方法；
3) 单元测试、集成测试、系统负载或性能测试、稳定性测试、可靠性测试等比较适合采用自动化测试；
4) 当界面、需求变化比较频繁时、开发周期很短的软件、或做一次性软件开发项目（而不是做软件产品）时，自动化测试吃力不讨好，投入大而产出小。
5) 有些测试工具只能运行在Windows平台上，不能运行在Mac/Unix等平台上。
多数情况下，手工测试和自动化测试相结合，以最有效的方法来完成测试任务。

 

 

4. 有计划测试和随机测试

在测试执行前，我们一般都进行测试的策划、计划，分析测试的重点和范围，精心设计测试用例，来做好测试执行前的准备，通过测试计划和测试用例进行的测试是有计划的测试，而不通过事先计划或不借助测试用例，完全凭感觉、猜测而进行自由、灵活的测试，被称作随机的测试或ad-hoc test。有计划的测试效率高、针对性强，可以很好地达到测试目标，但由于用户使用软件的情景很多、千变万化，测试用例很难覆盖各种情况，特别是一些边界和特殊的操作。根据经验和历史数据统计，对于大型系统软件测试用例的覆盖度一般在90%到95%之间。所以，必须借助一些自由的ad-hoc test，充分发挥测试人员最大的灵动性、创造性，进行各种猜测和试探，去发现一些相对隐藏比较深或偏僻的软件缺陷。ad-hoc test另外一个作用是帮助测试人员尽早地熟悉产品，改进测试用例。

 

5. 新功能测试和回归测试

即使在开发一个新软件（第一个版本），在进行系统测试还是功能测试时，总会发现一些严重的缺陷而需要修正，这时就要构造一个新的软件包(Full Build)或新的软件补丁包(Patch),然后进行测试。这时的测试不仅要验证被修复的软件缺陷是否真正被解决了，而且要保证以前所有运行正常的功能依旧保持正常，而没有受到这次修改的影响。对于检验原有正常功能没有出现回归的缺陷而进行的测试，称为回归测试。对于开发第二、三个版本或以后的版本，这种回归测试所占的比重越来越大。所以，一个完整的测试，可以看作新功能或新修改的测试，加上回归测试的组合。

在软件产品实现过程中，新功能的实现固然重要，可以增强产品的亮点和竞争力，增加市场份额，但是不能正常工作的已有功能所引起的客户抱怨可能更大，因为客户已经习惯地使用已有功能了，而对于新功能，客户还没怎么使用（没尝到甜头）或者客户可能不知道这个新功能，甚至我们可以在客户知道前去掉这个功能。所以，从这个意义上说，回归测试显得更为重要。

 

前面我们曾谈到测试执行中一种有效性策略，实际就是一个典型例子，显示了有效性和风险性之间的矛盾和统一。测试方法有效性和风险性的这种关系，实际表现在整个测试周期，存在整个开发周期。

1. 有效性和风险性, 首先体现在一种测试理念的较量上。虽然，当我们问一个测试工程师，测试是什么？她/他可能会毫不犹豫地说，测试是发现缺陷。当她/他管理一个测试项目或进行测试时，总是想证明所有功能是正常的，而大大降低测试的效率。至少，在心里进行不断的斗争，结果可能会去冒一些风险，可能会牺牲一些效率。

2. 在制定测试策略、测试计划时，有效性和风险性的矛盾可能更突出，即确定测试的质量标准、测试范围和测试重点。“如何减少测试范围、抓住测试重点”是具有技巧性和经验性，技巧和经验提高测试有效性，有时也往往引起一些容易忽视的风险。质量标准（产品特性的具体要求）也具有策略性，是市场(marketing requirements) 和工程 (Engineering ) 的一种斗争的结果，也极具平衡的艺术。

3. 设计测试用例时，我们也常常为测试用例的“颗粒度”而伤神。如果把测试用例设计得很细，照顾到每一个数据输入、每一个条件、每一个环境、每一个路径，那么测试用例的数量将是巨大的，虽然风险很小很小，但是测试效率会很低，并且测试执行没有思考的空间，可能使测试执行人员变得呆板（除非全部测试自动化），不需要创造力、思考。测试用例设计很粗，测试效率可能比较高，测试人员有一个发挥的空间，使测试更有趣，但这依赖于个人的责任感和能力，风险大得多。

4. 在执行时，这种关系也比较突出，前面谈得较多，请参考： http://blog.csdn.net/kerryzhu/archive/2006/06/14/796881.aspx

 

测试执行中非常有效的策略：

 

对于大型项目，软件测试的执行，除了需要很好的测试范围分析、测试计划制定和测试资源的分配与组织之外，还是有一个容易被大家忽视的策略问题。

对于大多数应用项目（非国防、载入飞船上天、净室工程等），我们都知道，测试不是为了证明所有的功能能正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的问题，也就是说，测试的一般工作就是发现缺陷 (detect bug)，当然这些缺陷包括需求分析、设计等的缺陷，不仅仅是程序中的运行。测试的启动和项目启动是同时发生的，测试的重要工作是在测试用例的设计，这是随后测试执行的基础。同时，我们应该承认，测试的主要工作是在测试的执行，当自动化测试工具在功能测试中发挥作用比较困难时，测试执行的工作量还是很大的。

如何更早地发现缺陷又不增加风险？测试的本质是什么，发现缺陷还是风险评估？如何引导大家向着一个目标——产品及时高质量发布努力？

1. 首先就要向测试人员灌输一个概念——“测试的一般工作就是发现缺陷 (detect bug)”，达成共识，这是很重要。这样，测试人员，就知道什么是自己真正的工作。这一点，不仅在测试执行时发挥作用，而且在设计测试用例时更能发挥作用。

2. 测试执行阶段可以划分为两个子阶段，前一个阶段的目的非常清楚，就是发现缺陷，督促大家就是找出缺陷。测试用例的执行，应该是帮助我们更快地发现缺陷，而不是成为“发现缺陷”的障碍——使发现缺陷的能力降低。从理论上说，如果缺陷都找出来了，质量也就有保证了。所以在这一阶段，要不顾风险，就是发现缺陷，这样不仅对开发团队也非常有利，能尽早地修正大部分缺陷；对测试有利，测试效率高，后面的回归测试也会稳定，信心更充分。

3. 在代码冻结或产品发布前的稍后的子阶段，目的是减少风险，增加测试的覆盖度，这时测试的效率会低一些，以损失部分测试效率以极大降低风险、获得更高质量的收益。

4. 在前一阶段，测试用例的执行速度要低一些，测试人员多思考，多做些ad-hoc 测试，这样又帮助提高测试用例的质量，从而对随后的回归测试提供了更有力的保障。

 5. 测试执行要进行有效监控，包括测试执行效率（缺陷数/KTC, KTC = 1000 test cases）、Bug历史情况和发展趋势等。根据获得的数据，必要时对测试范围、测试重点等进行调整，包括对测试人员的调整、互换模块等手段，提高测试覆盖度，降低风险

6. 测试总是是有风险的，正是始终存在的风险，使之测试更具有艺术性。