前几天在网上看到别人的推荐，下了电子稿一直都放着没看，今天有时间看了一遍，还是有点收获的。
作者在这篇文章中给了五个关于提高软件测试部门的建议。
1.There are two types of code and they require different types of tests.
译：整个软件包含两种代码类型，而这两种代码类型要用不同的测试方法来测试
（注：本人译，不能保证百分之百正确，如有错误，欢迎纠正）
这一点要讲的是针对不同的测试内容选择不同的测试方法。这里的two types of code 指的分别是experience code(用户的操作、功能、特性等，我的理解是表现层的代码)以及infrastructure code(指的是底层的，我的理解是逻辑层和数据库交互层的代码，这种代码是用户看不到执行结果的，除非出现比较严重的错误前台才会弹出信息框报错) 。对experience code要更多的采用手动测试，因为这一层的代码效果只有用肉眼辨别才能更准确，也就是说这部分的代码，如果采用自动化测试出来没有问题后，并不代表我们可以对这部分放松了;对infrastruct code要多采用自动化测试，设置变量来看处理的有无问题。
2.Take your testing down a level from features to capabilities.
译 ：降低你的测试一级从特性测试到功能测试。
光看特性测试，感觉不是很明确，有很多人也可能无从着手，但如果把一个特性转化成影响这个特性的多个功能点，那么就好分析了。
作者提到了他们团队采用component-feature-capabilities，我对component这个词还没法准确的把握是什么意思，我对这个的理解就是先把系统分模块，然后再把对这个模块的抽象的特性描述分解成若干个明确的功能点来分析。
3.Take your testing up a level from test cases to techniques.
译：将你的测试抬高一级，从测试用例到测试方法
当你的测试结果出现failure的时候，你不能只看这个case以及结果，而应该从一个更大的范围来看这个问题，将这个测试的目的、内容、策略以及最终结果相结合起来，总结出一个大的问题，从而能引申出其他的的问题。 例如，某个case发现程序对页面的跳转在输入0的时候出现了问题，那么就可以引申出这个系统可能对页面跳转输入的字符的非法情况没有正确处理，从而可以引伸出其他可能存在的问题：输入非数字、小数等。
4.Improving development is your top priority.
译：对于这句话的理解，在看了后面的文章之后我觉得应该是译成“要把提高开发部门作为最高优先级”
在文章里面有一句话说：开发出一个好的软件并不是测试人员，而是开发人员，要想保证软件质量，那就要通过提高开发人员的能力。
仔细想想，如果开发人员能力提高了，那么bug就会少了，对于我们测试人员来说也就轻松了。所以我们测试人员并不是每天重复的去操作那些测试用例发现bug就完事了，而是通过测试来告诉开发人员他们所面临的问题是什么，他们在解决这些问题的过程中不断提高自己，也就不断提高了软件的质量。
文章中作者引用了一个人的话，看下面这句话应该能更好的理解这第四个建议，我就不翻译了，以免出错误人子弟。
"The real value of tests is not that they detect bugs in the code, but that they detect inadequacies in the methods, concentraction and skill of those who design and produce the code."
5. Testing without innovation is a great way to lose talnet.
译：没有创造性的测试是很容易流失人才的。
在很多人看来测试就是一种枯燥的工作，重复的运行测试用例，不停的点击点击发现bug。但真正的测试人才并不是花很多时间在执行测试上，而是在不断的分析测试提高测试策略的事情上，后者才是测试的趣味所在。
以上便是我看这篇文章后的收获。想来我现在好像越来越喜欢写测试文档了，在前期好好分析、设计测试，选择测试工具远比执行测试有趣的多了。看来我正在向大师迈进啊，HOHOHO~~
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
