有什么好的测试方法么？

[twtyypmb123]

比如说要测试一个方法，必须先登录，注入session，然后一堆点击，发现不是想要的，改了个符号，然后又继续重复，有什么好的方法或者工具，比如“记住当前所有状态”，直接“运行到要测试的那一句”？

[twtyypmb123]

不过不只是要测试单个的方法，我的意思是直接“跳”到运行处，而且程序状态是之前“保存”的

[人生导师]

可以的，这个可能需要做自动测试工具，你看看能不能用单元测试来做啊，.net 中有Moq类库可以为我们模拟对象。

[以专业开发人员为伍]

编写测试程序，就是使用你开发所用的工具，编写即可。所编写的程序，就是要模拟用户的操作行为，然后使用“断言”来将测试程序与vs的调试器相连接。

[以专业开发人员为伍]

我先给你写一个比较“傻的”例子，首先在 Page_Load 中你要判断是否需要判断，例如

protected void Page_Load(object sender, EventArgs e)
{
    if (Comm.Common.IsTestMode)
        test();
    //......进行正常的 Page_Load 操作
}

这样就驱动了测试。然后写

    private void test()
    {
        if (Step == 1)
        {
            this.PreRenderComplete += (s, arg) =>
            {
                Debug.Assert(this.TextBox2.TextMode == TextBoxMode.Password);
                var scp = new StringBuilder();
                scp.AppendLine(string.Format("document.getElementById('{0}').value='{1}';", this.TextBox1.ClientID, "1234"));
                scp.AppendLine(string.Format("document.getElementById('{0}').value='{1}';", this.TextBox2.ClientID, "23456"));
                scp.AppendLine(this.ClientScript.GetPostBackEventReference(this.Button1, string.Empty));
                ScriptManager.RegisterStartupScript(this, this.GetType(), "test1", scp.ToString(), true);
                Step = 2;
            };
        }
        else if (Step == 2)
        {
            this.LoadComplete += (s, arg) =>
            {
                Debug.Assert(this.TextBox2.Text == "23456");
            };
            this.PreRenderComplete += (s, arg) =>
            {
                var name = (string)Session["loginName"];
                Debug.Assert(name == "1234");
            };
            this.登陆成功 += () =>   //验证此事件确实抛出，然后才继续进行测试
            {
                //执行进一步的测试用例，使用 ScriptManager.RegisterStartupScript 语句输出模拟用户操作的脚本
                Step = 3;
            };
        }
    }

    private int Step
    {
        get
        {
            var x = ViewState["TestStep"];
            if (x == null)
                return 1;
            else
                return (int)x;
        }
        set
        {
            ViewState["TestStep"] = value;
        }
    }

这样这个页面就会自动模拟用户操作，进行页面回发，直到把每一步的测试用例走完。 进一步地，你其实可以把这一个 test 过程拆分成几个独立的test类或者test过程单独独立出去，使用一个不到100行的“测试引擎”代码来自动管理这些测试用例（写在 Global.asax中即可），它自动反射到每一个 Page 的测试用例分别都有几步，然后在 Page 执行之前先执行测试用例（也就是说上面的Page_Load 中的 if 语句），然后当一个Page的测试步骤走到最后一步之后，它能够随机取出下一个待测试的页面的 url 来开始测试。 比如说你的 asp.net 应用有50个页面的300个测试用例。你中午去吃饭的时候，就可以开始测试，然后你的电脑就自动开始模拟用户的各种操作了。然后吃饭回来，你可以看看日志，会看到50个页面一共被测试了800遍（每一次都有随机顺序选择下一个测试页面），没有进入vs调试状态，也没有“停机”，还在继续测试着。这时候就说明测试通过了，可以停止测试了。 这里只是集中在最基本的入门概念上去说的。技术不重要，重要地是你能够实践。

[twtyypmb123]

引用 4 楼 sp1234 的回复:

