《软件测试质量体系》培训总结与思考
此次培训，不同于理论知识的讲解，更多的是微软测试思想、方法与技巧的传达。通过培训，了解了微软的测试思想及过程，很多思想、方法值得我们学习。
1         对软件测试的理解
1)       测试的目的
Ø 不仅是为了将测试做好，更是为了将项目做好
Ø 测试不仅仅是发现bug,测试的最高境界是建立起一套软件测试质量体系，使得项目按照既定的方向（进度）和标准（如质量）前进
Ø 开发过程中的质量，不仅仅最终代码存在质量，开发的工作方式、过程中的方法、产物同样是质量
思考：微软是没有QA的，微软人人都是QA，质量意识是微软人最基本的素质，由测试人员制定项目轨道，并在过程中执行推进。重要的一点：该踩刹车时要及时刹车
我们目前有专业的QA团队，负责项目过程中的质量管控，QC负责工程产物的质量，由两个角来达成该目标，按国内软件企业的现状，由两个角，专业化分工，开展起来确实更为有效。
2)       测试的原则：尽早的、不间断的进行测试
Ø 尽早的测试
ü 测试人员在需求阶段就介入，在项目前期预防和纠正需求及设计问题，做好缺陷的预防
ü 开发阶段：尽快的、尽可能的、极早的告诉开发代码是有效的
思考：
a)      目前我们已经做到了测试人员在需求阶段就参与，参与需求、设计文档的评审，但参与的效果还有待提升。
程序测试员需要学什么
b)     “不明确的需求是项目效率的第一杀手”，测试设计人员应更多的从上游发力，加深自己对业务、对客户实际需求的理解，从实际应用、用例设计的角度参与业务需求、设计文档的
评审，预防缺陷的发生。
c)      以前我们经常到项目后期了又发现重大BUG，这时给项目带来的极大风险，往往就是项目延期，再严重点的导致质量不可控，如何“尽快、极早的告诉开发代码是有效的”这是我们应该追求的目标，测试的依据是测试用例，还是应从测试用例设计上下功夫。
Ø 不间断的测试：微软采用“每日构建、自动化测试”的方式
ü 微软建立了一套自动化测试平台（据讲师介绍微软全部是自己开发的测试工具，花了5年多时间，各类工具有40多种，再由总控平台统一控制）
ü 采用自动化测试后，任何时候都执行所有用例（微软亚洲工程院的项目每天对3万多条测试用例重复开展自动测试，产生300万条测试结果）
思考：
a)      我们目前全是手工测试，不可能做到任何时候执行所有用例。项目过程中分为多个测试工序，不同测试工序选取不同级别的测试用例执行，手工执行重复测试容易疲劳，带来的
风险是修复BUG引起的新BUG可能被遗漏，或对未修改功能产生的影响被忽视。对影响点的识别与评估是我们需要加强的。
b)     微软的“任何时候执行所有用例”是一种理想状态，虽然自动化测试是行业的发展趋势，但我们不可能做到100%覆盖，可挑选出基本用例开发自动化，做到每日构建的基本用例验证，避免最基本、最不可接受的程序BUG。
2         测试计划与用例设计
1)       制定计划的原则
Ø 将项目切分为多个里程碑，分别进行管理。
ü 确保当前盖的这层楼是想清楚、明确后再去盖的
ü 确保已完成的是绝对可靠的
Ø 提前定好项目标准
ü 在每个里程碑节点完成后进行回顾
ü 最终标准达成后即发布
ü 微软的发布评估标准（Release Criteria）：
○         95%的测试用例通过率，且持续时间>5天。
（不是累计达到95%，而是5天每天达到95%）
○         允许有5%的case不通过，但级别不能是重要的case..
○         代码覆盖率>85%（指测试用例执行的代码覆盖率）
○         ZBB零bug边界，保持5天
（微软在ZBB后，会安排全员大扫除，连续5天时间未发现BUG，才可发布）
Ø 关注模块间的依赖
ü 确保每个模块及所有边界都有人测试，避免重复和无人测的情况
ü 边界出存在小范围重复测试是允许的
2)       制定测试计划中，发现人员不充分，经验不足怎么办？
Ø 从工程的角度考虑问题，不仅仅是要求测试人员之间分享经验，还需要有效的标准
ü 将有经验成员的能力转化为形式：将有能力者的思维方式形成模板
ü 一个好的模板，是节约人力成本的好办法。还能弱化对每个人的依赖度。
ü 重视过程文档：写文档，重在思考的过程。强调起清楚，再干活
ü 新老员工之间产物的区别，应转化为中间评审打回返回次数的区别，最终文档的质量应该是完全一致的
ü 文档质量的高低：50%取决于作者，50%取决于对该文档抓质量的程度
Ø 检查需求细不细
ü 避免主观语句（性能高，响应速度快等这样的形容词），速度响应快，快到多少秒。
ü 一定要量化需求，而不是主观感受。
Ø 凡事以数据说话，这样才能有说服力。
思考：
目前我们的流程、体系，与上面的大部分原则不谋而合，有些点我们现在是做了，但还做的不到位，应彻底落实。
a)      微软的发布标准是非常清晰，且完全是用数据说话，从中可以看出微软对质量的重视程度。我们目前的发布标准虽然也会依据质量目标的达成，但标准较为模糊，更多的还是测试团队的感知，测试人员测到最后阶段，也都很疲劳希望能够尽快发布了。这也是导致我们产品发布后立即频繁发补丁的原因之一。
如何清晰定义发布标准，使用有效的数据说话，是我们需要改进点之一。
b)     一直没太搞清楚“代码覆盖率”用什么方法来测算，现在我们只能测算到对功能点的覆盖率（颗粒度太粗），如果能够测算对代码的覆盖率会更准确，有助于用例设计覆盖率、测试质量的有效提升。
老师介绍一种方法是在代码中所有分支处设置数字标识，测试执行时验证该分支就会弹出标识，最终检查是否所有分支标识均进行了验证。这对开发人员要求较高，有一次与金碟的同行交流，他也提到他们会在代码里埋探针，来检测执行的代码覆盖率。不太清楚这样做会给开发带来多少工作，在我们团队中是否可行？
c)      我们对模块间的关系影响也有考虑，但对影响的识别、评估能力欠缺，对系统间的边界识别容易遗漏，计划中没有明示对边界的处理。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。