 |
|
|
| 返回 | 主页 |
强化测试用例在测试活动中的作用 下
[摘要]
F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。本人的原则是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。例如IBM Rational Robot或XDE...
F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。本人的原则是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。例如IBM Rational Robot或XDE Tester（http://www-900.ibm.com/cn/software/rational/products/xde_tester/index.shtml，现更名为Rational Functional Tester）。针对自动化测试原则，可参阅笔者的"自动化测试要点"译文，这里要提的其他几个基本原则是：
一、是选择恰当的测试工具品牌，并要求提供培训；
二、是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；
三、是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；
四、是选择最简单、最重用的测试用例使用自动测试方法；
五、是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制-加校验点-回放的方式，以开发出健壮且重用性强的测试脚本；
六、是有专人更新脚本，也有专人跟踪自动测试结果；
七、是一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；
八、是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本，IBM Rational ClearCase是当前业界功能最强大的配置管理工具，可以将开发代码和测试代码都集中管理，进行高效的版本控制和工作空间管理，保证多人开发大量代码的稳定性。对于局域网范围内的开发工作，使用ClearCase LT版足够。 由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。
5） 软件验收阶段，除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个新员工来做，那就死翘翘了！ 退一步说，如果您公司的测试部门经历一次这样重大的洗礼，有一个项目真正按照此原则实施一次，也必将对未来测试工作的开展发挥推波助澜的作用、起到事半功倍的效果。
6） 其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。
另外，笔者不赞成对人员的强制性管理，例如大张旗鼓整顿公司测试部门的管理，采取缺陷报告数和人员绩效挂钩、不按测试规范执行就适当惩罚等手段；个人认为切不可急功近利，当以人为本，鼓励+促进甚善然、甚妙哉！
3. 总结
综上所述，我们得出结论-- 测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利；测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全、不规范；至于如何解决，笔者提出了微薄建议，供业界朋友参考与交流。
国内软件测试行业目前仍处在群雄逐鹿、百家争鸣的时期，芸芸纷说，不如从企业自身出发，确立最适合自我的测试管理解决方案，整顿自身的测试工作流程，那才是金玉良言的上上策！
其它培训参考信息：
强化测试用例在测试活动中的作用 中
强化测试用例在测试活动中的作用 上
构件可测试性挑战
在测试用例预演过程中应该主要的问题
测试用例预演发现的问题需要记入缺陷库吗？
好像我用测试用例预演方法很难达到预期的目标？
测试用例预演方法可以用在其他地方吗？
测试用例预演可以在哪些场合下使用？
信息来自互联网，敬请核实，谨慎使用
