书评--提升软件质量的必经之路

软件是多个”人”长期构思，协同作业下的成果，不可能不出错。若没有配置相当的人力物力资源，分阶段把关测试，将随着系统规模渐大而逐渐失去控制的能力。
@小标：被疏忽的一环
笔者在赴制造业授课时，看到偌大的办公大楼内，整个楼层的品保(QA)专业人员，使用华丽的软硬件，针对制造流程上的瑕疵缺点做各种的良率分析，但该企业的 MIS 开发却没有测试人员的配置。换句话说，为支持品保所成立的软件团队，在开发软件时，本身没有品保的支持。
投资出钱的企业老板们往往不清楚软件开发的困难与复杂，一般大众也充满着对软件工业的误解。如笔者任职顾问的报业集团，其建立了首屈一指的编审制度，企业内全盛时期，有八到十位软件工程师花费近两年的时间，开发给上千位编辑使用的系统环境，为得就是对上千位记者所撰写的文字内容严格把关。
但没有软件专业人员为系统开发把关，让笔者斗胆做个对照，若程序设计师撰写程序代码如同记者撰写文稿，则我们没有测试工程师如同编辑来编审与校稿，也就是没有 code review与测试。软件开发团队也缺乏如编辑们对整份报纸的版面编排与改稿，也就是没有软件的重构(refactoring)。甚至对程序代码的错误追踪和版本控管都还不如编辑们对文稿修改所提追踪功能之要求。
换句话说，每个产业都有其专业，卓越企业的管理阶层对该公司之品管一定都有严格的标准，如本书第九章所描述的全面质量管理(TQM Total Quality Management)。但对支持品管的信息系统本身之品管却由于无知而导致漠视。
既然全面质量管理是大大小小的”计划(Plan)、执行(Do)、检查(Check)、处理(Act)”等 PDCA 循环流程，没道理提升公司竞争力的信息系统没有”检查”。而纯由脑力合作建构的信息系统又没有容易施行与监督的标准步骤(SOP)，则更应该强化软件测试，以提升质量。
软件测试在国内往往是被忽略的一环，光从笔者对书籍中专有名词的翻译感到陌生可作为一个指标 ，因为专有名词的翻译是约定俗成的，若大家朗朗上口，且对定义清楚明了，代表该技术在此已经落地生根行之有年。反之，则代表大家还在启蒙阶段，虽然美国早在上个世纪 70 年代就已经建构理论，近年更提出开发与测试人员的比例最少 3 比 1 的要求(本书中描述微软的开发与测试人员视项目的不同，比例是 1比 1.5 到 1 比 3，也就是一个程序撰写人员配置三个测试人员)。
而我曾经和国内一家软件开发商的美籍品管工程师聊天，他说他在美国曾待过四家公司，不管规模如何，没有一家公司没有专业的品保人员。但他在台湾没看过具专业品保流程与品保工程师的软件公司或 MIS 部门。
@小标：建构体系
软件生命周期中，大分有分析、设计、开发、测试、上线、维护，若越晚发现问题，修正错误所付出的代价越大。任何阶段的工作与产出皆有可能出错，因此如「以测试驱动开发(Test-Driven Development TDD)」方法论所提倡的，在分析的初始，应该就同时撰写测试案例(Test Case)，亦及以测试来验证对需求的了解程度，并规范接下去的设计与开发不至于偏离。
也就是在分析时期，要撰写如何测试是否符合使用者需求的文件，在设计时期，要提出模块与架构间整合测试的方式，以确认架构与接口定义的正确性。而在开发时期，同时撰写单元测试，以验证个别程序代码的正确性。同时，说明文件的正确性也要一并测试。让 V&V(Verification and Validation)的精神贯穿整个开发过程，时时验证(Verification)是在做使用者需要的产品，并确认(Validation)把事情做对。
软件测试理论从 1970 年代建构至今，已经自成体系。随着 ISO、CMMI、Agile 的盛行，不管是 CMMI 的 Support process areas，或是 Agile 的 TDD、Pair Programming，都规范了软件质量的基本要求，确保质量的构成要素，以及实践的方向。或许，这是当今软件项目管理人员不可或缺的常识。
浏览书中所架构的测试定位与流程让自己一身冷汗，忝为教人做软件的讲师或顾问，自认稍有涉猎软工中的测试环节，但从未在心中建立出一套完整的测试架构。或许是疏于找寻，满足于浮面的知识，以往总以人力资源不足，项目时间短促等理由自欺欺人，而让测试流于形式。
当我们永远陷在资源不足的窘境中时，如何拿捏资源分配应是首要问题。而不是把不熟的领域直接割舍。若心中没有整个测试的轮廓，如何能够取舍该做多少？
@小标：软件测试之定位
书中提出对软件测试定位的认知，或许值得你参考：

