使用树莓派3b+作为辅助开发体验

配置 树莓派3B+的配置 4核1G CPU ARMv7 Processor 64G SD卡 常用软件 neovim LXTerminal终端 chrome浏览器 谷歌拼音输入法 常用语言 golang c nodejs 外设 键盘鼠标: 雷柏 无线机械键盘加鼠标 150块左右 屏幕:一块ipad大小外接屏幕,400块左右 常用工作 Golang UDP Server开发, 总体还算流畅。前提时不要加载太多的neovim插件,特别象coc-vim, go-vim等插件,安装过后让你卡的绝望。每次当我绝望之时,我就关闭了图形界面,回到终端继续干活。但是即使使用纯文本方式登录,运行vim还是很卡。 后来我在macbook pro上也用neovim开发,发现也是很卡。于是我就释然了,9千多的macbook都卡,300多的树莓派卡一点怎么了! 但是卡顿还是非常影响心情的,于是我就大量精简vim的插件。 我基本上就用两个插件,都是和状态栏有关的。其他十二个插件都给注释掉了 call plug#begin('~/.vim/plugged') Plug 'vim-airline/vim-airline' Plug 'vim-airline/vim-airline-themes' Plug 'jiangmiao/auto-pairs' "Plug 'yonchu/accelerated-smooth-scroll' "Plug 'preservim/tagbar', { 'for': ['go', 'c']} "Plug 'airblade/vim-gitgutter' "Plug 'fatih/vim-go', { 'do': ':GoUpdateBinaries', 'for': 'go' } "Plug 'dense-analysis/ale' "Plug 'vim-scripts/matchit.zip' "Plug 'pangloss/vim-javascript', {'for':'javascript'} "Plug 'leafgarland/typescript-vim' "Plug 'neoclide/coc.nvim', {'branch': 'release'} "Plug 'jremmen/vim-ripgrep' "Plug 'plasticboy/vim-markdown' "Plug 'mzlogin/vim-markdown-toc' call plug#end() filetype plugin indent on filetype plugin on filetype indent on set guicursor= set history=1000 let g:netrw_banner=0 let g:ale_linters = { \ 'javascript': ['standard'], \ 'typescript': ['tsserver'] \} let g:ale_fixers = {'javascript': ['standard']} let g:ale_lint_on_save = 1 let g:ale_fix_on_save = 1 let g:ale_typescript_tsserver_executable='tsserver' let g:airline#extensions#tabline#enabled = 1 let g:ale_set_loclist = 0 let g:ale_set_quickfix = 1 let g:ale_open_list = 0 let g:vim_markdown_folding_disabled = 1 let g:vmt_cycle_list_item_markers = 1 let g:tagbar_sort = 0 " colorscheme codedark " let g:airline_theme = 'codedark' " " buffer let mapleader = "," nnoremap <Leader>j :bp<CR> " previous buffer nnoremap <Leader>k :bn<CR> " next buffer nnoremap <Leader>n :bf<CR> " previous buffer nnoremap <Leader>m :bl<CR> " next buffer nnoremap <Leader>l :b#<CR> " previous buffer nnoremap <Leader>e :e<CR> " open netrw nnoremap <Leader>d :bd<CR> " close buffer nnoremap <Leader>g :!go fmt %<CR> " go fmt current file nnoremap <Leader>tm :%s/\s\+$//e<CR> " trim space at endofline nnoremap <Leader>a A nnoremap <Leader>w :w<CR> nnoremap <Leader>c :clo<CR> nnoremap <Leader>/ :Rg<Space> inoremap jj <ESC> highlight CocErrorFloat ctermfg=White let g:netrw_list_hide= '.*\.swp$' let g:ctrlp_custom_ignore = { \ 'dir': '\v[\/]\.?(git|hg|svn|node_modules)$', \ 'file': '\v\.(exe|so|dll|min.js)$', \ 'link': 'some_bad_symbolic_links', \ } set autoread " au CursorHold,CursorHoldI * :e " au FocusGained,BufEnter * :e set so=7 set ruler set cmdheight=2 set hid set backspace=eol,start,indent set whichwrap+=<,>,h,l set ignorecase set smartcase set hlsearch set incsearch set showmatch set mat=2 syntax enable set background=dark set ffs=unix,dos,mac "set ai "Auto indent "set si "Smart indent set wrap "Wrap lines set cursorline set tabstop=4 set shiftwidth=4 set expandtab set background=dark " colorscheme solarized " let g:ackprg = 'rg --vimgrep --type-not sql --smart-case' map ; : autocmd FileType javascript setlocal ts=2 sts=2 shiftwidth=2 但是没有go-vim写golang还是不太方便的,特别是保存的时候格式化,但是也有方案, 执行vim的Ex命令,:!go fmt % 视频 看视频是非常危险的行为,有可能需要强制关机重启。

