2023-08-31 11:30:31 +08:00
|
|
|
|
## 1.软件生命周期包括几个阶段
|
|
|
|
|
|
|
|
|
|
|
|
软件生命周期包括：问题定义、需求分析、软件设计、软件开发、软件测试、软件维护和更新等阶段。
|
|
|
|
|
|
|
|
|
|
|
|
## 2.软件开发模型并简述其优缺点
|
|
|
|
|
|
|
|
|
|
|
|
#### (1)瀑布模型：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
优点：检查点清晰，分工明确，有利于大型软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。
|
|
|
|
|
|
|
|
|
|
|
|
缺点：严格按照线性执行，增加了开发风险；要求必须有产出结果，增加了开发工作量。对于现代软件，各阶段之间的关系很少是线性，瀑布模型已经不适合现代软件开发。
|
|
|
|
|
|
|
|
|
|
|
|
#### (2)快速原型模型：
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
优点：克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。
|
|
|
|
|
|
|
|
|
|
|
|
缺点：原型设计较难；不利于开发人员对产品的扩展。
|
|
|
|
|
|
|
|
|
|
|
|
#### (3)迭代模型
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
优点：适应客户需求变更；降低了开发成本和风险。
|
|
|
|
|
|
|
|
|
|
|
|
缺点：增加了集成失败风险；容易退化为“边做边改”模式，失去对整个项目的控制。
|
|
|
|
|
|
|
|
|
|
|
|
#### (4)螺旋模型
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
螺旋模型包含四个象限：
|
|
|
|
|
|
|
|
|
|
|
|
● 制定计划：确定软件目标，制定实施方案，列出项目开发的限制条件。
|
|
|
|
|
|
|
|
|
|
|
|
● 风险分析：评价所制定的实施方案，识别风险并消除风险。
|
|
|
|
|
|
|
|
|
|
|
|
● 实施工程：开发产品并进行验证。
|
|
|
|
|
|
|
|
|
|
|
|
● 客户评估：客户对产品进行审核评估，提出修正建议，制定下一步计划。
|
|
|
|
|
|
|
|
|
|
|
|
优点：强调了风险分析，有助于将软件质量融入开发中；小分段构建大型软件，易于计算成本；客户参与，保证项目可控性。
|
|
|
|
|
|
|
|
|
|
|
|
缺点：构建过程太过繁琐，不适合小型项目。
|
|
|
|
|
|
|
|
|
|
|
|
#### (5)敏捷模型：
|
|
|
|
|
|
|
|
|
|
|
|
敏捷模型以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
|
|
|
|
|
|
|
|
|
|
|
|
敏捷模型的特点如下：
|
|
|
|
|
|
|
|
|
|
|
|
● 项目被拆分成多个子项目，迭代完成，每个迭代都要经过测试。
|
|
|
|
|
|
|
|
|
|
|
|
● 快速响应需求变更，在修改过程中，软件一直处于可用状态。
|
|
|
|
|
|
|
|
|
|
|
|
● 不断对产品进行细微、渐进式地改进，每次改进一小部分，如果可行再逐步扩大改进范围。
|
|
|
|
|
|
|
|
|
|
|
|
● 开发未动，测试先行。
|
|
|
|
|
|
|
|
|
|
|
|
● 注重“人”的作用。
|
|
|
|
|
|
|
|
|
|
|
|
优点：及时响应客户需求变更，不断适应新的趋势。
|
|
|
|
|
|
|
|
|
|
|
|
缺点：管理相对混乱，不适合大型项目。
|
|
|
|
|
|
|
|
|
|
|
|
## 3.软件质量的3个层次及影响软件质量的因素
|
|
|
|
|
|
|
|
|
|
|
|
3个层次：
|
|
|
|
|
|
|
|
|
|
|
|
(1)满足需求规定：软件产品符合开发者明确定义的目标，并且能可靠运行。
|
|
|
|
|
|
|
|
|
|
|
|
(2)满足用户需求：软件产品的需求是由用户产生的，软件最终的目的就是满足用户需求，解决用户的实际问题。
|
|
|
|
|
|
|
|
|
|
|
|
(3)满足用户隐式需求：除了满足用户的显式需求，软件产品如果满足用户的隐式需求，即潜在的可能需要在将来开发的功能，将会极大地提升用户满意度，这就意味着软件质量更高。
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
影响软件质量的因素包括：需求分析、设计、编码、集成、部署、测试、维护等。
|
|
|
|
|
|
|
|
|
|
|
|
## 4.产生软件缺陷的原因及软件处理流程
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
#### 原因：
|
|
|
|
|
|
|
|
|
|
|
|
软件缺陷的产生主要是由软件产品的特点和开发过程决定的，比如需求不清晰、需求频繁变更、开发人员水平有限等。归结起来，软件缺陷产生的原因主要有以下几点：
|
|
|
|
|
|
|
|
|
|
|
|
(1)需求不明确。软件需求不清晰或者开发人员对需求理解不明确，导致软件在设计时偏离客户的需求目标，造成软件功能或特征上的缺陷。此外，在开发过程中，客户频繁变更需求也会影响软件最终的质量。
|
|
|
|
|
|
|
|
|
|
|
|
(2)软件结构复杂如果软件系统结构比较复杂，很难设计出一个具有很好层次结构或组件结构的框架，这就会导致软件在开发、扩充、系统维护上的困难。即使能够设计出一个很好的架构，复杂的系统在实现时也会隐藏着相互作用的难题，而导致隐藏的软件缺陷。
|
|
|
|
|
|
|
|
|
|
|
|
(3)编码问题。在软件开发过程中，程序员水平参差不齐，再加上开发过程中缺乏有效的沟通和监督，问题累积越来越多，如果不能逐一解决这些问题，会导致最终软件中存在很多缺陷。
|
|
|
|
|
|
|
|
|
|
|
|
(4)项目期限短。现在大部分软件产品开发周期都很短，开发团队要在有限的时间内完成软件产品的开发，压力非常大，因此开发人员往往是在疲劳、压力大、受到干扰的状态下开发软件，这样的状态下，开发人员对待软件问题的态度是“不严重就不解决”。
|
|
|
|
|
|
|
|
|
|
|
|
(5)使用新技术。现代社会，每种技术发展都日新月异。使用新技术进行软件开发时，如果新技术本身存在不足或开发人员对新技术掌握不精，也会影响软件产品的开发过程，导致软件存在缺陷。
|
|
|
|
|
|
|
|
|
|
|
|
#### 处理流程：
|
|
|
|
|
|
|
|
|
|
|
|
每个公司的软件缺陷处理流程不尽相同，但是它们遵循的最基本流程是一样的，都要经过提交、分配、确认、处理、复测、关闭等环节。
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
● 提交：测试人员发现缺陷之后，将缺陷提交给测试组长。
|
|
|
|
|
|
|
|
|
|
|
|
● 分配：测试组长接收到测试组员提交的缺陷之后，将其移交给开发人员。
|
|
|
|
|
|
|
|
|
|
|
|
● 确认：开发人员接收到移交的缺陷之后，会与团队甚至测试人员一起商议，确定该缺陷是否是一个缺陷。
|
|
|
|
|
|
|
|
|
|
|
|
● 拒绝：如果经过商议之后，缺陷不是一个真正的缺陷则拒绝处理，关闭缺陷。如果经过商议之后，确定其是一个真正的缺陷，则可以根据缺陷的严重程度或优先级等立即处理或延期处理。
|
|
|
|
|
|
|
|
|
|
|
|
● 复测：开发人员修改好缺陷之后，测试人员重新进行测试（复测），检测缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。
|
|
|
|
|
|
|
|
|
|
|
|
● 关闭：测试人员重新测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成。
|
|
|
|
|
|
|
|
|
|
|
|
## 5.软件测试的目的及分类
|
|
|
|
|
|
|
|
|
|
|
|
### 目的：
|
|
|
|
|
|
|
|
|
|
|
|
(1)对于软件开发来说，软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发的模式、工具、技术等方面存在的问题与不足，预防下次缺陷的产生。
|
|
|
|
|
|
|
|
|
|
|
|
(2)对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富的经验。
|
|
|
|
|
|
|
|
|
|
|
|
(3)对于客户需求来说，软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据。
|
|
|
|
|
|
|
|
|
|
|
|
### 分类：
|
|
|
|
|
|
|
|
|
|
|
|
#### (1)按照测试阶段分类
|
|
|
|
|
|
|
|
|
|
|
|
1.单元测试
|
|
|
|
|
|
|
|
|
|
|
|
验证软件单元是否符合软件需求与设计，开发人员自测。
|
|
|
|
|
|
|
|
|
|
|
|
2.冒烟测试
|
|
|
|
|
|
|
|
|
|
|
|
软件构建版本建立后，对系统的基本功能进行简单的测试，这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试。
|
|
|
|
|
|
|
|
|
|
|
|
3.集成4测试
|
|
|
|
|
|
|
|
|
|
|
|
冒烟测试之后，将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。
|
|
|
|
|
|
|
|
|
|
|
|
4.系统测试
|
|
|
|
|
|
|
|
|
|
|
|
将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试。
|
|
|
|
|
|
|
|
|
|
|
|
5.验收测试
|
|
|
|
|
|
|
|
|
|
|
|
主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。
|
|
|
|
|
|
|
|
|
|
|
|
#### (2)按照测试技术分类
|
|
|
|
|
|
|
|
|
|
|
|
1.黑盒测试
|
|
|
|
|
|
|
|
|
|
|
|
把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
2.白盒测试
|
|
|
|
|
|
|
|
|
|
|
|
测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
总结：相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，它要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在软件公司里，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往是黑盒测试与白盒测试相结合对软件进行完整全面的测试。
|
|
|
|
|
|
|
|
|
|
|
|
#### (3)按照软件质量特性分类
|
|
|
|
|
|
|
|
|
|
|
|
1.功能测试
|
|
|
|
|
|
|
|
|
|
|
|
测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。
|
|
|
|
|
|
|
|
|
|
|
|
2.性能测试
|
|
|
|
|
|
|
|
|
|
|
|
测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。
|
|
|
|
|
|
|
|
|
|
|
|
#### (4)按照自动化程度分类
|
|
|
|
|
|
|
|
|
|
|
|
1.手工测试
|
|
|
|
|
|
|
|
|
|
|
|
测试人员一条一条的执行代码完成测试工作。费时费力且很验证保证测试效果。
|
|
|
|
|
|
|
|
|
|
|
|
2.自动化测试
|
|
|
|
|
|
|
|
|
|
|
|
借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。
|
|
|
|
|
|
|
|
|
|
|
|
#### (5)按照测试类型分类
|
|
|
|
|
|
|
|
|
|
|
|
1.界面类测试
|
|
|
|
|
|
|
|
|
|
|
|
验证软件界面是否符合客户需求。
|
|
|
|
|
|
|
|
|
|
|
|
2.安全性测试
|
|
|
|
|
|
|
|
|
|
|
|
试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。
|
|
|
|
|
|
|
|
|
|
|
|
3.文档测试
|
|
|
|
|
|
|
|
|
|
|
|
以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。
|
|
|
|
|
|
|
|
|
|
|
|
#### (6)其他分类
|
|
|
|
|
|
|
|
|
|
|
|
1.α测试
|
|
|
|
|
|
|
|
|
|
|
|
软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。
|
|
|
|
|
|
|
|
|
|
|
|
2.β测试
|
|
|
|
|
|
|
|
|
|
|
|
软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。
|
|
|
|
|
|
|
|
|
|
|
|
3.回归测试
|
|
|
|
|
|
|
|
|
|
|
|
对修改后的程序重新进行测试确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。
|
|
|
|
|
|
|
|
|
|
|
|
4.随机测试
|
|
|
|
|
|
|
|
|
|
|
|
没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。
|
|
|
|
|
|
|
|
|
|
|
|
## 6.软件测试与软件开发的关系
|
|
|
|
|
|
|
|
|
|
|
|
软件测试在项目各个阶段的作用如下：
|
|
|
|
|
|
|
|
|
|
|
|
● 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。
|
|
|
|
|
|
|
|
|
|
|
|
● 需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么，同时制定系统测试计划。
|
|
|
|
|
|
|
|
|
|
|
|
● 概要设计与详细设计阶段：制定单元测试计划和集成测试计划。
|
|
|
|
|
|
|
|
|
|
|
|
● 编码阶段：开发相应的测试代码和测试脚本。
|
|
|
|
|
|
|
|
|
|
|
|
● 测试阶段：实施测试并提交相应的测试报告。
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
## 7.常见的软件测试模型
|
|
|
|
|
|
|
|
|
|
|
|
#### (1)V模型
|
|
|
|
|
|
|
|
|
|
|
|
V模型是一种水平型的软件测试模型，它把软件开发过程分为验收测试和系统测试两个阶段，每一阶段由一组测试活动构成，它们是相互联系的。V模型的优点在于及时发现缺陷，减少重复测试，减少发现缺陷所需要的时间，有效控制质量，提高效率，为软件开发提供可操作性的测试规范。
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
#### (2)W模型
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
W模型是一种垂直型的软件测试模型，它在V模型的基础上扩展出来的，它的特点是把软件开发过程分为8个部分，每个部分都有一组测试活动。W模型的优点在于，它能够更好地控制软件的质量，更加注重从需求分析到实施的整个软件开发过程，充分发挥测试人员的技术知识，提高测试效率。
|
|
|
|
|
|
|
|
|
|
|
|
#### (3)H模型
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
H模型是一种水平型的软件测试模型，它是V模型的升级版。H模型把软件开发过程分为4个部分，每个部分都有一组测试活动，它们都是相互联系的。H模型的优点在于，它能够更好地控制软件的质量，更加注重从需求分析到实施的整个软件开发过程，充分发挥测试人员的技术知识，提高测试效率，避免重复测试和发现缺陷所耗费的时间。
|
|
|
|
|
|
|
|
|
|
|
|
#### (4)X模型
|
|
|
|
|
|
|
2023-08-31 12:43:36 +08:00
|
|
|
|
|
2023-08-31 11:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
X模型是一种通过把软件开发过程分为多个交叉部分，每个部分都有一组测试活动的模型。X模型的优点在于，它可以更好地控制软件的质量，从需求分析到实施的整个软件开发过程都可以发挥测试人员的技术知识，提高测试效率，减少重复测试和发现缺陷所耗费的时间。
|
|
|
|
|
|
|
|
|
|
|
|
## 8.软件测试原则
|
|
|
|
|
|
|
|
|
|
|
|
#### (1)测试应基于客户需求
|
|
|
|
|
|
|
|
|
|
|
|
所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此满试应依照客户的需求配置环境，并且按照客户的使用习惯进行测试并评价结果。
|
|
|
|
|
|
|
|
|
|
|
|
#### (2)测试要尽早进行
|
|
|
|
|
|
|
|
|
|
|
|
软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早地开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制订出完善的计划和方案，提高测试的效率。
|
|
|
|
|
|
|
|
|
|
|
|
#### (3)穷尽测试是不可能的
|
|
|
|
|
|
|
|
|
|
|
|
由于时间和资源的限制，进行完全(各种输入和输出的全部组合)的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。
|
|
|
|
|
|
|
|
|
|
|
|
#### (4)遵循GoodEnough原则
|
|
|
|
|
|
|
|
|
|
|
|
GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。随着测试资源投入的增加，测试的产出也是增加的，但当投入达到一定的比例后，测试的效果就不会明显增强了。因此在测试时要根据实际要求和产品质量考虑测试的投入，最好使测试投入与产出达到一个GoodEnough状态。
|
|
|
|
|
|
|
|
|
|
|
|
#### (5)测试缺陷要符合“二八”定理
|
|
|
|
|
|
|
|
|
|
|
|
缺陷的“二八”定理也称为Pareto原则、缺陷集群效应，一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。
|
|
|
|
|
|
|
|
|
|
|
|
#### (6)避免缺陷免疫
|
|
|
|
|
|
|
|
|
|
|
|
我们都知道虫子的抗药性原理，即一种药物使用久了，虫子就会产生抗药性。而在软件测试中，缺陷也是会产生免疫性的。同样的测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定式。
|
|
|
|
|
|
|
|
|
|
|
|
要克服这种情况，就要不断对测试用例进行修改和评审，不断增加新的测试用例，同时，测试人员也要发散思维，不能只是为了完成测试任务而做一些输入和输出的对比。最后，没有缺陷的软件是不存在的，软件测试是为了找出软件测试中的缺陷，而不是为了证明软件没有缺陷。
|
|
|
|
|
|
|
|
|
|
|
|
## 9.软件测试流程
|
|
|
|
|
|
|
|
|
|
|
|
不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同的公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是一样的。
|
|
|
|
|
|
|
|
|
|
|
|
#### (1)分析测试需求
|
|
|
|
|
|
|
|
|
|
|
|
测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。此外，分析测试需求也是对软件需求进行测试，以发现软件需求中不合理的地方。
|
|
|
|
|
|
|
|
|
|
|
|
| **序号** | **检查项** | **检查结果** | **说明** |
|
|
|
|
|
|
| -------- | ------------------------------------------------------------ | ------------------ | -------- |
|
|
|
|
|
|
| **1** | 是否覆盖了客户提出的所有需求项 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **2** | 用词是否清晰、语义是否存在歧义 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **3** | 是否清楚地描述了软件需要做什么以及不做什么 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **4** | 是否描述了软件的目标环境，包括软硬件环境 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **5** | 是否对需求项进行了合理的编号 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **6** | 需求项是否前后一致、彼此不冲突 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **7** | 是否清楚地说明了软件的每个输入、输出格式，以及输入与输出之间的对应关系 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **8** | 是否清晰地描述了软件系统的性能要求 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **9** | 需求的优先级是否合理分配 | 是【】否【】NA【】 | |
|
|
|
|
|
|
| **10** | 是否描述了各种约束条件 | 是【】否【】NA【】 | |
|
|
|
|
|
|
|
|
|
|
|
|
被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。
|
|
|
|
|
|
|
|
|
|
|
|
#### (2)制定测试计划
|
|
|
|
|
|
|
|
|
|
|
|
测试计划一般要做好以下工作安排。
|
|
|
|
|
|
|
|
|
|
|
|
● 确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。
|
|
|
|
|
|
|
|
|
|
|
|
● 制定测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。
|
|
|
|
|
|
|
|
|
|
|
|
● 安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。
|
|
|
|
|
|
|
|
|
|
|
|
● 安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。
|
|
|
|
|
|
|
|
|
|
|
|
● 预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。
|
|
|
|
|
|
|
|
|
|
|
|
#### (3)设计测试用例
|
|
|
|
|
|
|
|
|
|
|
|
测试用例（Test Case）指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。
|
|
|
|
|
|
|
|
|
|
|
|
#### (4)执行测试
|
|
|
|
|
|
|
|
|
|
|
|
测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。在执行测试过程中，测试人员要密切跟踪测试过程，记录缺陷、形成报告等，这一阶段是测试人员最重要的工作阶段。
|
|
|
|
|
|
|
|
|
|
|
|
#### (5)编写测试报告
|
|
|
|
|
|
|
|
|
|
|
|
一份完整的测试报告必须要包含以下几个要点。
|
|
|
|
|
|
|
|
|
|
|
|
● 引言：测试报告编写目的、报告中出现的专业术语解释及参考资料等。
|
|
|
|
|
|
|
|
|
|
|
|
● 测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。
|
|
|
|
|
|
|
|
|
|
|
|
● 测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。
|
|
|
|
|
|
|
|
|
|
|
|
● 缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。
|
|
|
|
|
|
|
|
|
|
|
|
● 测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。
|
|
|
|
|
|
|
|
|
|
|
|
测试报告的数据是真实的，每一条结论的得出都要有评价依据，不能是主观臆断的。
|
