软件质量保证和测试不常见的问题

如果一个组织的增长速度如此之快以至于固定的质量保证程序是不可能的 
这是软件行业常见的问题，特别是在新技术领域。在这种情况下，通常没有简单的解决方案。一种方法是：

· 雇用好人

· 管理层应该“无情地优先考虑”质量问题并保持对客户的关注

· 组织中的每个人都应该清楚“质量”对客户意味着什么

根据增长率的不同，增量自我管理的团队方法可能是适用的，例如“改善”持续流程改进方法或Deming-Shewhart Plan-Do-Check-Act循环等等。

---

自动化测试工具会使测试更容易吗？

· 有可能。对于小型项目，学习和实施这些项目所需的时间可能并不值得，除非人员已经熟悉这些工具。对于较大的项目或持续的长期项目，它们可能是有价值的。

· 大多数测试自动化工具使用标准的编码语言，如ruby，python，Java等，或专用于该工具的专有脚本语言。有时初始测试可以被“记录”，以便自动生成测试脚本。然后根据需要进行修改。自动化测试面临的挑战之一是，如果被测系统持续发生变化，测试自动化代码可能不得不经常更改，以至于不断更新脚本变得非常耗时（因此代价昂贵）。此外，结果（屏幕，报告，数据，日志等）的解释和分析可能是一项艰巨的任务。请注意，Web和UI界面以及基于文本和后端界面以及所有类型的平台都有测试自动化工具和框架。

· 功能测试自动化的一种常见方法是“数据驱动”或“关键字驱动”的自动化测试，其中测试驱动程序与测试中使用的数据和/或动作分开（“动作”将是像“在文本框中输入一个值”）。测试驱动程序可以是自动化测试工具或框架或自定义测试软件的形式。数据和操作可以更容易维护 - 比如通过电子表格- 因为它们与测试驱动程序是分开的。测试驱动程序“读取”数据/操作信息以执行指定的测试。这种方法可以实现对自动化测试/测试用例的更有效的控制，开发，记录和维护。

· 其他自动化工具可以包括：

 代码分析器 - 监视代码复杂性，遵守标准等

 覆盖率分析器 - 这些工具检查哪些部分代码已经通过测试，并可能面向代码语句的覆盖面，条件覆盖                  率，路径覆盖率等

 内存分析器 - 如边界检查器和泄漏检测器。

 负载/性能测试工具 - 用于测试客户端/服务器和各种负载下的Web应用程序水平。

 网络测试工具 - 检查链接是否有效，HTML代码用法是正确的，客户端和服务器端程序工作，一个网互动                 是安全的。

 其他工具 - 用于测试用例管理，BDT（行为驱动测试），文档，管理，错误报告和配置管理，文件和数             据库比较，屏幕捕获，安全测试，宏观录像机等

当然，如果没有COTS工具，测试自动化是可能的。许多成功的自动化工作都利用开源工具，或针对特定项目，特定软件应用程序或特定组织软件开发环境的自定义自动化软件。在测试驱动的敏捷软件开发环境中，应用程序编码期间（或之前）通常会在软件中内置自动化测试。

---

选择测试自动化工具的最佳方法是什么？ 
很容易陷入对测试自动化“银弹”的热情之中，梦想是单击一下鼠标即可初始化整个软件应用程序的全面无人值守测试，错误将自动报告，易于理解总结报告将在上午在经理的收件箱中等待。

虽然在某些情况下可能实际上是可能的，但事实并非如此。

在手动测试中，测试工程师执行软件功能来确定软件是否以预期的方式工作。这意味着测试人员必须能够判断测试的预期结果，例如预期的数据输出，屏幕消息，用户界面外观的变化，XML文件，数据库更改等。在自动化测试中，计算机没有人类的“判断”能力来确定测试结果是否正确。这意味着必须有一种机制，通过这种机制，计算机可以在每个自动化测试场景中自动比较实际结果和预期结果，并毫不含糊地进行合格或不合格判定。这个因素可能需要整个测试方法的重大改变，

· 根据软件系统的预测试状态的变化对预期的测试结果进行精神调整

