1.      软件质量是测试人员和质量管理部的事，跟程序员没关系，程序员只负责缺陷发现后的修改，你觉得这句话对吗？为什么？ 

2.      软件的隐藏缺陷，你认为在发布前修改好，还是先发布让用户使用，等用户发现了再修改好呢？ 

3.      你觉得我们现在的产品质量如果？□    不错  □有少量缺陷，在用户允许范围内 □ 缺陷不少，但维护起来较为容易 

□不理想，维护人员经常“救火”，维护难度大，客户经常抱怨

4.      对我们的软件质量提高你有什么好的建议吗？ 

5.      你觉得规范开发规范测试只是留于形式耽误开发周期，对整个项目开发并无好处吗？ 

6.      单元测试是什么？单元测试主要测试哪些内容？ 

7.      你认为做单元测试是浪费的时间阻碍系统集成进度吗？并简述你的经验 

8.      你觉得单元测试是验证代码是做什么的还是验证代码是能做到应该能做的什么不能做到应该做的什么？ 

9.      你自信这段程序不会有问题，你会跳过单元测试吗？你是个很棒的程序员，你是否就觉得你没有在单元测试上浪费时间了呢？ 

10.  有集成测试、系统测试，单元测试是否就可以省略？ 

11.  你觉得系统测试由项目组开发人员测试就可以达到测试效果吗？

对于报表测试看了很多同行的文章，我想提一点个人的看法

报表测试主要分为：报表界面测试、报表安全性、报表准确性、报表展示速度（也就是性能）。

不调胃口，从重点开始，数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。

从整个项目节约成本看，逐层测试效果是最好的。完全修改率也是最高的。首先建立测试数据模型，模拟所有应用表，建立简单易跟踪的数据用例，底层的数据表测试，方法很原始，嘿嘿，通过SQL语句和手工计算，对数据进行比对。对系统中的报表数据准确性测试方法较为灵活，①系统中报表重叠的进行比对②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对，③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。呵呵，这要看测试人员的需求了解深度个人能力了。插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？J接着说④使用SQL和手工计算进行比对。以上是差错方式，接下来讲一下查什么错？哪些地方容易出错

Ø        原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。

Ø        数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。

Ø        数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。

Ø        数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

Ø        由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了if else,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。

Ø        最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。

我现在想到的只有这些（有待补充）

报表的界面和输入输出测试

界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。输入界面要求是：①输入项字段长度不允许超过字段长度；②输入不符合字段要求的，不允许查询。如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。③用户 权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。

④对于选项，应不出现可选择的用户权限以外的选项。⑤对于汉字模糊查询，考虑不常见字，如“”即汉字因译码问题，造成的汉字存储出现乱码问题。

输出界面要求：①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据，不能因为打印缺少了报表表格框②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序③报表标题明确，不能含糊误导用户④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。

报表性能测试

这块主要使用自动化测试工具来测试，具体工具如何测试，不详细说明了，只说一下测试点：

Ø        并发查询，测试系统一个报表同时允许多少用户并发查询，并发查询报表平均展现的时间

Ø        一定量用户在线，报表平均展现时间

怎么觉得我这个文档头重脚轻，虎头蛇尾，这个测试主要针对报表数据准确这一重点，所以其他测试只是简略说明。

嘿嘿，大家看一下专家的看法吧！

由于人们对于软件质量的重视程度越来越高，就导致了测试在软件开发中的地位越来越重要。是的，测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。在这一趋势的引导下，现在很多软件相关的公司都非常重视对于他们所开发的软件的测试，甚至不惜花费巨资购买商用的测试工具，但是效果却不一定理想。究其原因主要是存在着对于软件测试的诸多误解。本文试图对一些比较普遍的关于测试的误解进行剖析，并且在测试对于软件产品质量可能带来的更深远的影响方面，也进行了论述。

引言

测试在软件开发过程中一直都是备受关注的，即使在传统的软件工程中，也有一个明确、独立的测试阶段。随着软件危机的频频出现以及人们对于软件本质的进一步认识，测试的地位得到了前所未有的提高。测试已经不仅仅局限于软件开发中的一个阶段，它已经开始贯穿于整个软件开发过程，人们已经开始认识到：测试开始的时间越早，测试执行的越频繁，所带来的整个软件开发成本的下降就会越多。Extreme Programming更是把测试推到了极限的位置，一切软件开发活动都要从首先编写测试代码开始。

