微软软件测试技巧

liangjz

2.1        两点间直线最近，QA建立轨道让开发在直线间滑行
2.2        测试最高境界：不需要测试
2.3        预防缺陷成本<发现BUG；预防缺陷成本<事后追究责任成本
2.4        测试驱动开发，让测试与开发同时结束
2.5        BUG 分类深刻原因：经验模式转向量化数据、统计分析的科学模式，便于定义优先级、资源分配，穿插管理思想。
2.6        执行用户体验 (UE ) 测试。UE设计能用一步完成绝不用2步。
2.7        测试不局限于你看到的内容，把测试扎得很深、透。测试对象不局限于软件，文档也是测试对象
2.8        对测试的软件施加酷刑
2.9        白盒测试是很高难度的，用工具而非肉眼阅读
2.10        Daily build与daily test结合才有意义，每个用例每日都运行，报告反映软件最新的全貌
2.11        没人对QA 产出进行审核？
2.12        如开发多次询问BUG重现步骤，说明内部质量管理是有问题的
2.13        严格执行测试计划，排除测试随意性。但鼓励测试工程师创造性
2.14        让测试数据说话，对用例和BUG统计了解项目发生了什么
2.15        测试理论从实践中提炼，异于推理性理论。
2.16        V模型包含妥协，其思想是在何时做某一个测试更合适。但每一个阶段都应该全部测试。应该打破V模型的局限
2.17        文档记录下思路，和他人一起评审；补文档效益不显著。文档没有写好，更多反映态度问题。用最简单、直接的方式表达思路给他人。
2.18        定格子明确测试范围，确认是否完备？有重复？接口测试按模块切分了么？
2.19        测试资源不足时，思考现有人员是否有潜力？是否有效利用资源了？是否有其他方式可以解决？招聘后资源空余如何处理
2.20        在时间和质量矛盾时，选择保证质量
2.21        5天内专业团队发现0个BUG，达到ZBB阶段(Zero Bug Bounce
2.22        Case 通过率：促使开发修复BUG;代码覆盖率：促使测试增加测试用例
2.23        区分工程师能力之一：功能验证点
2.24        衡量代码覆盖率的技巧：awk 在程序分支处加入printf（序号），运行检查遗漏的序号
2.25        内部产品必须平滑过渡
2.26        灰盒测试是一种妥协，一定要追求白盒测试；白盒测试本质用程序测试另外一种程序，编写白盒测试工具也是能力转换的方式。白盒测试工具与应用程序互验证。
2.27        购买工具思考清楚想解决什么问题，用一个工具来解决，否则工具多反而效率下降。工具需可定制化
2.28        自动化流程从创建开始，到环境恢复止。自动化测试主干流程容易重复，重视单元级的细致测试
2.29        用自动化思维思考问题，抽样也是一种妥协
2.30        定制控件，不要牺牲软件特性换取程序可测试性
2.31        B 测试不是让用户找BUG，而是让用户判断是否满足功能需求、UI需求
2.32        创造UE测试标准
2.33        自动化编码原则
用例间独立运行，不依赖其他
用例结束RESET
用例运行次数建执行无障碍

2.34        1个人+ 1群机器运行，高效
2.35        从入库开始，代码就接近可发布的ZBB
2.36        手工测试为主，研发与测试比例2：1  ，最高不超4：1；自主研发测试工具为主的team，研发与测试比例1:1
2.37        不单纯依据BUG数量衡量开发人员水平，否则带来无穷的争吵和问题
2.38        不要轻易放过一个有测试专长的人才
2.39        测试纪律不要定制太多太琐碎，应该保证充分严肃性
2.40        开发部门与测试部门配合是否流畅，和2部门经理风格相关，在于形成共识
2.41        规范无止境

junlingliu

阅读一部分，是很有概括性，但是不便于理解和学习。。。。不过一样谢谢

li_tea

好