解析器小结

第一次用编程语言写自己的工具，挺有成就感的说~ 也有一些体会。工具的任务是把SilkTest脚本转换成python脚本。里面有一些工作特定相关的假设和需求。主要所得是心得体会啦~

Draft for SilktTest to Python transfer:

requirements:

"word1 word2"  -> "word1 word2"
{ -> [   
} -> ]
NULL, null, Null -> None
TRUE, true -> True
a.b.c   -> a['b']['c']

["","a"] + ["","b"] ->  ["","b"]

// -> #
line continuation

':' is not key delimiter in SilkTest
SilkTest keyword
 =, +, -, (, ), [, ], ; , .
 

Addintional Plus:
 1. detect what library is used in the test case , add sentence to import the library: Open_dialogname_**, Set_dialogname_**, Dlg_Set_dialogname_**, Dlg_Get_dialogname_***, Close_dialogname_***
  dialoglib = lower(dialogname) + "lib"
  
  from raftlibs import dialoglib
  from dialoglib import *
  
 2. add sentence like Activate_App(), sDocumentsDir = os.path.join(getPathToDesktop(), "TestFiles") at appropriate place
 
 3. Function call refactor:
  VerifyObjectActive()

 

从软件开发的角度来看：

         这是一个编译器，需要完成的基本任务是1）提取字符串和注释 2）分解单词 3）转换 等等.. 这些需求适用于“编译器”这个领域。用什么结构存储中间数据，功能之间是怎么样的接口，这些是可选的，算是程序设计的一部份。程序结构之下，分隔符是什么，字符串的文法，这要看具体的处理对象。

         基本任务，和加分任务可以根据难易程度和需求程度分优先级。一般把简单的最需要的任务放在前面完成。通常一个亟需的任务能够通过简单的机械化做到，是引发想开发这个软件的原因。几个亟需的任务也可以一个一个在程序中完成。当任务的个数很多很乱时，可以提取它们的共同点、合并到一个任务之中，将任务内容化为数据储存。

          在实现越来越多的任务时，可能整个程序的结构都要发生改变。原先的设计不一定能保证完成后来添加的任务。改变是痛苦的，学习理论知识能帮助建立有效的结构。

         理论知识研究通用的结构和算法。但是我们的需求可能很明确，用简单愚笨的结构就能实现，没有许多意外情况需要考虑。不管怎么样，理论知识能建立起一个模型和一类需求之间的纽带。不过理论的书籍很少讨论需求。会说明这这是用来干什么的，但是需求为何需要很少解释。而模型的建立来自复杂的需求，阅读理论书籍而不理解需求会有障碍。也是我觉得为什么项目开发经验的收获之一就是理解需求。

 

从软件测试的角度来看:

         在添加任务时，一个完整的功能不一定被一个独立的模块实现，它可能被划分到几个部分中。这些部分的前趋和后继可能会需要调整。部分和部分之间有时可能重叠，有时可能不重叠，这会让人头疼。将一个功能错误地划分或者放入错误的部分就会导致问题。另外在需要覆盖所有情况时，对个别特殊情况枚举不全也会导致错误。