软件测试活动的组织与方法

软件测试活动的组织与方法

量是衡量一个软件是否成功的关键要素。而对于商业软件系统，除了软件的运行质量，文档质量以外，代码的质量也是非常重要的。本文试图论述软件测试活动的组织与方法。希望各位测试前辈提出宝贵意见。

1：在做需求分析，概要涉及，以及详细设计阶段，最好应该有测试组的优秀人员参与。这样在设计工作完成后，就可以着手测试的准备工作了，一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。

2：测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。

3：代码审查。软件开发进行到编码阶段的时候，最大的风险在于如何保证代码的易读性和一致性，从而使软件维护的代价不会很高。在软件开发的过程中，以下几种情形随处可见：1：软件维护时间长，而且维护人员的积极性不高。做过软件维护的开发人员，尤其是在接手不是自己开发产品的源码的时候，即使有良好的文档说明，仍然会对代码中冗长，没有注释的段落叹为观止。理解尚且如此困难，何况要修改或者增加新的功能。2：新的开发人员融入团队的时间比较长。这除了没有良好的培训，文档等有效机制以外，每个人一套的编码风格，也容易造成新成员对于已有代码的理解不够，甚至出现偏差。编码规范 做为解决以上问题的方案已经得到了很长时间的应用。而在产品或者项目实际开发的过程中，仅有

Code Conventions 是不能解决Code的问题的。他往往和Code Review配合，做为代码质量保证的手段。代码审查根据形式分为两种：一种是交叉代码审查（即自己的代码由他人来检查，就象检查作业一样）另一种是代码会审（即以会议的形式，大家共同审核代码的质量。Code Review 的目的有：在项目早期就能够发现代码中的Bug，帮助开发人员学习高级开发人员的经验，达到知识共享。避免开发人员犯一些很常见，很普通的错误。保证项目组的人员的良好沟通，项目或产品的代码更容易维护。 一般情况下，Code Review 的内容与层次如下：编码风格与代码规范一致性：检查代码是否符合编码规范，确保所有人写的代码基本一致。代码满足基本功能要求：检查代码的逻辑实现，以及单元测试的编写策略，确认实现功能性需求。代码满足性能等非功能性需求：非功能型需求一般不便于测试，需要借助一定的工具和Review人员的素质，针对编码中对于性能影响的瓶颈给出解决方案。去处冗余，提高代码可读性：适当使用Refactorying技术，去除代码中的Bad Smell；如果有需要，可以Refatorying to Pattern。

4：单元测试。单元测试集中在检查软件设计的最小单位-模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。

5：集成测试：集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。

6：系统测试：经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接下来就是对系统整体的测试了。

7：验收测试：验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。

3．测试方法分析

集成测试及其后的测试阶段，一般采用黑盒方法。

(1)用边值分析法和（或）等价分类法提出基本的测试用例；

(2)用猜测法补充新的测试用例；

(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上（1）、（2）两步进行。

单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：

a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。

b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。

三、测试人员组织

人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。为高质高效地完成测试任务，好的测试工程师应具有如下能力：

1、沟通能力

一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

2、技术能力

就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员

作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

3、自信心

开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

4、外交能力

当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于\"赢了战争却输了战役\"。

5、幽默感

在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

6、很强的记忆力

一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这

一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

7、怀疑精神

可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

8、自我督促

干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

9、洞察力

一个好的测试工程师具有\"测试是为了破坏\"的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

总之，测试是软件生存周期中的一个关键的阶段，也是保证软件质量的重要活动之一。无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分，面对软件开发规模的增大、复杂程度的增加，更应高度重视软件测试工作的组织与管理，以提到软件质量。