软件测试初学者精华(一)

作者: life0 发表日期: 2006-08-04 09:56 文章属性: 转

1．测试新手从何处入手  
2．测试计划的前提是什么？  
3．测试计划模版  
4．单元测试，集成测试和系统测试  
5．测试工具：  
6. 软件测试中的基本词汇  
7. 软件测试步骤  
8．我想问到底软件测试的流程是什么？  
9．请问Bug曲线是怎么会事？  
10．负载测试与压力测试有何区别？  
11．如何设计编制软件测试用例（一~三）  
12．软件测试的14种类型  
13．软件开发全过程检测及测试自动化  
15.微软的测试题  
16. 多线程与多进程  
17．回归测试  
18．测试大纲和测试计划  
19．测试版本大全－转贴  
20. 黑、白盒测试  
21．Software Testing 10 Rules  
1．测试新手从何处入手
学习，努力学习，没有别的捷径的
给大家提供一个我们的培训提纲，按照这些内容学吧
8、 软件测试技术概论
9、 测试管理
10、系统测试计划和方案
11、系统测试用例设计
12、集成测试计划和方案
13、集成测试用例设计
14、单元测试计划和方案
15、单元测试用例设计
16、单元测试执行
17、集成测试执行
18、系统测试执行
19、WEB项目测试专题
20、C/S架构项目测试专题
21、测试工程师职业素质
当你刚被聘用到一个测试小组时，作为新手，可能你应该按别人指定的测试计划执行测试。这并不是说你没有能力制定这样的计划，而是别人制定的测试计划可能比你的好（这是一个公认的事实）。按别人的计划执行，并记下那些可以用不同方式完成的部分和优秀之处。用不了多久，你就有自己作主的权利了，最开始要从你负责组件的测试计划作起。充分利用你的笔记和经验，这有助于你在第一次就能够写出一个高效、专业的测试计划。
当你在执行其他人的计划时，你可以考虑另外可尝试的测试用例。有一些可能不适用，但对于软件其他部分仍是好的测试用例，只是不是你负责的而已。不要低估自己作为测试人员的能力，要相信自己也能发现好的测试用例。
制定测试计划时应该考虑可用的资源和需要组织涉及参与的活动。不管是低级别的计划还是高级别的计划，都需要详细地规定工作的责任人、各人的工作任务，以及任务完成的时间。没有经过彻底交流过的计划是不可能有效的。最无效的计划就是那些没人知道其存在的计划。
2．测试计划的前提是什么？
当然是项目计划，作为整个项目来说测试是一个非常重要的步骤，如果pm都没有这个意识，那么你的工作就没有立足的根本了。
在了解了项目需求和开发计划后，你就可以根据项目开发时间来制定你的测试计划
1.test plan 整个测试需要那些资源，时间安排，需要产生哪些文档
2.test case 根据需求编写对应功能模块的测试案例，熟悉系统
3.test report 对每一个完成的模块进行详尽的测试，完成test report
4.bug 跟踪，并且进行数据统计和回归
一般来说只要1个人跟一个项目，这些事情基本还是能够完成的，不敢说多高质量，但是比没有还是好得多
3．测试计划模版
a.
“无忧测试”QQ整理——jzhao的测试计划

感谢jzhao和大家分享！

测试计划6月份--7月份

制定人   开始时间   结束时间   测试阶段   修订  
  2004-06-21   2004-07-22          

一、   测试类型及目标
Win 32 Release 1.0：构建测试和集成测试
a)   构建测试目标：
正确实现需求特性；
界面规范正确无误。
b)   集成测试目标：
正确实现本阶段的需求特性；
界面规范正确无误；
回归测试，对整个产品进行全面的测试
国际化测试
安装测试
二、   测试策略
l   使用测试用例。
l   可以使用WinRunner测试工具，从而减少回归测试的工作量。
l   使用Buggit作为缺陷管理工具，对缺陷进行分类管理，并且需要做出缺陷分析
三、   资源安排

B．这里给一份模板大家看看如何？

1．简介   3
1.1目的   3
1.2背景   3
1.3范围   3
2.   测试参考文档和测试提交文档   3
2.1测试参考文档   3
2.2测试提交文档   3
3.测试进度   3
4.测试资源   3
4.1人力资源   3
4.2测试环境   3
4.3测试工具   3
5.系统风险、优先级   3
6.测试策略   3
6.1数据和数据库完整性测试   3
6.2接口测试   3
6.3集成测试   3
6.4功能测试   3
6.5用户界面测试   3
6.6性能评测   3
6.7负载测试   3
6.8强度测试   3
6.9容量测试   3
6.10安全性和访问控制测试   3
6.11故障转移和恢复测试   3
6.12配置测试   3
6.13安装测试   3
7.问题严重度描述   3
8.附录：项目任务   3


1．   简介
1.   1目的
＜项目名称＞的这一“测试计划”文档有助于实现以下目标：

[确定现有项目的信息和应测试的软件构件。
列出推荐的测试需求（高级需求）。
推荐可采用的测试策略，并对这些策略加以说明。
确定所需的资源，并对测试的工作量进行估计。
列出测试项目的可交付元素]
1.   2背景
[对测试对象（构件、应用程序、系统等）及其目标进行简要说明。需要包括的信息有：主要的功能和性能、测试对象的构架以及项目的简史。]
1.3范围
[描述测试的各个阶段（例如，单元测试、集成测试或系统测试），并说明本计划所针对的测试类型（如功能测试或性能测试）。
简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
列出可能会影响测试设计、开发或实施的所有风险或意外事件。
列出可能会影响测试设计、开发或实施的所有约束。]


2.   测试参考文档和测试提交文档
2.1测试参考文档
下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性：
[注：可适当地删除或添加文档项。]
文档（版本/日期）   已创建或可用   已被接收或已经过复审   作者或来源   备注
可行性分析报告   是□　否□   是□　否□      
软件需求定义   是□　否□   是□　否□      
软件系统分析（STD,DFD,CFD,DD）   是□　否□   是□　否□      
软件概要设计   是□　否□   是□　否□      
软件详细设计   是□　否□   是□　否□      
软件测试需求   是□　否□   是□　否□      
硬件可行性分析报告   是□　否□   是□　否□      
硬件需求定义   是□　否□   是□　否□      
硬件概要设计   是□　否□   是□　否□      
硬件原理图设计   是□　否□   是□　否□      
硬件结构设计（包含PCB）   是□　否□   是□　否□      
FPGA设计   是□　否□   是□　否□      
硬件测试需求   是□　否□   是□　否□      
PCB设计   是□　否□   是□　否□      
USB驱动设计   是□　否□   是□　否□      
Tuner BSP 设计   是□　否□   是□　否□      
MCU设计   是□　否□   是□　否□      
模块开发手册   是□　否□   是□　否□      
测试时间表及人员安排   是□　否□   是□　否□      
测试计划   是□　否□   是□　否□      
测试方案   是□　否□   是□　否□      
测试报告   是□　否□   是□　否□      
测试分析报告   是□　否□   是□　否□      
用户操作手册   是□　否□   是□　否□      
安装指南   是□　否□   是□　否□      
2.2测试提交文档
[下面应当列出在测试阶段结束后，所有可提交的文档]
3.测试进度
测试活动   计划开始日期   实际开始日期   结束日期
制定测试计划          
设计测试          
集成测试          
系统测试          
性能测试          
安装测试          
用户验收测试          
对测试进行评估          
产品发布          


4.测试资源
4.1人力资源
下表列出了在此项目的人员配备方面所作的各种假定。
[注：可适当地删除或添加角色项。]
角色   所推荐的最少资源（所分配的专职角色数量）   具体职责或注释
     
     
4.2测试环境
下表列出了测试的系统环境
软件环境（相关软件、操作系统等）

硬件环境（网络、设备等）


4.3测试工具
此项目将列出测试使用的工具：
用途   工具   生产厂商/自产   版本


5.系统风险、优先级
[简要描述测试阶段的风险和处理的优先级]


6.测试策略
[测试策略提供了对测试对象进行测试的推荐方法。
对于每种测试，都应提供测试说明，并解释其实施的原因。
制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。
下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。]
注意：不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本项目不适用”。
6.1数据和数据库完整性测试
[要＜项目名称＞中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支持以下测试的工具和技术。]

