测试工程化项目实战之路（01）

lsekfe

1.1什么是测试工程化
　　在项目的实际开展过程中，我们经常面临如下场景：
　　需求不断变化，然而软件交付时间不变；
　　开发人员将版本发布延期，但没给测试人员留下太多测试时间；
　　在项目经理要求的新功能上线后，市场人员的反馈是新功能基本没人用。
　　在面对上述场景时，作为软件测试人员的我们可能会感到压力，因为我们不仅有产品交付的紧迫感，还要守护软件质量。随着项目迭代过程的推进，我们可能发现测试人员并不一定能够在早期就参与到项目中，以及测试人员发现的bug并不一定能及时得到修复。有时，我们会遇到软件版本上线时间临近，无论是已发现的bug，还是不符合需求的设计，都可能有不再修改的情况。我们可能并不赞成带缺陷的版本上线，但产品经理认为已知问题风险可控，版本必须发布，此时我们需要或可以接受目前的版本。
　　为什么呢？这个决策的背后其实遵循一个原则：测试是一种商业性投资活动。而作为投资活动，投资方必然考虑产品的投资回报率（Return On Investment，ROI），即产品价值问题。这些正是“敏捷铁三角”模型（见图1-1）所要表达的重要思想。

图1-1  “敏捷铁三角”模型

　　在一般情况下，所有产品的开发都会受到其价值、质量和约束的限制。其中，约束是指产品的开发受到投入成本、产品功能范围和产品发布进度的共同约束，三者关系紧密，相互影响。软件测试活动也不例外。本书探讨的测试工程化正是这种围绕产品价值的一系列测试活动而有序进行的过程。测试工程化是一个系统化、模块化和规范化的复杂过程。
　　为了便于读者进一步理解，作者以“房子验收”为例进行类比。下面是关于“房子验收”的故事（本故事仅为类比，与实际房子验收有出入）。
　　某天，一位名叫陈师的测试专业人士，将一群测试行业“小白”带到一个房子验收现场，现场示意图如图1-2所示。

图1-2  房子验收现场示意图

　　陈师：这面墙由什么组成？
　　小白A：红砖、钢筋、水泥和砂石。
　　陈师：好！这面墙的完成质量如何？
　　小白B：墙已经封顶，而且墙的表面看上去很平整，但墙的完成质量如何评判呢？
　　陈师首先用锤子在墙面上敲了几下，然后用放大镜看了看，最后用铁凿在红砖之间的接缝处凿了几下。
　　陈师：你们听到和看到了什么？
　　小白C：敲打的声音，有些红砖在敲打后出现了裂痕，而且红砖之间的接缝处掉渣子了。
　　陈师：昨晚，施工队长告诉我，房子可以验收了，你们就把这个房子当成软件发布的版本吧。大家看看我手上的放大镜、锤子和铁凿，它们可都是验收房子的“利器”呀！我手上的这把锤子很特别，它可以更换几种不同形状的锤头，我在墙面的不同地方使用不同的锤头和不同的力敲打，发出的声音是不一样的。这些锤头和力的组合构成了多种验收方法。通过放大镜，我们可以看到墙面上不易觉察的纹理。根据纹理，我们可以决定使用何种锤头与力的组合来敲打墙面，这与软件测试中的工具和方法的应用类似。在软件测试中，工具和方法的不同组合构成了软件的不同输入，不同的输入会带来不同的输出。我们可以把敲打红砖后出现的裂痕理解为软件的某个功能函数有bug，需要进一步判断是否修改。红砖之间的接缝处掉渣，说明它们之间的连接有问题，不能通过验收，这就像软件模块之间的接口有问题。如果模块间的耦合度高，那么我们需要考虑优化或重构。
　　小白A：哦，原来如此。但是，对于砌好的墙，我们为什么要用锤子、铁凿去破坏呢？这好像是在拆墙。
　　小白B：陈老师想表达的是一种测试思想。软件测试不是让你与开发人员对着干。为了测试软件的质量，测试人员需要应用一系列工具和方法。另外，测试人员还需要对软件的功能、性能等进行验收与评价。
　　此时，陈师冲小白B笑了笑，然后说：是的。
　　陈师接着说：开发人员通过编写代码实现了软件的各种功能。我们可以将一块块红砖看成一个个函数。函数是软件代码中的最小单元。当批量的红砖通过水泥、砂石和水砌在一起时，就会形成一面墙（见图1-3），这面墙可以发挥比一块砖更大的作用。同理，函数通过多层调用，形成功能模块。多面墙连接在一起，相当于软件的模块集成。这些墙经过组合后，就可以形成一座完整的建筑，如一栋3层的楼房。软件开发建造的是软件“房子”。这个“房子”既可以是可独立运行的App（Application，应用程序），如手机上的备忘录App，又可以是复杂的控制系统，如航空航天软件系统。

图1-3  由红砖砌成的一面墙

　　为了方便读者理解，作者将建造房子和开发软件进行对比，见表1-1。

表1-1  建造房子与开发软件的对比

　　小白C听后恍然大悟：原来如此，事物是相通的。
　　小白C：陈老师，软件测试中有黑盒测试和白盒测试，它们分别适用于何处？
　　陈师：这个问题提得好！对于功能模块的测试，我们通常采用黑盒测试。白盒测试可用于单元测试、模块集成测试和接口测试。
　　小白B：对于软件测试，我理解为“拆房子”，也就是逆向思维有利于发现并解决问题，从而更好地守护软件质量。
　　陈师：“拆房子”这种逆向思维虽好，但并不全面、系统，我们还需要从软件构建的整个体系出发，通过工程化方式，思考如何在软件生命周期的各阶段更好、更快地发现问题。例如，在需求阶段，我们可以纳入需求测试活动，也就是在开发人员未开始编码之前，解决需求问题，避免软件项目未实现需求而推倒重来，从而避免浪费开发人员和测试人员的时间。从产品软件在研发端交付后的后续流程来看，软件在产品量产环境下的安装和售后的用户服务是否方便，以及软件在客户端是否易用等，都是我们在软件生命周期内需要考虑的质量要素。对这些要素进行评估的活动通常称为非功能性DFX[DFX（Design for X，面向产品生命周期各环节或特性的设计），X表示产品生命周期的某一环节或特性，如可制造性（Manufacturability）设计称为DFM，可装配性（Assembly）设计称为DFA，可靠性（Reliability）设计称为DFR，等等。]测试。
　　作者认为，只有具备良好工程特性的产品，才是满足客户需求的好产品。软件测试始终需要围绕全链路的工程特性开展，这样才能全面、系统地守护软件质量。

oliver.tang

学到了