去年参与产品的测试工作，后面做的总结，今天领导翻出来给新人做模板，感觉那时候自己的想法还是蛮多的，呵呵，摘取一些内容和大家交流，望指教：
Theory1 Testing the Hidden Data
这是偶然从网络上看到的一篇PPT，对我平时的测试工作有一定的指导意义。来TTG组做测试一段时间之后，一直苦于测试内容集中在页面操作，不能深入下去。所以查找相关资料，看到这篇
文章。所谓Hidden Data，一般来说主要指
数据库中我们在提交数据时，前台没有展示的字段和一些在后台系统服务的配置文件或者后台Crontab表中的内容。
在PPT中有说明，要测试隐藏数据，需要一些基础的知识，比如
SQL，比如一些系统的Crontab的知识，当然这些知识都是一些基础性的常识。
我自己也总结了测试隐藏数据的意义：
* 一些系统的功能在页面没有直观的配置，只有在后台定期执行，比如Crontab中的reboot，clean report等，这些系统功能可能在我们各个产品中都有，不过我们日常测试都很少覆盖到，问题产品的后果也不是一天两天就能发现，比如clean report，需要日积月累的，持续积累到某个阶段，系统的磁盘空间没有了，造成了运行出错，对于这些服务我们也要手动的去执行下相应的脚本或者程序，以确认能够功能能够正确实现；
e.g.：
Bug 22813：clean-emailreport.py无法正确执行
* 一些页面的功能，提交到数据库中的某个字段，然后程序通过分析数据库中字段值来出发某种行为，亦或者是我们在前台提交的数据在提交数据库中会附加一些属性，比如CreationTime此类常出现的属性值，在提交的时候是正确的，但后期，可能要做数据归并等操作时，由于这个隐藏的CreationTime出现问题，而在页面提交时又没有这个属性值，可能造成归并时的数据遗漏；
e.g.：重启任务时数据库中semd_mail字段应重置
2 Data Flow
NSC这款产品最主要的功能是
日志的获取，分析，存贮，展示(也有部分设备管理功能)，所以，产品的核心在于数据流向，正如前文leader系统分析方法中提及，对于NSC这款产品的系统服务要有了解，何种数据通过哪个服务提交到数据库(抑或是存在在文件中)，而页面从哪里获取数据，又以何种方式展示数据，要做到心理有数。
对于数据流的理解主要在于：
* 当产品出现问题时，可以更好的排查问题的原因，定位问题；
* 在构造特殊测试用例时，可以丰富我们的测试数据，使测试数据不依赖于具体的设备，丰富我们的测试范围；
其实这里面就是体现的数据和逻辑分离的过程，我们在了解程序数据流的基础上在测试中将掌握更多的主动权，发现隐藏的更深的错误。
BTW：在自己构造测试数据的过程中，要充分理解程序能够处理的数据格式，注意构造数据的异常范围，不然恐怕会出现Invalid的bug
3 Bug分析
对自己提交和项目整体的Bug要心理有数，经常性的做Bug的分析统计，这种分析统计不单单是运用Bugzilla提供的分析Bug存在的模块，Bug所属的人，更要内心对Bug有一个总体的走势。
现在的程序编写功能有着丰富的类库，而且很少应用较复杂的逻辑，都是一定的逻辑的编码体现，所以熟练的程序员对产品框架和类库较熟悉，应用起来得心应手，相应的问题也少。
而NSC研发团队较为年轻，熟练的程序员较少，特别是我负责测试的NSC 6.1版本，基本上都是今年新进公司的新同事，他们对CAVY不是很熟悉，对类库也较为陌生，所以经常会有一些逻辑覆盖不到，或者/0，或者函数参数格式不对等等新手类错误，在测试中就要在新提交的功能中注意这些边界值的校验。
同时也有一些语言上的不专业，字体格式比较山寨，这些都是从个人编程到产品化中不可避免出现的问题，也是需要提出并修改的。
Voice1 测试人员是否应该执着于代码
其实关于这个题目，在测试理论上一直是两个声音：
* 测试人员应该关注产品代码，尽可能的获取产品代码，
* 测试人员可以不关注代码，
关于两个观点，就不多做论述，只是想谈一点自己的理解，其实自己也在一个矛盾的过程中摸索，刚开始的时候希望自己可以尽可能的获取更多的代码，因为NSC产品组有得天独厚的优势，可以访问产品的SVN并且自己打包未加密的安装包进行测试，这给了解代码提供了很多的方便。
然后结果是：我关注于每个服务的实现是否给我的工作带来了实质性的促进？
的确，工作了一段时间后，我可以排查错误，也可以修改产品中出现的问题，但明确的是：这些不是我的工作职责，我的工作职责是寻找错误，至于后面的修复那不是我的责任，
并且理论上说：谁编写的代码谁更了解他，所以相应的研发在代码层面确认修改起来一定是比我来搞更高效，所以我觉得太执着于代码是越俎代庖的。
当完全不关心代码也可能有些偏颇，因为有些问题的确认在代码层面更直观，一些测试工作如果在代码层面分析验证可能更简单，快捷。
所以我认为，对产品代码的应该有限的关注，层面在你能够确认问题存在就为止。
2 测试人员对于产品了解的层面
必须要说，可能常规的理解都是：对于产品越了解越好。
这样不错，但是不要忽略了工作的惯性，当你对产品非常了解之后，是否能够依旧保持清醒独立的头脑对产品进行测试？
往往在深入到细节之后会有思维的惯性，对一些产品本身逻辑上的问题就会丧失敏感度，觉得很正常，就应该是这样的。这也是一些公司推动测试用例的同业评审和测试人员进行交叉测试的意义所在。
所以认为：测试人员应该对自己负责的产品脉络了解清晰，同时也要了解产品相应领域的走势。
Disadvantage1 文档能力
老生常谈
然后自己的文档能力可能更多的是主观能动性上的，也就是并不是不会写，而且不愿意写。其实这个问题也一直是组内经常讨论的问题之一。我对于文档向来认为要严谨，保持有限的文档数量，但要持续更新，保持文档的实效性。
对于内容也提供形式不限，但原则就是：内容要清晰，能够让阅读者获取你想表达的信息。
2 技能技巧
2.1 技能
Bug 22936：[低]：地址簿名称带特殊字符，出现show table error报错
这是一个反馈，是我负责的功能模块中出现的问题，在问题确认的时候，我通过查资料知道XML五个特殊字符分别为：, “ < > & ，然后组内某同事说：这是常识！
其实在测试输入框的时候，对于特殊字符我也有尝试，不过一般局限在SQL注入常用字符上，比如：-- “ & %等等，一直不知道XML还有这五个特殊字符。通过这点就觉得，很多日常中的非常基础的技术常识自己还没有掌握，需要拓展自己在细节知识点上不断的
学习，丰富自己的技能。
2.2 意识
两个案例：
* 在刚到TTG的时候，leader给我分配的工作是将他写的一个数据库查询的脚本模块化，就是通过自己的脚本获取数据库中的数据然后和NSC获取的数据做对比，来验证产品功能的准确性；
* 测试NSC 6.0.4.4的时候，leader测下发策略功能，我测集中用户管理，两个功能类似，都是到ESD产品线的IPS产品后台获取或者下发一些文档。当然我负责的集中用户管理只需要校验一个文件，而leader负责的策略管理需要一次校验多个文件。后来我发现leader是用一个.bat来校验的，里面其实也是wget,md5sum等工具的集合使用，而我在校验过程中也是用的wget和md5sum等类似的工具，但我就没想到写个bat去做。
其实这两个案例有同样的意义：就是可能你会某些东西，也知道使用某种工具能让你的工作变得简单，但却没有主动的意识去把它自动起来。这就不是技能的欠缺，而是意识上的不灵活。学以致用。。。
