Tag Archives: Testing

best payday loans 缺陷工作流程和缺陷报告

最近在读《How We Test Software at Microsoft》 其中的缺陷和测试用例管理,发现很多思路和做法跟目前我们在进行的也颇为相似,总结如下: 缺陷管理和用例管理是一个软件测试项目的必备,无论是数千人的国际化大企业,还是三五人的小软件作坊。这都是测试队伍的两大工作成果。其中,测试用例描述测试 过程的意图,缺陷则描述这些测试用例的结果。,今天谈谈缺陷工作流程。 best online payday loans 缺陷工作流程为: 文字描述如下: 产品代码-》运行测试用例-》创建缺陷报告-》三方会审讨论缺陷 如果缺陷没有批准-》把缺陷当作不修正来解决-》关闭缺陷 如果缺陷批准了要调查-》研究是代码错误还是设计错误 如果是代码错误,提议修正代码错误-,在提交三方会审-》如果修正批准了-》修改代码-》解决缺陷-》重现缺陷-》通过了则关闭缺陷;不通过,则重新激活-》重新调查是代码错误还是设计错误 如果是设计错误,修正错误直到批准-》再进行三方会审。其他后续流程和以前类似。 在这里需要注意的是,有些缺陷需要综合考虑优先级别,产品发布周期等因素,标注为不予修复。也就是说虽然承认该缺陷,但不会修正,或者决定推迟修正,即该缺陷会在未来的版本修正。这些不予修正的缺陷应该在release notes中予以注明。 这里所说的三方会审,一般意义上指的是开发测试和项目管理。 缺陷报告中应该经常避免的几个错误: 1.电子邮件讨论 电子邮件和缺陷系统是大多数的工程师常用的工具,所以很多时候两者被混用就不足为怪了。然后除了开发工程师和测试工程师之外,缺陷报告还有其他的广泛用途,所以和缺陷不直接相关的信息不应该被写入报告。 2.缺陷渐变 缺陷渐变是说在同一个缺陷的报告中,缺陷从一个问题演变成另外一个不相关的问题。这种现象有时候发生很快,有时候过几天或者几个月。不管怎么样,都要极力避免缺陷渐变。对于已经变形的缺陷,通常很难分析其中根本原因,产品支持工程师在搜索相关问题时候还会发生混淆。如果一个缺陷报告开始演变,要及时停止,并就新问题重新报告一个新的缺陷。 3.对个缺陷 如果测试人员很忙碌,他们可能会相关的缺陷记录放在一个缺陷报告中。尽管我们尽力避免这类问题,在一个缺陷报告中报告几个问题从来就不是好主意。这会带来一系列的问题,比如: (1)缺陷的优先级别不能单独设置 (2)缺陷的决定不能单独设置,比如立即修复还是推迟到下一版本 (3)虽然缺陷在类似领域,但是可能需要分配给不同的开发工程师 (4)在分析产品缺陷的根本原因时候,同一缺陷报告中的每个缺陷可能有不同的错误根源。 关于缺陷报告的时候 这似乎是管理层最喜欢干的事情,这些报告发掘和代表了各种各样的数据。比如下面的一些度量: (1)修复的缺陷/所有解决了的缺陷:可以衡量缺陷修正和其他决断的比例 (2)缺陷发现率 (3)缺陷修正率:当缺陷会审标准提高时候,修正的百分比下降 (4)每个组件的缺陷数:根据功能排序可以影响哪些领域需要更多的测试 … Continue reading

Posted in 软件测试 | Tagged | Leave a comment

Tester Center聚合中心

testingjob download nightmare on elm street part 2 freddy s revenge a divx 域名一直没有充分利用起来,晚上用了一点空闲时间,借助Lilina做了一个聚合,聚合所有测试圈子里面朋友的blog和网站,Lilina是一款优秀的开源工具,类似的还有planet等。 Lilina is a free, open source aggregator for your server. This allows you to install it once and run it everywhere. 这个聚合可以省去不少朋友记忆域名的麻烦,可以集中展示测试圈子内的朋友的文章,可以说是一站式的博客平台,省的大家东奔西跑。如果你有blog也是有关于测试方面内容,也欢迎跟我申请,留言或者mail均可申请。 聚合地址,另外Logo和页面也在进一步完善中,也欢迎大家提出宝贵意见。 另外一个聚合地址在这里,是基于Planet 的,感觉风格好些。

Posted in 软件测试 | Tagged , | 3 Comments

测试设计技术Q-Patterns介绍

这是一个非常新的测试需求分析和测试用例设计技术,特别适用于测试需求不明确、文档不全的情况,而且把测试用例的重用性发挥到了极致,如果设计得当,基本可以做到design once, apply all的地步。不仅仅可以适应于跨项目,跨产品,甚至跨行业,跨公司都可以重用测试用例。 Q-Pattern中的Q是Question的意思,这是一个由一系列的问题组成的一个问题集的设计方法,针对不同颗粒的需求,小到一个下拉框,大到C/S级别的应用,都可以由一个包含许多问题集组成,针对不同的被测对象,回答这些问题就可以生成一系列的完成对产品覆盖的测试用例集。 下面是Q-Patterns的原文介绍 Patterns have proved to be a great tool for communication of domain specific knowledge across people and continuous skill enhancement. Designs, specifications, Architecture, Analysis patterns etc. are being widely used for this. ‘Questioning Patterns’ … Continue reading

Posted in 软件测试 | Tagged | 3 Comments

