软件测试必备

来源：互联网发布：威客网络赚钱编辑：程序博客网时间：2024/05/01 19:19

软件测试人员就是软件的质检员.

软件测试比实物测试,其失误造成的代价更大.

测试行业的职位:软件测试工程师, 高级软件测试工程师,测试组长, 测试经理,测试总监.

测试工程师的要求:

首先是扎实的计算机基础知识(微机原理/编译原理/计算机网络/操作系统/数据库/数据结构/编程语言/测试理论等).

掌握至少一门编程语言.掌握英语.

耐心.细心(严密的逻辑思维).

积极 (把自己的工作做好,多考虑与自己工作范围有衔接的公共区,与同事分享自己的经验,多发言及参与团队活动)

良好的团队合作能力 (有意识地关注关注项目进度和组内情况,愿意共享经验也善于从他人那里学习,以团队得奖为思考出发点不过多计较,互助,虚心认同他人尊重他人的工作,批评的时候只对事不对人,友好宽容地对待新同事)

有一双的测试的眼睛/平和的心态/

Windows操作系统及其他非Windows操作系统;

数据库访问

编程语言,最好熟悉一种编程语言

软件工程知识,以及软件测试方面的知识.

软件测试的考试:http://www.ceiaec.org

软件测评师(宽泛的计算机基础知识,包括操作系统/数据库/中间件/程序设计/网络等.)

软件工程知识/软件测试方法和标准/C++ C Java语言/英文

Mercury系列认证
1. Mercury有一系列的软件测试产品,例如LoadRunner/ WinRunner/ TestDirector/ QuickTestPro等.
2. 也有一系列认证如SP(Specialist Product产品专家), CPC(Certified Product Consultant产品顾问认证)

测试人员的职业发展

资深测试工程师.
测试管理者.带领一个团队或公司去做更大的事情.Leader Manager
测试咨询和测试培训人员.
测试书籍编写或者翻译者.

http://www.51Testing.com

http://www.testage.org

如测试一个用C语言编写的上网拨号程序,测试员需要考虑:

程序的功能是否正确(计算机知识)
是否符合用户的使用习惯(要求界面设计知识和换位思考能力)
性能是否满足要求,例如长时间使用下的性能及稳定性(要求资深的计算机知识)
是否能够满足用户在不同操作系统上使用的要求(要求计算机知识)
如果在全球发布,是否满足不同语言和文化的需求(要求软件国际化测试知识)
如何搭建测试环境(要求动手能力/硬件知识)
做代码检查(要求比较深入的C语言知识)
…

C语言

数据类型
运算符
数组
程序控制流 If-else/else-if/for/while/do-while/switch/break continue/goto
函数
指针
结构
头文件

C++语言

面向对象的编程方法
类和对象
构造函数和析构函数
Public/Private/Protected
继承和派生
多态
虚函数
掌握一种可视化C++编程工具,例如VC++

操作系统

操作系统的几种类型:批量/分时和实时操作系统
进程
进程同步和互斥
进程间的通信
线程
资源分配
处理机调度
内存管理
磁盘分区和管理
I/O控制
文件系统管理

数据结构

算法的时间复杂度和空间复杂度
线性表
栈
队列
树的基本概念
二叉树
图的基本概念
图的遍历以及图的生成树
查找,包括顺序查找/二分查找
排序,包括插入排序/选择排序和交换排序

数据库

数据库的发展史
关系型数据库
字段/关键字
表
索引
触发器
存储过程
事务以及事务的提交和回滚
游标
SQL语言
掌握一种关系型数据库的使用,例如SQL Server, Oracle
数据备份和空难恢复
数据导入和导出
权限控制
数据库设计初步

软件工程

软件工程的概念
几个知名的软件开发模型:瀑布模型/螺旋模型/增量模型等
需求分析
软件设计的基本原理:模块化/抽象/耦合/内聚
程序流程图
软件测试的基本概念
单元测试
集成测试
功能测试和性能测试
白盒测试和黑盒测试
评审
配置管理
CASE(计算机辅助软件工程)
了解一点ISO9000和CMM的知识
了解一点知名软件公司的软件研发流程,例如微软公司

网络

几种常见的网络拓扑结构:总线型/环形/星型/树型/网状/混合型等
OSI参考模型(七层协议)
TCP/IP
以太网
常见网络设备,例如路由器/网桥/中继器/网关等
广域网
熟悉一种操作系统上的网络配置和常见问题分析

软件测试技术基础

功能测试
1. 功能测试要做的是把需求规格说明书中的功能定义与软件产品一一比对,力争发现其中的错误.
2. 比如要测试一个记事本的功能:各种不同存储路径/不同文件名格式/不同的文件的长度/操作系统的不同/硬盘分区的不同情况/是否正确保存了/快捷键/硬盘空间不够的情况下如何处理/语言环境的不同/如果已经打开一个"保存"对话框,还能点击"保存"命令吗?/如果要保存为文件A,而文件A正被另外一个程序锁定,这时怎么处理?
等价类划分