我先给你写一个比较“傻的”例子，首先在 Page_Load 中你要判断是否需要判断，例如

protected void Page_Load(object sender, EventArgs e)
{
    if (Comm.Common.IsTestMode)
        test();
    //......进行正常的 Page_Load 操作
}

这样就驱动了测试。然后写

    private void test()
    {
        if (Step == 1)
        {
            this.PreRenderComplete += (s, arg) =>
            {
                Debug.Assert(this.TextBox2.TextMode == TextBoxMode.Password);
                var scp = new StringBuilder();
                scp.AppendLine(string.Format("document.getElementById('{0}').value='{1}';", this.TextBox1.ClientID, "1234"));
                scp.AppendLine(string.Format("document.getElementById('{0}').value='{1}';", this.TextBox2.ClientID, "23456"));
                scp.AppendLine(this.ClientScript.GetPostBackEventReference(this.Button1, string.Empty));
                ScriptManager.RegisterStartupScript(this, this.GetType(), "test1", scp.ToString(), true);
                Step = 2;
            };
        }
        else if (Step == 2)
        {
            this.LoadComplete += (s, arg) =>
            {
                Debug.Assert(this.TextBox2.Text == "23456");
            };
            this.PreRenderComplete += (s, arg) =>
            {
                var name = (string)Session["loginName"];
                Debug.Assert(name == "1234");
            };
            this.登陆成功 += () =>   //验证此事件确实抛出，然后才继续进行测试
            {
                //执行进一步的测试用例，使用 ScriptManager.RegisterStartupScript 语句输出模拟用户操作的脚本
                Step = 3;
            };
        }
    }

    private int Step
    {
        get
        {
            var x = ViewState["TestStep"];
            if (x == null)
                return 1;
            else
                return (int)x;
        }
        set
        {
            ViewState["TestStep"] = value;
        }
    }

这样这个页面就会自动模拟用户操作，进行页面回发，直到把每一步的测试用例走完。 进一步地，你其实可以把这一个 test 过程拆分成几个独立的test类或者test过程单独独立出去，使用一个不到100行的“测试引擎”代码来自动管理这些测试用例（写在 Global.asax中即可），它自动反射到每一个 Page 的测试用例分别都有几步，然后在 Page 执行之前先执行测试用例（也就是说上面的Page_Load 中的 if 语句），然后当一个Page的测试步骤走到最后一步之后，它能够随机取出下一个待测试的页面的 url 来开始测试。 比如说你的 asp.net 应用有50个页面的300个测试用例。你中午去吃饭的时候，就可以开始测试，然后你的电脑就自动开始模拟用户的各种操作了。然后吃饭回来，你可以看看日志，会看到50个页面一共被测试了800遍（每一次都有随机顺序选择下一个测试页面），没有进入vs调试状态，也没有“停机”，还在继续测试着。这时候就说明测试通过了，可以停止测试了。 这里只是集中在最基本的入门概念上去说的。技术不重要，重要地是你能够实践。

谢谢，给力的建议

[範先森]

如果你要测试的功能跟前面一些登录记录的状态什么的没关的话你可以提取出来做功能测试的啊，不然步数太多，为了测试一个功能还要写好多代码，平衡一下时间成本吧。

[以专业开发人员为伍]

“时间成本”十个幌子。许多人效率及其低，可是不已测试为准，而是以瞎猜为准。 当你以测试为准时，假设你有上万行代码，突然需要重新设计重要的框架，出了问题怎么调试？实际上这个时候是以测试为指导，而不是胡乱去调试。跟说的明白一点，假设一个东西你调试时10分钟还不知道所以，你就应该退一步回到测试用例上来，而不是继续瞎调试。因为前边的399个测试都通过了，那么第400个测试也就容易发现bug的起因，甚至你几乎不用调试就能立刻想起问题的起因是什么。相反地，胡乱在复杂系统上调试，那种做法看似挺忙、其实是骗老板的工资呢。