测试目标：   [确保数据库访问方法和进程正常运行，数据不会遭到损坏]
测试范围：  
技术：   [调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据（或对数据的请求）。检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；或者检查所返回的数据，确保正当的理由检索到了正确的数据]
开始标准：  
完成标准：   [所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。]
测试重点和优先级：  
需考虑的特殊事项：   [测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事件具有更大的可视度。]


6.2接口测试
测试目标   确保接口调用的正确性  
测试范围：   所有软件、硬件接口，记录输入输出数据
技术：  
开始标准：  
完成标准：  
测试重点和优先级：  
需考虑的特殊事项：   接口的限制条件


6.3集成测试
[集成测试―主要目的检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试基于功能完成的测试。]
测试目标   检测需求中业务流程，数据流的正确性
测试范围：   需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。
技术：   [利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]
开始标准：   在完成某个集成测试时必须达到标准
完成标准：   [所计划的测试已全部执行。所发现的缺陷已全部解决。]
测试重点和优先级：   测试重点指在测试过程中需着重测试的地方，优先级可以根据需求及严重来定
需考虑的特殊事项：   [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）]


6.4功能测试
[对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：]

测试目标   [确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。]
测试范围：  
技术：   [利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]
开始标准：  
完成标准：  
测试重点和优先级：  
需考虑的特殊事项：   [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）]


6.5用户界面测试
[用户界面（UI）测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。]

测试目标   [核实以下内容：通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。]
测试范围：  
技术：   [为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。]
开始标准：  
完成标准：   [成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准]
测试重点和优先级：  
需考虑的特殊事项：   [并不是所有定制或第三方对象的特征都可访问。]


6.6性能评测
[性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。
注：以下所说的事务是指“逻辑业务事务”。这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例，添加或修改给定的合同。]

测试目标   [核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量预期的最繁重工作量]
测试范围：  
技术：   [使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。]
开始标准：  
完成标准：   [单个事务或单个用户：在每个事务所预期时间范围内成功地完成测试脚本，没有发生任何故障。][多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。]
测试重点和优先级：  
需考虑的特殊事项：   [综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作，其中包括：直接将“事务强行分配到”服务器上，这通常以“结构化语言”（SQL）调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿真（Remote Terminal Emulation）工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。]


6.7负载测试
[负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。]
[注：以下所说的事务是指“逻辑业务事务”。这各事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能，例如，添加或修改给定的合同。]

测试目标   [核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。]
测试范围：  
技术：   [使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务发生的次数。]
开始标准：  
完成标准：   [多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。]
测试重点和优先级：  
需考虑的特殊事项：   [负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。]
6.8强度测试
[强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。]
[注：以下提到的事务都是指逻辑业务事务。]
测试目标   [核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：服务器上几乎没有或根本没有可用的内存（RAM和DASD）连接或模拟了最大实际（实际允许）数量的客户机多个用户对相同的数据或帐户执行相同的事务最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）。注：强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。客户机的强度测试在“配置测试”的第3.1.11节中进行了说明。]
测试范围：  
技术：   [使用为性能评测或负载测试制定的测试。要对有限的资源进行测试，就应该在一台计算机上运行测试，而且应该减少或限制服务器上的RAM和DASD。对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。]
开始标准：  
完成标准：   [所计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件故障，或者导致系统出现故障条件的并不在指定的条件范围之内。]
测试重点和优先级：  
需考虑的特殊事项：   [如果要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。应该暂时减少用于系统的DASD，以限制数据库可用空间的增长。使多个客户机对相同的记录或数据帐户同时进行的访问达到同步。]


6.9容量测试
[容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库。检验该软件是否正常运行并生成了正确的报表。]

测试目标   [核实测试对象在以下高容量条件下能否正常运行：连接或模拟了最大（实际或实际允许）数量的客户机，所有客户机在长时间内执行相同的、且情况（性能）最坏的业务功能。已达到最大的数据库大小（实际的或按比例缩放的），而且同时执行多个查询或报表事务。]
测试范围：  
技术：   [使用为性能评测或负载测试制定的测试。应该使用多台客户机来运行相同的测试或互补的测试，以便在长时间内产生最繁重的事务量或最差的事务组合（请参见上面的“强度测试”）创建最大的数据库大小（实际的、按比例缩放的、或填充了代表性数据的数据库），并使用多台客户机在长时间内同时运行查询和报表事务。]
开始标准：  
完成标准：   [所计划的测试已全部执行，而且达到或超出指定的系统限制时没有出现任何软件故障。]
测试重点和优先级：  
需考虑的特殊事项：   [对于上述的高容量条件，哪个时间段是可以接受的时间？]


6.10安全性和访问控制测试
[安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问。
系统级别的安全性，包括对系统的登录或远程访问。
应用程序级别的安全性可确保：在预期的安全性情况下，Actor只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新帐户，但只有管理员才能删除这些数据或帐户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。]
测试目标   应用程序级别的安全性：[核实Actor只能访问其所属用户类型已被授权访问的那些功能或数据。]系统级别的安全性：[核实只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。]
测试范围：  
技术：   应用程序级别的安全性：[确定并列出各用户类型及其被授权访问的功能或数据。][为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。]修改用户类型并为相同的用户重新运行测试。对于每种用户类型，确保正确地提供或拒绝了这些附加的功能或数据。系统级别的访问：[请参见以下的“需考虑的特殊事项”。]
开始标准：  
完成标准：   [各种已知的Actor类型都可访问相应的功能或数据，而且所有事务都按照预期的方式运行，并在先前的应用程序功能测试中运行了所有的事务。]
测试重点和优先级：  
需考虑的特殊事项：   [必须与相应的网络或系统管理员一直对系统访问权进行检查和讨论。由于此测试可能是网络管理可系统管理的职能，可能会不需要执行此测试。]


6.11故障转移和恢复测试
[故障转移和恢复测试可可确保测试对象能成功完成转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件可网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出（I/O）故障或无效的数据库指针和关键字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。]

测试目标   [确保恢复进程（手工或自动）将数据库、应用程序和系统正确地恢复到预期的已知状态。测试中将包括以下各种情况：客户机断电服务器断电通过网络服务器产生的通信中断DASD和/或DASD控制器被中断、断电或与DASD和/或DASD控制器的通信中断周期未完成（数据过滤进程被中断，数据同步进程被中断）。数据库指针或关键字无效数据库中的数据元素无效或遭到破坏]
测试范围：  
技术：   [应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点，就应该分别执行或模拟以下操作：²   客户机断电：关闭PC机的电源。²   服务器断电：模拟或启动服务器的断电过程。²   通过网络服务器产生的中断：模拟或启动网络的通信中断（实际断开通信线路的连接或关闭网络服务器或路由器的电源）。²   DASD和DASD控制器被中断、断电或与DASD和DASD控制器的通信中断：模拟与一个或多个DASD控制器或设备的通信，或实际取消这种通信。²   一旦实现了上述情况（或模拟情况），就应该执行其他事务。而且一旦达到第二个测试点状态，就应调用恢复过程。²   在测试不完整的周期时，所使用的技术与上述技术相同，只不过应异常终止或提前终止数据库进程本身。²   对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时，应该以手工方式在数据库中（通过数据库工具）直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行，并且应执行完整的周期。]
开始标准：  
完成标准：   [在所有上述情况中，应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏，以及表明进程或事务因中断面未被完成的报表。]
测试重点和优先级：  
需考虑的特殊事项：   ²   [恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法（模拟断电或通信中断）可能并不可取或不可行。所以，可能会需要采用其他方法，例如诊断性软件工具。²   需要系统（或计算机操作）、数据库和网络组中的资源。²   这些测试应该在工作时间之外或在一台独立的计算机上运行。]


6.12配置测试
[配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件　例如，应用程序、驱动程序等　而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。]

测试目标   [核实测试可在所需的硬件和软件配置中正常运行。]
测试范围：  
技术：   ²   [使用功能测试脚本。²   在测试过程中或在测试开始之前，打开各种与非测试对象相关的软件（例如Microsoft应用程序：Excel和Word），然后将其关闭。²   执行所选的事务，以模拟Actor与测试对象软件和非测试对象软件之间的交互。²   重复上述步骤，尽量减少客户机工作站上的常规可用内存。]
开始标准：  
完成标准：   [对于测试对象软件和非测试对象软件的各种组合，所有事务都成功完成，没有出现任何故障。]
测试重点和优先级：  
需考虑的特殊事项：   ²   [需要、可以使用并可以通过桌面访问哪种非测试对象软件？²   通常使用的是哪些应用程序？²   应用程序正在运行什么数据？例如，在Excel中打开的大型电子表格，或是在Word中打开的100页文档。²   作为此测试的一部分，应将整修系统、Netware、网络服务器、数据库等都记录下来。]


