软件测试方法总结_软件测试的总结方法 - CSDN
精华内容
参与话题
  • 根据常用的一些分析方法,等价类边界值判定表因果图场景法等方法,设计测试用例,对提取的功能点进行覆盖 测试各个阶段不断跟踪缺陷,做好用例的更新迭代和不断变更需求所带来的业务或者需求的错误 运行 App...

    功能性测试

    1. 评审需求,多方面考虑,整理出内在外在以及非功能性的直接间接功能点,对比需求,提取测试点
    2. 根据常用的一些分析方法,等价类边界值判定表因果图场景法等方法,设计测试用例,对提取的功能点进行覆盖
    3. 测试各个阶段不断跟踪缺陷,做好用例的更新迭代和不断变更需求所带来的业务或者需求的错误

    运行

    1. App安装完成后的试运行,可正常打开软件
    2. App打开测试,是否有加载状态进度提示
    3. App打开速度测试,速度是否可观
    4. App页面间的切换是否流畅,逻辑是否正确
    5. 注册: 用户名密码长度、注册后的提示页面、前台注册页面和后台的管理页面数据是否一致、注册后,在后台管理中页面提示
    6. 登录: 使用合法的用户登录系统、系统是否允许多次非法的登陆,是否有次数限制、使用已经登陆的账号登陆系统是否正确处理、使用禁用的账号登陆系统是否正确处理、用户名、口令(密码)错误或漏填时能否登陆、删除或修改后的用户,原用户登陆、不输入用户口令和用户、重复点(确定或取消按钮)是否允许登陆、登陆后,页面中登陆信息、页面中有注销按钮、登陆超时的处理
    7. 注销: 注销原模块,新的模块系统能否正确处理、终止注销能否返回原模块,原用户、注销原用户,新用户系统能否正确处理、使用错误的账号、口令、无权限的被禁用的账号进行注销

    应用前后台切换

    1. APP切换到后台,再回到 app,检查是否停留在上一次操作界面
    2. APP切换到后台,再回到 app,检查功能及应用状态是否正常
    3. app切换到后台,再回到前台时,注意程序是否崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候
    4. 手机锁屏解屏后进入app注意是否会崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候
    5. 当App使用过程中有电话进来中断后再切换到app,功能状态是否正常
    6. 当杀掉app进程后,再开启app,观察app能否正常启动
    7. 出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在,有时候会出现应用自动跳过提示框的缺陷
    8. 对于有数据交换的页面,每个页面都必需要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃

    免登录

    很多应用提供免登录功能,当应用开启时自动以上一次登录的用户身份来使用app

    1. 考虑无网络情况时能否正常进入免登录状态
    2. 切换用户登录后,要校验用户登录信息及数据内容是否相应更新,确保原用户退出
    3. 一个帐户只允许登录一台机器。所以,需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出,给出友好提示
    4. app切换到后台,再切回前台的校验
    5. 密码更换后,检查有数据交换时是否进行了有效身份的校验
    6. 支持自动登录的应用在进行数据交换时,检查系统是否能自动登录成功并且数据操作无误
    7. 检查用户主动退出登录后,下次启动app,应停留在登录界面

    数据更新

    1. 需要确定哪些地方需要提供手动刷新,哪些地方需要自动刷新,哪些地方需要手动+自动刷新
    2. 确定哪些地方从后台切换回前台时需要进行数据更新
    3. 根据业务、速度及流量的合理分配,确定哪些内容需要实时更新,哪些需要定时更新
    4. 确定数据展示部分的处理逻辑,是每次从服务端请求,还是有缓存到本地,这样才能有针对性的进行相应测试
    5. 检查有数据交换的地方,均有相应的异常处理

    离线浏览

    1. 在无网络情况可以浏览本地数据
    2. 退出app再开启app时能正常浏览
    3. 切换到后台再切回前台可以正常浏览
    4. 锁屏后再解屏回到应用前台可以正常浏览

    App更新

    1. 当客户端有新版本时,有更新提示
    2. 当版本为非强制升级版时,用户可以取消更新,老版本能正常使用。用户在下次启动app时,仍能出现更新提示
    3. 当版本为强制升级版时,当给出强制更新后用户没有做更新时,退出客户端。下次启动app时,仍出现强制升级提示
    4. 当客户端有新版本时,在本地不删除客户端的情况下,直接更新检查是否能正常更新
    5. 当客户端有新版本时,在本地不删除客户端的情况下,检查更新后的客户端功能是否是新版本
    6. 当客户端有新版本时,在本地不删除客户端的情况下,检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的,也都属于缺陷

    定位、照相机服务

    1. App有用到相机,定位服务时,需要注意系统版本差异
    2. 有用到定位服务、照相机服务的地方,需要进行前后台的切换测试,检查应用是否正常
    3. 当定位服务没有开启时,使用定位服务,会友好性弹出是否允许设置定位提示。当确定允许开启定位时,能自动跳转到定位设置中开启定位服务
    4. 测试定位、照相机服务时,需要采用真机进行测试

    时间测试

    1. 客户端可以自行设置手机的时区、时间,因此需要校验该设置对app的影响
    2. 中国为东8区,所以当手机设置的时间非东8区时,查看需要显示时间的地方,时间是否展示正确,应用功能是否正常
    3. 时间一般需要根据服务器时间再转换成客户端对应的时区来展示,这样的用户体验比较好

    推送测试

    1. 检查push消息是否按照指定的业务规则发送
    2. 检查不接受推送消息时,检查用户不会再接收到push
    3. 如果用户设置了免打扰的时间段,检查在免打扰时间段内,用户接收不到PUSH、在非免打扰时间段,用户能正常收到 push
    4. 当push消息是针对登录用户的时候,需要检查收到的push与用户身份是否相符,没有错误地将其它人的消息推送过来。一般情况下,只对手机上最后一个登录用户进行消息推送。
    5. 测试push时,需要采用真机进行测试

    兼容性测试

    1. android版本的兼容性
    2. 手机分辨率兼容性
    3. 网络的兼容性:2G3G4GWIFI,弱网下、断网时
    4. app跨版本的兼容性
    5. 各种设备品牌机型系统版本等兼容
    6. 与本地及主流App是否兼容

    性能测试

    1. 压力测试
    2. 电量流量测试
    3. cup、内存消耗
    4. app启动时长
    5. crash率
    6. 内存泄漏
    7. 压服务器端接口及客户端在不同网络环境下响应速度
    8. 极限测试:各种边界情况下验证app的响应能力,如:低电量、储存满。弱网等情况
    9. 响应能力测试:验证各种情况下不同操作能否满足用户响应需求,比如App安装、卸载的响应时间、App各类功能性操作的影响时间
    10. 压力测试:反复长期操作下,系统该资源的使用情况,比如App反复进行安装卸载,查看系统资源是否正常、其他功能反复进行操作,查看系统资源是否正常

    网络测试

    1. 外网测试主要现实模拟客户使用网络环境,检验客户单程序在实际网若环境中使用情况及进行业务操作
    2. 外网测试主要覆盖到wifi2G3G4G,.netwap、电信移动联通、所有可能的组合进行测试
    3. 尽可能全面覆盖用户的使用场景,测试用例中需要包含不同网络排列组合的各种可能
    4. 还有模拟信号被屏蔽时候。客户端的影响等。还有做外包场景测试,在高山、丘陵、火车上等特殊环境下进行全面测试

    接口性测试

    1. client端和service端的交互
    2. client端的数据更新和service端的数据是否一致
    3. client端更新时连接中断
    4. client端更新时service端宕机

    业务逻辑测试

    1. 主要测试客户端业务能否正常完成

    异常测试

    1. 交互异常性测试:客户端作为手机特性测试,包括被打扰的情况;如来电、来短信、低电量测试等,还要注意手机端硬件上,如:待机,插拔数据线、耳机等操作不会影响客户端
    2. 异常性测试:主要包含了断网、断电、服务器异常等情况下,客户端能否正常处理,保证数据正确性

    回归测试

    1. Bug修复后且在新版本发布后需要进行回归测试
    2. Bug修复后的回归测试在交付前、要进行全量用例的回归测试

    升级更新测试

    1. 每次app版本迭代更新时,配合不同网络环境,及不同更新权限(强制更新,不强制更新),进行下载、安装、更新、启动运行等测试
    2. 测试升级后的功能是否与需求说明一样
    3. 测试与升级模块相关的模块的功能是否与需求一致
    4. 升级安装意外情况的测试(如死机、断电、重启)
    5. 升级界面的UI测试
    6. 不同操作系统间的升级测试

    支付测试

    1. 支付结果的确认,数据库查询
    2. 请求报文是否加密
    3. 不同场景的支付,金额足够、金额不足、重复支付、无网支付、弱网支付、同账号多平台一起支付、余额宝微信信用卡等多种支付方式、不同支付方式的组合、密码正确/错误、支付上限等情况

    安全测试

    软件权限

    1. 扣费风险:包括发送短信、拨打电话、连接网络等
    2. 隐私泄露风险:包括访问手机信息、访问联系人信息等
    3. 对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测
    4. 限制/允许使用手机功能接人互联网
    5. 限制/允许使用手机发送接受信息功能
    6. 限制/允许应用程序来注册自动启动应用程序
    7. 限制或使用本地连接
    8. 限制/允许使用手机拍照或录音
    9. 限制/允许使用手机读取用户数据
    10. 限制/允许使用手机写人用户数据
    11. 检测App的用户授权级别、数据泄漏、非法授权访问等

    安装与卸载安全性

    1. 应用程序应能正确安装到设备驱动程序上
    2. 能够在安装设备驱动程序上找到应用程序的相应图标
    3. 是否包含数字签名信息
    4. JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
    5. JAD文件显示的资料内容与应用程序显示的资料内容应一致
    6. 安装路径应能指定
    7. 没有用户的允许,应用程序不能预先设定自动启动
    8. 卸载是否安全,其安装进去的文件是否全部卸载
    9. 卸载用户使用过程中产生的文件是否有提示
    10. 其修改的配置信息是否复原
    11. 卸载是否影响其他软件的功能
    12. 卸载应该移除所有的文件

    数据安全性

    1. 当将密码或其他的敏感数据输人到应用程序时,其不会被储存在设备中,同时密码也不会被解码
    2. 输人的密码将不以明文形式进行显示
    3. 密码,信用卡明细,或其他的敏感数据将不被储存在它们预输人的位置上
    4. 当应用程序处理信用卡明细,或其他的敏感数据时,不以明文形式将数据写到其它单独的文件或者临时文件中
    5. 防止应用程序异常终止而又没有侧除它的临时文件,文件可能遭受人侵者的袭击,然后读取这些数据信息
    6. 当将敏感数据输人到应用程序时,其不会被储存在设备中
    7. 备份应该加密,恢复数据应考虑恢复过程的异常通讯中断等,数据恢复后再使用前应该经过校验
    8. 应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全警告
    9. 如果数据库中重要的数据正要被重写,应及时告知用户
    10. 应用程序读和写数据正确

    通讯安全性

    1. 在运行其软件过程中,如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时,是否能暂停程序,优先处理通信,并在处理完毕后能正常恢复软件,继续其原来的功能
    2. 当创立连接时,应用程序能够处理因为网络连接中断,进而告诉用户连接中断的情况
    3. 应用程序将保持工作到通讯超时,进而发送给用户一个错误信息指示有连接错误
    4. HTTP、HTTPS覆盖测试

    人机接口安全性

    1. 返回菜单总保持可用
    2. 命令有优先权顺序
    3. 声音的设置不影响应用程序的功能
    4. 应用程序必需利用目标设备适用的全屏尺寸来显示上述内容
    5. 应用程序必需能够处理不可预知的用户操作,例如错误的操作和同时按下多个键

    安装、卸载测试

    安装

    1. 软件在不同操作系统(Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7)下安装是否正常
    2. 软件安装后的是否能够正常运行,安装后的文件夹及文件是否写到了指定的目录里
    3. 软件安装各个选项的组合是否符合概要设计说明
    4. 软件安装向导的 UI测试
    5. 软件安装过程是否可以取消,点击取消后,写入的文件是否如概要设计说明处理
    6. 软件安装过程中意外情况的处理是否符合需求(如死机,重启,断电)
    7. 安装空间不足时是否有相应提示
    8. 安装后没有生成多余的目录结构和文件
    9. 对于需要通过网络验证之类的安装,在断网情况下尝试一下
    10. 还需要对安装手册进行测试,依照安装手册是否能顺利安装

    卸载

    1. 直接删除安装文件夹卸载是否有提示信息
    2. 测试系统直接卸载程序是否有提示信息
    3. 测试卸载后文件是否全部删除所有的安装文件夹
    4. 卸载过程中出现的意外情况的测试(如死机、断电、重启)
    5. 卸载是否支持取消功能,单击取消后软件卸载的情况
    6. 系统直接卸载 UI测试,是否有卸载状态进度条提示

    UI测试

    1. 用户界面(菜单、对话框、窗口)等布局,风格是否满足用户需求,文字位置,描述是否正确,界面美观程度,文字图片组合是否合理
    2. 用户友好性、人性化、便于操作等

    导航测试

    1. 按钮、对话框、列表和窗口等;或在不同的连接页面之间需要导航
    2. 是否易于导航,导航是否直观
    3. 是否需要搜索引擎
    4. 导航帮助是否准确直观
    5. 导航与页面结构、菜单、连接页面的风格是否一致

    图形测试

    1. 横向比较。各控件操作方式统一
    2. 自适应界面设计,内容根据窗口大小自适应
    3. 页面标签风格是否统一
    4. 页面是否美观
    5. 页面的图片应有其实际意义而要求整体有序美观
    6. 图片质量要高且图片尺寸在设计符合要求的情况下应尽量小
    7. 界面整体使用的颜色不宜过多

    内容测试

    1. 输入框说明文字的内容与系统功能是否一致
    2. 文字长度是否加以限制
    3. 文字内容是否表意不明
    4. 是否有错别字
    5. 信息是否为中文显示
    6. 是否有敏感性词汇、关键词
    7. 是否有敏感性图片,如:涉及版权、专利、隐私等图片

    交叉事件测试

    1. 多个 App同时运行是否影响正常功能
    2. App运行时前/后台切换是否影响正常功能
    3. App运行时拨打/接听电话
    4. App运行时发送/接收信息
    5. App运行时发送/收取邮件
    6. App运行时切换网络(2G、3G、wifi)
    7. App运行时浏览网络
    8. App运行时使用蓝牙传送/接收数据
    9. App运行时使用相机、计算器等手机自带设备

    用户体验测试

    1. 是否有空数据界面设计,引导用户去执行操作
    2. 是否滥用用户引导
    3. 是否有不可点击的效果,如:你的按钮此时处于不可用状态,那么一定要灰掉,或者拿掉按钮,否则会给用户误导
    4. 菜单层次是否太深
    5. 交互流程分支是否太多
    6. 相关的选项是否离得很远
    7. 一次是否载入太多的数据
    8. 界面中按钮可点击范围是否适中
    9. 标签页是否跟内容没有从属关系,当切换标签的时候,内容跟着切换
    10. 操作应该有主次从属关系
    11. 是否定义 Back的逻辑。涉及软硬件交互时,Back键应具体定义
    12. 是否有横屏模式的设计,应用一般需要支持横屏模式,即自适应设计

    硬件环境测试

    手势操作测试

    1. 手机开锁屏对运行中的 App的影响
    2. 切换网络对运行中的 App的影响
    3. 运行中的 App前后台切换的影响
    4. 多个运行中的 App的切换
    5. App运行时关机
    6. App运行时重启系统
    7. App运行时充电
    8. App运行时kill掉进程再打开

    网络环境

    1. 无网络时,执行需要网络的操作,给予友好提示,确保程序不出现crash
    2. 内网测试时,要注意选择到外网操作时的异常情况处理
    3. 在网络信号不好时,检查功能状态是否正常,确保不因提交数据失败而造成crash
    4. 在网络信号不好时,检查数据是否会一直处于提交中的状态,有无超时限制。如遇数据交换失败时要给予提示
    5. 在网络信号不好时,执行操作后,在回调没有完成的情况下,退出本页面或者执行其他操作的情况,有无异常情况。此问题也会经常出现程序crash
    展开全文
  • 软件测试方法总结

    千次阅读 2015-11-07 19:26:37
    1、按是否查看程序内部结构分为: (1)黑盒测试(black-box testing):只关心输入和输出的结果。 (2)白盒测试(white-box testing):去研究里面的源代码和程序...黑盒测试也称功能测试或数据驱动测试,它是在已

    点击打开链接1、按是否查看程序内部结构分为:

    (1)黑盒测试(black-box testing):只关心输入和输出的结果。

    (2)白盒测试(white-box testing):去研究里面的源代码和程序结构。

    (3)灰盒测试(Gray-box testing)关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像“白盒”那样详细、完整。

    黑盒测试

    黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把测试对象看作看不见内部的黑盒,在完全不考虑程序内部逻辑结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性,程序是否能适当地接收输入数据而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。

    “黑盒”测试意味着要在软件的接口处进行测试,它着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。因此,可以说“黑盒”测试是站在使用软件和程序的角度,从输入数据和输出数据的对应关系出发进行的测试。

    黑盒测试方法主要有等价类划分法、边界值分析法、因果图法、错误推测法等,主要用于软件确认测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

    黑盒测试分为功能测试和性能测试:

    1) 功能测试(functiontesting),是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。包括

    a、逻辑功能测试(logicfunction testing)

    b、界面测试(UItesting)UI=User Interface

    c、易用性测试(usabilitytesting):是指从软件使用的合理性和方便性等角度对软件系统进行检查,来发现软件中不方便用户使用的地方。

    d、兼容性测试(compatibilitytesting):包括硬件兼容性测试和软件兼容性测试

    2)性能测试(performancetesting)
    软件的性能主要有时间性能和空间性能两种,时间性能:主要指软件的一个具体事务的响应时间(respond time);空间性能:主要指软件运行时所消耗的系统资源。

    软件性能测试分为:

    a、   一般性能测试:指的是让被测系统在正常的软硬件环境下运行,不向其施加任何压力的性能测试。

    b、   稳定性测试也叫可靠性测试(reliability testing):是指连续运行被测系统检查系统运行时的稳定程度。

    c、   负载测试(loadtesting):是指让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的稳定性。

    d、   压力测试(stresstesting):是指持续不断的给被测系统增加压力,直到将被测系统压垮为止,用来测试系统所能承受的最大压力。(Validatethe system or software can allowed the biggest stress.)

    e、   并发测试:验证系统的并发处理能力。一般是和服务器端建立大量的并发连接,通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载,之所以把并发测试单独提出来,是因为并发测试往往涉及服务器的并发容量,以及多进程/多线程协调同步可能带来的问题。这是要特别注意,必须测试的。

    f、   基准测试:当软件系统中增加一个新的模块的时候,需要做基准测试,以判断新模块对整个软件系统的性能影响。按照基准测试的方法,需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下作为基准(Benchmark),然后与打开模块状态下的系统性能指标作比较,以判断模块对系统性能的影响。

    g、   可恢复测试:测试系统能否快速地从错误状态中恢复到正常状态。比如,在一个配有负载均衡的系统中,主机承受了压力无法正常工作后,备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。

    提示:每种测试有其存在的空间和目的。当我们接手一个软件项目后,在有限的资源条件下,选择去做哪一种测试,这应该根据当前软件过程阶段和项目的本身特点来做选择。比如,在集成测试的时候要做基准测试,在软件产品每个发布点要做性能测试。

    白盒测试

    白盒测试也称结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法。它是基于一个应用代码的内部逻辑知识,测试覆盖全部代码、分支、路径和条件。它利用查看代码功能和实现方式得到的信息来确定那些需要测试、哪些不需要测试、如何展开测试。

    “白盒”测试一般分为静态测试和动态测试,静态测试不实际运行软件,主要是对软件的编程格式、结构等方面进行评估,采用的是代码走查、代码审查、程序结构分析、控制流分析、数据流测试及信息流分析等;而动态测试需要在Host环境或Target环境中实际运行软件,并使用设计的测试用例去探测软件缺陷。所采用的设计方法是逻辑覆盖(包括语句覆盖、分支覆盖、条件覆盖、分支条件覆盖自己路径覆盖)。

    它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,“白盒”测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。

    “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。

    黑盒、白盒,动态、静态测试之间的关系

    它们只是一个测试的不同分类角度而已,同一个测试,既有可能属于黑盒测试,也有可能属于动态测试;既有可能属于静态测试,也有可能属于白盒测试。而且它们之间还有包括交叉的关系,总结以下4句话:
    黑盒测试有可能是动态测试(运行程序,只看输入和输出),也有可能是静态测试(不运行程序,只是查看界面)

    “白盒”测试有可能是动态测试(运行程序,并分析代码结构),也有可能是静态测试(不运行程序,只是静态查看代码)

    动态测试有可能是“黑盒”测试(运行程序,只看输入和输出),也有可能是“白盒”测试(运行程序,并分析代码结构)

    静态测试有可能是“黑盒”测试(不运行程序,只是查看界面),也有可能是“白盒”测试(不运行程序,只是静态查看代码)

    灰盒测试

    灰盒测试是一种综合测试法,它将“黑盒”测试、“白盒”测试结合在一起,是基于程序运行时的外部表现又结合程序内部逻辑结构来设计用例,执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。可以这样理解,“灰盒”测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像“白盒”那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过“白盒”测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。灰盒测试结合了“白盒”测试和“黑盒”测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

    2、按是否运行程序分为:

    (1)静态测试(static testing):是指不实际运行被测软件,而只是静态地检查程序代码、界面或文档可能存在的错误的过程。
    静态测试包括:
    对于代码测试,主要是测试代码是否符合相应的标准和规范。
    对于界面测试,主要测试软件的实际界面与需求中的说明是否相符。
    对于文档测试,主要测试用户手册和需求说明是否真正符合用户的实际需求。

    (2)动态测试(dynamic testing),是指实际运行被测程序,输入相应的测试数据,检查输出结果和预期结果是否相符的过程

    3、按阶段划分:

    (1)单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。
    桩模块(stud)是指模拟被测模块所调用的模块,驱动模块(driver)是指模拟被测模块的上级模块,驱动模块用来接收测试数据,启动被测模块并输出结果。

    (2)集成测试(integration testing),是的下一阶段,是单元测试指将通过测试的单元模块组装成系统或子系统,再进行测试,重点测试不同模块的接口部门。
    集成测试就是用来检查各个单元模块结合到一起能否协同配合,正常运行。

    (3)系统测试(system testing),指的是把整个软件系统看做一个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试。
    系统测试的主要依据是《系统需求规格说明书》文档。

    (4)验收测试(acceptance testing),指的是在系统测试的后期,以用户测试为主,或有测试人员等质量保障人员共同参与的测试,它也是软件正式交给用户使用的最后一道工序。
    验收测试又分为a测试和beta测试,其中a测试指的是由用户、 测试人员、开发人员等共同参与的内部测试,而beta测试指的是内测后的公测,即完全交给最终用户测试。

    (5)回归测试(regression testing)是指对软件的新的版本测试时,重复执行上一个版本测试时的用例。

    4、按执行时是否需要人工干预划分

    (1)人工测试:人工测试是由测试人员手工逐步执行所有的活动,并观察每一步是否成功完成。人工测试是任何测试活动的一部分,在开发初始阶段软件及其用户接口还未足够稳定时尤其有效,因为这时自动化并不能发挥显著作用。即使在开发周期很短以及自动化测试驱动的开发过程中,人工测试技术依然具有重要的作用。

    (2)自动化测试:使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试和功能测试中用得较多。通过录制测试脚本,然后执行这个测试脚本来实现测试过程的自动化。自动化测试工具有QTP/UFTAutoRunner和TAR等。

    5、按测试实施的组织划分

    (1)开发方测试:通常也叫“难证测试”或“alpha”。开发方通过检验和提供客观证据,证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下,由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后,开发方对要提交的软件进行全面的自我检查与验证,可以和软件的“系统测试”一并进行

    (2)用户测试:是在用户的应用环境下,用户通过运行和使用软件,检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的“验收测试”,而是指用户的使用性测试,由用户找出软件的应用过程中发现的软件的缺陷与问题,并对使用质量进行评价。

    beta测试通常被看成一种“用户测试”。beta测试主要是把软件产品有计划地免费分发到目标市场,让用户大量使用,并评价、检查软件。通过用户各种方式的大量使用,来发现软件存在的问题与错误,把信息反馈给开发者修改。beta测试中厂商攻取的信息,可以有助于软件产品的成功发布。

    (3)第三方测试:介于软件开发方和用户方之间的测试组织的测试。第三方测试也称为独立测试。软件质量工程强调开展独立验证和确认(IV&V)活动。IV&V是由在技术、管理和财务上与开发组织具有规定程度独立的组织执行验证和确认过程。软件第三方测试也就是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。情况下是在模拟用户真实应用环境下,进行软件确认测试。

    5、其他测试类型:

    (1)冒烟测试(smoke testing),是指在对一个新版本进行大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。

    (2)随机测试(random testing),是指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。

    (3)用户界面测试(User interfacetesting)简称UI测试,测试用户界面的功能模块的布局是否合理,整体风格是否一致和各个控件的放置位置是否符合客户使用习惯,更重要的是要符合操作便捷,导航简单易懂,界面中文字是否正确,命名是否统一,页面是否美观,文字、图片组合是否完美等等

    (4)随机测试(Ad-hoc testing),软件测试中除了根据测试用例和测试说明书进行测试外,还需要进行随机测试(Ad-hoc testing),主要是根据测试者的经验对软件进行功能和性能抽查,是保证测试覆盖完整性的有效方式和过程。

    (5)本地化测试(Localization testing),本地化就是将软件版本语言进行更改,比如将英文的windows改成中文的windows就是本地化。本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    (6)卸载测试(UninstallTesting),卸载测试是对软件的全部、部分或升级卸载处理过程的测试。主要是测试软件能否卸载,卸载是否干净,对系统有无更改,在系统中的残留与后来的生成文件如何处理等。还有原来更改的系统值是否修改回去.

    (7)安全性测试(Security Testing),安全测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。安全测试检查系统对非法侵入的防范能力。安全测试期间,测试人员假扮非法入侵者,采用各种办法试图突破防线。

    例如:①想方设法截取或破译口令;②专门定做软件破坏系统的保护机制;③故意导致系统失败,企图趁恢复之机非法进入;④试图通过浏览非保密数据,推导所需信息,等等。理论上讲,只要有足够的时间和资源,没有不可进入的系统。因此系统安全设计的准则是,使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

    安全性一般分为两个层次,即应用程序级别的安全性和系统级别的安全性,针对不同的安全级别,其测试策略和方法也不相同。

    应用程序级别的安全性,包括对数据或业务功能的访问,在预期的安全性情况下,操作者只能访问应用程序的特定功能、有限的数据。其测试是核实操作者只能访问其所属用户类型已被授权访问的那些功能或数据。测试时,确定有不同权限的用户类型,创建各用户类型并用各用户类型所特有的事务来核实其权限,最后修改用户类型并为相同的用户重新运行测试。

    系统级别的安全性,可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问,它包括对系统的登录或远程访问。其测试是核实只有具备系统和应用程序访问权限的操作者才能访问系统和应用程序。

    (8)兼容性测试(Compatibility Testing),兼容测试是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。向上兼容向下兼容,软件兼容硬件兼容。软件的兼容性有很多需要考虑的地方。

     

     

     

     

     

    展开全文
  • 软件测试方法种类繁多,记忆起来混乱, 如果把软件测试方法进行分类, 就会清晰很多。 我参考一些书籍和网上的资料, 把常用的软件测试方法列出来, 让大家对软件测试行业有个总体的看法。   从测试设计方法分类 ...

    转自:http://www.cnblogs.com/TankXiao/archive/2012/02/20/2347016.html

    软件测试方法种类繁多,记忆起来混乱, 如果把软件测试方法进行分类, 就会清晰很多。 我参考一些书籍和网上的资料, 把常用的软件测试方法列出来, 让大家对软件测试行业有个总体的看法。

     

    从测试设计方法分类

     

    测试名称

    测试内容

    Black box黑盒测试

    把软件系统当作一个“黑箱”,无法了解或使用系统的内部结构及知识。从软件的行为,而不是内部结构出发来设计测试.

    White box白盒测试

    设计者可以看到软件系统的内部结构,并且使用软件的内部知识来指导测试数据及方法的选择。

    Gray box.  灰盒测试

    介于黑盒和白盒之间

     

    总结:   实际工作中,对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试,很少有做白盒测试的。 因为白盒测试对软件测试人员的要求非常高,需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。做JAVA程序的测试,需要你能看懂JAVA的代码。 如果你都能看懂了,你还会做测试么

     

    从测试是手动还是自动上分类

     

    测试名称

    测试内容

    Manual Test 手动测试

    测试人员用鼠标去手动测试 (测试GUI)

    Automation 自动化测试

    用程序测试程序 (测试API)

     

    对于项目来说, 手动测试和自动化测试同等重要,都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化,很多复杂的业务逻辑也很难自动化, 所以自动化测试无法取代手动测试。

    对于软件测试人员个人发展来说, 做自动化测试是个挑战,也是测试人员发展的一个方向,  需要测试人员学习大量的开发知识(开发的知识真是学无止境啊)。 从长远角度来看,自动化测试肯定是越来越吃香的。

    而手动测试比较适合刚工作不久的人,手动测试最大的缺点就是技术含量低,单调乏味,容易废人。

     

    总的来说,手工测试胜在测试业务逻辑,而自动化测试胜在测试底层架构。

     

    如果被测试的程序可测试性比较好, 很有必要做成自动化测试。 能做自动化的尽量做成自动化, 下面这些情形是可以做自动化的

    1.   测试存储过程。  例如用C#去测试存储过程

    2.   测试Web servies. 例如: 用SoupUI工具,或者C#,Java 去测试Web servies。

    3.   界面和业务逻辑分离的系统,比如,MVC,MVP架构, 或者WPF 程序。 可以用测试脚本去测试这些程序的API。

     

    从测试的目的分类

    功能测试

    测试的范围从小到大,从内到外, 从程序开发人员(单元测试)到测试人员,到一般用户Alpha/Beta测试

    测试名称

    测试内容

    Unit Test 单元测试

    在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的)

    Functional Test 功能测试

    验证模块的功能  (测试人员做的)

    Integration Test 集成测试

    验证几个互相有依赖关系的模块的功能 (测试人员做的)

    Scenario Test  场景测试

    验证几个模块是否能完成一个用户场景 (测试人员做的)

    System Test  系统测试

    对于整个系统功能的测试 (测试人员做的)

    Alpha 测试

    软件测试人员在真实用户环境中对软件进行全面的测试 (测试人员做的)

    Beta 测试

    真实的用户在真实的用户环境中进行的测试, 也叫公测   (最终用户做的)

     

     

     

    非功能测试

    一个软件除了基本功能之外,还有很多功能之外的特性,这些叫“Quality of Service requirement服务质量需求。没有软件的功能,这些特性都无从表现出来,因此,我们要在软件开发的适当阶段-基本功能完成后做这些测试。

     

    测试名称

    测试内容

    Stress test 压力测试

    验证软件在超过负载设计的情况下仍能返回正确的结果,没有崩溃

    Load test 负载测试

    测试软件在负载情况下能否正常工作

    Performance test性能测试

    测试软件的效能,是否提供满意的服务质量

    Accessibility test

    软件辅助功能测试-测试软件是否向残疾用户提供足够的辅助功能

    Localization/Globalization

    本地化/全球化测试

    Compatibility Test

    兼容性测试

    Configuration Test

    配置测试-测试软件在各种配置下能否正常工作

    Usability Test

    可用性测试测试软件是否好用

    Security Test

    软件安全性测试

     

    性能测试

    性能测试要求测试人员熟练性能测试工具,比如QTP, LoadRunner, Jmeter。  Visual Studio也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本

    性能测试非常有技术含量, 很有发展前途, 是软件测试人员的一个职业发展方向。

     

    安全性测试

    安全性测试的内容很广, 非常有难度啊。 我只接触过XSS(跨站脚本攻击)和SQL注入攻击。

    安全性测试非常有技术含量, 我认为也是软件测试人员的一个职业发展方向

     

     

    按测试的时机和作用分类

     

    在开发软件的过程中,不少测试起着“烽火台”的作用,它们告诉我们软件开发的流程是否畅通。

     

    测试名称

    测试内容

    Smoke Test

    冒烟”如果测试不通过,则不能进行下一步工作

    Build Verification Test(BVT)

    验证构建是否通过基本测试。

    Acceptance Test

    验收测试,为了全面考核某功能/特性而做的测试

     

    BVT测试是一种Smoke Test, 指Build生成好之后,自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了,需要开发人员马上修改,重新生成Build

     

     

     

    按测试测策略分类。

     

    测试名称

    测试内容

    Regression Test 回归测试

    对一个新的版本,重新运行以往的测试用例,看看新版本和已知的版本相比是否有退化 (regression)

    Ad hoc Test 探索性测试

    随机进行的,探索性的测试。

    Sanity Test

    粗略的测试, 只需要执行部分的测试用例

     

    Regression Test 回归测试:  

    对软件测试人员来说就是重复测试,所以回归测试最好是自动化的, 否则测试人员就要一遍又一遍地重复测试, 

    1. 开发人员做些小改动,就需要测试人员做回归测试。确保现有的功能没有被破坏

    2. Bug Fix 也需要回归测试,确保新的代码修复了Fix, 也确保现有的功能没有被破坏

    3. 项目后期,需要做一个完整回归测试, 确保所有的功能都是好的

     

    Ad hoc Test 探索性测试: 

    平常我最喜欢做随机测试了, 抛开test case.  自己按照自己的思路,随便点点。 如果测试GUI,Ad hoc能发现大量的bug. 


    展开全文
  • 软件测试方法大汇总

    2012-02-20 12:27:57
    软件测试方法种类繁多,记忆起来混乱, 如果把软件测试方法进行分类, 就会清晰很多。 我参考一些书籍和网上的资料, 把常用的软件测试方法列出来, 让大家对软件测试行业有个总体的看法。   从测试设计方法分类 ...

    转自:http://www.cnblogs.com/TankXiao/archive/2012/02/20/2347016.html


    软件测试方法种类繁多,记忆起来混乱, 如果把软件测试方法进行分类, 就会清晰很多。 我参考一些书籍和网上的资料, 把常用的软件测试方法列出来, 让大家对软件测试行业有个总体的看法。

     

    从测试设计方法分类

     

    测试名称

    测试内容

    Black box黑盒测试

    把软件系统当作一个“黑箱”,无法了解或使用系统的内部结构及知识。从软件的行为,而不是内部结构出发来设计测试.

    White box白盒测试

    设计者可以看到软件系统的内部结构,并且使用软件的内部知识来指导测试数据及方法的选择。

    Gray box.  灰盒测试

    介于黑盒和白盒之间

     

    总结:   实际工作中,对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试,很少有做白盒测试的。 因为白盒测试对软件测试人员的要求非常高,需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。做JAVA程序的测试,需要你能看懂JAVA的代码。 如果你都能看懂了,你还会做测试么

     

    从测试是手动还是自动上分类

     

    测试名称

    测试内容

    Manual Test 手动测试

    测试人员用鼠标去手动测试 (测试GUI)

    Automation 自动化测试

    用程序测试程序 (测试API)

     

    对于项目来说, 手动测试和自动化测试同等重要,都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化,很多复杂的业务逻辑也很难自动化, 所以自动化测试无法取代手动测试。

    对于软件测试人员个人发展来说, 做自动化测试是个挑战,也是测试人员发展的一个方向,  需要测试人员学习大量的开发知识(开发的知识真是学无止境啊)。 从长远角度来看,自动化测试肯定是越来越吃香的。

    而手动测试比较适合刚工作不久的人,手动测试最大的缺点就是技术含量低,单调乏味,容易废人。

     

    总的来说,手工测试胜在测试业务逻辑,而自动化测试胜在测试底层架构。

     

    如果被测试的程序可测试性比较好, 很有必要做成自动化测试。 能做自动化的尽量做成自动化, 下面这些情形是可以做自动化的

    1.   测试存储过程。  例如用C#去测试存储过程

    2.   测试Web servies. 例如: 用SoupUI工具,或者C#,Java 去测试Web servies。

    3.   界面和业务逻辑分离的系统,比如,MVC,MVP架构, 或者WPF 程序。 可以用测试脚本去测试这些程序的API。

     

    从测试的目的分类

    功能测试

    测试的范围从小到大,从内到外, 从程序开发人员(单元测试)到测试人员,到一般用户Alpha/Beta测试

    测试名称

    测试内容

    Unit Test 单元测试

    在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的)

    Functional Test 功能测试

    验证模块的功能  (测试人员做的)

    Integration Test 集成测试

    验证几个互相有依赖关系的模块的功能 (测试人员做的)

    Scenario Test  场景测试

    验证几个模块是否能完成一个用户场景 (测试人员做的)

    System Test  系统测试

    对于整个系统功能的测试 (测试人员做的)

    Alpha 测试

    软件测试人员在真实用户环境中对软件进行全面的测试 (测试人员做的)

    Beta 测试

    真实的用户在真实的用户环境中进行的测试, 也叫公测   (最终用户做的)

     

     

     

    非功能测试

    一个软件除了基本功能之外,还有很多功能之外的特性,这些叫“Quality of Service requirement服务质量需求。没有软件的功能,这些特性都无从表现出来,因此,我们要在软件开发的适当阶段-基本功能完成后做这些测试。

     

    测试名称

    测试内容

    Stress test 压力测试

    验证软件在超过负载设计的情况下仍能返回正确的结果,没有崩溃

    Load test 负载测试

    测试软件在负载情况下能否正常工作

    Performance test性能测试

    测试软件的效能,是否提供满意的服务质量

    Accessibility test

    软件辅助功能测试-测试软件是否向残疾用户提供足够的辅助功能

    Localization/Globalization

    本地化/全球化测试

    Compatibility Test

    兼容性测试

    Configuration Test

    配置测试-测试软件在各种配置下能否正常工作

    Usability Test

    可用性测试测试软件是否好用

    Security Test

    软件安全性测试

     

    性能测试

    性能测试要求测试人员熟练性能测试工具,比如QTP, LoadRunner, Jmeter。  Visual Studio也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本

    性能测试非常有技术含量, 很有发展前途, 是软件测试人员的一个职业发展方向。

     

    安全性测试

    安全性测试的内容很广, 非常有难度啊。 我只接触过XSS(跨站脚本攻击)和SQL注入攻击。

    安全性测试非常有技术含量, 我认为也是软件测试人员的一个职业发展方向

     

     

    按测试的时机和作用分类

     

    在开发软件的过程中,不少测试起着“烽火台”的作用,它们告诉我们软件开发的流程是否畅通。

     

    测试名称

    测试内容

    Smoke Test

    冒烟”如果测试不通过,则不能进行下一步工作

    Build Verification Test(BVT)

    验证构建是否通过基本测试。

    Acceptance Test

    验收测试,为了全面考核某功能/特性而做的测试

     

    BVT测试是一种Smoke Test, 指Build生成好之后,自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了,需要开发人员马上修改,重新生成Build

     

     

     

    按测试测策略分类。

     

    测试名称

    测试内容

    Regression Test 回归测试

    对一个新的版本,重新运行以往的测试用例,看看新版本和已知的版本相比是否有退化 (regression)

    Ad hoc Test 探索性测试

    随机进行的,探索性的测试。

    Santiy Test

    粗略的测试, 只需要执行部分的测试用例

     

    Regression Test 回归测试:  

    对软件测试人员来说就是重复测试,所以回归测试最好是自动化的, 否则测试人员就要一遍又一遍地重复测试, 

    1. 开发人员做些小改动,就需要测试人员做回归测试。确保现有的功能没有被破坏

    2. Bug Fix 也需要回归测试,确保新的代码修复了Fix, 也确保现有的功能没有被破坏

    3. 项目后期,需要做一个完整回归测试, 确保所有的功能都是好的

     

    Ad hoc Test 探索性测试: 

    平常我最喜欢做随机测试了, 抛开test case.  自己按照自己的思路,随便点点。 如果测试GUI,Ad hoc能发现大量的bug.



    展开全文
  • 软件测试方法总结

    2019-07-12 16:53:26
    软件测试方法总结 1、按是否查看程序内部结构分为: (1)白盒测试:又称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构,设计测试数据并完成测试的一种测试方法。 (2)黑盒测试:又称为数据驱动...
  • 软件测试总结

    万次阅读 2018-07-01 18:09:11
    1.什么是软件测试?软件测试的意义和目的是什么? IEEE对软件测试的定义为使用人工或自动手段来运行或测定某个系统的过程,其目的在于检验他是否满足规定的需求或是弄清预期结果与实际结果之间的差别。 软件测试是在...
  • 功能测试报告总结

    万次阅读 多人点赞 2016-07-08 13:44:01
    测试报告是测试人员在测试过程中用于反映测试状况的文档,其重要性通过网上哀求、跪求、旋转360度冰天雪地各种求测试报告模块的帖子中就可见一斑。其实测试报告的内容基本都是模板的那些,只是在实际测试过程中,...
  • 黑盒测试基础总结

    万次阅读 2012-11-04 20:12:40
    首先我们必须要知道的就是什么是软件测试和缺陷。然后要掌握常见测测试策略和方法,测试用例的设计方法和缺陷报告(如何写)。这些都是最最基础的知识了,必须要熟练掌握的。其他的测试计划,测试总结这些也要有一定...
  • 软件测试理论知识总结

    万次阅读 多人点赞 2013-01-25 14:14:17
    据了解,软件测试人员必须具有创新性和综合分析能力,必须具备判断准确、追求完美、执着认真、善于合作的品质,以及具有丰富的编程经验与查检故障的能力。 详细分类: 根据测试目的的不同,还有回归测试、压力...
  • 软件测试个人心得总结

    万次阅读 2012-11-15 15:10:40
    测试有几年的时间了,很少这样了完整的来总结一些东西,最近有时间小小的总结了一下,针对公司有些项目提交测试时,存在的一些问题,谈谈个人的一些看法,比如没有需求,也没什么任何文档或有少量不全文档;...
  • 《QuickTest Professional》原书作者授课,书籍配套视频,QuickTest是测试领域的一门重要的专业技术课程,其属于测试领域中课程。课程讲授当前HP旗下主流自动化测试工具QuickTest Professional。
  • 软件测试常见的经典面试题

    万次阅读 多人点赞 2018-09-25 10:27:33
    分析需求,分解需求→制定测试计划→设计测试用例→执行测试用例→提交bug→验证bug→测试报告→测试总结 具体的可根据自己公司的情况作删减。 2、测试用例设计的方法有哪些?平时工作中怎么运用? (1)等价类...
  • 软件测试演义——中高级系列(序)

    万次阅读 热门讨论 2007-01-16 19:11:00
    昨天晚上,忽然有一个想法,借自己Blog宝地,演义一回“软件测试”,系统地介绍软件测试的思想、方法、技术和实践等,更重要是抛砖引玉,吸引更多的朋友参与,营造一个“思想碰撞、技术交流”的软件测试社区。
  • 零基础学软件测试V2.0

    万次阅读 多人点赞 2015-01-09 13:15:20
     目前国内越来越重视软件测试,人才的缺口也是比较大的,为了帮助大家快速的学习测试知识来找到满意的工作,特此来分享本系列的课程。本教程的重点是黑盒测试基础知识和数据库部分的内容,其他部分也会介绍一些。 ...
  • 软件测试速成篇

    万人学习 2016-08-23 14:00:03
    课程内容是全面介绍软件测试知识的,帮助新手入门到软件测试领域(包括测试的技巧、测试用例的设计、如何迅速找出软件缺陷),并且胜任相关的工作,并且对软件测试管理者如何应对工作中遇到的风险与策略。
  • 软件测试十本书

    万次阅读 2017-10-18 22:56:57
    软件,已成为产品集成的必需部件。 软件产品的质量,与用户生活水平正比。 软件质量相关专业,正用武之地,期大有可为。 根据个人经验,推荐软件测试相关的十本书,静待有缘人。
  • 软件测试基础理论(总结

    万次阅读 多人点赞 2017-12-26 16:13:53
    1. 软件的三个要素:程序...3. 软件测试的目的:1)验证软件是否满足 软件开发合同 或者项目开发计划,系统/子系统设计文档,软件需求规格说明,软件产品说明等规定的软件质量要求 2)通过测试,发现软件缺陷 3
  • 软件测试面试前必备题库(必备理论基础复习)

    万次阅读 多人点赞 2019-02-23 23:41:35
    因为我已经正式转岗成功,因此趁着有空,把之前自己面试钱复习的知识整理起来,既可以帮助到有需要的人,也顺便自己做个总结。 在面试或者准备转岗前,大家都应该对最基本的理论知识能做到熟悉掌握,主要有以下一些...
  • 软件测试工作流程概括与总结

    万次阅读 多人点赞 2020-05-21 15:35:39
    最近在为面试新工作做准备,所以想想整理一下软件测试的基本工作流程,大致梳理一遍,这样也便于自己在面试过程中可以沉着的面对面试管的测试工作如何进行的问题。 首先,作为测试人员需要学习并了解业务,分析需求...
  • 软件测试方法策略总结

    万次阅读 2017-06-08 16:34:17
    经常使用的测试方法 1.等价类划分 { 适用场合: 有数据输入的地方,可以使用等价类划分,将大量的数据划分出若干范围,从每个范围中挑选代表数据进行测试,避免穷举,提高测试效率. 有效等价类,无效等价类概念: 有效...
1 2 3 4 5 ... 20
收藏数 206,706
精华内容 82,682
关键字:

软件测试方法总结