· 通常会根据需要对测试中使用的数据进行即时调整

· 对每个测试的结果做出合格/不合格判断

· 对需求的变化做出快速的判断和调整。

· 根据需要做出各种其他类型的判断和调整。

对于那些测试自动化的新手来说，先做一些阅读或培训可能是一个好主意。有很多方法可以做到这一点; 一些示例方法是：

· 在网上阅读有关测试自动化的信息，例如某些测试工具供应商网站上提供的一般信息，或“其他资源” 自动化部分中列出的一些自动化测试文章 。

· 阅读一些关于测试自动化的书籍

· 获得一些测试工具试用版或低成本或开源测试工具并进行试验

· 参加与测试自动化相关的软件测试会议或培训课程

和其他任何事情一样，正确的计划和分析对于成功选择和使用自动化测试工具至关重要。仅仅为了“自动化测试”而选择测试工具是没有用的; 有用的目的可能包括：更彻底地测试，通过手动方法（例如负载测试）以前不可行的方式进行测试，更快地测试，实现持续集成过程，或者减少过于繁琐的手动测试。自动化测试很少能够节省测试成本，尽管与其他任何质量相关的举措一样，可以节省软件生命周期（或增加销售额）。

有了测试自动化的适当背景和理解，以下考虑因素可以帮助您选择测试工具（自动化测试不一定能够解决这些问题，它们仅仅是自动化潜力的考虑因素）：

· 分析当前的非自动化测试情况，以确定哪些测试没有完成或看起来不够用

· 目前的测试过于耗时的地方在哪里？

· 目前的测试过于繁琐？

· 什么样的问题在目前的测试中屡屡错过？

· 什么样的测试程序被重复执行（如回归测试或安全测试）？

· 什么样的测试程序不是反复进行，而应该是？

· 什么样的测试跟踪和管理流程可以通过使用自动化测试工具来实现或提高效率？

考虑到通过分析这些考虑因素和其他适当因素确定的测试需求，可以确定所需测试工具的类型。对于每种类型的测试工具（例如功能测试工具，负载测试工具等），可以根据软件应用的特性进一步缩小选择范围。当然，相关特性将取决于测试工具的情况和类型等因素。这些特性可以包括操作系统，GUI组件，开发语言，Web服务器类型等。影响选择的其他因素可以包括测试人员的经验水平和能力，开发定制自动化测试工具的优点/缺点，工具成本，工具质量和易用性，该工具在其他项目上的有用性等。

一旦选择了潜在测试工具的简短列表，可以在试用的基础上使用几个测试工具进行最终测定。任何昂贵的测试工具都应该在试用期间进行彻底的分析，以确保它是合适的，并且它的能力和局限性是很好理解的。这可能需要大量时间或培训，但另一种选择是承担错误投资（时间，资源和/或采购价格）的主要风险。

---

如何确定测试环境是否合适？ 
这是一个难题，因为它通常需要在“更好”的测试环境和成本之间进行权衡。最终的情况将是一个测试环境的集合，模拟所有可能的硬件，软件，网络，数据，以及使用该软件的预期现场环境的使用特性。对于许多软件应用程序，这将涉及几乎无限的变化，显然是不可能的。而对于新的软件应用程序来说，预测应用程序运行环境的所有变化也是不可能的。对于非常大型，复杂的系统来说，复制“现场”类型的环境可能过于昂贵。

在现实中，必须对软件应用环境的哪些特征是重要的做出判断，并且在考虑时间，预算和后勤约束的情况下可以在此基础上选择测试环境。这样的判断最好由具有最合适的技术知识和经验的人员以及对风险和限制的理解来完成。

对于规模较小或风险较低的项目而言，非正式方法是常见的，但对于风险较大或较高的项目（金钱，财产或生活方面），涉及多名人员和大量工作和费用的更正式流程可能是适当的。

