| 编辑推荐: |
本文来自于软件测试网，文章介绍了如何在软件软件测试阶段进行质量全周期的管控。 |
|
1.4.7 测试阶段
软件测试阶段的工作就是根据需求设计的测试方案和测试用例，利用人工或测试工具对产品进行功能和非功能测试，需要跟踪故障缺陷，以确保开发的产品适合需求。如图1-12所示列出了测试阶段各个角色的任务和产出。测试人员在这个阶段需要准备集成测试和报告，之后准备系统测试计划和报告，并主持和参与系统测试，最后总结出系统测试评审报告。
图1-12 测试阶段
测试阶段需要测试人员来主导，开发人员配合修改缺陷，以确保产品质量。这里的测试主要包括代码扫描、功能测试、系统测试、集成测试、性能测试、安全测试和回归测试。
在软件测试过程中，经常会遇到如下一些误区。
1.开发人员测试自己编写的程序。
开发人员在编写程序时，有着固有的思维方式，也有可能理解错了需求定义和设计规范。若开发人员测试自己编写的代码，则很难发现问题。可能有些小公司没有配备专门的测试人员，但至少交叉测试也能找出比自我测试多得多的缺陷。
2.计划测试工作时假定不会发现错误。
这是非常危险的假设。人无完人，没有一个程序员可以100%地保证产品没有缺陷。
3.测试在代码开发完后才开始。
测试是贯穿整个开发流程中的，比如，需求阶段要进行需求测试，拟定测试计划。越早进行测试就能越早发现缺陷，修正的成本也就越少。
4.测试就是为了找到缺陷。
这个错误观点强调了测试的目的在于要以查找错误为中心，而不仅仅是为了演示正确功能为目的。通过分析错误产生的原因和分布特征，可以帮助项目管理者发现当前软件管理过程的缺陷，帮助开发者在类似的功能模块避免出现同样的缺陷。软件测试是一个过程或一系列过程，用来确认软件完成其应该完成的功能并且不执行不该有的操作。
5.如果产品上线后发现质量问题，都是测试人员的错。
产品的高质量不是测试人员测试出来的，而是需求、设计、开发等各个环节决定的。出现错误不是某个人的错误，可能来源于混乱的项目管理，也可能来源于技术的不支持，还可能是环境的配置问题。
在发现质量问题后，要积极地分析和修正缺陷，对周边受影响的模块再做细致的测试，避免更多的类似错误仍然在线上。程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
6.开发人员对测试不够重视，觉得测试技术要求不高，随便谁都能做。
软件测试是一项极富创造性、极具智力挑战性的工作。测试包含功能测试、性能测试、自动化测试和安全测试等，这些都需要专业的技能，要设计覆盖率好的可重复执行的测试用例，还要不断更新新技术、新工具、新流程、新测试方法。
开发人员只有尊重测试人员，关系才能融洽，才有助于测试人员更加积极地测试产品，尽量发现更多的缺陷，确保产品质量。
7.开发延期，为了项目按时上线，压缩测试时间。
很多时候，由于需求变更过多或者开发技术限制等因素，代码交付的时候已经延期很多。而项目经理为了按时交付产品，会压缩整个测试时间，这样会使得测试人员的压力过大，为完成任务而跳过很多环节。在这种情况下，项目经理应该仔细评估风险和成本，可以延期项目，或者可以缩小第一期交付的产品特性，不牺牲产品质量。
测试人员在设计和执行测试时，需要秉承如下几个重要原则：
（1）测试用例需清晰定义对预期的输入和输出；
（2）应当彻底检查每个测试的执行结果；
（3）测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当考虑无效和未预料到的输入情况；
（4）检查程序是否"未做其应该做的"仅是测试的一半，测试的另一半是检查程序是否"做了其不应该做的"；
（5）应避免测试用例用后即弃，除非软件本身就是一次性的软件。
如表1-10所示定义了测试阶段的条件、活动、标准输入和标准输出，并且确定了责任人。
表1-10 测试阶段的活动和输入输出
1.4.8 部署与试运行
部署主要由系统运维人员搭建部署环境，提供给测试人员回归测试、验收系统。项目经理需要配合部署人员做项目部署，了解项目部署环境，跟踪项目运行期间产生的缺陷，安排相关人员对相应缺陷进行更改。如图1-13所示列出了部署与试运行阶段各个角色的任务和产出。
图1-13 部署与试运行阶段
在部署与试运行阶段，有以下几个常见的问题。
1.应急响应系统不完善，没有自动化警报。
有些公司没有设立自动化运维系统，在系统异常时，没有设定警报。在早期阶段，运维人员需要值班，以保证试运行系统出故障可以马上处理。但这不是长久之计，还是需要自动化警告，通过QQ、邮件、微信等方式通知运维人员，提高响应速度。
2.消极应对异常信息，态度不端正。
运维人员如不能对异常信息进行有效处理，难以分清轻重缓急，就会延误解决时间。这里需要运维负责人对组内人员做好培训，强调优先级。另外，项目经理需要快速跟进这些问题，必要时告知运维负责人分配和处理这些问题。
表1-11定义了部署与试运行阶段的条件、活动、标准输入和标准输出，并且确定了责任人。
表1-11 部署与试运行阶段的活动和输入输出
1.4.9 项目总结
项目在试运行之后，最好由第三方进行验收测试，并根据验收报告进行整改。验收成功后，正常上线运行。各部门召开会议，进行总结回顾，列出优点、不足和报告总结，确定哪些可以在二期中进行提高和完善，以及如何更地好加强部门之间的协作等。
在项目总结阶段，可以得到如下总结：
1.《验收测试报告》；
2.《项目总结报告》；
3.《项目发布报告》；
4.《项目结项审计报告》；
5. 归档检查单；
6. 项目总结检查单；
7. 总结经验教训，丰富资产库。
8. 项目总结阶段的流程如图1-14所示。
9. 项目总结会应避免出现以下几种情况。
10.总结会过场子。
大家讲些不痛不痒的话，没有真正总结优缺点。
总结会变成批斗会。
由于项目延期上线或者试运行问题较多，大家互相数落对方的不是，这样不利于团队合作。项目开发过程中暴露出来的问题，需要就事论事，不要进行人身攻击。应该把之前的经验教训都记录下来，避免其他项目再走同样的弯路。
图1-14 项目总结阶段
表1-12定义了项目总结阶段的条件、活动、标准输入和标准输出，并且确定了责任人。
表1-12 项目总结阶段的活动和输入输出
1.5 项目管理十诫
笔者参与过大大小小几十个项目，包括B2B沃尔玛供应链、SAP各个模块实施和Abap二次开发、第三方支付平台、清结算和风险控制系统，总结出一些经验。由于自身的局限性，以及项目的不同、技术的不同和参与人员的不同，与读者要做的项目可能有很大的差异，以下这些经验仅供参考。
（1）绝对不要出现如图1-15所示的情况，图中所有人将全部工作都推给开发人员，这样会造成项目内各成员关系紧张，不利于沟通和后续工作的进行。其实很多工作是可以在其他阶段进行的，例如公共类和框架标准都是在设计阶段完成的。
（2）很多项目都是在需求未定的情况下就开始进行研发工作，这是最大的问题。相当多的项目经理在开发部门工作完成后，发现与需求不一致，再重新研发，宁愿花费几个月的时间反复研究，也不愿意在前期把需求定义分析清楚。最不能接受的情况是研发测试完成后再修改需求，本末倒置。
（3）当项目立项或者启动后，读者会发现戴明环、PMP等各种软件方法论和软件管理方法都无法施展，因为没有一个方法论或者软件开发过程是适合自己公司、自己团队的，只能在不断的磨合中创新一套自己公司、自己团队的软件开发过程。总之，适合自己的方法论就是最好的方法论，成功实施的软件开发过程就是最好的软件开发过程。
（4）在团队会议中，类似"这么简单的项目都做不了"的话说了也没有用，权利是吓不住项目组成员的，大家期望项目经理以身作则，而不是作威作福。公司的规章制度一定要严格遵守，项目经理应该起模范作用。
（5）不要轻易承诺，比如"我做过多个优秀项目，这个不成问题""这个项目是老板定的，大家放心，资源肯定能落实到位"。盲目乐观的结果注定是悲观，需要落实的奖励机制和奖金政策一定要落实。
（6）有时常听到类似"兄弟，我的前程就靠你了""今年的年终奖就看这个项目了，一起吃个饭，把这个事情搞定"这样的话。孤注一掷的成功概率往往低于50%，因为风险都在一个人的身上，这恰恰是最高的风险。
（7）没有计划，工作估算就是随便拍脑袋想想，例如"你说10个工作日，7个工作日吧，没有问题，你们是最棒的，能力最强，加几天班，肯定能完成"。在项目启动阶段，计划、策略、风险控制和预防机制才是最关键的。在估算各自部门的时间时，尽量有一个时间缓冲，要不然会造成措手不及。
（8）遇到错误，不要说"你辜负了我的信任"。错误已经发生，要做的是找到解决方案，埋怨只会破坏和谐，团队氛围越来越差。
（9）"都是项目经理的问题，大不了我走人，绝对不和你一个项目组了。"三十六计"走为上策"不一定是正确的，下一个项目、下一个公司、下一个项目经理可能更差。在项目进行中，参与的项目组成员应该是固定的，尽量不要被临时抽调，否则会造成延迟。
（10）软件配置管理一定要严格，发布和确认一定要有说明。 |
