《测试之美》--读书笔记

《测试之美》--读书笔记

《测试之美》----Beautiful  Testing    业界测试专家揭示如何改进软件

“来自这些测试技术领袖的每一条真知灼见、每一则实用建议或者每一个优雅甚至富有挑战性的想法，被展现得如此清晰而富有
激情。这本包罗万象、动人心魄并且富有生趣的收藏集，应该摆放在每一位专业测试人员的书架上。”

测试之美的三重境界（激越期、磨炼期、顿悟期）。

“测试之美”的融会贯通：
    思维流程之美；
    探索发现之美；
    结构和谐之美；
    卓越功能之美；
    团队合作之美；


第一部分  测试者之美
测试是人类与生俱来的活动，即使测试不能思考、无法感受或令人沮丧，也需要有人考虑如何让测试用例变得自动化。
《测试之美》以人类方面的测试为开始，而不管是测试者自己或测试者与广阔世界的相互作用。

  第1章 这对你有好处吗
                -------------->以独特视角揭示测试者的心理。

        测试人员接受专门培训来发现并报告问题，他们通过发现和报告软件中的异常问题和存在的风险，进而帮助公司、开发团队、
客户和最终用户。

        测试的角色更像是顾问。实际上，让一个公司把测试人员放在“质量把关人”的位置，操作起来蛮困难的，也不太公平。所谓“质量
把关人”，就是在软件发布前已将该软件看做是一件商品的负责人。大多数测试人员不能很好地权衡风险、必要性、市场需求和成本
开销。评估和承担风险其实是项目管理者或公司管理层的任务。

        在态度方面，难道不应该团队协作吗？千真万确，你的测试人员也愿意扮演好团队成员角色，他们是想帮忙作贡献的，他们很
希望自己得到欣赏，但是他们关注的东西让项目组其他成员难以接受和欣赏他们的贡献。他们的幽默甚至增加了让他们融入团队的
难度。 更糟的是，如果你在一个不关注质量的公司工作，并不认同或不解决测试人员辛苦发现的问题，测试团队会认为这是对他们
以及他们的工作缺乏尊重。如果你不给予测试人员他们应得的尊重，很快就会让他们士气低落，然后你就很难留住具有本土市场上
热门技能的人才。

        你会发现如果对测试人员报以对开发人员、数据库管理员等人同样的尊重，就会促进建立一个能吸引和留住顶尖人才的测试
团队。


  第2章 完美的测试让利益相关者满意
                -------------->Rex Black有25年使软件利益相关方满意的经历，他解释了“测试之美”的魅力所在。

        测试中到底有什么，做好了能让利益相关者长期满意？哪些人是利益相关者，他们想从测试中获得什么？什么是让人满意的
外在的和内在的测试之美？
        测试人员和测试经理如何建立长期提供较高满意度的测试团队呢？作为测试人员，我们如何在工作中为自己和利益相关者创造
出优雅、有效、高效，甚至是乐趣呢？（这就是这一章要讲的内容）

外在美（为利益相关者的目标期望建立指标和目标）：

一、我们找到了多大比例的缺陷？
衡量指标：
        缺陷发现百分比（defect detection percentage,DDP）
        公式1：缺陷发现百分比（DDP） = 发现的缺陷 / 目前具有的缺陷
                （若你的测试是用户验收测试和部署前的质量保证的最后一环）

        公式2：用户验收测试和部署前的最后测试的缺陷发现百分比（DDP） = 测试的缺陷 / 测试的缺陷+产品的缺陷

二、我们发现了较高比例的严重缺陷吗？
        公式3：发现缺陷的侧重点：DDP（所有缺陷）< DDP（严重缺陷）
        -----实践基于风险的测试。

三、与在正式产品中出故障的成本相比，在测试中发现和解决一个缺陷的成本是多少呢？
        公式4：测试中发现的缺陷的平均成本（Average cost of a test bug,ACTB）
        ACTB = 发现成本+内部故障成本 / 测试的缺陷

        公式5：正式产品中发现的缺陷的平均成本（Average cost of a production bug,ACPB）
        ACPB = 外部故障成本 / 产品的缺陷

        公式6：计算测试的投资回报率（Test ROI）
        测试ROI = (ACPB - ACTB) * 测试的缺陷 / 发现成本

内在美(为测试的目标期望建立指标和目标)：

一、我们已经自动化了多大比例的回归测试？
        公式7：回归测试自动化的百分比（ Regression test automation percentage,RTA）
        RTA = 自动化回归测试 / 手动回归测试 + 自动化回归测试
        （测试自动化应保持或降低回归风险。所以，你应该衡量已经覆盖的有关回归的质量风险的比例。）

二、我们覆盖了多大比例有关回归的质量风险？
        公式8：回归风险覆盖率（Regression risk coverage,RRC）
        RRC = 已覆盖的回归风险 / 识别出的回归风险
        （识别出的回归风险应该是指需要做回归的用例或测试点）

三、我们还能加快多少自动化回归测试？
        公式9：回归测试加速比（Acceleration of regression testing,ART）
        ART = 手工回归测试时间 + 自动化回归测试时间 / 手工回归测试时间
        （自动化回归测试也应该让回归测试执行得更快。应该衡量回归测试执行的加速比）


  第3章 创建开源的QA社区
                -------------->社区支持决定了开源项目的生死。（作者分享建设一个漂亮的测试者社区的经验）


  第4章 协作是性能测试之美的基石
                -------------->作者解释了为什么漂亮的性能测试需要高于一切的协调能力。

        性能测试通常是软件开发项目中最无奈、最复杂、最缺人手、时间最紧迫、最易被误解、最好斗以及最吃力不讨好的方面，
但它并不必要如此。

系统性能测试要求：
*性能测试将在多种负载和使用模型下进行，具体负载和使用模型将在系统功能和工作流程建立时确定。
*对于任何内部版本，凡是出现性能测量结果超出以下数据的，必须报告开发组长：

在任意数量的用户条件下，有超过5%的情况加载网页的时间超过5秒；
在任意数量的用户条件下，有超过1%的情况加载网页的时间超过8秒；
超过2%的情况，课程无法完整或正确下载；
在任意数量的用户条件下，有超过5%的情况课程下载所需的时间超过60秒；
在当前最高负荷情况下运转时，系统可以持续1个小时保证95%的网页在5秒或更短时间内加载完毕，9%的课程在60秒或更短的时间
内完全正确下载。

*外部版本将附有性能测试报告，包括：
在任意数量的用户条件下，有超过5%的情况加载时间超过5秒的那些网页；
在任意数量的用户条件下，有超过1%的情况加载时间超过8秒的那些网页；
超过2%的情况无法完全或正确下载的课程；
在任意数量的用户条件下，有超过5%的情况下载所需时间超过60秒的那些课程；
在当前最高负荷情况下运转时，系统可以持续1个小时保证95%的网页在5秒或更短时间内加载完毕，95%的课程在60秒或更短的
时间内完全正确下载；

*项目经理可根据客户、开发团队、性能测试