Keep a Changelog
Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
3. Declaring repositories
Gradle User Manual Getting Started Gradle Tutorials Beginner Tutorial 1. Initializing the Project 2. Running Tasks 3. Understanding Dependencies 4. Applying Plugins 5. Exploring Incremental Builds 6. Enabling the Build Cache Intermediate Tutorial 1. Initializing the Project 2. Understanding the Build Lifecycle 3. Multi-Project Builds 4. Writing the Settings File 5. Writing a Build Script 6. Writin
アセンブリと DLL の名前 - Framework Design Guidelines
注 このコンテンツは、 フレームワーク設計ガイドライン (再利用可能な .NET ライブラリの規則、イディオム、パターン、第 2 版) から、Pearson Education, Inc. のアクセス許可によって再印刷されます。 そのエディションは2008年に出版され、その後 、本は第3版で完全に改訂されています。 このページの情報の一部が古くなっている可能性があります。 アセンブリは、マネージド コード プログラムの展開と ID の単位です。 アセンブリは 1 つ以上のファイルにまたがることができますが、通常、アセンブリは DLL を使用して 1 対 1 でマップします。 したがって、このセクションでは DLL の名前付け規則のみを説明し、アセンブリの名前付け規則にマップできます。 アセンブリ DLL の名前は、System.Data のように大きな機能を示すものを選んでください。 アセ
テスト消化曲線とバグ発生曲線の7パターン診断
今回は、Gompertz Curveによる「プロジェクトの問題点解析」について詳しく解説。あなたの開発現場はどのパターンに当てはまる？ 前回のコラム「最もタチの悪いバグが潜むテストフェイズとは？」では、7つの「基本的な出荷基準」を挙げ、「5．長時間耐久テスト、過負荷テストを実施した」について解説しました。今回はその続きとして、「6．バグの発生が頭打ちになった」を紹介します。 まずは、7つの基本的な出荷基準について再掲します。 全機能をテストした ブラックボックス／ホワイトボックス・テストで同値分割を実施した。 境界条件をテストした ブラックボックス／ホワイトボックス・テストの境界値分析を実施した。 未実行コードがない ホワイトボックス・テストのC0パス網羅を満足した。 エラー・ゲシング（Error Guessing）を実施した バグを想定し、それを摘出するためのテスト項目を設計・実施した。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