6.13安装测试
[安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下　例如，进行首次安装、升级、完整的或自定义的安装　都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。]
测试目标   核实在以下情况下，测试对象可正确地安装到各种所需的硬件配置中：²   首次安装。以前从未安装过＜项目名称＞的新计算机²   更新。以前安装过相同版本的＜项目名称＞的计算机²   更新。以前安装过＜Project Name>的较早版本的计算机
测试范围：  
技术：   ²   [手工开发脚本或开发自动脚本，以验证目标计算机的状况　首次安装＜项目名称＞从未安装过；＜项目名称＞安装过相同或较早的版本。²   启动或执行安装。²   使用预先确定的功能测试脚本子集来运行事务。]
开始标准：  
完成标准：   ＜项目名称＞事务成功执行，没有出现任何故障。
测试重点和优先级：  
需考虑的特殊事项：   [应该选择＜项目名称＞的哪些事务才能准确地测试出＜项目名称＞应用程序已经成功安装，而且没有遗漏主要的软件构件？。]


7.问题严重度描述
问题严重度   描述   响应时间
高   例如使系统崩溃   程序员在多长时间内改正此问题
中      
低      
     
     
8.附录：项目任务
以下是一些与测试有关的任务：
²   　　制定测试计划
n   确定测试需求
n   评估风险
n   制定测试策略
n   确定测试资源
n   创建时间表
n   生成测试计划
²   设计测试
n   准备工作量分析文档
n   确定并说明测试用例
n   确定测试过程，并建立测试过程的结构
²   复审和评估测试覆盖
²   实施测试
n   记录或通过编程创建测试脚本
n   确定设计与实施模型中的测试专用功能
n   建立外部数据集
²   执行测试
²   执行测试过程
²   评估测试的执行情况
²   恢复暂停的测试
²   核实结果
²   调查意外结果
²   记录缺陷
²   对测试进行评估
²   评估测试用例覆盖
²   评估代码覆盖
²   分析缺陷
²   确定是否达到了测试完成标准与成功标准

评论：单元测试/测试环境/过于复杂可针对公司不同情况精简/一个太简单，一个太复杂了，就要靠自己扩充和提炼了
4．单元测试，集成测试和系统测试
单元测试关注软件单元内部的逻辑结构和控制流程；
集成测试关注软件模块之间的接口和模块集成后整体功能的实现；
系统测试完全不考虑软件内部结构，只从需求出发进行验证。
评论：
单元测试应该是程序员自己做比较好。其他的测试应该以测试工程师为主，程序员、用户配合，这样效果比较好个人意见啊/很多不同意这个观点

5．测试工具：
winRunner ,Loadrunner， Rational等测试工具

6. 软件测试中的基本词汇

软件测试中的基本词汇
ü     黑盒测试 (Black box testing) ── 不考虑内部设计和代码，根据需求和功能进行测试。

ü     白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。

ü     功能测试 (functional testing) ── 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。)

ü     系统测试 ── 针对全部需求说明进行黑盒测试，包括系统中所有的部件。

ü     端到端测试 (end-to-end testing) ── 类似于系统测试，但测试范围更“宏观”一些。模仿实际应用环境，对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。

ü     回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。

ü     负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。

ü     压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。

ü     性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。

ü     可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。

ü     恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统的情况。

ü     安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。

ü     α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

ü   β 测试 (beta testing) ── 当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
ST系统测试
IT集成测试
UT单元测试
SRS软件需求规格说明书
HLD概要设计
LLD详细设计
CMO配置管理员
RC需求变更
REVIEW评审
Alpha和Beta测试简介

大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。

Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给这些专业测试机构进行测试。

7. 软件测试步骤

软件测试步骤
•   测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。
•   开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
•   集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
•   确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
•   系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
单元测试 (Unit Testing)
•   单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
•   单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
1. 单元测试的内容
•   在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
(1) 模块接口测试
•   在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：
–   调用本模块的输入参数是否正确；
–   本模块调用子模块时输入给子模块的参数是否正确；
–   全局量的定义在各模块中是否一致；
•   在做内外存交换时要考虑：
–   文件属性是否正确；
–   OPEN与CLOSE语句是否正确；
–   缓冲区容量与记录长度是否匹配；
–   在进行读写操作之前是否打开了文件；
–   在结束文件处理时是否关闭了文件；
–   正文书写／输入错误，
–   I／O错误是否检查并做了处理。


(2) 局部数据结构测试
•   不正确或不一致的数据类型说明
•   使用尚未赋值或尚未初始化的变量
•   错误的初始值或错误的缺省值
•   变量名拼写错或书写错
•   不一致的数据类型
•   全局数据对模块的影响
(3) 路径测试
•   选择适当的测试用例，对模块中重要的执行路径进行测试。
•   应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
•   对基本执行路径和循环进行测试可以发现大量的路径错误。
(4) 错误处理测试
•   出错的描述是否难以理解
•   出错的描述是否能够对错误定位
•   显示的错误与实际的错误是否相符
•   对错误条件的处理正确与否
•   在对错误进行处理之前，错误条件是否已经引起系统的干预等
(5) 边界测试
•   注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。
•   如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。





2. 单元测试的步骤
•   模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
–   驱动模块 (driver)
–   桩模块 (stub) ── 存根模块




