分类目录归档:测试

测试用例设计

测试用例设计

测试用例就是一个文档,描述输入、操作和预期结果,其目的是为了验证待测特性是否符合设计需求。

测试用例基本要素

测试用例编号

命名规则

项目名称+测试阶段类型(系统测试阶段)+编号
比如

系统测试用例的编号这样定义规则: PROJECT1-ST-001

测试用例编号的作用

便于查找测试用例,便于测试用例的跟踪。

测试标题

对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。
比如

测试用户登录时输入错误密码时,软件的响应情况。

重要级别

定义测试用例执行的优先级别,可以笼统的分为四个不同的等级

测试输入

提供测试执行中的各种输入条件。

根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。

继续阅读

ASCII码对照表

ASCII控制字符

二进制 十进制 十六进制 缩写 可以显示的表示法 名称/意义
0000 0000 0 00 NUL 空字符(Null)
0000 0001 1 01 SOH 标题开始
0000 0010 2 02 STX 本文开始
0000 0011 3 03 ETX 本文结束
0000 0100 4 04 EOT 传输结束
0000 0101 5 05 ENQ 请求
0000 0110 6 06 ACK 确认回应
0000 0111 7 07 BEL 响铃
0000 1000 8 08 BS 退格
0000 1001 9 09 HT 水平定位符号
0000 1010 10 0A LF 换行键
0000 1011 11 0B VT 垂直定位符号
0000 1100 12 0C FF 换页键
0000 1101 13 0D CR 归位键
0000 1110 14 0E SO 取消变换(Shift out)
0000 1111 15 0F SI 启用变换(Shift in)
0001 0000 16 10 DLE 跳出数据通讯
0001 0001 17 11 DC1 设备控制一(XON 启用软件速度控制)
0001 0010 18 12 DC2 设备控制二
0001 0011 19 13 DC3 设备控制三(XOFF 停用软件速度控制)
0001 0100 20 14 DC4 设备控制四
0001 0101 21 15 NAK 确认失败回应
0001 0110 22 16 SYN 同步用暂停
0001 0111 23 17 ETB 区块传输结束
0001 1000 24 18 CAN 取消
0001 1001 25 19 EM 连接介质中断
0001 1010 26 1A SUB 替换
0001 1011 27 1B ESC 跳出
0001 1100 28 1C FS 文件分割符
0001 1101 29 1D GS 组群分隔符
0001 1110 30 1E RS 记录分隔符
0001 1111 31 1F US 单元分隔符
0111 1111 127 7F DEL 删除

继续阅读

测试用例概述

测试用例:

测试用例(Test Case)是为了某个特殊目标而制定的一组测试输入、执行步骤以及预期结果,以便测试程序某个路径或着核实某个功能是否满足特定需求

测试用例的本质:

构成设计和测试过程的基础
测试用例是软件测试的核心
测试用例是测试工作的指导,
软件测试的必须遵守的准则
更是软件测试质量稳定的根本保障。

设计测试用例的作用:

有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。

影响软件测试的因素

软件本身的复杂程度
开发人员(包括分析、设计、编程和测试的人员)的素质
人员变动
测试方法
测试技术
测试的“深度”与测试用例的数量成比例,测试工作量与测试用例的数量也成比例。根据全面细化的测试用例,可以更准确地估算连续测试阶段各个周期的时间安排。
判断测试是否完全的标准:
是基于需求的覆盖,而这又是以确定、实施或执行的测试用例的数量为依据的。
类似下面这样的说明:“95 % 的关键测试用例已得以执行和验证”

编写测试用例核心内容:
验证程序做了它应该做的事情
验证程序没有做它不该做的事情

编写测试用例的最佳方案:

为每个测试需求至少编制两个测试用例

  • 一个测试用例用于证明该需求已经满足,通常称作正面测试用例
  • 另一个测试用例反映某个无法接受、反常或意外的条件或数据作为输入,用于论证条件不满足的情况下功能需求的实现,这个测试用例称作负面测试用例。

继续阅读

软件开发概念

软件开发概述:
根据用户要求建造出软件系统或者系统中软件部分的一个产品开发的过程。

软件开发步骤:
需求分析
软件架构
软件设计
软件编程
软件测试
软件部署
软件维护

需求分析的定义:
在系统工程及软件工程中,需求分析指的是在创建一个新的或改变一个现存的系统或产品时,确定新系统的目的、范围、定义和功能时所要做的所有工作。

需求分析是关键过程:
在这个过程中,系统分析员和软件工程师确定顾客的需求。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。

需求分析的主要困难:
随着工程师对需求分析的越来越重视,今天我们对需求分析的主要困难也理解得比较清楚:

需求分析需要由有充分的经验、技术知识和语言技巧的专家来完成;
顾客一开始所提出的需要,往往不完全、太乐观以及过分受老的系统或过程的影响;
使用复杂的工具和不同的技术来进行需求分析往往会打消获得一个完整的和细致的结果的希望。

怎样看待顾客需求:

顾客不明白他自己需要什么
顾客不愿将他们的需要固定在一系列写在纸上的条例中
在价格和时间确定后,顾客坚持要求新的需要
分析者与顾客的通讯太缓慢
顾客不参加回顾或无法参加回顾
顾客缺乏技术上的知识
顾客缺乏对软件开发的知识

需求解决方法:
制作原型
统一建模语言(UML)
用例(Use case)
敏捷软件开发

软件开发模式:
敏捷开发 | 无尘室 | 迭代式开发 | RAD | 统一过程 | 螺旋模型 | 瀑布模型 | 极限编程 | Scrum

软件开发辅助领域:
配置管理 | 文档编写 | 质量管理 | 项目管理 | 使用者经验设计

软件测试理论

什么是软件测试:

  软件测试(英语software testing),描述一种用来促进鉴定软件正确性完整性安全性质量的过程。
软件测试理论

软件质量:

软件质量,是指软件系统或系统中的软件部分的质量,即满足用户需求,包括功能需求性能需求的程度。

软件质量包括:

  • 正确性
  • 高效性
  • 可靠性
  • 安全性
  • 可升级性
  • 可维护性
  • 其他质量特性

软件测试的经典定义:

在规定的条件下,对程序进行操作,以发现程序错误,衡量软件质量,并对其是否满足设计要求进行评估的过程。

软件测试本质:

实际输出与预期结果之间的审核或者比较过程。

软件测试内容:

    软件测试针对被测软件,制定测试计划配置测试环境按照各种测试方法编写测试用例,并严格按照测试设计步骤执行测试用例,对执行结果进行分析,并得出测试报告,这是软件质量保证的关键步骤。

软件测试公共特性:

    公认特性是共通的:可靠性稳定性、轻便性、易于维护、以及实用性。

怎样看待软件测试:

    软件测试一度被认为是编程能力偏低的员工的工作,直到今天,仍然有许多公司把优秀的人才放在编码上,也有更多公司让优秀的人才进行设计,可是很少公司让优秀的人才进行测试工作。实际的软件工程实践证明,让对软件思想有深刻理解的工程师进行软件测试的,可以大幅度的提高软件质量。

继续阅读