•  提高软件测试的效率和产出依靠功力，好的测试人员不仅要掌握各种测试技术，还要具备丰富的程序编写和对 bug 的敏感度。
•  经验对软件测试至关重要，有无经验的测试人员实有天壤之别。软件测试有复杂专业的技术，且需要测试项目本身的项目管理。
•  软件测试有规范与理论，不是随心所欲爱做多少做多少，需要分配时间、人力、财力。
•  开发与测试是相辅相成的过程，开发与测试两个团队间的交流、协助是提高整体效率的重要因素。
•  软件生命周期中的「测试阶段」表明该阶段的主要工作是测试，但不是说测试工作只发生在该阶段。通常「测试阶段」的主要任务是执行测试与撰写报告，但准备工作如测试计划，案例(test case)以及测试程序的编写要在更早阶段完成。
  开发过程中交互执行着单元测试(unit test)，若干单元或全部集结后的测试，在日渐高涨的软工理论 TDD 中，要求周期性的甚至到每天编译(build)后执行测试计划，第二天看分析报表。
•  软件测试是一种有效提高软件质量的手段，但不能百分之百地发现所有质量的隐忧。

@小标：工欲善其事，必先利其器
由于应用程序的开发方式繁多，如采用 C++、Visual Basic、Java、Delphi、.NET、D2K…等，存取接口也大不相同，如批次作业、Web、Windows Form。而我们的测试目的，除了上述开发流程中的配套作业外，尚有安全、压力等测试。广义而言，你还需要测试使用者的专业能力(或许使用者的无知，是系统损毁、安全疑虑的最大来源)，系统灾难复原的能力、随着软硬件迭代更新的兼容性等等。因此，测试工程师需要选择适合的软件工具，建构独立的测试环境，并有程序写作、整合软硬件平台，协调开发人员的能力，同时在人格特质上喜欢找问题，挑毛病。这其实与软件开发工程师喜欢堆积木，无中生有创造系统的特质不同。
当我们定出软件测试的流程后，若没有强悍、整合、易上手且自动化的工具程序，则推广的结果可能是流于空谈，毕竟测试是一再重复而枯燥的流程。
本书中除了对 ISO、CMM、TQM 等规范与软件测试之关系，各种开发阶段所应进行的测试工作，不同类型的测试之定位有明确解说外，于后半册广泛介绍了在软件测试领域著名的厂家，也详列了著名的软件测试工具，并分门别类地介绍工具之使用。撷取操作的屏幕画面，以逐步介绍的方式解说。
＠小标：阅读建议
这本书有点流于教科书的繁杂，且部份细部章节的编排上稍嫌紊乱。书中有些过于理论的说明，需要读者耐得住性子 。且受限于项目经费、时程与人力，若要将书中的建议全部落实于我们日常的团队合作，似乎仍有一段落差。
建议你先广泛地浏览一下书籍内所谈到的内容，如操做测试的黑箱/白箱进行方式，配合开发流程而对应的测试流程，如单元、整合、确认、系统、平行验收等测试。有了概念后，在软件开发的过程中，再择要精读。
由于导入测试的效益要明显呈现，恐怕是在两三个案子之后，这种先期需要投资，但下两三个案子才见效益的规划，对项目经理而言，可能更需要谨慎拿捏资源配置的比例。
@小标：相关阅读
对于国内广大的微软产品爱用者而言，这本书有点可惜的是于此主题着墨不多。若你需要从事 Microsoft .NET 开发相关的测试，可以参考以下的书籍：
 Test-Driven Development in Microsoft.NET，作者为 James W. Newkirk、Alexei A. Vorontsov。出版社 Microsoft。
此书有介绍 TDD 的概念，以及免费软件工具 NUnit 搭配 C#/.NET Framework 开发与测试的使用方式。
 Working with Microsoft Visual Studio 2005 Team System，作者为 Richard Hundhausen。出版社 Microsoft。
此书是本入门书，介绍 VSTS 的架构，与实做软件生命周期管理之方式。并对于 VSTS 所提供的测试管理：Test Manager、Test View、Test Project、Test Results，以及测试类型 Unit Test、Code Coverage、Profiling、Manual Test、Web Test、Load Test 稍有介绍。
若要强化软件质量，重构是可考虑的过程，而重构更与测试密不可分。你可参考与重构相关的书籍：
 重构—改善既有程序的设计(Refactoring : Improving The Design of Existing Code)，作者为 Martin Fowler，译者 侯捷/熊节，碁峰出版。
除了书籍外，以下这个网站也蛮有趣的，值得去逛逛：周思博趣谈软件(http://chinesetrad.joelonsoftware.com/index.html)

@书名：软件测试理论与实作
@飞思科技产品研发中心 编着
@博硕文化出版
@售价：520元

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=809831