•   如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。
•   对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
集成测试（Integrated Testing）
•   集成测试 (集成测试、联合测试）
•   通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：
–   在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；
–   一个模块的功能是否会对另一个模块的功能产生不利的影响；



–   各个子功能组合起来，能否达到预期要求的父功能；
–   全局数据结构是否有问题；
–   单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行集成测试，
发现并排除在模块连接中可能出现
的问题，最终构成要求的软件系统。





•   子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
•   通常，把模块集成成为系统的方式有两种
–   一次性集成方式
–   增殖式集成方式


1. 一次性集成方式(big bang)
•   它是一种非增殖式组装方式。也叫做整体拼装。
•   使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。

2. 增殖式集成方式
•   这种集成方式又称渐增式集成
•   首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
•   在集成的过程中边连接边测试，以发现连接过程中产生的问题
•   通过增殖逐步组装成为要求的软件系统。


(1) 自顶向下的增殖方式
•   这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。
•   自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
•   选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。

(2) 自底向上的增殖方式
•   这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
•   因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。



•   自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
•   一般来讲，一种方式的优点是另一种方式的缺点。
(3) 混合增殖式测试
•   衍变的自顶向下的增殖测试
–   首先对输入／输出模块和引入新算法模块进行测试;
–   再自底向上组装成为功能相当完整且相对独立的子系统;
–   然后由主模块开始自顶向下进行增殖测试。

•   自底向上-自顶向下的增殖测试
–   首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
–   然后对含写操作的子系统做自顶向下的组装与测试。
•   回归测试
–   这种方式采取自顶向下的方式测试被修改的模块及其子模块;
–   然后将这一部分视为子系统，再自底向上测试。
关键模块问题
•   在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。
•   关键模块的特征：
① 满足某些软件需求；
② 在程序的模块结构中位于较高的层次（高层控制模块）；
③ 较复杂、较易发生错误；
④ 有明确定义的性能要求。


确认测试（Validation Testing）
•   确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
•   对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。

1. 进行有效性测试（黑盒测试）
•   有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
•   首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。

•   通过实施预定的测试计划和测试步骤，确定
–   软件的特性是否与需求相符；
–   所有的文档都是正确且便于使用；
–   同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试

•   在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
–   测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
–   测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。


2. 软件配置复查
n   软件配置复查的目的是保证
u 软件配置的所有成分都齐全；
u 各方面的质量都符合要求；
u 具有维护阶段所必需的细节；
u 而且已经编排好分类的目录。
n 应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
验收测试（Acceptance Testing）
•   在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。
•   验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。
•   由用户参加设计测试用例，使用生产中的实际数据进行测试。

•   在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
•   确认测试应交付的文档有：
–   确认测试分析报告
–   最终的用户手册和操作手册
–   项目开发总结报告。


系统测试（System Testing）
•   系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
•   系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
α测试和β测试
•   在软件交付使用之后，用户将如何实际使用程序，对于开发者来说是无法预测的。
•   α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

•   α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重产品的界面和特色。
•   α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。



•   β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。
•   测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。
•   在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。

•   β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。
•   只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。
测试类型
•   软件测试是由一系列不同的测试组成。主要目的是对以计算机为基础的系统进行充分的测试。
功能测试
功能测试是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。

强度测试

强度测试是要检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试。例如：
–   把输入数据速率提高一个数量级，确定输入功能将如何响应。
–   设计需要占用最大存储量或其它资源的测试用例进行测试。



–   设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。
–   设计出会对磁盘常驻内存的数据过度访问的测试用例进行测试。
•   强度测试的一个变种就是敏感性测试。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降的情况发生。此测试用以发现可能引起这种不稳定性或不正常处理的某些数据组合。



性能测试
•   性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。
•   性能测试常常需要与强度测试结合起来进行，并常常要求同时进行硬件和软件检测。
•   通常，对软件性能的检测表现在以下几个方面：响应时间、吞吐量、辅助存储区，例如缓冲区，工作区的大小等、处理精度，等等。

恢复测试
恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后，系统能否正常地继续进行工作，并不对系统造成任何损害。
•   为此，可采用各种人工干预的手段，模拟硬件故障，故意造成软件出错。并由此检查：
–   错误探测功能──系统能否发现硬件失效与故障；

–   能否切换或启动备用的硬件；
–   在故障发生时能否保护正在运行的作业和系统状态；
–   在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业，等等。
–   掉电测试：其目的是测试软件系统在发生电源中断时能否保护当时的状态且不毁坏数据，然后在电源恢复时从保留的断点处重新进行操作。



配置测试

•   这类测试是要检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。
•   它主要包括以下几种：
–   配置命令测试：验证全部配置命令的可操作性（有效性）；特别对最大配置和最小配置要进行测试。软件配置和硬件配置都要测试。



–   循环配置测试：证明对每个设备物理与逻辑的，逻辑与功能的每次循环置换配置都能正常工作。
–   修复测试：检查每种配置状态及哪个设备是坏的。并用自动的或手工的方式进行配置状态间的转换。

安全性测试
安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
•   力图破坏系统的保护机构以进入系统的主要方法有以下几种：
–   正面攻击或从侧面、背面攻击系统中易受损坏的那些部分；
–   以系统输入为突破口，利用输入的容错性进行正面攻击；



–   申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统；
–   故意使系统出错，利用系统恢复的过程，窃取用户口令及其它有用的信息；
–   通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令，安全码，译码关键字等信息；
–   浏览全局数据，期望从中找到进入系统的关键字；
–   浏览那些逻辑上不存在，但物理上还存在的各种记录和资料等。

可使用性测试

•   可使用性测试主要从使用的合理性和方便性等角度对软件系统进行检查，发现人为因素或使用上的问题。
•   要保证在足够详细的程度下，用户界面便于使用；对输入量可容错、响应时间和响应方式合理可行、输出信息有意义、正确并前后一致；出错信息能够引导用户去解决问题；软件文档全面、正规、确切。

安装测试
安装测试的目的不是找软件错误，而是找安装错误。
•   在安装软件系统时，会有多种选择。
–   要分配和装入文件与程序库
–   布置适用的硬件配置
–   进行程序的联结。
•   而安装测试就是要找出在这些安装过程中出现的错误。


•   安装测试是在系统安装之后进行测试。它要检验：
–   用户选择的一套任选方案是否相容；
–   系统的每一部分是否都齐全；
–   所有文件是否都已产生并确有所需要的内容；
–   硬件的配置是否合理，等等。



容量测试

•   容量测试是要检验系统的能力最高能达到什么程度。例如，
–   对于编译程序，让它处理特别长的源程序；
–   对于操作系统，让它的作业队列“满员”；
–   对于信息检索系统，让它使用频率达到最大。
在使系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。



文档测试

这种测试是检查用户文档(如用户手册)的清晰性和精确性。
•   用户文档中所使用的例子必须在测试中一一试过，确保叙述正确无误。

自动测试
•   认识自动测试
•   什么时候使用自动测试

8．我想问到底软件测试的流程是什么？
具体情况具体定，大体上是：
测试计划－测试设计－测试用例－测试执行－测试报告。
有些人把设计和用例放在一起，有些公司是讲test case 积累，下个项目可以继续累加，增加了覆盖率。
测试开发包括测试用例的实现/测试代码的编写等等；测试设计实现测试方案的写作

《面向对象的软件测试》，作者 John D.McGregor

整个测试过程来说比较复杂，在这只说一下系统测试阶段的流程，首先是开发人员的需求分析阶段，在需求分析的同时，测试人员可以提出 可测试性需求，然后需求分析初步定搞后，测试人员可以参加需求评审，当需求经过评审纳入到配置库中后，测试人员就可以开始写测试计划了，测试计划主要是规划这次测试活动，角度是从管理方面，测试计划一般都有模版，然后在根据测试计划以及需求规格说明书来写测试方案，测试方案是从技术的角度来规划本次测试活动，有了方案了我们就可以根据它和SRS来写测试用例（这些都是有模版的），测试用例是最重要的！！测试用例写好了就可以进行测试的执行了，在这些过程中都会产生一些文挡，这些文档一般是需要经过评审的。当所有的测试用例都执行完了并且相关的测试文挡都通过了评审的话，那么本次测试活动就可以结束了。。。。

测试流程
转眼间来了公司一个多月了，工作时间应该算是很短的了，但是测试部门就我和勇斌两个人，我还算长的了，呵呵。由于以前公司没有测试人员，所以测试流程很不完善，估计大家对测试也不是很了解。以下是我个人的一些看法。
测试部门的职责：
今年的主要目标有三个，
　第一个是严格把关产品质量，所谓严格并不意味着测试会在软件项目和用户不需要的前提下，建立不合理和难以实现的质量目标。而是会进一步完善我们的现有的测试规范，严格按照规范办事。比如说，问题单改到%之多少才可以提交测试版本等等，这一点希望各位项目经理和开发人员能够理解。 如果改一个问题就出一个版本的话，我们的测试很难做的。这只是一个目标,呵呵.
　第二个要达到的目标是提供及时的测试服务，因为我们测试需要承担公司内所有项目的测试工作，而目前测试部人员缺少（就两个人），在有些情况下，开发已经完成编码工作，测试部由于人员等情况，我们可能将测试执行工作或是文档工作推后。在今后我们会尽量克服这个问题，做到能及时进行测试分析、及时执行测试、及提时提交问题单、及提交测试报告、及时编写测试用例。
　第三个目标是提高我们测试的服务水平
　　因为现在需要测试公司内的所有项目，为了更好的达到测试的目标，测试必须设法适用于我们所面对的所有项目，这样对测试人员的水平也是一个挑战（怎样部署不同的项目的测试环境、怎样对于不同的操作系统下的项目进行测试，）这些都是我们有待提高的技术；另外现在公司的同事们对测试人员已非常尊重，这一点很好，其实测试与开发一样都同一个目标就是做好每一个项目，这些也是我们今后努力的目标。
测试流程的定义：
首先向大家介绍一下我理解的测试流程是什么，流程在词典上的解释是“工艺程序,从原料到制成品的各项工序安排的程序”，那测试流程就是指从软件测试开始到软件测试结束经过的一系列准备、执行、分析的过程。所以我认为测试流程并不是只存在于有完整测试团队的公司，它分布在每一个对软件执行测试的公司中，哪怕像我们这样的只有一两个测试人员的公司。
下边是我根据咱们 公司做的一个关于bug管理的描述（公司内暂时没有bug管理工具，我正在寻找比较好的免费工具）
  测试人员（Tester）只要发现问题就立即新建一个Bug予以跟踪并发送给相关的开发小组长（Dev Lead）现在主要是通过excel表格来发送，，不好控制和管理，
开发小组长会判断这个Bug属于某个特定的开发人员（Dev）并指派给他处理
开发人员会根据Bug的详细描述信息找到问题所在，修改程序解决这个Bug并把Bug返回给当初的测试人员；希望开发发送给我们版本的时候，把以前的测试报告也发送给我们，最好注明那些问题已经修改，怎么修改的。那些问题依然存在。那些问题存在争议，争议的焦点。（备注：存在争议如何处理，）
测试人员在看到某个Bug被解决后，就去验证这个Bug是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个Bug；若还能重现，或者不同意开发人员的解法，可以激活这个Bug，返还给当初的开发人员做进一步调查处理.
下边的这些是我自己思考的一些问题:
各个项目的需求，项目的完成时间，计划安排。我希望能够让我们了解更多的关于产品的信息,如果我们什么也不知道就拿一个产品进行测试,这样很难发现一些问题,甚至是一些表面的问题。我们知道了项目的安排和计划，便于我们能够合理的安排测试。
当一个新的版本出现时，必须标明是哪个版本，修改了那些问题 。这样我们可以进行有针对性地测试。
开发大概多长时间出一个版本，有些问题越到最后越麻烦。我希望我们能够及时地拿到版本，不要很长时间才测试一次，有些问题越到最后越难管理。
编写测试用例。我正在考虑我们是不是需要编写一些简单的测试用例。
这个问题是我们自己思考的，希望大家给点意见的。
就是测试，什么叫测试完毕呢。
我的理解就是首先你的按照正常的操作步骤，把所有的路径走一遍。我的正常的操作步骤就是客户肯定会用到的，经常用到的。然后再进行一些自由的测试，把自己能够想到的都测试一遍。

9．请问Bug曲线是怎么会事？

Bug曲线具体是如何定义的？

是怎么制作出来的？

意义是什么？

它能反映出那些问题？（
1）偶是这样认为的：
从测试开始，bug被不断发现，那么这些bug与测试的日期等都有对应的关系，可以通过bug管理工具进行绘图，绘好就很容易看出bug随测试时间的变化趋势，不同的绘图方式，还能体现出什么类型的、什么级别，那个功能，谁负责的部份，由于什么原因等bug的趋势情况，这样就可以有针对性的加强那个部分，比如：bug图随着项目的逐步稳定，显示开发员A模块中的bug不断增加，没有任何递减的趋势，而其它相关开发员的模块bug不断下降，这时就要研究一下A开发员的工作了，是什么原因造成的，还是个人编码习惯等问题喽。。又比如：通过整体bug走势，可以一定程度上预测产品会达标的大概日期，因为bug曲线终归要近似趋零或达到可允许的范围（严重级别与个数）
－在TD中可以绘制bug图附件中(有两幅刚截的参考图)
－在testtrack中也可以.（我只发现表格形式的)