2021-08-30 21:18:15 · 2 min · Eddie Wang

树莓派3b+踩坑记录

选择那个版本的系统? 不要过高的估算树莓派的性能,最好不要选择那些具有漂亮界面的ubuntu或者manjaro, 因为当你使用这些带桌面的系统时,很大概率界面能让你卡的想把树莓派砸了。 所以优先选择不带图形界面的lite版本的系统,如果确实需要的话,可以再安装lxde 网线插了,还是无法联网 插了网线,网口上的绿灯也是在闪烁,但是eth0就是无法联网成功。真是气人。 解决方案: 编辑 /etc/network/interfaces, 将里面的内容改写成下面的,然后重启树莓派。 这个配置文件的涵义是:在启动时就使用eth0有线网卡,并且使用dhcp给这个网卡自动配置IP auto eth0 iface eth0 inet dhcp iface etho inet6 dhcp source-directory /etc/network/interfaces.d 无桌面版本,如何手工安装桌面 首先安装lxde sudo apt update sudo apt install lxde -y 然后通过raspi-config, 配置默认从桌面启动 sudo rasip-config 选择系统配置, 按回车键进入 选择Boot/Auto login, 按回车进入 选择Desktop, 回车确认。保存之后,退出重启。 键盘无法输入| | 在linux中是管道的意思,然而我的键盘却无法输入。最终发现是键盘布局的原因。 在图标上右键,选择配置 注意这里是US, 这是正常的。如果是UK,就是英式布局,是有问题的,需要把UK的删除,重新增加一个US的。 如何安装最新版本的neovim? 树莓派使用apt安装的neovim, 版本太老了。很多插件使用上都会体验不好。所以建议安装最新版的neovim。 ...

2021-08-14 11:01:17 · 1 min · Eddie Wang

js sdk 跨层穿透问题

关于js sdk的设计,这篇文档基本上详细介绍了很多的点,值得深入阅读一遍。https://github.com/hueitan/javascript-sdk-design 然而最近在重构某个js sdk时,也发现了一些问题,这个问题并不存在于上述文章中的。 js sdk在收到服务端的响应时,直接将server端返回的错误码给到用户。 这里会有一个问题,这个响应码,实际上是js sdk和server之间的消息交流。并不是js sdk和用户之间的消息交流。 如果我们将server端的响应直接返回给用户,则js sdk可以理解为是一个透明代理。用户将会和server端产生强耦合。如果server端有不兼容的变化,将会直接影响到用户的使用。 所以较好的做法是js sdk将这个错误封装为另一个种表现形式,和server端分离出来。

2021-08-12 13:46:39 · 1 min · Eddie Wang

面向异常编程todo

