2014年6月30日月曜日

ほりえもん

( 投稿「ブログに画像転用で気になった」(2014/0715)で引用での注意事項に合わせて内容を一部修正しました)

2014年6月26日木曜日

スティーブジョブズ

( 投稿「ブログに画像転用で気になった」(2014/0715)で引用での注意事項に合わせて内容を一部修正しました)

2014年6月24日火曜日

Internet Explorerの調子が悪くなったら試すべき対処法

表示が遅い、正常に動作しない――。
Internet Explorerの使用時に直面するこうしたトラブルの対処方法をまとめてみました。

1. 閲覧履歴データを削除する
IEのキャッシュやcookie、関連オフラインファイルを削除する。
【手順】
「ツール」メニューから利用できる「インターネットオプション」の「全般」タブにある「閲覧の履歴」セクションで、「削除」を選択すると表示する「閲覧の履歴の削除」というダイアログボックスで、削除できる。
なおツールメニューは、IEウィンドウの右上隅の歯車アイコンをクリックしても開く。

2. 一時ファイルの場所を変更する
【手順】

インターネット一時ファイルの場所をデフォルトの「C:Users<ユーザー名>AppDataLocalMicrosoftWindowsTemporary Internet Files」から異なるドライブへ移すことを考えるとよい。

3. マルウェアや拡張機能を疑う
マルウェア対策ソフトを導入済みでも、それと共存可能なマルウェア対策ソフトを追加で実行すると効果的な場合がある。
またツールメニューから利用できる「アドオンの管理」ダイアログボックスで、どのツールバーや拡張機能がインストールされ、有効になっているかをチェックするとよい。
サードパーティー製や独自開発のツールバーやブラウザヘルパーオブジェクト、ActiveXコントロールは、いずれもIE 10が奇妙で不安定な動きをする原因になることがある。不審なものは遠慮せずに全て無効にする。
ただし、そうすると、特定のWebサイトやWebアプリケーションの機能が使えなくなる可能性がある。そのため、必要な場合は元に戻せるように、何を無効にしたかを覚えておこう。
※マルウェア (malware) とは、不正かつ有害な動作を行う意図で作成された悪意のあるソフトウェアや悪質なコードの総称である

4. タブのロード状況を確認する
タブの数やメモリ使用量と、システム全体のパフォーマンスには、直接的な相関関係がある。

5. 「F12開発者ツール」を利用する
IE 10が内蔵する「F12開発者ツール」は、WebブラウザとWebページの問題を解消するための補助ツールだ。IEの起動後にキーボードの「F12」キーを押すだけで、セッションのcookieの表示や操作、ポップアップウィンドウの無効化、ユーザーエージェント文字列の変更など、さまざまな作業ができるようになる。

6. ポリシーを確認する
 セキュリティポリシーがIE 10の機能に影響を与えることもある。ローカルセキュリティポリシー設定を確認するには、「gpedit.msc」(ローカルグループポリシーエディタ)を実行し、「コンピュータの構成」または「ユーザーの構成」から、「管理用テンプレート」「Windowsコンポーネント」「Internet Explorer」の順に選択する。

ドメインレベルのグループポリシーも調べておこう。「新しいポリシーが最近プッシュされたか」「変更できる要素や無効にできる要素があるか」といったことが確認すべきポイントだ。不確かなときは、コマンドプロンプトで「gpupdate」と入力してローカルポリシーを更新するなどの手段を取る。

7. 自動更新を無効化する
「Windows Update」や「Windows Server Update Services(WSUS)」をはじめとするパッチ管理ツールが、特定の機能(特に、IEに大きく依存するWebアプリケーションの機能)を破壊するIE用修正プログラムをプッシュする場合もある。IE 10では、新バージョンの自動インストールが可能になっている。

8. 設定を完全にリセットする
以上の対処をしてもIE 10のトラブルシューティングがうまくいかないときは、IE 10の設定を完全にリセットすべきだ。インターネットオプションのダイアログボックスにある「詳細設定」タブで、設定の復元や全ての設定のリセットが簡単にできる。

なお、「Firefox」のような別のWebブラウザへの完全な乗り換えも選択肢の1つとなる。