2）严格来说，一个项目过程中的BUG走向应该是符合一定规律的，但由于我们外部条件和内部条件的因素，导致我们的曲线与书上所介绍的曲线有很大差异。
3）大家应该更加注重的是这个曲线有何实际意义，对于测试、开发、以及成本等有何影响，就目前的测试的环境来看，研究这个曲线意义不大。测试人员可能还管不了那许多，还有即使有权力干涉开发人员的工作，但这也不能说明什么问题，反而招来非议，程序的编写主观性与客观性都存在，从这个曲线中不能反应任何关于开发人员的问题。对开发人员的评价自有另外的方法。而这个曲线的不正常，也可能与测试人员有关，很难保证所有测试人员一直都能保持一个正常的发挥其测试能力。

一句话：这个曲线中看不中用！最多只能直观的说明某阶段发现了多少BUG。其它什么都说明不了。
4）我是这么看的,
BUG曲线纵轴是Bug数,而横轴根据你自己的定义,可以产生好多种类的曲线图,你可以将横轴定义为时间,或定义为人力资源,或定义为用例数等等,根据横轴定义的不同可以产生好多Bug曲线图.就看你怎么定义,怎么发明了.当然,你的定义肯定对你以后的度量工作产生积极的意义,那你的"发明"也真正有意义和作用
5）如果你们的测试部门绝对独立，过程绝对严格，那这个曲线很能反映情况，否则。。。
6）Bug 的曲线有很多种，就拿ClearQuest中来说，你可以根据自己的需要进行定制
一般我用的比较多的有下面几种：
新Bug的产生曲线：主要看每天新增bug的情况，理想情况应该是开始的时候不是很多，然后很快达到高峰，急剧减少，但是中间会有小的波动，这样的曲线是比较理想的
系统中总的Bug曲线：这个是去掉解决完的bug的图，理想的情况和尚一个差不多，只是减少的会慢一点，波动也会大一些
Bug的修复趋势：这个土我一般拿系统中的新增Bug，当天Close的bug放在一起看
当然还有其它很多的图，我们会根据需要进行设定。其实我的意思就是大家不要拘泥于别人的形式，要根据自己的情况来做。
我们这里每天一个项目大概每个人能报到7-10个bug,算是挺多了。
CQ的功能很强大，可以定制各种反应软件不同指标的表格或者曲线。至于说到如何考核的问题，也是不能依葫芦画瓢。不同的公司，不同的系统架构，不同的企业文化，对考核的指标都会有不同的看法。
Bug的修复率本身这个指标在不同的时期，我想期望值应该不同。而且这些指标并不能反映项目的好坏，就像我们公司现在实行SQA一样，稽核没有抓住实质的东西，没有细致的曲分析，相当于是为了稽核而稽核，就失去了意义了。每次老总问他们，这个项目的异常点这么多，是不是这个项目就是做的不好？他们总是回答不出。
我建议你可以拿以前做的一个较好的项目，统计一下它的各项指标，然后可以把这些作为一个参考值，在后面的项目中发现这个指标不合理就及时调整。

尽信书则不如无书，很多软件测试的专业资料上的指标是一种很理想的指标，或者是很成熟的公司，体制下的指标，我们如果生搬硬套，会很痛苦。
10．负载测试与压力测试有何区别？
1）压力测试是在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。
负载测试：在一定的工作负荷下，给系统造成的负荷及系统响应的时间。
从概念上区别他们，可以看出压力测试有个长时间运行，而负载测试负载类型可能是其他类型的。
压力测试主要是为了发现在一（任意）定条件下软件系统的性能的变化情况。通过改变应用程序的输入以对应用程序施加越来越大的负载（并发，循环操作，多用户）并测量在这些不同的输入时性能的改变，也就是通常说的概念：压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。其实这种测试也可以称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
比如实际中我们说从比较小的负载开始，逐渐增加模拟用户的数量， 直到应用程序响应时间超时，就是说的负载测试。
2）负载测试更多的是在正常的工作条件下，验证系统的容量是否达到要求
例如，一个服务器，能支持10万人同时访问，那么负载测试就是要测出在用户为10万人时，服务器是否还在正常工作的状态下，例如CPU的占用，内存的占用等。
压力测试呢一般指在超过正常负载的情况下系统的能力，例如CPU占用正常工作应该低于50%，那么如果在一定的负载下，CPU的占用率达到80%，甚至100%，那么整个系统是否还能工作，而不是down机。还有，压力测试还应该包括在大负载下的异常处理能力。
3）负载测试主要测试在给定的负载情况下，检测系统是否达到系统预期的性能目标。
压力测试主要是在通过系统给定的预期的性能目标情况下，在逐渐给系统进行加压，测试系统在什么样的情况下，系统会产生异常。
4）简单总结一下:
压力：长时间连续运行，增加超负荷（并发，循环操作，多用户），什么时候系统会产生异常，以及异常处理能力，验证系统可靠性，找出瓶颈所在。
负载：一个很短时间内，处理一个巨大的数据量或执行许多功能调用上的能力,验证系统预期的性能目标，响应时间等。
11．如何设计编制软件测试用例（一~三）
这是我们公司的培训资料,我看文件的保密级是大众级,发上来应该没事,希望对大家有点帮助,特别是新人.
一、测试用例是软件测试的核心
软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

二、什么叫测试用例
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

三、编制测试用例
着重介绍一些编制测试用例的具体做法。

1、测试用例文档
编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。
如何设计编制软件测试用例(二)

2、测试用例的设置
我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

按功能测试是最简捷的，按用例规约遍历测试每一功能。

对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

3、设计测试用例
测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

四、测试用例在软件测试中的作用
1、指导测试的实施
测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
如何设计编制软件测试用例(三)

2、规划测试数据的准备
在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3、编写测试脚本的"设计规格说明书"
为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4、评估测试结果的度量基准
完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5、分析缺陷的标准
通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

五、相关问题
1、测试用例的评审
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

2、测试用例的修改更新
测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

12．软件测试的14种类型
软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

1 数据和数据库完整性测试

数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
数据库完整性原即：
主码完整性：主码不能为空；
外码完整性：外码必须等于对应的主码或者为空。
数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。

比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。
员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。


2 白盒测试

