开发测试总结

两年前五月份写的，两年后翻出来看看，别有一番滋味~ 如今这些问题依然存在，这也是我离开的原因~

 

 

我们目前的测试环境搭建的方式是：

    测试库服务器+应用程序服务器，也就是测试库部署在一台机子上，应用程序部署在另外一台机子上。测试的帐号权限的分配也是根据业务的需要进行创建与分配。

    先说数据库：目前为止的10个版本，10个版本的测试库都是从开发库直接导到测试库做测试的，一方面可以节省测试库部署的时间，不用花时间去比对各个数据库模式，另一方面跟每次版本跟进的进度安排有关，所以大家都有这样一种态度，能省事的越简单的方式解决问题就是最优的。不然开发完毕，花大量的时间在测试环境的部署上，有点得不偿失。大家都希望能尽快投入到测试中去，赶进度。这主要来自各个方面的压力，在不断的催促声中，我们走过来10个版本。【想想挺不可思议的，客户似乎也能习惯了我们不断的错误，也能容忍我们在界面上弹出各种各样的异常或者不正确的提示信息，而这些异常以及不正确的提示对于我们开发人员来说，我觉得是很大的耻辱。】发布的时候，才进行各个数据库模式的比对，生成脚本等方式更新到正式运行环境中，所以才出现发布的时候，要花大把大把的时间整理脚本，部署脚本。

 

    再说应用程序，这两次测试应用程序的部署的时候还出现一种状况就是：应用程序的代码没有完全编译的情况。因为对测试人员来说，应用程序的部署是透明的，只管测试就好，根本不会去留意类有没有编译的情况。后来是因为觉得很纳闷，我在本地运行的好好的程序，为什么到测试环境中就不行了呢？是库没有部署好？还是？带着这个疑问，去测试机上看到后台报的异常才发现，很多类都没有完整编译。还有就是应用程序是直接跑在IDE里的，这样对吗？

    还有一些特殊的界面，如拍照界面，每次都会忘记替换成正式用的，导致测试的时候都没问题，发布的时候没有替换成客户端用的，导致出错。

 

    最后是测试帐号的分配上，目前一般是一个产品一个帐号，而这个帐号，可能多个人都在测，也就是说不同的测试人员，就用一个帐号测的情况比较普遍。一方面是测试时间有限，测试人员也有限。一个测试人员，用一个产品的帐号，把所有的功能模块都走一遍，基本上测试时间已经结束。根本没时间，去测试多种情况。

 

    就以上情况大略总结下目前慧运通测试的现状：

    1.开发库直接导到测试库做测试。

    2.应用程序是跑在IDE里的。

    3.测试用的帐号一般一个产品只用到一个，而这一个帐号，也可能是多个人都在测。

    4.测试用例没有能够随着版本及时更新，而目前的测试用例还无法满足集成测试的需要。

 

    一开始，并没有发现这样子有什么不对，但是随着正式环境中客户或者客服提到的一些越来越匪夷所思的问题来看，弊端还是有的。

    1.比如这周的检测区域控制，越来越多检测数据上传上来提示是：车籍地超出范围。明明是晋安区的车，为什么不能在晋安区检测？怎么会有这样的提示呢？测试过这部分模块的人，也觉得奇怪，测试的时候都可以啊！查看检测区域控制表，一开始也并没有发现有什么问题，在晋安区允许检测的地方，明明配置这晋安区呀？这是怎么回事？ 一看代码才知道，一开始是用车籍地来控制的，后来需求改成用管理机构来控制。而管理机构与车籍地在库里代码的差异是有没有在末尾加上00.如35010100与350101.正式库中的配置是旧的也就是车籍地的配置，在版本更新的时候，没有更新到这张表。因为对除了PLATFORM中的一些表外，对其他数据库模式中的表，只进行表结构比对更新，并没有进行数据上的更新【因为关系到正式的业务数据，只能做表结构更新，除非有一些表是特例，用来配置一些信息的，如检测区域控制表】。开发库与正式库中的这张表，数据上不一致。

    2.还有就是3月份就已经更新的：该车上次二维还没签章，不能打印出厂合格证！也是配置在TGBASE里的某张配置表里的，到5月份才发现正式库没有，而出现一些车第二次去签章了，才发现第一次没有签。签章人员发现有两笔没有签章的数据。

    3.为什么有的功能有的企业可以正常使用，而有的企业不能正常使用？

 

    出现这种情况的原因可能有以下三种：

    1).开发库直接导到测试库做测试，开发库里的一些数据开发人员通过新需求做了修改。测试的时候不会发现这个问题，也就是没办法把出现上面的情况规避在测试阶段了。

    2).部署的人和开发新需求的不是同一个人，导致部署人员可能不完全知晓哪些是配置信息要更新到正式库里。

    3).测试的时候，可能只测了一家企业。

    

    针对慧运通测试的现状，以及出现的情况，对以后版本的测试我想提出以下的建议：

    1).从正式库导一份到测试库，然后将测试库与开发库做比对，比对完更新脚本。对于非PLATFORM中的数据更新，开发人员要及时记录，然后与部署人员沟通。这样做，也导致了测试库的部署与正式库部署一样，需要花比较长的时间。

    2).我觉得应用程序不应该直接跑在IDE里，而应该是像发布的时候一样，用程序包的形式直接发布在WEB服务器下的。也就是说，我的想法是，测试环境尽量地能模拟真实环境。因为IDE在不同机子上，因为配置的不同，而导致编译的情况不同，还是有的。

    3).测试帐号的分配上，这个需要一定的智慧。因为，目前是多产品，也就是说有多个企业，目前货运的有上百家，维修的也差不多。我们不可能一个一个企业测试过去，但是如果不一个一个测试过去，又怎么知道没有错呢？这个测试帐号的分配上，需要大家一起来探讨。

      我的想法是：每一种产品，至少分配两个帐号，每个测试人员用不同的帐号做测试。

                  比如维修企业，至少测试两个产品，一个产品一个测试人员测试。也就是说每个测试人员测试的是不同的企业。货运也类似。

                  还有就是行政端，因为现在分维修的行政端与货运的行政端，每个行政端，行政区域都是一样，大体都有市处及五区八县的。每个帐号，尽量做到都走一遍。

 

      这样做，在分配帐号上，是要下点功夫的。

 

    4.关于测试用例，更没有时间去处理了。每次分配一天左右的时间写，说实话，只能是应付。下周一开始写测试用例，也是用一天。能否写完，还要打个问号？把原先交通局的行政端移植过来，那么多模块，从零开始写，就够写一两天了。不要说写其他的了。而实际上，都目前为止，测试用例的作用并没有很明显显现出来。我们做测试的时候，一般也很少按测试用例走，但是为了应付文档，还是要敷衍下，这个是实情。

      目前这种情况测试用例有点像鸡肋，食之无味弃之可惜的感觉。我没办法拿捏它的轻重，觉得，如果真的要赶进度，可以暂时先放一放。如果不赶进度，那就写吧。