但是，相对于测试这个词的流行程度而言，有关测试教育方面的工作做的还远远不够，很多关于测试的文章都是针对某种测试工具使用方面的，而测试工具厂商也往往出于商业的目的对于测试工具的作用夸大其词。这样，很多的软件从业者就很容易陷入一些误区，导致了测试并没有在他们所在的软件开发项目中起到有效的作用。下面几个小节将对于一些比较具有代表性的误区进行剖析，并对于测试背后所蕴含的一些设计思考进行了阐述，希望能够起到抛砖引玉的作用。

误区之一：使用了测试工具，就是进行了有效的测试

这个误区可以说是一种通病，几乎每一个领域中的CASE工具刚刚出现时都会带来这个问题，比如：如果一个软件开发团队在软件的开发中使用了Rational Rose工具来进行UML图的绘制，他们可能就会声称他们采用了面向对象的方法，也不管他们的设计和代码实际上是多么的过程化。

在测试领域中也一样如此，一个软件开发团队往往认为只要自己使用了某种软件测试工具，那么就应该可以获取测试带来的种种好处，这种想法当然是错误的。因为，要想对一个软件或者模块进行有效的测试，首先该软件或者模块应该是可测试的。可测试性是反映软件质量的一个内在属性，不会因为你使用了某种测试工具进行了测试行为，就使得被测试的软件具有了可测试性。如果被测试的软件本身并不具备可测试性，那么使用多么昂贵的测试工具进行测试所能够带来的收益都是微乎其微的。

巧的是，可测试性和好的软件品质的其他方面有天然的关联，一个具有可测试性的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不可测试的软件往往具有过强的耦合和混乱的逻辑。关于可测试性方面更多的内容不在本文的论述范围，请自行参见相关的文献（本文所附的参考文献中有关于可测试性的更深入的信息）。

要想真正获取测试带来的巨大好处，并且使得测试工具能够发挥最大的效率，关键就是要使软件本身具有很好的可测试性。这种能力的获取是一个逐步的过程，是不可能一蹴而就的。最关键的一点就是要不断实践，不断学习一些优秀的经验，不断的反思。要想获取好的结果，就必须要付出努力，这是亘古不变的真理。Extreme Programming中的测试先行的实践倒是一个很好的起点，具体可以参见参考文献[3]。

对于测试工具的选择，只要满足需要并能够自动运行测试用例就可以了。不要一味的追求复杂的功能和不必要的灵活性。对于大多数项目来说，一些非常著名的源码开放的测试工具就足够了，比如：Java方面的单元测试工具JUnit和C++方面的单元测试工具CppUnit。关于验收测试方面，目前没有比较好的满足各方面需要通用的测试工具，不过使用脚本语言，循序渐进的自行开发一个适合自己的验收测试工具也不是一件困难的事情，一句话：只有提高了自身团队内在的素质，外在的工具才能够发挥作用。

误区之二：存在太多的无法测试的东西

在软件开发领域，确实存在一些东西看起来要比另外一些东西难测试一些，但是远非无法测试。并且在大多数的情况下，还是由于被测试的软件本身在设计时没有考虑到可测试性的问题。只不过这种不可测试性不是由于被测试的软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧，从而表现出被测试的软件本身很难测试。这些很难测试的部分比较常见的有：图形界面、硬件、数据库等。下面以图形界面为例进行说明。

如果一个软件模块必须要通过图形界面才能够触发它的应用逻辑时，那么要对这个软件模块进行测试时就必须要使用图形界面。但是图形界面又是很难测试的。看起来好像很难办。让我们换一个角度考虑一下，其实我们真正想要测试的是软件模块本身的应用逻辑，而不是图形界面的触发逻辑。如果我们在设计时能够把被测试的软件模块本身进行很好的封装，定义良好的服务提供接口，那么我们就完全可以通过软件模块本身提供的接口进行测试。这样就可以绕过难以测试的图形界面。造成上述软件模块很难测试的原因正是由于在设计时把软件模块本身的应用逻辑和图形界面这两个无关的逻辑耦合在了一起。把这两个逻辑分离，不仅可以对该软件模块进行更容易、更有效的测试，而且也使得该软件模块具有了很好的可重用性和可移植性。

