软件测试宣言

  • 侯伯薇

2012 年 10 月 31 日

话题:测试语言 & 开发文化 & 方法

认可测试的价值,但更鼓励事先确定验证的标准并以此来驱动开发

认可专业测试人员的不可替代的价值,但更鼓励开发人员做好测试

认可测试计划的价值,但更强调计划是一个基于风险不断调整的过程

认可探索式测试的价值,但更希望测试是具有系统方法的、相对规范的过程

认可发现缺陷的价值,但更重视对软件产品质量的全面评估与持续反馈

崔启亮 - 北京 ISTQB:测试需要提高认识,满足用户的综合要求。测试和开发的关系将更加密切,而不是完全独立。提倡测试驱动开发 Test Drived Development (TDD),开发辅助测试 Developer Assisted Test (DAT)。

朱少民:回复@崔启亮 - 北京 ISTQB: TDD 和 DAT 同时出现更好,但我更提倡 ATDD (验收测试驱动开发),提倡先确定验证标准(质量的具体要求)。而 TDD 实施起来效率会有些问题,有一定的浪费。

胡争辉:脱离的产品工程的品质保证工程是无本之木,无源之水。首先应当强调产品工程,然后在产品工程中强调需求工程,其次在需求工程的基础上强调品质保证工程。在一个工程中,品质保证超过需求,或者品质保证超过产品都是没有意义的。

朱少民:回复@胡争辉: 不能完全同意,品质保证可以跨越产品工程,覆盖整个软件的生态链、生态环境。现在软件更多是服务过程,产品的概念越来越淡薄。

程序员邹欣:值得开发,测试,项目管理人员思考。 认可内部测试的重要性, 但更重视产品对用户的长期影响。

朱少民:回复@程序员邹欣: 差不多可以作为我的软件测试宣言第 6 句: 认可内部测试的重要性, 但更重视产品对用户的长期影响

胖子 - 邓晓明:朱老师,我是在上海软测大会得到您签名书的童鞋, 我有两个问题: 1、为什么把认可探索式测试放在前面?为什么不是 ST? 另外本句后面个人更倾向于【更强调】 2、最后一句,认可发现缺陷的价值,个人认为有点倾向于人,而后一句又是描述过程改进。以上两方面是我个人看法,请朱老师指正 。

朱少民:回复@胖子 - 邓晓明: 好问题啊。1. 因为未知,才有探索的空间,因为需求不清楚、时间紧等各种原因,探索式测试才更有效,在一定程度上是因为软件开发本身的问题,例如我称”敏捷开发“为”探索式开发“,测试才被动应付这种局面。2. 最后一句讨论了测试的本质:是发现缺陷呢还是对产品质量的全面评估?

蔡德辉 _IT 研发管理前沿:为啥就没人发一个如何保证设计本身的质量杠杠的,而不是靠测试呢?我们认可测试的价值,但出产无缺陷的产品才是我们追求的。

朱少民:回复@蔡德辉 _IT 研发管理前沿: 有设计原则、设计模式和开发框架等,以及设计、可测试性检查等,都是在设计上预防问题的发生。

jeffsn:多谢总结,从测试的角度提出了对产品开发的要求。 请问如何定义产品发布前的软件测试工作和用户测试工作的范畴呢?用户测试的工作是否应该有软件测试人员介入?

朱少民:回复@jeffsn: 一般来说,系统测试工作覆盖功能测试、性能测试、安全性测试、易用性测试等工作,包括各种负面测试等。而用户测试主要针对用户环境、用户数据等进行安装 / 卸载测试、数据和系统的兼容性和安全性测试、用户需求的进一步确认(功能性测试)等,软件测试人员应该介入,和用户(代表)共同实施。

不脱不洒脱:我们现在的探索性测试为零,这是我们团队测试中的一个漏洞环节,因为我本身就认为测试必须具有系统方法和标准的流程体系。这也是我的不足,无可辩解……

朱少民:回复@不脱不洒脱: 属于哪个行业?什么产品类型?在传统软件行业来看,探索式测试可以作为一个辅助手段。这不能算“漏洞环节”,如果发布出去的产品质量不够好,可以加强探索式测试,反过来也可以完善已有的测试用例。也不要忘记缺陷的 RCA。

测试语言 & 开发文化 & 方法