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

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

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

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

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

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

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

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

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

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

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

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

    刚经理来电话了说**功能有错误。一个星期前，经理问我，“软件错误多吗？”我很自信的回答：“没有”。

    这个错误只要把A数据除以B数据，然后乘以100%就能发现问题，这也是最基本的功能，而我却忽略。

    分析原因：

           1、当时感觉数据有点古怪，却没有深究（给自己的理由是都卖1年多了，如果有这种功能性错误，用户早

              发现了），当时深究一下，也就能发现问题。

           2、好好写测试用例，不然也发现了。

           3、没有好好看用户手册，不然也测试出来了即使没有写用例。

总结：测试之前按照用户手册好好写测试用例。遇到可疑处，不能给自己任何理由，也要把可疑处弄清楚。  

 懊悔中，希望大家也指点一二怎么避免漏测现象

    测“这个模块”的功能测试已经半年多了，开发那边开一个问题就出现另一个问题，缺陷数没有下降的趋势。我开始对缺陷进行分类（表现形式）：比如，悬空线类、文本框类、画布设置类等。我开始追个攻击，比如一个时间段，我只测“悬空线类”。就这个半年过去了。线再也不悬空，画布设置也不再出现错误了等。我再也没有像开始“测这个模块”那样的激情，我开始讨厌测这个模板，因为每个版本总是有一个让程序崩溃的缺陷。11月我测试了两天没有发现错误（针对我那些分类），也没有崩溃的现象。我提出结束测试。因为“这个模块”的效率比较低。没有发布出去。

    这是我来新公司测的第一个模块，就这样结束。我开始接受新的模块。

    又一个月过去了，快年底了已经是12月19号，软件要release，然后也包括我开始测的“这个模块”，这时它的效率也有所改进。于是我有开始测试“这个模块”，只是使用半个多小时就发现问题8个。当时差点晕倒。这个问题都是以前发现过的，然后改过的问题。而且大部分的缺陷我复现不了。

     这时大家都会在考虑为什么会出现这样的现象？我也希望同行能给我一些建议

     我个人认为，1、我对缺陷没有很好的管理。只是告诉开发有那些错误，不是很严重的自己没有记载。导致一个月后去测试，不知道怎么去测？

                  2、当开发修复缺陷后，我应该再整体的测试一遍，不应该放置在哪里没有测。（在11月份最后的测试只发现两个不是很重要的缺陷。我口头传达，就没有再管顺序图了）

                  3、我应该积极调整自己的。不应该对顺序图有厌烦的感觉。

    这是我第一次单独写测试用例。这个项目没有需求分析说明书，也没有其它的资料，有的只是一个需要测试的软件，哪怎么来写测试用例呢？

    开始我的做法是：1、把功能点列出来。

                    2、把个个功能点的测试点列出来。

                    3、一边操作一边写测试用例。

     这样的弊端：会丢掉很多重要的东西，而且很容易把界面测试和功能测试混在一起。因为是一边操作软件一边写测试点，操作软件时，动不动就出现对话框，写着写着就全部是对话框的测试点，当然最后写测试用例的时候发现全部都是对话框的测试用例，而且用例都差不多。看着自己的测试用例发现把最重要的功能全部丢了。开始只知道不对，这样的测试用例是不行的而且通过率很高，但不知错在什么地方总是感觉不对。后来在和一个朋友的聊天下，发现自己把把界面测试和功能测试混在一起了。

    在没有需求分析说明书和其它的资料的情况下，正确的做法是：

    1、先把软件的功能列出来就象功能树那样，然后对于每个功能写出相应的结果。让项目经理过目，看看功能是否写全，判断结果是否正确。

    2、弄清楚项目开发方式和周期，对测试时间进行把握。

    3、查看项目成本和销售对象，对质量衡量标准进行确定。因为每个地区对软件的要求不同，（一般情况下，中国对软件的要求质量比较低，只要功能实现了、一般不出现严重的错误；而欧美那些国家对软件质量要求就比较高，不仅仅是实现功能而且要有很好的界面、稳定性，易用性等等）而且成本越低，对项目质量的要求就越低。不要增加项目不必要的成本。测试软件不仅仅要从项目本身质量考虑，也要从成本上考虑。

       4、编写测试用例，确定是测试软件那方面的内容，是功能还是UI还是数据等等，根据测试计划和功能树编写测试用例，不要一边操作一边写测试用例。写测试用例首先把最基本的功能写好，再考虑其它的异常。这样做一是保证所有功能用正常运行，二是防止遗漏功能。

当这两者都很好时，不要忘记了打乱路径顺序再测试一遍

最后祝自己在测试的道路上越走越好。