软件测试与维护-The Realities of Software Testing
软件过程模型不是一个现实的想法
- No software development effort follows a process model perfectly
- Nevertheless, an ideal model is helpful
Software Testing Axioms 软件测试原则
It is impossible to test a program completely.
- 完全测试时不可能的
- The only way to be absolutely sure software works is to run it against all possible inputs and observe all of its outputs
- Oh, and the specification must be correct and complete.
- 虽然需要测试所有的可能性，但无法进行穷举测试
Software testing is a risk-based exercise.
- 软件测试时一个基于风险的测试
- 利用测试技术降低风险
随着测试量的增加，测试的花费增加，missed bugs的数量降低
- 前期随着测试量增加，测试的花费增加较缓
- 前期随着测试量的增加，missed bus降低速度较快
- If you try to test too much, the development cost becomes prohibitive（抑制）.
- If you test too little, the probability of software failure increases and as we discussed … software failures can cost us big time!
Testing cannot show the absence of bugs.
- 不能保证没有bugs
The more bugs you find, the more bugs there are.
Bugs appear in groups 哪边发现bug可能会找到更多bugs
- 可能与开发者、开发团队有关
Not all bugs found will be fixed.
- 可能没有足够时间
并不是一个真正意义上的bug
- 需求文件有误
修复风险太高
- 例如时某一个人的代码
不值得修复
- 例如是一个附加功能，可以等待下一个版本修复
It is difficult to say when a bug is indeed a bug.
- 难确定bug何时会出现
Specifications are never final.
- Building a product based on a "moving target" specification
- Software testers are not the most popular members of a project.
Software testing is a disciplined and technical profession.
- 软件测试者如果没有经过训练，测试不可能是有系统的有方法的
- 软件额是作为一门学科已经成熟了
补充
- 所有测试的标准都是建立在用户需求之上
- 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和核心质量冲突时，时间要服从质量
- 事先定义好产品的质量标准，只有质量标准，才能根据测试结果，对产品质量进行分析和评估
- 测试从软件开发起点就开始
- 测试重启是很困难的
- 第三阿飞那个测试更客观有效
- 测试计划是做好测试工作的前提
- 测试用例是设计出来的
- 对发现错误多的程序段，进行深入测试
- 重视文档
软件缺陷产生的原因
技术问题
- 算法错误、语法错误、计算和精度问题，接口参数传递不匹配
团队工作
- 误解、沟通不充分
软件本身
- 文档错误、用户使用场合（user scenario）、时间上不协调、或不一致性所带来的问题、系统的自我恢复或数据的一地方备份、灾难性恢复等问题
软件缺陷的构成
软件测试
- 对软件进行充分的测试才能保证软件的质量
软件测试的分类
- 按目标/特性：功能测试和非功能测试
按软件测试用例的设计方法：黑盒测试和白盒测试
- 黑盒测试：数据输入边界条件法、等价划分
白盒测试：逻辑路径法
- 成本更高
- 灰盒测试：一部分白盒、一部分黑盒
需求阶段测试工作流程
测试动态阶段（SDLC）
单元测试
- 单元测试的对象是程序系统中的最小单元——模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构触发设计测试用例，检查程序模块或组件的以实现的功能与定义的功能是否一直，以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块。
- 单选测试一般有编程人员和测试人员共同完成
- 白盒为主，黑盒为辅
集成测试
- 集成测试也称组装测试、联合测试、联调测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题
- 一次性结成方法和渐增式集成方式
- 白盒与黑盒结合，检查接口功能与接口代码（白盒）
功能测试
- 功能测试一般在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于系统中的功能需求，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否能正常使用。
- 黑盒测试
系统测试
- 指非功能测试
- 系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列测试
- 黑盒测试
验收测试
- 验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和非功能如同用户所合理期待的那样
- 黑盒测试
安装测试
- 是指按照软件产品安装手册或相应文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性测试，经常让外部人员进行测试
- 黑盒测试
确认、系统与验收测试
- 若缺少相应的依据，则根据需求进行
回归测试
- 经测试，找出bug，相关人员更改，更改之后再回来测试，称为回归测试
测试与调试
- 测试发展的初期，测试就是调试，而现在测试是一个系统化工程化的概念，有自己的生命周期，调试的范畴更小一些
- 调试不属于测试，是编码阶段的工作，由程序员完成；而测试由测试员或程序员完成
- 测试是为了找出软件中存在的缺陷，并督促相关人员解决，为了提升软件质量； 而调试是为了解决存在的缺陷
- 成功的测试发现了错误的症状，从而引起调试的进行
测试管理体系
Some Terminology
Verification
- Are we building the product right
构建过程是否正确
- 各个阶段的规范化，是否满足要求
Validation
- Are we building the right product
- 对研发出的产品的验证
SQA Software Quality Assurance
- 软件质量保证是通过对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程
SQA活动
- 标准的制定、执行
- 技术方法的应用
- 软件测试
- 正式技术评审的实施
- 修改的控制
- 度量：对质量进行量化
- 质量记录和记录保存
SQA与软件测试的关系
- SQA 是管理工作、审查对象是流程、强调以预防为主
- 测试是技术实施工作、测试对象是产品、主要是以事后检查（文档、程序）为主
- SQA指导测试、监控测试测试为SQA提供依据
- 测试是SQA的一个环节、一个手段
ISO 9000
- ISO 9000由ISO的TC（技术委员会）176制定的系列标准
- ISO 9000 总体思想：质量管理与质量保证
- ISO 9000-3 软件质量标准，是ISO质量管理和质量保证标准再软件开发、供应和维护中的使用指南
组件测试队伍
软件测试团队的任务与责任
- 基本任务：测试计划、测试用例设计、执行测试、评估测试结果、递交测试报告
- 尽早地发现问题，发现软件程序、文档、系统或产品中所有的问题，督促相关人员尽快地解决产品中的缺陷；
- 并对问题进行分析、分类总结和跟踪；
- 帮助项目管理人员制定合理的开发计划；
- 帮助改善开发流程、提高产品开发效率；
- 提高程序、文档编写的规范性、易读性、可维护性等。
软件测试团队的基本构成
- QA（quality assurance）/测试经理：人员管理、资源调配、测试方法改进等
- 环境配置人员/实验室管理人员：设置、配置和维护实验室的测试环境
- 内审员：审查流程，简历测试模板，跟踪缺陷测试报告的质量
- 测试组长：负责项目的管理、测试计划、任务安排等；
- 测试设计人员/资深测试工程师，产品规格说明书、设计的审查、测试用例的设计、技术难题的解决、培训和指导、实际测试任务的执行；
- 一般（初级）测试工程师：执行测试用例和相关的测试任务。
- 发布工程师：负责测试后产品的上载、打包、发布
以项目经理为核心的组织模型
- 测试经理与开发经理相互独立，测试更有效果，受到制约较少
评论已关闭