最初的目标
有一位程序员，喜欢新东西，经常引入新方法新思路试图改变现状。有一次，他觉得部门在测试手段太依赖手工测试了，于是就想引入自动测试。他调研试用了几种工具以后，选择了某大公司的产品作为主要工具。
他计算了一下，一共有1000条测试用例需要自动化，于是他定下计划:一个人一天可以写5个测试用例，所以需要200个人天;计划要在一个季度完成，按一个人一季度共60个人天的话，需要4个人还有余。这样，全部用例做好以后，他估计，至少减少一半测试工作量。
于是，这老兄报告给总经理，总经理同意了。于是就给他招了4个人，成立了自动测试组，风风火火就干起来了。
他的做法是，手工测试有多少条用例，他就用自动测试工具实现多少条。
一个季度下来了，全部测试用例完成了。当然大家敲锣打鼓的庆祝。但接下来，却遇到了意想不到的问题。
第一、所有的测试人员都认为自动测试组写出来的脚本没有用。为什么呢?因为自动测试组的员工都是新招的，对产品不熟;因此他们只好对照着手工测试用例一条条的做，就像做翻译一样把手工测试用例变成自动脚本。但测试人员说，手工测试用例本身就不够完善
，很多测试的验证点是凭经验的，这样翻译出来的用例当然不过关。
第二、新产品特性已经改变了，写出得脚本过期了。因为是比照着手工用例，自动测试组使用的用例是产品的上一个版本的，这样写出来的用例当然不适合现状。
第三、短期内投入产出比很低。手工测试一天能走100个测试用例，1000个用例10天走完。但4个自动测试工程师3个月才完成1000个用例的开发，也就是花了4×3×20=240个人天，就算测试用例100%可用，也需要240÷10=24轮才能在成本上持平，如果每个版本测3轮
的话，相当于8个版本。而8个版本，产品还在不在都难说了。
程序员做了反省，发现自己犯的最大错误是:自己提出问题的初衷是减少测试工作量，但执行的时候却把“翻译”完所有的测试作为了目的，而忘记了最初的目标。因为只顾着往前赶数量，从来没有请手工测试的工程师来看看，是不是可以100%替代手工测试;也没有
在小模块上试试，看看开发人员有什么意见。
这样，程序员改变了做法。和开发、手工测试和手下沟通后，他决定把自动测试工程师分散到模块去，和相应模块的开发，测试成为一个工作小组。开发人员设计编码的时候，他们就设计自动测试用例，充分听取手工测试工程师的经验，并且每天都运行一遍。这样
，自动测试的脚本就完全和产品同步。他们把自动测试用例和产品代码签入到同一个代码库，同样的版本具有同样的标签，这样，每个版本的产品都有了自动测试的脚本。
这样，又过了一个季度，团队开始接受自动测试了。而且有了一个意外的收获，开发人员现在乐于用自动脚本做单元测试，居然开发效率和质量都提高了。
程序员得出一个经验，目标在最初的设定，一般都会比较清楚的，但在漫长的实现过程中很容易忘了原来的目标是什么，而把一些表面的指标当成重要的东西。因此，经常看看今天所做的努力和原先的目标是否一致，和能否一致，是很重要的。
我们的Bug描述中同样也要包括以下三要素：位置、操作、现象。具体来说：
1.位置：首先应说明操作进行的位置，通常是系统中的某一模块。另外是具体的出错位置，可能是某一字段、某一页面...
2.操作：详细的、有次序的、每一步的操作步骤，包括输入的数据
3.现象：具体的错误描述，包括界面显示、错误信息
Bug的记录是测试人员工作的基本内容，也是测试和开发交流的基础，确保了Bug描述的有效性，即可提高Bug的修改速度，也可提高Bug的修改质量。而作为测试人员在Bug描述中出现错别字就如同开发人员在程序中出现界面上的Bug一样，完全是不细心造成的，对于测试
人员来说是不应该出现的。 写的不错，推荐阅读 写的很好！！ 我也推荐阅读 看得我现在充满动力了
页:
[1]