在某些情况下，有可能减轻维护大量不同测试环境的需要。一种方法可能是通过beta测试工作来协调内部测试。另一种可能的缓解方法是提供在最终用户安装应用程序时自动运行的内置自动化测试。这些测试然后可以通过互联网自动回报有关应用环境和遇到的问题的信息。另一种可能性是使用虚拟环境而不是物理测试环境，使用诸如VMWare或VirtualBox等工具。

---

什么是最好的软件测试评估方法？ 
这个没有简单的答案。“最佳方法”高度依赖于特定组织和项目以及相关人员的经验。

例如，如果给定两个类似复杂性和规模的软件项目，那么对于一个项目来说，适合的测试工作可能是非常大的，如果是用于生命关键的医疗设备软件的话，但是对于另一个项目来说可能会小得多成本电脑游戏。仅考虑规模和复杂性的测试评估方法可能适用于一个项目，而不适用于其他项目。

以下是一些考虑的方法：

隐式风险背景方法：
测试评估的典型方法是项目经理或质量管理经理隐含地使用风险背景，结合组织过去的个人经验，选择分配到测试的资源水平。在许多组织中，“风险背景”被假定为从一个项目到下一个项目是相似的，所以没有明确考虑风险背景。（风险背景可能包括组织的典型软件质量水平，软件的预期用途，开发人员和测试人员的经验水平等因素）。这基本上是基于经验的直观推测。

基于指标的方法： 
一个有用的方法是追踪一个组织的各种项目的过去经验以及对项目有效的相关测试工作。一旦有一组涵盖合理数量项目的特征的数据，那么这个“过去的经验”信息就可以用于未来的测试项目计划。（随着时间的推移确定和收集有用的项目指标可能是一项非常困难的任务。）对于每个特定的新项目，可以根据可用的度量或其他信息来调整“预期”所需的测试时间，例如功能点数，数量外部系统接口，开发人员完成的单元测试，项目风险等等。最后，这基本上是“基于记录的经验判断”，并不容易。

测试工作分解方法：
另一种常见的方法是将预期的测试任务分解成一系列小任务，至少在理论上可以以合理的精度进行评估。这当然假定测试任务的准确和可预测的分解和他们的估计努力是可行的。在许多大型项目中，情况并非如此。例如，如果在项目中发现大量的错误，则会增加测试，重新测试，错误分析和报告所需的时间。这也会增加开发所需的时间，如果开发进度和努力没有按计划进行，这将进一步影响测试。

迭代方法：
在这种大型测试方法中，首先进行粗略的测试估计。一旦开始测试，在第一次估算工作的一小部分（例如1％）完成之后，将进行更精确的估计。在这一点上，测试人员获得了更多的测试项目知识，对问题，一般软件质量和风险有了更好的理解。测试计划和时间表可根据需要进行重构，并提供新的估算。然后，在新工作估算的比例较大（例如2％）完成之后，进行更精确的估算。根据需要/适当重复循环。

发展百分比方法：
一些组织根据估计的编程工作利用快速估算方法进行测试。例如，如果一个项目估计需要1000小时的编程工作，并且组织通常发现40％的测试比例是合适的，那么将使用估计400小时的测试。这种方法可能会也可能不会有用，这取决于项目之间在风险，人员，应用类型，复杂程度等方面的差异。

对于大多数组织来说，成功的测试评估是一个挑战，因为很少有人能够准确地评估软件项目开发工作，更不用说项目的测试工作。如果没有一个项目的详细信息，包括详细的需求，过去对类似项目的经验，以及对项目“测试”估算中应该包括什么的理解，功能也很难尝试测试估算测试？单元测试？评论？检查？负载测试？安全测试？）

使用敏捷的软件开发方法，如果使用纯粹的测试驱动开发，测试工作估算可能是不必要的。然而，将一些自动化的正面型单元测试与一些单独的手动或自动功能测试结合起来并不罕见。一般而言，基于敏捷的项目本质上不会严重依赖于大型的一次性测试工作，因为他们强调在短的迭代周期内构建可释放的软件。测试估计通常集中在个人的“故事”以及与这些测试相关的测试上。这些较小的多重测试努力估计可能不是很难估计，不准确的估计的影响将不那么严重，并且预期每个冲刺都会提高估计。