一、安装
命令格式：
rpm -i ( or --install) options file1.rpm ... fileN.rpm
参数：
file1.rpm ... fileN.rpm 将要安装的RPM包的文件名
详细选项：
-h (or --hash) 安装时输出hash记号 (``#'')
--test 只对安装进行测试，并不实际安装。
--percent 以百分比的形式输出安装的进度。
--excludedocs 不安装软件包中的文档文件
--includedocs 安装文档
--replacepkgs 强制重新安装已经安装的软件包
--replacefiles 替换属于其它软件包的文件
--force 忽略软件包及文件的冲突
--noscripts 不运行预安装和后安装脚本
--prefix 将软件包安装到由 指定的路径下
--ignorearch 不校验软件包的结构
--ignoreos 不检查软件包运行的操作系统
--nodeps 不检查依赖性关系
--ftpproxy 用 作为 FTP代理
--ftpport 指定FTP的端口号为
通用选项
-v 显示附加信息
-vv 显示调试信息
--root 让RPM将指定的路径做为"根目录"，这样预安装程序和后安装程序都会安装到这个目录下
--rcfile 设置rpmrc文件为
--dbpath 设置RPM 资料库存所在的路径为
二、删除
命令格式：
rpm -e ( or --erase) options pkg1 ... pkgN
参数
pkg1 ... pkgN ：要删除的软件包
详细选项
--test 只执行删除的测试
--noscripts 不运行预安装和后安装脚本程序
--nodeps 不检查依赖性
通用选项
-vv 显示调试信息
--root 让RPM将指定的路径做为"根目录"，这样预安装程序和后安装程序都会安装到这个目录下
--rcfile 设置rpmrc文件为
--dbpath 设置RPM 资料库存所在的路径为
三、升级
命令格式
rpm -U ( or --upgrade) options file1.rpm ... fileN.rpm
参数
file1.rpm ... fileN.rpm 软件包的名字
详细选项
-h (or --hash) 安装时输出hash记号 (``#'')
--oldpackage 允许"升级"到一个老版本
--test 只进行升级测试
--excludedocs 不安装软件包中的文档文件
--includedocs 安装文档
--replacepkgs 强制重新安装已经安装的软件包
--replacefiles 替换属于其它软件包的文件
--force 忽略软件包及文件的冲突
--percent 以百分比的形式输出安装的进度。
--noscripts 不运行预安装和后安装脚本
--prefix 将软件包安装到由 指定的路径下
--ignorearch 不校验软件包的结构
--ignoreos 不检查软件包运行的操作系统
--nodeps 不检查依赖性关系
--ftpproxy 用 作为 FTP代理
--ftpport 指定FTP的端口号为
通用选项
-v 显示附加信息
-vv 显示调试信息
--root 让RPM将指定的路径做为"根目录"，这样预安装程序和后安装程序都会安装到这个目录下
--rcfile 设置rpmrc文件为
--dbpath 设置RPM 资料库存所在的路径为
四、查询
命令格式：
rpm -q ( or --query) options
参数：
pkg1 ... pkgN ：查询已安装的软件包
详细选项
-p (or ``-'') 查询软件包的文件
-f 查询属于哪个软件包
-a 查询所有安装的软件包
--whatprovides 查询提供了 功能的软件包
-g 查询属于 组的软件包
--whatrequires 查询所有需要 功能的软件包
信息选项
显示软件包的全部标识
-i 显示软件包的概要信息
-l 显示软件包中的文件列表
-c 显示配置文件列表
-d 显示文档文件列表
-s 显示软件包中文件列表并显示每个文件的状态
--scripts 显示安装、卸载、校验脚本
--queryformat (or --qf) 以用户指定的方式显示查询信息
--dump 显示每个文件的所有已校验信息
--provides 显示软件包提供的功能
--requires (or -R) 显示软件包所需的功能
通用选项
-v 显示附加信息
-vv 显示调试信息
--root 让RPM将指定的路径做为"根目录"，这样预安装程序和后安装程序都会安装到这个目录下
--rcfile 设置rpmrc文件为
--dbpath 设置RPM 资料库存所在的路径为
五、校验已安装的软件包
命令格式：
rpm -V ( or --verify, or -y) options
参数
pkg1 ... pkgN 将要校验的软件包名
软件包选项
-p Verify against package file
-f 校验所属的软件包
-a Verify 校验所有的软件包
-g 校验所有属于组 的软件包
详细选项
--noscripts 不运行校验脚本
--nodeps 不校验依赖性
--nofiles 不校验文件属性
通用选项
-v 显示附加信息
-vv 显示调试信息
--root 让RPM将指定的路径做为"根目录"，这样预安装程序和后安装程序都会安装到这个目录下
--rcfile 设置rpmrc文件为
--dbpath 设置RPM 资料库存所在的路径为
六、校验软件包中的文件
语法：
rpm -K ( or --checksig) options file1.rpm ... fileN.rpm
参数：
file1.rpm ... fileN.rpm 软件包的文件名
Checksig--详细选项
--nopgp 不校验PGP签名
通用选项
-v 显示附加信息
-vv 显示调试信息
--rcfile 设置rpmrc文件为
七、其它RPM选项
--rebuilddb 重建RPM资料库
--initdb 创建一个新的RPM资料库
--quiet 尽可能的减少输出
--help 显示帮助文件
--version 显示RPM的当前版本
posted @
2007-06-06 20:48 软件测试大本营 阅读(80) |
评论 (0) |
编辑一、JDK安装
1、RPM in self-extracting file (j2sdk-1_4_2_04-linux-i586.bin, 32.77 MB) 这个是自解压的文件，在linux上安装如下：
# chmod u+x ./j2sdk-1_4_2_04-linux-i586.bin
# ./j2sdk-1_4_2_04-linux-i586.bin
在按提示输入yes后，jdk被解压到./j2sdk1.4.2_04目录下。为与下面2中JDK安装路径一致，我们进行下列操作,在/usr/java下建立安装路径，
并将文件考到该路径下：
# mkdir /usr/java
# cp -fr ./j2sdk1.4.2_04 /usr/java
2、RPM in self-extracting file (j2sdk-1_4_2_04-linux-i586-rpm.bin, 32.77
MB)这个也是一个自解压文件，不过解压后的文件是j2sdk-1_4_2_04-linux-i586-rpm包，执行rpm命令装到linux上就可以了。安装如下：
#chmod u+x ./j2sdk-1_4_2_04-linux-i586-rpm.bin
# ./j2sdk-1_4_2_04-linux-i586-rpm.bin
# rpm -ivh j2sdk-1_4_2_04-linux-i586-rpm
安装软件会将JDK自动安装到 /usr/java/j2sdk1.4.2_04目录下。
二、配置环境变量
1.修改用户环境变量
假设使用java的用户为 kunp，编辑该用户的.bashrc文件进行环境变量设置。
# vi /home/kunp/.bashrc
在 .bashrc文件中加入：
export JAVA_HOME=/usr/java/j2sdk1.4.2_04
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH:$HOMR/bin
2.修改所有用户的环境变量
# vi /etc/profile
在该文件中加入:
export JAVA_HOME=/usr/java/j2sdk1.4.2_04
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH:$HOMR/bin
一定要在CLASSPATH路径中加入$CLASSPATH:
posted @
2007-05-29 15:46 软件测试大本营 阅读(23) |
评论 (0) |
编辑安装好Rational RequisitePro后，新建立一个project时，要选择库的类型，可以支持MS Access、SQL SERVER和oralce
首先在SQL SERVER里新建一数据库名为”RequisitePro”
然后在查询分析器里执行其自带的脚本文件，位置在《Rational安装目录》\requisitepro\database\sqlserver目录下，依次执行下列文件
Login and user.sql
Tables and indexes.sql
Triggers.sql
Initial data.sql
在RequisitePro里新建project里，选择SQL SERVER，然后单击properties..按钮
单击config按钮，选择SERVER，单击下一步，输入login ID和password,password是reqpro
单击下一步，选择改变默认数据库复选框，并选择刚才建立的RequisitePro数据库，配置完成后，单击account info按钮，输入password是reqpro，在schema中输入ReqPro，单击OK完成配置,单击valivade按钮可以测试一下是否配置成功
posted @
2007-03-19 07:57 软件测试大本营 阅读(111) |
评论 (0) |
编辑
ClearQuest 7.0.0新版本的所有软件包及主要功能:
AMBaseActivity 与MS Project Tracker集成时应用
AMWorkActivitySchedule 与MS Project Tracker集成应用
AMStateTypes UCM集成应用，完成状态匹配
ATStateTypes 部署跟踪管理DeploymentTracking
Attachments 附件管理
AuditTrail 审计跟踪管理
BaseCMActivity UCM另一种Activity,生成另一种记录类型
BTStateTypes 部署跟踪管理DeploymentTracking
BuildTracking 部署跟踪管理DeploymentTracking；
CharacterSetValidation 数据/代码页转换
ClearCase Base ClearCase集成应用
CQTM TestManager 在ClearQuest中的部署应用
CrossPlatformSCM 提供跨平台编译（本地的ClearCase与远程Z/OS）
Customer 顾客管理
DeploymentTracking 部署跟踪管理
DTStateTypes 部署跟踪管理DeploymentTracking
Email 电子邮件规则管理
EnhancementRequest 需求记录
eSignature 电子签名管理
History 历史记录
Notes 注释
PQC Purify, Visual Quantify, and Pure-Coverage集成部署
Project 项目工程
RequisitePro 与Rational ReqPro集成部署应用
RequisiteProSupplement Rational ReqPro集成应用
Resolution 解决方法
TeamTest 与PQC集成应用
TPM 与IBM Tivoli集成，完成部署管理
UCMPolicyScript UCM集成应用
UnifiedChangeManagement ClearCase UCM集成部署应用
VisualSourceSafe 与MS VSS集成应用
posted @
2007-03-18 18:32 软件测试大本营 阅读(86) |
评论 (0) |
编辑
误区之一：软件开发完成后进行软件测试
人们一般认为，软件项目要经过以下几个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件发布。据此，认为软件测试只是软件编码后的一个过程。这是不了解软件测试周期的错误认识。软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。因此，软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，那么，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。
误区之二：软件发布后如果发现质量问题，那是软件测试人员的错
这种认识很打击软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因为从根本上讲，软件测试不可能发现全部的错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。出现软件错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于混乱的项目管理。应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。
误区之三：软件测试要求不高，随便找个人多都行
很多人都认为软件测试就是安装和运行程序，点点鼠标，按按键盘的工作。这是由于不了解软件测试的具体技术和方法造成的。随之软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。所以，具有编程经验的程序员不一定是一名优秀的测试工程师。软件测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习精神。
误区之四：软件测试是测试人员的事情，与程序员无关
开发和测试是相辅相成的过程，需要软件测试人员、程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误，很多需要程序员通过修改编码才能修复。程序员可以通过有目的的分析软件错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力。
误区之五：项目进度吃紧时少做些测试，时间富裕时多做测试
这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。一个软件项目的顺利实现需要有合理的项目进度计划，其中包括合理的测试计划，对项目实施过程中的任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单的缩短测试时间、人力和资源。因为缩短测试时间带来的测试不完整，对项目质量的下降引起的潜在风险，往往造成更大的浪费。克服这种现象的最好办法是加强软件过程的计划和控制，包括软件测试计划、测试设计、测试执行、测试度量和测试控制。
误区之六：软件测试是没有前途的工作，只有程序员才是软件高手
由于我国软件整体开发能力比较低，软件过程很不规范，很多软件项目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和待遇。因此，在这种环境下，软件测试不受重视，软件测试人员的地位和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员还要高。软件测试将会成为一个具有很大发展前景的行业，软件测试大有前途，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样是软件专家。
posted @
2007-03-17 11:56 软件测试大本营 阅读(67) |
评论 (0) |
编辑
Rational系列工具贯穿于整个软件开发生命周期，覆盖了分析设计、需求管理、配置管理、测试管理、缺陷管理、功能测试、性能测试、单元测试等方面。以下是一些常用的Rational工具：
1、Robot 用于功能回归测试和性能测试测试脚步的自动生成和手工修改
2、TestManager 是一个测试管理工具，其中有测试计划、测试用例、测试执行的管理，性能测试的运行场景在这里部署
3、Purfiy 用于白盒测试，测试C、C＋＋、java程序的内存泄漏
4、purCoverage 代码覆盖测试工具，用于检查测试用例是否完全覆盖了被测试程序、序，或者覆盖率等
5、ClearCase 配置管理工具
6、ClearQuest Bug管理工具和Project集成
7、SiteCheck 网站连接检查工具，用于检查网站的坏连接，快速实用
8、Rose 分析设计工具 开发设计人员必用的工具
9、Rup 文档描述，Rational 统一开发过程描述 与CMM紧密相关
Rational系列产品大概的介绍
Rational Application Developer for WebSphere Software
用于架构和建模、模型驱动开发、组件、组件测试、运行时分析活动的工具。
Rational Professional Bundle
提供企业级桌面工具，以便设计、构建和测试J2EE/门户/面向服务的应用程序。
Rational Rose Developer for UNIX
提供行业领先的模型驱动开发工具。
Rational Rose Technical Developer
一个模型驱动开发解决方案，针对Java、C、C＋＋自动进行从设计到代码的转换。
Rational Rose XDE Developer for Java
为基于J2EE 的系统提供完整的可视化设计和开发环境。
Rational Rose XDE Developer for Visual Studio
为基于.NET 的系统提供完整的可视化设计和开发环境。
Rational Rose XDE Developer Plus
为基于J2EE 和基于.NET 的系统提供可视化设计和开发环境。
Rational Software Architect
利用 UML 为模型驱动开发提供整合设计和开发支持。
Rational Software Modeler
支持 UML 可视化建模/设计，从不同的视图编制系统文档。
Rational Suite DevelopmentStudio for UNIX
合并屡获殊荣的开发工具，帮助人们更快速地构建更好的软件。
Rational Suite for Technical Developers
支持诸如实时和嵌入式技术应用程序的可视化开发。
Rational Web Developer for WebSphere Software
简化和加速了 Web、Web 服务和 Java 开发。
过程和项目管理
Rational Portfolio Manager
协调优先级、项目和人员。
Rational ProjectConsole
提供项目 Web 站点和度量指示板。
Rational SoDA
在整个生命周期中自动化软件项目的文档编制工作。
Rational Suite
提供最佳实践、工具和服务的完整而整合的生命周期解决方案。
Rational SUMMIT Ascendant
为交付企业级 IT 项目提供方法库。
Rational Team Unifying Platform
允许公共访问开发资产、需求和过程指导。
Rational Unified Process
经过验证的开发过程，可进行配置以满足您的项目要求。
需求分析
IBM Rational RequisitePro
需求和使用案例管理的强大、简便易用的集成产品，有助于促进更全面的通信，增强团队协作和降低项目风险。
IBM Rational Rose Data Modeler
数据库设计人员、分析人员、开发人员以及开发小组中的任何人能够协作的可视建模工具，从而能够捕获和共享企业需求，在整个流程中跟踪需求的变化。
IBM Rational Rose XDE Modeler
使设计人员能够使用统一建模语言（UML）来进行由模型驱动的开发。用户可以建立与平台无关的软件架构、企业需求、可重复使用的资产和管理级通信模型。
软件配置管理
Rational ClearCase
为大中型开发团队提供可靠的、可伸缩的和灵活的软件资产管理。
Rational ClearCase and MultiSite
为地域性分布式环境提供完整的软件资产管理。
Rational ClearCase Change Management Solution Enterprise Edition
为大中型项目和分布式团队提供集成的软件配置管理。
IBM Rational ClearCase LT
为中小型集中项目团队提供可靠的、入门级版本控制思路。
Rational ClearCase MultiSite
支持跨地域性分布式环境的并行开发方式。
Rational ClearQuest
在整个应用程序开发生命周期中提供灵活的缺陷和变更跟踪功能。
Rational ClearQuest and MultiSite
为地域性分布式环境提供完整的缺陷和变更跟踪功能。
Rational ClearQuest MultiSite
支持整个分布式环境中的缺陷和变更跟踪。
软件质量
Rational Functional Tester
对 Java、Web 和基于 VS.NET WinForm 的应用程序进行高级自动化功能测试。
Rational Functional Tester Extension for Terminal-based Applications
扩展了Rational Functional Tester，以支持基于终端的应用程序的测试。
Rational Manual Tester
使用新测试设计技术来改进人工测试设计和执行工作。
Rational Performance Tester
检查可变多用户负载下可接受的应用程序响应时间和可伸缩性。
Rational Purify for Linux and UNIX
为 Linux 和 UNIX提供了内存泄漏和内存损坏检测。
Rational Purify for Windows
为 Windows 提供了内存泄漏和内存损坏检测。
Rational PurifyPlus 企业版
为 Windows、Linux 和 UNIX 提供了运行时分析。
Rational PurifyPlus for Linux and UNIX
为 基于 Linux 和 Unix 的 Java 和 C/C++ 开发提供了分析工具集。
Rational PurifyPlus for Windows
为基于 Windows的Java、C/C++、Visual Basic 和 托管 .NET 开发提供了运行时分析。
Rational Robot
客户机/服务器应用程序的通用测试自动化工具。
Rational TestManager
提供开放、可扩展的测试管理。
Rational Test RealTime
支持嵌入式和实时的跨平台软件的组件测试和运行时分析。
传统语言和调试工具
Rational Ada Developer
为基于 Ada 的应用程序提供集成开发环境
posted @
2007-03-16 13:39 软件测试大本营 阅读(370) |
评论 (0) |
编辑
）代表多个源代码文件的一组版本。
比如有三个文件，aaa.c、bbb.c和ccc.h。可以对这三个文件做一个基线，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一个基线。换
句话说，通常在vss和cvs里面做label，就是在做基线。
这种基线对“构建审计”特别有用：在做build的时候，可以先对所有源文件做一个label，取名为"Build2394"，然后再编译、集成。这样，以后如果要找到和build 2394对应的原文件，只需要
到vss或者cvs里面把所有文件对应label Build2394的版本取回来就可以了。
2）代表文档的一个稳定状态。
比如有一个项目设计文档，当设计基本完成，开发即将开始的时候，需要把这个文档固定下来，内容不能再频繁改变，否则开发人员就无所适从了，可能导致每个人所参照的文档并不是同一个文档。
一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被“基线化”了，然后所有人就可以在这个“基线”的基础上工作。
当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既然是“基线”，就不能随便动。
但是到了一定时候，修改积累到一定程度，就需要把很多修改合并到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的参考标准，并把老的版本淘汰掉。这就叫做“基线提升”。
以上就是我个人对“基线”这个术语的两种不同含义的理解，大家可以讨论讨论看，是不是差不多就是这个意思。
3)合同基线
当你和客户讨论后，“敲定”的合同
4）发行基线
你会对你要发行的代码，文档版本进行label, 比如Release2.2,
这样，你可以随时取出此版本作build，进行测试，发布。
5）产品基线
当发布时，你会对产品中所有的配置项进行label,包括可执行命令，文档手册，库文件
posted @
2007-03-07 14:04 软件测试大本营 阅读(148) |
评论 (0) |
编辑一、 环境配置测试
（1） 网络连接是否正常
（2） 网络流量负担是否过重
（3） 软件测试平台是否可选
（4） 如果（3），是否在不同的软件测试平台进行软件测试
（5） 所选软件测试平台的版本（包括Service Pack）是否正确
（6） 所选软件测试平台的参数设置是否正确
（7） 所选软件测试平台上正在运行的其它程序是否会影响测试结果
（8） 画面的分辨率和色彩设定是否正确
二、 代码测试
A． 静态测试
（1） 同一程序内的代码书写是否为同一风格
（2） 代码布局是否合理、美观
（3） 程序中函数、子程序块分界是否明显
（4） 注释是否符合既定格式
（5） 注释是否正确反映代码的功能
（6） 变量定义是否正确（长度、类型、存储类型）
（7） 是否引用了未初始化变量
（8） 数组和字符串的下标是否为整数
（9） 的数组和字符串的下标是否在范围内（不“越界”）
（10） 进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”
（11） 是否在应该使用常量的地方使用了变量（例：数组范围检查）
（12） 是否为变量赋予不同类型的值
（13） （12）的情况下，赋值是否符合数据类型的转换规则
（14） 变量的命名是否相似
（15） 是否存在声明过，但从未引用或者只引用过一次的变量
（16） 在特定模块中所有的变量是否都显式声明过
（17） 非（16）的情况下，是否可以理解为该变量具有更高的共享级别
（18） 是否为引用的指针分配内存
（19） 数据结构在函数和子程序中的引用是否明确定义了其结构
（20） 计算中是否使用了不同数据类型的变量
（21） 计算中是否使用了不同的数据类型相同但长度不同的变量
（22） 赋值的目的变量是否小于赋值表达式的值
（23） 数值计算是否会出现溢出（向上）的情况
（24） 数值计算是否会出现溢出（向下）的情况
（25） 除数是否可能为零
（26） 某些计算是否会丢失计算精度
（27） 变量的值是否超过有意义的值
（28） 计算式的求值的顺序是否容易让人感到混乱
（29） 比较是否正确
（30） 是否存在分数和浮点数的比较
（31） 如果（30），精度问题是否会影响比较
（32） 每一个逻辑表达式是否都得到了正确表达
（33） 逻辑表达式的操作数是否均为逻辑值
（34） 程序中的Begin…End和Do…While等语句中，End是否对应
（35） 程序、模块、子程序和循环是否能够终止
（36） 是否存在永不执行的循环
（37） 是否存在多循环一次或少循环一次的情况
（38） 循环变量是否在循环内被错误地修改
（39） 多分支选择中，索引变量是否能超过可能的分支数
（40） 如果（39）,该情况是否能够得到正确处理
（41） 子程序接受的参数类型、大小、次序是否和调用模块相匹配
（42） 全局变量定义和用法在各个模块中是否一致
（43） 是否修改了只作为输入用的参数
（44） 常量是否被做为形式参数进行传递
B 动态测试
（1） 测试数据是否具有一定的代表性
（2） 测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）
（3） 是否可能从客户那边得到测试数据
（4） 非（3）的情况下，所用的测试数据是否具有实际的意义
（5） 是否每一组测试数据都得到了执行
（6） 每一组测试数据的测试结果是否与预期结果一致
（7） 文件的属性是否正确
（8） 打开文件语句是否正确
（9） 输入/输出语句是否与格式说明书所记述的一致
（10） 缓冲区大小与记录长度是否匹配
（11） 使用文件前是否已打开了文件
（12） 文件结束条件是否存在
（13） 产生输入/输出错误时，系统是否进行检测并处理
（14） 输出信息中是否存在文字书写错误和语法错误
（15） 控件尺寸是否大小适宜
（16） 控件颜色是否符合规约
（17） 控件布局是否合理、美观
（18） 控件TAB顺序是否从左到右，从上到下
（19） 数字输入框是否接受数字输入
（20） （19）的情况下、数字是否按既定格式显示
（21） 数字输入框是否拒绝字符串和“非法”数字的输入
（22） 组合框是否的能够进行下拉选择
（23） 组合框是否能够进行下拉多项选择
（24） 对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择
（25） 列表框是否能够进行选择
（26） 多项列表框是否能够进行多数据项选择
（27） 日期输入框是否接受正确的日期输入
（28） 日期输入框是否拒绝错误的日期输入
（29） 日期输入框在日期输入后是否按既定的日期格式显示日期
（30） 单选组内是否有且只有一个单选钮可选
（31） 如果单选组内无单选钮可选，这种情况是否允许存在
（32） 复选框组内是否允许多个复选框（包括全部可选）可选
（33） 如果复选框组内无复选框可选，这种情况是否允许存在
（34） 文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理
（35） 密码输入框是否按掩码的方式显示
（36） Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理
（37） Submit之类的按钮按下后，数据是否得到提交或按既定规约处理
（38） 异常信息表述是否正确
（39） 软件是否按预期方式处理错误
（40） 文件或外设不存在的情况下是否存在相应的错误处理
（41） 软件是否严格的遵循外设的读写格式
（42） 画面文字（全、半角、格式、拼写）是否正确
（43） 产生的文件和数据表的格式是否正确
（44） 产生的文件和数据表的计算结果是否正确
（45） 打印的报表是否符合既定的格式
（46） 错误日志的表述是否正确
（47） 错误日志的格式是否正确
posted @
2007-03-07 13:48 软件测试大本营 阅读(108) |
评论 (0) |
编辑
在恢复QC9.0、TD8.0过程中会遇到这种情况
1、SQL孤立用户：exec sp_change_users_login 'update_one','td','td'
2、SQL必须安装SP3补丁
3、QC、TD的SQL数据库用户td密码是tdtdtd
posted @
2007-03-07 08:41 软件测试大本营 阅读(90) |
评论 (0) |
编辑