2014年6月23日月曜日

プログラムテストについて

最近プログラムテスト仕様書を書くことが多くなってきました。
メモとして、テスト報告書についてまとめてみました。

テストってどんなことがあるか?。
①単体テスト……プログラミングの成果を検査するテスト
②結合テスト……内部設計の仕様を満たしていることを確認するテスト
③システムテスト……外部設計の仕様を満たしていることを確認するテスト
④運用テスト……要件定義を満たしていることを確認するテスト
これらのテストのうち、顧客に関係するのは「運用テスト」となる。

2、顧客にとって良いテスト仕様書とは
顧客にとってテスト仕様書は、「要件定義書で決めた事項が満たされたシステムになっているかどうか、導入前にチェックして確認するための文書」となる。
顧客側は、主に下記のようなことを確認しますので、確認事項を考慮してテスト仕様書を作成しなければなりません。
機能や性能が要求どおりの品質になっていること
使い勝手や、ユーザーインターフェイスが業務作業に支障ないこと
システムを導入するメリット(業務効率の改善、導入前より業務作業がやりやすくなるなど)が達成されていること

従いまして、顧客にとって良いテスト仕様書とは、これらの確認するために、「システムがきちんと完成していることが簡単に確認できる文書」となります。
また、テスト仕様書は、開発側の視点と顧客の視点、両方から見て満足できるものにしなければなりません。
つまり、「このテスト項目は、要件定義書のどの定義事項を確認するためのものか」、参照しやすくドキュメントにしましょう。

3、テスト項目はどのようなことを記述するか
テスト仕様書を分かりやすくするためには、先頭に「テスト概要」を記述します。
概要は、いわゆる5W1Hを念頭に記述します。
What:何をテストするのか=顧客に納入するシステム
Why:何のためのテストであるのか=要件定義書で定義した事項を確認するため
When:運用テストの時期やスケジュール
Where:運用テストを行う場所や環境(顧客の業務環境を使ってテストするケースもある)
Who:テストを実行する担当者(顧客の業務担当者にお願いするケースもある)
How:運用テストのやり方。顧客に提供する操作マニュアルに記述された手順に従ってテストを実行する場合は、その旨を記述する

テスト仕様書の終わりには、まとめの報告(「テスト結果(結論)」)を記述します。
まとめの報告は、テストが完了しているのであれば、テスト結果に問題がないことを報告すればよいだけです。
テスト中に検出したバグの修正が完了せず、未解決のバグが残ってしまったテスト項目が存在する場合、バグが修正できなかったテスト項目ごとに、次のような事項を記述します。
・問題の原因・理由
・システムのどの機能や性能に、どのような影響があるのか
・どのような方針で、どのような対応をするのか
・どのような方法で改善するのか
・いつまでに対応するのか
・もし改善が顧客の稼働開始に間に合わないのであれば、バグを避けながら同等の機能・性能を確保できるような代替の手段や手順を記述します。

その他、実際に、テスト仕様書に記述すべきものとして、以下の事項があります。
 3.1.テストを実施した環境(テスト環境)
ここで必要なのは、「要件定義書で規定した環境」でテストする。
要件定義書が規定した環境でテストした場合は、そのことを明記したうえでテスト環境を具体的に記述します。要件定義書の環境と異なる環境(例えば、簡易化した環境)でテストした場合は、以下の点に留意する必要があります。
・テストを実施した環境を具体的に明示する
・テスト実施環境と業務遂行時の環境との差異を明確にする
・両者の差異はシステムの動作に影響を与えないと断言する

例えば次のように記述して、テスト実施環境が納得できるものであること記述します。
--------------------------------------------------------------
テストを実施したシステム環境を別紙に示します。今回のテスト環境は、実際の業務時の環境とは以下のような点が異なります。

(1)……

(2)……

しかし、これらの点はシステムのテスト結果には影響を与えません。今回のテスト環境で正常に動作すれば、実際の業務環境でも正常に動作します。
--------------------------------------------------------------

また、テスト段階で、顧客が業務で使用するときとは異なるケースがあります。この場合は、前提条件を明示するとともに、その条件がシステムのテスト結果には無関係であることを断言します。

例えば、次のように記述します。
--------------------------------------------------------------
このようにテスト実施に際して前提とした条件がありますが、それらはシステムの動作には無関係であり、テスト結果に影響を与えることはありません。
--------------------------------------------------------------

3.2.実施するテストの内容(テスト内容/確認内容)
「確認内容」項目は、このテストが「何を確認することを目的としているか」分かるように記述します。
 ・「正常系」テストと「異常系」テストの区分を明示する。
テストでは、正常な使い方をしたケースだけでなく、例外的な使い方や誤った操作をしたケースについても、テスト項目に盛り込みます。
このとき、前者と後者の区別が明確になるような記述が重要です。具体的には、テスト仕様書を見ただけで、
・機能Aの正常な使い方・操作を確認するテスト項目
・機能Aの誤った使い方・操作を確認するテスト項目
が一目で理解できることが大切です。

3.3.テストを実施するためのシステムの操作手順(テスト手順/操作手順)
システムの操作手順は、具体的な操作イメージをつかめるように記述します。操作手順が長く複雑になる場合は、簡潔にまとめましょう。

3.4.テストの実行結果(テスト結果/確認結果)
OK → 問題なし
NG → 問題あり・修正必要/問題未解決・修正必要
「確認内容」では、「テスト結果」だけでなく、「バグがあって正しく動作しなかったときの状況」についても同時に記述します。
ただし、状況の概要は簡潔に記述し、詳細は添付資料に別途まとめる。

3.5..障害報告票番号(発生した障害の詳細を開発グループに報告する帳票の識別番号)
テスト実施期間中は、発生した障害を管理して、障害の詳細を開発担当チームに報告します。このため、テスト項目ごとに「障害報告票番号」の記述が必要となります。
しかし、顧客に提出する版では「障害報告票番号」を削除します。なぜなら、開発チーム内部で活用する情報があると分かりにくくなるからです。
顧客に提出するテスト仕様書には、顧客がテスト結果を確認するために必要な情報だけを記述しましょう。

3.6.テストを実施した年月日(実施日)

3.7.テストを実行した担当者(実施者 )

以上ですが、また気づいた点があったら補足していきます。



2014年6月18日水曜日

SEO対策

SEOについて勉強してみると、大体対応策は、同じであるが、なかなかうまくいかないものである。
主な対応策は、以下である。またそれぞれの対応策に少し味付けを考えてみました。

(1) 必要であればキーワードの再選定
 GoogleWebmasterで、数か月様子見て、キーワードを選ぶ。
 キーワードの記入配置もよく考える。

(2) 内部SEO対策
・titleタグにキーワード追加
 タイトルは、ブラウザに表示また、検索結果に表示されるので、わかりやすくする。
・metaタグにキーワード追加
・h1、h2、h3・・・等の強調タグにキーワード追加
 見出しを付け<h1>タグで、強調する。
 <h1>タグの表示は、<h2>、<h3>などのタグより上部に、記述することが大切です。
・ページ内キーワード率の調整
 5%という話もある。
・ページ容量の調整
・サイト内ページからの被リンクを増やす
 パンくずリスト作成することも有効である
 サイトマップを作成する。
・<strong>タグで、キーワードを強調する。
・ページの簡単な説明文を記入する。
 説明文は、大切なキーワードを挿入しておきましょう。
 descriptionは、各ページ異なる内容にする。
・画像にもキーワードを挿入、altで説明文を記載も有効である

(3) 外部SEO対策
・外部リンクの獲得(検索エンジン登録・テキスト広告リンク・カテゴリ登録・プレスリリース 他)
 無料でできる口コミサイト(例えば、エキテン)登録する。
 Facebook,twitter,g+作成してリンクするのも有効だろう。
・Google、Yahoo!、MSNへのサイト登録
 検索エンジンにURLを登録は、以下で行う。
 ・Google
   http://www.google.co.jp/addurl/?hl=ja&continue=/addurl
 ・Bing
   http://www.bing.com/docs/submit.aspx


また、ライバルサイトと比較して、何がよいのか調べる。

今後すこしづつ、調べて、SEOの有粉手段を見つけていきたい。