在考虑一个功能的测试的时候,我们可以做一个分类,从每一类中选择有代表的数据或者情况来做测试.这在术语上就叫做等价类划分.

边界值(容易遗漏的问题)
1. 分析问题时只懂得边界值理论,再没有其他的法宝;
2. 在问题复杂的情况下,往往遗漏对一些边界值的检查;
3. 有些边界值看起来不重要或者出现概率很低,你容易"放它一马";
因果图和判定表
1. 因果图
2. 判定表
代码覆盖
1. 语句覆盖
2. 分支覆盖
3. 条件覆盖
如何编写测试用例
1. 测试用例组成部分:简明扼要的标题/详细的步骤/正确的预期结果
2. 容易犯的错误:含糊不清或者与内容不相符的标题/过于简单的步骤/没有写明预期结果/多个用例温在一个用例中.
3. 测试用例的优先级:从高到低级分别用0~4来表示.
如何执行测试用例
1. 首先要做的是清晰且正确地理解用例,不带差点含糊;
2. 执行用例不能走样;
3. 细心,在整个过程中都要保持观察;
4. 及时记录,收集好发现的问题.

可以多想想,哪些测试用例是自己没有想到的,测试用例编写者的思维主线是什么,怎么样扩充测试用例

如何提交一个Bug
1. 一个规范的Bug报告应当包括:
  1. 清晰明确重现步骤.任何人,只要按照这些步骤一步一步地做下去,就能重现这个Bug.
  2. 要有预期结果和实际结果的对比.什么是问题,而什么又是预期的正确结果.
  3. 级别定义.一般把Bug分为0~4一共五个级别.也会分为严重性和优先级两个不同的指标.
  4. 如果有可能,可以做一个可能的原因分析.
  5. 如果是界面方面的Bug,尽量附图.
  6. 其他信息,如软件版本号,测试环境要求,测试工程师名字等.
2. 对于一位测试工程师,假Bug应该尽量避免.发现了Bug后,不要急着去提交,多确认.不确认的Bug,发现了真正的重现步骤后再提交,也可以与同事讨论,以求发现真正的Bug.
3. 尽量避免提交重复的Bug.试着养成一种阅读其他测试工程师的Bug报告的习惯.
对Bug保持跟踪.
1. 在提交Bug之后还要跟踪它们.
  1. 如果开发人员不认同这个Bug,争吵不能解决任何问题.
  2. 如果Bug描述不清,导致开发或者项目管理人员理解错误或者无法理解.
  3. 如果开发人员需要更多的信息.
  4. 如果没有适时的Bug跟踪工具,我们每天查看一次自己的Bug集合是应当的.
性能测试: <软件性能测试过程与安全剖析>(清华大学出版社)

处理速度(在做性能测试时,假设的客户端一定要比实际可能的数据还要大)

响应速度.
吞吐量.
CPU占用率
占用内存数和内存占用率

性能测试的第一步是定义什么是预期的性能,也就是什么情况才算达标.

性能测试一般都需要使用测试工具.

界面UI测试. <软件测试实战--测试Web MSN>
1. 所谓界面测试就是功能和性能测试之外,对界面设计,不同分辨率/默认焦点等做测试.
2. 可以从以下几个方面考虑界面测试:
  1. 界面元素要符合通用的标准;
  2. 界面尺寸的改变(缩放).例如控件要不要成比率缩小或者放大,控件要不要重新排列,界面刷新等
  3. 操作系统层次上的不同外观设置;
  4. 不同分辨率.
  5. 焦点问题.每个界面都有焦点设置,这里我们需要考虑:默认焦点是否合适/执行一个功能后焦点变化是否正确/焦点跳变的顺序(Tab键来验证)是否正确等.
  6. 对静态文本图片和动画的检查.要检查界面上所有的文字/画片/动画是否正确,不能有错别字,不能有语法错误,更不能有违反法律的字句和图像存在.
  7. 快捷键.验证各个控件的快捷键是否正确.
  8. 其他的还包括界面风格界面颜色搭配等.

本地化测试.
1. 本地化就是翻译,就是国外的软件经过汉化,拿到中国市场来销售.如Windows中文版 Office中文版等.
2. 首先要验证主要的功能是否正确.本地化测试不是功能测试,只要对主要功能做一个验证就可以.
3. 看界面.汉化后中文字符显示不全,要验证所有界面和窗口.
4. 翻译不完整是本地化常见的问题,就是会有一些信息没有被翻译.
5. 翻译出错.
测试的根本:正确理解需求定义.
1. 测试工程师需要的需求有:
  1. 产品需求规格说明书
  2. 产品需要遵守的软件规范,如界面的设计/控件样式/排版格式/命令格式/文件名等
  3. 易用性上的要求.
