如何有效又圆满地完成软件测试?

本书通过两个案例背景,全面展开软件测试的思想、流程、方法和技术最佳实践。全书共十二章,覆盖测试项目启动准备、测试计划制定、系统架构审查、测试用例设计等内容。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

        2000年刚建立测试团队时,测试和开发人员是一种对立的关系,开发人员觉得软件测试是挑他们的毛病、和他们过不去,有一个简单的故事可以说明这一点。当时,条件有限,测试人员和开发人员共享一台小型机服务器,测试人员发现了一个缺陷,告诉某个开发人员,而他趁测试人员不注意回到自己座位,偷偷地修改了代码、处理了那个缺陷,然后跑到测试人员身边,说“你把那个Bug再现给我看?”。结果,可想而知,这个测试人员无论如何也不能复现那个Bug(缺陷)。
    几年以后,这种情况不会再出现了,不是因为条件好了,可以买很多服务器,将测试环境和开发环境分离开来,而是观念改变了。虽然也的确购买了几百台服务器(不用小型机,越来越多采用Linux系统),将测试环境和开发环境分离开来,在客观上避免那类“悲剧”的发生,但是观念远远比机器重要。拥有正确的观念,就比较容易创建良好的质量文化,开发人员的态度也随之发生变化,已经深深认识到:
  • 软件测试是帮助自己,测试人员在是找产品定义、设计和实现的缺陷,不是找自己的缺陷,是对事、不是对人。
  • 测试人员越快地发现缺陷,项目才能尽早一点结束。
  • 测试人员尽可能地发现更多的Bug,遗留在产品中的Bug就会越少,产品的质量就会越高。
  • 测试人员和自己(开发人员)的工作都是为了相同的目标——按时、高质量的发布产品。
  • 水平越高的开发人员,所写的程序中的Bug越少,而不只是使用别人不知道的技巧。

    现在,有的开发人员向我抱怨,是不是换了一个新人测试他写的模块?因为这个测试人员发现的缺陷比以前那个测试工程师发现的缺陷少多了。开发人员希望更多的缺陷被发现出来,绝不希望缺陷被客户发现。
   
    今天,我们高兴看到开发人员和测试人员心往一处想。从项目启动的第一天起到需求和设计的评审阶段,从后期的缺陷修正到产品维护——在整个软件生命周期中,开发人员和测试人员愉快地合作、共同努力,将软件产品的开发效率和质量推到一个新的高度。一方面,开发人员主动介绍自己对产品特性是如何理解的、又如何实现这些特性,主动邀请测试人员参与代码的走查、对新发现的Bug快速响应。另一方面,测试人员提前将设计好的一些测试用例交给开发人员,让开发人员先根据这些测试用例验证正在开发的功能特性,测试人员还愉快地帮助开发人员再现某个缺陷。
   
    所有这些,显示了软件测试在国内越来越受到重视,软件测试领域正迎来朝气蓬勃的新气象。当更多的人投入到测试行业时,需要一本实践性强、富有启发的专业书,指导大家如何进行测试,出色地完成测试任务。
   
    这本 新书《全程软件测试》就承载这样一个任务,从项目启动开始,一步一步地教会大家如何做好测试工作,包括建立测试组、计划测试、设计测试用例、选择测试工具、开发测试脚本、执行测试和编写测试报告等。这也是将多年来所积累的软件测试经验与技术实践,以及不断思考所获得的体会和升华,借此机会与大家分享。
   
    为了写这本书,事先也做了一些尝试,尽量收集大家对软件测试内容需求的反馈,于是在优快云的个人博客 上演义了30回的软件测试 (
 软件测试演义——中高级系列(序) ),受到了大家的好评。也许就因为这个,在优快云建博客不到8个月,就成为当年(2006年)十大最具价值的博客之一 ( 迟到的感谢——2006最有价值博客的候选人(& 个人回顾) , 新浪报道 优快云最有价值博客TOP10 )。

    此后,也和许多软件测试人员进行面对面的交流,如
 技术布道——全程软件测试       优快云 Blog推出文章指数概念,文章指数是对Blog文章综合评分后推算出的,综合评分项分别是该文章的点击量,回复次数,被网摘收录数量,文章长度和文章类型;满分100,每月更新一次。

    此前,曾写过一本《软件测试方法和技术》教材,在比较短的时间内印刷了好几次,也颇受欢迎。但那本书,在很大程度上是从理论、概念上讲解软件测试的方法和技术,适合在校学生使用。而这本书重实践、重应用,适合软件公司的测试经理、工程师和想进入这个软件测试行业的人员等学习。


   
      全书共十二章,以两个案例为背景,以项目向前发展的实际过程为路线图,全面展开软件测试的思想、流程、方法、技术和最佳实践。全书力求做到方法有效、技术实用,集中讲解实际测试工作,没有单纯的概念介绍,将概念准确穿插在测试进程活动之中
  • 第1章 介绍测试项目启动后要做好哪些准备、如何掌控项目背景和要素,为测试计划打下坚实的基础,包括了解软件的质量需求、深刻理解究竟什么是软件测试和测试过程和开发过程之间的关系,确定软件测试组长和制定测试规范。
  • 第2章 测试计划是焦点,主要讨论了测试人员在需求评审的作用、确定软件功能和非功能性的系统测试测试需求、各个阶段的测试任务、测试范围分析和工作量估计、测试资源需求和团队组建、测试里程碑和进度安排,基于测试风险分析来制定有效的测试策略。
  • 第3章 从系统架构的审查,然后深入到系统组件设计、设计规格说明书、界面设计和系统部署设计等一系列的审查。在系统部署设计中,详细讨论了系统部署逻辑设计、物理设计、可用性设计、可伸缩性设计和安全性设计的验证。
  • 第4章 围绕测试设计展开讨论,先从测试用例框架的设计入手,然后逐步涉及测试用例的构成、设计方法、评审、功能测试用例和系统测试用例的设计,其中对各种功能设计方法、故障转移和系统安全性的测试用例设计做了更细的介绍。
  • 第5章 测试工具的选择和脚本的开发是本章的主题。在这一章,对测试工具的优势、实现原理等进行了分析,介绍了测试工具选择的标准、评估报告和误区,给出了开源的或商业的测试工具的完整解决方案,包括详细介绍了Selenium和Jmeter的使用,最后说明如何进行测试脚本录制、回放、开发和重构。
  • 第6章 展示测试和编程的交互过程,主要经历程序代码的审查、程序的动态测试两个环节。对于白盒测试方法及其应用、单元测试工具等,在这一章做了详细介绍。
  • 第7章 开始进入功能测试的执行阶段,并着重自动化功能测试的执行、如何优化测试环境的组合、如何有效地创建测试套件和软件缺陷的报告,包括测试执行之前的准备、测试环境的建立和设置、UI测试、回归测试等。
  • 第8章 介绍如何进行国际化测试和本地化测试,包括本地化的功能测试、数据格式验证、UI验证、配置和兼容性验证和翻译验证。
  • 第9章 内容是围绕系统测试执行来展开,进一步了解系统测试,详细分析了负载测试的加载方式、负载参数、执行布局和结果报告,从而更好地理解如何做好性能测试,并相继介绍了Web安全性测试、容错性测试、兼容性测试、安装测试等。
  • 第10章 内容相对简单,包括4个方面:验收测试、文档测试、α测试和β测试、产品后继版本的测试。
  • 第11章 内容丰富,涉及测试管理的思想和系统、测试用例的管理、测试自动化的管理、缺陷跟踪和分析、测试进度和风险的控制、测试覆盖度和结果分析等。例如单就缺陷分析,缺陷生命周期、缺陷状态的跟踪、缺陷的分析、累计缺陷趋势分析等。
  • 第12章 最后一章是总结和思考,认清现实、制定原则,然后用辨证统一的方法去看各种测试方法的对立统一体,如白盒测试方法和黑盒测试方法、静态测试和动态测试、手工测试和自动化测试、有计划测试和随机测试的等,从而真正悟出软件测试方法的应用之道。这章还分享了测试实践中所积累的、大量的最佳实践,并以实用的测试成熟度模型作为结尾。


 
