软件测试基础理论(三)

1. 测试用例评审

1. 1 同行评审

• 测试用例的检查方式有很多，同行评审是其中最敏捷的一种。
• “个体和交互比过程和工具更有价值”，这强调了测试用例设计者之间的思想碰撞，通过探讨、协作来完成测试用例的设计。

1. 2 用户评审

• 顾客的协作比合同谈判更有价值

　如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场调查人员或相关领域专家）；　　如果测试被定义为对开发提供帮助和支持，那么顾客就是程序员

2. 软件缺陷的定义

• 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
• 因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。
• 软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。
  • 软件未达到需求规格说明书表明的功能
  • 软件出现了需求规格说明书指明不会出现的错误
  • 软件的功能超出了需求规格说明书指明的范围
  • 软件未达到需求规格说明书虽未指明而应该达到的目标
  • 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好

3. 软件缺陷示例

• 计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应.
  • 软件未达到软件需求规格说明书表明的功能
• 若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。
  • 软件的功能超出了软件需求规格说明书指明的范围
• 若在测试过程中发现，因为电池没电而导致了计算不正确，但软件需求规格说明书未能指出在此情况下应如何进行处理
  • 软件未达到软件需求规格说明书未指明而应该达到的目标
• 假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应
  • 软件出现了软件需求规格说明书指明不会出现的错误
• 测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。
  • 软件测试人员认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好

4. 软件缺陷表现形式

• 功能、特性没有实现或部分实现。
• 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
• 产品实际结果和所期望的结果不一致。
• 没有达到需求规格说明书所规定的性能指标等。
• 运行出错，包括运行中断、系统崩溃、界面混乱等。
• 数据不正确、精度不够、不完整或格式不统一。
• 用户不能接受的其他问题，如存取时间过长、界面不美观。
• 硬件或系统软件上存在的其他问题

5. 软件缺陷的产生的原因

• 需求解释或者记录错误
• 用户需求定义错误
• 设计说明存在错误
• 编码说明、程序代码有误
• 硬件或者软件系统上存在错误
• 其他，如文档错误、内容不正确或拼写错误

6. 软件缺陷的根源

• 交流不充分
  • 客户与开发人员、开发人员与测试人员等
• 软件的复杂性
  • 功能复杂、开发复杂、测试复杂
• 开发人员的错误
  • 对需求的理解、开发压力、能力与经验
• 需求的变化
  • 需求说明书、设计文档、程序的变更
• 进度压力
  • 项目周期比较紧

7. 软件缺陷的信息

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计.

8. 软件缺陷分类——BUG类型

软件测试分类

9.缺陷严重程序

10. 开发人员拒绝修改的缺陷

• 程序员无法重现或者现象难以捕捉
• 没有明确的报告以说明重现缺陷的步骤
• 程序员无法读懂的缺陷报告
• 用户很少使用或者不符合用户使用习惯的操作出错
• 由不受信任的测试人员提出

11. 缺陷修改说明

• 不是所有缺陷都会修改
  • 市场的压力使得产品最终发行有时间限制
  • 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
  • 错误的修改影响的模块较多，带来的风险较大(遗留)
  • 修改性价比太低
  • 缺陷报告中提出的问题很难重现

12. 缺陷报告的重要性

• 软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的。
  • 清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。
  • 提高软件缺陷修复的速度，使项目组能够有效地工作
  • 提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。
  • 加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作。

13. 报告缺陷注意事项

• 尽量确保缺陷可以重现
  • 如果提交的缺陷无法重现，会影响开发人员的工作效率。
• 简洁、准确、完整
  • 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。
• 一个缺陷一个报告
  • 有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点：
    • 不便于分配
      • 比如缺陷报告有2个缺陷，分别属于不同的开发人员，到底该分配给谁呢？
    • 不便于验证
      • 比如一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2还没有解决，那么这个缺陷报告该不该关闭呢？

14. 缺陷书写规范

• 标题：应保持简短、准确，提供缺陷的本质信息
  • 尽量按缺陷发生的原因与结果的方式书写；
  • 避免不要使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；
  • 为了便于他人理解，避免使用俚语或过分具体的测试细节。
• 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。
  • 为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：
    • 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；
    • 包含的信息过少，丢失了操作的必要步骤；
• 复现步骤的正确书写方式：
  • 提供测试的环境信息；
    • 系统
    • 系统版本
      • windows 7,8,10.
      • linux
        • centos
        • ubuntu
        • ….
      • mac os
        • 版本号….
    • 尽可能详细我测试环境
  • 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；
  • 每个步骤前使用数字对步骤编号；
  • 尽量使用短语或短句，避免复杂句型句式；
  • 复现的步骤要完整、准确、简短；
  • 将常见步骤合并为较少步骤；
  • 按实际需要决定是否包含步骤执行后的结果。
• 实际结果：是执行复现步骤后软件的现象和产生的行为。
  • 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
• 期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
• 避免常见的错误：
  • 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
  • 避免使用情绪化的语言和强调符号；
  • 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
  • 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
  • 避免提交不确定的测试问题，自己至少需要重现一次再提交。
  • 反面的示例：
    • 上海人：哪能查询到的结果和查询条件不搭噶的。
    • 北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。

 

来源：知乎

作者：天行健

链接：https://zhuanlan.zhihu.com/p/82068693

可以关注我的公众号了解更多方面的内容：

                                                      -------------------------------------善知软件实训--------------------------------