那么对于不好测试的图形界面，我们该怎么办呢？原则很简单，如果某种东西不好测试，那么就让它做肯定不会出错的事情，而把可能会出错的逻辑剥离出来，放到一个可以测试的模块中。对于图形界面来说，就是仅仅保持一个很薄的图形界面逻辑，它的工作就是把用户的请求简单的转发给真正处理该请求的软件模块（一般称之为Application Facade）。转发逻辑足够简单以至于它肯定不会出错，所以我们也无需对它进行测试。关于这方面更多的信息，请参见参考文献[5]。

如果在进行软件开发时能够首先编写测试代码，那么就会迫使你从易使用性，易测试性的角度开考虑问题，从而你就会专注于软件模块的高层抽象和职责。这样就会定义出清晰的、明确反映意图的模块接口来，另外，为了使得测试能够进行，你就会主动把那些导致不好测试的耦合去掉。这样的结果不仅仅是获得了可测试性，并且也产生了更好的设计和系统架构。

但是确实存在一些不好测试的东西并且很难只让它执行一些非常简单的逻辑，比如嵌入式系统中的BSP（板级支持包）。开发它们所使用的语言、环境以及它们本身的特性等决定了它们是很难测试的。这里说的难测试其实是一个测试代价问题，具体的说就是要付出更多的时间和努力。这就需要你在付出的代价和测试带来的收益之间进行平衡。如果付出的代价所带来的收益（更少的调试、维护、发布成本）是巨大的，那么付出的代价就是非常值得的。

误区之三：测试代码可以随意写

大家肯定知道测试代码是不能随意编写的，并且在编写测试代码时也不是抱着一种随意的态度，但是你编写出来的测试代码以及测试代码运行的情况却表现出了一种随意性和无序性。因为你可能并没有弄清楚测试的真正意图所在。

本人曾经看到过有关验收测试的这样一个案例，验收测试者使用昂贵的商用测试工具对一个具有图形界面的软件进行测试。测试的方法是通过编写测试脚本驱动鼠标在图形界面上随机的点击（当然每一次的点击，都点到了图形界面上可以接收事件的区域），然后等待着被测试软件的崩溃。当然这种测试方法可以作为验收测试的一个方面，但是决不是唯一的一个方面。还有更重要的内容被忽视了。

测试的目的是用来检验软件系统是否满足了需求。所以，你的测试代码一定要明确的表达出这一点来。就那上面的案例来说，如果测试者真正从用户的需求出发，那么他写出来的测试脚本肯定不会是那样的，而因该是每一个测试用例都清晰的刻画了一项用户的需求，然后检验系统是否实现了用户期望的功能。这样的测试才是有明确目的，才是最有效的测试。和把界面逻辑和应用逻辑隔离，采用明确表现用户需求测试用例进行测试相比，上面的测试方法不能不说是随意了一点。

在针对类进行的单元测试中，也经常会看到一些错误的测试方法。很多的测试者往往针对类中的每个特定的实现细节进行测试。类中的特定的实现细节是很容易变化的，在快速的迭代式开发中更是如此。一旦你测试的类中的某个实现细节发生了变化，你原先的测试代码就要进行相应的更改，否则就失去了意义。这种频繁更改的代价是巨大的。类是一种抽象，它反映了更高层面的内聚性，它应该有明确的职责和定义良好的服务接口，它的职责和对外的接口相对于内部的实现细节来说要稳定的多，并且我们要验证的正是这个类是否具备了它的职责。因此，在对类进测试时，我们应该针对类的接口来验证类是否实现了它的职责而不是其他。这样写出来的测试代码要稳定的多，也有效的多。

细想一下，造成容易陷入针对实现细节测试的原因主要是由于先实现了类，然后才去进行测试。如果先实现了类的功能，然后在去对类进行测试，潜意识中就会不由自主的想去验证已经完成的类的某种实现细节。如果能够在编写实际类前，首先编写针对该类的测试代码，情况就会有很大的不同，因为这会迫使你从类的使用者的角度去考虑问题。结果就是会把关注点放在类的易用性上，放在类的职责上面，放在类提供服务的接口上面，而不是某种实现细节。

总之，测试代码的编写应该从被测试的对象是否满足需要的层面进行，而不是其他。

误区之四：单元测试和验收测试没有什么区别

和误解之三一样，可能很多人并不承认这一点。但是他们却又不能比较清楚的说出二者的差别来。这样，在他们进行测试代码的编写时就会比较迷茫。本小节结试图给出一些区分单元测试和验收测试的一些原则来。

