Raspberry Piは本当に壊れやすいのか
最近「Raspberry Piはすぐ壊れる」という趣旨の話題がTL上に出てきたので複雑な心境で眺めていました。 (以下簡略化のためRaspberryPi = RPiにします) もし「RPiはすぐ壊れるから製品投入に向いてない」と思っている方がいるのであれば、その理由でRPiを切ってるのはもったいないなぁと思いこの記事を書いてみました。 カンタンに自己紹介をしておくと、某社でRPiをベースにした製品を作り「RPiはすぐ壊れないものなのか？」の検証を進めていました。今では各地で5000台以上は動いてると思います。 ざっと書いたので、あまり技術的に詳しいことは書いてませんが、読み物として楽しんでもらえれば幸いです。 （これらテストをしたのがどのバージョンのRPiなのかについては触れません。読者さんが使いたいと思ったRPiでで気になる部分をテストしてもらうことが良いと思っています） 10,000回
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
動的型言語は静的型言語に比べてテストが増えるのか？
自分も合っているかどうか分からない話で、それなりに重要だと思うので編集自由でまとめてみます。 とりあえずは、自分とmakotokuwataさんのTLをRT含めてまとめてみました。 時間順なので多少会話が前後します。 他の人の意見が聞いてみたいので、含めるべきツイートがある場合は自由に追加してください。
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
北陸新幹線の試験走行にはどうして「ふた冬」が必要なのか？
現在は長野までが開業している北陸新幹線ですが、既に長野から飯山、上越、糸魚川、新黒部、富山、新高岡を経て金沢まで（一部の駅名は仮称）の延伸区間に関しては、ほぼ土木工事が完成しています。レールの敷設もほとんど完了しており、残る主要な工事としては電化関係の設備と駅舎の整備を残すだけです。 また東京から金沢までの直通運転を担う新型車両のＥ７・Ｗ７系の車両もデザインと諸元が発表になっており、今年、2013年の秋には第一弾の編成が落成する予定になっています。内外装に「和」のコンセプトを取り入れたデザインは、既に好評を博しているようです。 では、肝心の開業時期はいつになるのでしょうか？ 一部には開業の前倒しを望む声もありましたが、現時点では長野＝金沢間の開業は14年末、つまりおそらくは15年の３月になるという計画です。 一見すると奇妙な話です。土木工事はほぼ完了し、新造車両もドンドン完成するのであれば
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
@yohei さんの品質についての考え
YAMAMOTO Yohei @yohei まず、テストって言葉は広いからうまくどの「テスト」について話しているのかを切り分けないと混乱しますね。特に開発者テストといわゆる品質保証的なテストとが混乱すると悲劇。そういう意味でTDDって言葉は功罪あったと思う 2011-12-21 06:12:44 YAMAMOTO Yohei @yohei 僕がブックマークでコメントしたプロセスを強化する方向が楽だからというのは、何か問題が起きたときの対策として、その原因を突き止めてそれが再発しないことをプロセスに落としこむの方が楽だからという意味です 2011-12-21 06:15:31 YAMAMOTO Yohei @yohei もちろんプロセスの強化が必要な場合もある。でもそれってものすごく基本的なプロセスが間違っていたとか、ひどいミスが多発した場合に必要なことであって、プロセスの強化だけで何か解決
銀行などの信用機関の83パーセントが本物の個人データをシステムのテスト用に用いている - Cyberlaw
銀行が新しいデータベースシステムやATMシステムなどを構築した場合，そのシステムが正常に稼動するかどうかを何らかのデータを用いて何度もテストしてみなければならない。ところが，例えば，個人情報（個人データ）を含むデータを開発中のシステムの試験運用で処理させるということは，個人情報（個人データ）を適正に処理することができるかどうかがまだ確認されていないシステムで本物の個人情報（個人データ）を処理するということになるから，形式論としては，個人情報（個人データ）を適正に扱っていないという結論にならざるを得ない。このことは以前から指摘されていたことではあるが，現実にどれくらいの割合で実データを用いたテストが実施されているのかについて正確な統計等が存在しているわけではない。 Dark Readingを読んでいたら，この点に関する調査結果が公表されたということを知った。調査対象が限定されているのだけれど
テストの重要性が認識されてないのだよなぁ - ただのにっき(2009-01-16)
■ テストの重要性が認識されてないのだよなぁ IDEA*IDEAに300億のボタンという記事が出ていて、ようするに「ECサイトのフォームを改善したら売上が年間300億円も増えた」という話。 改善の内容はありがちというか、いまどきECサイト作るなら常識に入る部類のものなので、「まぁ(300億という)数字はすごいけど今さらねぇ」と思ってみていたら、はてブ数が300近いの。しかもコメントの多くが「ボタン」のことばかり。 違うでしょ。 個別の改善例なんて条件次第でいくらでも良し悪しが変わるんだから、どうでもいい。この話で一番大切なのは、「何も問題がないと思い込んでいた」ウェブデザイナたちに、ユーザビリティテストという「証拠」を突きつけて改善させたというところだよ。 アクセス解析やユーザビリティテストで、作る側の「思い込み」がひっくり返される例は山ほどある。Firefoxにアドオンを山ほど入れて、新
Webの負荷テストに使えるフリーソフトウェア | OSDN Magazine
Webアプリケーションおよびサーバの高負荷時の挙動を確認する方法の1つが、擬似的に負荷をかけてテストを行うことだ。ここでは、そうしたテストを実施するフリーソフトウェアをいくつか試し、それぞれがどんなタイプのサイトに適しているかを調べた。 負荷テスト用のツールはいろいろあるが、メンテナンスが行われていないもの、フリーでないもの、インストール手順が明確でないものを除くと、curl-loader、httperf、Siege、Tsung、Apache JMeterの5つが候補として残る。 JMeterについては、すでにDaniel Rubio氏が取り上げているので、ここでは詳しく説明しない。ただし、最後のまとめでほかのツールと共に簡単に触れている。 curl-loader curl-loaderは、「SpirentのAvalancheやIXIAのIxLoadの代替として使える強力かつ柔軟なオープン
[ThinkIT] 第5回：複数人での開発におけるテストの勘所 (1/3)
これまで解説してきたように、ウノウでは各々の開発者の開発環境で慎重に組み上げられたソースコードをSubversionで管理された統一の開発環境にそれぞれコミットし、リリースに向けて足並みを揃えながらシステムテストを実施します。 ウノウではテスト専門の担当者が在籍しており、開発者とは違った視点から成果物のチェックを行う体制を整えています。今回はその実践事例を紹介しながら、複数人での開発におけるテストの勘所について解説していきます。 テスト工程はプロダクトの品質を確保するために欠かせないフローの1つです。組み上げられたばかりのソースコードは、まだ完成度が客観的に保証されていない状態であり、開発者のスキルに対する信頼によってのみ「完成した」と推測されるものでしかありません。極端にいえば、いざ蓋を開けてみたら動かなかったということもあり得るのです。 自社プロダクトの開発がほとんどであれば、問題が発
ウノウラボ Unoh Labs: WEBアプリのテストに必須なツール７種
こんにちは！やまもと＠テスト番長です。 前回satoさんの書いたエントリーが好評のようですね。 自分は実は美術系出身です。なので「デザインセンスのある人からみた～」というエントリーでも続けて書いちゃおうかなと一瞬思いましたが、世の中にはWEBデザインのプロの方もいらっしゃることだし、控えておきましょう。 センスってのも考え込むと難しいですしね。 個人的には、WEBデザインの美醜って「使いやすさ」とかなり直結な気がしてます。 さて、今回は僕が普段テストに使っているツールでもご紹介してみようかと思います。 Selenium 一年前くらいに登場した無償の自動実行ツールです。 有償の自動実行ツールは以前からありましたが、 ベンチャーが購入するには高価なものなので 大手以外にはあまり導入されていなかったであろう類のツールです。 テストシナリオにそってブラウザを自動で操作してくれます。
ウノウラボ Unoh Labs: 「２流のテスター」は要らない！(2)
こんにちは！ やまもと＠テスト番長です。 その1を書いてから間が空いてしまいました。 No More Second Class Testers! という面白いコラムを、引き続きご紹介しましょう。 なぜ１流のテスターでなければいけないか テスターは商品開発における重要な役割を果たします。 テスターは開発中の製品の情報とテストに関する情報を提供します。 テスターには少なくとも3種類の相手（客）がいます。 ・開発者には、分かりにくい箇所、テスタビリティ、そして動作しない箇所について報告します。 ・ユーザーには、サポート係を通して製品の情報を提供します。 ・開発マネージャーには、リリースのリスクについて情報を提供します。 １流のテスターは、コードが書かれている前にシステムのデザインとアーキテクチャを評価することができるくらいクリエイティブです。 コーディングが進む間、テストの準備を整えます
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
