面向Java开发人员的十佳GitHub储存库
|
但做好测试，可以收获下面这些益处，至于要不要做，完全取决于当前你的团队： 早发现，早治疗在数据库开发领域，手工测试和一次性脚本测试，是最常用的。 但不利于找出是否有破坏性的功能缺陷因为新加的特性而引入。有了自动化的测试工具，任何时候针对任何数据库版本，都可随时完成测试。 往往寻找一个bug的产生，需要耗费8-16小时，甚至更多，仅仅是因为某个开发嵌入了一个新模块的代码，针对数据库开发来说，没有特别好的debug工具，只能靠人肉眼去逐行扫描代码，最终才能定位到某个可疑的地方。 减少重构风险网上有个玩笑，中年(35岁)程序员如何才能保住自己的饭碗?将SQL写的越长越好，越少人看得懂越好。碰到这样的祖传代码，很多新人都是要问候原作者的直系亲属的。我上次说5000行代码的维护，就已经有读者受不了了。 那么怎么规避这种毫无设计感的代码呢?还是测试。假如一开始，一个用户需求就是一套测试用例，那么放心的去重构吧，爱怎么重构就怎么构，完了跑下测试就行。但如果没有测试，你敢动这大几千行的代码么，即使你拍着胸脯说，你敢，你老板敢么? 保障团队协作如果说程序员比较宅，不喜欢旅游，可以天天上线解决代码问题，那么谁还能不生个病呢。如果生病的时候，你负责的代码出问题了，谁来解决呢?全组都要等一个人才能继续往下工作，这种风险也太大了。 如果有了测试策略，一个人断了线，另一个人接上，接着往下码。只要大家都是同一个平台，接手完全没有问题。这对数据库开发就更有利了。无论是sql server, oracle,mysql, 只要测试用例都在，我们的目标就是编写出通过测试用例的代码，至于T-SQL, PL/SQL的转换，文档查查，一点问题没有。 数据库测试怎么做 那么数据库怎么做测试呢，特别是看到上千行的存储过程，一大堆的 ETL 程序?作为开发，完成功能的实现就万事大吉，但作为测试，既没有实现功能的大快人心，还必须提心吊胆为最后的质量把关，弄不好，老板认为测试不具备生产力，还要压低你的薪水，彻底悲剧了你。 既然测试这么难，那么我们怎么保障自己测试的质量呢?下面说说我的一些个人看法。 就跟看书一样，如果拿起一本书从头看到尾(曾经我也是这样么像教科书一样看计算机的图书)，那么我敢打赌，一本800页的数据结构，99.99%的人，看到300页的时候，绝对放弃了，顶多再往后多翻 5 页，即305页。然后不停的翻翻后面，数数还有多少 页没看，还需要花多少时间，不用问为什么我知道，你懂得。 那么我从什么时候开始不这么看书了呢?从看完《CLR Via C#》开始.本书777页，我花了近 5 个多月，每个礼拜天就躲在家里看，看不下去了，就喝杯星巴克，继续看，边看边画。最终一页不落，全部看完。有些地方还看了不止5遍。还有本手册，《Oracle Concepts》,大概看了不少于 6 遍，边看边画，每个晚上8点准时看，一直到看不动为止。 那么为什么看完这两本之后，再也不相信从头到尾的看书方式了呢?因为好的书，配上好的结构，你看任何 一章，都是可以不需要前面章节的知识，依旧可以读的很愉快。如果读不懂，通过想象力和搜索引擎，反而能解决当下最重要的问题。 因此，读书最重要的是明白自己想要什么。测试也一样，必须根据测试内容，而制定测试计划。如果要测试并发压力，就不能用单元测试;要测试新功能，就不能执行回归测试。
有的同学会觉得数据库测试很简单，先 R(retrieve) 一下，在CUD(Create Update Delete) 一波，最后在 R 以下，如果满足结果就算测试通过。
画个图介绍下，不就是这样么： （编辑：平顶山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
