敏捷测试（三）

1、敏捷测试的定义

　　敏捷测试是敏捷的一种&＃xff0c;敏捷测试是遵循敏捷宣言进行&＃xff0c;把开发作为顾客看待&＃xff0c;测试中采用的是敏捷方法论。

　　敏捷测试是遵循敏捷宣言的一种测试实践&＃xff1a;

　　●强调从客户的角度&＃xff0c;即使用系统的用户的角度&＃xff0c;来测试系统&＃xff1b;

　　●重点关注持续迭代的测试新开发的功能&＃xff0c;而不再强调传统测试过程中严格的测试阶段&＃xff1b;

　　●提倡尽早的开始测试&＃xff0c;一旦系统某个层面可测&＃xff0c;比如提供了模块功能&＃xff0c;就要开始模块层面的单元测试&＃xff0c;同时随着测试深入&＃xff0c;持续进行回归测试保证之前测试过内容的正确性。

　　2、敏捷测试中测试人员扮演的角色

　　1&＃xff09;测试是项目的“车头灯”&＃xff0c;它告诉大家现在到哪了&＃xff0c;正在往哪个方向走。

　　2&＃xff09;测试为项目组提供信息&＃xff0c;使得项目组基于可靠的信息作出正确的决定。

　　3&＃xff09;“BUG”是让用户感觉烦恼的东西&＃xff0c;测试人员不作出发布的决定。

　　4&＃xff09;测试员不保证质量&＃xff0c;整个项目组对质量负责。

　　5&＃xff09;测试不是抓虫子的游戏&＃xff0c;它的目的不是纠缠在错误中&＃xff0c;而是帮助找到目标。

　　3、敏捷测试的特点

　　传统的测试应该是——可以坐在我们测试部门专用的办公区内&＃xff0c;等待产品策划的文档&＃xff0c;拿到文档后着手准备用例&＃xff0c;并看一下项目的计划&＃xff0c;在程序员提交可用版本后对产品进行测试&＃xff0c;然后将找到的bug提交bug管理系统&＃xff0c;最后在产品计划发布之前&＃xff0c;拿出几个还未修改的bug说产品还未准备好……然而现在&＃xff0c;我们不再和产品团队有空间距离&＃xff0c;不再只是看文档写用例&＃xff0c;不再只是提交bug&＃xff0c;不再只是争论某个bug是否必须修改……敏捷的开发决定了我们必须以敏捷的测试来应对。

　　敏捷测试具有以下几个特点&＃xff1a;

　　1&＃xff09;“沟通”成了最重要的技能之一

　　敏捷测试更强调人的作用&＃xff0c;强调测试人员与开发人员之间的沟通。以往我们总要等到产品的一个正式版本发布&＃xff0c;才可以开始测试&＃xff0c;否则过多的介入会打乱开发计划。而现在&＃xff0c;敏捷测试告诉我们&＃xff0c;在产品开发过程中就要介入测试。

　　在传统的测试中&＃xff0c;当测试人员发现并提交一个bug时&＃xff0c;需要写大量的文字来描述bug的环境以及bug的重现步骤。程序员修正bug时&＃xff0c;也自信满满的说&＃xff0c;该bug已修正。但当测试人员一一复查时&＃xff0c;却发现你所认识的那个bug还在&＃xff0c;而程序员完全理解错了你所说的bug。这样的事情在以往的测试实践中有很多&＃xff0c;而现在&＃xff0c;测试人员所需要做的&＃xff0c;是与开发人员直接沟通&＃xff0c;把问题说清楚&＃xff0c;让他能够准确的理解你的意思&＃xff0c;甚至包括你对于该bug的分析。接下来一切就十分好办了。

　　仅仅是几句话的沟通&＃xff0c;就能将一个bug在最短的时间内修正&＃xff0c;这节省了很多时间。这皆得益于比以往更便捷的沟通&＃xff0c;同时也大大的提高了开发效率。但这也对测试提出了更高的要求&＃xff0c;虽然传统的测试也很强调沟通能力&＃xff0c;但现在由于需要更频繁的沟通&＃xff0c;测试人员对沟通能力的提高也变得也越来越重要&＃xff0c;成为了最重要的技能之一。

　　说到这里&＃xff0c;其实我们已经能感受到&＃xff0c;测试的角色定位已经变了。因为敏捷开发中&＃xff0c;要对质量负责的是整个团队&＃xff0c;这一目标就要求测试人员不再是一个独立的质量监督部门&＃xff0c;而是要融入到整个团队中&＃xff0c;成为开发中不可分割的一部分。

　　2&＃xff09;调整测试用例的粒度

　　业界通常认为&＃xff0c;测试员最重要的技能就是写用例&＃xff0c;通过用例来表达测试思想。我想&＃xff0c;即使是到了敏捷时代&＃xff0c;这个技能仍然是第一位的。只是&＃xff0c;如果你的用例写得过于详细和复杂&＃xff0c;那么在团队开始响应变化的时候&＃xff0c;你就会措手不及了。

　　至于粒度到什么程度才是合适的呢?那就要看个人的能力&＃xff0c;是否强大到能随时调整一份复杂和详细的用例的程度。一般不推崇十分详细的用例&＃xff0c;因为有些很细节的地方&＃xff0c;也没有文档可以参考。敏捷的最直接的特点就是快速&＃xff0c;如果设计的用例粒度太细&＃xff0c;那是很难开展敏捷测试的。

　　3&＃xff09;更多的测试方法

　　如何开展具有快速特点的敏捷测试呢&＃xff1f;单单用一种测试方法是很难开展测试工作的&＃xff0c;需要采用多种测试方法。

　　灰盒测试是一种介于黑盒测试和白盒测试之间的测试方法&＃xff0c;它设计的用例可以比黑盒测试更简洁&＃xff0c;而且随着你对程序框架的理解更加的深入&＃xff0c;你对所测的产品会更有把握。当然&＃xff0c;传统的黑盒测试是不能抛弃的&＃xff0c;因为很多bug都是在你所意料不到的情况下发生的。如何合理的分配灰盒测试和黑盒测试&＃xff0c;这还需要在漫长的敏捷测试中慢慢体会。

　　除了简单的灰盒黑盒&＃xff0c;测试人员尝试做一下白盒也是很有用处的。虽然程序员也做了白盒测试&＃xff0c;但测试人员的测试思路会和程序员有所不同&＃xff0c;得到的结果也许就会不一样。可以尝试对核心代码进行白盒测试&＃xff1a;包括代码的走查&＃xff0c;对函数的独立测试&＃xff0c;以及使用内存检测工具的检测等等。

　　最后还要结合自动化测试方法。由于产品会经常的响应变化&＃xff0c;对于某些重要的系统的测试就会一次又一次的要重来。若系统简单些还好&＃xff0c;若系统是比较复杂&＃xff0c;或是比较核心的&＃xff0c;如果还是用手动测试&＃xff0c;那就会很让人头痛了。所以测试人员的自动化测试是很有必要的。为自己最容易自动化的系统写一个自动测试脚本&＃xff0c;这样&＃xff0c;随便他们怎么改动&＃xff0c;我们都可以随时的进行回归测试了。

　　4&＃xff09;更多的人参与测试

　　当测试人员已经不再是一个独立的测试部门时&＃xff0c;需要进行测试的也就不只是测试人员了。程序员要自测&＃xff0c;策划也要测试&＃xff0c;甚至用户也可以来测试。不同的人可以得到不同的结果&＃xff0c;这样才能使我们对产品有全面的把握&＃xff0c;才能时刻的知道产品下一步应该怎样“响应变化”。

　　程序员的自测可以减少程序上的bug。策划的测试可以使策划更清楚的看到目前产品的现状&＃xff0c;亲自体验自己设计的系统。而用户的测试则可以给我们带来我们的最终用户的反馈&＃xff0c;这是最有价值的信息。