在巨人的肩膀上对软件测试的思考（二）

（接上文。。。）

3 打造“完美”测试

3.1 自动化测试与众测是完美测试吗

        萨尔瓦多·达利曾说：“不用担心完美——你永远无法达到的。”自动化测试的出现令很多早已厌恶测试的人欣喜若狂，产生了下列完美的设想：

1. 所有的测试都能够实现自动化
2. 既然自动化测试能如此显著地提高生产率，我们就能以更少的人员完成所有的测试
3. 自动化测试如此简单，我们无需任何培训
4. 自动化方法将缩减整体测试工作量
5. 我们无需制订任何测试方案
6. 有了自动化测试，测试人员不就成了"过时的"或"多余的"了吗
7. 那种耗时的测试设计工作不再必要了

        然而，自动化测试是完美测试么？答案是否定的。自动化测试，或者说自动化测试策略及工具的实现，只是测试人员工具箱里的一件利器。它有几个特点：1 它不是被用来发现bug的，它是用来提高执行效率、彻底性的：注意它是基于testcase的，所有的bug只有约1/4是通过testcase发现的，其他的bug都来源于人的智慧；2 它本身也是程序，也许要投入大量精力实现，可能也会存在缺陷；3 自动化测试程序面对的客户是专业人士，故拓展性、灵活性，可配置性以及友好的交互性相比其他商业软件不是特别好。

        下列情况不适合自动化测试：

        1、定制型项目（一次性的）

        为客户定制的项目，维护期由客户方承担的，甚至采用的开发语言、运行环境也是客户特别要求的，即公司在这方面的测试积累就少，这样的项目不适合作自动化化测试。

        2、项目周期很短的项目

        项目周期很短，测试周期很短，就不值得花精力去投资自动化测试，好不容易建立起的测试脚本，不能得到重复的利用是不现实的。

        3、业务规则复杂的对象

        业务规则复杂的对象，有很多的逻辑关系、运算关系，工具就很难测试。

        4、美观、声音、易用性测试

        人的感观方面的：界面的美观、声音的体验、易用性的测试，也只有人来测试

        5、测试很少运行：一个月只运行一次

        测试很少运行，对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反复复的运行才有效率。

        6、软件不稳定

        软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳定，没有界面性严重错误和中断错误才能开始自动化测试。

        7、涉及物理交互

        工具很难完成与物理设备的交互，比如刷卡的测试等。

        对于众测，我觉得类似于很多人进行黑盒测试，利用了人群优势。相比开源，它并不开放源代码，能够明确问题的概率会小的多，即使发现了也不一定能解决或者解决的代价也很大。不过对比自动化测试，它可以更有效的可以去测试界面、声音和易用性的情况，收集用户的反馈。

3.2 如何追求“完美”测试

        朱少明定义了一种“完美”测试：通过最有效的手段（包括方法、技术和工具）完成所有必要的测试，达到事先所要求的功能需求和非功能需求的测试覆盖率、代码的测试覆盖率，最终能够准确的给出软件产品一个完整的质量评估。

        1. 最有效的手段：以最短的时间或最少的资源来有效地完成给定的测试任务，具体问题具体分析。

        2. 必要的测试：没有执行多余的测试任务，也没有漏掉该执行的测试任务。

        3. 测试覆盖率：没有覆盖率的衡量，就不能确定测试的效果以及完成情况；没有覆盖率的衡量，就很难知道测试什么时候可以结束，难以对测试工作进行评估，甚至难以控制测试的进度。

        4. 准确又完整的质量评估：在完成必要的软件测试之后，并有能力发现测试范围中的

        软件缺陷，然后根据所发现的缺陷，以及前面所参加的需求评审、设计评审和代码评审的结果，针对待发布软件的各种质量特性做出准确的评估，从而能够全面准备的了解产品的质量，为是否能够发布做出判断，对持续改进软件质量也能提出明确的举措。

        具体针对各种情况和测试技术，在《完美测试》中都给出了经验之谈。

4 写在最后

        经常看到开发人员与测试人员的敌对局势，或者测试人员对测试的仇大苦深，这些隔阂很大一部分来自于潜意识对“银弹”的向往，对测试的误解以及利益选择。

        首先，我们应当摆正对测试的态度。测试不能发现所有的错误，不可能对所有可能进行测试，从统计的概念说，测试只是个信息收集的过程，而且是用了采样。

        其次，正确的定义可以防止或结束争论。测试人员认为他们的工作是测试（发现问题）而开发人员认为测试人员的工作是为开发提供支持——对开发人员而言意味着测试和查明缺陷（甚至定位缺陷以及确定重要性）。我们需要对问题查明到何种程度达成一致的定义。

        最后，测试技术，如自动化测试等只是工具，我们需要知道什么时候什么产品需要什么样的测试。一般来说，测试并不是一个特定的阶段，而是贯穿在整个过程中，并且尽早开始最好；其次我们要考虑以下因素来分析一个产品需要什么样的测试：

1. 用户质量和开发质量
2. 产品对缺陷的容忍度以及修复代价
3. 有效地测试方式
4. 产品所处的阶段以及团队的状况

        有效地借鉴他人的经验能够很好的帮助我们更加深入的了解这个过程以及获得一些指导，所谓站在巨人的肩膀上。当然，“纸上得来终觉浅”，将测试与自己实际联系起来，因地制宜才是最重要的。

参考文献：
1. 《完美软件：对软件测试的若干幻想》
2. 《完美测试：软件测试系列最佳实践》
3. 《软件测试(原书中文第二版)》
4. 《软件测试的艺术》
5. 《软件测试方法平衡之美》
6. 《软件工程的事实与谬论》
7. 自动化测试：真的是银弹？：http://www.51testing.com/html/60/n-20960.html
8. 不适合自动化测试的情况：http://www.cnblogs.com/zzp28/articles/1580244.html
9. 自动化测试不是灵丹妙药：http://www.newhua.com/2010/0112/83486.shtml
10. 腾讯众测：http://baike.baidu.com/