Chen Jian

初学者入门:软件测试从零开始

初学者入门:软件测试从零开始 出处:51TESTING 作者:王威 本文面向软件测试新手,从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不规范的现状,本文为软件测试新手提供了若干个软件测试的关注点。   【关键词】软件测试、测试用例、测试需求、测试结果分析   引言   几年前,从学校毕业后,第一份工作就是软件测试。那时候,国内的软件企业大多对软件测试还没有什么概念,书店里除了郑人杰编写的《计算机软件测试技术》之外,几乎没有其它的软件测试相关书籍,软件测试仅仅在软件工程的教材中作为一个章节列出来,因此,我对软件测试一无所知。不过,在正式走上工作岗位之前,公司提供了为期两周的系统的软件测试技术专题培训,对接下来的软件测试工作有很大的指导意义。现在,我继续从事软件测试的培训与咨询服务,在这个过程中,亲眼目睹了很多软件测试新手面对的困惑,他们初涉软件测试行业,没有接受系统的培训,对软件测试一无所知,既不知道该测试什么,也不知道如何开始测试。下面针对上述情况,给出若干解决办法。   测试准备工作   在测试工作伊始,软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理,他往往会这样回答: “ 发现我们产品里面的所有 BUG ,这就是你的工作目的 ” 。作为一名软件测试新手,如何才能发现所有的 BUG ?如何开始测试工作?即便面对的是一个很小的软件项目,测试需要考虑的问题也是方方面面的,包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢?   向有经验的测试人员学习   如果你进入的是一家运作规范的软件公司,有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累,那么,恭喜你!你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师,由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录,在业务导师的指导下逐步熟悉软件测试的相关工作。其实,在很多运作规范的软件公司,已经把上述的师父带徒弟的方式固化到流程中。   如果你进入的是一个软件测试一片空白的软件企业,那么,也恭喜你!你可以在这里开创一片自己的软件测试事业,当然,前提是老板确实认识到软件测试的重要性,实实在在需要提高产品的质量。这时候,可以到国内的软件测试论坛和相关网站上寻找软件测试资源,这种情况下,自学能力和对技术的悟性就至关重要了。   阅读软件测试的相关书籍   现在,中文版的软件测试书籍越来越多,有的是国人自己写的,有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前,从国外引入的软件测试书籍有很多经典之作,但是,翻译成中文后,翻译质量对阅读效果有很大的影响。   走读缺陷跟踪库中的问题报告单   如果您所在的公司已经有软件缺陷跟踪库了,无论采用的是商用工具,如 ClearQuest 、 TestDirecter 等工具,还是采用的 Bugzilla 、 Mantis 等开源工具,这都无关紧要,缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现,同时也是软件产品问题的集中体现。一般来说,缺陷报告单中最关键的几个部分包括:第一部分是发现缺陷的环境,包括软件环境、硬件环境等;第二部分是缺陷的基本描述;第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析,不知不觉你已经吸收了其他软件测试人员的工作经验,并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。   走读相关产品的历史测试用例   如果你所在的公司有测试用例管理系统,那么,走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例,下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项,该测试项的目的是测试用户登录功能是否正确,是否能够完成正常的登录功能,是否能够对非法用户名和密码做异常处理等等。因此,根据该用例项,可以设计出若干个测试用例,大多数情况下,测试用例项和测试用例是一对多的关系。   通过走读测试用例项目,你可以掌握应该从哪些功能点着手未来的测试工作;通过走读软件测试用例,你可以了解如何根据被测试的功能点开展软件测试用例的设计工作,包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。   总之,走读其他软件测试人员设计的优秀软件测试用例,是提高自身用例设计水平的好方法。   学习产品相关的业务知识   软件测试人员不仅要掌握软件测试技术相关知识,对产品相关的业务知识也要学习。这很好理解,如果从事财务软件的测试工作,一定要学习财务知识;如果从事通讯产品测试工作,那么相关的通讯理论知识也是必须的;如果从事银行软件的测试,银行的业务流程也是不可或缺的知识点。   因此,在学习软件测试技术的同时,千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家,但是对产品业务知识一无所知,那么也只能测试出来纯粹的软件缺陷,而面对眼前出现的产品业务相关的缺陷,很可能是视而不见,如此这般,软件测试的效果会大打折扣。   识别测试需求   识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档,那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出,来设计测试用例。如果开发人员没有提供软件需求文档,那该如何是好?下面给出几个有效的方法:   主动获取需求   开发人员通常不会更好地考虑软件测试,如果没有开发流程的强制规定,他们通常是不愿意提供任何开发文档,即便有强制规定,需求文档也未必能够真正指导软件系统测试工作。因此,需要测试人员发挥主观能动性,与相关的软件开发项目经理和软件开发人员保持沟通,了解软件实现的主要功能是什么,并记录得收集到的信息。一般来说,开发人员即便没有提供相关需求文档,也会保存一些简单的过程文档,主动向开发人员索要这些文档,可以作为测试的参考。此外,可以与公司的技术支持人员交流,技术支持人员是最贴近用户的人,因此,通过交流可以获取第一手的用户使用感受,在测试的过程中会更加贴近用户。   当拿到相关的资料后,从哪些方面分析需求?如何与开发人员交流需求?其实,只要把握需求分析的几个关键的点就可以解决问题:输入、处理过程、输出、性能要求、运行环境,下面针对每一个项目逐一分析:   软件输入: 与该需求相关的一切可能输入,可以从这几方面考虑,输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中,这部分内容作为测试用例输入的依据。   处理过程: …

