【软件测试】点评“现代软件测试原则”
七年前，我在写《完美测试：软件测试系列最佳实践》时，列了十几条测试原则，可以概括为十大测试原则：
测试目标要明确，并建立合理的阶段性目标
一切从客户/用户的角度出发，想客户所想
测试尽早介入，一旦项目启动，测试就要介入进去。
尽可能确保软件的可测试性
持续地测试、持续地反馈，最大程度地降低研发成本，提高研发效率
测试时不能穷尽的，应设定合理的测试目标或测试终止的条件
基于项目的上下文来制定相应的测试策略
基于风险的测试策略总是有效的
测试计划不仅是文档，更是一个过程，应根据测试状态不断变化而进行调整
80/20原则，发现错误越多的地方，越要投入更多的测试资源或进行更深入的测试
这些原则并没有考虑开发是传统的还是敏捷的，而是具有良好的普适性，能有效地指导测试的工作。
前天本公众号转发了Christina Geng和Lisa Crispin对话敏捷测试 文章，提到了Alan Page和Brent Jensen在其AB测试播客中提出的现代测试原则，
今天就来说说这七项现代测试原则。
所谓现代测试原则，是适应敏捷开发模式的（人们往往把敏捷开发看成是现代开发模式），而不适合传统开发模式的。从敏捷开发目标看，就是要做到快速交付、持续交付。作为测试，就是如何助开发一臂之力，实现高质量的持续交付。Alan Page和Brent Jensen（简称：AB）认为“在敏捷开发中，测试人员可以开始从质量所有者转变为可交付质量的大使，提供价值，并改善团队的质量文化”。这种提法值得商榷：
在传统开发中，测试人员也不应该是质量的所有者。质量一定是整个团队和公司管理者共同拥有，而且测试人员也不是质量的管理者，因为有质量管理人员或质量保证人员（QA），甚至不是质量改进的最主要的驱动者（团队的每一个都应该是质量的驱动者），因为还有工程过程组（SEPG）。虽然上线后漏掉缺陷，有些公司第一个责怪的人会是测试人员。即使在传统的公司中，这样做的公司也算是比较落后的公司，不能把落后的公司的实践算在传统测试的头上。如果要问责，也是要把开发人员和测试人员一块叫过来，看看问题究竟出在哪里。
大使，有全权代表的含义，也有形象代言人的含义，这里是指：敏捷测试人员作为质量的代言人还是作为全权代表？感觉都不对，这样是不是回到老路上去，而且把测试的责任搞含糊了。测试人员就是不断暴露软件产品的质量风险，不断发现问题，及时反馈给团队，帮助团队持续提升质量。
感觉AB的出发点就错了。那我们再看看这七项现代测试原则有什么新东西？是不是真正能成为敏捷测试的原则？
1.我们的首要任务是改善业务
AB认为：现代测试人员，热衷于提高效率，并希望加快发布流程，更快地为客户提供价值。强调为团队增添价值，应用于功能团队的良好测试思维是增值，而非成本，因为过去人们往往把测试看作是成本中心。这种价值可以通过数据来驱动，表示为客户所熟悉的一些指标。
点评：不仅是测试，开发也一样，都是为业务服务的，业务驱动开发、业务驱动测试，甚至我们说：不以业务敏捷的敏捷都是伪敏捷。从这一点看，这条原则没错。但是，这条原则适合传统的开发，而不局限于敏捷方法；也适合整个敏捷团队，而不局限于测试人员。其次，AB的解释，并没有真正触及到“业务为先的测试”、“业务驱动测试”的实质，即如何明确表达“业务驱动测试的准则”。
2.我们加速团队，并使用精益思维和约束理论等模型来帮助识别、排序和缓解系统的瓶颈。
AB认为：测试人员做较少的测试，更多是驱动质量的提升，指导开发人员设计小规模的测试（这来自Google公司对测试的划分：小规模、中等规模、大规模的测试，而不是我们通常说的单元测试、系统测试、验收测试），让开发人员做更多测试。测试人员负责那些大规模的测试。通过单项工作的结对体验（如结对编程、结对测试），团队可以在代码中找到更多缺陷，并更快地培育质量。
点评：这里更多是强调团队对测试负责，测试人员是测试教练，更多是做那种贯穿业务流程、端到端的测试，单元测试或单个功能测试应该让开发人员自己做。提升开发的测试能力，或整个团队做测试，是解决“测试作为敏捷研发一大瓶颈”这样的问题。但应用精益思想、约束理论来识别、排序、缓解系统的瓶颈，也是这个团队的工作，没有测试的特殊性。虽然我们承认，许多时候，测试是敏捷开发的最大瓶颈，这种提法也挺好的，让我们时时关注“测试是不是处在瓶颈状态”，不断寻找有效的策略，加速测试。
（不急，先了解两个知识点）
| 补充知识点：精益思想（正好也是7项原则）1)尊重一线人员。工作在一线的人最了解实际情况，能制定更好的应对措施，更有能力提出正确的改进意见；2)消除浪费。任何不能为客户增加价值的行为即是浪费，为了消除浪费，必须以价值流来识别浪费，并指出浪费的根源并消除它，识别和消除浪费的过程是持续不断的；3)增强学习。软件开发是持续学习的过程，从而能够面对各种挑战；4)尽量延迟决定。直到能够基于事实而非不确定的假定和预测来做出决定，因为系统越来越复杂，软件开发中存在更多的不确定性；5)构建质量。如果从研发的各个阶段（需求、设计、编程等）都能保证产出物的质量，我们就能以最低的成本达到产品的质量目标，即最大程度地减少浪费；6)快速交付。只有将产品交付给用户，才产生价值。交付越快，产生价值越早；7)整体优化。局部的优化，若不能带来整体的改善，将是没有价值的。 |
补充知识点： 约束理论 约束即阻碍企业有效扩大产出能力、降低库存和运行成本的环节，即任何一个多阶段生产系统，如果其中一个阶段的产出取决于前面一个或几个阶段的产出，那么产出率最低的阶段决定着整个系统的生产能力。约束理论是企业识别并消除在实现目标过程中存在的制约因素(即约束）的管理理念和原则，主要操作过程是： 1)找出系统中存在哪些约束（来自原料、能力、流程、市场等方面的约束）；2)最大限度利用瓶颈，即提高瓶颈利用率；3)使企业的所有其他活动服从第二步中提出的各种措施；4)打破瓶颈，即设法解决第一步中找出的瓶颈；5)重返第一步，持续改善。 |
3.测试人员是持续改进的力量，帮助团队适应和优化以获得成功，而不是提供安全网来捕捉失效。
AB认为：随着逐步将更多代码密集型测试任务转移给开发人员，并让测试人员指导和领导测试工作，团队项目的质量得到提高。测试人员不再被视为最后一道质量防线，而成为“设法留住客户、让客户使用应用程序”的第一道攻击线。
点评：让测试人员变被动为主动，帮助团队持续改进，从而不断提升构建的质量，这挺好。从本质上讲，这种任务是真正SQA人员或管理人员所承担的责任，只是许多公司SQA人员是缺失的，管理人员也不够关注质量，结果就让测试人员来承担了。但这种原则更应归为质量文化建设、质量管理的原则，而不能算测试原则。就像前面说的，AB把测试人员当作质量大使，所以让测试人员更关注质量文化建设的建设，从这个角度看，也没错。
4.非常关注团队的质量文化，我们指导、领导和培养团队，以建立更成熟的质量文化。
AB认为：创建代替孤立的测试人员的社区，这对于发展成熟的质量文化很重要。借助协作和创新，社区成员与其他成员建立共鸣，并能推进项目的成长和新想法。
点评：这也是质量文化，不是测试，但具体的实践——“在企业内部创建社区”挺好。我之前演讲或企业内训中也提过，当实实在在的测试部门不存在时，我们可以建立虚拟的测试部门——测试社区。这在一些公司（如Cisco）都有类似的实践。
5.相信：唯一能够判断和评估我们产品质量是客户。
AB认为：现代测试实践中，客户的反馈是非常重要的。收集客户反馈，直接或间接地从客户那里收集数据，使团队能够最好地判断客户是如何响应功能的。
点评：因为研发人员，包括产品经理、业务人员，都不能真正代表客户或用户，只有真正的用户才能给出真实的产品使用体验。要让用户更喜欢我们的产品或向客户交付更多的价值，我们自然要关注用户的反馈。这正如前面所说的传统测试原则：一切从客户的角度出发，想客户所想。测试人员要能够扮演用户角色，设身处地去针对产品进行测试，这样也就能挖掘更多的应用场景，发现更多的问题或提出更好的产品设计建议。
6.广泛使用数据来深入了解客户使用情况，然后缩小产品假设和业务影响之间的差距。
AB认为：数据是现代测试的关键。如果没有数据，我们只能猜测客户正在做什么、真正喜欢什么。提供无人使用或被迫使用的功能并不能长期给客户提过价值，而数据可以提供持续和预测性的反馈、缩小产品假设和业务影响之间的差距，帮助团队采取正确的行动。
点评：这是第1原则、第5原则的延伸，要客观地获得用户的反馈，客户使用产品的数据是关键的信息来源。如何基于这些数据，构建测试模型或帮助我们建立Test Oracle，需要具体的方法和工具来支持。
7.扩展整个团队的测试能力和专业知识;了解这可能会减少（或消除）对专业测试专家的需求。
AB认为：“我是否需要辞掉工作并成为开发人员？”不，专注于自己的测试使命，如引领质量文化、寻找改进、投入到测试工具的使用并获取知识以更好地帮助业务等。
点评：当测试人员指导开发人员做测试，可能会担心革了自己的命，所以才有开头那一问。如果对测试有信心、对自己有信心，就没有这种担心，否则做一些改变，“成为开发人员”也不失为明智的选择。一个工程师，能做开发工作也能做测试工作，自然在职场上更具竞争力，只是在“开发”和“测试”中，我们还是有自己更擅长的一面。
以上是 【软件测试】点评“现代软件测试原则” 的全部内容， 来源链接： utcz.com/a/131804.html
