2009年4月23日 我的第一个独立项目是这样进行的

测试下一个星期进入第二个阶段，现在把第一个阶段总结一下。

    项目写了测试计划和测试大纲。测试用例写了一点点，后来就没有写了，嫌麻烦。BUG的跟踪和管理开始很认真的执行，后来也就。。。。

    我自己写测试计划的目的：1、对软件有一个整体的规划，能好好的把握一下整个软件的状态；2、锻炼一下自己（这是我自己第一个独立的项目）。实际上，做项目时有很多无法预测的问题，使得项目不能按照进度走的。虽然进度安排上有风险预测，但是很多时候是预测不到的，特别是我这个项目，如果技术支持把板子拿走，有时一出差就是一个星期。而且每个板子都有自己的特性。自己对某些知识的理解也是无法预测的，本来认为自己掌握了，其实操作起来，却很费时间。心得，如果能从需求分析开始跟项目，就从需求开始接触项目。这样对软件理解度要高，而且对项目的亲合力比较好，说白了就是对软件的感觉比较好。我的项目是卖了一年以后我才接触的。

    写测试大纲的目的：怕自己漏测功能或测试点，而且看测试大纲写测试用例，思路是很清晰的。建议写测试大纲。我写了测试大纲，作用的有的，但是由于没有组织好，后来的测试用例也就是乱乱的，在改进中。

    测试用例：如果写的话感觉很费时间，而且很烦。但是等到项目进行一大半时，发现没有测试用例也是比较累的。特别是项目的路径比较多。当回归测试时，比较累。对软件进行缺陷分析或是其他的都是很麻烦的事情。所以有测试用例是最好的。

    回归测试：如果软件功能比较简单，路径比较少，回归测试时，不要用测试工具，自己手工把软件测试一次，就像第一次测试接触这个软件一样，最好是用不同的方法和思路。

BUG的跟踪和管理，是这次项目第一个阶段的收获。

    开始测试，也就是和大家一样，对话框的测试，功能是否正常运行（这个是肯定能正常运行的，因为卖了1年），就是当用户使用非法数据时能引导用户输入正确的数据。然后是界面的测试。这些都好记录缺陷的，而且也是很好写测试用例的。

    接下来是针对每个功能进行测试，也是界面，但不是纯粹的界面测试。当修改代码，配置数据，看看功能的界面是否发生异常的情况。这个 测试用例想的出来，但是描述起来很麻烦，对缺陷的描述也是一样的。没有使用缺陷管理工具，即没有对缺陷进行管理

    优点：项目进度快。测试者状态会比较好。因为没有很多麻烦的事情。只要把一天的缺陷记录在纸上，找个时间给开发演示一边，就行了，基本上开发当天就能解决。描述一个缺陷要5分钟还不一定描述得清楚，牵扯的前提条件（运行环境）比较复杂，我演示5个也就8分钟左右。

    缺点：1、当验证这些错误时，很不情愿去验证（人是有惰性的，如果使用了缺陷管理工具，因为要去关闭缺陷的，所以会好好的验证。自己记录在纸上是没有人管的，就靠自己的敬业精神了）。2、如果版本与版本之间的间隔比较长，很多时候就忘记了当时的环境。而且找相同类型的缺陷，很难找。再者也不好。3、验证缺陷困难，滋长开发的惰性。开发也有惰性的时候，如果没有使用管理工具，他不一会及时改，他改了那些缺陷，测试者是不知道的，所以验证的时候很困难的，要把所有的缺陷验证一次。

    总结：从现在的版本开始我很好的使用缺陷管理工具，虽然描述缺陷很麻烦，但是比起以后的麻烦，那描述缺陷就不是麻烦了。测试用例和测试大纲用休息的时间好好修改修改。测试的书籍还是要多看看。编程还是要会的。英语也是要的。数据库也是要学的，计算机相关的体系知识必需是要调节的。不知道的东西太多了。