以下是关于测试的几个重要观念。
1 测试的目的
测试的目的是为了发现尽可能多的缺陷。
这里缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等等。测试总是先假设程序中存在缺陷，再通过执行程序来发现并最终改正缺陷。理解测试的目的是个很重要的意识问题。如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是虚假的。项目经理圈子
/（个人见解）目前高校的科技成果鉴定会普遍存在类似的虚假现象。我在读硕士时就亲身经历过这样的事。我们的项目是研究集成电路制造过程中的成品率问题。当时国内大多数工厂的集成电路成品率只有百分之几，我编写的示例程序可以将集成电路的成品率优化到98%。示例效果是如此的好，以致一位评委（某厂的总工程师）不无讽刺地说：“采用你们的成果，我们可要发大财了。”这个项目就轻易地通过了鉴定，并且不久后获得了电子工业部科技进步二等奖。这就象在考试时通过作弊取得了好成绩而被表扬。我那时尚且纯真，羞愧之余，不禁对高校科研成果的水平和真实性大失所望（现在我已不再失望，因为很少抱希望）。*/
一个成功的测试示例在于发现了至今尚未发现的缺陷。
测试并不仅是个技术问题，更是个职业道德问题。
2 测试的心理要求
项目管理者联盟文章
测试主要是由人而不是由机器执行，这就不免与心理因素相关。为了测试的真实性，对测试的心理要求是“无情”。这似乎太残酷了。开发人员不能很好地测试自己的程序是因为做不到无情。而测试人员如果做到了无情却会引起开发人员的愤怒，遭人白眼。
尽管已经明白了测试的目的是为了发现尽可能多的缺陷，但当测试人员真的发现了一堆缺陷时，却不可乐颠颠地跑去恭喜那个倒霉的开发者，否则会打架的。
3 测试的真理
测试只能证明缺陷存在，而不能证明缺陷不存在。
这个真理告诉我们，对于一个复杂的系统而言，无论采取什么样的测试手段都不能证明缺陷已经不复存在。“彻底地测试”只是一种理想。在实践中，测试要考虑时间、费用等限制，不允许无休止地测试。
4 测试与质量的关系
测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。blog.mypm.net
学习好的学生，在考试时通过认真检查能减少因疏忽而造成的答题错误，从而“提高”了考试成绩（取得他本来就该得的好成绩）。
而学习差的学生，他原本就不会做题目，无论检查多么细心，也不能提高成绩。
所以说，软件的高质量是设计出来的，而不是靠测试修补出来的。
////////////////////////////////// 经常用的测试工具 ////////////////////////////////////////
工具名称 功能范围
WinRunner-----功能：1.插入检查点；2.检验数据；3.增强测试；4.分析结果；5.维护测试；6.为无线应用作准备。
范围：功能测试、生成测试用例、分析测试结果、维护测试用例、回归测试。
LoadRunner-----功能：1.松创建虚拟用户； 2.创建真实的负载； 3.定位性能问题；4.分析结果以精确定位问题所在； 5.重复测试保证系统发布的高性能；6.Enterprise Java Beans的测试； 7.支持无线应用协议； 8.支持Media Stream应用； 9.完整的企业应用环境的支持。
范围：性能测试、压力测试、模拟多用户、定位性能瓶颈。
TestDirector------功能：1．需求管理;2. 计划测试;3. 安排和执行测试;4. 缺陷管理;5. 图形化和报表输出;范围：
测试管理工具
Rational系列-------Rational Purify（测试时用，检查运行时内存错误）;
Rational Quantify（性能检测工具，查出系统瓶颈以便改进运行速度）;
Rational TestManager （测试管理）;
Robot （软件测试用，通过Script自动模拟输入输出）;
LoadTest （负载测试）;
TestFactory （软件测试用）;
QACenter-----QACenter帮助所有的测试人员创建一个快速，可重用的测试过程。这些测试工具自动帮助管理测试过程，快速分析和调试程序，包括针对回归，强度，单元，并发，集成，移植，容量和负载,建立测试用例，自动执行测试和产生文档结果。
QACenter主要包括以下几个模块：
QARun：应用的功能测试工具。
QALoad：强负载下应用的性能测试工具。
QADirector：测试的组织设计和创建以及管理工具。
TrackRecord：集成的缺陷跟踪管理工具。
EcoTools：高层次的性能监测工具。
QARun----1.强大的测试脚本建立功能。2.可反复运行，进行回归测试。
3．支持更多的应用访问
QALoad------1.自动捕获实际执行过程，自动生成测试脚本。2.通过控制台（安装在WindowsNT）控制各个Agent（安装在Windows和Unix），进行脚本分配。3.模拟实际操作，压力测试。
WebLoad-----Web压力测试工具
panorama，功能主要是用于白盒测试。它对分析源码和跟踪错误方面有一定独到的见解，并且采用图解的方法跟踪源码。白盒方面Compuware也非常不错;
//////////////////////////////////////软件测试方案///////////////////////////////////////
目录----测试目标，测试范围，测试内容，测试使用的方法（黑盒，白盒，自动化等等），时间人员进度安排
目录----
测试目的,测试范围,测试准则,测试模型,测试策略,测试内容,测试实施准备,
测试组织结构,测试环境及工具需求,测试输出,测试计划,测试风险分析
心得---我们搞清楚测试方案是处在测试中的那个阶段。
测试方案是处在测试需求分析之后，而在测试用例设计之前。那么很明显，他要起到这个承上启下的作用。
也就是说，如果把测试需求转化成用例。
好了，知道了这个目标，那么我们来看看要做那些工作。
首先，你要明白都有那些测试内容，那些是测试重点。
然后是，这些测试对象，从大方向应该选择怎样的测试方法。
注意：我说的是测试方法，不是设计用例的方法，别搞混。例如：白盒，黑盒，自动化，验收测试，确认测试，冒烟测试，都是测试方法。
确定测试方法很重要，不然测试怎么会有针对性？
再然后，就是分析具体的测试点应该用什么方法测试，也就是设计用例的方法，怎么能转化成用例呢？
好了做完这些工作，一个完美的测试方案出来了，下面来写测试用例，谁还不会写呢？方案中分析的那么透彻。
最后一个文档，再加上一些格式需要的头啊，尾啊，成功了。
测试方案是质量模型的一个重要组成部分，如果你们有质量模型，那么也要在这里面分析，怎么来达到这个质量标准，
还有就是每个质量标准包含那些测试内容，怎么来计算和实现这个标准。
当然，如果你们有测试度量阶段的话，就放在这里面做是最合适了。
别忘了，测试方案是用来做什么的，不是用来给领导看的摆设，二是用来知道设计测试用例的。
/////////////////////////////////////////测试用例//////////////////////////////////
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果的条件或变量，
以便测试某个程序路径或核实是否满足某个特定需求。
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：
指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
/////////////////////////////////linux的认识////////////////////////////////////////
Linux开发更多关注的是它的内在功能而不是表面上的东西。即使是在纯文本的环境中， Linux同样拥有非常先进的网络、脚本和安全能力。执行一些任务所需的某些表面上看起来比较奇怪的步骤是令人 费解的，除非您认识到 Linux 是期望在网络上与其他 Linux系统协同执行这些任务。Linux的自动执行能力也很强， 只需要设计批处理文件就可以让系统自动完成非常详细的任务。Linux 的这种能力来自于其基于文本的本质。
Linux通过文件访问权限来判断文件是否为可执行文件。任何一个文件都可以赋予可执行权限， 这样程序和脚本的创建者或管理员可以将它们识别为可执行文件。这样做有利于安全。 保存到系统上的可执行的文件不能自动执行，这样就可以防止许多脚本病毒。 -----这里的从新引导似乎是从新启动的意思
如果您使用Windows已经很长时间了，您可能已经习惯出于各种原因（从软件安装到纠正服务故障）而重新引导系统 。在Linux思想中您的这一习惯需要改变。Linux在本质上更遵循“牛顿运动定律”。 一旦开始运行，它将保持运行状态，直到受到外来因素的影响，比如硬件的故障。 实际上，Linux系统的设计使得应用程序不会导致内核的崩溃， 因此不必经常重新引导（与Windows系统的设计相对而言）。所以除了Linux内核之外， 其他软件的安装、启动、停止和重新配置都不用重新引导系统。
--------- GCC的简单介绍----------------
GCC（GNU Compiler Collection，GNU编译器套装），是一套由 GNU 开发的编程语言编译器。
它是一套
以 GPL 及 LGPL 许可证所发行的自由软件，也是 GNU计划的关键部分，
亦是自由的类Unix及苹果电脑 Mac OS X 操作系统的标准编译器。
GCC 原名为 GNU C 语言编译器，因为它原本只能处理 C语言。GCC 很快地扩展
变得可处理 C++。之后也变得可处理 Fortran、Pascal、Objective-C、Java, 以及 Ada与其他语言
其中options就是编译器所需要的参数，filenames给出相关的文件名称。、
-c，只编译，不连接成为可执行文件，编译器只是由输入的.c等源代码文件生成.o为后缀的目标文件，通常用于编译不包含主程序的子程序文件。
-o output_filename，确定输出文件的名称为output_filename，同时这个名称不能和源文件同名。如果不给出这个选项，gcc就给出预设的可执行文件a.out。
-g，产生符号调试工具(GNU的gdb)所必要的符号资讯，要想对源代码进行调试，我们就必须加入这个选项
-O，对程序进行优化编译、连接，采用这个选项，整个源代码会在编译、连接过程中进行优化处理，这样产生的可执行文件的执行效率可以提高，但是，编译、连接的速度就相应地要慢一些。、
-O2，比-O更好的优化编译、连接，当然整个编译、连接过程会更慢。
gcc -E hello.c -o hello.i //预编译过程
gcc -S hello.i -o hello.s //编译过程过程
gcc -c hello.s -o hello.o //汇编过程
gcc hello.c -o hello 、 //连接过程
./hello
hello,world!
/////////////////////////名词解释////////////////////////
采用什么方法对软件进行测试呢？常用的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。
白盒，
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。 白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。 六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。
黑盒，
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。
黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。功能不正确或遗漏；界面错误；数据库访问错误；性能错误；初始化和终止错误等。
从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
自动化，
动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后， 由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。 在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。 实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件： 1) 软件需求变动不频繁 2) 项目周期足够长 3) 自动化测试脚本可重复使用。 适用的场合：
(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费； (2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具； (3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性； (4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖；
验收测试，
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。 验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。
实施验收测试的常用策略有三种，它们分别是： · 正式验收 · 非正式验收或 Alpha 测试 · Beta 测试
确认测试，
确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础。
测试内容
安装测试 功能测试 可靠性测试 安全性测试 时间及空间性能测试 易用性测试 可移植性测试 可维护性测试 文档测试
冒烟测试：
冒烟测试(smoke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
//////////////////////////JAVA与c++的异同//////////////////////////
1 多继承：Java中不使用多继承，而是用一个叫“Interface”的结构，Java中的接口与C＋＋中的一个只有纯虚函数的类等价。但Java接口不是一个类。接口中声明的方法不能在接口中执行，而且一个Java接口不能有任何成员变量。所以对接口的多继承就不会导致被加到C＋＋中的虚继承的问题。所以在Java中不需要虚继承，因为它不可能在多于一个路径中继承到相同的成员变量。Java中使用类聚合来替换多继承，特别是在Observer模式中，是一致的。 2 内存管理：Java使用垃圾收集机制，垃圾收集是一个内存管理scheme ，它在对内存块的所有引用都不存在后就自动的释放这个内存块。垃圾收集机制使得对特定种类的应用很容易编程，程序的设计者不需要考虑清除“dead”内存。C＋＋中缺少这种机制，很多人为C＋＋提供了garbage collectors ，有的是第三方软件，有的是在网上的共享软件。这些collectors很不完美，但方便了使用。 对于Java没有方法来使writer来手动的发现去管理内存。很明显，你不能写你自己的内存管理者，也不能在内存管理者控制的内存中构造对象。 原因：任何内存管理计划都允许程序有指针和对未使用空间的引用，这是违反特定的安全的。手动管理内存的任何形式，如holding on to dead pointers or references ，都会导致安全漏洞。在典型的Java环境中，安全是一个涉及到的严重的问题。Java applets经常在web浏览器中运行和被下载。用户可能不知道运行的applet，因为他们的浏览器是活动的。如果允许手动内存管理，不道德的人就可能发布包含不安全applet的web页。这些applet可能就被正在浏览的，没有防备的用户下载到了自己的系统中。一但下载了这些applet，就可以把私有信息返回给web页的作者。 在Java中缺少手动内存管理的问题？这使得Java在硬实时（a hard real time system）约束的系统中使用困难。当garbage collector运行时，这个问题是很难预测的。可以使用有意义的CPU时间来处理，必须建立一种方式，使得你要用的内存可靠而不会引起垃圾收集。在实时应用中使用任何Java库都可能导致垃圾收集，要注意。 3. Finalize Java 中的finalize 方法大概对应于C＋＋中的析构器。当一个对象被garbage collector收集了，它的finalize方法就被调用了。注意，在大多数情况下，finalize不是一个释放由对象持有的资源的好的位置。可能需要很长时间这个对象才好被garbage collector收集，这样，在finalize中它们释放的资源可能被持有很长时间。 导出类的finalize方法必须明确调用基类的finalize方法。如果忘记这样做，基类中的finalize方法就完全不会被调用。 4. ToString() 任何有toString方法的类，都是被用于特殊的上下文中，希望得到一个String 。在一个String的上下文中，对象的toString方法会自动的调用。对toString()方法的自动使用好像是自动转换C＋＋系统的不成熟版本。这个特征使得String类有些地方比其它类特殊。我认为，对Java设计者，可以看作是使用一个一般的转换系统（如，一个方法模板） 5. Exceptions and finally 在C＋＋中，当一个异常离开了一个方法的范围，被定位在堆栈的所有对象被回收，它们的析构器被调用。这样，如果你想释放一个资源或当一个异常发生时，清除什么。你必须把代码放到一个被定位到堆栈上的对象的析构器中。 这是人为的，错误倾向的，不方便的。而且从构造器和析构器中抛出异常是有问题的，这在C＋＋中是难使用的问题。 在Java中，每个try块可以有一个finally语句，这样一个块退出的任何时间，不管退出的原因（try块执行结束或者异常抛出），finally语句中的代码都被执行。 这看起来比C＋＋的机制要好，可以在finally语句中直接清除代码，而不是人为的把它们放到析构器中。而且，被清除的代码可以与被清楚的变量保持在相同的范围中。主要的不利方面是强迫应用程序员（1）知道被定位在块中的每个资源的释放协议（2）在finally块中要明确的处理所有的清除操作。 6. Threads Java中线程的执行是最小的和优雅的。方法可以被从并发修改中保护的简单方式是简单的标志和严格的代码机制，在两个线程间创建一个集合点是非常简单的，所有的结合也是一个好的语言特征。 7. Operator Overloading 在Java 1 中不能像C＋＋那样使用操作符重载。 8. Templates 模板是C＋＋中好的特征。在Java中不能创建一个类型安全的容器。Java中所有的容器都能包含任何种类的对象，这会导致问题。 在Java中所有的casts（造型）是类型安全的，这减轻了这个问题。即Java中的造型等价于C＋＋中引用的dynamic_cast (动态造型)。不正确的造型结果在一个异常中被抛出。因为一个Java容器中的对象必须被下溯（downcast），且因为这样的造型相对的安全，类型安全容器的需要就减轻了。 类型安全容器并不是模板的唯一好处。C＋＋中的模板可以获得静态多态。尽管在C＋＋和Java中可以使用抽象基类来获得这种多态，使用模板还是用独特的好处的，如，不需要virtual overhead ，如，不需要额外的时间和内存来管理对正常C＋＋虚函数的动态绑定。 9. Break和Continue标签 对结构化语言的原则是不允许使用goto语句的，但也不允许使用破坏单入口，单出口的范例（paradigm）。如使用goto语句来创建for循环或者while循环的等价体并不违反结构化编程。 单入口，单出口范例要求对每个代码块只能有一个入口点和一个出口点。不能有其它方式从代码块中间进入或者退出。入口在顶部，出口在底部。 在C，C＋＋中break和continue的使用，或者Java中的Continue的使用都违反了单入口，单出口的范例。我们使用它们在一个循环的中间来转换控制退出。事实上，对一下封装块来说，它们不知道它们正被退出，且可能写了假设它们不被退出。这会导致很难识别的错误。
////////////////////////////////////////软件测试与软件质量//////////////////////////////////
软件测试中对软件质量进行度量的指标常用的
有N多种指标： 缺陷统计数据的度量(I) 所有缺陷数量的时间走势或趋势统计 (Bug Trends By Time) 未被处理的缺陷按照严重程度的统计 (Active Bugs By Severity) 未被处理的缺陷按照优先程度的统计 (Active Bugs By Priority) 未被处理的缺陷数量的时间走势或趋势统计 （Active Bugs Over Time） 已发现缺陷的数量和已修复的缺陷的数量的比率 (Fixed/Found)。也被称为修改率或纠错率(Fix Rate) 未处理的缺陷数量和已处理的的缺陷数量的比率 (active/resolved) 已处理的被修复的缺陷数量和已处理的缺陷数量的比率（Resolved as Fixed/resolved） 重新被激活的已修复的缺陷数量(Bug re-activation rate) 通过测试找到的缺陷的统计(Bugs opened by testing activity) 所有的缺陷按照严重程度的统计(All Bugs By Severity) 新被发现的缺陷按严重程度的统计 (Opened Bugs By Severity) 已处理的缺陷按照严重程度的统计 (Resolved Bugs By Severity) 被修复的缺陷按照严重程度的统计 (Fixed By Severity) 不同语言版本缺陷数量的统计(Bugs opened by Language version) 被报告存在缺陷的各功能统计(Where your bugs were found) 处理缺陷的平均时间的统计(Average Time to Resolve) 关闭缺陷的平均时间的统计(Average Time to Close) 被处理缺陷的不同结论统计(Resolved Bugs By Resolution)
浙公网安备 33010602011771号