白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
2.1 静态白盒测试
利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下：
Function NameGet(){
….
}
这是属于不符合开发规范的错误。
有这样一段代码:
if (i<0) & (i>=0)
…
这段代码交集为整个数轴，IF语句没有必要
I=0;
while(I>100){
J=J+100;
T=J*PI;
}
在循环体内没有I的增加,bug产生。

2.2 动态白盒测试
利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
看一段代码
if(I<0){
P1
}else{
P2
}
在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷

3.功能测试

功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。

4.UI测试

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。

5.性能测试

性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试
5.1负载测试
负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？
5.2强度测试
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。
5.3数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
5.4基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。
5.5竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

6. 安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
6.1应用程序级别的安全性
可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？
6.2系统级别的安全性
可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

7.故障转移和恢复测试

故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？
8.配置测试

又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）
下面列出主要配置测试
8.1浏览器兼容性
测试软件在不同产商的浏览器下是否能够正确显示与运行；
比如测试IE，Natscape浏览器下是否可以运行这套软件？
8.2操作系统兼容性
测试软件在不同操作系统下是否能够正确显示与运行；
比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？
8.3硬件兼容性
测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.
比如在INTER,舒龙CPU芯片下系统是否能够正常运行？
这样的测试必须建立测试实验室，在各种环境下进行测试。

9.安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

10.多语种测试

又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
本地化测试还要考虑：
l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。

11.文字测试

文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。
比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。

12.分辨率测试

测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

13发布测试

主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试

13.1说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确
13.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片
13.3帮助文件测试
帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。
13.4广告用语
产品出公司前的广告材料文字，功能，图片，人性化的检查

14 文档审核测试

文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：

文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。

14.1需求文档测试

主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；

14.2设计文档测试

测试设计是否符合全部需求以及设计是否合理。

总结

据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型。

参考文献
《Rational统一过程模型》
《软件测试》
bug管理主要有VSS，TD，TD专业点，VSS常用在版本和文档管理
测试软件针对不同的测试环节也分很多种
不过，个人认为，测试新手不要把眼光盯在各种测试软件上
首先必须对测试理论和公司的软件产品要有个基本的概念
然后熟悉一下测试流程
在自己写几个测试计划
当你对测试有个比较深刻的认识后
在去考虑应用WR.CUINT等测试软件
我觉得这样可能更有利个人的发展

13．软件开发全过程检测及测试自动化

　　首先谈谈软件测试。这可以说是一个非常令人捉摸不定的领域。“应该怎样对我们的产品进行测试？”和“怎样才算对产品进行了足够的测试？”等问题，对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品，实际操作上都会有很大的不同。

　　SEI的SW-CMM在它的成熟度第三级的“软件产品工程”关键过程域中，把软件开发周期中不同阶段的测试作为实施活动中的关键实践。（在SW-CMM版本2.0 的讨论过程中，曾经有过提议，在成熟度第二级设立一个关键过程域“软件测试管理”。但在版本2.0 的讨论稿C 中，并没有这样做。从这里我们也可以看出，SW-CMM本身也是一个人为地制定的“软件”。）

　　一般地，基于开发周期中不同阶段对不同对象所进行的测试，可划分为：

　　单元测试（unit test ）：

　　由编程的开发人员自行计划与完成的，针对单个或相关联的一组程序单元的测试。

　　组装测试（inegration test ）：

　　计划于设计阶段，由开发人员与测试人员合作完成的，针对结合起来的不同单元以及它们的接口的测试。

　　系统测试（system test ）：（可认为包括“可用性与图形用户界面测试”）

　　测试整个系统，以证实它满足要求所规定的功能、质量和性能等方面的特性。

　　回归测试（regression test ）：

　　用于验证改变了的系统或其组件仍然保持应有的特性。

　　验收测试（acceptance test ）：

　　测试整个系统，以保证其达到可以交付使用的状态。

　　关于上述各阶段的测试的具体内容及实现的方法，读者可参考SW-CMM及有关软件工程和软件测试的书籍。千万不要停留在只参考SW-CMM，因为该文件只讲述要做些什么，而没有介绍怎样做。同时，所有的资料中谈及的内容及方法，都是一般化的。对于一个特定软件的测试，必须经过使用者对通用的测试方法的改变及改进，才能有效和达到高效率。

　　下面，谈谈软件测试的其他方面的一些问题。

　　一个被人忽略的软件测试目的

　　在谈到测试时，许多作者都引用了Grenford J. Myers 就软件测试目的提出的以下观点：

　　1.测试是程序的执行过程，目的在于发现错误；

　　2.一个好的测试用例在于能发现至今未发现的错误；

　　3.一个成功的测试是发现了至今未发现的错误的测试。

　　这是一种比较狭窄的观点。作为一个清醒的、纵观全局的软件开发人员或管理者，我们应当从软件过程的角度来看测试。

　　一个被人忽略的软件测试目的是：测试可以帮助发现当前开发工作所采用的软件过程（也是一个“软件”）的缺陷，以便进行改进。（在以下的讨论中，“错误”与“缺陷”基本上认为代表相同意义。）

　　怎样理解这种说法呢？

　　首先，测试并不仅仅是为了要找出错误。分析错误产生的原因和错误在开发的哪一个阶段产生，具有非常重要的意义。

　　通过分析错误的原因，我们可以立即在开发行动中对其进行改正。同时，这种分析也能帮助我们推理出 与所分析的错误有关联的潜在错误，从而有针对性地设计出检测的方法。

　　通过分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现，我们可以判断从错误的产生到错误的发现，跨越了多少个开发阶段。软件开发的一条重要原则是尽早发现与修正错误。（当然，更高的一条原则是尽量预防错误的出现。）一个错误能够超越本开发阶段而不被发现，就指明了该开发阶段的检测手段有缺陷，从而也不难有针对性地制定出加强的措施与办法。这也就是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现及修正错误，该开发机构就可以预期有一个高质量的产品及一个低成本、高效率的软件过程。

　　有些项目的主持人，认为以尽快的速度把测试之前的所有开发阶段完成（实际并没有完成），早日开始测试，以图达到快速和高质量（因为似乎有更长的时间可用于测试）。实际的效果将会是俗语所说的“欲速不达”。从常识就可以知道，花开发时间去继续扩大发展前面阶段引入的错误，得出的只能是更大量的需要耗时修正的错误。

　　因此，正确分析与利用测试的结果，我们可以非常有效地进行软件过程改进。

　　软件开发全过程检测，力争本阶段修正错误

　　从上面的讨论，我们很自然的就能领会到，软件错误的发现绝不能等到测试才开始（按常规，最早的测试就是编码后的单元测试）。因此，笔者提出一个软件工程的守则：软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开发的“实现阶段”才开始的，在此之前的“可行性研究与计划阶段”，“需求分析阶段”，“概要设计阶段”，和“详细设计阶段”，都必须有非常明确切实的手段与措施对开发结果进行检验，以保证阶段的正确完成。

　　怎样判断一个软件过程的优劣，怎样进行软件过程改进，都可以在这个守则的指导下进行。这个守则是简单明确的，但因企业背景、条件的不同，开发环境条件的不同，项目产品的不同，实际的软件过程的实现方法就会变化无穷。考虑实现这个原则的方法的时候，可以尽量多参考各种理论及经验，但在选择制定本企业开发实践中使用的软件过程时，就必须处处根据是否能给自身的项目带来好处，以及自身的条件进行考虑。千万不要仅仅为了满足某个“标准”的提法而做一些无实际意义的工作。要尽量避免烦琐，争取做到简单、有条理和有最大的效果。

　　软件测试的自动化

　　软件测试的工作量很大（据统计，会用到40% 的开发时间；一些可靠性要求非常高的软件，测试时间甚至占到总开发时间的60% ），但测试却是在整个软件过程中极有可能应用计算机进行自动化的工作，原因是测试的许多操作是重复性的、非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完成这些任务。企业在这方面的投资，会对整个开发工作的质量、成本、和周期带来非常明显的效果。

　　一些适于考虑进行自动化的测试操作为：

　　1.测试个案的生成（包括测试输入，标准输出，测试操作指令等）。

　　2.测试的执行写控制（包括单机与网络多机分布运行；夜间及假日运行。测试个案调用控制；测试对象、范围、版本控制等。）。

　　3.测试结果与标准输出的对比。

　　4.不吻合的测试结果的分析、记录、分类、和通报。

　　5.总测试状况的统计，报表的产生。