2. 软件测试要参与到研发的各个过程.
3. 测试需要一个支撑平台.
  1. 首先应当有一个测试用例管理工具,用来存储测试用例以及执行信息.

一个测试用例管理工具需要记录哪些信息?项目名称/模块名称/测试用例名称/测试用例的具体步骤/测试用例的优先级/编写人每次的具体执行结果,如通过还是失败.

其次应当有一个Bug管理工具.至少包括以下信息:
1. Bug名称
2. 严重等级
3. 优先级
4. 所属项目和模块
5. 发现的步骤和具体表现
6. 发现时间
7. 产品版本号
8. Bug状态(例如是打开/修复/关闭)
9. 备注
再次应该有一个测试报告工具,用来统计测试数据.
最后,要有独立的测试环境.

如何考虑周全,以一个拨号程序为例

开发人员的考虑

调用什么系统函数能实现拨号
写一个什么逻辑能保证拨号成功

测试人员的考虑

功能上,是否正确实现拨号功能?掉线后能否实现自动重拨?能支持多少种拨号设备?
性能上,拨号速度如何?占用内存和CPU是多少?长期运行是否稳定?是否有内存泄露?
界面上,界面设计是否符合规范?字体颜色的设置与搭配是否恰当
易用性,是否符合用户的操作习惯?是否支持快捷键?在各种情况下,是否有简明正确的提示?
兼容性,是否兼容各种常见的操作系统?是否兼容各种常见的软件?
安全性,保存的用户名和密码是否容易被盗取?

应该做到:

自己多思考
多评审
多看同事的测试文档
多看书
多参加技术讲座

版本控制Build,如何做好版本控制?
1. 我们只需要开发人员提供源代码,而不需要他们去做build.也就是说,由测试人员或者第三方(例如专门做build的人)来做一个新版本.
2. 我们对每一个新版本做BVT(Build Verification Testing),俗称冒烟测试.没有通过BVT测试的版本,测试组一律不予接收.
3. 选择一个稳定的版本来做测试.例如我们从1000个测试用例中选50个最重要的用例,只有通过了这50个用例的版本才会被采纳作为测试版本.这种测试可以称为CC(Code Complete)测试.
4. 为了跟踪和后期分析方便,任何一次的测试结果中都要有版本信息,例如1.0.0.1234.,这样我们可以知道哪个版本稳定,哪个版本不行.
5. 在开发人员向代码服务器上传最新的代码之前,如果测试人员有精力的话,可以帮忙做一下确认测试.
6. 版本测试要做到有始有终.
写测试计划
1. 如果要写整个软件产品的测试计划,需要考虑的有:
  1. 测试的范围.同时也可以做一个优先级的区分,另外也要明确什么是测试范围之外的.
  2. 测试的策略.指我们测试的指导思想是什么,如手工测试和自动化测试的分工,黑盒测试和白盒测试的分工等.
  3. 测试的思路.是针对具体的功能点或者性能指标,可以写详细一些,可以把测试用例(此处不写用例的详细步骤)都包含进来.
  4. 测试进度的安排.
  5. 测试资源的安排.例如人员计算机设备软件等
  6. 风险分析.也就是容易遗漏或者失败的地方,或者测试安排上的一些为难之处,例如时间紧张等.
  7. 没有解决的问题.有疑问的地方要记录下来.
测试任务分解后的风险及其应对
1. 除了自己负责的模块之外,还要了解整个产品的细节.
2. 去阅读其他人的测试计划和测试用例,拓展自己的测试思路.在时间允许条件下,可以做一些交换测试的尝试.
3. 多考虑用户的实际使用场景.
4. 安排一些探险测试.即大家抛开测试,完全按照自己的意愿去使用软件产品以期发现错误.
实施自动化测试.
1. 在自动化测试的前期,测试的成本非但不会减少,反而增加.只有自动化测试进行到一定阶段,降低测试成本的效果才会显现出来.
2. 建议是先将性能测试或者压力测试实现自动化.然后再铺展开来,后期也要大量地维护自动化测试.
改进测试的几种方法
1. 整个软件项目小组审查测试计划,参与审阅测试计划是PM(Program Manager,程序经理)/ Dev(Develop,开发工程师)/Tester(软件测试人员).测试计划编写者要提前几天把会议材料发出来,开会前收集所有的反馈意见.
2. 请开发人员评审一部分测试用例.
3. 做Code Complete(编码完成)测试.
4. 做好BVT.
5. 正确定义测试用例的优先级.
6. 要记得做性能测试.
7. 做一些探险测试 (Ad-hoc).
8. 保持改进.
更专业一些.
1. 少提交虚假的Bug/重复的Bug/穷追不舍/重视交流/分析错误原因/发现了问题后要再现一遍/不要放弃不能重现的bug
2. Bug的描述要清晰,无歧义/图片要经过裁剪/大局为重

1 1