You should know, what you get base on what you gave, so don't cheat , or your life will cheat you!

发布新日志

  • RFT不能在页面里输入中文,这是个很头疼的问题,是因为是试用版吗?

    2007-06-26 17:16:51

    RFT不能在页面里输入中文,这是个很头疼的问题,是因为是试用版吗?
  • 阶段性测试报告和总结测试报告内容

    2007-06-15 08:55:27

    一、阶段性测试报告内容(见如下表):

    项目名称:

    拟制:

    审核:

    项目代号:

    收文:

    产品版本:

    抄送:

    计划完成时间

    测试负责人:

    实际完成时间

    测试人员

    背景备注

    //

    定义

    //

    参考资料

    测试说明文档

    测试对象

    记录要测试的对象名称。

    测试阶段

    本测试报告是哪个测试阶段的报告

    测试环境

    详细记录测试环境,包括软环境、硬环境

    测试概要

    记录测试的步骤及测试的具体内容等。测试内容的说明,建议标识测试用例的编号。

    输出说明

    说明满足输出准则的情况,列出质量目标,记录实际测试结果,bug数量、级别等。

    遗留缺陷及影响

    列出遗留问题及其所影响到的软件模块

    对项目的影响

    遗留问题对整个项目的影响。

    遗留缺陷改进方案或建议

    针对遗留缺陷,从技术和流程上提出改进建议

    测试结果

    对测试工作做出判断,是否满足项目要求。

    度量

    对本阶段测试所涉及的工作做统计,统计内容至少包括:1)资源消耗,2)人员消耗,3)测试覆盖率(针对测试用例)、4)缺陷发现率(Defect/KLOC

     
    二、总结报告内容:
    1. 引言
     1.1 编写目的
     1.2 背景
     1.3 用户群
     1.4 参考资料
     1.5 测试对象
     1.6 测试阶段
     1.7 测试工具
    2. 测试概要
    3. 测试环境
     3.1 软硬件配置
     3.2 网络拓扑方案
    4. 测试结果及发现
     4.1 功能测试
      4.1.1 BUG版本走势
      4.1.2 BUG模块分布
      4.1.3 BUG严重程度分布
      4.1.4 BUG引入阶段分析
      4.1.5 BUG状态分布图
      4.1.6 BUG修改人分布图
     4.2 性能测试
    5. 测试结论
     5.1 功能
     5.2 易用性
     5.3 效率
     5.4 兼容性
    6. 分析摘要
     6.1 能力
     6.2 遗留缺陷的影响
     6.3 建议
     6.4 评价
    7. 度量
     7.1 资源消耗
     7.2 缺陷密度
     
  • 测试计划、测试说明包括的内容

    2007-06-14 09:51:02

    一、测试计划包括的内容:

    1.引言(编写目的,背景,定义,参考资料);

    2.计划
      
      2.1 测试环境(软、硬件环境),网络拓扑;
      2.2 测试对象(测试对象,测试阶段,测试质量特性);
      2.3 功能测试
      2.3.1 测试过程(过程定义,输入准则,输出准则);
      2.3.2 进度安排;
      2.3.3 资源要求(硬件,软件,测试工具,人员及这些需要的时间段);
      2.3.4 技能及培训;
      2.4 风险评估;

    3.评价准则
      3.1 范围;
      3.2 数据整理;
      3.3 尺度;
      3.4 度量;

    二、测试用例包括的内容:

    1 引言 
        1.1      编写目的 
        1.2      背景 
        1.3      定义 
        1.4      用户群 
        1.5      参考资料 
        1.6      测试阶段 
        1.7      质量特性 
        1.8      测试工具 

    2 系统整体架构

    3 测试需求

        3.1      测试对象
        3.2      需求矩阵

    4     测试过程

        4.1      输入准则
        4.2      输出准则
        4.3      过程定义

    5     测试环境

        5.1      软硬件配置
        5.2      网络拓扑方案

    6     测试策略

        6.1      测试方法
            6.1.1       功能测试
            6.1.2       Web测试
            6.1.3       自动化测试
        6.2      测试重点
        6.3      测试步骤

    7     测试用例

        7.1      功能测试
            7.1.1       功能确认用例
            7.1.2       通用测试用例
            7.1.3       逻辑测试用例
            7.1.4       验收测试用例
        7.2      易用性测试
            7.2.1       易用性
            7.2.2       规范性
            7.2.3       帮助设施
            7.2.4       合理性
            7.2.5       美观与协调性
            7.2.6       菜单位置
            7.2.7       独特性
            7.2.8       快捷方式的组合
            7.2.9       安全性考虑
            7.2.10     多窗口的应用与系统资源:   

  • 软件测试流程

    2007-06-14 09:14:21

    1.项目立项;
    2.根据需求写测试计划,测试用例;
    3.评审测试计划和测试用例;
    4.修改测试计划和测试用例;
    5.执行修改后的测试计划和测试用例;
    6.每测试完一个B之后,应提交“阶段测试报告”,并发邮件给所有项目人员;
    7.最后,发布之前提交总结报告;
    8.根据总结报告发布产品。

    我目前写的这个是最基本的流程,将来也会逐步的丰富,希望有经验、有想法的你们能给我意见~

     

  • JMeter使用最基本入门步骤

    2007-06-14 09:02:15

    1.点击“测试计划”,选择“线程组”;

    2.点击“配置元件”—>"cookie管理器"->添加“录制控制器”;

    3.点击“工作台”,选择“代理server”;

    4.添加“高斯定时器”;

    5.“目标”选“线程...录制...”;

    6.“分组”选“只存”;

    7.点“启动”;

    8.设置IE代理;

    9.对线程组添加一个监听器;

    此时就OK了,可以录制IE上的任何操作了。

  • RFT的两种校验方法之介绍和比较

    2007-06-13 17:30:20

    RFT的两种校验方法之介绍和比较

     

    我们在做自动化测试时,会需要验证页面上某些值是否是我们所期望的预期值,我们把它称为校验点。RFT有两种校验点:一种称为静态的校验点,另一种成为动态的校验点。

     

    首先,介绍一下静态校验点,静态校验点的方法很简单,和原来我们用ROBOT时差不多,是在代码里写好校验点所在的窗口,校验点控键的类型和校验点在代码中的名称。然后让工具通过这些条件到网页上找到该校验点,然后再比较校验点里的值是否和我们预期的值相等。

     

    其次,再来介绍动态校验点,动态校验点的方法相对于上述方法来说,要复杂多了。它的思想是这样的,把验证点的预期值和验证点的描述放在两个资源文件里,当调用这个验证方法的时候,会把页面上的包含所有验证点的控键容器,作为一个参数传到方法里,然后这个方法通过调用资源文件,搜索容器中符合验证点描述的控键,再把其值取出和预期值进行比较。

      

     

    最后,这两种方法之比较,见下表:

     

     

     

    静态测试方法

    动态测试方法

    预期值

    硬编码于源程序中

    配置在一个单独的文件中

    被测试控件

    需要一个个的抓取到scrīpt explorer

    配置在一个单独的文件中

    校验代码

    非常冗长,代码行和校验点数量成正比

    非常简短,而且随着校验点增加而不变

    维护性

    需要在编译前修改源程序,而且经常需要维护scrīpt explorer

    只需要修改两个配置文件,不需要重新编译,几乎不需要维护scrīpt explorer

    重用性

    几乎没有重用性,对于新增加的校验点,需要添加新的程序段

    重用性非常高,不需要对新增的校验点不需要编写任何新的代码

    性能

    性能非常好

    性能中等,因为遍历需要消耗时间

     

    在前面提到,在动态的测试框架下,如果需要进行回归测试,或者增加/减少被测试控件,只需要修改两个配置文件并且重新运行即可。在这个过程中,预期值、测试过程和被测试对象之间的耦合被大量减少,带来的是代码可读性和可维护性的提高。然而,该方法也是以损失一部分性能为代价的,因为对象的动态识别需要至少两次遍历tabContent内部的所有对象,这就损失了一些效率。幸运的是,对于大多数基于eclipse的被测试程序,根据实践经验用户通常感觉不到这方面性能的问题。

     

    动态的校验点测试的另外一个巨大的潜力在于,它有潜力发展成为一种校验点测试的框架。测试人员使用自动化测试工具来进行测试,其本质目的是为了能够减少手工重复点击和校验,所以测试人员书写的代码脚本越少越少。将测试人员关注的业务部分单独配置出来,而将他们不熟悉的部分封装在一个框架中,会大大提高测试工作的有效性。而本文提供的动态校验点测试正是在这个方面做出了一定的探索。在这个基础上,再增加配置文件的管理、多种控件/相对位置的识别,再辅之于输入输出的接口,它就可能是一个通用性很强的RFT测试框架。

     

    附:以CWT员工管理为例,说明两种种验证点方法的核心代码

    1.静态验证点判断方法:

    boolean result=staffpw.equals(text_staffPassword2().getText());//判断字符串是否等于预期值

    String context="The value of textfield ="+staffpw;

    RationalTestscrīpt.logTestResult(context,result);//输出测试的结果

           

    3.动态验证点判断方法:

    //该类负责主要的校验流程和关键参数的传入

    public class PanelVerifier {

       

        private TestObject tabContent = null; // 控件容器的引用

     

        private String dataPath = null; // 预期值文件和控件定义文件的存储位置

     

        public PanelVerifier(String dataPath, TestObject tabContent) {

            this.tabContent = tabContent;

            this.dataPath = dataPath;

        }

     

        private List readProperties() throws Exception {

            /**

             * 然后,添加方法readProperties来读取配置文件。readProperties方法读

             * 取预期值文件和控件定义配置文件,将这些读取的值封装在一个List中,List

             * 的每个元素都是ObjDef的实例。每个ObjDef对应于一个被测试的控件对象,其中的各种属性值都来自于配置文件。

             */

            Map propertiesMap=readAllProperties();

            List lst = new ArrayList();

            try {

                Set set = propertiesMap.keySet();

                Iterator iter = set.iterator();

                while (iter.hasNext()){

                    Object obj1 = iter.next();

                    System.out.println(obj1 + "::" + propertiesMap.get(obj1));

                    String[] str = propertiesMap.get(obj1).toString().split(",");

                    ObjDef ōbj = new ObjDef();

                    obj.setInput(str[0]);

                    obj.setLabel(str[1]);

                    obj.setPos(str[2]);

                    obj.setType(str[3]);

                    lst.add(obj);

                }

            } catch(Exception e) {

                e.printStackTrace();

            }  

          

            return lst;

           

        }

     

        public Map readAllProperties() throws Exception {

            Properties p = new Properties();

            Map propertiesMap = new HashMap();

            File file = new File(dataPath + IConstant.IDSFILE);

       

            p.load(new FileInputStream(file));

     

            loadProperties(p, propertiesMap);//propertiesMap:{staffEmail=seasy@etraveltek.com, staffName=seasy, staffRPW=123, staffPW=123}

            System.out.println(propertiesMap);

            file = new File(dataPath + IConstant.OBJECTSFIlE);

            p.load(new FileInputStream(file));

            loadProperties(p, propertiesMap);//propertiesMap:{staffEmail=seasy@etraveltek.com,.tag,Text, staffName=seasy,.tag,Text, staffRPW=123,.tag,Text, staffPW=123,.tag,Text}

            System.out.println(propertiesMap);

            return propertiesMap;

        }

     

        private void loadProperties(Properties p, Map propertiesMap) {

            Set pSet = p.keySet();

            Iterator iter = pSet.iterator();

     

            while (iter.hasNext()) {

                Object key = iter.next();

                String value = p.getProperty(key.toString());

                setMapValue(propertiesMap, key, value);

            }

        }

     

        private void setMapValue(Map map, Object key, Object value) {

            Object beforeValue = map.get(key);

            if (beforeValue == null) {

                map.put(key, value);

            } else {

                map.put(key, beforeValue.toString() + "," + value.toString());

            }

        }

     

        /**

         * 接下来,为类PanelVerifier增加一个filterSubitems方法,该方法能够 在一个被测试对象内部寻找属性符合预期的子对象。比如

         * filterSubitems(tabcontent, "text","Name"),就是在

         * tabcontent的所有子对象中寻找符合属性text等于Name的子对象。

         */

        private List filterSubitems(ExtTestObject testobject, String propertyname,

                Object propertyvalue,Object lablevalue) {

            TestObject[] children = testobject.getTestObject().getChildren();

            ArrayList list = new ArrayList();

            for (int i = 0; i < children.length; i++) { // 循环遍历所有内部的被测试对象

                TestObject subitem = children[i];

    //          System.out.println(subitem.getProperties());

                ExtTestObject eto = new ExtTestObject(subitem);

                try {

                    Object value1 = subitem.getProperty(propertyname);

                    Object value2 = subitem.getProperty(".name");

                    if (value1 != null && value1.equals(propertyvalue) && value2 != null && value2.equals(lablevalue) ) { // 判断对象是否符合要求

                        list.add(eto);

                    }

                } catch (Exception e) {

     

                }

                list.addAll(filterSubitems(eto, propertyname, propertyvalue,lablevalue));

            }

            return list;

        }

     

        public void verify() throws Exception {

            List expectvalue = readProperties();

           

            for (int i = 0; i <expectvalue.size(); i++)

            {

                ObjDef ōbj = (ObjDef) expectvalue.get(i);

                List factvalue = filterSubitems(new ExtTestObject(tabContent),obj.getPos(),obj.getType(),obj.getLabel());

                boolean flag=false;

                String value = "";

                for (int j = 0; j < factvalue.size(); j++)

                {

                    ExtTestObject eto = (ExtTestObject) factvalue.get(j);

                    value = (String) eto.getTestObject().getTestData("text")

                            .getProperty("data");

                    boolean result = value.equals(obj.getInput());

                    if (result)

                    {

                        RationalTestscrīpt.logTestResult(

  • 测试心理学

    2007-06-12 09:29:33

    昨天小组开会讨论了关于大家近期工作的问题,在此我还接受了一个新的观念就是“测试心理学”。原来测试里的学问还真挺多的,不过听起来倒是很有趣的,大家如果有类似的问题可以一起讨论下~!
  • 测试用例的维护

    2007-06-12 09:03:18

    当项目很多,而且变更很多时测试用例也要不断更新,但这个工作量是很大的,大家能说说你们的做法吗?
  • RFT,QTP,ROBOT工具比较小结

    2007-06-07 10:30:21

    RFT,QTP,ROBOT工具比较小结

    前提:

    RFT使用时间:2个月

    QTP使用时间:1个月

    ROBOT使用时间:36个月

     

    之所以用“小结”是就目前我使用的情况而言的,因为毕竟我对RFTQTP使用并不是很长时间,下面我将对我使用过的几点,将三个工具加以对照:

     

    1.       脚本语言:RFT使用的是JAVA, QTP使用的是VBROBOT使用的是SQABasic

     

    2.       对象识别能力:RFT对象识别能力比ROBOT有了很大的提高,与QTP的对象识别能力不相上下。RFTQTP都用到了对象库技术,即在录制脚本时,把录制的每个控件作为一个对象记录在对象库里。而且这个对象库里的内容一般是不让修改的(就目前使用的试用版RFT而言,对中文的支持很不友好,在界面上识别的中文全部是乱码)。

     

    3.       录制脚本:QTP在录制时不是只录你操作的对象,而是把所有出现在页面上的控件作为对象全部记录下来,这样就导致我们在录脚本时,必须把页面上所有控件的内容改动一下,如果不是这样的话,回放很难成功。举个例说一下:在线预订时,在录制时没有选择日期,入住日期默认是当天的日期,用QTP录制时在它的对象库里会记录下这个入住日期,在第二天回放该脚本时,则不会成功,因为QTP会把日期改为录的那一天,而且这个值不能在脚本里改,这个值在对象库里改不了。一般的解决办法是重新录,这样导致这个脚本的维护性很低。而在ROBOTRFT中,这点确表现的很好,录什么则记录什么,也可以追加录制,很灵活方便。

     

    4.       日志记录能力:RFT的日志记录能力最强。它可以形成HTML日志或TEXT日志或记录在TESTMANAGER里。而且除了文档,它还可以生成伪视频,捕捉在出错前的一个短视频。

     

    5.       文本编辑能力:三者之中QTP最弱,ROBOT次之,RFT最强。而且RFT是基于ECLIPS编辑器的,所以编辑功能比之前的ROBOT大大加强。

     

    6.       回放速度:QTP的回放速度最快,ROBOTRFT差不多。

     

    7.       数据池:QTP的数据池最简单,不用设计变量类型,而ROBOTRFT的都要复杂些,特别是RFT还需要指出类型所在的包。

     

    8.       对系统资源要求:RFT对系统资源的要求最高,在默认设置下,RFT的回放需要700M内存,而且是就这一个工具运行而言。

  • 对于以前某一个版本不能解决的BUG如何控制

    2007-05-29 17:29:54

    遇到这样一种情况:

    测试员a在测试系统A的Build 10的时候,有个BUG解决不了,然后这个BUG被搁置了,系统A还是如期照发了。后来这个系统A交给了测试员b测试,测试员a测试系统B。测试了若干个版本后,这个被搁置的BUG改好了,但b知道a不知道。这会造成当a发现系统B也有系统A的那个BUG时,把它当成理所当然,而不会提出这个BUG,这个BUG很有可能会被客户提出。

    这个情况该如何避免呢?

Open Toolbar