[以专业开发人员为伍]

那些整天在班上工作12个小时，周末也在老板面前表现得很积极要去加班的人，我们一眼就能看出其能力是不是真的必须靠加班、靠体力来弥补。 真正的程序员不加班，把工作做得很棒。因为他工作时很有章法，他有测试驱动的习惯，而不是盲目调试。

[以专业开发人员为伍]

引用 楼主 x3230835 的回复:

直接“运行到要测试的那一句”？

事实上，这个说法往往不够实际。 有些人、有些测试文章说什么“测试最好是按照单个函数来组织”，这一般来说其实是从意淫出发的想法。你想一下，编程是很低级的事情，对吧？编程的目的是是为了能够让通过测试（好拿到你想拿到的工资，或者其他报酬），而测试的目的是敢于真正去发布，而发布的目的是满足投资人的需求、用户的需求。 所以测试最终是以验收为单元的，而开发过程中得的测试则是以程序员的能力为单元的。这些东西哪一个没有人味儿？怎么可能让测试以一个没有人味儿的所谓“函数”为基线呢？ 在开发中，有经验的人负责设计测试用例（也就是负责分配任务），他以预估程序员的能力为准绳。例如开发的节奏最多用50分钟为一节，那么最多在50分钟之后如何验收呢？这就是设计每一个测试用例的理论基础。 比如说我要写一个“计算两个数值的加法结果”的函数，我的能力比较低级，我用50分钟只能保证计算“1+1=?”，然后再用50分钟只能保证"1+2=?"，然后再用50分钟只能保证计算“4+2=?”，最后50分钟才能保证“120+72=?"，那么我们就设计这样4个测试用例，让开发者循序渐进地进行开发。至于说这个计算函数底下还调用了什么函数，我们不用再去纠结！ 因此设计测试用例是以开发者的个人能力、开发时间为准。而不是以什么没有人情味儿、个人看法不同的纯粹技术为准。 技术算什么？你不能脱离开不同人的能力，去谈开发和管理。就好像你不能胡说什么“程序员沟通”而只从行政角度而非开发行为角度去奢谈沟通。 所以设计测试用例不要太具体、仅仅说什么“我就是要测试一条语句、一个函数”，但是也不要太空洞而忘记了这个“节奏”。 既然设计测试用例时要实际地按照开发进度细节来设计，那么设计多少才算完？——以你认为“要吐了”为准。比如说我要是对上面的“计算两个数值的加法结果”用例写上7个可能就吐了，那么我就写7个。写完了测试用例，我才开始真正编程开发。

[sp1234_maJia]

一旦你开始用自己的开发环境去编写测试用例（而不是到网上到处去下载各种没谱的“自动测试工具”），那么你就可能自己想到各种提高效率的改进措施。 例如可能“默认情况下”启动的测试只是运行最近3天的测试，而只有特意去进行“完全测试”时才运行所有测试。通常一个人每隔几分钟就会运行一下最近3天的测试。而1、2个小时才会运行一次完全测试，并且也并不持续很长时间。 例如你可能写一个几十行代码的“迭代器”方法，来枚举页面上的所有控件。因为你的测试用例中可能要“断言”某个控件下面一定有某个特征的子控件，这就需要写一个查询（例如linq查询）语句来表示，而查询的数据源需要自动迭代控件树。这是编写 UI 测试用例最常用的一个函数。 例如你可能写一个只有几行的bat（批处理）文件，来同时打开10个浏览器窗口去并发测试。因为许多问题用顺序测试是发现不了的，应该随时进行并发多线程测试（asp.net 对浏览器端的单独请求是启动子线程来处理的）。 ........ 总之，是用自己的开发工具来自己动手编写测试。不只是去要求网上有什么现成的自动测试工具，不要纠结非得用什么漂亮的图形来显示测试统计结果，那些都不是测试的实质目的。