联系我:新浪微博@阳光下的云朵2012或者zhangcaiyun_86#163.com(将#换成@)

记植树节资深人士组间培训(二)

上一篇 / 下一篇  2012-03-20 16:37:56 / 个人分类:测试技术

    实在不好意思,呵呵植树节的日志都放到现在了,还没有写完呢~~呵呵,看来
 
本人的打字速度还是要提高喽,今天一定完成!!!
 
    4.2缺陷的识别与处置(续1)
  
  
缺陷的处置的大原则:
测试预期结果应该是与需求一致的,这是与开发组出现意见分歧时的首要判断依据;
未在需求中明确的,如必要,可回溯需求定义并在项目组讨论;同意变更的要经过变更控制流程才能进入测试;
改进意见也是以已确立的需求为基础的,不要任意扩展;
如果对于优先级和严重等级的定义有分歧,需要测试负责人和开发负责人依据项目进度和时间、成本目标进行讨论;
项目组应该是缺陷争执的最高裁判单位;测试是在项目内成本核算的,项目经理最终管理着测试并对产品质量负责,而不是测试组;
不易复现的缺陷/问题的处置原则:
权衡进度和任务状况,不要穷追不舍;
如果能明确复现条件,可进行几率考察——是否达到30%50%的复现率;
如果问题出现在新的缺陷修复和代码升级后,考察上一版本是否也可以复现同样的问题;
对开发人员而言,精确的复现步骤的描述至关重要;
如果对复现步骤毫无头绪,则根据任务进度状况做备忘和上报,不再深究;

N要在测试前就明确优先级和缺陷严重等级的定义,开发组对此的了解尤其重要;
N如果没有缺陷跟踪工具,要在测试开始前为所有项目人员定义缺陷处理流程;测试计划必须为此做出定义并估算成本和时间;
N如果使用了缺陷跟踪工具,要在开始前对所有项目人员进行工具使用的培训;开发组同样要十分明确缺陷跟踪工具的处理流程;测试计划要考虑这个部分的估算;
4.3缺陷的识别与处置(续2)
 
交付前的质量评价与缺陷的处置原则:
Regression结束或产品稳定测试结果后发现系统缺陷,要慎重处置;不要推进无条件修复,这样可能引入更多的缺陷;
评价需求实现的能力是重要的尺度;
与开发组、项目经理、产品经理、QA共同评审未修复的已知缺陷/问题;如有必要,要求客户团队参加;
如果对提交前确定不修复的已知缺陷/问题难题必须如实记录到发布手册中,并为最终用户提供绕行方案;
如果对复现步再度重申--项目经理是项目质量的最终负责人,不是测试组;QA负责评价项目的执行质量;在交付过程中测试组提供客观的质量评估是职责的根本所在,没有理由采取异常坚定和对立的立场。
5.1 项目周期中的测试过程和任务
 
 

测试的投入和参与的原则:

测试加入项目的时机是项目管理者思考的问题。视组织的资源状况、成本控制的要求、测试人员的技术能力和可参与价值等等而定,没有统一标准。有时甚至依赖于项目管理人的组织经验乃至习惯;
Move to the left”的原则下,鼓励测试组早期介入项目;
早期参与的测试人员应当对质量目标的量化起到关键作用;这些目标可能在需求定义和评审的过程中出现;
参与风险评估也是测试的早期参与价值之一;
开始执行测试之前,测试组应该全面启动;
测试计划的制定的和测试的推进和管理,建议按照独立的项目管理模式来运行;
6.1 测试的工具化和自动化
 
测试管理的工具化
Microsoft Visual Studio Team Foundation Server
自定义的测试管理工具
用例与质量评价结果关联的统计;
功能/用例的横向矩阵;
测试进度控制甘特图/Burn-down chart
自定义的质量评估统计工具
代码行与缺陷率的统计;
通过率面积图;
Regression统计;
按功能区域、按重要等级、按修复进度、质量指标等确立的矩阵;
变更控制与缺陷率相关性分析图;
6.2 测试的工具化和自动化(续)
 
 
测试自动化功能测试
Microsoft Visual Studio Team Foundation Server
UI测试
类似Windows Test Technologies的框架下,基于web自动化测试管理平台;
MercuryUI测试工具
Mercury的自动脚本记录器;
测试自动化压力、海量数据处理、疲劳测试
MercuryLoadRunner
 
   7.1 谁想成为测试人员
 
 
软件测试作为一个职业,或许你需要说“I do
你真得了解测试工程师的职责和使命吗?
你了解国内测试行业的现状吗?
你真得对测试感兴趣并愿意与它“终身为伴”吗?

TAG:

 

评分:0

我来说两句

Open Toolbar