|
|
测试常识
什么是“软件测试”?
软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。也就是说，如果用户面对着应用程序的 A 界面，在使用硬件 B 的时候做 C 操作，那么 D 结果应该出现。所谓受控制的条件应该包括正常条件和非正常条件。应该故意地去促使错误的发生，也就是事情在不该出现的时候出现或者在应该出现的时候没有出现。从本质上说，软件测试是“探测”。
在如何负责质量保障和软件测试的责任方面，各个机构有不同的做法。有时候，由一个小组或者个人来负责。常见的办法是项目组包括了测试人员和开发人员，他们在一起合作工作，由项目负责人来对质量保障进行总负责。这取决于该机构的大小和该机构的商务结构。
(软件测试是在受控制的条件下对系统或应用程序进行操作并评价操作的结果)
在软件开发过程中5个常见的问题是什么?
M 需求说明差 (poor requirements) ── 需求不清楚、不完整、太概括、或者不可测试，都会造成问题。
M 不切实际的时间表 (unrealistic schedule) ── 如果在很短的时间里要求做许多事，出现错误是不可避免的。
M 测试不充分 (inadequate testing)── 只能根据客户意见或者系统崩溃来判断系统质量的高低。
M 不断增加功能 (featuritis) ── 在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
M 交流问题 (miscommunication) ── 如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
(需求说明差 不切实际的时间表 测试不充分 不断增加功能 交流问题)
针对软件开发过程中的问题，有5个解决办法：
ü 可靠的需求 (solid requirements) —— 应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。
ü 合理的时间表 (realistic schedules) —— 为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
ü 适当的测试 (adequate testing) —— 尽早开始测试；每次改错或变更之后，都应重新测试。项目计划中要为测试和改错留出足够的时间。
ü 尽可能坚持最初的需求 (stick to initial requirements as much as possible) —— 一旦开发工作开始，要准备防止修改需求和新增功能。要说明这样作的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。
ü 沟通 (communication ) —— 在适当时机进行预排和检查；充分利用团组通信工具 —— 电子邮件、群件 (groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档；进行远距离联合作业及协作；尽早使用模型，使得客户的预想是清楚的。
(可靠的需求 合理的时间表 适当的测试 尽可能的坚持最初的需求 沟通)
软件测试包括哪些内容?
以下是一些需要考虑的步骤：
ü 得到需求、功能设计、内部设计说书和其他必要的文档
ü 得到预算和进度要求
ü 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 (例如发行过程、变更过程、等等)
ü 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
ü 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
ü 确定对测试环境的要求 (硬件、软件、通信等)
ü 确定所需的测试用具 (testware)，包括记录/回放工具、覆盖分析、测试跟踪、问题/错误跟踪、等等
ü 确定对测试的输入数据的要求
ü 分配任务和任务负责人，以及所需的劳动力
ü 设立大致的时间表、期限、和里程碑
ü 确定输入环境的类别、边界值分析、错误类别
ü 准备测试计划文件和对计划进行必要的回顾
ü 准备白盒测试案例
ü 对测试案例进行必要的回顾/调查/计划
ü 准备测试环境和测试用具，得到必需的用户手册/参考文件/结构指南/安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
ü 得到并安装软件版本
ü 进行测试
ü 评估和报告结果
ü 跟踪问题/错误，并解决它
ü 如果有必要，重新进行测试
ü 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
什么是“测试案例”?
测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。
注：开发一个应用软件的测试案例的过程，需要全面、深入地考虑该软件的操作，所以有助于发现在其需求或设计里面的问题。因此，如果有可能，在开发周期中应当尽早准备测试案例。
(测试案例包括:测试标识, 案例名称,目标,测试条件/设置,输入数据要求,步骤,以及预期结果)
如果时间不够，无法进行充分的测试怎么办?
使用风险分析，确定测试的重点。
由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：
ü 对于该项目的用途而言，哪种功能最重要?
ü 哪种功能对用户最明显?
ü 哪种功能对安全影响最大?
ü 哪种功能对用户最有用?
ü 对客户来说，该应用软件的哪个部分最重要?
ü 在开发过程中，该应用软件的哪个部分可以最先测试?
ü 哪一部分代码最复杂，容易导致出现错误?
ü 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?
ü 哪一部分程序与过去项目中引起问题的部分相类似/有关?
ü 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
ü 需求和设计的那些部分不清楚或不容易读?
ü 开发人员认为在应用软件中哪些部分是高风险的?
ü 哪些问题能造成最差的发行?
ü 哪些问题最能引起用户抱怨?
ü 哪些测试可以容易地覆盖多种功能?
ü 哪些测试在覆盖高风险部分的测试时使用时间最少?
如果需求一直在变化怎么办?
这是一个常见的令人头疼的问题。
ü 如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。
ü 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。
ü 好的代码注释和好的文档有助于开发人员作出相应的改变。
ü 只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。
ü 在项目的时间表中应当留出余量，以应付可能出现的变更。
ü 尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。
ü 通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。
ü 要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。
ü 在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。
ü 在设计自动测试剧本时，试图使其有一些灵活性。
ü 在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
ü 对变更进行适当的风险分析，以减少回归测试的要求。
ü 在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。
ü 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。
面向对象的设计如何影响测试?
好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试，最后追溯到需求，成为一件容易的事。因为它对黑盒测试的影响很少 (不需要了解应用软件的内部设计) ，而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好，就可简化测试设计。[br]<p align=right><font color=red>+3 RD币</font></p> |
|
IP卡
狗仔卡
发表于 2006-11-7 13:06:28
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