我们还以经常用来和软件进行类比的建筑为例，首先给大家一个感性的认识。单元测试可以类比为一个建筑的质检人员对建筑进行的检测， 他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等。他的检测是要保证建筑的各个部分是正常的、安全的，换句话说，就是要保证施工满足建筑上面的质量标准。验收测试可以类比为建筑的使用者来对建筑进行的检测。首先，他认为这个建筑是满足规定的工程质量的，这是有建筑的质检人员来保证的。使用者关注的重点是住在这个建筑的中的感受。他关心建筑的外观是否美观、各个房间的大小是否合适，窗户的位置是否合适，是否能够满足家庭的需要等。这里，建筑的使用者执行的就是验收测试，他是从用户的角度出发的。建筑的质检人员执行的就是单元测试，他是从构建者的角度出发的。

正是这种角度的不同决定了单元测试和验收测试之间的区别。它们是对系统的不同的方面进行的测试，二者是互相补充的。不管我们在系统的构建中使用了多么聪明的方法，不管我们的系统是多么的灵活，但是首先我们的产品必须是可用的，否则我们所做的就是浪费时间，从这一点上来说验收测试要比单元测试显得更加重要。

还以上一小节给出的案例为例，案例中所使用的测试方法仅仅是从系统是否健壮的角度出发进行的，即使系统从不崩溃也不能证明那是一个可用的系统。因为测试根本就不是从用户使用的角度出发的，测试者本应该和用户一起来编写验收测试。单元测试保证我们把事情作对，而验收测试则保证我们做正确的事情。

关于单元测试和验收测试之间的明确划分，没有一个通用的标准，只有通过自己的不断实践来增加这方面的经验。你进行的有关测试的实践越多，你就会越清晰的感觉到单元测试和验收测试之间的界限所在。下面给出一些指导原则，在你编写测试代码时可能会有帮助。

• 如果一个单元测试要跨越类的边界，那么它可能应该是一个验收测试
• 如果一个单元测试变的非常复杂，那么它可能应该是一个验收测试
• 如果一个单元测试经常要随着用户需求的变化而改变，那么它可能应该是一个验收测试
• 如果一个单元测试比它要测试的代码本身要难以编写，那么它可能应该是一个验收测试

结论

测试是用来保证软件开发过程的高效性，以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一件非常困难的事情，这也决定了有效的测试决不是简单的依靠一些测试工具就可以进行的。在使用工具的同时，我们更要加强关于测试的培训、教育，使大家对于测试首先有一个正确的认识。只有这样，我们才能够更加有效、高效的使用工具，才能够使测试真正起到它应有的作用。希望本文能够对大家在进行测试方面的工作时有所帮助。

参考资料

• Extreme Programming Explained: Embrace Change，Kent Beck，1999
• Agile Software Development, Principles, Patterns, and Practices，Robert C. Martin，2002
• Test Driven Development: By Example ，Kent Beck， 2002
• Refactoring: Improving the Design of Existing Code，Martin Fowler, Kent Beck，1999
• Testing Things That Seem Hard to Test，Robert S. Koss ，2001

   TestDirector：MI公司的缺陷管理工具，优点是：B/S构架模式；Windows平台；.可以定制流程；可以定制查询；可以定制功能域；可以定制用户角色，可以定制角色权限；可Email通知；可以生产各种报表；支持多种数据库；可以与其他MI公司测试工具集成；安装配置较为简单，有可优化的工作流，可使用C改进优化系统。 缺点是：价格太贵（呵呵，死结）；除与微软的Access接口比较好，其他数据库接口不是太完善；没有中文版（虽然有破解汉化版），缺少角色可视窗口配置，版本更新，但功能没有改进。

   Mantis：优点，开源，不收费，B/S构架模式；Windows平台；可邮件通知，操作较为灵活。缺点：安装配置复杂，不收费的东西，界面也不够美观，有很多功能根本只是架子，没法真正使用，比如说添加附件。

   BugFree:：这款缺陷管理工具跟Mantis一样开源的，缺点优点也跟Mantis相近。

QAMonitor：这个工具很小巧，优点是操作简单，直观，对只有几个人的开发测试团队内部测试用很适合，并且是中文的。缺点是：基于C/S结构，项目配置需要到底层数据库中去配置，缺少项目定制客户界面，因为适合内部测试，所以没有全面的报表分析，没有Email通知。

