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

1、软件测试活动的组织 与方法 量是衡量一个 软件是否成功的 关键要素。而对于商业软件系统，除了软件的运行质量，文档质量以外，代 码 的质量也是非常重要的。本文 试图论述软件测试活动的组织与方法。希望各位 测试前辈提出宝 贵意见。1：在做需求分析，概要 涉及，以及 详细设计阶 段，最好 应该有测试组的优秀人 员参与。这样在设计工作完成 后，就可以着手 测试的准备工作了，一般来 讲，由一位 对整个系统设计 熟悉的设计人员编写测试大纲，明确 测试的内容和 测试通过的准则，设计完整合理的 测试用例，以便系 统实现后进行全面 测试。2：测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计

2、过程中形成的 测试大纲、 测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好 测试前的准备工作。3：代码审查。软件开发进行到编码阶段的时候，最大的 风险在于如何保证代码的易读性和一致性，从而使 软 件维护的代价不会很高。在 软件开发的过程中，以下几 种情形随 处可见：1：软件维护时间长 ，而且维护人员 的积极性不高。做 过软件维护的开发人员，尤其是在接手不是自己 开发产品的源 码的时候，即使有良好的文 档说明，仍然会 对代码中冗长，没有注 释的段落叹为观止。理解尚且如此困 难，何况要修改或者增加新的功 能。2：新的 开发人员融入团队的时间比较长。这除了没有良好的培 训，文

3、档等有效机制以外， 每个人一套的 编码风格，也容易造成新成 员对于已有代码的理解不 够，甚至出现偏差。编码规范做为解决以上问题的方案 已经得到了很 长时间的应用。而在产品或者项目实际开发 的过程中，仅有 Code Conventions 是不能解决 Code 的问题的。他往往和 Code Review 配合，做为代码质量保证的手段。代码审查根据形式分 为两种：一种是交 叉代码审查（即自己的代 码由他人来检查，就象检查作业一样）另一种是代码会审（即以会 议的形式，大家 共同审核代码的质量。Code Review的目的有：在 项目早期就能 够发现代码中的Bug，帮助开发人员学习高 级开发人员的经验

4、，达到知识共享。避免开发人员犯一些很常 见，很普通的 错误。保证项目组的人员的良好 沟通， 项目或产品的代码更容易维护。 一般情况下， Code Review 的内容与 层次如下： 编码风格与代码规范 一致性 ：检查代码是否符合 编码规 范，确保所有人写的代 码基本一致。 代码满足基本功能要求 ：检查代码的 逻辑实现 ，以及单元测试的编写策略，确 认实现功能性需求。 代码满足性能等非功能性需求 ：非功能型需求 一般不便于 测试 ，需要借助一定的工具和 Review 人员的素质，针对编码 中对于性能影响的瓶 颈给 出解决方案。 去处冗余，提高代 码可读性：适当使用 Refactorying 技术

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

6、测试：集成测试是将模块按照设计要求组装起来同 时进行测试，主要目 标是发现与接口有 关的问题。 如数据穿 过接口 时可能 丢失；一个模 块与另一个模 块可能有由于疏忽的 问题而造成有害影响；把子功能 组合 起来可能不 产生 预期的主功能；个 别看起来是可以接受的 误差可能 积累到不能接受的程度；全程数据 结构可 能有 错误 等。6：系统测试 ：经集成测试后，已经按照设计把所有的模 块组装成一个完整的 软件系统，接口 错误也已经基本 排除了，接下来就是 对系统整体的 测试 了。7：验收测试：验收测试的目的是向未来的用 户表明系统能够像预定要求那 样工作。经集成测试后，已经按照 设计把所有的模 块

