图
遇到问题耐心自己需找方法，不要一上来就在网上找答案，这样解决问题容易知道其原理
---
gx020104010031@sina.com 问题
看了你的blog后，觉得你对测试工作有很深的理解与经验，也能够感觉到你的公司对测试很重视。我想有时间跟你探讨一下关于测试的理解，我刚工作一年。但是 我们公司对测试一点都不重视。目前，我对测试工具td，loadrunner等的使用都是自学的。感觉力不从心。希望你能够给我些意见与指导。谢谢！！
我的意见是，不要把工作看的那么简单，善于扑捉机会来锻炼工作能力，工作能力需要工作机会才能学到东西，只是闷头学，学的太肤浅，成长需要环境，环境可以培养。
-----
谢春刚  xiechungang@163.com 问题软件源代码安全测试
你写的真好啊呵呵　　我呢是做软件源代码安全自动化测试工具的，从你这里学了很多呵呵　　！
嘿嘿，相互学习吧
给大家推荐一个资源共享站，搞技术的需要的是共享精神，大家一起共享才能一起成长
http://zh.wikipedia.org/w/index.php?title=%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95&variant=zh-cn
------
还有很多朋友希望得到td工具的汉化包，我工作忙，没来得及发给大家，其实汉化很简单，就是替代一下C:\Program Files\Common Files\Mercury Interactive\TD2000_80的tdclientui80.ocx，这个文件网上到处都有，搜一下吧，自己做需要脱皮工具

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
)

表中的数据如下：

产品Chang和Tofu的记录在产品信息表中存在重复。现在要删除这些重复的记录，只保留其中的一条。步骤如下：

第一、    建立一张具有相同结构的临时表

CREATE TABLE Products_temp (

ProductID int,

ProductName nvarchar (40),

Unit char(2),

UnitPrice money

)

第二、    为该表加上索引，并使其忽略重复的值

方法是在企业管理器中找到上面建立的临时表Products _temp，单击鼠标右键，选择所有任务，选择管理索引，选择新建。如图所示。 按照图中圈出来的地方设置索引选项。

第三、拷贝产品信息到临时表：  insert into Products_temp Select * from Products

此时SQL Server会返回如下提示：

服务器: 消息 3604，级别 16，状态 1，行 1

已忽略重复的键。

它表明在产品信息临时表Products_temp中不会有重复的行出现。

第四、将新的数据导入原表

将原产品信息表Products清空，并将临时表Products_temp中数据导入，最后删除临时表Products_temp。

delete Products
insert into Products select * from Products_temp
drop table Products_temp

这样就完成了对表中重复记录的删除。无论表有多大，它的执行速度都是相当快的，而且因为几乎不用写语句，所以它也是很安全的。

软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

用户认证安全的测试要考虑问题：

1.         明确区分系统中不同用户权限

2.         系统中会不会出现用户冲突

3.         系统会不会因用户的权限的改变造成混乱

4.         用户登陆密码是否是可见、可复制

5.         是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）

6.         用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统

系统网络安全的测试要考虑问题

1.         测试采取的防护措施是否正确装配好，有关系统的补丁是否打上

2.         模拟非授权攻击，看防护系统是否坚固

3.         采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ）

4.         采用各种木马检查工具检查系统木马情况

5.         采用各种防外挂工具检查系统各组程序的客外挂漏洞

数据库安全考虑问题：

1.         系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）

2.         系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）

3.         系统数据可管理性

4.         系统数据的独立性

5.         系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

 安全性测试复习笔记

六条确定等价类测原则理解

1.     在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类

比如，密码的设置在 6 － 16 个字符之间，我们对这个字符长度等价类划分为一个有效的等价类 6 － 16 的字符串；无效等价类就是小于 6 个的字符串和多余 16 个的字符串

2.     在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况，可以确立一个有效等价类和一个无效等价类

一个等价类就是“必须的条件类”；无效等价类就是“非必须条件”

3.     在输入条件是一个布尔量的情况，可确定一个有效等价类和一个无效等价类

一个有效等价类是“真”；无效的等价类就是“假”

4.     在规定了输入数据的一组值（假定是 n 个），并且程序要对每个输入值分别处理的情况，可确立 n 个有效等价类和一个无效等价类

比如：用户名不允许汉字；这样无效等价类就是汉字，而不是汉字的各种情况就会有很多

5.     在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

这个是第四个原则的反面

6.     在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应在将该等价类进一步的划分为更小的等价类。

首先等价类可以是有效等价类，也可以是无效等价类；比如已划分的一个等价类还可以划分为若干小的等价类。但就各元素在程序处理中的方式不同的情况下不是很能理解

两条根据等价类设计测试用例的技巧

一、        设计一个新的测试用例让其尽量多的覆盖未覆盖有效等价类

二、        设计一个新的测试用例让其覆盖一个无效等价类

重复上面两条直到等价类全部被覆盖

