联系我:新浪微博@阳光下的云朵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测试
▫Mercury的UI测试工具…
▫Mercury的自动脚本记录器;
•测试自动化–压力、海量数据处理、疲劳测试
7.1 谁想成为测试人员
•将软件测试作为一个职业,或许你需要说“I do”… ▫你真得了解测试工程师的职责和使命吗?
▫你了解国内测试行业的现状吗?
▫你真得对测试感兴趣并愿意与它“终身为伴”吗?
收藏
举报
TAG: