做一个开发人员认可的测试人员（二）

作者：网络转载发布时间：[ 2014/1/23 11:25:01 ] 推荐标签：开发人员测试人员自动化测试

　　在各种小化或者刚打开的窗口都能Focus住并且大化。

　　第二个问题是命名不可避免会有重复和多态出现。有时候还是得去扫一眼代码，看看不同的Wizard到底是做啥的。

　　比如导入文档的时候可选的不同字段，这个时候会出现多态，也是同一个类似的名字，但是不同的参数。

Declare Function ADoc_AddPolicy basiclib "A_Document" (Title As String， FileName As String， _

    Declare Function ADoc_AddPolicy1       basiclib "A_Document" (Title As String， _
                                                                    FileName As String， _
                                                                    Optional ExpireDate As Variant， _
                                                                    Optional Country As Variant， _
                                                                    Optional City As Variant， _
                                                                    Optional Desc As Variant， _
                                                                    Optional StateName As Variant， _
                                                                    Optional Template As Variant， _
                                                                    Optional TstTimeStamp As Variant， _
                                                                    Optional TstTime As Variant) As Integer

　　如果在输入文档的时候需要输入过期时间等字段只能选择第二个函数，第一个函数是基础的只去填写必填字段的。

　　这个时候是考察队Test Framework是否熟悉了。

　　后一个要说的问题是在Test Case 的每个部分命名的问题，为了隔离每个Case，让每个Case都能独立于其他Case，让Case粒度更小。

　　我们这样约定：
　　1 第一部分是创建环境，比如为了验证Search文档，第一步我得Create/Import文档。
　　2 第二部分验证Search文档。
　　3 第三部分是删除掉第一步的文档。

　　我们有2个命名方法

　　第一种： PreEnv_CreateDoc
Verify_SearchDoc
PostEnv_DeleteDoc

　　第二种： Part1
Part2
Part3

　　我想你一定和当初的我一样毫不犹豫选择了第一种。呵呵。

　　想想如果第一步不是创建一个文档这样简单，而是要做10几个无法简写的步骤呢？于是我们看到了各种各样千奇百怪的命名，在Debug的时候，调试的人想死的心都有了。

　　于是我们简化到第二种，反正第一步是第三步的逆操作。第二步是验证。

　　稳定，简单压倒一切。为了简单可维护。有时候得牺牲掉可读性。

　　另外是各位写Test Framework的大大，也得去学学算法。曾经有个人写了个在某个负责的C/S的复杂的类似于Excel那样的10X10的格子取到第三行第四列的显示的值。