做测试工作那么久了， 编程知识还是少的可怜，趁着这两周不太忙的时间， 组织组内的测试人员自己开发了一个Task系统（即任务管理系统）， 这是一个小的不能再小的系统，  但是我的想法是希望借此机会锻炼一下测试人员的编程能力，

          虽然这个小系统的功能少的可怜， 不外乎新增，修改，删除，查询什么的， 却可以让我们开始一个比较系统的学习， 系统虽然小， 但是从需求文档，需求确认，设计文档， 原型，数据库建表，到开发的三层架构，到最后的测试过程， 我们都一丝不苟的进行下去了，我感觉到收获还是很大的。

         今天下午， 我们发布了我们的第一个Release版本，这次的测试工作， 久换位交给了我们组的开发们，在此也特别感谢我们的项目经理和其他的开发人员对于我们的大力支持，至少他们没有认为我们在浪费时间，打扰他们， 反而给予我们很多的帮助和相关的培训，

         PS：他们找bug的时候也是一丝不苟啊， 还常常教育我们：“你们不是常说×××么， 看吧， 现在自己范这个错误了！”

         这次发布的是1.0版本， 我希望我们以后还有更多的2.0，3.0版本， 随着版本的提升，功能的增强， 我们可以更好的了解编程知识，这些必将有利于我们今后的测试工作。So，Keep Studying！  

测试数据库原则上应该和开发数据库独立开

问题:  目前公司测试人员的测试数据库和研发人员的开发数据库没有独立开。

解决：测试人员的测试数据库原则上应该和研发人员的开发数据库独立开，

原因分析：
       1，测试人员构建自己的测试数据，在测试过程中观察数据的正确性，避免了受研发人员开发过程中针对数据库进行变动所引起的不确定性。
       2，测试人员如果独立自己的测试数据库，使用人数少，在通过工具跟踪程序运行的SQL语句时（比如事件探查器），可以使跟踪语句单纯，便于测试人员迅速掌握数据库之间的关系，便于查找到正确的数据库链接数，
       3，测试人员独立测试数据库，对于数据库的版本变更掌握更清楚，方便针对不同版本的客户数据库进行升级和维护，这样的做法针对测试人员担任发布角色，且客户版本众多的公司，尤为重要。 

 

copy from wonder 3月日志

原因分析：

 

copy from wonder 2006.9 日志

什么样的需求是一个好的需求？？

1,主要流程是否描述清楚,是否有二义性, 如“3个月以上”是否包括3个月,表现形式是否已经确定?

2,流程的分支结构以及分支处理情况是否考虑完全??

3,是否定义清楚与其他模块和产品的交互流程

4,是否考虑了新增功能点对原有功能的影响？

5,是否所有的系统输入已确定，包括其来源、准确性，取值范围和频率？ 9,所有的需求之间不互相冲突吗？

6,是否所有的系统输出已确定，包括其目的地、准确性，取值范围、频率和格式？

7,是否已确定所有的通信接口信息包括握手、错误检查、通讯协议、返回码的统一定义？

8,是否考虑了数据合法性校验的规定？

9,是否有说明系统非功能性外的其他要求?? 详细包括:操作系统支持??分辨率支持??其他软件版本(比如office,数据库)的支持??语言类别(简体,繁体,英文)的支持??

10,是否提供量化的性能指标 14,是否有系统失败和成功的定义

11,每项需求都可测试吗？每项需求是否能够独立得到验证？

12,从用户观点来看，是否考虑了操作的易用性和可用性？

（忘了在哪里看到的了， 加了点自己的想法）

copy from wonder 2006.05 日志

copy from wonder 2006.07 日志

目前的工作都是功能测试，每天就是不停的重复工作，最多进行业务上的扩展，如果光靠每天的工作， 很难再学习到更多的东西， 很想让自己的测试小组成员在测试这个领域上都能有长足的进步，当然也为了不断的提升自己， 所以想在小组里营造一种自我学习和互相分享的氛围， 不知道应该怎么样去开展？

目前的想法是每两周开一次分享会，但是分享的内容不知道怎么去确定，分享人又该怎么确定，如果不指定人员，大家一般不会主动请缨，很难有持续的过程；如果指定了人员，感觉就象是一种任务一样，不知道学习效果如何？ 另外关于分享的内容应该如何确定，现在也不太清楚，是应该1对多，即一个人学习之后，分享给每个人，还是多对多，即提供一篇文章，或者技术，由每个人去领悟，然后互相讨论呢？

因为没有这方面的经验，所以感觉很迷茫， 不知道大家在这些地方有些什么建议和经验可以分享和指点？？

 

Link URL: http://blog.csdn.net/wonder4203/archive/2006/11/30/1421548.aspx

当一个项目同时来了两个需求， 且要求提交时间不一致，应该如何进行版本控制？ 怎么保证充分利用人力的情况下， 同时进行两个需求的修改，但是先发布的一个需求不会包含没有测完的第二个需求的bug呢？ 目前我们的做法是： 1， 当两个需求都比较小，且需求不紧急的时候， 和客户沟通， 争取将两个需求都做完之后同时发布， 2， 当一个需求做的时间比较长， 而另外一个需求很小，甚至就是简单的debug一下，需要马上发布， 则在VSS上保留原始的code 目录 来做时间相对而言较长的项目， 然后开出一个上次发布版本的Code 分支， 做时间紧急的项目。这样就可以两边同时进行修改而互相不影响， 最后在发布大需求的时候将小需求的code合并回去，（ 这里还是会增加一些重复的工作量）。注意在发布大需求之前，需要一直保留小需求的code分支， 方便合并之前的修改。

copy from wonder 2006.09 日志

 刚刚提上日程的自动化测试， 又被拖了下来，从一开始，我大概就是知道这个结局的，因为我就经历过这样一段挣扎的过程。不过我还是把它提出来了，因为如果没有真正的使用过，有过这方面的经验，有过这样力不从心的感受， 你就不会那么深刻的体会到， 为什么我们组的测试工作还不能使用到自动化测试工具？ 为什么我们还要一直停留在最最基本的手动测试上面?

我现在大概知道了一些玲玲当时的想法， 因为我也真的很希望大家可以多学一些知识， 可能明知这些知识暂时还用不上， 但是还是要给大家一个激励，自己学习固然是好，有一个推动和激励会让我们更加有动力。

很多人觉得做测试工作， 如果只是停留在手动测试的基础上，就没有意义了， 就太简单了， 就没有技术含量了 然而目前国内的现状很多都是这样的，毕竟我们的公司还在起步阶段，系统没有稳定，测试流程还不够规范，项目逻辑非常复杂的同时，测试人员的整体技术水平还有待提高， 在这样的大前提下， 要推行自动化测试真的很难。往往在浪费了很多人力之后， 才发现那些脚本起到的作用几乎微不足道， 才发现使用这些工具如果不具备良好的编程能力，不对脚本进行维护， 很多的check点，我们真的力不从心， 才发现常常很多脚本还没有使用到就又要被迫进行修改，导致我们觉得自己象白痴一样做了好多无用功。。。这些都是我们的阻碍。但是我要恭喜你们的是，在这样的公司里， 你可以学到很多在流程规范的大公司里学习不到的东西： 你可以以体验到一个变化的过程， 你更能体会到每一个规范的形成原因以及使用它的好处， 你可以从如何找到一个合适自己公司自己项目的流程的过程中学习到经验，你更可以从中找到分析问题解决问题，在挣扎后破茧而出的乐趣，而这些东西都是很宝贵的。

copy from wonder 2006.10 日志