Bugzero：安装配置比较复杂，需要单独安装java和tomcat。B/s 版本，价格还可以，国产软件，试用版是英文版，并且页面出现乱码，通过在线试用，流程不太清晰，界面不够客户（测试人员的职业病对每个软件的使用都已发现缺陷为目标）。

迅捷缺陷跟踪系统：安装配置简单，中文使用方便，流程控制较清晰，缺少邮件通知功能，缺陷参数少，界面粗糙，没有独立可管理的数据库。

第一个问题：2003的ISS是手工启动的。启动后，不显示td的初始界面，但在其他机器上，通过网络浏览没有问题。

解决方法.修改win2003的IIS的TDBIN的属性， 开始－管理工具－Internet信息服务(IIS)管理器中，本地计算机-网站-默认网站-TDBIN，右键菜单 属性-HTTP头à【MIME类型】，点【新建】按钮，填扩展名为ini，MIME类型为text/*，继续新建扩展名分别为：lld、dll、ocx、xco、exe、adt、adm、xxx，MIME类型都填为text/*。

第二个问题：安装过程中，提示用户名密码错误，无法进行下面安装，原因数据执行保护DEP不允许该程序执行。解决方法：右击“我的电脑”选择“属性”à性能【设置】à数据执行保护，选择选项：为除下列选定程序之外的所有程序和服务启动DEP（U），点击【添加】按钮，找到TD安装程序中的bin目录下：checku.exe,添加上即可。

第三个问题：安装程序完成，登陆时出现“The RPC server is unavailable”，The RPC server is unavailable.翻译过来就是“RPC（远程过程调用）服务不可行。”它指的是“权限不够”的意思。导致这个错误的原因有很多

1. RPC服务未启动。解决：控制面板-管理工具-服务-“Remote Procedure Call(RPC)”，启动一下（自动），服务状态“启动”；

2. 本身操作系统有问题缺少远程过程调用补丁。解决：更新操作系统。

3.服务器端IIS没装。解决：安装IIS。以2000系统为例，控制面板-添加删除程序-添加删除windows组件-“Internet 信息服务(IIS)”打一下勾，下一步……

4.TD服务未启动。此种情况比较复杂，需要尝试不同的解决方案，先到TD所在的那台机器上，点右键的testdirector checker，看看出错提示，对症下药。

以下几种可以结合起来尝试：

Ø        启动一下TD。到TD所在的那台电脑上，在系统栏右边有个小图标，鼠标移上去，点右键“Start TestDirector”；

Ø        清空IE的cookies、History、缓存；删掉TD2000_80目录，重新下载一次插件；

Ø        把 http://IP/tdbin/start_a.htm 改为 http://计算机名/tdbin/start_a.htm

Ø        TD服务器装了多个版本的TD，兼容性问题；请卸载其中一个版本，重装TD；

第四个问题：MSIE7.0无法访问testdirector8.0，提示：“Microsoft Internet Explorer : 4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR.3.0.04131.06) is not supported”。原因：testdirector8.0不支持MSIE7.0的问题，解决：　在安装目录一般为C:\Inetpub\TDBIN下找到Start_a.htm文件，用记事本打开，即看到了文件源代码，找到fMSIE3456参数，修改在|| (ua.lastIndexOf('MSIE 6.0') != -1)后黏贴|| (ua.lastIndexOf('MSIE 7.0') != -1)，保持即可。打开IE7.0再次访问，下载插件，安装插件，没有问题了。

2007-7——现在  组织机构代码数据仓库

该项目隶属于山东省质量技术监督局，主要用利用山东省的组织机构的信息，对山东经济的发展，以及经济预测、业务工作趋势预测。

¨         参与与北京中科院的博士针对该项目的具体情况建立数据仓库的技术交流会。

¨         熟悉了解数据仓库知识，了解数据仓库工作流程，并对数据仓库测试点的挖掘，参与项目组对该项目的需求分析，对在每个确立的需求测试计划及测试着重注意点做详细记录。

¨         该项目使用数据库为DB2，虽以前培训学习过该数据库使用，但因为时间长了忘记了一些，找到笔记复习。

2007-6 —— 2007-7  食品标签服务平台

该平台隶属于山东省标准化研究院，该平台主要用于加强对食品企业的管理，该平台主要分为三个部分：后台管理、前台交互、食品社区。

¨         分析测试需求；制定测试计划；

¨         配置安装测试工具

¨         编写测试用例；执行测试（手工测试，工具测试：Xenu、My Browers）；缺陷跟踪管理（使用TD）

¨         分析整理测试报告

注：该项目客户不要求做性能测试和压力测试。该系统的收获是认识并使用了cookie测试工具My Browers；第一次测试社区。

2007-5——2007-6   中国名牌产品博览交易会

¨         分析测试需求；

¨         配置Test Director项目；

¨         编写测试计划、测试用例；执行测试；使用Test Director对软件缺陷进行跟踪管理；编写测试分析报告

¨         项目验收后追加功能的测试：追加功能简要测试计划、测试用例编写，Test Director中版本管理跟踪缺陷。（公司使用需求报告/修改单详细记录功能需求，备注，测试人员）

2007-1——2007-5   山东法人信息库

该项目是一个面向决策支持的应用系统，主要包括基于部门业务系统、数据交换平台、数据中心数据库管理和统一应用展示的系统。通过该项目实现于无缝集成当前山东省工商、国税、地税、质检、人民银行等部门的业务系统，并能无缝集成将来要加入的政府部门。

¨         参与项目需求分析

¨         分析测试需求；制定测试计划；

¨         编写测试用例；执行测试；跟踪管理缺陷（TD）;

¨         编写测试报告

注：该项目初期考虑过数据安全测试，但后来客户提出该数据使用专线专网，不需考虑其传输安全。只考虑了数据传输的完整性与传输断点问题。

2006-10——2007-1全国组织机构代码档案采集系统、全国组织机构代码档案查询系统（B/S）

¨         参与项目需求分析

¨         根据需求编写测试计划

¨         测试用例编写；执行测试；缺陷跟踪管理（TD）；

¨         编写测试报告，参与项目验收。

¨         系统用户培训（独立完成三期山东省17地市使用培训）。

¨         项目实施以及项目的技术支持工作。

注：在这个项目测试过程还有一些附带软件测试：电子档案存储分区管理、电子档案上报服务。后期的技术支持转交他人。

2006-8——2006-10  网络实名系统

该系统是收费的网上确认机构信息的实名系统。测试重点搜索引擎测试、网络链接测试、收费测试。

¨         根据需求制订测试计划

¨         编写测试用例

¨         根据该测试性质使用了自动化功能测试工具QuickTest Professional对搜索引擎进行大量测试，减少了重复劳动，加快了项目进程。根据该系统链接多特点，使用了链接测试工具Xenu，并对死链接进行分析。

¨         对收费功能进行了安全测试

¨         跟踪管理缺陷（TD）

¨         编写测试报告

2006-1——2006-7  组织机构代码管理系统（B/S）

根据公司测试管理空白；编制了公司测试文档模板；制定了测试管理流程；通过vss对文档实施更新管理，使用Test Director对缺陷跟踪管理；安装测试工具Test Director、QuickTest Professional、Winrunner 、loadrunner。

¨         根据项目需求制订测试计划以及性能测试方案

¨         编写测试用例

¨         指导其他测试员使用测试工具

¨         执行测试：使用功能测试工具QuickTest Professional对部分功能进行测试，使用性能测试工具LoadRunner进行性能及压力测试。

¨         跟踪管理缺陷（TD）

¨         编写测试报告

¨         系统用户培训

¨         系统实施（与客户配合完成三个地市该系统实施工作）

其实麻烦的只是个过程挺。我改完了以后就想，总的来说就是一个tdclientui80.ocx文件。同行们有需要的小龙虾免费提供，可是不能保证你会喜欢我改的这字体。希望下一版能在界面上能自动修改。

一下就是是修改完文件后的个覆盖步骤：

将文件的后缀改成相应的文件然后覆盖下面两个目录下的相应文件即可

C:\Inetpub\TDBIN\Install目录下tdclientui80. xco

C:\Program Files\Common Files\Mercury Interactive\TD2000_80目录下的tdclientui80.ocx

以上是服务器端的操作。

下面是客户端的操作：删除插件安装，重新下载安装插件即可。

很久没有学习数据库了，想看本书呢，在找书的时候发现了这篇文章。感觉这个方法不错。

为了能清楚地表述，首先假设存在一个产品信息表Products，其表结构如下：

CREATE TABLE Products (
ProductID int,
ProductName nvarchar (40),
Unit char(2),
UnitPrice money
)

表中的数据如下：