### 软件测试与硬件测试中的缺陷管理流程 #### 缺陷管理的重要性 在软件开发和硬件生产过程中,缺陷管理是一个至关重要的环节。有效的缺陷管理系统可以帮助团队及时识别并解决潜在问题,从而提高产品的质量和可靠性。 #### 软件测试中的缺陷管理流程 1. **缺陷报告** 当测试人员发现软件存在缺陷时,会创建详细的缺陷报告。该报告应包含重现步骤、预期行为、实际行为以及其他任何有助于开发者理解和修复问题的信息[^1]。 2. **缺陷分类与优先级设定** 报告提交后,项目经理或指定负责人会对这些缺陷进行分类,并根据其严重性和影响范围设置相应的优先级。这一步骤对于合理分配资源至关重要[^2]。 3. **确认与指派** 开发者收到经过初步处理后的缺陷列表,在仔细审查之后决定哪些确实是有效的问题,并将其分给合适的工程师负责修正。如果认为某个问题是误报,则需提供理由说明为何不予采纳[^4]。 4. **修复过程跟踪** 已经被接受下来的每一个缺陷都会进入待办事项清单等待进一步处理;与此同时,相关人员还需定期更新状态直至最终关闭为止——无论是因为已经解决了还是由于其他原因不再考虑修改。 5. **回归测试** 完成修复工作以后,必须再次运行之前失败过的测试案例来验证改动确实达到了预期效果而且不会引发新的错误。只有当所有关联项都通过检验才能正式结案。 ```python def defect_management_software(): report_defect() classify_and_set_priority() confirm_and_assign() track_fix_process() regression_test() def report_defect(): print("Creating detailed defect reports.") def classify_and_set_priority(): print("Classifying defects and setting priorities.") def confirm_and_assign(): print("Confirming validity of reported issues, assigning to developers.") def track_fix_process(): print("Tracking the progress until resolution or closure.") def regression_test(): print("Performing regression tests after fixes.") ``` #### 硬件测试中的缺陷管理流程 1. **检测异常现象** 在生产和组装阶段可能会遇到各种各样的物理层面的问题,比如元器件损坏、线路短路等。这些问题通常由生产线上的质检员最先察觉到,并记录下来作为后续调查的基础材料[^3]。 2. **根本原因分析 (RCA)** 面对较为复杂的情况,可能还需要专门的技术支持小组介入来进行更深层次的原因探究。他们利用专业的工具和技术手段找出真正导致故障发生的根源所在,以便采取针对性强的有效措施加以预防。 3. **纠正行动规划** 明确了具体缘由之后就可以着手准备具体的解决方案了。这里不仅涉及到如何修补现有批次里已知的瑕疵品,还包括怎样调整工艺参数以防止同类事件在未来重演。此外还应该考虑到成本效益等因素作出最优化的选择。 4. **实施与监控** 执行上述拟定好的行动计划的同时也要密切关注整个系统的响应情况,确保所做的一切都在可控范围内平稳推进。一旦发现问题要及时反馈给相关部门共同商讨对策,必要时可以暂停操作直到找到妥善办法再继续前进。 5. **长期监测机制建立** 即便短期内看似圆满解决问题也不能掉以轻心,而是要建立起一套完善的长效监督体制用于持续观察设备的表现状况,随时准备好应对可能出现的新挑战。这种做法有利于积累宝贵的经验教训供日后借鉴参考之用。 ```python def defect_management_hardware(): detect_anomalies() root_cause_analysis() corrective_action_planning() implementation_monitoring() long_term_monitoring_mechanism() def detect_anomalies(): print("Identifying physical anomalies during production.") def root_cause_analysis(): print("Conducting Root Cause Analysis using specialized tools.") def corrective_action_planning(): print("Planning specific solutions based on RCA findings.") def implementation_monitoring(): print("Implementing plans while closely monitoring system response.") def long_term_monitoring_mechanism(): print("Establishing a mechanism for ongoing observation post-fixes.") ```
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值