现代软件测试原则之大盘点

我之前也梳理过很多测试方面的原则，可以概括为十大测试原则：

测试目标要明确，并建立合理的阶段性目标

一切从客户/用户的角度出发，想客户所想

测试尽早介入，一旦项目启动，测试就要介入进去。

尽可能确保软件的可测试性

持续地测试、持续地反馈，最大程度地降低研发成本，提高研发效率

测试时不能穷尽的，应设定合理的测试目标或测试终止的条件

基于项目的上下文来制定相应的测试策略

基于风险的测试策略总是有效的

测试计划不仅是文档，更是一个过程，应根据测试状态不断变化而进行调整

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认为 ：“我是否需要辞掉工作并成为开发人员？”不，专注于自己的测试使命，如引领质量文化、寻找改进、投入到测试工具的使用并获取知识以更好地帮助业务等。

点评 ：当测试人员指导开发人员做测试，可能会担心革了自己的命，所以才有开头那一问。 如果对测试有信心、对自己有 信心 ，就没有这种担心 ，否则做一些改变，“成为开发人员”也不失为明智的选择。一个工程师，能做开发工作也能做测试工作，自然在职场上更具竞争力，只是在“开发”和“测试”中，我们还是有自己更擅长的一面。

在这里推荐一个软件测试交流群，QQ：642830685，群中会不定期的分享测试资源，测试面试题以及测试行业资讯，大家可以在群中积极交流技术，还有大佬为你解答问题。

• 还没有人评论，欢迎说说您的想法！