　　测试自动化与软件配置管理是密不可分的。与测试有关的资源都应在配置管理中进行统一的计划考虑。另外，测试工具的采用也是一个提高质量的关键，有些专用的测试工具能帮助发现一些用任何测试个案都难以触及的错误。
14.安装与卸载测试－我的学习总结

前几天发表了“如何进行卸载测试”的贴子，得到很多回复，这里表示感谢！
通过认真地学习与总结前辈们的宝贵经验，现整理一部分如下，主要是加深自己对它们的理解，还有希望大家继续补充与给出建议，谢谢！
软件安装与卸载测试是相辅相成，通过互相补充，会发现更多的测试角度，谢谢

============卸载测试==============
文件－－－－安装目录里的文件及文件夹（如：程序安装在几处的)
　　　　　　非安装目录（向系统其它地方添加的文件及文件夹）
    它们包括（exe,dll,配置文件等)
快捷方式－（桌面，菜单，任务栏，系统栏,控件面板，系统服务列表等）
复原方面－卸载后，系统能否恢复到软件安装前的状态（包含目录结构、动态库,注册表，系统配置文件,驱动程序,关联情况等）
卸载方式－－程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具（如:优化大师)
卸载状态－－程序在运行/暂停/终止等状态时的卸载
非正常卸载情况－卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用
冲击卸载－－在卸载的过程中，中断电源，然后，启动计算机后，重新卸载软件，如果软件无法卸载，则重新安装软件，安装之后再重新卸载。
卸载环境－－不同的(操作系统，硬件环境，网络环境等)下进行卸载
卸载后,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)
==========安装测试============
一：基本目标
1.安装程序能正确运行
2.程序安装正确
3.程序安装后能正确运行
4.完善性安装后程序能正确运行
二：一些方面
0、安装手册给的所有步骤得到验证；
1、安装过程中所有缺省选项得到验证；
2、安装过程中典型选项得到验证；
3、测试各种不同的安装组合，并验证各种不同组合的正确性(包括参数组合，控件执行顺序组合，产品安装组件组合，产品组件安装顺序组合(如b/s)等)
4、安装过程中异常配置或状态（非法和不合理配置）情况进行了测试(如：断电；数据库终止，网络终止等)
5、安装后是否能产生正确的目录结构和文件，文件属性正确；
6、安装后动态库是否正确；
6、安装后软件能否正确运行；
7、安装后没有生成多余的目录结构,文件，注册表信息，快捷方式等；
9、安装测试应该在所有的运行环境上进行验证(手册上指定如：操作系统，数据库，硬件环境，网络环境等)；
10、自动安装还是手工配置安装
11、至少要在一台笔记本上进行安装/卸载测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品
13、安装,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)
15.微软的测试题

Test Paper for Software Design Engineer

(Test time: 60 minutes)

Name:         Date:         Location:



Part 1: Technical Skills Set

（请将 “ ● ”paste在您所掌握的技能程度表格内，并注明您的使用时间和相关的证书）

技能列表 精通   熟练   掌握   了解   使用时间(月) 所获证书

English (oral)

English (written)

OOP programming skills

C/C++ (pointer, memory)

Java

C#

NET

算法&数据结构

Win API experience –plus


Part 2 : Technical Test

1． 实现二分查找的递归算法的函数。（使用C++，不建议用伪码）











2． 请指出该程序的错误。

#include <iostream.h>



int *p;



void Function();

{

int n;

n = 25;

p = &n;

}



void main()

{

Function();

cout<<"value of *p: "<<*p<<endl;

}













3. 英语写作

Question: Please describe your career path in the next two years.
16. 多线程与多进程
线程的外壳是进程，进程管理线程；
线程不占用系统资源，而进程占用系统资源；
什么叫进程？进程同程序有什么区别？
答:进程是程序在计算机上的一次执行活动。当你运行一个程序，你就启动了一个进程。显然，程序是死的(静态的)，进程是活的(动态的)。进程可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程，它们就是处于运行状态下的操作系统本身；用户进程就不必我多讲了吧，所有由你启动的进程都是用户进程。进程是操作系统进行资源分配的单位。
在Windows下，进程又被细化为线程，也就是一个进程下有多个能独立运行的更小的单位。
在同一个时间里，同一个计算机系统中如果允许两个或两个以上的进程处于运行状态，这便是多任务。现代的操作系统几乎都是多任务操作系统，能够同时管理多个进程的运行。 多任务带来的好处是明显的，比如你可以边听mp3边上网，与此同时甚至可以将下载的文档打印出来，而这些任务之间丝毫不会相互干扰。那么这里就涉及到并行的问题，俗话说，一心不能二用，这对计算机也一样，原则上一个CPU只能分配给一个进程，以便运行这个进程。我们通常使用的计算机中只有一个CPU，也就是说只有一颗心，要让它一心多用，同时运行多个进程，就必须使用并发技术。实现并发技术相当复杂，最容易理解的是“时间片轮转进程调度算法”，它的思想简单介绍如下：在操作系统的管理下，所有正在运行的进程轮流使用CPU，每个进程允许占用CPU的时间非常短(比如10毫秒)，这样用户根本感觉不出来CPU是在轮流为多个进程服务，就好象所有的进程都在不间断地运行一样。但实际上在任何一个时间内有且仅有一个进程占有CPU。
　如果一台计算机有多个CPU，情况就不同了，如果进程数小于CPU数，则不同的进程可以分配给不同的CPU来运行，这样，多个进程就是真正同时运行的，这便是并行。但如果进程数大于CPU数，则仍然需要使用并发技术。
　　在Windows中，进行CPU分配是以线程为单位的，一个进程可能由多个线程组成，这时情况更加复杂，但简单地说，有如下关系：

　　总线程数<= CPU数量：并行运行

　　总线程数> CPU数量：并发运行

　　并行运行的效率显然高于并发运行，所以在多CPU的计算机中，多任务的效率比较高。但是，如果在多CPU计算机中只运行一个进程(线程)，就不能发挥多CPU的优势。

这里涉及到多任务操作系统的问题，多任务操作系统(如Windows)的基本原理是:操作系统将CPU的时间片分配给多个线程,每个线程在操作系统指定的时间片内完成(注意,这里的多个线程是分属于不同进程的).操作系统不断的从一个线程的执行切换到另一个线程的执行,如此往复,宏观上看来,就好像是多个线程在一起执行.由于这多个线程分属于不同的进程,因此在我们看来,就好像是多个进程在同时执行,这样就实现了多任务.Whoops，真绕口.

所以结合楼上的答复，不知道楼主是否可以满意！

关于多线程，多进程的问题，楼主可以看看操作系统方面的书，可以得到更多的启示！


　　如上,多线程和多任务是有很明显的区别的.但是再想一下,在一个应用程序内实现多线程不也是靠CPU分配时间片吗?既然原理是相同的,那么多线程也可以说是多任务的.

17．回归测试
回归测试和验证修复的bug不是等同的.回归测试要求在新的版本中,重新遍历测试用例,因为开发人员在解决问题时可能会影响到相关的模块,只验证修复的问题是否已经解决不能叫做回归测试.
我们最新采用的回归测试的方法是：把所有的测试说明中的用例全部执行一遍！（很麻烦的说）
然后对于初次测试出问题的地方及其边缘重点测试！
1、关于Bug的状态前面有帖子楼主可以看看，开发人员如果认为Bug已修复，应把Bug的状态改成Resolved，测试人员发现有Resolved的Bug就要进行回归测试以验证Bug是否真的解决，如验证通过则将Bug的状态改成Verified Pass，然后再由相关人员（如测试负责人）把Bug的装体改成Closed；如验证失败则将Bug的状态改成Verified Fail，让开发人员再去解决。
2、关于楼主提到的“但是在测试用例很多的情况下，自己可能也不记得那些测试用例中有实际结果与期望结果不一致的用例”说明Bug的提交和记录存在问题，Bug所对应的测试用例编号是肯定要包含在Bug报告中的，这样回归测试的时候就不会搞不清楚了。
3、现在开源的Bug管理工具也是有的，如bugzilla，最好还是去装一个吧。

