前段时间，由于测试需要，使用C#结合WatiN组件，开发了一个小小的web自动化测试工具。

WatiN 是一个非常简单灵活的测试框架，可以模拟用户在客户端浏览器中的大部份操作，API也比较简单。

一、实现url调用和web控件的控制很简单，参考下面代码：

  for (int i = 0; i < txtUrls.Length; i++)
            {
                try
                {
                    WatiN.Core.DialogHandlers.AlertDialogHandler dh = new WatiN.Core.DialogHandlers.AlertDialogHandler();

                    using (IE ie = new IE(txtUrls[i]))    //调用URL，txtUrls[i]为Url地址
                    {
                        ie.AddDialogHandler(dh);//增加一个控制句柄

                        ie.CheckBox("cblSets_6").Checked = false;
                        ie.CheckBox("cblSets_8").Checked = true;                        
                        ie.Button("btnSave").ClickNoWait();   //执行保存
                        ie.RemoveDialogHandler(dh);
                        ie.Close();
                    }
                }
                catch (Exception e)
                {
                    sb.Append("Execute Err:").Append(txtUrls[i]).Append(";");
                }               
            }

WatiN 官方网址：http://watin.sourceforge.net/ 可以在上面下载组件。

    测试在软件开发流程中似乎处于下游，在执行和操作上看以处于被动地位。于是乎，很多时候，测试人员就会产生如下一些疑问(摘自某位网友的疑问，其实也是很多普通测试人员共有的疑问)：
    1、测试不知道自己在测试什么
    2、测试人员的依据不对
    3、测试人员是完全黑盒的，没有关注开发怎么实现
    4、测试人员没有充分测试
    5、测试人员完全被动

    结合我个人的一些实践，谈谈以上问题。
    首页，对1、2、3个问题，其实归结起来还是对需求分析的不透彻导致的。因为对需求分析不足，不知道当前版本开发人员做了哪些修改，所以也就无法在测试设计时，设计出很好的针对性用例来；同样因为对需求分析的不足，对客户不了解，对客户需要什么不了解，也就自然没有了测试依据！ 在软件能力成熟度模型(CMM)中，特别强调评审的工作，其实，测试人员需要参与到需求、设计的评审去中，这也是一个需求分析的过程。 当然，不否认现在很多企业，根本就还不存在这种过程规范，那么这就需要我们测试人员去推动它。推动开发提供需求、设计文档，推动参与到需求、设计文档的评审中去。
    在一些比较标准流程的软件企业中，测试其实也有专门的测试需求分析这一阶段的，这些工作由专门的TSE(相对于开发的SE来说,也都是一些技术牛人)来进行，充分说明了对这一块的重视。

    另外，对第4点，更多的应该是对系统、对业务使用的熟悉不够导致的。在居于测试已经确认的开发的修改范围后，测试用例的针对性和覆盖度，那么就在于你对系统结构的熟悉了，以及你对系统的业务应用场景的熟悉。就像经典的三角形的测试案例一样，因为你对三角形、等边、等腰的概念熟悉，那么很容易就设计了针对的用例,结合数字方面常见的错误，也就可以做出很好的覆盖来。

    对最后一点,我并不认同。主动与否，不是你的岗位决定，而是你个人决定的。如果企业在过程管理比较规范的话，那么规范应该不会让你被动的；如果没有规范的话，测试人员也可以主动起来。就像需求、设计文档，测试人员可以主动参与；另外，在版本参与上，也需要提前介入，而不应该等到版本转测试以后才匆忙介入， 这样就会导致在需求分析、开发实现特性、测试计划、测试设计等方面都被动。 测试人员也需要对项目全局掌控，特别是在需求变更上;再有一点，测试人员应该是站在用户角度上的(需求一端的)，是帮用户验证软件的。
    其实，对于一些流程操作不规范的企业，测试人员更应该本着软件质量保证的目的出发，去主动地推动相关过程的规范化。流程的规范不是一朝一夕的，需要不停地去总结和改进。

   在软件测试阶段，可能我们对软件的需求变更的事情已经很熟悉了，这个的影响，更多的影响到你的测试计划，对软件缺陷的漏测影响还不算很大。但当开发人员，在需求的背后，悄悄地“捅”你一刀－－根据他的想法，修改了计划外的东西！那这就很要命了，测试对需求不可控！很容易就造成了漏测。这在一些走敏捷开发、敏捷测试流程的企业里，算是司空见惯的事情。那么，面对这种现状下，我们该怎么去控制，怎么使漏测的可能性降低呢？

    首页，这个当然得从软件开发流程上去把握了。在流程上，我们可以操作的，一方面是将这个问题暴露给整个流程上的相关人员（可以通过群组邮件或在质量会议上），陈述这种“暗箱”操作的危险性，让PM强调开发流程，同时让开发人员增强这种缺陷的意识。另一方面，我们可以提高版本转测试的门槛。在转测试时，对开发的交付件进行严格审查，特别是对单元测试报告，对版本变更汇总，还可以更强硬地要求开发人员提供修改说明，描述具体修改了哪个模块、修改了哪一行的代码，这样，也可以在一定程度上，让测试人员对版本的修改更有把握，测试的针对性方面也会做得更有效。

    除了在流程上的掌控外，我们还需要从测试技术上来实现真正的自控。为何说是"真正的自控”呢？ 开发流程的东西，要所有人员很正直、很严格地遵守才行，如果开发转测试的交付件里，也很“无私地”不体现他的"额外工作"时，那也只能在我们测试这边来把握了。所以测试要建立在完全不信任开发的情况下（好像这个也应该是测试的本质）。对转测试版本，我们首先可以使用代码比较工具（如beyond compare），对前后版本进行比较，然后我们再根据需求来分析一下代码的修改，这样，我们对修改的合理性，对意外的修改也可以一目了然了，这样在做测试时，更可以有针对性地执行。笔者，曾经就在一个版本中发现开发人员无端去掉了一个加锁的操作（他以为这个线程锁，而我们这个进程现在只支持单线程），然后笔者使用多进程方式，发送交叉请求，问题就出现了。这个就是比较分析代码的功劳（因为这次需求根本就不涉及到多进程，与压力有关）。 还有一种工作就是进行压力的测试，笔者一贯都比较提倡，不管这个版本需求有无涉及到压力的影响。通过压力，我们可以测试一下交叉的请求，也可以关注一下内存泄漏方面的问题。这个笔者也有多次经历。它对于发现并发冲突、内存泄漏方面、性能下降等问题都很有帮助。再一个工作，如果可能的话，可以使用一些内存泄漏工具对软件进行内存泄漏方面的分析（如valgrind，purify等）。在一个版本修改少时，很多开发人员都会忽略对内存泄漏的检查。

    当然，以上这些方法需要具备一定的条件。如需要有质量管理这概念、测试可以接触源代码等。

    以上内容，纯属笔者亲身体验，有感而发。望各方朋友，多加指点。