程序可能大部分时间都是按照正常的逻辑运行,然而也有少数的概率,程序发生异常。 优秀程序,不仅仅要考虑正常运行,还需要考虑两点: 如何处理异常 如何在发生异常后,快速定位原因 正常的处理如果称为收益的话,异常的处理就是要能够及时止损。 能稳定运行364天的程序,很可能因为一天的问题,就被客户抛弃。因为这一天的损失,就可能会超过之前收益的总和。 异常应当如何处理 如果事情有变坏的可能,不管这种可能性有多小,它总会发生。《莫非定律》 对于程序来说,避免变坏的方法只有一个,就是不要运行程序(纯粹废话😂)。 1. 及时崩溃 var conn = nil var maxConnectTimes = 3 var reconnectDelay = 3 * 1000 var currentReconnectTimes = 0 var timeId = 0 func InitDb () { conn = connect("数据库") conn.on("connected", ()=>{ // 将当前重连次数重制为0 currentReconnectTimes = 0 }) conn.on("error", ReconnectDb) } func ReconnectDb () { conn.Close() // 如果重连次数大于最大重连次数,将不在重连 if currentReconnecTimes > maxConnectTimes { return } // 如果已经催在重连的任务,则先关闭 if timeId != 0 { cleanTimeout(timeId) } // 当前重连次数增加 currentReconnectTimes++ // 开始延迟重连 timeId = setTimeout(InitDb, reconnectDelay) } 2. 如何快速定位问题 第一,代码的敬畏之心 第二,及时告警。日志,或者http请求 第三,编程时,就要考虑异常。例如程序依赖 MQ或者Mysql,当与之交互的链接断开后,应该怎样处理? 第四,多实例问题考虑 第五,检查清单 ...

2021-08-05 08:58:30 · 1 min · Eddie Wang

监控pod重启并写日志文件

一般来说,监控pod状态重启和告警,可以使用普罗米修斯或者kubewatch。 但是如果你只想将某个pod重启了,往某个日志文件中写一条记录,那么下面的方式将是非常简单的。 实现的思路是使用kubectl 获取所有pod的状态信息,统计发生过重启的pod, 然后和之前的重启次数做对比,如果比之前记录的次数大,那么肯定是发生过重启了。 #!/bin/bash now=$(date "+%Y-%m-%d %H:%M:%S") log_file="/var/log/pod.restart.log" ns="some-namespace" echo $now start pod restart monitor >> $log_file # touch一下之前的记录文件,防止文件不存在 touch restart.old.log # 生成本次的统计数据 kubectl get pod -n $ns -o wide | awk '$4 > 0{print $1,$4}' | grep -v NAME > restart.now.log # 按行读取本次统计数据 # 数据格式为:podname 重启次数 while read line do # pod name name=$(echo $line | awk '{print $1}') # 重启次数 count=$(echo $line | awk '{print $2}') # 检查本次重启的pod名称是否在之前的记录中存在 if grep $name restart.old.log; then # 如果存在,则取出之前记录的重启次数 t=$(grep $name restart.old.log | awk '{print $2}') # 和本次记录的重启次数比较,如果本次的重启次数较大 # 则说明pod一定重启过 if [ $count -gt $t]; then echo $now ERROR pod_restart $name >> $log_file fi else # 如果重启的pod不存在之前的记录中,也说明pod重启过 echo $now ERROR pod_restart $name >> $log_file fi done < restart.now.log # 删除老的记录文件 rm -f restart.old.log # 将新的记录文件重命名为老的记录文件 mv restart.now.log restart.old.log 然后可以将上面的脚本做成定时任务,每分钟执行一次。那么就可以将pod重启的信息写入文件。 ...

2021-07-28 21:21:33 · 1 min · Eddie Wang

udp cluster 多进程调度策略学习

本来我的目的是使用cluster模块的fork出多个进程,让各个进程都能处理udp消息的。但是最终测试发现,实际上仅有一个进程处理了绝大数消息,其他的进程,要么不处理消息,要么处理的非常少的消息。 然而使用cluster来开启http服务的多进程,却能够达到多进程的负载。 server端demo代码: const cluster = require('cluster') const numCPUs = require('os').cpus().length const { logger } = require('./logger') const dgram = require('dgram') // const { createHTTPServer, createUDPServer } = require('./app') const port = 8088 if (cluster.isMaster) { for (let i = 0; i < numCPUs; i++) { cluster.fork() } cluster.on('exit', (worker, code, signal) => { logger.info(`工作进程 ${worker.process.pid} 已退出`) }) } else { const server = dgram.createSocket({ type: 'udp4', reuseAddr: true }) server.on('error', (err) => { logger.info(`udp server error:\n${err.stack}`) server.close() }) server.on('message', (msg, rinfo) => { logger.info(`${process.pid} udp server got: ${msg} from ${rinfo.address}:${rinfo.port}`) }) server.on('listening', () => { const address = server.address() logger.info(`udp server listening ${address.address}:${address.port}`) }) server.bind(port) } 日志库如下: ...

2021-07-21 12:57:03 · 4 min · Eddie Wang

使用nginx为udp服务负载均衡

对nginx的最低版本要求是? 1.9.13 The ngx_stream_proxy_module module (1.9.0) allows proxying data streams over TCP, UDP (1.9.13), and UNIX-domain sockets. 简单的配置是什么样? 例如监听本地53的udp端口,然后转发到192.168.136.130和192.168.136.131的53端口 注意事项 stream是顶层的配置,不能包含在http模块里面 proxy_responses很重要,如果你的udp服务只接受udp消息,并不发送udp消息,那么务必将proxy_responses的值设置为0 stream { upstream dns_upstreams { server 192.168.136.130:53; server 192.168.136.131:53; } server { listen 53 udp; proxy_pass dns_upstreams; proxy_timeout 1s; proxy_responses 0; error_log logs/dns.log; } } | Syntax: | proxy_responses number; Default: — Context: stream, server | This directive appeared in version 1.9.13. Sets the number of datagrams expected from the proxied server in response to a client datagram if the UDP protocol is used. The number serves as a hint for session termination. By default, the number of datagrams is not limited. If zero value is specified, no response is expected. However, if a response is received and the session is still not finished, the response will be handled. ...

2021-07-17 19:28:18 · 1 min · Eddie Wang

7月书单

6月书单回顾 《鳗鱼的旅行》刚读到92% 《Googler软件测试之道》100% 《软件测试之道微软技术专家经验总结》24% 《沉默的病人》100% 《一个人的朝圣》9% 《读懂发票》100% 《108个训练让你成为手机摄影达人》100% 《经济学通识课》5% 《楚留香新传》100% 7月书单 《鳗鱼的旅行》 《软件测试之道微软技术专家经验总结》 [KU]《一个人的朝圣》 [KU]《经济学通识课》 new 水浒传 [KU] new 围城 [KU] new 黄金时代 new 长安十二时辰 [KU] new 幻夜 new 软件开发本质论 [KU] new 苏东坡传 [KU] new 诡计博物馆 [KU] new 大师的盛宴 二十世纪最佳科幻小说 [KU] new 活出生命的意义

2021-07-08 12:34:59 · 1 min · Eddie Wang

Google软件测试之道(异步图书) James Whittaker; Jason Arbon; Jeff Carollo

Google软件测试之道(异步图书)James Whittaker; Jason Arbon; Jeff Carollo 序标注(黄色) - 位置 361从根本上说,如果测试人员想加入这个俱乐部,就必须具备良好的计算机科学基础和编程能力。变革标注(黄色) - 位置 367招聘具备开发能力的测试人员很难,找到懂测试的开发人员就更难,标注(黄色) - 位置 368但是维持现状更要命,我只能往前走。标注(黄色) - 位置 388我们寻找的人要兼具开发人员的技能和测试人员的思维,他们必须会编程,能实现工具、平台和测试自动化。第1章 Google软件测试介绍标注(黄色) - 1.1 质量不等于测试 > 位置 573Google能用如此少的专职测试人员的原因,就是开发对质量的负责。标注(黄色) - 1.1 质量不等于测试 > 位置 574如果某个产品出了问题,第一个跳出来的肯定是导致这个问题发生的开发人员,而不是遗漏这个 bug的测试人员。标注(黄色) - 1.2.1 软件开发工程师(SWE) > 位置 593软件开发工程师(标注(黄色) - 1.2.2 软件测试开发工程师(SET) > 位置 600软件测试开发工程师(标注(黄色) - 1.2.3 测试工程师(TE) > 位置 612TE把用户放在第一位来思考。 TE组织整体质量实践,分析解释测试运行结果,第2章 软件测试开发工程师书签 - 位置 784标注(黄色) - 位置 787Google的 SWE是功能开发人员; Google的 SET是测试开发人员; Google的 TE是用户开发人员。标注(黄色) - 2.1.1 开发和测试流程 > 位置 864测试驱动开发”标注(黄色) - 2.1.3 项目的早期阶段 > 位置 908一个产品如果在概念上还没有完全确定成型时就去关心质量,这就是优先级混乱的表现。标注(黄色) - 2.1.14 测试运行要求 > 位置 1398每个测试和其他测试之间都是独立的,使它们就能够以任意顺序来执行。标注(黄色) - 2.1.14 测试运行要求 > 位置 1399测试不做任何数据持久化方面的工作。标注(黄色) - 2.1.14 测试运行要求 > 位置 1400在这些测试用例离开测试环境的时候,要保证测试环境的状态与测试用例开始执行之前的状态是一样的。标注(黄色) - 2.1.14 测试运行要求 > 位置 1404总之,“任意顺序”意味着可以并发执行用例。标注(黄色) - 2.3 SET的招聘 > 位置 1650在一些棘手的编码问题或功能的正确性上浪费时间,不如考核他们是如何看待编码和质量的。标注(黄色) - 2.3 SET的招聘 > 位置 1727测试不应是被要求了才去做的事情。标注(黄色) - 2.3 SET的招聘 > 位置 1728程序的稳定性和韧性比功能正确要重要的多。标注(黄色) - 2.4 与工具开发工程师Ted Mao的访谈 > 位置 1796要允许他们使用你无法预料的方式来使用你的工具。标注(黄色) - 2.5 与Web Driver的创建者Simon Stewart的对话 > 位置 1845我使用了一个被称为 DDD(译注: defect-driven development)的流程,缺陷驱动开发。标注(黄色) - 2.5 与Web Driver的创建者Simon Stewart的对话 > 位置 1859Chrome在使用 PyAuto,第3章 测试工程师标注(黄色) - 3.1 一种面向用户的测试角色 > 位置 1879我们说 TE是一种“用户开发者( user-developer)”,这不是一个容易理解的概念。标注(黄色) - 3.1 一种面向用户的测试角色 > 位置 1880对于编码的敬意是公司文化中相当重要的一点。标注(黄色) - 3.2 测试工程师的工作 > 位置 1903在研发的早期阶段,功能还在不断变化,最终功能列表和范畴还没有确定, TE通常没有太多的工作可做。标注(黄色) - 3.2 测试工程师的工作 > 位置 1904给一个项目配备多少测试人员,取决于项目风险和投资回报率。标注(黄色) - 3.2 测试工程师的工作 > 位置 1906我们需要在正确的时间,投入正确数量的 TE,并带来足够的价值。标注(黄色) - 3.2 测试工程师的工作 > 位置 1908当前软件的薄弱点在哪里?标注(黄色) - 3.2 测试工程师的工作 > 位置 1909有没有安全、隐私、性能、可靠性、可用性、标注(黄色) - 3.2 测试工程师的工作 > 位置 1910主要用户场景是否功能正常?标注(黄色) - 3.2 测试工程师的工作 > 位置 1911当发生问题的时候,是否容易诊断问题所在?标注(黄色) - 3.2 测试工程师的工作 > 位置 1914TE的根本使命是保护用户和业务的利益,使之不受到糟糕的设计、令人困惑的用户体验、标注(黄色) - 3.2 测试工程师的工作 > 位置 1921TE擅长发现需求中的模糊之处,标注(黄色) - 3.2 测试工程师的工作 > 位置 1924TE通常是团队里最出名的人,因为他们需要与各种角色标注(黄色) - 3.2 测试工程师的工作 > 位置 1938下面是我们关于 TE职责的一般性描述。测试计划和风险分析。评审需求、设计、代码和测试。探索式测试。用户场景。编写测试用例。标注(黄色) - 3.2.1 测试计划 > 位置 1949如果软件深受人们喜爱,大家就会认为测试所作所为是理所应当的;如果软件很糟糕,人们可能就会质疑测试工作。笔记 - 3.2.1 测试计划 > 位置 1950测试背锅标注(黄色) - 3.2.1 测试计划 > 位置 1990读者可以用“ Google Test Analytics”关键词搜索到这个工具。标注(黄色) - 3.2.1 测试计划 > 位置 1991避免散漫的文字,推荐使用简明的列表。标注(黄色) - 3.2.1 测试计划 > 位置 1993不必推销。标注(黄色) - 3.2.1 测试计划 > 位置 1995简洁。标注(黄色) - 3.2.1 测试计划 > 位置 1996不要把不重要的、无法执行的东西放进测试标注(黄色) - 3.2.1 测试计划 > 位置 1998渐进式的描述( Make it flow)。标注(黄色) - 3.2.1 测试计划 > 位置 2001最终结果应该是测试用例。标注(黄色) - 3.2.1 测试计划 > 位置 20091. A代表特质( Attribute)标注(黄色) - 3.2.1 测试计划 > 位置 2010在开始测试计划或做 ACC分析的时候,必须先确定该产品对用户、对业务的意义。我们为什么要开发这个东西呢?它能带来什么核心价值?它又靠什么来吸引用户?记住,标注(黄色) - 3.2.1 测试计划 > 位置 20462. C代表组件( component)组件是系统的名词,在特质被识别之后确定。标注(黄色) - 3.2.1 测试计划 > 位置 2049组件是构成待建系统的模块,标注(黄色) - 3.2.1 测试计划 > 位置 20633. C代表能力( capability)能力是系统的动词,代表着系统在用户指令之下完成的动作。标注(黄色) - 3.2.1 测试计划 > 位置 2095能力最重要的一个特点是它的可测试性。标注(黄色) - 3.2.1 测试计划 > 位置 2098能力最重要的一个特点是它的可测试性。标注(黄色) - 3.2.1 测试计划 > 位置 2100一个能力可以描述任意数量的用例。标注(黄色) - 3.2.1 测试计划 > 位置 2130用一系列能力来描述用户故事,标注(黄色) - 3.2.1 测试计划 > 位置 2142确定 Google +的特质、组件和能力。标注(黄色) - 3.2.2 风险 > 位置 2193风险无处不在——标注(黄色) - 3.2.2 风险 > 位置 2202确定风险的过程称为风险分析。标注(黄色) - 3.2.2 风险 > 位置 22021.风险分析标注(黄色) - 3.2.2 风险 > 位置 2204这些事件发生的可能性有多大?一旦发生,对公司产生多大影响?一旦发生,对客户产生多大影响?产品具备什么缓解措施?标注(黄色) - 3.2.2 风险 > 位置 2206这些缓解措施有多大可能会失败?处理这些失败的成本有哪些?恢复过程有多困难?事件是一次性问题,还是会再次发生?影响标注(黄色) - 3.2.2 风险 > 位置 2209在 Google,我们确定了两个要素:失败频率( frequency of failure)和影响( impact)。标注(黄色) - 3.2.2 风险 > 位置 2214风险发生频率有 4个预定义值。罕见(标注(黄色) - 3.2.2 风险 > 位置 2217少见( seldom):标注(黄色) - 3.2.2 风险 > 位置 2221偶尔( occasionally):标注(黄色) - 3.2.2 风险 > 位置 2225常见( often):标注(黄色) - 3.2.2 风险 > 位置 2229测试人员确定每个能力的故障发生频率。标注(黄色) - 3.2.2 风险 > 位置 2230估计风险影响的方法大致相同,也是从几种偶数取值中选标注(黄色) - 3.2.2 风险 > 位置 2231最小( minimal):用户甚至不会注意到的问题。标注(黄色) - 3.2.2 风险 > 位置 2234一些( some):可能会打扰到用户的问题。一旦发生,重试或恢复标注(黄色) - 3.2.2 风险 > 位置 2237较大( considerable):故障导致标注(黄色) - 3.2.2 风险 > 位置 2240最大( maximal):发生的故障会永久性的损害产品的声誉,并导致用户不再使用它。标注(黄色) - 3.2.2 风险 > 位置 2267风险不大可能彻底消除。驾驶有风险,但我们仍然会开车出行;旅游有风险,但我们并没有停止旅游。标注(黄色) - 3.2.2 风险 > 位置 2285在软件开发中,任何一种可以在 10分钟之内完成的事情都是微不足道的,或是本来就不值得做的。标注(黄色) - 3.2.2 风险 > 位置 2323风险分析是一个独立的领域,在许多其他行业里被严肃地对待。我们现在采用的是一个轻量级的版本,标注(黄色) - 3.2.2 风险 > 位置 2325风险管理方法),这可以作为进一步学习这一重要课题的起点。标注(黄色) - 3.2.2 风险 > 位置 2328TE有责任理解所有的风险点,并使用他或她可以利用的任何手段予以缓解。标注(黄色) - 3.2.5 TE的招聘 > 位置 2668他们只是在试图破坏软件,还是同时在验证它能正常工作?标注(黄色) - 3.2.5 TE的招聘 > 位置 2717我们需要的是愿意持续学习和成长的人。我们也需要那些带来新鲜思想和经验的人,标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特(Lindsay Webster)的访谈 > 位置 3301对于一个新项目,我首先要站在用户的角度了解这个产品。有可能的话,我会作为一个用户,以自己的账户和个人数据去使用产品。我努力使自己经历完整的用户体验。一旦有自己的真实数据在里面,你对一个产品的期待会彻底改变。在具备了用户心态之后,我会做下面的一些事情。标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特(Lindsay Webster)的访谈 > 位置 3362遗漏到客户的 bug是一项重要指标,我希望这个数字接近 0。标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特(Lindsay Webster)的访谈 > 位置 3377或者用户场景无需编写、自动到位。 CRUD操作(译注: create、 read、 update、 delete)标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特(Lindsay Webster)的访谈 > 位置 3385团队在推出一个产品或新功能时难免感到提心吊胆,而我能带给他们镇定和信心,这使我感到自己是一种正面、有益的力量。标注(黄色) - 3.4 与YouTube测试工程师安普·周(Apple Chow)的访谈 > 位置 3416而 Google的 SET必须写代码,这是他们的工作。这里也很难找到不会写代码的 TE。标注(黄色) - 3.4 与YouTube测试工程师安普·周(Apple Chow)的访谈 > 位置 3426Google的测试与其他公司的相同之处呢? Apple:在测试上难以自动化的软件,很难成为好的软件。标注(黄色) - 3.4 与YouTube测试工程师安普·周(Apple Chow)的访谈 > 位置 3493不管是测试框架还是测试用例都以简单为要,随着项目的开展再迭代的设计。不要试图事先解决所有问题。要敢于扔掉过时的东西。第4章 测试工程经理标注(黄色) - 4.8 搜索和地理信息测试总监Shelton Mar的访谈 > 位置 3989把测试推向上游,让整个团队(开发 +测试)为交付的质量负责。标注(黄色) - 4.8 搜索和地理信息测试总监Shelton Mar的访谈 > 位置 4025从那以后,我们把配置变更也纳入质量流程中,我们开发了一套自动化测试,每次数据和配置变更时都要执行。标注(黄色) - 4.11 工程经理Brad Green访谈 > 位置 4219Google聘用的都是有极端自我驱动力的家伙。“标注(黄色) - 4.12 James Whittaker访谈 > 位置 4339先虚心学习,再在一线作出成绩,然后开始寻求创新的方法。第5章 Google软件测试改进标注(黄色) - 位置 4398Google的测试流程可以非常简练地概括为:标注(黄色) - 位置 4398让每个工程师都注重质量。标注(黄色) - 位置 4398只要大家诚实认真地这么做,质量就会提高。代码质量从一开始就能更好,标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4408可是测试并不能保证质量。质量是内建的,而不是外加的。因此,保证质量是开发者的任务,标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4409测试成了开发的拐杖。我们越不让开发考虑测试的问题,把测试变得越简单,开发就越来越不会去做测试。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4415保证质量不但是别人的问题,它甚至还属于另一个部门。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4416出问题的时候也很容易就把责任推卸给修前草坪的外包公司。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4426第三个致命的缺陷,是测试人员往往崇拜测试产物( test artifact)胜过软件本身。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4430所有测试产物的价值,在于它们对代码的影响,进而通过产品来体现。标注(黄色) - 5.2 SET的未来 > 位置 4447简单来说,我们认为 SET没有未来。 SET就是开发。就这么简单。标注(黄色) - 5.2 SET的未来 > 位置 4450SET直接负责很多功能特性,如可测试性、可靠性、可调试性, ...

2021-07-08 09:03:07 · 4 min · Eddie Wang

沉默的病人(世界狂销300万册的烧脑神作!多少看似完美的夫妻,都在等待杀死对方的契机)

沉默的病人(世界狂销300万册的烧脑神作!多少看似完美的夫妻,都在等待杀死对方的契机)亚历克斯·麦克利兹 第二部分 PAPT TWO标注(黄色) - 9 > 位置 1294选择自己所爱的人就像选择心理治疗师,”鲁思说,“我们有必要问自己,这个人会不会对我忠诚,能不能听得进批评,标注(黄色) - 9 > 位置 1295承认所犯的错误,而且做不到的事情决不承诺?”第三部分 PAPT THREE标注(黄色) - 位置 2577虽然我生来不是个好人,有时我却偶然要做个好人。——威廉·莎士比亚《冬天的故事》[

2021-07-08 08:58:49 · 1 min · Eddie Wang