Bug的状态各个公司会不同，多少也不一样，我原来在德公司就有30来种状态。呵呵！
一般只要能够区分下面几种情况，并且不让人误解就好了
1，新提交的Bug
2，开发正在修改的Bug
3，已经修改好并且等待测试人员验证的Bug
4，验证通过的Bug
5，验证没有通过的Bug（这个要和新提交的Bug同样处理，不过有的公司需要记住没有改好的次数，用来考评开发的绩效）
6，设计问题
7，测试人员报错
8，暂时不修改的Bug
回归测试的方法具体问题具体分析，可能有人说我这样等于什么都没说，可是每个项目不同，不同时期也不同，甚至可能测试的人员都换了，如果以一种固定的方法来做，未免显得有点死板。个人认为，在测试的时候，最好能够边测试，边在测试用例上加上备注，说明实际结果。并且最好用颜色标记，如果你够仔细，能够把有问题的测试用例再标注上Bug的编号就更好了，这样在复查bug时，就知道修改好的bug是由哪个用例引起的，可以执行一下相关的用例，看是否真的改好并且没有影响到其他部分，这样就可以放心的Close了。如果有人觉得这样太过麻烦或者中途有人员的变动，也可以只看Bug的描述，按照bug的说明进行验证就够了，但是要记住最好能够对相关的模块进行一下测试，看看流程是否还能走通。不过这就要求Bug的描述要写得比较清晰，明了。
18．测试大纲和测试计划

测试大纲只是简单的描述如何开展测试，而测试计划是针对测试中的每个环节的。单元测试、集成测试、系统测试等一般都写测试计划，写的重点不同。而大纲只是简要的写一下测试策略是什么，需要做哪些测试，测试过程如何组织，测试人员包括哪些。可以说管理人员写测试大纲，而测试人员写测试计划。

19．测试版本大全－转贴

alpha 内部测试版
　　beta 外部测试版
　　demo 演示版
　　Enhance 增强版或者加强版 属于正式版
　　Free 自由版
　　Full version 完全版 属于正式版
　　shareware 共享版
　　Release 发行版 有时间限制
　　Upgrade 升级版
　　Retail 零售版
　　Cardware 属共享软件的一种，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见。
　　Plus 属增强版，不过这种大部分是在程序界面及多媒体功能上增强。
　　Preview 预览版
　　Corporation & Enterprise 企业版
　　Standard 标准版
　　Mini 迷你版也叫精简版只有最基本的功能
　　Premium -- 贵价版
　　Professional -- 专业版
　　Express -- 特别版
　　Deluxe -- 豪华版
　　Regged -- 已注册版
　　CN -- 简体中文版
　　CHT -- 繁体中文版
　　EN -- 英文版
　　Multilanguage -- 多语言版
　　Rip 是指从原版文件（一般是指光盘或光盘镜像文件）直接将有用的内容（核心内容）分离出来，剔除无用的文档，例如PDF说明文件啊，视频演示啊之类的东西，也可以算做是精简版吧…但主要内容功能是一点也不能缺少的！另：DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来。
　　trail 试用版（含有某些限制，如时间、功能，注册后也有可能变为正式版）
　　RC 版。是 Release Candidate 的缩写，意思是发布倒计时，该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG，不会对软件做任何大的更改。
　　RTM 版。这基本就是最终的版本，英文是 Release To Manufactur，意思是发布到生产商。
　　Original Equipment Manufacturer (OEM)
　　You may license products through an Original Equipment Manufacturer (OEM). These products, such as Windows operating systems, come installed when you purchase a new computer.
　　OEM软件是给电脑生产厂的版本，无需多说。
　　Full Packaged Product (FPP)-Retail
　　Physical, shrink-wrapped boxes of licensed product that can be purchased in a local retail store or any local software retailer.
　　FPP就是零售版（盒装软件），这种产品的光盘的卷标都带有"FPP"字样，比如英文WXP Pro的FPP版本的光盘卷标就是WXPFPP_EN，其中WX表示是Windows XP，P是Professional（H是Home），FPP表明是零售版本，EN是表明是英语。获得途径除了在商店购买之外，某些MSDN用户也可以得到。
　　Volume Licensing for Organizations (VLO)
　　You may enjoy potentially significant savings by acquiring multiple product licenses. Depending on the size and type of your organization.
　　团体批量许可证（大量采购授权合约），这是为团体购买而制定的一种优惠方式。这种产品的光盘的卷标都带有"VOL"字样，取"Volume"前3个字母，以表明是批量，比如英文WXP Pro的VOL版本的光盘卷标就是WXPVOL_EN，其中WX表示是Windows XP，P是Professional（VOL没有Home版本），VOL表明是团体批量许可证版本，EN是表明是英语。获得途径主要是集团购买，某些MSDN用户也可以得到。
这种版本根据购买数量等又细分为“开放式许可证”、“选择式许可证”、“企业协议”、“学术教育许可证”等以下5种版本
　　Open License
　　Select License
　　Enterprise Agreement
　　Enterprise Subscription Agreement
　　Academic Volume Licensing
　　由此可见，平时说的什么select/corp是许可证授权方式，他的出现是为了用若干种不同级别的优惠政策卖同一种软件，通过select/corp许可证授权方式得到的xxx的光盘都是VOL这一种、是并不是有很多种，只不过是相同的VOL光盘配以不同的许可证方式；而Volume Licensing (Product) Keys，即VLK，它所指的只是一个Key（密匙），仅仅是一个为证明产品合法化、以及安装所使用的Key，因为根据VOL计划规定，VOL产品是不需要激活的！
　　或者说，VLK不是指一种版本，而是指这种版本在部署（deploy）过程中所需要的Key，而需要VLK这种Key的版本应该叫做VOL！只不过在实际中，没有必要强调这种叫法、称呼的准确性，加之很多人的VOL版本光盘是通过企业的选择式许可证、企业协议等方式得到的等等原因，所以才会有很多人叫他为“选择版”等等。
官方网站有一个表格，上面有一句话：“Different products require different Volume Licensing Keys (VLKs). Refer to the table below to make sure you have the correct VLK for your Microsoft product.”，我想这就很好的说明了VLK指的是Key而不是产品了。 很明显的，FPP需要激活，VOL不需要激活。
20. 黑、白盒测试

白盒测试和黑盒测试不是决然分开的，单独做黑盒测试或白盒测试都是做了测试的一个方面，很难保证发现了软件中大部分缺陷。在测试过程中往往把两者结合起来进行测试，从代码逻辑结构上保证正确，再从功能和非功能特性上保证正确，经过这两方面的测试，才能最大可能的保证软件质量。在测试过程中，采用这两种测试技术的时间有所不同。

单元测试、集成测试、系统测试是按照测试的阶段来进行划分的，而白盒测试、黑盒测试是从测试技术的角度来划分的。一般来说，单元测试阶段进行的测试基本上以白盒测试技术为主，系统测试阶段进行的测试基本上以黑盒测试技术为主，而集成测试所采用的技术是介于白盒和黑盒之间的，有的技术文献也称之为灰盒技术

软件测试是一个过程，一个完整的软件测试过程又分为三个阶段，分别是单元集成和系统（当然还有写别的测试过程），而黑盒和白盒只是在这些过程中所采用的测试方法罢了。

个人意见
1. 黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
2. 白盒测试
　　白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
　　“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
3. 灰盒测试
灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
  灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
21．Software Testing 10 Rules
1. Test early and test often.
尽早测试，经常测试
2. Integrate the application development and testing life cycles. You'll get better results and you won't have to mediate between two armed camps in your IT shop.(这后半句怎么理解？)
整合应用程序开发和软件测试生命周期，你将得到更好的结果，并且不必要在程序开发和软件测试两者之间左右为难。
3. Formalize a testing methodology; you'll test everything the same way and you'll get uniform results.
形成一套完整的测试方法；你将用同样的方法开展测试工作，并且可以得到始终如一的结果
4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
开发一套完整、全面的的测试计划；作为软件测试方法论的基础部分
5. Use both static and dynamic testing.
采用静态测试和动态测试相结合的方法（可以采用静态代码检查工具作静态测试）
6. Define your expected results.
定义测试预期结果（在测试用例中，这是比不可少的项目)
7. Understand the business reason behind the application. You'll write a better application and better testing scripts.
理解应用背后的商业动机，找出真正的需求根源，你将写出更好的应用程序和测试脚本。
8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
采用多层面和多类型的软件测试（回归测试、系统测试、集成测试、压力测试和负载测试）
9. Review and inspect the work, it will lower costs.
多工作评审和检视，可以降低成本（检视和评审可以提早发现问题，规避问题，避免造成不必要的损失，因此，可以降低成本）
10. Don't let your programmers check their own work; they'll miss their own errors.
不要让程序员检查自己的工作产品，程序员会忽略自己犯的错误。