一、软件测试背景
软件缺陷
把所有的软件问题都称为缺陷(bugs)听起来也许非常简单,但是这样做并不能真正解决问题。
首先需要了解一个辅助术语:产品说明书(product specification)。产品说明书有时又简称为说明(spec) 或产品说明(product spec),是软件开发小组的一个协定。它对开发的产品进行定义,给出产品的细节、如何做、做什么、不能做什么。
至少满足下列5个规则之一才称发生了一个软件缺陷(software bug ):
- 1)软件未实现产品说明书要求的功能。
- 2)软件出现了产品说明书指明不应该出现的错误。
- 3)软件实现了产品说明书未提到的功能。
- 4)软件未实现产品说明书虽未明确提及但应该实现的目标。
- 5)软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。
为什么会出现软件缺陷
1.产品说明书成为造成软件缺陷的罪魁祸首有不少原因。
- 在许多情况下,说明书没有写;
- 其他原因可能是说明书不够全面、经常更改
- 或者整个开发小组没有很好地沟通;
2.软件缺陷的第二大来源是设计。 这是程序员规划软件的过程,产生缺陷的原因——随意、易变、沟通不足。
3.编码原因:软件的复杂性,文档不足,进度压力或者普遍的低级错误。
4.其他原因, 某些缺陷产生的原因是把误解(即把本来正确的)当成缺陷。
还有可能缺陷多处反复出现,实际上是由一个原因引起的。一些缺陷可以归咎于测试错误。
软件缺陷的修复费用
从开始到计划、编程、测试到公开使用的过程中,都有可能发现软件缺陷。说明书--设计--编码--测试--发布,解决缺陷的费用呈十倍地增长。
软件测试员的职责
尽快、尽早地发现软件缺陷,以便降低修复成本,并确保其得以修复。
优秀的软件测试员应具备的素质:
- 他们是群探索者。软件测试员不会害怕进入陌生环境。他们喜欢拿到新软件,安装在自己的机器上,观看结果。
- 他们是故障排除员。软件测试员善于发现问题的症结。
- 他们不放过任何蛛丝马迹。软件测试员总在不停地尝试。他们可能会碰到转瞬即逝或者难以重现的软件缺陷。他们不会当做是偶然而轻易放过,而会想尽一切可能去发现它们。
- 他们具有创造性。测试显而易见的事实,对软件测试员来说还不够。他们的工作是要设想出富有创意甚至超常的手段来寻找缺陷。
- 他们是群追求完美者。他们力求完美,但是当知道某些无法企及时,不去苛求,而是尽力接近目标。
- 他们判断准确。软件测试员要决定测试内容、测试时间,以及看到的问题是否是真正的缺陷。
- 他们注重策略和外交。软件测试员常常带来的是坏消息。优秀的软件测试员知道怎样策略和职业地处理这些问题,也知道如何和不够冷静的程序员合作。
- 他们善于说服。软件测试员找出的缺陷有时被认为不重要,不用修复。测试员要善于清晰地表达观点,说明软件缺陷为何必须修复,并推进缺陷的修复。
- 在软件编程方面受过教育也很重要。了解软件是怎样编写的,可以从不同角度找出软件缺陷,从而使测试更加高效
什么是软件测试
首先要明确测试的定义,所谓测试,就是以检验产品是否满足需求为目标。
软件测试:在规定的条件下对程序进行操作,以发现错误,对软件质量进行评估。
按照软件质量国家标准 GB-T8566–2001G,软件质量可以用下列特征来评价:
a.功能特征:与一组功能及其指定性质有关的一组属性,这里的功能是满足明确或隐含的需求的那些功能。
b.可靠特征:在规定的一段时间和条件下,与软件维持其性能水平的能力有关的一组属性。
c.易用特征:由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
d.效率特征:与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
e.可维护特征:与进行指定的修改所需的努力有关的一组属性。
f.可移植特征:与软件从一个环境转移到另一个环境的能力有关的一组属性。
二、软件开发的过程
软件开发过程
1).客户需求
2).产品
产品说明书
进度表
3).开发
软件设计文档:结构文档、数据流图、状态转换图、流程图、代码注释
4).测试
测试计划(test plan)。描述用于验证软件是否符合产品说明书和客户需求的整体;包括质量目标、资源需求、进度表、任务分配、方法等。
测试用例(testcases)。列举测试的项目,描述验证软件的详细步骤。
缺陷报告(bug reports)。描述执行测试用例找出的问题。
测试工具和自动化测试(test tools and automation):测试小组使用的测试工具和自动化测试工具测试软件
度量、统计和总结(metrics,statistics,summaries)。测试过程的汇总。采用图形表格和报告等形式。
软件维护
软件维护是确保软件系统正常运行和持续发展的关键过程。它主要分为四种类型:更正性维护、预防性维护、适应性维护和完善性维护。
更正性维护:这种维护类型专注于修复系统中已经发生的错误。通过检测和修复软件中的缺陷,确保系统的稳定性和可靠性。
预防性维护:它侧重于识别和解决那些尚未发生的潜在错误。通过预测和预防可能的故障,预防性维护旨在减少系统崩溃和停机时间。系统维护工作不应总是被动地等待用户提出要求后才进行,应进行主动的预防性维护,即选择那些还有较长使用寿命,目前尚能正常运行,但可能将要发生变化或调整的系统进行维护,目的是通过预防性维护为未来的修改与调整奠定更好的基础。 例如,将目前能应用的报表功能改成通用报表生成功能,以应付今后报表内容和格式可能的变化。
适应性维护:这种维护类型涉及使软件适应不断变化的技术和管理需求。随着企业外部市场环境和管理需求的演变,适应性维护确保软件能够满足新的信息需求。
完善性维护:它旨在通过增加新功能和改善性能来扩展软件系统。完善性维护为系统添加了在设计和开发阶段未包含的新特性,从而提升系统的整体能力。在系统的使用过程中,用户往往要求扩充原有系统的功能,增加一些在软件需求规范书中没有规定的功能与性能特征,以及对处理效率和编写程序的改进。例如,有时可将几个小程序合并成一个单一的运行良好的程序,从而提高处理效率;增加数据输出的图形方式;增加联机在线帮助功能;调整用户界面等。尽管这些要求在原来系统开发的需求规格说明书中并没有,但用户要求在原有系统基 础上进一步改善和提高;并且随着用户对系统的使用和熟悉,这种要求可能不断提出。为了满足这些要求而进行的系统维护工作就是完善性维护。
- 某搜索引擎在交付后,开发人员修改了其中的索引方法,使得用户可以更快地得到搜索结果。这种修改属于完善性维护。
这四种维护类型共同构成了软件维护的完整体系,确保软件系统能够适应不断变化的环境和需求,保持其竞争力和生命力。
软件项目人员
项目经理、产品经理或者监制人员自始至终驱动整个项目。他们通常负责编写产品说明书、管理进度、进行重大决策。
体系架构师或者系统工程师是产品小组中的技术专家。他们一般经验丰富,可以胜任设计整个系统的体系架构或软件。他们的工作与程序员关系紧密。
程序员、开发人员或者代码制作者设计、编写软件并修复软件中的缺陷。他们与项目经理和设计师密切合作制作软件,然后与项目经理和测试员密切合作修复缺陷。
测试员或质量保证(Quality Assurance,QA)员负责找出并报告软件产品的问题。他们与开发小组全部成员在开发过程中密切合作,进行测试并报告发现的问题。
技术作者、用户协助专员、用户培训专员、手册编写员或者文案专员编制软件产品附带的文件和联机文档。
配置管理员或构建员负责把程序员编写的代码及技术作者写的全部文档资料组合在一起,合成为一个软件包。
软件开发生命周期
软件生命周期(Software life cycle)又称为软件生存期。是指从形成开发软件概念起,所开发的软件使用以后,直到失去使用价值消亡为止的整个过程。一般来说,整个生存周期包括计划(定义)、开发、运行(维护)三个时期,每个时期又划分为若干个阶段,每个阶段有明确的任务。
大爆炸模式
过程简单,计划、进度安排和正规开发过程几乎没有,所有人力和资金都花在了开发软件和编写代码上。假如产品需求很好理解,而且最终发布日期可以随意更改,这样的开发过程很理想。此外,客户最后一刻再知道自己拿到了怎样的软件。
大爆炸模式几乎没有测试,即使有也是在发布前测试。面临一个已经做好的软件,再修复就比较困难。
边写边改模式
采用这种方式的小组最初只有粗略的想法,接着进行一些简单的设计,然后开始漫长的来回编写、测试和修复缺陷的过程。适合快速制作且用完就扔的小项目,例如原型范例和演示程序。
作为边写边改的项目的软件测试员,需要和程序员一样清醒地认识到自己将陷入无休止的循环往复。几乎每一天都会拿到新的软件版本并着手进行测试。当新版本出来时,旧版本的测试可能尚未完成,而新版本还可能包含新的或者经过修改的功能。最后,终于有机会对几乎所有功能进行测试了,并且发现软件缺陷越来越少,这时某人(或者进度)决定该发布软件了。
瀑布模型
优点:强调需求、设计的作用,前一阶段完成后,只需关注后续阶段;
为项目提供了按阶段划分的检查点,里程碑清晰,文档规范。
缺点:难以适用需求的频繁变化,项目周期后段才能看到成果;
强制的里程碑、完成时间点,文档工作量大。
螺旋模型
螺旋模型是一种迭代式的软件开发过程模型,它结合了传统瀑布模型的系统化和迭代开发模型的灵活性,旨在减少软件项目的风险。螺旋模型的核心思想是将迭代开发周期与风险分析相结合,通过多次迭代来逐步完善产品,同时识别和解决潜在的风险。
螺旋模型适用于以下类型的项目:
- 高风险项目:对于涉及新技术或创新概念的项目,螺旋模型可以帮助识别和减轻风险。
- 大型项目:需要多个团队协作的大型项目,螺旋模型提供了一种结构化的方法来管理复杂性。
- 需求不明确的项目:在项目开始时需求不明确的项目,螺旋模型允许在开发过程中逐步明确和细化需求。
优点:
- 风险管理:螺旋模型的主要优点是其对风险管理的关注。通过在每个迭代周期中识别和评估风险,项目团队可以提前识别和解决潜在的问题。
- 客户参与:强调客户参与和反馈,有助于确保项目成果符合客户的期望,并在开发过程中进行必要的调整。
- 灵活性:迭代性质使其具有很高的灵活性,项目团队可以根据项目进展和反馈调整计划和目标。
缺点:
- 成本和时间:可能需要更多的时间和资源,因为它涉及多个迭代周期和详细的风险评估,这可能会增加项目的成本和时间。
- 管理复杂性:由于涉及多个迭代周期和复杂的风险评估过程,项目管理可能会变得更加复杂。
- 专业知识要求:需要项目团队具备深厚的风险评估和管理技能,这可能需要额外的培训和专业知识。
极限编程
极限编程(Extreme Programming,XP)是一种敏捷软件开发方法,旨在通过短开发周期和频繁的发布来提高软件质量和开发团队的生活质量。极限编程强调团队合作、客户满意度和应对不断变化的需求。它通过一系列具体的实践和原则,帮助团队在动态环境中开发高质量的软件。
在软件架构设计中,"高内聚、低耦合"是两条至关重要的原则。
敏捷软件开发
敏捷宣言:
个体与交付重于过程和工具;
可工作的软件重于详尽的文档;
客户合作重于合同谈判;
相应变化重于遵循计划。
敏捷打通了业务、开发和测试,将业务作为角色A加入。
DevOps(Development and Operations),可以把DevOps看作开发、技术运营和QA三者的交集。敏捷开发和 DevOps 的目标相同,即提高软件开发的速度和质量。DevOps的兴起是软件开发流程与快速交付之间的冲突无法调解的结果。
Epic
中文通常翻译为史诗,指公司的关键战略举措,可以是重大的业务方向。
大功能--可以认为就是一个大的stroy,还没有拆解,是对大story的一个描述性标签。Epic的粒度比较大,需要分解为Feature(也可以不分解,直接分解为story),并通过Feature继续分解细化为User story来完成最终的开发和交付。
Epic通常持续数月(months),需要多个选代才能完成最终的交付。
- XS-0-10 points
- S-10-50
- M-50-100
- L-100-200
- XL-200-300
- XXL-300-500
Feature
中文通常翻译为特性,代表可以给客户带来价值的产品功能或特性。
Feature向上承接Epic,向下分解为User story。相比Epic,Feature更具体形象,客户可以直接感知,通常在产品发布时作为ReleaseNotes的一部分发布给客户。
Feature通常持续数个星期(weeks),需要多个迭代完成交付。
User Story
是从用户角度对产品需求的详细描述,更小粒度的功能。
story承接Feature,并放入有优先级的backlog中,持续规划、滚动调整优先级,始终让高优先级的story更早的交付给客户。
优秀的story应遵循如下的INVEST原则:
- Independent:每个用户故事应该是独立的,可独立交付给客户,
- Negotiable:不必非常明确的阐述功能,细节应带到开发阶段跟程序员、客户来共同商议。
- Valuable:对客户有价值。
- Estimable:能估计出工作量,
- smal:要小一点,但不是越小越好,至少在一个选代中能完成。
- Testable:可测试
story通常持续数天(days),并应在一个迭代内完成交付。用Points来评估难易程度,1,2,3,5,8,1...斐波那契数列
Task
在迭代计划(planning)会议中,将纳入迭代的story指派给具体成员,并分解成一个或多个Task,填写“预计工时”
Theme
可以认为是一组story,有相似特性的一些story的集合。
MMF& MVP
MMF(最小市场特征或最小市场特征集Minimal Marketable Feature or Minimal Marketable Feature set)这是另外一种定义需求的方式。MMF通常比story更大,于是许多人已经将它视为史诗故事了,但是它比刚才的大故事有更多具体的定义,如果你发布的东西有客户来买,功能再少了客户就不买了,这样的最少特性集就是MMF。如果它没有市场,可能是它太小了,而且不能分解出更大的故事。一个或多个MMF与最小可用产品(MVP)一起发布。因为精益企业(Lean startup)活动的出现,最近这个词已经非常流行。
MVP(Minimum viable Product),最小可行性产品,其核心思想是在产品开发过程中,通过尽量少的资源投入,快速推出一个具备基本功能的产品版本,并在市场上进行测试和验证。MVP的目的是尽早获得用户反馈,以便进一步完善产品,降低开发成本和风险。
软件测试模型
V模型
V模型各个阶段测试人员的工作 :
需求分析
审核需求分析报告:需求中是否存在不合理现象;需求是否可以被实现
需求评审会议
书写验收测试计划
概要设计
审核概要设计报告:概要设计是否符合全部需求,概要设计是否存在问题
概要设计评审会议
书写系统测试计划
详细设计
审核详细设计报告:详细设计是否符合全部需求,详细设计是否存在问题
详细设计评审会议
书写集成测试计划
软件编码
开发指南评审会议
书写各个阶段测试用例
召开测试用例评审会议:由项目经理,测试设计师,测试工程师参加
设计(由测试设计师设计)并书写测试脚本(由开发人员书写)
单元测试
开发后期,由开发人员对开发的模块进行单元测试
集成测试
按照模块上下集关系,进行从上到下或者从下到上的集成测试方法进行集成测试,单元测试与集成测试主要考虑功能性测试。同时也要对单个模块或者集成模块进行非功能性的抽样测试。
系统测试
对整合系统进行整合测试,这时的测试主要测试系统的整体功能和全部非功能性的需求
验收测试
验收测试首先进行正规性的测试,即由技术人员模拟各户环境,以用户的身份进行安装和测试工作。然后进行非正规测试alpha测试和bate测试
Alpha测试:由公司内部开发人员模拟用户进行测试,这个时候还允许对需求做些修改工作。
Bate测试:alpha测试后将产品提交给某些特定用户,进行测试。
UAT测试(用户验收测试)是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后,产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段,也称为交付测试。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
开发周期所需要产生的文档:
W模型
测试最规范的过程如下:需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试
详细的描述一个测试活动完整的过程
- 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。
- 开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。
- 测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
- 测试用例完成后,测试和开发需要进行评审。
- 测试人员搭建环境
- 开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现BUG后提交到bug管理系统。
- 开发提交第二个版本,包括Bug Fix以及增加了部分功能,测试人员进行测试。
- 重复上面的工作,一般是3-4个版本后BUG数量减少,达到出货的要求。
- 执行自动化测试,编写脚本,执行,分析,报告;进行性能测试,压力测试等其他测试,执行,分析,调优,报告。
- 编写测试报告
- 如果有客户反馈的问题,需要测试人员协助重现并重新测试
X模型
H模型
敏捷测试模型
敏捷测试就是符合敏捷宣言思想,遵守敏捷开发原则,在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践,这些实践具有鲜明的敏捷开发的特征,如TDD、ATDD、结对编程、持续测试等。
强调从使用系统的用户(客户)角度出发来测试系统。重点关注持续迭代地测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。同时需要及早介入测试 ,不间断测试,具备条件即测试,持续进行回归测试保证之前测试过内容的正确性。
传统测试与敏捷测试对比:
传统测试 | 敏捷测试 |
测试是质量的最后保护者,测试团队和开发团队是相对独立的 | 开发和测试人员是紧密合作,大家都有责任对软件负责,团队合作是无缝障合作 |
严格的变更管理 | 变更是可接受的,拥抱变更 |
预先的计划和细节的准备,传统测试强调测试的计划性,认为没有良好的测试计划和不按计划执行,测试就难以控制和管理 | 计划随着进展时常调整,敏捷测试更强调测试的速度和适应性,侧重计划的不断调整以适应需求的变化 |
重量级文档 | 只需要绝对必要的文档 |
各阶段测试严格的入口和出口标准 | 各迭代之间已经没有明显的入口和出口标准 |
更多在回归测试时进行重量级的自动化测试 | 所有阶段都需要自动测试,每个人都需要做,是项目集成的一部分,敏捷测试的基础就是自动化测试,敏捷测试是具有良好的自动化测试框架支撑的快速测试。 |
严格依赖流程执行,传统测试更具有阶段性,从需求评审、设计评审、单元测试到集成测试、系统测试等,从测试计划、测试设计再到测试执行、测试报告等 | 流程不再需要严格执行,敏捷测试更强调持续测试、持续的质量反馈,阶段性比较模糊。 |
传统测试强调测试是由“验证”和“确认”两种活动构成的 | 敏捷测试没有这种区分,始终以用户需求为中心,每时每刻不离用户需求,将验证和确认统一起来 |
传统测试强调任何发现的缺陷要记录下来,以便进行缺陷根本原因分析,达到缺陷预防的目的,并强调缺陷跟踪和处理的流程,区分测试人员和开发人员的各自不同的责任 | 敏捷测试强调面对面的沟通、协作,强调团队的责任,不太关注对缺陷的记录与跟踪 |
传统测试更关注缺陷,围绕缺陷开展一系列的活动,如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等 | 敏捷测试更关注产品本身,关注可以交付的客户价值。在快速交付的敏捷开发模式下,缺陷修复的成本很低。 |
测试驱动开发(TDD)
测试驱动开发,英文全称是Test-Driven Development,简称为TDD,它是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写好测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速开发过程。
简单来说,测试驱动开发是针对一些小功能点甚至小到一个方法的敏捷开发实践。传统的开发模式是开发人员编写完业务代码后再开始编写单元测试脚本来验证上一步的业务功能代码,而测试驱动开发的中心思想却是先根据需求文档来编写测试代码(即先编写单元测试脚本),并思考怎样对这些要实现的业务功能作验证,等编写了足够的单元测试脚本后,再继续编写业务功能代码,通过测试后,再继续迭代以上的过程一直到编写完成所有的业务需求功能模块。
测试驱动开发与传统开发的区别
传统开发模式下编写的单元测试脚本其实还是为了验证功能,仍属于测试的一种形式。而测试驱动开发已经不再是一种简单的测试行为了,准确地说,它是一种设计行为。测试驱动开发类似于是对一段代码的用法而编写的设计规格说明,可以从编写代码的内聚性、可测性、可复用性以及缺陷密度、接口的简易水平看出。在测试驱动开发中,以需求的剖析、用户业务功能的理解都是层层递进的,是可以逐步细化到代码级别的,而这样的过程也恰恰提高了测试的覆盖率,同时能从根本上解决一些因业务逻辑设计错误而导致的后期大量的缺陷修复工作。
测试驱动开发的优缺点
测试驱动开发最大的优点就是重构了,不断迭代,不断地对现有代码进行重构,不断优化代码的内部结构,最终实现对整体代码的改进。以此不断减少一些设计冗余、代码冗余、接口复杂度等等。
另外,对于一些前期需求不明确,甚至需求信息量特别少,且后期又会有大量业务功能修改时,传统的开发模式需要加班加点以此赶工开发,测试,缺陷修复,人工、时间成本且不说,最重要的产品质量也无法得到保证。当然 ,这种模式下也最适合采用原型法、敏捷开发模式了,毕竟拥抱变化是敏捷的宗旨 。而测试驱动开发也是敏捷开发模式的基础,这样无论是来自客户的紧急需求还是项目团队的一次技术改革,都可以通过重构设计、增加测试脚本来实现了。
三、软件测试基础
1.测试用例(test case)
测试用例设计原则
- 基于需求:测试用例应基于需求设计,避免过度设计不在需求范围内的功能。
- 场景化:测试用例应贴近真实用户的使用场景,围绕场景进行更多的探索。
- 描述精准:测试用例的描述应准确无误,避免歧义。
- 可判定:测试用例的结果应易于判定,每一个测试用例都应有相应的期望结果,确保测试的有效性。
- 原子化:测试用例应尽可能小而独立,避免复杂的依赖关系。
- 可回归:测试用例应易于回归测试,确保在系统变更后的验证效果。
- 独立性:测试用例应独立于其他用例,避免相互影响。
- 正交:测试用例应尽可能覆盖不同的测试维度,确保全面性。
- 代表性:能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。
- 可再现性:即对同样的测试用例,系统的执行结果应当是相同的。
测试用例分类
sprint test case
Regression case
- E2E test case
Automation case
- BDD steps
测试用例模版
Column | Description |
case ID | 1,2,3... |
epic ID |