-
案例一：测试主管新到一个环境你如何开展工作？
Spark.lee 发布于 2007-05-30 10:56:36
案例内容：
公司有一个不到10人成立不到半年的测试部，我成为该公司的新聘测试主管，公司要求我尽快建立适合的流程，我该如何开展工作？
是先了解几天情况，然后找每个测试人员谈话了解工作情况每个人的想法？还是一直按兵不动仔细观察个十天半月？
分析一：
作者：herlga
分析内容：
1、新了解情况是必须的，建立与测试人员之间的信任关系。
2、总结目前状况，整理成报告，指出问题。
3、确定目标，提出改进方案。 分析二：
作者：味书生
分析内容：
这个问题不错，以下是我的一些想法：
1.首先，要深刻体会上层对测试的定位（这个工作可以在面试时探讨，但如果探讨的不够深刻，一定在启动工作时，认真领会）
2.了解企业文化非常重要，因为他是你推行流程和管理的基础
3.了解当前公司的测试状态
--找一些问题与CTO，质量控制部门，项目部门，工程部门，开发部门等等部门进行外部交流
--与测试部门人员交流
4.了解测试部门人员水平
5.引进管理工具，和标准规范
6.论证流程，制定一个与公司现有状况适度的流程
7.选择一个重视质量的项目进行开练问题一，该案中，公司已经建立了测试部，并且半年之久，诚然存在很大的问题，否则不会空降一位测试主管。
问题二，公司要求尽快建立适合的流程。做过测试管理的同行都知道，这个问题难就难在适合二字，测试流程容易，拿本软件工程的书，或者网上搜一下，也能找出个把的流程。而尽快二字确是一道金箍。
问题三，作者尚不熟悉该公司的环境，古语道：“入乡即需随俗”。
古有训：“一朝天子，一朝臣”，我想作者也是受这种“封建残余” 的影响而却步吧。不过我们是从事着新新行业，新新领域的一代新人了，机会和挑战是并存的。不要却步，虽然team建设是件不容易的事情，公司既然在“众里 寻他”的过程中选中了你，便是对你的能力肯定和支持。
首先第一点，分析一中也提到了解情况是必须的，“实事求是”嘛。这个了解情况，作者自己 也提到了，只是这个方法上静观其变好像在上任之初是不太合适的，跟每个人谈话的方式，笔者认为，太难控制，让测试人员自揭缺点是不太容易的，同时容易让别 人排斥你。距离不全都是美的，要把握适度。沟通的距离合适了，合作的距离才能近。
一个新的团队，要了解的情况包括：
测试人员的基本情况，如果公司有受聘人员的简历或者更详细的档案最好，如果没有，只好自己设计一份测试题或者技能调查表。直截了当的反馈。
测试组的工作进展情况，如果有幸跟前一位主管进行工作交接或者公司对工作文档都进行了配置管理，那就方便很多了，如果没有，只好自己向相关人员索要了。 有四个文档是必须要看的：软件需求规格说明书、测试计划书、缺陷报告、测试分析报告。软件需求规格说明书的内容质量是体现开发团队过程管理水平重要因素， 所谓好的开始，是成功的一半。在软件开发过程中，一份好的软件需求规格说明书，是项目成功的一半，它的质量对软件来讲有事半功倍的效果；测试计划书是测试 team工作的灵魂，从一份测试计划书中可以解读team的管理水平以及撰写者的技术水平；缺陷报告是缺陷提交者和相关代码开发者的技术水平的整体体现， 这份报告，不单是新到一个团队要看，而是时时刻刻要看，每个项目要看。做测试之前要看，做完测试之后也要看。测试分析报告，做事情要有头有尾，这份文档可 以体现总结者的诚实和负责任的程度，同时可以从中感受，感受企业文化。
第二点,不要批评，无论了解的过程中发现了什么样的问题，不要批评。批评是疏远和不负责任的表现。给出解决方案先。解决方案要跟测试组，或者开发过程中所有相关的人员进行讨论，他们会在认同你的解决方案的同时，认同你这个人。
第三点针对企业尽快制定适合的测试流程，拟订标准测试流程和各个工作节点裁减说明。这不是明哲保身，不要草率，这将是你工作的起点和改进的基础或者是目标。（拟的流程过于简单就是基础，很完善就是目标---关键在于你的水平）
相信说到这里你已经容入团队开始工作了。余下的就看你的水平啦！：） -
究竟什么是软件测试？
Kerryzhu 发布于 2007-03-13 19:20:14
-
关于缺陷的优先级和严重级别
songfun 发布于 2007-03-11 02:49:08
今天看到论坛里一个学员在问“到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？”，还有学员对优先级这个字段理解的不够透彻，原话是“优先级的填写要看情况的。因为有时Tester 开的bug 很多，而PM又有好多TESTER，那PM就来不及去一一看那些BUG了，这时Priority就得由tester填写”，而论坛里还有同学找了篇英文的文章来告诉大家“看，老外都是这么做的”。
我觉得有必要给大家解释透这两个概念，这样不至于在日后的工作中做错。
以下粉红色部分是对那篇英文的引用，后面则是我的回答（结合微软的实际例子给大家说明）。
QUOTE:原帖由 rivermen 于 2007-3-9 09:12 发表
c) The tester then selects the priority of the defect:
Critical - fatal error
High - require immediate attention
Medium - needs to be resolved as soon as possible but not a showstopper
Low - cosmetic error
从这篇文章来看，这段英文描述是有问题的——不能说不对，至少不合理。
优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过项目管理的工作或者学习过项目管理的知识。
为什么这么说呢？
因为Tester只是项目团队的成员之一，对缺陷管理、项目进度和项目风险都不可避免的会“盲人摸象”、“管中窥豹”，只“看”到自己“看”到的那个部分。
一般来说，一个被测系统往往需要多个tester的，而每个tester往往只关注自己发现的bug，不大会去了解其他tester所发现的bug，那么在这种情况下，他如何能够决定这个bug被修复的优先级别呢？！
这里再次强调一次，大家必须了解“Priority”真正的含义和作用——它是给管理者来据此做项目决策的，也就是说，缺陷优先级将直接导致工作安排的优先顺序。PM正是通过参考缺陷优先级来安排开发人员的工作顺序（这甚至能在Project里体现），使得项目风险降低、项目成本降低，解决问题更高效。
其实，这在微软内部就叫做“基于风险的测试”，也就是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。
以下是微软公司的缺陷流程（不知道现在做微软外包的公司是否也采用这套流程），给大家参考参考。
Bug跟踪过程
在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段：
1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。
2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。
3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。
4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。
话说回来，网上有很多自称专家的人在那里大谈特谈所谓的优先级标准，什么“系统死机是高级别，界面错误是低级别”之类。其实这些指的是缺陷的严重级别（Serverity）！
当然，一般来说缺陷的严重级别也不是tester“主观判断”决定的，如果公司比较规范的话，会由测试经理、项目经理等组织制订这么一份相关的标准文档，文档是关于对应缺陷严重级别的定义。Tester在测试的时候就根据这么一份文档来决定对应Bug的严重级别。
我下面粘贴某公司的一个《缺陷等级标准》的文档，大家可以看到其中的“E类——测试建议”正是我上课所说的Enhancement。
========================
缺陷严重级别定义:
o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.
o 紧急---事件非常重要,并且需要马上给予关注.
o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.
o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.
o 低级---事件不重要,可以在时间和资源允许的情况下再解决.
o 建议性缺陷.
更为详细的划分如下:
A类——严重错误，包括：
o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
B类——较严重错误，包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，包括：
o 界面错误(详细文档)
o 打印内容、格式错误
o 简单的输入限制未放在前台进行控制
o 删除操作未给出提示
D类——较小错误，包括：
o 辅助说明描述不清楚
o 显示格式不规范
o 长时间操作未给用户进度提示
o 提示窗口文字未采用行业术语
o 可输入区域和只读区域没有明显的区分标志
o 系统处理未优化
E类——测试建议（非缺陷）
===============================
好了，关于缺陷优先级和严重级别我解释到这儿，我希望同学们在学习的过程中知其然更要知其所以然。流程的制定不是想当然的，更不是因为看到别的公司都这么做自己就跟着做的。项目管理、缺陷管理都需要有很深的技术管理知识作为支撑，否则是作不好的。 -
2006年上半年软件评测师试题及答案(上)
jzhao 发布于 2007-01-24 09:27:30
-
性能测试的步骤
Spark.lee 发布于 2006-12-08 12:03:54
-
性能测试
Spark.lee 发布于 2006-12-08 12:08:30
-
常用的功能测试方法
Spark.lee 发布于 2006-12-08 11:49:57
-
设计功能和界面测试用例
Spark.lee 发布于 2006-12-07 17:26:08
设计功能和界面测试用例
1.1 文本框、按钮等控件测试
1.1.1 文本框的测试
如何对文本框进行测试
a,输入正常的字母或数字。
b,输入已存在的文件的名称；
c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
d,输入默认值，空白，空格；
e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
g,输入特殊字符集，例如，NUL及\n等；
h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示
在测试过程中所用到的测试方法：
1,输入非法数据；
2,输入默认值；
3,输入特殊字符集；
4,输入使缓冲区溢出的数据；
5,输入相同的文件名；
命令按钮控件的测试
测试方法：
a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；
单选按钮控件的测试
测试方法：
a,一组单选按钮不能同时选中，只能选中一个。
b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；
up－down控件文本框的测试
测试方法：
a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
c,直接输入超边界值，系统应该提示重新输入；
d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
e,输入字符。此时系统应提示输入有误。
组合列表框的测试
测试方法：
a,条目内容正确，其详细条目内容可以根据需求说明确定；
b,逐一执行列表框中每个条目的功能；
c,检查能否向组合列表框输入数据；
复选框的测试
测试方法：
a,多个复选框可以被同时选中；
b,多个复选框可以被部分选中；
c,多个复选框可以都不被选中；
d,逐一执行每个复选框的功能；
列表框控件的测试
测试方法：
a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
b,列表框的内容较多时要使用滚动条；
c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；
滚动条控件的测试
要注意一下几点：
a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
c,单击滚动条；
d,用滚轮控制滚动条；
e,滚动条的上下按钮。
各种控件在窗体中混和使用时的测试
a,控件间的相互作用；
b,tab键的顺序，一般是从上到下，从左到右；
c,热键的使用，逐一测试；
d,enter键和esc键的使用；
在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。
ps:密码输入框测试时要特别注意进行字母大写输入的测试。
查找替换操作
案例演示:打开word中的"替换"对话框
测试本功能有通过测试和失败测试两种情况
通过测试:
1,输入内容直接查找,或查找全部
2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.
失败测试:
1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;
替换测试大体相同.
关于编辑操作窗口的功能测试的用例:
1,关闭查找替换窗口.不执行任何操作,直接退出;
2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
4,热键, Tab键.回车键的使用.
插入操作
1,插入文件
测试的情况
a,插入文件;
b,插入图像;
c,在文档中插入文档本身;
d,移除插入的源文件;
e,更换插入的源文件的内容;
2,链接文件
测试方法:
a,插入链接文件;
b,在文档中链接文档本身;
c,移除插入的源文件;
d,更换插入的源文件的内容.
3,插入对象
要测试的内容
a,插入程序允许的对象,如,在word中插入excel工作表;
b,修改所插入对象的内容.插入的对象仍能正确显示;
c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.
编辑操作
编辑操作包括剪切,复制,粘贴操作.
测试剪切操作的方法
a,对文本,文本框,图文框进行剪切;
b,剪切图像
c,文本图像混合剪切
复制操作方法与剪切类似.
测试时,主要是对粘贴操作的测试,方法是:
a,粘贴剪切的文本,文本框及图文框;
b,粘贴所剪切的图像;
c,剪切后,在不同的程序中粘贴
d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
e,利用粘贴操作强制输入程序所不允许输入的数据.
界面测试用例的设计方法
1,窗体
测试窗体的方法:
a,窗体大小,大小要合适,控件布局合理;
b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;
2,控件
测试方法:
a,窗体或控件的字体和大小要一致;
b,注意全角,半角混合
c,无中英文混合.
菜单
进行测试时要注意
a,选择菜单是否可以正常工作,并与实际执行内容一致;
b,是否有错别字:
c,快捷键是否重复;
d,热键是否重复;
e,快捷键与热键操作是否有效
f,是否存在中英文混合
g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
h,鼠标右键快捷菜单
特殊属性
1,安装界面应有公司介绍或产品介绍,有公司的图标
2,主界面及大多数界面最好有公司图标
3,选择"帮助"->"关于"命令,应
看见相关版权和产品信息
标题搜索
我的存档
数据统计
- 访问量: 83364
- 日志数: 89
- 图片数: 1
- 文件数: 1
- 书签数: 2
- 建立时间: 2006-12-08
- 更新时间: 2009-07-17