7、组装成一个完整的 软件系统，接口 错误也已经基本排除了，接着就 应该进一步验证软件的 有效性， 这就是 验收测试的仸务，即软件的功能和性能如同用 户所合理期待的那 样。经过上述的测试过程对软件进行测试后，软件基本满足开发的要求， 测试宣告结束，经验收后，将 软件提交 用户。3测试 方法分析集成测试及其后的 测试阶 段，一般采用黑盒方法。(1) 用边值 分析法和(或)等价分 类法提出基本的 测试 用例；(2) 用猜测法补充新的 测试用例；(3) 如果在程序的功能 说明中含有 输入条件的 组合，宜在一 开始就用因果 图法，然后再按以上( 1)、(2) 两步进行。单元测试的设计策略稍有不同。因 为在

8、为模块设计程序用例 时，可以直接参考模 块的源程序。所以 单元 测试 的策略， 总是把白盒法和黑盒法 结合运用。具体做法有两 种：a、先仿照上述 步骤用黑盒法提出一 组基本的测试用例，然后用白盒法作 验证。如果发现用黑盒法产生的 测试用例未能满足所需的覆盖 标准，就用白盒法增 补新的测试用例来满足它们。覆盖的 标准应该根据模块的 具体情况确定。 对可靠性要求 较高的模块，通常要 满足条件组合覆盖或路径覆盖 标准。b、先用白盒法分析模 块的逻辑结构，提出一批 测试用例，然后根据模 块的功能用黑盒法 进行补充。三、 测试人员组织人是测试工作中最有价 值也是最重要的 资源，没有一个合格的、 积极的测

9、试小组， 测试就不可能 实现。为 高质高效地完成 测试仸务，好的 测试工程师应具有如下能力：1、沟通能力一名理想的 测试 者必须能够同测试涉及到的所有人 进行沟通，具有与技 术（开发者）和非技 术人员（客 户，管理人 员）的交流能力。既要可以和用 户谈得来，又能同 开发 人员说 得上 话，不幸的是 这两类人没有共 同语言。和用 户谈话的重点必 须放在系统可以正确地 处理什么和不可以 处理什么上。而和 开发者谈相同的信 息时，就必 须将这些活重新 组织以另一 种方式表达出来， 测试小组的成员必须能够同等地同用 户和开发者沟 通。2、技 术能力就总体言，开发人员对那些不懂技 术的人持一种轻视的态度

10、。一旦测试小组的某个成员作出了一个 错误 的断定，那 么他们的可信度就会立刻被 传扬 了出去。一个 测试 者必 须既明白被 测软 件系统的概念又要会使用 工程中的那些工具。要做到 这一点需要有几年以上的 编程经验，前期的 开发经验 可以帮助 对软件开发过 程有 较深入的理解，从 开发人员的角度正确的 评价测试者，简化自动测试 工具编程的学 习曲线。3、自信心开发者指责测试 者出了错是常有的事， 测试者必须对自己的观点有足够的自信心。如果容 许别人对自己 指 东指西，就不能完成什 么更多的事情了。4、外交能力当你告 诉某人他出了 错时，就必须使用一些外交方法。机智老 练和外交手法有助于 维护与开

11、发 人员的协 作关系，测试者在告 诉开发者他的 软件有错误时，也同样需要一定的外交手腕。如果采取的方法 过于强硬， 对测试 者来 说，在以后和 开发部门的合作方面就相当于 赢了战争却 输了战役。5、幽默感在遇到狡 辩 的情况下，一个幽默的批 评 将是很有帮助的。6、很 强的记忆力一个理想的 测试 者应该 有能力将以前曾 经遇到 过的类似的 错误 从记忆 深处挖掘出来， 这一能力在 测试过 程中的价 值是无法衡量的。因 为许多新出现的问题和我们已经发现 的问题相差无几。7、怀 疑精神可以预料，开发者会尽他 们最大的努力将所有的 错误解释过去。测式者必 须听每个人的说明，但他必 须 保持 怀疑直到他自己看 过以后。8、自我督促干测试工作很容易使你 变得懒散。只有那些具有自我督促能力的人才能 够使自己 每天正常地工作。9、洞察力一个好的测试工程师具有测试是为了破坏的观点，捕获用户观点的能力，