测试用例的设计方法还有很多如边界值（在白盒测试中是一种很不错的方法）、错误推断（这跟工作经验有关了）、因果图（因果图的理论仿佛很难理解，如果举个例子理解起来就简单很多，下面有我举的一个示例）， 待续。。。。。（实在是累的不行了）

(一)  提示：“ the link file .... may be corrupted or has illegated link string ”的，提示重复多次均无法安装。

原因 ：你的 Loaderunner 的安装文件夹名写成中文了，造成 Lr 的安装教本无法识别路径，最终导致不断有这样的错误提示。

解决方案：把安装文件的目录名改为非中文就可以了。

(二)  没法完全卸载

要想把 LR 的老版本完全卸载，正确的步骤是：

1.         停止所有的运行的 LR 的进程和服务（ including the Controller, VuGen, Analysis ， or the LoadRunner Agent Process/Service ）

2.         备份已有的脚本，你的脚本有可能在你的默认安装路径下

3.         在控制面板的添加删除程序中，删除 LR ，并重启机器

4.         手动删除所有 LR 的文件夹，包括您的开始菜单里的 LR 快捷方式

5.         如果你的版本是 6 。 0 系列的，删除 Borland 文件夹（通常在 C:\Borland or C:\BDE  目录下）

6.         搜索    wlrun.* 、    vugen.* ，除了安装文件夹中的文件，其他的都删除

7.         打开注册表，找到

如果只安装了 MI 公司的 LoadRunner 这一个产品，请删除：

HKEY_LOCAL_MACHINESOFTWAREMercury Interactive.

HKEY_CURRENT_USERSOFTWAREMercury Interactive.

否则请删除：

HKEY_LOCAL_MACHINESOFTWAREMercury InteractiveLoadRunner.

HKEY_CURRENT_USERSOFTWAREMercury InteractiveLoadRunner.

删除所有和 LR 有关的数值，除了你的 License2 或 License ，

8.         清空回收站

实现以上步骤后，即可放心安装了，切记在重装后，一定要重启机器，因为一些必要信息要写入注册表。

(三)  卸载后 , 执行安装过程时出现“ license security violation.Operation is not allowed ”提示信息 , 安装失败

解决方案： :

1.         进入一台 Loadrunner 运行正常的电脑 ( 安装路径要和你的相同 ) 进入注册表 , 导出以下两个目录 :

HKEY_CURRENT_USER\Software\Mercury Interactive

HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive

2.         回到刚才安装不成功的电脑 , 进入注册表导入刚才这两个文件 .

3.         再次执行安装 .

建议 : 如果有用 Ghost 提前做 Ghost, 或者为系统设置还原点 .

2 、对测试人员发现的问题的价值没有进行评估
发现1个系统架构设计方面存在的缺陷和隐患，远比发现几个普通界面的显示问题要有价值的多。因此，在对测试人员进行评价时，必须区分不同问题的重要性和价值。

3 、 不重视测试文档的质量
测试文档的质量直接影响到测试工作的质量和规范化。测试文档的质量是反映了测试人员的测试水平的一个重要方面。只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量。所以测试文档的质量也是评价测试人员绩效的一个方面 。

4 、 不重视测试人员的综合能力
首先，必须考察测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次，需要关心测试人员的工作积极性，积极工作的态度不仅能带来很高的测试质量，还能提高整个团队的积极向上的风气。还有，测试人员的沟通能力，如果一个测试人员和开发人员对问题沟通交流不畅，甚至经常引发争执，这显然会影响测试工作的效率。


二、建议对测试人员进行综合性的全面评价
评价方法如下：

三、总结
综上所述，必须本着以测试质量为重、对测试负责的角度对测试人员绩效进行客观评价，同时也提高测试人员的质量意识。通过合理的绩效评价，让测试人员以积极的心态投入的测试工作中，保证测试工作的顺利进行。

四、 绩效评价不是简单的公式化的权值分配问题
权值应根据实际工作内容而定，工作的侧重点不同，考核标准就应该不同，不能把权值做为一个死板的指标。不同情况下，你考核的重点是不一样的，因此考核评价绝对不应该是完全公式化的，这里给出你评价指标的目的在于：建议采用更全面、立体化的方式对测试人员进行评价。下面举几个例子来说明：

例1、比如：一个新入职的测试人员甲月发现问题2个，但是他这个月积极的学习了产品知识、业务流程，工作态度很好。另一个测试人员乙月发现问题15个，测试了100个用例，但是他工作不积极，相比以往问题产量、测试执行情况都下降很多。这种情况下，你是根据权值系数把测试产量高的乙评价为优秀呢？还是打算把态度积极的甲评价为优秀呢？显然，不同测试人员的工作重点不同，可比性就不同，不能简单的通过一个权值计算公式来评价，你可能需要对测试人员乙进行纵向比较他以前的工作业绩，并横向比较其他和他工作任务相似的测试人员的业绩。可见，评价不是一个简单的权值分配问题。不同情况需要区别对待。


