转载～软件测试

开发模型变了，工作模式不可能一层不变。如果想要在不同的模型中都获得成功，自是要对不同模型对人员的需求有所了解。通过很多科学家及实践证明，敏捷开发是所有开发型中最高效的。如果结果不尽如人意，想来就是实施应用的不对了。下面就是敏捷开发中的测试之我见了。

 

 

1.     敏捷开发模型的自适应性对开发和测试人员的要求。

-          测试要深入需求变化

随着需求的变化，产品设计和实现也在做相应的调整。如果测试人员只能从黑盒角度看到变化，那么一则bug发现总是在较晚时期，二则测试任务将是无底洞式的。因为永远循环的重复测试，才能保证新的改动实施正确且没有影响到已经稳定了的功能模块。所以，测试人员要深入产品的设计与实现。这和计划驱动方法下的软件测试方法区别很大。因为，我们不在局限于按计划按时按预算完成工作。

 

-          自适应性要深入技术开发层面

如果仅仅从项目管理层面实行敏捷开发，而忽略了技术层面，敏捷开发也很难得以成功。

从开发角度看，自测试代码（Self-Testing Code），持续集成（Continuous Integration），重构（Refactoring），和简洁设计（Simple Design）等等这些技术层面上的方法都需要应用执行才能达到开发的自适应。

 

2.     敏捷开发的引入将引起测试领域的革命。将底层测试人员和高级测试人员彻底划分开来。这是自动化测试等非手动功能测试方法做不到的。因为敏捷开发小组要求人员的平均素质，而不是一个将领一群兵。这也将使软件开发国际化真正实现—发展中国家脱离外包工厂的名号，进一步发挥人的主观能动性。

    我们知道在中国，或是印度等相对发展落后的国家，大多数的IT工作都是重复的简单的非核心的劳动。这点在《世界是平的》一书中解释的很详细。不难想象，这些人拿到设计说明书，按步骤执行实现需求的功能，这是不需要发挥太大人的主观作用的，大多数工作人员只是按事先规定好的方法和流程做事情。但是，制作软件的全过程都是人在参与，人的主观能动性如果没有得到发挥，将是大大浪费了资源。当然，这项的实施是需要整体人员的综合素质的。

 -          首先，看看微软是怎么划分测试人员的职责的：在微软的测试体系中，主要的测试人员分为两种，一种是SDET（Software Design Engineer Tester），一种是STE（Software Test Engineer）。对SDET编程能力的要求和对开发人员的要求基本上是一样的。他们都须有扎实的计算机基础知识和编程能力。区别可能在于开发人员对算法更加精通，或某一方面的技术钻研的更深入一些。而微软亚洲工程院要求SDET的技术面很宽，要能使用很多种技术，比如可以用C、C#、脚本等来写程序。如果测试人员懂开发，有扎实的编程能力，那么他们能够做一些普通测试人员做不了的工作，比如可以将源代码打开做代码的静态分析，还可以做测试用例的代码覆盖率调查。所谓的代码覆盖率调查，是指考察测试用例能否将所有的源代码都调用到，是一种对测试质量的初步评估标准。而这些恰恰是敏捷开发所需要的。

-          从公司管理的角度看测试人员的划分：引自“测试人员招聘的尴尬”

测试人员的岗位有很大区别，包括做UI功能测试、系统测试、数据库测试、自动化开发、环境管理和项目管理等，对技术要求不一样。为了更好地找到合适的测试人员，有一些比较好的办法，例如：

1.对于功能测试，技术含量低，但要求悟性好、思维能力好、沟通能力和理解能力强等，可以面向高中毕业生和大专生，通过良好的培训，就可以满足岗位要求。他们的稳定性好、肯干。

2.对于UI适用性和易用性测试，为了打破单调性、习惯性，可以找些合同工、周末钟点工，人员的来源可以根据软件产品的涉众范围决定，包括暑假的教师、政府的公务员（周末钟点工）和在校的大学生等。

3. 可以招大学应届毕业生，通过4－5个月公司内部的专业培训，可以从事技术要求比较高的测试工作，如API测试、自动化脚本开发。

4. 通过前几项省下来的预算，可以用更好的薪水招聘具有丰富编程经验和测试经验（4－5年以上）的工程师，从事技术要求更高的系统测试、数据库测试等。

我想如果是敏捷开发，大多测试分布在整个产品测试阶段，并且很难划分。因此需要测试人员具有综合素质。这种模式下，功能测试、可用性测试、稳定性测试、系统测试、数据库测试等等都是一起进行的。因此，单一素质需求，在这里就不是很试用了。

3.     沟通-成败的根本

沟通在任何开发模型中都很重要，在敏捷开发中尤为重要。甚至关系成败。可是，它也是最难写出来量化的东西。有些好的方法可以借鉴，但是实际中的一些细节问题还是要做事情的人本身去思考去琢磨去总结，然后去做好。以下是引用Martin Fowler试图从理论层面达到好的沟通译成中文的一段话。

“沟通的确是一个非常重要的环节，它是敏捷方法的核心。在敏捷方法中，单元测试是程序员和代码组件的沟通，功能测试是程序员以及QA和系统的沟通，故事墙（Story Wall）和回顾（Retrospective）是团队和成员之间的沟通，功能演示（Showcase 或者 Demo）是团队通过产品和最终用户的沟通，持续集成（Continuous Integration）是产品和企业计算环境的沟通。沟通好了，什么事情都可以妥善解决，沟通得不好，好事也会变坏事。和广大技术爱好者交流沟通也是酷壳存在的目的和意义。”

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/ctina/archive/2010/08/02/5783697.aspx