推荐两本好书

最近两次去图书馆,也不是一无所得,还是发现了两本有关Solaris的好书的,给朋友们推荐一下,对Solaris有兴趣的朋友或者用的着的朋友可以考虑买一个本。 第一本就是:Solaris内核结构(第二版) 英文原版的,据说中文版也已经出来了,不过不那么难,不用中文版一般也看得懂的。书中从soalris的进程结构,进程间通信,进度调度,内存文件系统管理等都做了深入的剖析。作者Richard McDougall 是Sun公司杰出工程师,专门从事OS技术和系统性能的研究,另外一个作者是Jim Mauro ,Sun公司高级工程师,从事性能、体系结构和应用工程小组方面的研究。 第二本就是Solaris内核结构的姊妹篇,Solaris性能与工具(第二版) 下面是这本书的简介: 本书全面介绍了Solaris 10和OpenSolaris中的强大工具,包括Solaris动态跟踪工具、DTrace和MDB(模块调试器)。书中提供了理解性能和行为的系统方法,包括: ● 分析内核和应用程序的CPU利用率,包括读取和理解硬件计数器。 ● 进程级资源使用和概要描述。 ● 磁盘IO行为和分析。 ● 系统和应用程序级的内存使用。 ● 网络性能。 ● 内核监视和概要描述,以及收集内核统计数据。 ● 使用DTrace提供者和聚集。 ● MDB命令和完整的MDB指南。 对任何水平的Solaris 10和OpenSolaris用户来说,本书和《Solaris内核结构》都极具参考价值。

Posted in 主机 | Tagged | 1 Comment

读书笔记-软件质量保证合同评审

如何区别两个合同评审阶段: 建议草案评审。这个阶段评审最终建议草案及其基础:顾客的需求文档,顾客对需求的详细解释,费用与资源评估,同合伙商和分包商已有的合同等。 合同草案评审。这个阶段在后续谈判其达成的理解和建议的基础上评审合同草案。 每个合同评审阶段的目标:

Posted in 软件测试 | Tagged | 2 Comments

读书笔记-软件质量保证部件概述

McCall的因素模型将所有软件需求按照11个软件质量因素分类。这11个因素被分为如下三个类别–产品运行,产品校正和产品转移: 1。产品运行因素:正确性,可靠性,效率,完整性,实用性。 2。产品校正因素:可维护性,灵活性,可测试性。 3。产品转移因素:可移植性,可重用性,互操作性。 20世纪80年代出现了两个因素模型,被认为是McCall经典因素模型的替代物,他们是: * Evans和Marciniak因素模型 * Deutsch 和 Willis因素模型 这些替代物建议给McCall模型增加5个因素。其中两个非常类似于McCall模型的两个因素,其余三个因素是新的:

Posted in 软件测试 | Tagged | Leave a comment

读书笔记-什么是软件质量保证

软件质量保证,首先必须有概念的定义,什么是软件?什么是软件质量?什么是软件质量保证? 软件—IEEE定义: 软件是计算机程序,规程以及可能的相关文档和运行计算机系统需要的数据. 也就是说,包含计算机程序,规程,文档和软件系统运行所必需的数据四个部分. 软件错误,软件故障和软件失效的关系: 软件错误是指由于程序分析员,程序员或者软件开发组其他成员造成的语法,逻辑或者其他错误,部分或者全部不正确的代码段 软件故障是再特定应用期间导致软件不正确功能的软件错误 只有再软件故障激活被激活的时候,即用户试图使用故障的特定软件段时,他才变成软件失效 软件开发过程中产生的错误中只有部分会变成软件故障,而再这些故障中又只有部分转变成软件失效 软件错误的9种产生原因 需求的不完善定义 客户–开发者通信失效 对软件需求的故意偏离 逻辑错误设计 编码错误 不符合文档编制于编码规定 测试过程的不足 规程错误 文档编制错误 软件质量–IEEE定义 软件质量是 1. 系统,部件或者过程满足规定需求的程度. 2.系统,部件或者过程满足顾客或者用户需要或期望的程度 另外的关于软件质量的定义: 符合明确陈述的功能和性能需求,明确文档化了的开发标准和所有专业开发软件预期的隐含特征(有点拗口,呵呵) 软件质量保证–IEEE定义: 软件质量保证是: 1. 一种有计划的,系统化的行动模式,他是为项目或者产品符合已有技术需求提供充分信任所必需的. 2. 设计用来评价开发或者制造产品的过程的一组活动.与质量控制有区别. 然而,这和实际的软件质量保证有些偏离,首先: SQA不应局限与开发过程 SQA行动不应局限与功能需求的技术方面,而应该包含同进度和预算有关的活动. 基于这个考虑,有一个SQA的扩展定义: 软件质量保证是:一个有系统的,有计划的行动集合,他是为提供软件产品的软件开发过程与维护过程符合其已建立的技术需求以及跟上计划安排与在预算限制之内进行的管理上的需求的充分信任所必需的.

Posted in 软件测试 | Tagged | Leave a comment

测试自动化和质量保证

有关于测试自动化和软件质量保证,性能测试以及测试工具,还有其他一些文章,请参考我在http://rickyzhuengineer.blogspot.com的老博客,这里仅仅转载几篇原创的文章,以后的新文章会陆续在这边发表. 欢迎提出您的宝贵意见,大家一起探讨学习,共同进步.

Posted in 测试自动化 | Tagged | Leave a comment