联系我：新浪微博@阳光下的云朵2012或者zhangcaiyun_86#163.com(将#换成@)
记植树节资深人士组间培训（一）
上一篇 /
下一篇 2012-03-13 10:55:38
/ 个人分类：测试技术
2012年3月12日下午14：00测试资深人士对我组还有其他组进行了长达two hours的测试培训，这次期间我听到了很多新的测试领域的名词（印象最为深刻的呵呵~~），还有把自己从事测试以来的接触到的实际问题和他所说作对比，去粗取精，去伪留真，提高了自己的测试认知度和测试能力水平~~呵呵，与此同时他幽默风趣的谈话也给我（我相信大家也是）留下了深刻的印象......
下面是测试PPT的补充修订版，我不知道几天可以写完，呵呵，分享给大家，希望有所帮助，大家共同努力提高~~
1.测试究竟该何时、如何介入项目？
2.执行测试用例--如何使测试流程更高效？如何避免重复工作？ 3.如何识别不易发现的缺陷？
4.一个职业测试工程师应该具备的素质？
5.为什么测试人员总要承受最后的压力？
6.处于整个软件团队下的测试团队的“权利”和“权力”？
7.项目早期测试团队的操作流程和具体任务？
8.测试人员应该具备的基础知识？
9.有什么好的测试工具（好用又不普通的）？
10.”后台测试”都要做些什么？
11.缺陷无法复现怎么办？
12.被测对象存留缺陷但交付期已到，PM施压交付时我们怎么办？
第一章 那么我们的问题是什么？
粗略的归纳：
2.测试用例优先级的定义；以及如何利用质量评价结果（要不要借鉴产品周期测试的模式）
3.O 测试覆盖度评审和测试的计划与跟踪
4.O缺陷的识别与处置--错误、缺陷、问题
5.O测试团队在整个项目周期中的过程和任务
6.O测试的工具化和自动化（管理的和工程的）
7.谁想成为测试的一员
O--管理者需要参与和考虑的问题
1.1测试用例的编写
•依据-系统需求（用例）；测试覆盖的是系统需求，但不仅仅是系统需求；需求的定义直接影响到测试用例的结构化质量；
•功能测试用例的结构化展开-主业务、分支业务、边界、强错、消息库... •非功能测试用例的结构化-需求指标的验证、上下限测定、环境指标...
•其他需求指标（如果已经定义）-安全性、易用性、兼容性、交换机性、强固性、可维护性、稳定性、SLA约束条款（响应、服务等）
•在概述中指明当前用例的测试功能点非常重要
1.2测试用例的使用
•读懂测试工程师设计的测试用例
▫用例文档的必要组成部分—环境配置、必要条件、数据项、执行内容、预期结果、实际结果、评价；
▫从概述中识别测试的要点，从而确立执行步骤—被测产品的基本知识、GUI路径、终端用户的行为模拟；
▫工具–表格，商业自动化工具，脚本的运行；
▫Ad Hoc和Selfhosting的尝试如何摆脱测试用例的思路–在没有系统地执行过测试之前，不建议采用Ad Hoc和Selfhosting；
•测试用例的维护
▫输入主要来自test bug、test case follow up； ▫Ad hoc的发现可能会成为可执行的用例；
▫新增用例虽然定义了优先级，但可能需要在下一轮测试时执行一次验证；
▫测试用例的更新和补充不是“马后炮”，要重视它的重用价值；
第二章 测试的优先级
•（借鉴产品测试的分级策略）
▫不同文档-抽取不同级别的测试用例归类成文档（BVT/FVT;Basic/In-depth）
▫同文档-定义P0-Px；然后在不同的测试策略定义的优先级范围；
▫质量评价结果可以调整，优先级和执行密度提供参考--从不出错的用例可以降低关注度或减少测试密度；
N优先级的定义和调整必须要通过集体讨论决定
第三章 测试用例的评审和计划跟踪
•评审
▫覆盖度--需求跟踪矩阵；
▫完整性和经济性--检查单
•进度跟踪
▫完成度-在每个计划执行周期建立计划个数和完成个数的进度表；
▫通过率-执行总数与通过数量的对比；
▫相关性分析（是否是新代码、投入了多少人，测试密度和持续期）；
第四章 缺陷的识别与处置
4.1缺陷的识别与处置
•缺陷判断的依据：
▫需求，永远都是需求—测试是对需求的验证，而不是对被测对象本身的验证；
▫程序错误；
▫预先定义的质量指标（e.g.，易用性、安全性等）、业界指标或惯例（e.g.,友好性、耐受性）；
▫改进意见；
•在缺陷报告中体现测试的价值：
▫缺陷注入原因的分析；
▫历史缺陷和历史修复的把握和分析；
▫充足的可视化证据和详细的复现方法以及需要怀疑的环境因素；
▫客户报告要做缺陷报告标准化转换；
N至少应该在一个项目内定义一个统一的缺陷报告概述模板；
N至少应该再一个项目内定义一个统一的缺陷报告详述模板；
N要在测试前就明确优先级和缺陷严重等级的定义，比起测试组，开发组对此的了解更为重要；
收藏
举报
TAG:
