曾经有位前辈跟我说，测试员最重要的技能就是写用例，通过用例来表达测试思想。我想，即使是到了敏捷时代，这个技能仍然是第一位的。只是，如果你的用例写得过于详细和复杂，那么在团队开始响应变化的时候，你就会措手不及了。
我就真的遇到过这种情况，某一个设计做到一半的时候，由于效果并不好，被要求进行修改。这时我的用例也要相应的进行修改——最怕这个了。如果这是一系列粒度很细的用例，动辄上千条，一旦改起来，费时又费力。但如果我的用例的粒度本来就并不是非常细，那我调整起来就快速多了。
至于粒度到什么程度才是合适的呢？那就要看个人的能力，是否强大到能随时调整一份复杂和详细的用例的程度。我个人并不推崇十分详细的用例，因为有些很细节的地方，也没有文档可以参考。而且我们测试的游戏，很多细节没有绝对的对与错之分。即使真的出现了一些有疑问的地方时，迅速的和程序员和策划进行沟通也比写一份更详细的用例要有效得多。要知道，我们的目标也应该和团队内所有的成员一样，是一款可以玩和好玩的游戏，而不是面面俱到的测试用例。
更多的测试方式
我看过不少介绍敏捷开发的文章，大都有这么说过：在进行敏捷开发中，快速的响应变化的前提，一定是对质量的保证。如果质量无法保证，那是无法对变化做出响应的。因此这要求程序员能更多的进行自测，包括白盒的，自动化的，测试驱动的。而站在测试人员的角度上，我们能做些什么呢？
因为对产品接触的更具体，我有了很多机会接触详细的程序设计，这使得我已经可以尝试直接阅读代码，并在此基础上进行测试用例的设计。行话说，这就是灰盒测试。灰盒测试带来的好处是，用例的设计可以比黑盒测试更简洁，而且随着你对程序框架的理解更加的深入，你对所测的产品会更有安全感。当然，传统的黑盒测试是不能抛弃的，因为很多bug都是在你所意料不到的情况下发生的。如何合理的分配灰盒测试和黑盒测试，这还需要在漫长的敏捷测试中慢慢体会。
除了简单的灰盒黑盒，测试人员尝试做一下白盒也是很有用处的。虽然程序员也做了这样的工作，但测试人员的测试思路会和程序员有所不同，得到的结果也许就会不一样。我就尝试过对核心代码进行白盒测试：包括代码的走查，对函数的独立测试，以及使用内存检测工具的检测，尽管最后还是没有查出bug。
最后别忘了自动化。由于产品会经常的响应变化——相信我，这事儿真的很轻易的就发生了，对于某些重要的系统的测试就会一次又一次的要重来。若系统简单些还好，若系统是比较复杂，或是比较核心的，如果还是用手动测试，那就会很让人头痛了。所以测试人员的自动化测试是很有必要的。为自己最容易自动化的系统写一个自动测试脚本，这样，随便他们怎么改动，我们都可以随时的进行回归测试了。
此文章共有3页 上一页 1 2 3 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