例2、比如：一个测试人员这个月侧重于执行测试，发现了一些问题。而另一个测试人员侧重于整理用例，补充了很多非常有用的用例。这样按权值计算就不是很合适，不同类型的参数权值可比性不强。

例3、比如：一个测试人员月发现严重问题3个，另一个测试人员月发现一般问题7个。这种同类的参数比较适合用权值，有可比性。一般情况下，我们把致命问题、严重问题、一般问题、建议问题的加权系数分别是：5，3，1，0.5。当然，具体的系数定义还要参照各公司的标准、实际项目中对问题的区分度而定。


评价的指标是要做为测试人员绩效评定的参考，它的意义主要应该基于以下几个方面：一方面是根据绩效对测试人员进行激励；另一方面是要全面的了解测试人员的工作成果和工作中的问题，以便鼓励他们保持工作中出色的方面，并帮助他们改进工作中的不足。还有一个方面，是通过量化所有测试人员的工作输出，可以对整个测试活动进行评估，对测试活动中出现的问题进行分析，改善测试计划设计、测试设计、测试过程管理。

CMM 是指 “ 能力成熟度模型 ” ，其英文全称为 Capability Maturity Model for Software ，英文 缩写为 SW-CMM ，简称 CMM 。它是对于 软件 组织在定义、实施、 度量 、控制和改善其 软件过程 的实践中各个发展阶段的描述。 CMM 的核心是把 软件开发 视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

CMM 是是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。

CMM 标准共分五个等级，从第一级到第五级分别为：初始级、可重复级、定义级、管理级和优化级，从低到高，软件开发生产的计划精度越来越高，每单位工程的生产周期越来越短，每单位工程的成本也越来越低。

1. 初始级：初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

2. 可重复级：根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、 配置管理 和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

3. 定义级：在第二级仅定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

4. 管理级：第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量 ( 包括工作产品和提交给用户的产品 ) 需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成为一种工业生产活动。

5. 优化级：第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果一个企业达到了这一级，那么表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

　　 CMM 证书主要用于出口美国的软件组织。

　　 CMM 是一种管理方法

　　 CMM 是一组公众可用的描述成熟软件组织特征的准则。组织能运用这些准则去改进开发和维护软件的过程，以及政府或商业组织用于评价与某具体公司签订软件项目合同时的风险。 CMM 将软件开发视为一个过程，提供了一种以有条不紊的和一致的方法改进软件产品的管理和开发的概念性结构。组织软件开发过程是由初始到成熟的一个渐进的过程， CMM 分为 5 级，由低到高分别是：初始级、可重复级、妥善定义级、定量管理级、和持续优化级。软件组织在执行 CMM 的过程中，软件过程能力将持续改进，组织将由几乎无管理、完全依赖个人努力的取得成功，逐渐走向规范化管理，能利用来自过程的以及来自先导性创新思想和新技术的定量和反馈信息，持续改进的过程取得成功。

　　美国软件业发达很重要的一个原因就是：无论规模大小，绝大多数组织都按照规范化的工作方法管理软件循环过程，始终把最终用户放在软件产品供应优化和质量控制的中心，把达到认证标准放在很重要的位置上。

二、 软件组织为什么要做 CMM

WTO 入世在即，中国软件组织何去何从？如何面对挑战？是在国内固步自封，还是勇敢的创出去，进军国际市场。中国的软件组织大多数仍然处于一种手工作坊式运营阶段，质量和效率观念都不强，在技术和产品本身与国际市场接轨方面更是一片空白。这些对软件组织而言，是一个致命的弱点。软件产业的规则就是技术及其标准，全球软件产业处于一个非常开放的价值链中，因此如果你落后了这些技术和标准，就可能被抛出游戏中。另外，软件组织是一个技术密集型组织，获取竞争力的关键就在于提高开发应用效率，降低成本，同时提高产品的质量，这方面是 CMM 的强项。

三、 ISO9000

四、 ISO9000 不是指一个标准，而是一族标准的统称， ISO9000 族标准是指国际标准化组织中的质量管理和质量保证技术委员会制定的标准，现有 21 个标准，可分为 5 类：质量数与标准、质量保证标准、标准选用与实施指南以及支持性技术标准。主要说一下 ISO 软件质量对立模型 

五、 CMM 与 ISO9000 的关系

　　 ISO9000 和 CMM 既有区别又相互联系。

　　 ISO9000 和 CMM 是国际上通用的软件质量评估和管理方法。二者有很多相似之处，它们的实施可以改变软件组织开发不规范、文档不齐、维护跟不上、质量漏洞多等弊病。尽管 ISO 9001 标准的一些要求在 CMM 中不存在，而 CMM 的一些要求在 ISO 9001 标准中也不存在，两者之间的关系非常密切。

　　两者的最大相似之处在于两者都强调对每一个重要的过程应形成文件，包括指导书和说明，并检查交货质量水平，同时也都强调强调持续改进。取得 ISO 9001 认证对于取得 CMM 的等级证书是有益的，反之，取得 CMM 等级证书，对于取得 ISO 9001 认证也是有帮助的。