初学者入门:软件测试从零开始 Read More »

在POS机时代,商户和收单行仍以日终批量方式结算

菜鸟 [8:58]: 问个问题,现在信用卡刷卡后,收单行是不是实时将钱记入商户的账号,还是商户在日终时凭签购单请求收单行批量进账? 大师M [8:59]: 日终批次 菜鸟 [9:00]: 收单行和发卡行之间的划账 又要一个日终批次了? 那商户在提供商品后,岂不是要等两天才能拿到钱? 大师M [9:01]: 有的还很多天

ISO 8583 [wiki]

ISO 8583 From Wikipedia, the free encyclopedia Jump to: navigation, search ISO 8583 Standard for Financial Transaction Card Originated Messages – Interchange message specifications is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards. Introduction A card-based transaction typically travels from a transaction acquiring device, such …

ISO 8583 [wiki] Read More »

优化AppFuse 1.9.3 SpringMVC IBatis:使后台管理功能更现实

    AppFuse提供的某些功能和在某方面表现出来的风格使它不像一个典型的业务系统,我们应该裁减、修改一些东西,使它符合我们的习惯。本文谨介绍一下本人在应用AppFuse所做的改动,包括改动的功能和改动的方法。    1. 用户属性重新配置        a. 调整User的属性。去掉User Bean及User表中的非必要属性,只保留一些最基本的属性,并新增一个fullName属性作为用户真实姓名        b. 禁止删除用户:去掉UserManager中的 removeUser方法,去掉userForm.jsp中的 “删除”按钮        c. 禁止修改用户名:修改userForm.jsp          d. 用户中的enable, expired,locked 三个属性中只要使用enable一个就行了。其他的两个应从userForm.jsp 中抹除,不过,下层代码和数据库不必修改                2. 二级或多级管理员体系     一个业务系统里应设置两级或两级以上后台管理员,较低级管理员执行日常的、不太危险的管理操作,较高级管理员则有权执行危险性较高的操作,而且只在必要的情况下动手。在用户数年较多的系统中,较低级的管理员可以有多个,较高级管理员则控制在一两个之内。个人认为这是平衡操作风险与管理工作量的较好模式。     若在AppFuse中采用这种模式,则需要修改的地方包括且不限于:security.xml 、 UserSecurityAdvice.java 和 menu-config.xml       另外,我还建议将用户管理权限的判断放到 UserSecurityAdvice代码中,而不是通过  Spring-Bean  "userManagerSecurity" (见security.xml)来实现。这样做的好处是免于在security.xml中重载userManager

优化AppFuse 1.9.3 SpringMVC IBatis:适配Oracle数据库

    原版本中的sql是mysql风格的,它和Oracle数据库不太兼容。   主要问题有:     1. 自增主键问题。Oracle中没有自增主键,须自定义Sequence。具体有:       a. 新增一个专用于权限子系统的sequence           CREATE SEQUENCE security_sequence           INCREMENT BY 1  — 每次加几个         START WITH 1    — 从1开始计数         NOMAXVALUE      — 不设置最大值         NOCYCLE         — 一直累加,不循环         CACHE 10;               b.修改UserSql.xml中的addUser,应用这个sequence        2. sql语句的分号问题。使用Ibatis + Oracle时,sql中不能使用分号。因此应去掉ibatis sql文件中各语句的分号

优化AppFuse 1.9.3 SpringMVC IBatis:去除Bug

       我在使用 AppFuse_1.9.3_SpringMVC_IBatis 时发现了一些Bug,现在我把这些bug给出来,并提供个人的解决办法。不过,有的BUG我在处理时只记录了解决办法,却没有记录问题,不好意思……     Bug1: 不记得了……    解决办法:UserDaoiBatis.java文件中有句话        List userRoles = getSqlMapClientTemplate().queryForList("getUserRoles", user.getUsername());        其中的getUsername()应改为 getId()       或者直接去掉这句话,因为它没有任何作用     Bug2:在后台为某用户分配多个角色,结果该用户只获得了所选角色中的第一个     解决办法:在UserDaoiBatis.java文件中找到        if (userRoles.isEmpty()) {                      getSqlMapClientTemplate().update("addUserRole", newRole);                  }        然后去掉这个 if条件    Bug3:admin menu按权限显示时出莫名奇妙的问题     解决办法:将struts-menu版本升级到 2.4.3,并将cssHorizontalMenu.vm 和 cssVerticalMenu.vm替换为 appFuse2.0中的版本。      Bug4:不记得了……        解决办法:UserFormController中的             return new ModelAndView(new …

优化AppFuse 1.9.3 SpringMVC IBatis:去除Bug Read More »