CI（継続的インテグレーション）超入門：Jenkinsのススメに参加してきました！ | DevelopersIO
こんにちは！おおはしりきたけです！ 10月13日(水)に豆蔵さんで行われた豆ナイトのCI（継続的インテグレーション）超入門：Jenkinsのススメ」に参加してきました！ イベントURL：http://kokucheese.com/event/index/18660/ ＝＝＝ アジェンダ ＝＝＝＝ １．はじめに ２．「ビルドを料理するコツ ３．「CI超入門：Jenkinsのススメ」 ４．「CIツールの紹介」 ５．「ディスカッション」 19時開始だったのですが、若干遅刻してしまったため、一部聞けませんでしたorz。 １．はじめに 豆蔵の羽生田栄一さんからのお話でしたが、遅刻のため聞けませんでした。 ２．「ビルドを料理するコツ ここの途中から参加したので、一部足りないです。 概要：ソフトウェアのビルドに関する基本的な知識を導入します。 発表者：Microsoft Office Linguisti
テスト計画の立案
メディア 記事一覧 オルタナティブ・ブログ 用語辞典 ITmedia エンタープライズ テスト計画の立案：開発プロセス再入門（7）（2/2 ページ） » 2004年10月27日 12時00分 公開 [津田義史（豆蔵），＠IT] 前のページへ 1|2 前のページへ 1|2 Copyright © ITmedia, Inc. All Rights Reserved. SpecialPR 検索 SpecialPR 注目のテーマ 人気記事ランキング 「VMwareは20年前のテクノロジーの寄せ集め」Broadcomトップのコメントに見るITインフラの今後 「失敗は許されない」は時代遅れ ガートナーが示す新しいセキュリティの考え方 自社用LLM構築にむけて RAG評価ってどうやればいいの？ 最新フレームワーク「Auepora」をチェック なぜ、AIの社内活用は進まないのか？ PwC調査で判明した「コ
Software test documentation - Wikipedia
Status of IEEE 829[edit] Note: IEEE 829-2008 has been superseded by ISO/IEC/IEEE 29119-3:2013.[1] Background to IEEE 829[edit] IEEE 829-2008, also known as the 829 Standard for Software and System Test Documentation, was an IEEE standard that specified the form of a set of documents for use in eight defined stages of software testing and system testing, each stage potentially producing its own sep
ソフトウェアテストの基礎：ソフトウェアテストの7原則 | Knowledge Note
ソフトウェアテストという技術分野の持つ７つの原則「テストは欠陥があることしか示せない」「全数テストは不可能」「初期テスト」「欠陥の偏在」「殺虫剤のパラドックス」「テストは条件次第」「バグゼロ」の落とし穴」についての紹介と、それぞれの原則に対して実際に現場ではどのような対策を取れば良いのかを考察します。 ソフトウェアテストの「基礎」を考えるとき、どのようなアプローチがあるでしょうか。テストの設計、実装の「技法」を学ぶ、テストを開発する「プロセス」を学ぶ、開発プロジェクトにおけるテストの「役割、価値」を学ぶ、あるいはテストチームの運営方法を学ぶ、などさまざまなアプローチが存在し、そのどれも誤りとはいえません。そこで本連載では複数存在するソフトウェアテストの「基礎」へのアプローチを適宜取り上げていきます。 その第1回目として、これまでなんとなくテストに接してきた方にとっては新鮮、かつ考えさせられ
日本語テストメソッドについて
14. ASP.NET MVC の例 ※MvcHtmlStringTest.cs [Fact] public void ToStringReturnsEmptyStringIfOriginal StringWasNull () { // Null から MvcHtmlString インスタンスを // 生成した時、ToString() が // String.Emptyを返すことを確認しています } 16. Entity Framework の例 ※DatabaseInitializerTests .cs [Fact] public void DropCreateDatabaseIfModelChanges_throws_if_database_e xists_and_model_does_not_match_with_Migrations_enable d() { // DB マイグレー
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
コードカバレッジのまとめ - ソフトウェアテストの勉強室
単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。 2008/03/12更新 サンプルプログラムで解説を追加 サンプルプログラムは、以前例題として作成したテニスのスコアボードについて [例題]テニスのスコアボード ステートメントカバレッジ 命令網羅。テスト対象となるプログラム中のステートメント（命令文）をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基本的なカバレッジ基準で
テストケースの「正常系/異常系」というカテゴライズについて - ソフトウェアテストの勉強室
ソフトウェアテストには7つの原則(*)があって、そのひとつに「テストは欠陥があることしか示せない」という原則がある。これはどういうことかというと、テストというプロセスでは「不具合がない」ことは示せない、示せるのは「不具合がある」ことだけだ、ということを意味している。つまり、テストの目的＝不具合を見つけ出すことなので、より多くの不具合を見つけられるテストケースが優秀といえる。 テスト仕様書に「正常系/異常系」のカテゴライズは必要？ by クライングドーベルマン 第三者テスト、とかソフトウェアテスト専門部隊、に属する僕個人の意見としては、「正常系/異常系」のカテゴリーはテスト仕様書には特に必要ないように感じる。多分、「正常系/異常系」というカテゴリーはテスト実行の優先度として使用する目的で設定していると思うが、「とりあえず正常系から先にテストする」という戦略は時として重大なテスト漏れを発生させ
fluentd の output plugin のテストのかきかた
fluentd のプラグインのテストで、他のoutputも利用するタイプのプラグインはどうテストするのかなあと思ってしらべてみた。@tagomoris さんの out_forest はちゃんとテストが存在したのでそれを読む事に。 https://github.com/tagomoris/fluent-plugin-forest/blob/master/test/plugin/test_out_forest.rb#L416 まず fluentd のプラグインのテストの書き方から理解していないので理解しなければ、と 公式ドキュメント を読むと: Please see Fluentd’s source code for details. うっ、はい… まず前準備に Fluent::Test.setup を呼ばないといけないっぽい。これ、engine.rb に書いてある所為でgrepしないと見つか
Microsoft PowerPoint - JaSST四国100702.ppt
© NISHI, Yasuharu 第三世代に突入したソフトウェアテスト ソフトウェアテストシンポジウム四国 2010 2010/7/2（金） 電気通信大学 大学院 情報理工学研究科 総合情報学専攻 経営情報学コース 西 康晴 © NISHI, Yasuharu 2 自己紹介 • 身分 – ソフトウェア工学の研究者 » 電気通信大学 大学院 情報理工学研究科 総合情報学専攻 経営情報学コース » ちょっと「生臭い」研究／ソフトウェアテストやプロセス改善など – 先日までソフトウェアのよろず品質コンサルタント • 専門分野 – ソフトウェアテスト／プロジェクトマネジメント ／ＱＡ／ソフトウェア品質／ＴＱＭ全般／教育 • 共訳書 – 実践ソフトウェア・エンジニアリング／日科技連出版 – 基本から学ぶソフトウェアテスト／日経ＢＰ – ソフトウェアテスト293の鉄則／日経ＢＰ • もろもろ – T
実践！テスト自動化の勘所
システム開発において、安定稼働を支えるシステム品質の鍵を握るソフトウエアテスト。システムの大規模化や複雑化、デバイスの多様化などによってその作業負担は増える一方だ。手作業に頼ったテストが、結果としてシステムの品質低下や開発工期の増大を招く。ソフトウエアテストの専門家が、ツールを用いたテスト自動化のポイントを解説する。 テスト自動化とツールの導入
Rails API Testing Best Practices · Matthew Lehner
Something went wrong! Hang in there while we get back on track Writing an API is almost a given with modern web applications. I’d like to lay out some simple guidelines and best practises for Rails API testing. We need to determine what to test and why it should be tested. Once we’ve established what we will be writing tests for, we will set up RSpec to do this quickly and easily. Basically we’ll
これぞテストの最終形態！FitNesseとRubySlimで実現するエンドツーエンドテスト
FitnesseとRubySlimを使ってでエンドツーエンドを書いてみました。 なんどもおんなじネタで恐縮だけれども、FitNesseとRubySlimを利用して、エンドツーエンドを実装してみました。 この記事は、以下の記事の延長になります。 組込み開発のシステムテスト・機能テストを自動化できるか?Rubyのminitestで非同期テストを実施する方法を本気出して考えてみた | Futurismo ミライの組込み開発！vagrant × sahara × minitestで実現する仮想エンドツーエンドテスト | Futurismo teratermマクロで自由自在にエンドツーエンドを書く！TTLのためのxUnitフレームワーク「TTLUnit」 | Futurismo FitNesse テストケースの用意# まずは、テストケースのページの作成です。 RubyのAPIレベルのテストを直叩きで
第10回 莫大なテスト工程を効率化、最適なツールの導入で効率を上げミスを減らす
第10回 莫大なテスト工程を効率化、最適なツールの導入で効率を上げミスを減らす ソフトウエア開発の自動化（4）テスト設計の自動化 テスト工程では、ソフトウエアの実行やソースコードの検証を行います。この作業を通じて、システムが正しく意図した通りに動作するのかを確認し、ソフトウエアに潜むバグを発見します。 テストは、システムの納品前に品質を確保する非常に重要な作業ですが、単調で地道な作業をコツコツとこなしていく必要があります。 その一方でテストは、非常に多くの作業工数を要します。システムの規模や種類にもよりますが、システム開発に関わる工数のうち、一般的におよそ4割がテストに費やされているといわれています。このため、テストの効率化は開発全体の効率化に非常に大きく寄与します。 テスト自動化で効率を上げ品質を高める テスト工程に自動化ツールを活用することにより、単調なテストの作業を効率化できるだけで
ツールを使っていない理由
今回の調査で明らかになったのは、テストツールの利用率は低いものの（前々回記事）、テストツールを利用している人の満足度は高い（前回記事）ということだ。では、なぜテストツールは使われないのだろうか――。 その理由を明らかにするために、テストツールを使っていない人にその理由を聞いている。単体テスト/結合テスト/システムテストツールのそれぞれで使わない理由を聞いたところ、1位～3位はいずれも同じ。1位は「導入コストが高い」、2位は「手作業で行った方が早い」、3位は「どんなツールがあるのか知らない」であった（図1、図2、図3）。
テストと検証の違いってなに？ - OKWAVE
SLCP(SLCP-JCF98)の用語で言うなら 検証 ---->検証 テスト---->妥当性確認 だと思いますが、それら２つはそれぞれ 検証： 設計・開発プロセスでの結果が、設計・開発プロセスのスタートのところで必要と判断された要求事項を 満たしているかどうかを確認することが検証。 妥当性確認： 客観的証拠を提示することによって，特定の意図された用途又は適用に関する要求事項が満たされていること を確認すること。 難しく書いていますが、客観的証拠を提示するとは、テスト結果を示すことと解釈していいと思います。 また、 妥当性確認については、最終製品・サービスが、実際に顧客のニーズを満足させる能力を備えているか、 または実際に顧客ニーズ・期待に合致しているかどうかを確認するプロセスということになります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
Pixelhandler's blog
テストを書くことの重要性 | tbaba
https://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf