1
hhyvs111 2019-02-15 15:47:07 +08:00
写多了就行了
|
2
xcolder 2019-02-15 15:48:23 +08:00
单元测试
|
3
jdgui 2019-02-15 15:49:04 +08:00
调整心态。
只需要在心里骂,什么傻逼用户这么用软件的。就完事 |
4
emCupid 2019-02-15 15:50:11 +08:00 1
电脑、显示器、键盘、鼠标一切和撸代码有关的设备都贴上符,保平安
|
5
misaka19000 2019-02-15 15:52:35 +08:00 via Android
靠测试来保证质量
|
6
cnoder 2019-02-15 15:53:42 +08:00
感觉就像一个风中残烛的老人支撑着拐杖往前走,总怕他会在哪跌倒
|
7
richangfan 2019-02-15 15:55:59 +08:00
软件的可用性是由测试保证的,大学里都教过的。
|
8
Kylin30 2019-02-15 16:01:46 +08:00
配发操作手册,严格演练,责任到人。
|
9
orangeChar 2019-02-15 16:06:49 +08:00
写监视程序 写监视监视程序的程序 写监视监视监视程序程序的程序
写备份方案 写备份方案的备份方案 写备份方案的备份方案的备份方案 想好甩锅方案(指甩锅给测试以及用户以及其他人,不包括开发) 想甩锅方案失败的甩锅方案 ~~~~ 完了就多写代码 |
10
jinhan13789991 2019-02-15 16:08:26 +08:00
要么程序简单的没有 bug,要么复杂的到不到 bug
|
11
unicloud 2019-02-15 16:17:48 +08:00
多写多总结
|
12
c466934322 OP @cnoder 同感
|
13
xpresslink 2019-02-15 16:23:16 +08:00
你保证不了。
正经软件公司都会有专业的测试部门和人员,要做功能测试和压力测试。 当你被测试的妹子给怼的不要不要的,不停改 bug 的时候你就提高了。 |
14
tomczhen 2019-02-15 16:23:56 +08:00
对边界情况要保证测试用例覆盖。
可能会超出预期的情况,如果项目时间不足,则需要防御性编程,发生问题可以第一时间定位。 发生过的错误,除了修复,还需要编写对应测试用例。 |
15
saulshao 2019-02-15 16:49:14 +08:00
这个其实就是测试用例,经验指的就是这种事情。
除非有一天我们可以用程序本身来写程序,否则就要依赖于这种失败->修正的循环过程来提高稳定性 |
16
lk920724 2019-02-15 16:56:49 +08:00
一直试错
吧? |
17
KickAssTonight 2019-02-15 17:24:20 +08:00
代码 review
|
18
cxtrinityy 2019-02-15 17:27:25 +08:00
写之前就做好所有 if else 的情况考虑,同时保证代码的扩展性,写出基础版本后自己测试各种情况,不断迭代,最后由测试来做最后的保证
|
19
xiaoidea 2019-02-15 17:31:59 +08:00
即使你写了很完备的单元测试,你也没法保证不会出现各种运行时异常,数据 /机器 /网络甚至项目中用到的各种 library/middleware 都会导致难以预料的运行时异常。所以要做好日志+监控+报警,亡羊补牢是有必要的
|
20
zlmdaybreak 2019-02-15 17:35:20 +08:00
少考虑场景谁都无法避免,全靠经验。开发前通过 review 方案和结束后的 review 代码是可以帮助减少这种现象。
|
21
Sparetire 2019-02-15 19:14:19 +08:00
普通人靠静态类型的类型检查和单元测试, 巨佬靠形式化验证...
|
22
leekafai 2019-02-15 20:19:55 +08:00 via Android
没做过自然就会没考虑到,多做就行了
|
23
yiyi11 2019-02-15 22:05:46 +08:00 via Android
考虑不到是经验问题。理论方法来提高程序可靠性有很多。但实际上跟需求,设计,架构,工期有很大的关系,具体业务编码只是占很小作用的一部分。
|
24
fish47 2019-02-16 14:33:09 +08:00
我建议加一个限定 -- "在你所见过,或实践过的,并且有所成效的" 。
|
25
vtoee 2019-02-16 17:57:15 +08:00
@xpresslink 谁说测试一定是妹子
|