六天入门软件测试①——测试执行讲义
Day 1 测试执行讲义
软件测试工作的参与是从执行开始的。开始从事软件测试以后，第一个接触的工作内容一般都是执行。那么什么是执行呢？
测试执行，是按照测试设计的要求，通过执行测试用例，对比预期结果与设计结果的过程。
从这里开，引出了新的内容：测试用例。实际上整个测试执行是围绕着测试用例进行的。我们这篇讲义解决的主要问题是：
- 在项目中，请问你执行过什么样的测试？
- 在执行测试的过程中，你遇到过什么问题？如何解决的？
- 如何高效的执行测试？
- 在项目中，请问你发现过什么样的缺陷？
0 主要内容
- 1 P1_禅道系统使用
- 2 T1_测试执行
- 3 T3_软件缺陷
1 P1_禅道系统使用
“工欲善其事，必先利其器”，在任何时候，任何情况下，这句亘古不变的道理，都是来帮助我们前行的方法。软件测试也不例外，测试活动是依靠工具进行的。禅道项目管理软件是『王春生』大神的作品，国产开源项目管理软件的佼佼者。不得不说，更多的禅道的使用者是软件测试人员，理由其实很“历史”，开发人员有自己的管理系统，并且该系统不支持测试管理。
是的，中国的不长的软件开发历史上，确实是以“开发”为重的，等到越来越多的公司和团队意识到软件测试的重要性的时候，其实已经不用往“开发的管理系统”上再开发添加测试功能了，因为有了专门管理测试的软件，例如：禅道。当然也有 Bugfree，QC/ALM，JIRA，Mantis 等，国产管理系统中，禅道算是比较完整的方案，当然还有一些其他的方案，名气最大的应该是腾讯公司的 TAPD，以及 Testin 的 BugOut，还有今天刚刚看到的飞蛾（http://feie.work），这里我们还是专门聊禅道。
还是要说一句的是，希望技术团队的开发人员也尽早能够用上禅道，如果测试人员在用禅道的话。
1.1 禅道部署
首先，要用禅道，我们要做的事情是需要安装部署。禅道是一个 PHP 开发的 Web 系统，需要一个支持 PHP 的 Web 服务器，建议用 Apache 或者 Nginx，迫不得已用 IIS 也可以。安装步骤如下：
- 安装 xampp
- 官网下载禅道源码包，最新的源码包为 zentaopms.10.4.stable.zip（http://dl.cnezsoft.com/zentao/10.4/ZenTaoPMS.10.4.stable.zip）
- 复制源码包到 xampp/htdocs 目录中，并解压出来，形成 xampp/htdocs/zentaopms 文件目录
- 启动 apache 和 MySQL
- 访问 http://localhost/zentaopms/www 按照提示，完成安装。
- 也可以不使用 xampp，例如在 Linux 中安装，或者用 WampServer、宝塔、PhpStudy、UPUPW 等都可以完成禅道的部署。当然与可以部署在 阿里云服务器、腾讯云服务器、天翼云服务器等。具体的安装步骤截图等就不再这里赘述了。
1.2 禅道使用
如果禅道部署好了，可以使用 http://localhost/zentaopms/www 访问禅道
如果禅道尚未部署好，也可以使用 http://demo.zentao.net/ 禅道官方提供的体验版本访问禅道
初次使用禅道，我们需要使用的地方是“测试”模块，以及“用例”和“Bug”两个功能。
-
测试模块
image.png
-
用例和Bug功能
image.png
1.3 创建用例
测试用例，是“测试执行用到的例子”，英文是 Test Case，有时候简写 TC，或者 case 等。
我们通过禅道的测试用例添加页面，来分析测试用例的组成和编写。
image.png
主要包括以下几个部分：
- 标题：一般包括编号和描述，编号是用例的识别号，描述是用例的主要涉及内容。
- 步骤：用例执行的每一步
- 预期：用例执行的每一步对应的预期结果
- 级别：一般为①、②、③、④，默认一般选择③。级别越小，越优先执行。
一个用例的栗子如下：
image.png
用例的详情
image.png
步骤和期望
image.png
2 T1_测试执行
2.1 测试执行的概述
测试执行是对测试实现（测试用例完成）后的进一步测试过程，通过对测试用例的执行，从而验证产品的质量。
测试执行有三个要点：
- 测试用例的执行，在项目经理（开发经理）提测以后进行。
- 测试用例的执行，需要指定测试版本
- 测试用例的执行得到的缺陷，需要测试工程师的分析与跟踪
测试执行的核心内容：①编写测试用例，②准备测试数据，③执行测试用例
2.2 测试场景与测试执行
测试场景，Test Scenario，是实际项目中最重要的测试部分之一。事实上，测试场景是用户行为的描述。测试执行最靠谱的方式就是按照测试场景执行。步骤如下：
- 分析并列出每一个测试场景
- 对每一个测试场景编写测试用例
- 对每一个用例准备测试数据
- 然后执行每一个用例
2.3 测试执行的结果
测试执行的结果一般来说有两种：执行通过和执行失败
- 执行通过，PASS：
- 开发人员没错
- 测试用例安装准备好的数据，可以进行每一步，并且每一步的结果都是和预期一致。
- 执行失败，FAIL：
- 开发人员错了
- 测试用例执行过程中的某一步，结果与预期不要一致
有些时候，测试执行的结果还有一种：执行异常
- 执行异常，ERROR：
- 测试人员错了
- 用例错误，用例的步骤不对，用例的步骤无法执行。
3 T3_软件缺陷
3.1 软件的质量需求
- 软件质量的定义： 质量是反映实体(产品、过程或活动等)满足明确和隐含需要的能力的特性总和。
- 软件质量的管理体系
- ISO9001
- CMM：Capability Maturity Model，能力成熟度模型
- 软件质量的模型
- 功能性：是指当软件在指定条件下使用，软件产品满足明确和隐含要求功能的能力。
- 适合性：是指软件产品与指定的任务和用户目标提供一组合适的功能的能力。
- 准确性：是指软件产品具有所需精确度的正确或相符的结果及效果的能力。
- 互操作性：是指软件产品与一个或多个规定系统进行交互的能力。
- 保密安全性：是指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，但不拒绝授权人员或系统对其的访问。
- 功能依从性：是指软件产品依附与同功能性相关的标准、约定或法规以及类似规定的能力。
- 可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。
- 成熟性：是指软件产品避免因软件中错误发生而导致失效的能力。
- 容错性：是指在软件发生故障或违反指定接口的情况下，软件产品维持规定的性能级别的能力。
- 易恢复性：是指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。
- 可靠性依从性：是指软件产品依附与同可靠性相关的标准、约定或法规以及类似规定的能力。
- 易用性：是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
- 易理解性：是指软件产品使用户能理解软件产品是否合适以及如何能将软件用于特定的任务和使用环境的能力。
- 易学性：是指软件产品使用户能学习它的能力。
- 易操作性：是指软件产品使用户能操作和控制它的能力。
- 吸引性：是指软件产品吸引用户的能力。
- 易用性依从性：是指软件产品依附与同易用性相关的标准、约定、风格指南或法规以及类似规定的能力。
- 效率：是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。
- 时间特性：是指在规定条件下，软件产品执行其功能时，提供适当的响应时间和处理时间以及吞吐率的能力。
- 资源利用性：是指在规定条件下，软件产品执行其功能时，提供合适的数量和类型的资源的能力。
- 效率依从性：是指软件产品依附与同效率相关的标准或约定的能力。
- 维护性：是指软件产品可被修改的能力，修改可能包括修正，改进或软件适应环境、需求和功能规格说明中的变化。
- 易分析性：是指软件产品诊断软件中的缺陷或失效原因，以及判定待修改的部分的能力。
- 易改变性：是指软件产品使指定的修改可以被实现的能力。
- 稳定性：是指软件产品避免由于软件修改而造成意外结果的能力。
- 易测试性：是指软件产品使已修改软件能被确认的能力。
- 维护性依从性：是指软件产品依附与同维护性相关的标准或约定的能力。
- 可移植性：是指软件产品从一种环境迁移到另一种环境的能力。
- 适应性：是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同的指定环境的能力。
- 易安装性：是指软件产品在指定环境中被安装的能力。
- 共存性：是指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
- 易替换性：是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。
- 可移植性依从性：是指软件产品依附与同可移植性相关的标准或约定的能力。
- 功能性：是指当软件在指定条件下使用，软件产品满足明确和隐含要求功能的能力。
3.2 软件质量的对立面--软件缺陷
-
问题的引出
The First “Computer Bug” | 首个“计算机Bug”
Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1947. The operators affixed the moth to the computer log, with the entry: “First actual case of bug being found”. They put out the word that they had “debugged” the machine, thus introducing the term “debugging a computer program”.
1947年9月9日，哈佛大学测试马克II型艾肯中继器计算机，操作员在电板编号为70的中继器触点旁发现了一只飞蛾。然后操作员把飞蛾贴在计算机日志上了，并写下了“首个发现bug的实际案例”。他们提出了一个词，“debug（调试）”了机器，从而引入新术语“debugging a computer program（调试计算机程序）”。
In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia.
1988年，这个仍然贴着飞蛾的日志，保存于弗吉尼亚州达尔格伦的海军水面作战中心计算机博物馆。
以下的两句话明确了缺陷的产生。
程序员犯了一个错误，这个错误在程序中表现为缺陷
运行带有缺陷的软件或者程序，就可能观察到失效
-
缺陷
程序或者软件中不正确的步骤、过程或者数据定义等
- 错误的语句
- 错误的标量定义
- 不正确的文档
- 不正确的程序段
- 不正确的指令
- 不正确的数据定义
- ……
-
失效
软件系统或单元无法实现需求文档中规定的功能特性或者非功能特性
- 不正确的系统反应
- 系统崩溃
- 系统死机
- ……
-
缺陷产生的原因
软件缺陷的产生主要有软件产品的特点和开发过程决定的。比如需求不够清晰，频繁变更等；或者软件由于竞争非常激烈，技术日新月异，使用新技术也容易产生问题。大致有以下几种主要原因：
- 项目期限的压力
- 产品的复杂程度
- 沟通不良
- 开发人员疲劳、压力过大或者受到干扰
- 缺乏足够的知识、技术和经验
- 不了解客户的需求
- 缺乏动力
-
缺陷管理的目的
软件测试就是为了更早、更快的发现缺陷。换句话说，缺陷的发现可以看作是测试工作的主要成果之一。软件缺陷管理的实施，至少有如下三个基本目的：
- 加快缺陷的修正。
- 产品的质量评估
- 预防缺陷
-
最终的定义
软件缺陷（Defect），常常又被叫做Bug。 所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
-
bug 和 defect
飞蛾或者虫子爬进主机引起短路，造成计算机失效的事件中，我们可以看到bug就是虫子或者是虫子引发失效这样的事件。那么defect又是什么呢？
真正的Defect是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，即不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。
-
术语解释
软件测试使用各种术语描述软件出现的问题，通用的术语如下：
-
软件错误
Software Error， 导致软件包含故障的人的行为。软件生存期内的人为错误，导致软件缺陷产生。是人为过程，相对于软件本身是外部行为。
在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿者人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。
-
软件缺陷
Software Defect，软件的异常情况，软件存在的一些短板。存在于软件（文档、数据、程序）中的偏差，导致软件在某个特定条件下出现故障，这时称软件缺陷被激活。
软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。
-
软件故障
Software Fault，引起一个功能组件不能完成所要求的功能的一种意外情况。软件运行过程中出现的不希望或不可接收的内部状态。是动态行为。
软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无时当的措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。
-
软件失效
Software Failure，功能组件执行其规定功能的能力丧失。软件运行时产生的不希望或不可接受的外部行为结果。
软件失效是指软件运行时产生 的一种不希望或不可接受的外部行为结果。失效是指功能部件执行其规定功能的能力丧失。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。
软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有集市的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。
-
-
缺陷的类型
- 遗漏（Missing）
- 错误（Error）
- 额外的实现（Extra）
- 改进（Enhancement）
-
缺陷的评价标准
- 软件未实现需求规格说明书要求的功能
- 软件未实现需求规格说明书虽未明确提及但应该实现的目标
- 软件出现了需求规格说明书指明不应出现的错误
- 软件实现了需求规格说明书未提到的功能
- 软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好
-
缺陷报告
测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。
软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初并且最好的机会。一个好的描述，需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。因此，准确的报告软件缺陷是非常重要的。
- 清晰准确的软件缺陷描述可以减少被开发人员退回来的缺陷数量
- 提高软件缺陷修复的速度，使每一个小组能够有效的工作
- 提高测试人员的可信任度，可以得到开发人员对有效缺陷的快速或者及时响应
- 加强开发人员、测试人员和管理人员的协同工作，让他们可以更好的工作
-
缺陷分析
- 错误：程序员在写代码的时候犯错误，写错代码，此时程序已经有了缺陷
- 失效：错误的代码在运行的时候，遇到特定的情况，激发了错误之处，导致程序被观察到失效
- 缺陷：程序的失效，会证明软件有缺陷
3.3 软件缺陷与Bug
-
第一个Bug 发现的过程。
1947年9月9日，哈佛大学测试马克II型艾肯中继器计算机，操作员在电板编号为70的中继器触点旁发现了一只飞蛾。然后操作员把飞蛾贴在计算机日志上了，并写下了“首个发现bug的实际案例”。他们提出了一个词，“debug（调试）”了机器，从而引入新术语“debugging a computer program（调试计算机程序）”。1988年，这个仍然贴着飞蛾的日志，保存于弗吉尼亚州达尔格伦的海军水面作战中心计算机博物馆。
Paste_Image.png
bug就是虫子或者是虫子引发失效这样的事件。
主机的散热孔缺少更加细密的金属网，这是计算机设计人员疏忽的地方，是产品真正的Defect。
而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。
-
缺陷产生的原因
- 项目期限的压力
- 产品的复杂程度
- 沟通不良
- 开发人员疲劳、压力过大或者受到干扰
- 缺乏足够的知识、技术和经验
- 不了解客户的需求
- 缺乏动力
-
Bug报告单写作原则：5C
- Correct（准确）每个组成部分的描述准确，不会引起误解
- Clear（清晰）每个组成部分的描述清晰，易于理解
- Concise（简洁）只包含必不可少的信息，不包括任何多余的内容
- Complete（完整）包含复现该缺陷的完整步骤和其他本质信息
- Consistent（一致）按照一致的格式书写全部缺陷报告
-
缺陷的状态
| 缺陷的状态 | 描述 |
|---|---|
| 激活的或打开的（Active or Open） | 缺陷的起始状态，问题还没有解决，等待修复 |
| 已修正的或已修复的（Fixed or Resolved） | 已被开发人员检查和修复，等待验证人员验证 |
| 关闭的或非激活的（Close or Inactive） | 验证通过，确认缺陷已经可以关闭 |
| 重新打开 （Reopen） | 验证不通过，需要 |
| 推迟 （Deferred） | 缺陷不严重，在下一个版本中解决 |
| 保留 （On hold） | 由于技术原因或者其他原因，暂时无法解决 |
- 缺陷的优先级
| 缺陷的优先级 | 描述 |
|---|---|
| 立即解决（P1） | 缺陷导致系统不可使用，无法测试或者测试无法继续 |
| 高优先级（P2） | 缺陷严重，影响测试，需要优先考虑 |
| 正常排队（P3） | 缺陷需要正常排队等待修复 |
| 低优先级（P4） | 缺陷可以在开发人员有时间的时候被修正 |
- 缺陷的严重级别
| 缺陷的严重级别 | 描述 |
|---|---|
| 致命（Fatal） | 系统的主要功能完全失效，用户利益受到损失、系统崩溃、死机等 |
| 严重（Critical） | 系统的主要功能部分失效，数据无法保存、提供的服务受到影响 |
| 一般（Major） | 系统的次要功能没有完全实现，不影响用户的正常使用，如提示不准确等 |
| 较小（Minor） | 用户体验不好，不影响功能实现 |
-
缺陷在禅道中的栗子
创建缺陷
image.png
- 缺陷标题：描述清楚问题所在
- 严重程度：是不是很严重，一般是①，②，③，④。
- 优先级别：是不是很着急修复，一般是①，②，③，④。
- 重现步骤：非常重要，开发人员根据提供的步骤，对应截图进行重现问题。
六天入门软件测试系列课程总纲
- 相关学习
网友评论